SGLang без магии: как устроены основные настройки инференса LLM

Когда LLM помещается на одной GPU и получает несколько запросов в минуту, настройка движка инференса обычно заканчивается на выборе модели и типа данных. Проблемы начинаются дальше: модель перестает помещаться в память, растет очередь запросов, длинные промпты съедают KV-кэш, а GPU простаивают в ожидании обмена данными друг с другом. 

Привет, Хабр! На связи Эрик из команды больших языковых моделей ecom.tech. В этой статье я помогу тем, кто только погружается в мир LLM-инференса, разобраться во всем многообразии настроек одного из самых популярных фреймворков инференса - SGLang.

Разберем пять групп настроек: параллелизм: TP, DP, CP, PP и EP, KV-кэш: Radix Cache и HiCache, вычисления и коммуникации в MoE, attention-бекенд, спекулятивное декодирование. Задача — не перечислить все CLI-флаги SGLang, а понять, что именно в пайплайне инференса меняет каждая настройка и в какой ситуации ее имеет смысл трогать. Поехали! 

Параллелизм: что именно мы делим между GPU

Первая задача при развертывании большой модели — решить, как использовать доступные GPU. Фраза «запустить модель на восьми GPU» сама по себе почти ничего не говорит. Можно разделить между ними веса модели, запросы, контекст, слои или экспертов MoE. Это разные виды параллелизма с разными требованиями к памяти и коммуникациям.

В SGLang основные варианты — Tensor Parallelism, Data Parallelism, Context Parallelism, Pipeline Parallelism и Expert Parallelism.

• Тensor Parallelism

  TP делит вычисления внутри слоев модели между несколькими GPU. Если матрица с весами линейного слоя слишком большая, чтобы эффективно считать ее на одной карте, она шардируется. Каждый GPU считает свою часть результата, после чего результаты объединяются операциями All-Reduce/All-Gather.

  Главная причина использовать TP проста: модель не помещается на одной GPU. Например, при tp=8 один экземпляр модели распределен между восемью GPU. Один запрос при этом тоже проходит через все восемь карт.

  Цена такого подхода — коммуникации. GPU постоянно обмениваются промежуточными результатами, поэтому TP лучше всего работает, когда между видеокартами есть быстрый канал связи. Чем медленнее коммуникация между GPU, тем больше времени уходит на обмен вместо вычислений.

• Data Parallelism

  DP решает другую задачу. Вместо разделения одной модели мы создаем несколько ее реплик и отправляем разные запросы разным репликам.

  Если модель помещается на GPU, четыре карты условно могут обслуживать четыре независимых потока запросов. Между ними при инференсе не нужна синхронизация весов, как при обучении. Поэтому DP в первую очередь масштабирует пропускную способность, а не максимальный размер модели. Из этого получается важное различие:

  TP позволяет большему числу GPU работать над одним экземпляром модели.
  DP позволяет одновременно работать нескольким экземплярам модели.

На практике они естественно комбинируются. Например, если модель требует четыре GPU, а сервер располагает шестнадцатью, можно получить четыре TP-группы по четыре GPU и распределять запросы между ними.

• Context Parallelism

  При длинных последовательностях узкое место может сместиться с весов модели или пропускной способности на контекст. CP разделяет последовательность токенов между GPU. Это позволяет работать с контекстом, который иначе не помещался бы в память одной карты.
  Но attention требует взаимодействия между частями последовательности, поэтому CP тоже создает коммуникационные расходы. Кроме того, поддержка CP в SGLang зависит от конкретной пары модели и бекенда.

• Pipeline Parallelism

  PP режет модель уже не внутри слоя, а по слоям. Условно:

  GPU 0: слои  1–20
  GPU 1: слои 21–40
  GPU 2: слои 41–60
  GPU 3: слои 61–80

  Запрос последовательно проходит через эти стадии. Главное преимущество — данные можно передавать последовательно от одной стадии к следующей, вместо постоянного обмена между GPU, как в TP. Поэтому PP особенно полезен в конфигурациях с большим количеством нод, где связь между серверами заметно медленнее, чем между GPU внутри одного сервера.
  Обратная сторона — часть GPU может простаивать. Пока запрос обрабатывается на первых слоях, GPU с последующими слоями ждут своей очереди. Чем больше одновременных запросов, тем легче загрузить все стадии работой и уменьшить эти простои.

