tekBlueprint

Запуск больших языковых моделей в продакшене требует большего, чем просто загрузка чекпоинта и вызов forward(). Разрыв между исследовательскими бенчмарками и реальной работой определяется целями по задержке, бюджетами памяти и ограничениями стоимости, которыми исследовательские статьи редко занимаются.

Это часть 1 из 4 цикла “LLM-инференс в продакшене”. Эта обзорная статья посвящена архитектурам моделей и ключевым метрикам, определяющим инференс. В последующих частях будут рассмотрены квантование и KV-кэш, параллелизм и скорость, а также фреймворки и эксплуатацию.

Почему LLM-инференс сложен

LLM-инференс состоит из двух принципиально разных фаз, предъявляющих противоположные требования к оборудованию. Фаза prefill обрабатывает весь промпт за один прямой проход. Она ограничена вычислительной мощностью, определяется матричными умножениями и масштабируется в зависимости от количества токенов во входных данных. Фаза decode генерирует по одному токену за раз. Она ограничена памятью, зависит от скорости считывания весов из HBM (VRAM) и масштабируется пропорционально длине генерации.

Авторегрессивное “узкое место” – фундаментальное ограничение. Каждый сгенерированный токен требует полного прямого прохода через все слои модели. Для модели с 70B параметров считывание всех весов из HBM занимает значительно больше времени, чем сами вычисления на современных GPU. Именно ширина пропускной полосы памяти становится преградой, а не количество FLOP. Вот почему GPU с большим числом FLOP, но той же шириной полосы памяти часто не ускоряет decode по сравнению с предыдущим поколением.

Проблема усугубляется при пакетном инференсе. Несколько последовательностей в одном пакете имеют разную длину и завершают генерацию в разное время. Остаётся либо добавлять выравнивание (тратя вычислительные ресурсы впустую), либо использовать непрерывную пакетизацию (continuous batching) – подход, зародившийся в системе Orca (OSDI 2022), которая ввела планирование на уровне итераций. Он позволяет движку динамически добавлять и удалять запросы из пакета в любой итерации токенов, максимизируя загрузку GPU, но одновременно добавляя сложность в управлении памятью и планировании ядер.

К 2026 году ландшафт аппаратного обеспечения изменился. H100 обеспечивает пропускную способность памяти 2.0 ТБ/с (PCIe) — 3.35 ТБ/с (SXM5), а H200 — 4.8 ТБ/с пиковой полосы. Размеры моделей растут быстрее, чем ёмкость чипов памяти, опережая рост пропускной способности. Кластер 8x H100 80 ГБ вмещает 640 ГБ HBM – чего достаточно для квантованной 70B-модели с KV-кэшем, а для плотной 405B-модели в 4-битном квантовании остаётся лишь ~330 ГБ на KV-кэш и активации. MoE-модели усложняют картину: все эксперты должны помещаться в память, хотя активируется лишь часть из них на каждый токен.

Инференс в продакшене оценивается по четырем метрикам, которые часто конфликтуют друг с другом:

• TTFT – время до первого токена. Задержка от отправки запроса до получения первого сгенерированного байта. TTFT определяется фазой prefill и первым шагом decode.
• ITL (межтокенная задержка) – ранее также называлась TPOT (время на выходной токен). Устойчивая задержка декодирования между последовательными токенами после первого. ITL определяет, насколько быстро генерируются длинные ответы.
• Пропускная способность (Throughput) – общее количество токенов, обрабатываемых в секунду по всем параллельным запросам. Пропускная способность выигрывает от батчинга и операций, ограниченных вычислениями.
• Стоимость на миллион токенов – непосредственно определяется использованием оборудования, размером пакета и эффективностью decode. Более низкий ITL означает меньшую стоимость, но только при условии высокой загрузки GPU.

Эти метрики образуют треугольник противоречий. Оптимизация TTFT обычно означает выполнение prefill на выделенном оборудовании, что снижает пропускную способность. Оптимизация пропускной способности требует максимального размера пакета, что может увеличить ITL, так как ширина полосы памяти GPU разделяется между большим количеством последовательностей. Снижение стоимости за токен требует высокой утилизации, которую трудно поддерживать при переменных паттернах трафика.

