Состав batch может меняться между decode ticks
При static batching все requests стартуют вместе, а короткие могут ждать длинный. Continuous batching удаляет завершённые sequences и добавляет новые, чтобы каждый iteration обслуживал актуальный набор. Scheduler должен учитывать доступную KV-memory, token budget, priority и fairness, а не только максимальный batch size. F09.
В упрощённом fixture три requests имеют остатки [2,1,3]. За tick каждый active request производит один token, поэтому active counts [3,2,1], всего шесть token-slots. Реальный iteration time не обязан быть постоянным:
Что показывает модель. Timeline различает waiting, prefill, decode и completed. Хороший throughput может сосуществовать с плохой latency отдельного request, поэтому dashboard показывает queue time, TTFT и inter-token latency отдельно. Admission control должен отклонить или отложить request до allocation, а не падать посреди generation без явной ошибки.
Граница применимости. Учебный tick не моделирует разную prompt length, speculative decoding, preemption, prefix caching или hardware occupancy. Aggressive batching способен увеличить latency. Приоритеты без aging создают starvation; fairness policy должна быть наблюдаемой и тестируемой.