vLLM обходит SGLang на промптах в 64K токенов, но SGLang вырывается вперед, когда контекст достигает 200K на сервере с 8 GPU B300. Этот сдвиг показывает, что при расширении окна токенов производительность диктуется узкими местами на этапе декодирования (decode stage), а не на этапе prefill.
Почему этот бенчмарк важен
Инференс с длинным контекстом определяет стоимость работы чат-ассистентов, помощников по написанию кода и любых приложений, которым необходимо держать сотни тысяч токенов в памяти. Kimi-K3, модель с огромным количеством параметров, является одной из первых LLM с открытыми весами, способных комфортно работать с такими окнами, но именно движок, на котором она запущена, определяет, завершится ли запрос за секунды или за минуты.
И vLLM, и SGLang обещают высокую пропускную способность инференса, однако они используют противоположные подходы к этапу декодирования. vLLM сохраняет путь декодирования простым, избегая дополнительной синхронизации, которую вносит Decode Context Parallelism (DCP). SGLang распределяет чтение KV-кэша (key-value cache) между несколькими GPU с помощью DCP — эта техника позволяет эффективно распределить нагрузку на пропускную способность памяти ценой увеличения объема межпроцессорного взаимодействия.
Тестовый стенд
- Hardware: один сервер с восемью GPU NVIDIA B300, каждая с идентичным объемом памяти.
- Workloads: два режима длины контекста — 64K токенов (нижняя граница «длинного контекста») и 200K токенов (верхняя граница, на которую ориентировано множество исследовательских демо).
- Metrics: общее время обработки фиксированного батча промптов; пропускная способность вычисляется на основе разницы во времени.
Мы поддерживали размер батча, веса модели и целевые показатели использования памяти неизменными. Единственным параметром, который мы меняли между запусками, был движок инференса.
Цифры говорят сами за себя
| Контекст | Движок | Время (с) | Относительная скорость |
|---|---|---|---|
| 64K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ в 1.5× быстрее | |
| 200K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ в 1.31× быстрее |
Пропускная способность (токенов в секунду) у vLLM резко упала при увеличении контекста: снижение в 3.29× при переходе от 64K к 200K. Пропускная способность SGLang за тот же период снизилась всего в 1.25×.
Откуда берется разрыв
Оба движка тратят примерно одинаковое время на этап prefill — загрузку промпта в KV-кэш. Расхождение проявляется на этапе декодирования, когда модель генерирует токены по одному.
- 64K токенов: преобладает межпроцессорное взаимодействие (inter-GPU communication). Путь декодирования vLLM на одном GPU позволяет избежать дополнительной синхронизации, необходимой для DCP, что позволяет завершить работу примерно в 1.5× быстрее.
- 200K токенов: KV-кэш становится настолько большим, что его чтение превращается в узкое место. DCP в SGLang с размером 8 распределяет эти операции чтения между всеми восемью GPU. Выигрыш в пропускной способности перевешивает затраты на коммуникацию, обеспечивая SGLang явное преимущество.
Второе, практическое наблюдение касается нагрузки на память. Запуск любого из движков с целевым показателем использования памяти 0.95 приводил к повторным попыткам из-за нехватки памяти (OOM) на B300. Снижение целевого показателя до 0.92 устранило повторные попытки и стабилизировало время выполнения, ценой небольшого увеличения задержки (latency).
Кто выигрывает, а кто проигрывает
- Разработчики с коротким или средним контекстом (≤ 64K токенов) получают больше преимуществ от оптимизированного пути декодирования vLLM. Более быстрое выполнение запросов означает более низкие счета за облачные вычисления и более быстрый отклик для пользователя.
- Командам, создающим инструменты для глубокого анализа или исследований, которым необходимо удерживать сотни тысяч токенов в контексте, следует склоняться к SGLang с включенным DCP. Его более стабильная пропускная способность снижает риск таймаутов и поддерживает более высокую загрузку GPU по мере роста требований к памяти.
- Планировщикам оборудования стоит учитывать, что само по себе количество GPU не гарантирует линейного масштабирования. Когда пропускная способность KV-кэша становится узким местом, архитектуры, способные распараллеливать чтение кэша — либо через DCP, либо за счет будущих обновлений подсистемы памяти — будут извлекать больше пользы из того же кремния.
Контраргумент: сможет ли vLLM сократить разрыв?
Пока не появятся новые данные, текущие цифры остаются лучшим публичным сравнением.
За чем следить дальше
- Более широкие окна контекста еще сильнее нагрузят пропускную способность KV-кэша, что потенциально может увеличить отрыв SGLang.
Итог
Если вам нужно обрабатывать запросы с длинным контекстом на кластере на базе B300, выбирайте движок, соответствующий вашему окну токенов. Для нагрузок с контекстом 64K токенов vLLM обеспечивает инференс примерно в 1.5× быстрее. При превышении порога в 200K токенов более эффективным выбором становится декодирование в SGLang на базе DCP, так как его пропускная способность снижается всего в 1.25× по сравнению с падением в 3.29× у vLLM. Установите использование памяти на уровне 0.92, чтобы избежать повторных попыток из-за OOM, и помните, что «лучший» движок зависит от контекста, а не является универсальным решением.