Нагрузка на VRAM – это скрытое ограничение, стоящее за всем этим. Веса модели составляют базовую нагрузку. KV-кэш растёт линейно с длиной последовательности и размером пакета. Для пакета из 32 последовательностей при контексте 8K токенов KV-кэш может потреблять столько же памяти, сколько и сами веса модели. Невозможно увеличивать размер пакета для улучшения пропускной способности, не натолкнувшись в итоге на потолок VRAM.

Архитектуры моделей

Выбор между плотными моделями (dense), смесями экспертов (MoE) или мультимодальными моделями – это первое и самое важное решение для инференса в продакшене. Оно определяет размер оборудования, стратегию оптимизации и эксплуатационную сложность.

Плотные модели (Dense Models)

Плотные трансформер-модели активируют каждый вес при каждом прямом проходе. Для входной последовательности токены проходят через стопку слоёв multi-head attention и feed-forward сетей (FNN). Все параметры участвуют в формировании каждого выходного токена. Именно такую архитектуру имеют Llama 3.1, Mistral Large 2, плотные варианты Qwen3 (до 32B) и большинство моделей, работающих в продакшене сегодня.

Главное преимущество плотных моделей — предсказуемость. Требуемые вычисления на токен постоянны и известны заранее: три матричных умножения на слой FFN (проекции gate, up и down через SwiGLU) и четыре в слое внимания (проекции Q, K, V и выходная проекция), всего семь на слой трансформера. Доступ к памяти следует регулярному шаблону: потоковое чтение весов из HBM, вычисления на Tensor Cores, запись результата, повторение. Именно такая регулярность оптимизируется в стеках GPU-компиляторов и стратегиях слияния ядер (kernel fusing).

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

Недостаток — линейное масштабирование. Удвоение количества параметров удваивает объем вычислений на токен и удваивает потребление VRAM. Обойти эту арифметику невозможно. Плотная модель на 70B требует примерно в два раза больше ресурсов, чем модель на 34B. Если вам нужна большая емкость, вы покупаете больше железа.

Плотные модели отлично подходят для развертывания на одном узле. Модель 7B помещается на один потребительский GPU после квантования. Модель 70B помещается на один узел A100 после агрессивного квантования. Вы избегаете целого класса проблем с многоузловым сетевым взаимодействием еще до того, как начнете о них думать.

Vision-Language модели (VLM)

К 2026 году чисто текстовые LLM в продакшене все чаще заменяются на VLM (Vision-Language Models). VLM интегрируют визуальный энкодер (например, Vision Transformer, ViT) с базовой LLM. Визуальный энкодер преобразует изображения в последовательности “токенов патчей изображения”, которые затем проецируются в пространство эмбеддингов LLM и конкатенируются с текстовыми токенами.

При инференсе VLM создают специфическую проблему: патчи изображения резко раздувют длину последовательности prefill. Одно изображение высокого разрешения может легко превратиться в 1000–-4000 токенов. Это усиливает compute-bound природу фазы prefill, вызывает всплеск TTFT и быстро расходует память KV-кэша. При обслуживании VLM агрессивный чанкованный prefill (chunked prefill) и параллелизм контекста становятся обязательными даже при умеренных размерах батча.

Mixture of Experts (MoE)

Модели MoE используют условные вычисления. Каждый токен направляется к подмножеству сетей “экспертов”, и только эти эксперты обрабатывают токен. Классическая реализация разделяет слой FFN на N параллельных экспертов и маршрутизатор, который выбирает top-k экспертов для каждого токена. Для модели с 16 экспертами и маршрутизацией top-2 каждый токен активирует только 1/8 параметров FFN.

Ключевая идея MoE — разделение двух величин: емкости модели (общего числа параметров) и вычислений на токен (активных параметров). Mixtral 8x7B имеет 46.7B общих параметров, но активными на токен являются только 12.9B. Это означает, что модель достигает производительности, сопоставимой с плотной моделью на 30B, используя вычисления, эквивалентные плотной модели на 13B за один прямой проход. Компромисс в том, что все 46.7B параметров должны храниться в памяти.