• Expert Parallelism

  EP имеет смысл только для MoE-моделей. В MoE бОльшая часть параметров находится в экспертах, но каждый токен использует только небольшую их часть. Поэтому вместо разделения всех экспертных матриц между GPU можно распределить по GPU самих экспертов.
  Роутер выбирает нужных экспертов, после чего токены отправляются на те GPU, где они находятся. Затем результаты собираются обратно. Из-за этого между GPU приходится передавать много данных. Поэтому эффективность EP сильно зависит от того, как организован этот обмен — к его настройкам вернемся ниже.

Как выбирать?

В первом приближении логика такая:

• не помещается модель на одну GPU → смотрим на TP;

• модель помещается, но не хватает QPS → DP;

• не помещается контекст → CP;

• модель нудно распределить между нескольким нодами → PP;

• используете большую MoE-модель → EP.

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

KV-кэш: почему память заканчивается раньше, чем кажется

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

Упрощенно:

промпт → префилл → KV-кэш
↓
 токен #1
↓
 токен #2
   ↓
токен #3

Чем больше контекст, количество одновременных запросов и число слоев модели, тем больше KV занимает памяти. Поэтому свободная VRAM после загрузки весов — это не просто запас. Значительная ее часть используется под KV-кэш и во многом определяет, сколько токенов система может одновременно держать в обработке.

Radix Cache

SGLang идет дальше обычного KV-кэша и позволяет переиспользовать уже посчитанный KV между запросами.

Представим три промпта:

Ты полезный ассистент. Расскажи про кошек.
Ты полезный ассистент. Расскажи про собак.
Ты полезный ассистент. Расскажи про машины.

Большой системный промпт здесь одинаковый. Без переиспользования кеша модели пришлось бы каждый раз заново обрабатывать этот общий префикс. Radix Cache хранит общие префиксы в radix-дереве. Когда приходит новый запрос, SGLang ищет самое длинное совпадающее начало. Если оно уже есть в кеше, готовый KV используется повторно, а модели остается обработать только новую часть промпта.

Это особенно полезно для нагрузок, где запросы действительно имеют общие начала:

• длинный одинаковый системный промпт;

• несколько примеров прямо в промпте;

• многоходовой диалог;

• агентные сценарии;

• повторные запросы к одному большому документу.

HiCache

Но есть еще одна проблема: даже полезный KV-кеш может перестать помещаться в VRAM. Можно его удалить. Тогда при следующем обращении префикс придется вычислять заново.
HiCache предлагает другой вариант — иерархию хранения:

GPU VRAM
   ↕
CPU RAM
   ↕
SSD / внешнее хранилище

GPU VRAM — самый быстрый, но самый дефицитный уровень. CPU RAM медленнее, зато значительно вместительнее. SSD еще медленнее, но позволяет хранить гораздо больший объем KV-кэша. Получается классическая задача иерархии памяти: горячий KV держим максимально близко к GPU, менее востребованный вместо удаления переносим на уровень ниже.

Поэтому Radix Cache и HiCache решают две связанные, но разные задачи:

1. Radix Cache отвечает на вопрос «Какой KV можно переиспользовать?».

2. HiCache — «Где этот KV хранить, если GPU-памяти недостаточно?».

MoE: отдельно считаем, отдельно передаем

У обычного трансформера каждый токен проходит через одни и те же MLP-блоки. В Mixture-of-Experts вместо одного MLP есть несколько экспертов. Роутер для каждого токена выбирает несколько из них. Схематично:

токен
↓
роутер
↓
Top-K экспертов
↓
вычисления экспертов
↓
взвешенный результат

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

