tekBlueprint

В Части 3 рассматривались методы параллелизма и ускорения. Это заключительная часть (4 из 4) серии о Production LLM Inference. Она посвящена фреймворкам для инференса, процессам эксплуатации в продакшене и практическому фреймворку для выбора подходящего стека технологий.

Часть 1: Архитектура и метрики → Часть 2: Квантизация и KV Cache → Часть 3: Параллелизм и скорость ← Часть 4: Фреймворки и эксплуатация

Фреймворки для инференса

vLLM

vLLM — это движок для инференса LLM общего назначения, построенный вокруг PagedAttention — техники, которая рассматривает KV-кэш как виртуальную память с несмежным физическим выделением, устраняя фрагментацию без необходимости ручного управления кэшем. Благодаря реализации непрерывного батчинга (continuous batching) движок может чередовать фазы prefill и decode между запросами, обеспечивая постоянную загрузку GPU на каждой итерации. Автоматическое кэширование префиксов (Automatic Prefix Caching, APC) встроено в планировщик: vLLM отслеживает общие префиксы между запросами с помощью хеширования блоков и переиспользует ранее вычисленные блоки KV-кэша, когда новый запрос пересекается с закэшированным контентом.

Фреймворк «из коробки» поддерживает несколько форматов квантизации, включая AWQ, GPTQ, INT8 (только веса), FP8 со смешанной точностью KV-кэша и GGUF для оффлоада на CPU. Эти форматы загружаются напрямую из файлов чекпойнтов без необходимости отдельного пайплайна квантизации, что упрощает развертывание задач, ограниченных по памяти. Тензорный и конвейерный параллелизмы реализованы с помощью бэкенда NCCL от NVIDIA, а vLLM обеспечивает нативную поддержку моделей Mixture-of-Experts (MoE) с экспертным параллелизмом для крупных MoE-топологий.

Предсказание нескольких токенов (Multi-Token Prediction, MTP) поддерживается для моделей, которые предоставляют черновые токены (draft tokens) нативно (например, Gemma 4 со своими draft heads), а также для спекулятивного декодирования на уровне признаков в стилях Medusa и EAGLE. Движок vLLM маршрутизирует черновые токены через ту же инфраструктуру PagedAttention, поэтому для инференса MTP не требуется отдельная структура кэша.

Сервер предоставляет API, совместимый с OpenAI, включая стриминг, chat completions и logprobs на уровне токенов, со встроенной наблюдаемостью (observability), которая отображает метрики для каждого запроса, такие как time-to-first-token, inter-token latency и коэффициент попаданий в кэш. Последние версии поддерживают дезагрегированный инференс (disaggregated serving), при котором фазы prefill и decode могут быть назначены отдельным пулам GPU для оптимальной утилизации. Это делает vLLM удачным выбором по умолчанию для инференса общего назначения, исследовательских экспериментов и смешанных нагрузок, объединяющих разные размеры моделей и паттерны запросов в одном кластере. Его основные ограничения неочевидны: поскольку vLLM аппаратно независим, он не использует NVIDIA-специфичные слияния ядер (kernel fusions) в той же степени, что TensorRT-LLM, что может привести к тому, что на премиальном оборудовании GPU не будет достигнут прирост пропускной способности на несколько процентов.

TensorRT-LLM

TensorRT-LLM — это официальный стек инференса LLM от NVIDIA, построенный на базе компилятора TensorRT со специально написанными CUDA-ядрами для механизма внимания, layernorm и слияния функций активации, что устраняет необходимость межслойного обмена данными через память. Процесс сборки компилирует конфигурацию модели в файл движка, в который закладываются уровни квантизации, стратегия параллелизма и выбор ядер, создавая высокооптимизированные бинарники под конкретное аппаратное обеспечение. Стриминг весов (weight streaming) и слияние слоев снижают объем памяти под активации во время decode, позволяя TensorRT-LLM приблизить пропускную способность к теоретическому пределу пропускной способности памяти GPU A100, H100 и B200.

