SGLang или vLLM: как выбрать сервер для своей нагрузки

  </tr><tr>
    <td>
    <p>Платформа начального руководства</p>
  </td>
<td>
    <p>Linux рекомендован, Python ≥3.10, NVIDIA CUDA sm80+; другие платформы вынесены в отдельные руководства <a href="#src-s2" rel="noopener noreferrer">s2</a></p>
  </td>
<td>
    <p>Linux, Python 3.10–3.13; NVIDIA, AMD ROCm, Intel XPU и отдельный vLLM-Metal для Mac имеют разные пути <a href="#src-s5" rel="noopener noreferrer">s5</a><a href="#src-s6" rel="noopener noreferrer">s6</a></p>
  </td>

  </tr><tr>
    <td>
    <p>Запуск HTTP</p>
  </td>
<td>
    <p><code>python3 -m sglang.launch_server --model-path &lt;HF_ID&gt;</code>; порт 30000 <a href="#src-s2" rel="noopener noreferrer">s2</a></p>
  </td>
<td>
    <p><code>vllm serve &lt;HF_ID&gt;</code>; порт 8000 <a href="#src-s6" rel="noopener noreferrer">s6</a></p>
  </td>

  </tr><tr>
    <td>
    <p>Проверка модели</p>
  </td>
<td>
    <p>Chat Completions в quickstart; дополнительные API — отдельные главы <a href="#src-s2" rel="noopener noreferrer">s2</a><a href="#src-s3" rel="noopener noreferrer">s3</a></p>
  </td>
<td>
    <p><code>/v1/models</code> и Chat Completions с chat template модели <a href="#src-s6" rel="noopener noreferrer">s6</a><a href="#src-s7" rel="noopener noreferrer">s7</a></p>
  </td>

  </tr><tr>
    <td>
    <p>Измерение сервиса</p>
  </td>
<td>
    <p><code>python3 -m sglang.bench_serving</code> с вариантами native и OpenAI-совместимого API <a href="#src-s4" rel="noopener noreferrer">s4</a></p>
  </td>