Реальные архитектуры MoE значительно различаются. DeepSeek V3 использует 256 экспертов с маршрутизацией top-8 и одним общим экспертом на токен (671B total, 37B active). DeepSeek V4 сохраняет 256 экспертов, но заменяет функцию Sigmoid на Sqrt(Softplus), убирает фиксированное ограничение top-K и активирует в среднем ~16 экспертов (V4-Pro: 1.6T total / 49B active; V4-Flash: 284B / 13B active). Mixtral 8x7B использует 8 экспертов с маршрутизацией top-2. Qwen3 MoE масштабируется до 235B total / 22B active на 128 экспертах без общего эксперта. Gemma 4 представила MoE-вариант 26B с 4B active, в то время как Gemma 3 остаётся чисто плотной моделью (1B–27B).

Преимущества MoE для инференса весьма конкретны. Пропускная способность на ватт улучшается, поскольку каждый токен требует меньше FLOP. Если вы ограничены вычислениями, модель MoE превосходит плотную модель аналогичного качества. Что более важно, MoE обеспечивают качество рассуждений на уровне плотных моделей при доле от стоимости вычислений на токен. Для API-провайдеров, обрабатывающих миллионы токенов, это напрямую транслируется в снижение затрат на оборудование.

Недостатков больше. Сбои маршрутизации происходят, когда маршрутизатор отправляет все токены в батче одному и тому же эксперту. Это создает “горячую точку”, которая сериализует вычисления и снижает пропускную способность. Дисбаланс экспертов — когда некоторые эксперты постоянно предпочитаются — оставляет неиспользуемую емкость простаивающей в VRAM. Обе проблемы усугубляются при малых размерах батча и коротких последовательностях, предоставляющих недостаточно контекста для маршрутизатора.

Накладные расходы на коммуникацию — скрытая стоимость MoE. При развертывании на одном узле маршрутизация токенов между экспертами на одном GPU требует перемещения данных внутри HBM. При многоузловом развертывании токены может потребоваться отправлять через NVLink или PCIe для достижения назначенных им экспертов. Шаблон связи “все-ко-всем” (all-to-all) для маршрутизации экспертов добавляет задержку, которая масштабируется с размером батча и количеством экспертов.

Существует жесткое ограничение VRAM. Все эксперты должны одновременно поместиться в памяти, даже если активна лишь их часть. Модель MoE с 8 экспертами по 7B параметров требует память для всех 56B параметров, а не только для 14B, активируемых за один токен. Это означает, что модель MoE может потреблять в 3-4 раза больше VRAM, чем плотная модель с эквивалентным количеством активных параметров.

Маршрутизация MoE в деталях

Маршрутизатор — это небольшой линейный слой, который вычисляет логиты для набора экспертов для каждого токена. При маршрутизации top-k маршрутизатор выбирает k экспертов с наивысшими оценками логитов и назначает веса, пропорциональные softmax этих логитов. Выход FFN для токена представляет собой взвешенную сумму выходов выбранных экспертов.

Маршрутизация top-2 назначает каждый токен 2 экспертам. Это баланс между охватом и вычислениями. При top-1 единственная ошибка маршрутизатора отправляет токен не тому эксперту без возможности восстановления. При top-4 вычисления почти удваиваются при уменьшающейся отдаче в качестве. Top-2 — самый распространенный выбор в продакшене.

Веса маршрутизатора определяют всё. Хорошо обученный маршрутизатор распределяет токены равномерно по экспертам, максимизируя параллелизм. Плохо обученный маршрутизатор концентрирует трафик, создавая узкие места. Обучение маршрутизатора использует вспомогательную функцию потерь балансировки нагрузки (auxiliary load-balancing loss), которая штрафует за неравномерное использование экспертов. Эта функция потерь вычисляется как скалярное произведение между частотой токенов и вероятностями маршрутизации экспертов:

L_aux = alpha * N * sum(f_i * P_i)

Где f_i — доля токенов, направленных эксперту i, P_i — средняя вероятность softmax, присвоенная маршрутизатором эксперту i в рамках батча (в идеале P_i ~ 1/N), N — общее количество экспертов, а alpha — масштабирующий коэффициент. Эта функция потерь минимизируется, когда распределение токенов совпадает с равномерным, подталкивая маршрутизатор к сбалансированной утилизации экспертов.