Квантизация — сильнейшее конкурентное преимущество фреймворка. Точность FP8 поддерживается нативно с аппаратно-точными масштабными коэффициентами как для весов, так и для KV-кэша, а INT8 и INT4 доступны через пайплайны Quantization-Aware Training (QAT), минимизирующие деградацию точности. Процесс QAT использует Custom Allreduce от NVIDIA и поканальное масштабирование (per-channel scaling), чтобы удерживать ошибку квантизации в допустимых пределах для языкового моделирования. Исследовательские подходы, такие как QuaRot (поворот скрытых состояний для 4-битного инференса без выбросов) и QoQ (W4A8KV4) из QServe, демонстрируют полный потенциал утилизации Tensor Core при ультранизкой точности, хотя они и не интегрированы в стек TRT-LLM. Для продакшен-развертываний, где важна абсолютная пропускная способность, TensorRT-LLM стабильно показывает результаты на пределе или около него для оборудования NVIDIA.

Фреймворк поддерживает широкие возможности параллелизма: тензорный параллелизм (обычно до 8 способов в рамках одного узла, масштабируется далее через многоузловые конфигурации), конвейерный параллелизм с буферизацией между этапами, контекстный параллелизм для нагрузок с длинными последовательностями и авто-параллелизм, который выбирает оптимальную стратегию разделения на основе размера модели и доступных GPU. Модели Mixture-of-Experts выигрывают от экспертного параллелизма и оптимизаций межузлового взаимодействия, встроенных в рантайм TensorRT-LLM. Фреймворк масштабируется от развертываний на одном GPU до многоузловых кластеров с десятками GPU, включая конфигурации с дезагрегированным инференсом.

Компромисс заключается в возросшей операционной сложности. Для сборки движка TensorRT-LLM требуется доступ к GPU во время компиляции, рабочий CUDA toolkit и тщательная настройка конфигураций плагинов. Кривая обучения более крутая, чем у vLLM, а фреймворк работает исключительно на оборудовании NVIDIA без поддержки бэкендов AMD, Intel или CPU. Организации, сделавшие ставку на инфраструктуру NVIDIA и готовые инвестировать в сборочные пайплайны, находят, что прирост пропускной способности TensorRT-LLM окупает эти накладные расходы.

SGLang

SGLang выделяется благодаря RadixAttention — системе кэширования префиксов, структурированной в виде префиксного дерева (trie), а не в виде последовательности блоков. В отличие от поблочного сопоставления префиксов в vLLM, RadixAttention индексирует отдельные токены в дереве, обеспечивая более гранулярное переиспользование, когда запросы имеют частично совпадающие префиксы в разных позициях. Для API-нагрузок, где системные промпты переиспользуются в сотнях пользовательских запросов, RadixAttention может сэкономить значительную долю вычислений на этапе prefill за счет переиспользования узлов кэша для общих путей префиксов.

Структурированная генерация встроена во фреймворк на уровне сэмплирования. SGLang поддерживает ограничения JSON-схем, регулярные выражения и ограничения формальных грамматик без пост-генерационной фильтрации, поскольку ограниченное декодирование (constrained decoding) интегрировано непосредственно в шаг сэмплирования через маскирование словаря на основе грамматик. Это устраняет цикл «сгенерировать-проверить-повторить», делая SGLang практичным инструментом для последующих систем, требующих детерминированных форматов вывода.

Базовые ядра механизма внимания предоставляются FlashInfer, который предлагает оптимизированные реализации механизма внимания как для фазы prefill, так и для фазы decode с поддержкой переменной длины последовательностей. API, совместимый с OpenAI, позволяет легко внедрить SGLang в существующие сервисные архитектуры, а фреймворк обрабатывает параллельные запросы с помощью непрерывного батчинга, аналогично vLLM. SGLang также включает надежную поддержку спекулятивного декодирования и предсказания нескольких токенов (MTP) благодаря интеграции с инфраструктурой draft-моделей FlashInfer, включая генерацию черновых токенов в стилях Medusa и EAGLE.

Поддержка квантизации была значительно расширена в последних версиях: SGLang теперь поддерживает форматы AWQ, GPTQ, FP8 (включая FP8 KV-кэш) и GGUF, что делает его конкурентоспособным с vLLM для развертываний, ограниченных по памяти. Проект продолжает быстро развиваться, добавляя новые оптимизации для нагрузок с длинным контекстом и мультимодальных моделей.

llama.cpp

llama.cpp использует подход, в первую очередь ориентированный на CPU, который не требует GPU, CUDA toolkit или проприетарного рантайма. Проект реализует полный стек механизма внимания, layernorm и MLP на C++, оптимизированный под наборы SIMD-инструкций, с путями выполнения AVX2 и AVX512, эффективно работающими на процессорах потребительского класса. Оффлоад на GPU доступен через бэкенды Vulkan, Metal (macOS) и CUDA, но архитектурная цель — заставить LLM-инференс работать на оборудовании, которое не может позволить себе выделенный ускоритель.

