LLM serving workload оказывается существенно сложнее, чем принято моделировать. FineServe показывает, как реальные нагрузки ломают упрощённые предположения и влияют на архитектуру.
Современные LLM-платформы работают как always-on сервисы с жёсткими требованиями к latency и throughput.
Основная проблема — нестабильный и неоднородный LLM serving workload.
Большинство исследований опирались на синтетические или прокси-трейсы, где нагрузка моделируется как стационарный процесс. FineServe показывает, что это допущение системно неверно. В реальных multi-model системах поведение запросов зависит от архитектуры модели, её размера и пользовательского сценария. В результате деградация начинается не из-за пиков как таковых, а из-за несовпадения модели нагрузки с реальной динамикой: burstiness, non-stationarity и token variability накладываются друг на друга.
Решение, предложенное в FineServe, — перейти к fine-grained анализу workload.
Вместо агрегированных метрик система рассматривает три оси: архитектура (Dense vs MoE), scale tier и task intent. Это прагматичный выбор: он не усложняет систему искусственно, но даёт достаточно сигналов для routing, scheduling и capacity planning.
Ключевой trade-off — рост сложности моделирования и генерации нагрузок.
Однако без этого невозможно адекватно оценивать multi-model LLM serving. В частности, выясняется, что small Dense модели создают наиболее нестабильный трафик, тогда как крупные MoE — более предсказуемы, но склонны к резким всплескам.
На уровне реализации FineServe опирается на production dataset: 1.48B запросов, десятки моделей, глобальная инфраструктура. Важная деталь — используются только metadata (timestamps, token counts, model id), без пользовательского контента. Это позволяет анализировать arrival patterns и token geometry без нарушения приватности. Для моделирования нагрузки применяется двухуровневый подход:
- Gamma-распределение для inter-arrival time (IAT),
- Negative Binomial для миллисекундной агрегации запросов.
Это закрывает важный разрыв: классические модели учитывают среднюю интенсивность, но игнорируют burstiness на малых интервалах. В результате система недооценивает queue buildup и tail latency. FineServe показывает, что для Dense <10B моделей это критично: у них наблюдается высокая MSSD (резкие колебания), даже при относительно ровном среднем потоке.
Отдельный слой — token geometry. Здесь проявляется менее очевидная проблема. Входные токены имеют тяжёлые хвосты (long-context), а выходные — более ограничены, но всё равно значимы. При этом зависимость input-output не линейна. Для Dense моделей характерна inverted-bowl зависимость: рост output до определённого порога входа, затем падение. Это связано с переходом от генерации к summarization.
У MoE моделей — другая картина: рост с насыщением.
Это различие напрямую влияет на KV-cache, batching и memory pressure. Унифицированные модели оценки здесь дают искажения. Task intent добавляет ещё один уровень неоднородности. Например: — технические задачи ведут себя как inverted-bowl — conversational задачи почти не зависят от длины входа Это означает, что даже при одинаковых arrival rates система может испытывать разную нагрузку на decode и prefill стадии. Игнорирование этого фактора приводит к неправильному buffer allocation и деградации latency.
Результат работы — не только dataset, но и генератор нагрузки. FineServe workload generator умеет: — воспроизводить реальные трейсы (trace replay) — генерировать синтетические, но реалистичные нагрузки (parametric synthesis).
Ключевая идея — смешивание per-model потоков с учётом их статистических свойств. Это важно для benchmarking: вместо “средней” нагрузки можно тестировать систему в условиях, близких к production. При этом авторы прямо отмечают: точных метрик улучшения системы не приводится. Фокус — на корректности моделирования, а не на оптимизации конкретной реализации.
Главный вывод для архитекторов: LLM serving workload нельзя рассматривать как единый процесс. Он принципиально неоднороден и зависит от:
- типа модели,
- её размера,
- пользовательского сценария.
Практическое следствие — необходимость architecture-aware стратегий: — для Dense моделей — быстрые scheduler’ы, чувствительные к jitter — для MoE — устойчивость к крупным burst’ам и грамотное capacity planning FineServe не предлагает универсального решения, но задаёт более точную модель реальности. Это эволюционное улучшение, которое делает benchmarking и проектирование систем менее наивными.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей. Материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. Сайт — arxiv.org