SGLang или vLLM: что проверить перед выбором LLM-сервера — поддержку архитектуры, оборудование и условия измерения. Для выбора проверяют пять вещей: поддержку архитектуры вашей модели, поддержку вашего ускорителя, совпадение API и планировщика, режим кэша и порядок замеров. Решение принимается на одной модели и одном оборудовании. Чужие бенчмарки для этого не годятся.
Что именно сравнивают в SGLang и vLLM
Оба проекта решают одну задачу: держать языковую модель на сервере и отдавать ответы по сети. Документация SGLang описывает фреймворк для больших языковых, визуально-языковых и диффузионных моделей, оптимизированный под агентные нагрузки, крупный сервинг и RL-прогоны. Документация vLLM указывает поддержку GPU NVIDIA, GPU AMD и процессоров x86, ARM и PowerPC, а также плагины под TPU Google, Intel Gaudi, IBM Spyre, Huawei Ascend, Apple Silicon и другие ускорители. Это разные списки, и сверять их нужно построчно под своё железо.
Разница в происхождении подхода видна в первичной работе по SGLang. Авторы описывают систему как совместное проектирование фронтенд-языка и бэкенд-рантайма: язык даёт примитивы для работы с промптами и генерациями, а рантайм обеспечивает автоматический параллелизм, батчинг, кэширование и разделение между вызовами. В той же работе отмечено, что бэкенд-движки того времени опирались на интерфейс одиночного вызова в стиле OpenAI Completion API и обрабатывали промпт без сохранения состояния. Отсюда растёт практический вопрос: сколько вызовов в вашем сценарии связано общим префиксом.
Предел механизма прост. Кэш помогает там, где запросы повторяют общий кусок текста. Если каждый запрос уникален, делиться нечем, и выигрыш упирается в скорость самой модели и ускорителя. Ни один из двух серверов не даёт постоянного преимущества по скорости: результат зависит от модели, точности, длины контекста, конкурентности и версии рантайма.
Учебный паспорт: один вход для обеих сторон
Чтобы сравнение было осмысленным, зафиксируйте вход до запуска. Ниже учебный паспорт: абстрактная модель M с одним revision, одна GPU G, одинаковая точность, контекст 4096. Это заданные настройки учебного плана. Они не описывают лимиты продуктов.
Модель: M, revision один и тот же для обоих серверов
Ускоритель: G, один и тот же экземпляр
Точность: одинаковая на обеих сторонах
Контекст: 4096
Конкурентность: 1, затем 4, затем 8
Политика кэша: одинаковая на обеих сторонах
Разогрев: одинаковое число запросов до замера
Максимальная длина выхода: одинаковая
Задачи:
1) "17+26" -> ожидаемый ответ 43
2) полный документ "Для замены нужен код R-2", вопрос о коде -> ожидаемый ответ R-2
3) общий префикс "Правило мастерской v1" с двумя вопросами:
"Как называется правило?" -> Правило мастерской
"Какая версия указана?" -> v1
Три задачи закрывают три разных поведения. Первая проверяет короткий запрос без общего префикса. Вторая проверяет извлечение факта из полного короткого документа. Третья проверяет разделение кэша: префикс один, вопросы разные. Разницу времени в третьей задаче ещё нужно объяснить: сначала проверьте фактические cache hit, разогрев, токенизацию и длину выхода. По одному результату причина не устанавливается.
Эталон проверки — правильность ответов на трёх задачах при одинаковых условиях. Эталоны: 43, R-2, а для двух вопросов с общим префиксом — название Правило мастерской и версия v1. Замеры без этой проверки бессмысленны: быстрый сервер, который отвечает неверно, задачу не решает.
Структурная корректность и фактическая правильность
Эти две вещи расходятся, и разводить их нужно до замеров. Структурная корректность означает, что сервер поднялся, принял запрос, вернул ответ в ожидаемом формате и не упал под нагрузкой. Фактическая правильность проверяется по эталонам: арифметический ответ 43 и точный код R-2.
Сервер может быть структурно исправен и фактически неверен. Причины бывают разные: несовпадение шаблона чата, обрезанный контекст, неверный параметр сэмплирования, потеря части документа при усечении. Все они выглядят как успешный HTTP-ответ.
Практический порядок такой. Сначала прогоните три задачи при конкурентности 1 и сверьте ответы с эталоном. Затем поднимите конкурентность до 4 и до 8 и повторите сверку. Только после того, как ответы совпали на всех трёх уровнях, переходите к метрикам времени. Обратный порядок даёт красивые графики по неверным ответам.
Отдельно проверьте, что оба сервера получают одинаковый текст промпта. Разный шаблон чата меняет и ответ, и длину входа, и тогда сравнение времени теряет смысл.
Таблица отвода: что проверить до запуска
Заполните таблицу до первого запроса. Она отсеивает варианты, которые не стоит мерить.
| Проверка | Что смотрим | Если не выполнено |
|---|---|---|
| Архитектура модели M | Список поддерживаемых архитектур в документации сервера | Отвод до замера |
| Revision модели | Совпадение revision на обеих сторонах | Отвод до замера |
| Ускоритель G | Список поддерживаемого железа и плагинов | Отвод до замера |
| Backend и драйвер | Совместимость версии драйвера с рантаймом | Отвод до замера |
| API | Совпадение формата запроса и ответа | Отвод до замера |
| Планировщик | Режим батчинга и его настройки | Отвод до замера |
| Кэш | Политика кэша и её параметры | Отвод до замера |
| Точность | Одинаковый режим на обеих сторонах | Отвод до замера |
Строки «API» и «Кэш» чаще всего дают ложное совпадение. Два сервера могут принимать похожий JSON и по-разному трактовать параметры. Сверяйте не только имена полей, но и значения по умолчанию.
Внешние утверждения о поддержке железа берите из документации конкретного проекта. Документация SGLang по ROCm описывает запуск на GPU AMD через готовый Docker-образ или pip и требует установленного драйвера amdgpu. Документация vLLM отдельно упоминает работу на macOS через vLLM-Metal для ускорения на Apple Silicon. Версии образов, порты и переменные окружения переносите между продуктами с осторожностью: у каждого владельца свои значения.
Различия, которые нужно записать в паспорт
Документация SGLang называет RadixAttention, кэширование префиксов и multi-GPU параллелизм среди механизмов рантайма. Это не означает, что один сервер умеет кэшировать префиксы, а второй нет: документация vLLM тоже перечисляет prefix caching вместе с continuous batching и chunked prefill. PagedAttention в vLLM относится к управлению KV-памятью. Эти названия описывают разные стороны работы, поэтому противопоставлять RadixAttention и PagedAttention как взаимоисключающие свойства всех версий нельзя.
Для интерфейса тоже нужны конкретные проверки. Туториал SGLang показывает /v1/chat/completions и опубликованную сервером спецификацию OpenAPI. vLLM заявляет OpenAI-совместимый сервер, потоковый вывод, структурированные ответы и вызовы инструментов. Наличие совместимого endpoint ещё не доказывает одинаковые значения параметров по умолчанию.
Quickstart vLLM отдельно предупреждает: offline-метод llm.generate сам не применяет chat template, тогда как llm.chat принимает сообщения; сервер по умолчанию использует шаблон из токенизатора. Та же документация сообщает, что параметры сэмплирования могут браться из generation_config.json модели. Поэтому в сравнении нужно записать фактически применённый шаблон и параметры, иначе скорость и правильность смешаются с различиями входа. Эти детали относятся к описанным API vLLM; для SGLang поведение сверяют по его документации.
Метрики: что мерить и в каком порядке
После отвода и проверки правильности остаются шесть чисел. Сравнивайте их попарно при одинаковых условиях.
| Метрика | Что показывает | Условие сопоставимости |
|---|---|---|
| TTFT | Время до первого токена | Одинаковый разогрев |
| Межтокенная задержка | Скорость генерации после первого токена | Одинаковая длина выхода |
| p95 конечной задержки | Хвост распределения | Одинаковая конкурентность |
| Успешные запросы в секунду | Пропускная способность | Одинаковый набор задач |
| Peak memory | Потребление памяти | Одинаковый контекст |
| Правильность задач | Совпадение с эталоном | Одинаковый шаблон промпта |
Порядок замера: разогрев, затем конкурентность 1, 4, 8, и на каждом уровне сначала правильность, потом время. Если разошлись cache hit или число выходных токенов, сначала установите и запишите причину. Различия прогрева, входов и настроек требуют повторного сопоставимого прогона. При одинаковых внешних условиях разную эффективность кэша учитывайте как результат конкретной конфигурации. Для сравнения скорости генерации проведите отдельный прогон с фиксированной длиной выхода.
Поля результатов держите пустыми до реального запуска. Заполнять их заранее нельзя: числа появятся только после прогона на вашем железе.
Случай, где сравнение не решает задачу
Бывает сценарий, в котором выбор между двумя серверами не меняет результат. Пример: у вас один пользователь, короткие уникальные запросы без общего префикса, модель помещается в память с запасом, а узкое место — скорость самого ускорителя. Кэш разделять нечего, батчинг нечего группировать, конкурентность равна единице. Даже в таком случае реализации ядер могут различаться, поэтому равную скорость заранее утверждать нельзя. Приоритет проверки — установить фактическое узкое место.
Второй случай: модель или её архитектура отсутствует в списке поддержки одного из серверов. Тогда вопрос выбора закрывается на этапе отвода, и метрики не нужны.
Третий случай: требования к API заданы извне. Если ваш клиент жёстко ждёт определённый формат ответа, а сервер его не отдаёт, скорость не имеет значения.
Ни один из этих случаев не означает, что подход плох. Он означает, что сравнение серверов здесь не является рычагом. Рычаг лежит в железе, в модели или в клиенте.
Частые вопросы
SGLang или vLLM: что лучше по скорости?
Постоянного победителя нет. Скорость зависит от модели, точности, длины контекста, конкурентности и версии рантайма. Сравнивать нужно на своей модели и своём железе по одинаковому паспорту.
Как понять, поддерживает ли сервер мою модель?
Сверьте архитектуру и revision модели со списком поддерживаемых архитектур в документации конкретного сервера. Если архитектуры в списке нет, вариант отводится до замера. Документация vLLM перечисляет поддерживаемое железо и плагины, документация SGLang — свои платформы.
Почему нельзя взять готовый бенчмарк из интернета?
Чужой бенчмарк снят на другой модели, другой точности и другой конкурентности. Числа из него не переносятся на ваш случай. Готовый бенчмарк помогает выбрать методику проверки. Результат для своей конфигурации получают отдельным запуском.
Какие метрики обязательно мерить?
TTFT, межтокенную задержку, p95 конечной задержки, успешные запросы в секунду, peak memory и правильность на трёх задачах. Правильность проверяется до времени, иначе замеры теряют смысл.
Что делать, если оба сервера прошли отвод?
Прогнать учебный паспорт на обоих при конкурентности 1, 4 и 8. Сравнить шесть метрик при одинаковых условиях. Если условия разошлись, уровень из сравнения выпадает, и вывод по нему не делается.