--moe-runner-backend

Runner-бекенд определяет, как GPU выполняет вычисления внутри экспертов.

SGLang поддерживает много вариантов: Triton, DeepGEMM, CUTLASS, FlashInfer, TRT-LLM и другие. Можно выбрать auto и позволить SGLang подобрать подходящий вариант автоматически. Важно не путать runner-бекенд с квантованием.

Например, FP8 определяет, в каком формате хранятся веса, а runner — как GPU выполняет вычисления с этими весами.

Упрощенно:

квантование → что храним
runner → как считаем

Поэтому оптимальный runner зависит от GPU и формата весов.

--moe-a2a-backend

Теперь обмен данными. При Expert Parallelism эксперты находятся на разных GPU. После того как роутер выбрал нужных экспертов, токены нужно отправить на GPU, где эти эксперты находятся. Это называется dispatch — рассылка токенов. После вычислений результаты нужно собрать обратно. Это называется combine — сбор результатов. За этот обмен между GPU и отвечает  --moe-a2a-backend.
SGLang поддерживает большое количество реализаций: DeepEP, FlashInfer, Mooncake, NIXL, pplx и т.д. Их общая задача — как можно быстрее передавать токены между GPU.
Для крупной MoE-модели итоговый путь выглядит примерно так:

router
↓
dispatch
↓
вычисления экспертов
↓
combine

Поэтому для MoE важна не только скорость самих вычислений. Если обмен между GPU медленный, они будут тратить время на ожидание данных.

Перекрываем коммуникации и вычисления

Следующий способ ускорить MoE — выполнять передачу данных и вычисления одновременно. Для этого в SGLang есть механизмы вроде Two-Batch Overlap и Single-Batch Overlap. Пока одни токены передаются между GPU, другие уже могут обрабатываться.

Есть и другая проблема: роутер не всегда распределяет токены между экспертами равномерно. Одни эксперты могут получать больше токенов, чем другие, из-за чего часть GPU оказывается перегружена. EPLB помогает выровнять нагрузку, перераспределяя и при необходимости дублируя наиболее востребованных экспертов.

Attention-бекенд: одна формула, разные ядра

Математически attention остаётся тем же:

Но одну и ту же операцию на GPU можно реализовать по-разному, и от этого сильно зависит скорость. Современные реализации вроде FlashAttention стараются выполнять механизм внимания так, чтобы тратить меньше времени на чтение и запись данных в память GPU. Поэтому выбор attention-бэкенда не меняет саму модель. Меняется только то, как вычисления выполняются на GPU.

Префилл и декодирование — разные нагрузки

Здесь важно разделить две стадии инференса:

• Префилл обрабатывает сразу весь входной промпт. GPU получает большой объём вычислений, которые можно выполнять параллельно.

• Декодирование генерирует новые токены по одному и постоянно обращается к уже созданному KV-кэшу.

Префилл → много вычислений
Декодирование → много работы с памятью

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

MHA/GQA и MLA

Выбор attention-бекенда зависит и от архитектуры самой модели. Например, Llama, Qwen и Gemma обычно используют MHA или GQA. Для них подходят бэкенды вроде FlashAttention и FlashInfer. DeepSeek использует другой механизм — MLA (Multi-head Latent Attention). Он устроен иначе, поэтому для него существуют отдельные оптимизированные реализации. Встречаются и другие варианты attention, например разреженное и линейное внимание.

Поэтому нельзя составить универсальный рейтинг бекендов и использовать его для любой модели. Выбор зависит сразу от нескольких вещей:

архитектура модели
+
архитектура GPU
+
этап инференса (префилл или декодирование)
+
другие включенные оптимизации
↓
attention-бекенд

Поколение GPU тоже имеет значение

H100 и B200 — это не просто две NVIDIA разной скорости.

Они относятся к разным поколениям GPU и по-разному выполняют некоторые операции. Поэтому один и тот же бэкенд может показывать разную производительность на разных GPU.

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