Формат файлов GGUF разработан специально для хранения квантованных моделей, с типами квантизации для каждого слоя, смешивающими точность между группами весов. Поддерживаемые форматы варьируются от Q4_K_M, который сжимает 4-битные веса с 16-битным масштабом на группу и 8-битными каналами для выбросов (outliers), до Q8_0 и полностью деквантованных вариантов FP16. Стратегия K-mixed квантизации удерживает веса механизма внимания и выходные веса в более высокой точности, одновременно агрессивнее сжимая промежуточные веса MLP, обменивая небольшую долю точности на значительную экономию памяти.

Бинарник llama-server «из коробки» предоставляет полноценный API, совместимый с OpenAI, включая эндпоинты /v1/chat/completions и /v1/completions с поддержкой стриминга. Это делает llama.cpp подходящим не только для локальных экспериментов, но и для легковесных продакшен-развертываний на edge-устройствах или серверах только с CPU. Пропускная способность на CPU ниже, чем у фреймворков с ускорением на GPU, и обычно измеряется несколькими токенами в секунду, а не в десятках или сотнях. Непрерывный батчинг поддерживается, хотя он менее оптимизирован, чем в фреймворках с ускорением на GPU, и здесь нет нативного пайплайна квантизации: GGUF-файлы должны создаваться внешними утилитами конвертации, предоставляемыми проектом. Для edge-развертываний, тестирования на потребительском железе и сред с GPU не от NVIDIA, где другие фреймворки не имеют поддержки, llama.cpp остается самым доступным вариантом.

TGI (Text Generation Inference)

TGI — это продакшен-сервер инференса от Hugging Face, созданный с использованием кастомных ядер на Rust и CUDA, оптимизированных для высокопроизводительного инференса. Фреймворк был одним из первых, кто внедрил концепции PagedAttention, и продолжает развивать свои стратегии управления памятью. Поддерживаются тензорный параллелизм, а также спекулятивное декодирование с отдельными draft-моделями, а сервер предоставляет опциональное встраивание водяных знаков (watermarking) для атрибуции генерируемого текста. TGI напрямую интегрируется с Hugging Face Hub, позволяя использовать рабочие процессы pull-and-run, которые легко вписываются в контейнеризированные пайплайны развертывания.

Фреймворк сфокусирован на NVIDIA, с ядрами CUDA и коллективными операциями NCCL, оптимизированными под оборудование A100 и H100. Набор функций TGI во многом пересекается с vLLM, включая батчинг, тензорный параллелизм и ограниченное декодирование, и, судя по недавним бенчмаркам, vLLM превосходит TGI по чистой пропускной способности для моделей нескольких размеров. Примечание: репозиторий TGI был заархивирован Hugging Face в марте 2026 года и сейчас находится в режиме поддержки. HF рекомендует vLLM, SGLang, llama.cpp или MLX для новых развертываний. TGI остается удачным вариантом для команд, уже встроенных в экосистему Hugging Face, но его динамика снизилась, поскольку vLLM перенял многие его дизайнерские решения, обеспечив более широкую поддержку оборудования и более активное развитие сообществом.

Таблица сравнения фреймворков

Ориентировочные показатели 2026 года на одном H100 для модели на 70B параметров. “Высокая” и “Низкая” — относительные рейтинги внутри столбца; точные числа зависят от размера батча, длины последовательности и точности.

Продакшн-эксплуатация

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

Наблюдаемость и метрики

Стандартных метрик веб-серверов, таких как загрузка CPU и сетевой I/O, недостаточно для LLM. Продакшен-наблюдаемость требует отслеживания четырех метрик инференса (TTFT, ITL, Пропускная способность, Стоимость) на уровне каждого запроса. Современные фреймворки для инференса предоставляют нативные эндпоинты Prometheus (/metrics), которые экспортируют глубину очереди, размеры активных батчей, утилизацию блоков KV-кэша и скорости генерации токенов.

Для распределенной трассировки такие инструменты, как OpenLLMetry или LangSmith, интегрируются с OpenTelemetry для отслеживания запроса по мере его прохождения через API-шлюз, токенизатор, фазу prefill и цикл decode. Это критически важно для диагностики аномалий задержки: всплеск TTFT может быть вызван временем ожидания в очереди, в то время как всплеск ITL может быть следствием периодических помех от чанкованного prefill (chunked prefill) или своппинга памяти.