<td>
    <p><code>vllm bench serve</code>; собственное руководство предупреждает о кеше при повторах <a href="#src-s8" rel="noopener noreferrer">s8</a></p>
  </td>

  </tr></tbody>
    </table>
  <p>Здесь <code>&lt;HF_ID&gt;</code> означает <strong>один и тот же заранее проверенный</strong> репозиторий модели для обоих серверов, а не универсальное обещание совместимости. Проверяйте формат весов, chat template и выбранный backend до установки: поддержка семейства в одном runtime не доказывает поддержку произвольной квантизации в другом <a href="#src-s2" rel="noopener noreferrer">s2</a><a href="#src-s7" rel="noopener noreferrer">s7</a>. Разница в файле весов и конфигурации модели разрушает чистоту сравнения; отдельный <a href="/zhurnal/videokarta-dlya-llm/" rel="noopener noreferrer">гайд по видеопамяти</a> помогает заранее спланировать запас, но файл весов нельзя считать минимальной VRAM.</p><h2>Когда выбирать по железу, а когда — по привычному API?</h2><p>Для типовой NVIDIA-конфигурации актуальная страница установки SGLang описывает CUDA 13 и предупреждает, что CUDA 12-образы/колёса относятся к прежней ветке; её quickstart формулирует ориентир sm80+ <a href="#src-s1" rel="noopener noreferrer">s1</a><a href="#src-s2" rel="noopener noreferrer">s2</a>. Если вы на иной GPU или CPU, <strong>это не означает, что SGLang там никогда не работает</strong>: у проекта отдельные платформенные страницы, которые следует проверять для своей версии. Не переносите NVIDIA-команды на AMD или Mac без такой проверки <a href="#src-s1" rel="noopener noreferrer">s1</a><a href="#src-s2" rel="noopener noreferrer">s2</a>. В vLLM quickstart перечислены отдельные пути ROCm, Intel XPU и Apple Silicon через vLLM-Metal; каждый требует собственной совместимости, и широкая строка «поддерживает платформу» не равна гарантии для вашего устройства <a href="#src-s5" rel="noopener noreferrer">s5</a><a href="#src-s6" rel="noopener noreferrer">s6</a>.</p><p>Оба документа показывают OpenAI-совместимый Chat API, но <strong>«совместим» не значит «все расширения и аргументы одинаковы»</strong>: сверяйте конкретный endpoint и требуемые поля клиента. SGLang также документирует отдельные семейства API, а vLLM разделяет Chat, Responses, embeddings и другие маршруты по типам модели <a href="#src-s3" rel="noopener noreferrer">s3</a><a href="#src-s7" rel="noopener noreferrer">s7</a>. Для закрытого контура не выставляйте тестовый сервер на публичный интерфейс: quickstart SGLang демонстрирует <code>--host 0.0.0.0</code> как пример запуска, но это меняет сетевую доступность. У vLLM опция <code>--api-key</code> не защищает все endpoints, поэтому доступность сети следует ограничивать отдельно; по одной настройке токена приватность не доказана <a href="#src-s2" rel="noopener noreferrer">s2</a><a href="#src-s7" rel="noopener noreferrer">s7</a>.</p><h2>Как проверить, что сравниваются работающие серверы?</h2><p>Откройте инструкции <a href="/zhurnal/sglang/" rel="noopener noreferrer">SGLang</a> и <a href="/zhurnal/vllm/" rel="noopener noreferrer">vLLM</a> и установите выбранные версии в <strong>разных средах</strong>, не смешивая CUDA-зависимости <a href="#src-s1" rel="noopener noreferrer">s1</a><a href="#src-s6" rel="noopener noreferrer">s6</a>. Запишите ОС, драйвер, GPU, ревизию модели и версию каждого runtime. Для SGLang quickstart описывает запуск <code>python3 -m sglang.launch_server --model-path &lt;HF_ID&gt;</code> и ответ <code>/v1/chat/completions</code>; для vLLM — <code>vllm serve &lt;HF_ID&gt;</code>, <code>/v1/models</code> и Chat Completions при наличии chat template <a href="#src-s2" rel="noopener noreferrer">s2</a><a href="#src-s6" rel="noopener noreferrer">s6</a><a href="#src-s7" rel="noopener noreferrer">s7</a>.</p><p>Сначала отправьте <strong>по одному одинаковому вопросу</strong> на оба порта и проверьте, что HTTP-ответ содержит ожидаемую структуру и соответствует тому же репозиторию модели. Ошибка запуска, несовместимый формат или отсутствующий chat template — результат проверки совместимости, но не «медленный runtime». Лишь после успешного ответа приступайте к замеру. Не запускайте два сервера одновременно на одном занятом GPU, если хотите сопоставить доступный каждому ресурс: выполняйте прогоны последовательно, фиксируя состояние устройства.</p><h2>Как измерить свою нагрузку без ложного «победителя»?</h2><p><strong>Подготовьте набор запросов</strong> из вашего сценария: короткие одиночные вопросы, длинные фрагменты документов и, если это характерно вашему приложению, повторяющийся системный контекст с разными пользовательскими вопросами. Нагрузочный инструмент SGLang умеет режимы <code>random</code>, <code>generated-shared-prefix</code> и <code>agentic-trace</code>, а vLLM — в том числе <code>random</code>, <code>prefix repetition</code> и custom dataset <a href="#src-s4" rel="noopener noreferrer">s4</a><a href="#src-s8" rel="noopener noreferrer">s8</a>. Синтетика полезна как техническая проверка, но не заменяет ваши реальные входы и ожидаемое поведение. Не включайте клиентский код, скачивание весов и подготовку датасета во время собственно измерения.</p><p>Используйте <strong>один клиент</strong> для обоих серверов: <code>sglang.bench_serving</code> поддерживает backends <code>sglang-oai-chat</code> и <code>vllm-chat</code> для одного <code>/v1/chat/completions</code>, ограничение <code>--request-rate</code> и <code>--max-concurrency</code> <a href="#src-s4" rel="noopener noreferrer">s4</a>. Для репрезентативности задайте одинаковые модель и ревизию, precision/quantization (если оба их действительно поддерживают), длины входов/выходов, параметры генерации, tokenizer, конкурентность, скорость поступления запросов и streaming. Документация SGLang различает burst (<code>--request-rate inf</code>) и ненулевую интенсивность прихода, а без streaming TTFT может совпасть с общей задержкой; не смешивайте эти режимы в одной таблице <a href="#src-s4" rel="noopener noreferrer">s4</a>.</p><p><strong>Замеряйте отдельно:</strong> успешность и корректность ответов, время до первого токена (TTFT), интервалы между выдачами (ITL), задержку целого запроса и суммарную пропускную способность. У vLLM TPOT вычисляется для запроса как <code>(полная задержка − TTFT) / (число выходных токенов − 1)</code>; ITL измеряет интервалы между streaming-выдачами, поэтому при пакетной выдаче нескольких токенов эти метрики не обязаны совпадать <a href="#src-s8" rel="noopener noreferrer">s8</a>. Сравнивайте определения, а не одинаково названные колонки двух инструментов.</p><p><strong>Кеш — часть условий.</strong> Повтор одного и того же датасета может сохранить префиксы в кеше vLLM и искусственно улучшить итог; его собственная инструкция рекомендует менять seed, очищать/перезапускать сервер либо использовать sweep с контролем кеша <a href="#src-s8" rel="noopener noreferrer">s8</a>. Документация клиента SGLang умеет <code>--flush-cache</code> для обоих backend, однако для сброса vLLM требует <code>VLLM_SERVER_DEV_MODE=1</code> при старте; не переносите этот режим в открытый production-сервер и не называйте отсутствие сброса «холодным» прогоном <a href="#src-s4" rel="noopener noreferrer">s4</a>. Проведите <strong>раздельно холодный и тёплый</strong> сценарии с записанным состоянием кеша и несколькими повторами, не выбирая самый красивый результат.</p><h2>Когда ни один сервер не является готовым решением?</h2><p>Если ваш checkpoint, квантование или backend не проверены на выбранном runtime, начните с одного исправного ответа и протокола ошибки, а не с бенчмарка <a href="#src-s2" rel="noopener noreferrer">s2</a><a href="#src-s6" rel="noopener noreferrer">s6</a><a href="#src-s7" rel="noopener noreferrer">s7</a>. Если в задаче важны приватные документы, общий Chat API и токен не доказывают сетевой изоляции и разграничения прав <a href="#src-s7" rel="noopener noreferrer">s7</a>. Если GPU-памяти не хватает для выбранного контекста и параллелизма, снижение latency на чужом стенде вам не поможет: проверяйте размещение и ошибки на собственном устройстве, а не превращайте размер весов или vendor-замеры в «минимальную VRAM».</p><p><strong>Следующий шаг:</strong> <a href="/zhurnal/sglang/" rel="noopener noreferrer">подготовить SGLang по отдельному гайду</a>, затем получить ответ той же модели через <a href="/zhurnal/vllm/" rel="noopener noreferrer">vLLM</a> и сохранить таблицу условий, ошибок и измерений. Modelium не проводил этот сравнительный прогон; скорости и «победителя» здесь намеренно нет.</p>