_Перевод полной статьи Amit Shekhar для черновика Ghost. Источники: пост в X и оригинальная статья Outcome School._

Как работает SGLang?

Автор: Amit Shekhar Опубликовано: 30 июня 2026

В этой статье мы разберём, как работает SGLang. Мы также посмотрим, какую проблему он решает, как ускоряет обслуживание больших языковых моделей и какие умные идеи делают его особенным.

Мы рассмотрим следующее:

• Что такое SGLang
• Краткое повторение: как LLM генерирует текст
• Какую проблему решает SGLang
• RadixAttention: сердце SGLang
• Как RadixAttention переиспользует уже выполненную работу
• Фронтенд-язык SGLang
• Как runtime и frontend работают вместе
• Continuous batching в SGLang
• Структурированный вывод и более быстрое декодирование
• Простая картина от начала до конца
• Более мощные возможности SGLang
• Как SGLang сравнивается с vLLM

Я — Amit Shekhar, основатель Outcome School. Я обучал и менторил многих разработчиков; их усилия помогли им получить высокооплачиваемую работу в IT, помогли технологическим компаниям решать их уникальные задачи и привели к созданию множества open-source-библиотек, которыми пользуются ведущие компании. Я люблю делиться знаниями через open source, блоги и видео.

Я преподаю AI и Machine Learning в Outcome School.

Начнём.

Что такое SGLang

SGLang — это высокопроизводительный фреймворк для обслуживания больших языковых моделей и мультимодальных моделей.

Проще говоря, это инструмент, который берёт большую языковую модель и обслуживает её ответы для множества пользователей одновременно — настолько быстро, насколько возможно.

Название SGLang состоит из двух частей.

SGLang = SG (Structured Generation, структурированная генерация) + Lang (Language, язык).

То есть само название говорит нам две вещи. Он помогает генерировать структурированный вывод контролируемым способом и даёт небольшой язык, на котором мы можем описывать инструкции.

Не переживайте, мы подробно разберём каждую из этих частей.

Пока запомните главное. У SGLang есть две основные части, которые дают эти возможности. Одна часть — это runtime, движок, который фактически быстро запускает модель и отвечает за структурированный вывод. Другая часть — frontend language, тот самый небольшой язык, удобный способ сказать модели, что нужно сделать.

Теперь, прежде чем понять, почему SGLang быстрый, нужно сначала понять, как LLM генерирует текст. Когда мы это разберём, магия SGLang станет очень понятной.

Краткое повторение: как LLM генерирует текст

LLM пишет текст по одному слову за раз. Точнее, по одному токену за раз.

Токен — это небольшой фрагмент текста. Это может быть целое слово, часть слова или даже один символ. Для простоты можно думать о токене как примерно об одном слове.

Модель читает наш ввод, затем выдаёт один токен. Потом она читает наш ввод плюс этот новый токен и выдаёт следующий токен. И так продолжается, пока ответ не будет завершён.

Допустим, мы спрашиваем модель: «The sky is».

Сначала модель читает «The sky is» и выдаёт «blue».

Затем она читает «The sky is blue» и выдаёт «today».

Здесь важно заметить одну вещь. Чтобы выдать каждый новый токен, модель оглядывается на всё, что было раньше.

Но заново просматривать все предыдущие токены снова и снова было бы очень медленно. Поэтому модель сохраняет полезные числовые представления предыдущих токенов и переиспользует их. Эти сохранённые данные называются KV cache.

KV cache — это память модели о токенах, которые она уже обработала. KV означает key-value cache, кэш ключей и значений. Глубокая математика здесь не нужна. Нам достаточно простой идеи.

KV cache — это сохранённая работа модели для токенов, которые она уже видела, чтобы ей не приходилось повторять эту работу для каждого нового токена.

Этот KV cache очень важен. Это ключ к пониманию того, почему SGLang настолько быстр. Держите эту идею в голове.

Какую проблему решает SGLang

Теперь разберём реальную проблему.

В реальном мире LLM отвечает не одному человеку. Она отвечает тысячам людей одновременно. И одну и ту же модель снова и снова просят о похожих вещах.

Представим, что мы строим чат-бота. Каждый диалог начинается с одной и той же инструкции, которая называется system prompt.

System prompt — это фиксированный набор инструкций, который мы даём модели до того, как говорит пользователь. Например: «You are a helpful assistant.».

То есть каждый пользовательский запрос начинается с одной и той же инструкции. Модели приходится обрабатывать один и тот же текст снова и снова, для каждого пользователя. Это напрасная работа.