Автомасштабирование и холодный старт

Автомасштабирование нагрузок LLM печально известно своей сложностью из-за проблемы холодного старта. Загрузка модели 70B (даже квантованной до 35 ГБ) с диска в VRAM занимает минуты. Если автомасштабатор ждет превышения порога утилизации CPU/GPU перед запуском новых подов, входящий трафик отвалится по таймауту задолго до того, как новые мощности будут готовы.

Продакшен-развертывания должны использовать предиктивное автомасштабирование или автомасштабирование на основе очередей. Вместо реакции на загрузку CPU, Kubernetes Event-Driven Autoscaling (KEDA) или кастомные контроллеры мониторят метрику vllm:num_requests_waiting. При увеличении глубины очереди запускаются новые поды. Для смягчения холодного старта команды поддерживают «теплые пулы» (warm pools) простаивающих подов с весами, предварительно загруженными в оперативную память (RAM), что позволяет перенести их в VRAM за секунды, а не за минуты.

Отказоустойчивость

В распределенном инференсе LLM аппаратные сбои — статистическая неизбежность. В развертывании с TP=8 на 100 узлах сбой одного GPU или таймаут NCCL приводит к падению всей реплики модели.

Для моделей, реплицированных с помощью тензорного параллелизма (TP), плавная деградация редко возможна; если падает один GPU, падает вся TP-группа. Отказоустойчивость обычно обеспечивается на уровне маршрутизации: балансировщик нагрузки обнаруживает падение health-эндпоинта отказавшей реплики, перенаправляет трафик на здоровые реплики и сигнализирует оркестратору о необходимости замены пода. При дезагрегированном инференсе, если узел prefill падает прямо во время вычислений, маршрутизатор должен обнаружить разрыв соединения и повторить запрос на другом узле prefill, гарантируя отсутствие ошибок на стороне пользователя.

Фреймворк для принятия решений

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

Edge / Потребительское железо

Для развертывания на машинах без GPU используйте плотную (dense) модель 7-13B с квантизацией GGUF Q4_K_M, запускаемую через llama.cpp. Формат со смешанной точностью удерживает потребление памяти в пределах 6 ГБ для модели 7B, а путь выполнения CPU SIMD обеспечивает интерактивную пропускную способность на современных процессорах с минимум 16 потоками. Здесь нет зависимостей при настройке кроме бинарника, нет пайплайна квантизации и нет CUDA toolkit. API, совместимый с OpenAI, позволяет интегрироваться с существующими инструментами. Учтите, что пропускная способность будет измеряться несколькими токенами в секунду, и избегайте нагрузок, требующих time-to-first-token менее секунды.

Небольшой кластер (2-4 GPU) — Низкая задержка

При работе на 2-4 GPU с приоритетом на низкую задержку разверните плотную модель 13-70B, квантованную до FP8 (на оборудовании Hopper) или INT8 через AWQ (на старом оборудовании), и запускайте её через vLLM с тензорным параллелизмом на всех доступных GPU. FP8 или INT8 снижают использование VRAM примерно вдвое по сравнению с FP16, сохраняя 95-99% точности на стандартных бенчмарках. Непрерывный батчинг и Chunked Prefill в vLLM удерживают TTFT на низком уровне при умеренной конкуренции, а совместимый с OpenAI API минимизирует усилия по интеграции.

Небольшой кластер — Чат с общими промптами

Для чат- или агентных нагрузок, где системные промпты являются общими для тысяч запросов, используйте SGLang, чтобы задействовать префиксный кэш на базе дерева (trie) из RadixAttention. Древовидная структура переиспользует узлы кэша для общих путей префиксов более гранулярно, чем поблочное кэширование, снижая вычисления на prefill для повторяющихся системных сообщений. Сочетайте это со встроенной в SGLang структурированной генерацией для применения JSON-схем к ответам API без пост-обработки. Расширенная поддержка квантизации (AWQ, GPTQ, FP8) делает эту конфигурацию жизнеспособной даже для развертываний, ограниченных по памяти.

Большой кластер (8+ GPU) — Максимальная пропускная способность

