Глава 10 — Слой движка LLM

Десятый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, называющая границу между движком и платформой и обходящая пять движков, доминирующих на этом слое в 2026 году.

Зачем эта глава существует

Главы 1–9 обошли машинерию, которую трогает один прямой проход: авторегрессионный цикл, KV-кэш, GPU-подложку, квантизацию, ужимающую её, батчинг, скрывающий её простой, и спекулятивный декодинг, ломающий её последовательную зависимость. Ничего из этого не поставляется как библиотека, которую pip install и забыл. Кто-то соединяет это в среде исполнения одного узла, оборачивающей модель, владеющей KV-кэшем, планирующей запросы на непрерывный батч и выставляющей API инференса. Эта среда — движок. Глава 10 называет задачу слоя движка, отличает её от задачи платформы (глава 11) и обходит пять движков — vLLM, TensorRT-LLM, SGLang, TGI, Ollama, — делающих разные механические компромиссы на одной и той же задаче.

10.1 vLLM — Python-нативный дефолт

vLLM — движок, за которым большинству продакшен-команд стоит потянуться первым, потому что он делает верное дефолтное решение по каждой оси, о которой новичок не знал бы, как думать, и делает это на Python. PagedAttention даёт ему падение фрагментации с 60–80 процентов до однозначных чисел, что примерно удваивает достижимый размер батча на том же GPU. Continuous batching ложится сверху естественно, с chunked prefill, смешивающим prefill и decode-работу в одной итерации, так что граница между ними — не мёртвое время. Copy-on-write разделение префиксов бесплатно из дизайна таблицы блоков. Интерфейс — действительно offline-batch или OpenAI-совместимый HTTP в несколько строк, и каждая новая архитектура модели быстро приземляется, потому что сообщество широкое. Это движок для стандартизации, когда у оператора нет специальной причины выбрать что-то ещё.

10.2 TensorRT-LLM покупает пропускную конвейером сборки

Пич TensorRT-LLM узкий. Если флот эксклюзивно NVIDIA, если каждый процент пропускной на доллар важен, и если команда заплатит инженерный налог за компиляцию модель-специфичных engine-файлов на поколение железа, TRT-LLM извлекает 15–35 процентов больше пропускной, чем vLLM, на том же железе. Механизм — на уровне ядер: понизить граф трансформера в NVIDIA-специфичный IR, слить соседние ядра (layernorm + matmul + активация в один запуск), выбрать per-shape оптимальные ядра из предварительно тюненной библиотеки, произвести сериализованный engine и запустить его под Triton Inference Server. Слияние важно, потому что оверхед запуска ядра — 5–10 мкс каждое, а наивный прямой проход 70B диспетчит тысячи их на токен. Налог — сам конвейер сборки — per-model, per-GPU, per-batch-regime шаг компиляции, операционную стоимость которого большинство команд недооценивает. SGLang — другая специализация: RadixAttention хранит KV-кэш для каждого префикса промпта, который движок когда-либо видел, в радикс-дереве, поэтому два запроса, делящие k-токенный префикс, делят KV ровно для этих k токенов между батчами и во времени. На агентных нагрузках с длинными общими системными промптами и короткими вариантами-суффиксами SGLang даёт 2–6× пропускной над vLLM, и его DSL структурированных выходов проверяет JSON-схемы на уровне logit, так что вывод гарантированно валидируется.

10.3 Дерево решений идёт через форму нагрузки, а не через заголовки пропускной

Пять движков раскладываются по маленькому дереву решений. Ноутбук разработчика или edge со смешанными акселераторами → Ollama. Продакшен-флот GPU, эксклюзивно NVIDIA, высокий QPS, ROI пропускной оправдывает конвейер сборки → TensorRT-LLM. Смешанное железо или частые смены модели, нагрузка доминирована префикс-тяжёлыми структурированными паттернами (агенты, tool-вызовы, длинные общие промпты) → SGLang. Смешанное железо, общая чат-нагрузка, глубокая интеграция с Hugging Face → TGI. Всё остальное → vLLM. Решение не окончательное: движки взаимозаменяемы на границе API — они все говорят OpenAI-стиль HTTP — так что маршрутизатор на слое платформы может сдвигать трафик per-модель, per-нагрузка или per-регион без изменения клиентского кода. Многие продакшен-стеки запускают два-три движка бок о бок. Осторожно с заголовочным бенчмарком: «токенов в секунду на Llama-2-7B при батче 1» отвечает на вопрос, который ни одна продакшен-нагрузка не задаёт. Бенчмарк на своей модели, своём распределении промптов, своём профиле параллельности; полдня — сэкономит месяцы.

Что подготавливает глава 10

Каждый движок, описанный в этой главе, останавливается на одной и той же границе. Он знает про ядра, KV-блоки и continuous batching; он не знает про реплики, тенантов, цепочки или аутентификацию. Глава 11 обходит слой платформы, обрабатывающий эти заботы — Ray Serve, KServe, BentoML, Triton Inference Server — и показывает, что выбор гораздо меньше про фичи, чем про то, какая операционная модель совпадает с существующей инфраструктурой и компетенциями команды.

Дальше — Глава 11: Слой платформы и оркестрации. Ray Serve, KServe, BentoML, Triton — четыре платформы, сидящие над движком, выбираемые по совместимости с ops-культурой.