Другой пример. Допустим, мы строим агента, который отвечает на вопросы по документу. Документ один и тот же для каждого вопроса. Но модель каждый раз читает весь документ с нуля.

Это похоже на то, как если бы вы читали целую книгу с первой страницы каждый раз, когда кто-то задаёт маленький вопрос по ней. Это медленно и тратит усилия впустую.

Проблема ясна: модель много раз повторяет одну и ту же дорогую работу. Нам нужен способ выполнить эту общую работу один раз и затем переиспользовать её.

И здесь на помощь приходит SGLang.

SGLang построен вокруг одной центральной идеи. Если два запроса имеют одинаковый начальный текст, они могут разделять сохранённую работу для этого текста. Эта сохранённая работа, как мы уже узнали, — KV cache.

Техника, которая делает такое совместное использование возможным, называется RadixAttention. Это сердце SGLang.

RadixAttention: сердце SGLang

Сначала разберём само название.

RadixAttention = Radix (способ организовывать текст по общим префиксам) + Attention (ключевая операция LLM, с помощью которой модель смотрит назад на предыдущие токены).

Чтобы понять Radix, нужно сначала понять, что такое prefix.

Префикс — это начальная часть, общая для двух фрагментов текста.

Например, посмотрим на «The sky is blue» и «The sky is clear». У них общий префикс «The sky is». После него один текст говорит «blue», а другой — «clear».

SGLang хранит KV cache многих запросов в умной структуре, которая называется radix tree.

Radix tree — это древовидная структура, которая группирует текст по общему префиксу. Можно думать о ней как о семейном дереве предложений. Предложения, которые начинаются одинаково, идут по одной ветке. Они разделяются только там, где становятся разными.

Сделаем это очень конкретным на маленьком примере.

Предположим, три пользователя отправляют такие запросы:

• «You are a helpful assistant. What is the capital of France?»
• «You are a helpful assistant. What is the capital of Japan?»
• «You are a helpful assistant. Tell me a joke.»

Здесь видно, что у всех трёх одинаковое начало: «You are a helpful assistant.».

Без SGLang модель обработала бы «You are a helpful assistant.» три отдельных раза.

С SGLang radix tree хранит эту общую часть один раз. Её KV cache вычисляется только один раз. Затем каждый запрос продолжается дальше. А там, где какие-то запросы всё ещё имеют ещё больше общего текста, этот общий текст становится ещё одной веткой, которая тоже хранится только один раз.

Посмотрим на radix tree ниже:

"You are a helpful assistant."
(общий префикс, KV cache хранится один раз)
|
+-------------+--------------+
|                            |
v                            v
"What is the capital of"     "Tell me a joke."
(общая часть двух запросов,  (уникальный хвост)
KV cache хранится один раз)
|
+---+---+
|       |
v       v
"France?" "Japan?"
(уникально) (уникально)

Здесь видно, что общее начало, «You are a helpful assistant.», находится наверху как одна общая ветка. Её сохранённая работа вычисляется только один раз. Ниже два запроса про столицы имеют ещё больше общего текста: «What is the capital of». Поэтому эта часть становится ещё одной общей веткой, и её сохранённая работа тоже хранится только один раз. Только в самом низу «France?» и «Japan?» расходятся в свои уникальные части. Запрос «Tell me a joke.» использует только верхнюю общую ветку, а дальше идёт своим путём. Ни одна из общих веток никогда не пересчитывается.

Так RadixAttention экономит огромное количество работы. Общий префикс обрабатывается один раз, а сохранённая работа переиспользуется другими запросами с тем же префиксом, пока она остаётся в памяти.

Проблема решена.

Как RadixAttention переиспользует уже выполненную работу

Теперь разберём шаги, которым следует SGLang. Это сделает картину полностью понятной.

Шаг 1: приходит новый запрос. Например: «You are a helpful assistant. What is the capital of Italy?».

Шаг 2: SGLang смотрит на своё radix tree. Он проверяет, какая часть начала этого запроса уже есть в дереве.

Шаг 3: Он обнаруживает, что «You are a helpful assistant. What is the capital of» уже есть, потому что более ранние запросы про Францию и Японию добавили эту часть. Поэтому он переиспользует сохранённый KV cache для всего этого фрагмента. Он не пересчитывает его.

Шаг 4: Только новая часть, «Italy?», обрабатывается заново. Новая сохранённая работа затем добавляется в дерево как новая ветка.