Для высоконагруженного продакшена на 8+ GPU от NVIDIA объедините MoE-модель с архитектурой MLA, квантованием FP8 для весов и KV-кэша (или INT4 QAT, если FP8 недоступен) и запускайте через TensorRT-LLM с использованием 3D-параллелизма (тензорный, конвейерный и экспертный). Формат FP8 удерживает точность в допустимых пределах, снижая потребление памяти вдвое по сравнению с FP16, и легко масштабируется в многоузловых развертываниях. Слитые ядра (fused kernels) и скомпилированные графы движка TensorRT-LLM обеспечивают самую высокую измеренную пропускную способность на оборудовании H100, а экспертный параллелизм распределяет MoE-роутинг между узлами без чрезмерных накладных расходов на межузловую связь.

Большой кластер — Ускорение с MTP

Если нагрузка генерирует длинные ответы с низкой энтропией (код, документация, структурированные данные) и выбранная модель поддерживает предсказание нескольких токенов, разверните модель с нативными MTP-головами (например, Gemma 4 31B) через vLLM. MTP дает ускорение декодирования в 2-3 раза для небольших размеров батча (BS=1-4), поскольку draft heads авторегрессионно предсказывают несколько токенов за один прямой проход (forward pass), снижая количество итераций полной модели. Инфраструктура PagedAttention в vLLM прозрачно обрабатывает расширенные требования к кэшу. Эта конфигурация оптимальна, когда ограничивающим фактором является скорость декодирования индивидуальных запросов, а не совокупная пропускная способность. Для высокопроизводительных нагрузок с большими батчами отключайте MTP, чтобы избежать конкуренции за вычислительные ресурсы.

Инференс с ограниченным бюджетом

Когда бюджет на GPU ограничен, уменьшите размер модели до 7-13B и примените квантизацию INT4 AWQ через vLLM, дополнив ее спекулятивным декодированием с использованием меньшей модели-черновика (drafter). AWQ INT4 может снизить потребление VRAM примерно до четверти от FP16 с типичной потерей точности в 1-3% на стандартных бенчмарках. Меньшая модель-черновик (обычно 1-3B) генерирует токены, которые проверяются базовой моделью, увеличивая скорость декодирования ценой дополнительного расхода VRAM под drafter. Этот стек максимизирует отдачу от затрат на GPU, особенно для чувствительных к задержке нагрузок с небольшими батчами.

Мультимодельный / Мультитенантный инференс

Для сред, которые должны обслуживать несколько моделей или изолировать тенантов в одном кластере, запускайте vLLM с непрерывным батчингом и тензорным параллелизмом для каждой модели. vLLM поддерживает запуск нескольких моделей в одном процессе, где планировщик чередует запросы по моделям, а динамический батчинг группирует запросы по точности для максимизации утилизации GPU. Маршрутизация, совместимая с OpenAI, и наблюдаемость на уровне запросов делают реализацию изоляции тенантов на уровне API простой задачей.

Дезагрегированный кластерный инференс

Для очень крупных развертываний (100+ GPU) со смешанными нагрузками из запросов с длинным и коротким контекстом реализуйте дезагрегированный инференс с отдельными пулами для prefill и decode. Назначьте GPU с высокой пропускной способностью памяти (H100/H200) пулу decode, а оптимизированные под вычисления GPU — пулу prefill. Соедините их через высокоскоростной InfiniBand или RoCE для передачи KV-кэша. Эта конфигурация максимизирует общую утилизацию и минимизирует разброс ITL, хотя и требует тщательной балансировки нагрузки и мониторинга сети между пулами.

TCO и экономика: CapEx против OpEx

Выбор развертывания в конечном итоге диктуется совокупной стоимостью владения (TCO). Прямая покупка GPU H100 или B200 (CapEx) требует поддержания утилизации выше 80% 24/7; в противном случае амортизированная стоимость за токен становится неконкурентоспособной. Если трафик носит пиковый характер (высокий днем, простаивает ночью), аренда мощностей через облачных провайдеров OpEx (AWS Bedrock, GCP Vertex, Together AI) часто обходится дешевле, несмотря на более высокую цену за токен, потому что вы перестаете платить при падении трафика.

Кроме того, энергопотребление (TDP) является доминирующей эксплуатационной статьей расходов. H100 SXM потребляет 700 Вт; B200 — более 1000 Вт. За 3-летний срок службы затраты на электроэнергию и охлаждение ЦОД могут превысить первоначальную стоимость покупки оборудования. Эта экономическая реальность сильно располагает к архитектурам, минимизирующим количество FLOPs на токен, что делает MoE-модели и агрессивную квантизацию (W4A4/FP8) не просто технической оптимизацией, а финансовой необходимостью при масштабировании.