Сбои маршрутизации проявляются тремя способами. Переполнение емкости (Capacity overflow) возникает, когда к эксперту направляется больше токенов, чем позволяет его емкость. Стандартная обработка либо отбрасывает токены переполнения, либо перераспределяет их, что в обоих случаях ухудшает качество. Коллизия экспертов (Expert collision) происходит, когда все токены в батче выбирают пересекающиеся наборы экспертов, снижая эффективный параллелизм. Мертвые эксперты (Dead experts) — это эксперты, которые не получают ни одного токена на протяжении сотен прямых проходов, впустую тратя выделенную им память.

Маршрутизация Expert Choice (Выбор эксперта) появилась как элегантная альтернатива, полностью устраняющая эти режимы сбоев. Вместо того чтобы токены выбирали своих top-k экспертов, каждый эксперт выбирает свои top-N токенов из батча. Эта инверсия гарантирует идеальную балансировку нагрузки — каждый эксперт получает ровно N токенов, без переполнения, коллизий и мертвых экспертов. Вспомогательная функция потерь балансировки становится ненужной. Изначально представленная исследователями Google, Expert Choice (наряду с похожими механизмами, такими как балансировка без вспомогательных потерь, используемая в DeepSeek-V2 и V3) с тех пор стала стандартом для новых архитектур MoE, хотя для реализации ее теоретических преимуществ в продакшене требуются специализированные реализации ядер.

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

Сравнение Dense vs MoE

Когда выбирать Dense, а когда MoE

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

Выбирайте модель MoE, когда основными драйверами являются пропускная способность и экономическая эффективность. Если вы обрабатываете миллионы токенов в день для API или внутреннего сервиса, экономия на вычислениях быстро накапливается. Модели MoE эффективнее обрабатывают большие контекстные окна на один токен. Они также лучше масштабируются в много-GPU кластерах, где параллелизм экспертов естественным образом распределяется по устройствам.

Практическое правило: если ваш пиковый размер батча остается ниже 16, плотные модели обычно работают лучше. При размерах батча выше 32 MoE начинает показывать преимущества в пропускной способности. Точка пересечения зависит от количества экспертов, стратегии маршрутизации и топологии оборудования.

Глоссарий

Источники

1. Core Transformer Architecture
   1. Attention Is All You Need (The Transformer architecture). arXiv:1706.03762
2. Mixture of Experts and Routing
   1. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer (Original MoE formulation). arXiv:1701.06538
   2. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. arXiv:2101.03961
   3. Mixture-of-Experts with Expert Choice Routing. arXiv:2202.09368
   4. Mixtral of Experts (MoE architecture in practice). arXiv:2401.04088
   5. DeepSeek-V3 Technical Report (MoE with auxiliary-loss-free balancing, 256 experts, top-8 routing). arXiv:2412.19437
   6. DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence (V4 preview, Sqrt(Softplus) gating, 1M context). arXiv:2606.19348
3. Inference Serving and Continuous Batching
   1. Orca: A Distributed Serving System for Transformer-Based Generative Models (Iteration-Level / Continuous Batching). USENIX OSDI 2022
4. Model Fine-Tuning
   1. LoRA: Low-Rank Adaptation of Large Language Models (Low-Rank Adaptation). arXiv:2106.09685
   2. QLoRA: Efficient Finetuning of Quantized LLMs. arXiv:2305.14314
5. Models and Architecture References
   1. Introducing Llama 3.1 (8B, 70B, 405B dense models). Meta AI Blog
   2. Mixtral 8x7B Model Card (46.7B total, 12.9B active, top-2 MoE). Mistral Docs
   3. Mistral Large 3 (675B total, 41B active, granular MoE). Mistral Docs
   4. Qwen3 Technical Report. arXiv:2505.09388
   5. Gemma 3 Technical Report (only dense, 1B–27B, multimodal). arXiv:2503.19786
   6. Gemma 4 Technical Report (dense and MoE architectures). arXiv:2607.02770
6. Hardware
   1. NVIDIA Hopper Architecture In-Depth (H100, FP8 Tensor Cores, 3.35 TB/s HBM3). NVIDIA Resources
   2. NVIDIA H200 Tensor Core GPU Datasheet (141 GB HBM3e, 4.8 TB/s). NVIDIA SC23 Datasheet

Далее: Часть 2 – квантование и KV-кэш раскрывает снижение потребностей модели в памяти и влияния на кэш.