Шаг 5: Модель генерирует ответ по одному токену за раз, как мы уже обсуждали.

Чем больше текста разные запросы разделяют между собой, тем больше работы экономит SGLang. Это совместное использование происходит автоматически. Нам не нужно делать ничего особенного, чтобы включить его.

Есть ещё одна важная вещь. Память, в которой хранится KV cache, ограничена. Она не может держать всё вечно.

Поэтому SGLang должен решать, что оставить, а что выбросить, когда память заполняется. Он использует простое и умное правило: сначала удаляет ветки, которые использовались давнее всего. То есть ветки, которыми никто не пользовался дольше всего, удаляются первыми.

Это разумный выбор. Популярные общие префиксы, например system prompt, остаются в памяти, потому что используются постоянно. Редкие одноразовые части удаляются, когда нужно место.

Так SGLang сохраняет самую полезную выполненную работу и переиспользует её настолько часто, насколько возможно.

У нас есть подробная статья о том, как работает prompt caching; она объясняет это глубже.

Фронтенд-язык SGLang

До сих пор мы говорили о движке. Теперь пора разобраться с удобной частью — frontend language.

Frontend language — это простой способ писать инструкции для модели прямо внутри нашего Python-кода.

Зачем это нужно? Потому что реальные задачи редко сводятся к одному вопросу. Реальная задача часто состоит из нескольких шагов.

Допустим, мы хотим, чтобы модель сделала следующее:

• Прочитала абзац.
• Сделала его краткое содержание.
• Затем перевела это краткое содержание на французский.

Это три шага, которые зависят друг от друга. Писать всё это вручную и одновременно сохранять высокую скорость сложно.

Поэтому frontend language позволяет ясно описывать такие шаги. Мы можем написать последовательность вызовов модели, смешивать их с собственным текстом и сохранять вывод модели в переменные.

Посмотрим на небольшой пример:

import sglang as sgl

@sgl.function
def summarize_and_translate(s, paragraph):
    s += "Summarize this paragraph:\n" + paragraph + "\n"
    s += "Summary: " + sgl.gen("summary", max_tokens=64)
    s += "Now translate the summary to French.\n"
    s += "French: " + sgl.gen("french", max_tokens=64)

Здесь мы определили функцию, которая выполняет два вызова модели по порядку.

• Переменная s содержит растущий диалог. Мы продолжаем добавлять в неё текст.
• sgl.gen("summary", ...) просит модель сгенерировать краткое содержание и сохранить его под именем summary.
• После этого мы просим модель перевести текст и сохраняем результат под именем french.

То есть мы описываем весь поток простыми шагами, а SGLang эффективно выполняет его за кулисами.

В этом красота frontend language. Мы просто записываем наше намерение, а runtime заботится о скорости и совместном использовании.

Как runtime и frontend работают вместе

Теперь свяжем две части, которые мы изучили.

Frontend language — это способ описать задачу. Runtime — это движок, который быстро выполняет её с помощью RadixAttention.

Самое интересное вот в чём. Frontend понимает структуру нашей программы. Он знает, какие части фиксированные и общие, а какие — новые.

Поэтому, когда много запросов запускают одну и ту же программу, у них естественным образом появляются общие префиксы. Runtime видит это и переиспользует KV cache через radix tree.

Проще говоря, frontend и runtime спроектированы так, чтобы помогать друг другу. Frontend показывает общую структуру, а runtime использует её для скорости.

Эта совместная работа — главная причина, по которой SGLang одновременно прост в использовании и быстр.

Короткая заметка для вас

В какой бы технологической области вы ни работали, стоит разобраться с этими темами:

• LLM
• RAG
• MCP
• Agent
• Fine-tuning
• Quantization

Мы собрали всё это в одном видео:

AI Engineering Explained: LLM, RAG, MCP, Agent, Fine-Tuning, and Quantization

Не нужно прекращать чтение — добавьте в закладки и посмотрите позже, когда будет время. Будущая версия вас скажет спасибо.

Теперь вернёмся к теме.

Continuous batching в SGLang

Теперь изучим ещё одну идею, которая помогает SGLang оставаться быстрым. Эта идея не уникальна для SGLang. Её используют многие современные serving-системы. Она называется continuous batching.

Сначала: что такое batch? Batch — это группа запросов, которые модель обрабатывает вместе одновременно. Обрабатывать много запросов вместе намного эффективнее, чем по одному.