Таблица матрицы решений

Заключение

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

Не существует единой конфигурации, которая доминировала бы по всем параметрам. Плотная модель с точностью FP16, запускаемая через TensorRT-LLM, обеспечит самую низкую задержку, но потребляет больше всего памяти на запрос и требует тщательной многоузловой настройки для масштабирования. MoE-модель с архитектурой MLA, квантизацией FP8 и 3D-параллелизмом выдает наивысшую пропускную способность на уровне кластера, но вносит накладные расходы на роутинг и требует тщательного выбора архитектуры. Меньшая плотная модель со спекулятивным декодированием и кэшированием префиксов достигает практичного баланса для смешанных нагрузок.

Рекомендуемой отправной точкой для большинства команд является плотная модель с посттренировочной квантизацией (FP8 на оборудовании Hopper, INT8/INT4 на старых GPU), запускаемая через vLLM. Этот стек быстро развертывается, поддерживает маршрутизацию, совместимую с OpenAI, и обеспечивает достаточную наблюдаемость для выявления узких мест в целевой нагрузке. Как только эти узкие места измерены, можно итеративно переходить к более специализированным оптимизациям: добавьте спекулятивное декодирование, если ограничением является задержка decode при малых батчах; перейдите на QAT и TensorRT-LLM, если ограничением является пропускная способность на вложенный бюджет; используйте модели с MTP, если первичным сценарием использования является генерация длинных ответов с низкой энтропией; или внедрите дезагрегированный инференс, если вы работаете на масштабе кластера с гетерогенными нагрузками. Путь оптимизации носит инкрементный, а не обязательный характер.

Глоссарий

Ссылки

1. Архитектура и механизмы внимания (Architecture and Attention Mechanisms)
   1. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints. arXiv:2305.13245
   2. Fast Transformer Decoding: One Write-Head is All You Need (MQA). arXiv:1911.02150
   3. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model (MLA). arXiv:2405.04434
   4. DeepSeek-V3 Technical Report (MoE with auxiliary-loss-free balancing). arXiv:2412.19437
2. Смесь экспертов (MoE) и роутинг (Mixture of Experts and Routing)
   1. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. arXiv:2101.03961
   2. Mixture-of-Experts with Expert Choice Routing. arXiv:2202.09368
   3. Mixtral of Experts (MoE architecture in practice). arXiv:2401.04088
3. Предсказание нескольких токенов (MTP) и спекулятивное декодирование (Multi-Token Prediction and Speculative Decoding)
   1. Fast Inference from Transformers via Speculative Decoding. arXiv:2211.17192
   2. Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads. arXiv:2401.10774
   3. EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty. arXiv:2401.15077
   4. Gemma 4 Technical Report (Native MTP heads and QAT checkpoints). arXiv:2607.02770
4. Методы квантизации (Quantization Techniques)
   1. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. arXiv:2210.17323
   2. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. arXiv:2306.00978
   3. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. arXiv:2211.10438
   4. QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMs. arXiv:2404.00456
   5. QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving (QoQ algorithm). arXiv:2405.04532
5. Параллелизм и дезагрегированный инференс (Parallelism and Disaggregated Serving)
   1. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv:1909.08053
   2. Ring Attention with Blockwise Transformers for Near-Infinite Context (Context Parallelism). arXiv:2310.01889
   3. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving. arXiv:2401.09670
   4. Splitwise: Efficient Generative LLM Inference Using Phase Splitting. arXiv:2311.18677
6. Управление KV-кэшем (KV Cache Management)
   1. Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM). arXiv:2309.06180
   2. SGLang: Efficient Execution of Structured Language Model Programs (RadixAttention). arXiv:2312.07104
7. Фреймворки инференса и оборудование (Inference Frameworks and Hardware)
   1. TensorRT-LLM Developer Guide. NVIDIA Docs
   2. llama.cpp & GGUF Format Specification. GitHub
   3. Text Generation Inference (TGI) Documentation. HF Docs
   4. Hopper Architecture In-Depth Whitepaper (FP8 Tensor Cores, 3.35 TB/s HBM3). NVIDIA Resources
   5. Gemma 4 MTP Documentation. Google AI
   6. Documentation. docs.vllm.ai