Спекулятивное декодирование: несколько токенов за один дорогой проход целевой модели

При обычной генерации модель создаёт токены последовательно:

промпт→ forward pass→ токен1→ forward pass→ токен2→ forward pass→ токен3→ ...

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

Идея простая: маленькая и быстрая модель заранее предлагает несколько следующих токенов, а основная модель проверяет их за один проход.

маленькая модель
 ↓
предлагает несколько токенов
↓
основная модель
 ↓
проверяет их за один проход
↓
принять / отклонить

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

Предлагать токены можно по-разному

В SGLang есть несколько вариантов спекулятивного декодирования.

EAGLE3 использует дополнительную модель, специально обученную предсказывать следующие токены.

EAGLE / NEXTN — другие способы предсказывать несколько токенов вперёд.

STANDALONE позволяет использовать отдельную небольшую LLM.

NGRAM работает вообще без дополнительной модели — он ищет подходящие продолжения среди уже встречавшихся последовательностей.

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

Три основных параметра

После выбора метода есть три основные настройки:

--speculative-num-steps — на сколько шагов вперёд пытаемся предсказать токены.

--speculative-eagle-topk — сколько вариантов рассматриваем на каждом шаге.

--speculative-num-draft-tokens — сколько предложенных токенов отправляем основной модели на проверку.

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

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

Когда спекуляция особенно полезна

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

Меньше пользы от него при коротких ответах, длинных промптах и большом количестве ошибок в предсказанных токенах.

Есть и ограничения совместимости. Например, некоторые оптимизации работают только при topk=1, а при topk > 1 могут быть недоступны. Поэтому спекулятивное декодирование лучше проверять на реальной нагрузке, а не включать автоматически.

Как все это складывается вместе

Главная ошибка при настройке инференса — рассматривать каждую оптимизацию отдельно.

На практике все настройки связаны между собой:

Модель + GPU
↓
TP / DP / PP / CP / EP
↓
KV-кэш / Radix Cache / HiCache
↓
Attention-бэкенд
↓
MoE-бэкенды
↓
Спекулятивное декодирование

Изменение одной части может повлиять на остальные. Например, TP помогает распределить модель между GPU, но добавляет обмен данными между ними. Чем больше одновременных запросов, тем больше места требуется под KV-кэш. Для разных моделей и GPU могут лучше подходить разные attention-бекенды.

Поэтому универсальной лучшей конфигурации SGLang нет. Она всегда зависит от четырёх вещей:

модель × GPU × нагрузка × требования к скорости

С чего начинать настройку

На практике я бы двигался сверху вниз. Сначала нужно понять нагрузку: насколько длинные промпты и ответы, сколько запросов приходит одновременно и что для нас важнее — быстро начать отвечать или обработать как можно больше запросов.

Затем подобрать параллелизм. Если модель помещается на одну GPU, не стоит включать TP просто потому, что есть свободные карты: обмен данными между ними тоже занимает время.

Следующий шаг — память. Нужно посмотреть, сколько VRAM остаётся под KV-кэш и можно ли переиспользовать общие части промптов через Radix Cache. Если VRAM не хватает, можно рассмотреть HiCache. Для MoE отдельно смотрим на скорость вычислений экспертов и обмен токенами между GPU.

Затем подбираем attention-бэкенд с учётом модели и GPU. Префилл и декодирование при этом лучше проверять отдельно.

И только после получения хорошей базовой конфигурации имеет смысл добавлять спекулятивное декодирование.

Главное правило: менять одну группу настроек за раз и смотреть, что изменилось на реальной нагрузке.

Важно смотреть не только на общий tokens/s, но и на TTFT, ITL, QPS, использование VRAM и количество одновременных запросов, которое выдерживает сервер. В итоге длинный список флагов SGLang сводится к нескольким основным вопросам:

как распределить модель между GPU → как использовать память → как выполнять attention → как считать и передавать данные в MoE → как ускорить генерацию.