Но у простого batching есть проблема. Разные запросы заканчиваются в разное время. Один пользователь может хотеть короткий ответ, другой — длинный.

В batching старого типа мы ждали бы, пока завершится вся группа, прежде чем запускать новую группу. Это означает, что быстрые запросы застревают в ожидании медленных. Время тратится впустую.

И здесь на помощь приходит continuous batching.

Continuous batching означает, что как только один запрос в группе завершается, новый ожидающий запрос сразу занимает его место. Мы не ждём завершения всей группы.

Представим batch из четырёх запросов. Второй запрос завершился рано. Вместо того чтобы оставить слот пустым, SGLang сразу заполняет его следующим ожидающим запросом.

Посмотрим на разницу:

Batching старого типа (слот пустует, время тратится впустую):

Slot 1: [ R1 выполняется ............ ]
Slot 2: [ R2 завершён ] [ пусто, ждём всю группу ]
Slot 3: [ R3 выполняется ............ ]
Slot 4: [ R4 выполняется ............ ]

Continuous batching (пустой слот сразу заполняется):

Slot 1: [ R1 выполняется ............ ]
Slot 2: [ R2 завершён ] [ R5 сразу стартует ........ ]
Slot 3: [ R3 выполняется ............ ]
Slot 4: [ R4 выполняется ............ ]

Здесь видно, что при batching старого типа слот завершённого запроса остаётся пустым, пока не завершится вся группа. При continuous batching новый ожидающий запрос, R5, сразу заходит в этот слот. Ни один слот не простаивает.

Так модель всегда остаётся занятой. Ни один слот не пустует. Это заставляет железо работать на полную мощность и обслуживать больше пользователей за то же время.

Так continuous batching выжимает максимум из машины.

Один важный момент: continuous batching — распространённая техника, так что это не та часть, которая делает SGLang особенным. Особенность в том, что SGLang объединяет continuous batching и RadixAttention. RadixAttention переиспользует общую работу через radix tree, а continuous batching держит машину занятой. Именно эта комбинация помогает SGLang сиять, когда много запросов имеют длинное общее начало.

Чтобы разобраться, как serving-движки остаются быстрыми — KV Cache, Continuous Batching, Prompt Caching и Paged Attention — посмотрите нашу программу AI and Machine Learning Program в Outcome School.

Структурированный вывод и более быстрое декодирование

Вспомним название ещё раз. В SGLang есть слова «Structured Generation». Теперь мы наконец разберём эту часть.

Часто нам нужен от модели не свободный текст. Нам нужен ответ в фиксированном формате.

Например, нам может понадобиться JSON такого вида:

{
  "name": "Italy",
  "capital": "Rome"
}

JSON — это простой и распространённый формат для хранения данных как набора имён и значений. Многие программы читают и записывают данные в этом формате.

Проблема в том, что обычная модель может выдать слегка сломанный JSON. Она может забыть скобку или добавить лишние слова. Тогда наша программа не сможет его прочитать.

Поэтому SGLang позволяет принудительно заставить вывод следовать фиксированной форме. Мы задаём правило для формата, а SGLang следит, чтобы каждый сгенерированный токен соответствовал этому правилу.

Это называется constrained decoding.

Constrained decoding означает, что модель может выбирать только те токены, которые сохраняют вывод валидным для выбранного нами формата. Если токен сломал бы формат, он просто не разрешается.

Так вывод всегда остаётся валидным. Мы не получаем сломанный JSON. Проблема решена.

Есть и бонус. Поскольку формат уже фиксирует некоторые части вывода, SGLang иногда может заполнить эти фиксированные части очень быстро, вместо того чтобы просить модель генерировать их по одному токену. Это тоже ускоряет структурированный вывод.

Так SGLang даёт нам надёжные, хорошо оформленные ответы — и делает это быстро.

Простая картина от начала до конца

Теперь соберём всю историю в один простой поток.

Шаг 1: мы пишем задачу с помощью frontend language SGLang. Описываем шаги и формат, который хотим получить.

Шаг 2: наш запрос отправляется в runtime SGLang, то есть в движок.

Шаг 3: runtime смотрит на radix tree и проверяет, есть ли общий префикс, например system prompt. Если он уже есть, runtime переиспользует сохранённый KV cache через RadixAttention.

Шаг 4: только новая часть запроса обрабатывается заново, а её сохранённая работа добавляется в дерево.

Шаг 5: запрос присоединяется к batch. Благодаря continuous batching движок остаётся полностью загруженным и обслуживает много пользователей вместе.

Шаг 6: модель генерирует ответ по одному токену. Если мы попросили фиксированный формат, constrained decoding удерживает каждый токен валидным.

Шаг 7: мы получаем быстрый и корректно оформленный ответ.

Вот весь поток:

Мы пишем задачу (frontend language)
|
v
SGLang runtime (движок)
|
v
Проверка radix tree на общий префикс
|
+--------+--------+
|                 |
найден префикс    новая часть
|                 |
v                 v
переиспользовать  обработать заново и
сохранённый KV    добавить в дерево
cache             |
(RadixAttention)  |
+--------+--------+
|
v
Присоединиться к batch
(continuous batching держит движок занятым)
|
v
Генерировать по одному токену
(constrained decoding сохраняет формат валидным)
|
v
Быстрый, хорошо оформленный ответ

Здесь видно, как запрос идёт из frontend-кода в runtime, затем проходит через radix tree, где переиспользуется общая работа, попадает в batch, который держит движок занятым, и наконец выходит как валидный ответ.

Так SGLang работает от начала до конца.

У нас есть подробная статья об оптимизации LLM inference, которая охватывает более широкий ландшафт этих техник.

Более мощные возможности SGLang

Теперь мы увидели полный базовый поток SGLang. Но SGLang — большой и современный инструмент, и он делает гораздо больше, чем только ядро. Посмотрим на другие мощные возможности простыми словами. Многие из них также есть в других современных serving-инструментах, так что они не уникальны для SGLang.

Перед списком нужна одна маленькая идея. Когда модель отвечает, есть две стадии. Сначала она читает весь prompt за один проход. Эта стадия называется prefill. Затем она пишет ответ по одному токену. Эта стадия называется decode. Многие возможности ниже ускоряют именно эти две стадии.

Chunked prefill. Некоторые prompt очень длинные, например большой документ. Читать такой длинный prompt за один раз может блокировать всех остальных. Поэтому SGLang может разбивать длинный prompt на меньшие chunks и читать их по частям, перемешивая эту работу с генерацией ответов. Это делает нагрузку более ровной для всех пользователей.

Speculative decoding. Писать по одному токену медленно. Поэтому SGLang может заранее угадывать несколько токенов с помощью маленькой быстрой вспомогательной модели, а затем проверять эти догадки основной моделью за один шаг. Когда догадки верны, мы получаем много токенов сразу. Это ускоряет появление ответа.

Prefill and decode disaggregation. Стадии prefill и decode требуют разного. Prefill требует много сырой вычислительной мощности. Decode требует много памяти и быстрых обменов туда-сюда. Поэтому SGLang может запускать эти две стадии на отдельных машинах, каждая из которых настроена под свою задачу, а умный router отправляет каждый запрос туда, куда нужно. Это часто называют PD disaggregation, и это помогает SGLang ровно работать на очень большом масштабе.

Разделение модели между многими GPU. Некоторые модели слишком большие, чтобы поместиться на одном GPU. GPU — это мощный чип, который фактически запускает модель. Поэтому SGLang может разделить одну модель между многими GPU, чтобы она поместилась и работала быстро. Для очень больших mixture-of-experts-моделей, где модель состоит из множества меньших экспертных частей, SGLang может даже распределять этих экспертов между многими машинами. Так он обслуживает некоторые из крупнейших моделей в мире.

Quantization. Числа внутри модели занимают много памяти. Quantization сжимает эти числа в более компактную форму, поэтому модель использует меньше памяти и работает быстрее почти без потери качества. SGLang поддерживает много таких компактных форматов.

Обслуживание многих кастомных версий одновременно. Иногда у нас есть много небольших кастомных версий одной базовой модели, каждая из которых обучена под отдельную задачу. SGLang может обслуживать много таких версий вместе в одном batch, вместо того чтобы загружать каждую на отдельную машину. Это экономит много ресурсов.

Понимание изображений и не только. SGLang предназначен не только для текста. Он также может обслуживать модели, которые понимают изображения, и продолжает добавлять поддержку новых типов данных, например видео. Поэтому его называют фреймворком для больших языковых моделей и мультимодальных моделей.

Умный scheduler. Continuous batching, который мы уже видели, держит слоты заполненными. Scheduler решает другой тип ожидания. GPU выполняет тяжёлую работу, а CPU, часть системы, которая планирует работу, решает, что запускать дальше. SGLang делает это планирование, пока GPU всё ещё занят, поэтому GPU почти никогда не приходится ждать следующего шага.

Cache-aware load balancing. Когда SGLang работает на многих машинах, он старается отправлять каждый запрос на ту машину, где уже сохранена его общая работа. Так переиспользование, которое мы изучили на примере RadixAttention, продолжает работать даже между многими машинами.

Так что SGLang — это гораздо больше, чем RadixAttention. Это полноценный современный serving-инструмент с множеством возможностей, которые вместе делают обслуживание больших языковых моделей быстрым, доступным и надёжным.

Если вы хотите глубоко разобраться в Speculative Decoding, Mixture of Experts (MoE), Quantization и Multimodal AI, у нас есть полная программа по этому — посмотрите AI and Machine Learning Program в Outcome School.

Как SGLang сравнивается с vLLM

vLLM — ещё один инструмент для обслуживания больших языковых моделей. Это один из самых популярных инструментов в мире для такой задачи. Поэтому естественно спросить, чем SGLang отличается от него. Посмотрим на честную картину, не отдавая предпочтение ни одному из них.

Сначала самая важная правда. SGLang и vLLM — оба отличные инструменты, и со временем они стали довольно похожими. Оба быстрые. Оба обслуживают много пользователей одновременно. Оба переиспользуют сохранённую работу, то есть KV cache, для общего текста. Оба могут производить структурированный вывод вроде JSON. Оба даже предлагают похожий стиль простого API, поэтому часто можно перейти с одного на другой почти без изменений в коде.

Так что же на самом деле отличается?

Первое отличие — в том, как они переиспользуют общий текст. SGLang сопоставляет общий текст очень точно, по частям, используя radix tree. vLLM сопоставляет общий текст блоками фиксированного размера. Проще говоря, SGLang часто может заметить совместное использование, которое vLLM пропустил бы, особенно в длинных многоходовых чатах, где каждый ход добавляет немного текста. Когда много запросов начинаются с одного и того же фиксированного текста, оба справляются очень хорошо. Такое блочное сопоставление в vLLM называется PagedAttention, и у нас есть подробная статья о PagedAttention, где объясняется, как оно работает.

Второе отличие — охват и зрелость. vLLM существует немного дольше. У него самое большое сообщество и самый долгий production track record, поэтому для общего serving он часто является выбором по умолчанию. SGLang новее, но он очень быстро вырос и уже пользуется доверием на огромном масштабе, обслуживая огромное количество запросов каждый день во многих крупных компаниях. Оба работают на широком диапазоне hardware, то есть на разных типах чипов от разных компаний. Так что оба проверены в реальном мире.

Третье отличие — то, что SGLang добавляет сверху. SGLang даёт frontend language, который мы видели раньше, и он упрощает написание многошаговых задач. У него также очень сильная поддержка structured output с очень небольшим замедлением. И он особенно хорош там, где много запросов разделяют большой объём текста: длинные чаты, агенты или question-answering по документам.

А что насчёт сырой скорости? Честный ответ: это зависит от модели, workload и версии каждого инструмента. Иногда один чуть быстрее, иногда другой. Оба очень быстро улучшаются. Поэтому единого победителя по скорости нет.

Для удобства сведём различия между SGLang и vLLM в таблицу, чтобы было проще решить, что использовать в вашем случае.

| Пункт | vLLM | SGLang | |---|---|---| | Переиспользование общего текста | Блоками фиксированного размера | По частям, с помощью radix tree | | Track record и сообщество | Самые долгие и большие | Новее, но очень быстро растёт | | Лучше всего известен за | Общее быстрое serving и зрелость | Prefix sharing, frontend language и structured output | | Хорош для | Множества очень разных запросов | Multi-turn chat, agents и question-answering по документам |

Так как выбрать? Если нужны самое большое сообщество, самый долгий track record и общее serving с очень разными запросами, vLLM — отличный выбор. Если у вас много общего текста, например multi-turn chat, agents или question-answering по документам, и если нужен сильный structured output, SGLang — отличный выбор. Во многих повседневных случаях оба подойдут хорошо.

Теперь мы поняли, как работает SGLang. Он переиспользует общую работу с помощью RadixAttention, позволяет писать задачи с frontend language, держит машину занятой и даёт надёжный структурированный вывод. Вместе эти идеи позволяют обслуживать большие языковые модели для множества людей быстро и надёжно.

Готовьтесь к собеседованию по AI Engineering: AI Engineering Interview Questions.

На этом всё.

Спасибо.

Amit Shekhar Founder @ Outcome School