Вы вводите запрос в ChatGPT, Claude или Gemini — и через долю секунды на экране начинают появляться слова. За этой кажущейся простотой скрывается сложнейший конвейер: токенизация, матричные вычисления на миллиардах параметров, управление памятью GPU и десятки оптимизаций, отточенных годами исследований. Этот конвейер называется инференс (inference) — процесс получения ответа от обученной модели.

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

Что такое инференс и почему он важен

Жизненный цикл любой нейросети состоит из двух фаз: обучение (training) и инференс (inference). Обучение — это долгие недели на кластерах из тысяч GPU, когда модель учится на данных. Инференс — это применение обученной модели для генерации ответов в реальном времени.

ℹ Ключевое отличие
Обучение происходит один раз и стоит миллионы долларов. Инференс происходит миллионы раз в день и определяет реальный пользовательский опыт. По оценкам, до 90% всех вычислительных затрат на AI в продакшене приходится именно на инференс.

Когда пользователь отправляет запрос к LLM через API, происходит следующая цепочка:


graph LR
    A["Текст запроса"] --> B["Токенизация"]
    B --> C["Prefill-фаза"]
    C --> D["KV-кэш"]
    D --> E["Decode-фаза"]
    E --> F["Детокенизация"]
    F --> G["Текст ответа"]
    style C fill:#4a9eff,color:#fff
    style E fill:#ff6b6b,color:#fff

Два ключевых этапа — prefill и decode — принципиально различаются по характеру вычислений, и именно понимание этого различия открывает путь к оптимизациям.

Две фазы инференса: prefill и decode

Prefill: обработка входного контекста

Когда запрос поступает на сервер, весь текст промпта сначала разбивается на токены (подслова). Затем начинается prefill-фаза: модель обрабатывает все входные токены одновременно через параллельные матричные операции в слоях attention.

Это тяжёлая вычислительная работа — compute-bound операция, которая загружает GPU практически на 100%. Чем длиннее промпт, тем дольше фаза prefill. Для промпта в 1000 токенов на модели с 70B параметрами это может занять 200–500 мс.

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

Время до первого токена (TTFT — Time to First Token) — это по сути и есть длительность prefill-фазы. Именно этот показатель определяет, как быстро пользователь увидит начало ответа.

Decode: генерация по одному токену

После завершения prefill модель переходит в decode-фазу — автоматическую генерацию ответа токен за токеном. На каждом шаге модель:

  1. Берёт последний сгенерированный токен
  2. Прогоняет его через все слои трансформера
  3. Использует KV-кэш для вычисления attention (не пересчитывая предыдущие токены)
  4. Выбирает следующий токен из распределения вероятностей
  5. Повторяет до стоп-сигнала

Decode-фаза принципиально отличается от prefill: здесь обрабатывается только один токен за раз, поэтому GPU недозагружен вычислениями. Узкое место — не вычислительная мощность, а скорость чтения из памяти (memory-bound). Веса модели, ключи и значения из KV-кэша нужно загрузить из HBM-памяти GPU для каждого токена.

⚠ Проблема интерференции
Традиционные системы запускают prefill и decode на одном GPU. Когда GPU занят тяжёлой prefill-операцией для нового запроса, decode-шаги текущих генераций вынуждены ждать — и наоборот. Это увеличивает задержку для всех пользователей одновременно.

Современные решения вроде DistServe разделяют эти фазы на разные GPU: одни отвечают за prefill, другие — за decode. Это позволяет масштабировать каждую фазу независимо.

ХарактеристикаPrefillDecode
ОбрабатываетВсе входные токены сразуПо одному токену
Узкое местоВычисления (compute-bound)Память (memory-bound)
Загрузка GPU~100%10–30%
ОпределяетTTFT (время до первого токена)Скорость генерации (tok/s)
Можно ускоритьБолее мощный GPUБолее быстрая память (HBM)

KV-кэш: память, которая всё меняет

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

Проблема в том, что KV-кэш занимает огромный объём памяти. Для модели с 70B параметрами и контекстным окном в 200K токенов KV-кэш может потребовать 40–80 ГБ видеопамяти — почти весь объём NVIDIA H100 (80 ГБ), не оставляя места для весов модели.

Как оптимизируют KV-кэш

PagedAttention (vLLM). Прорывная техника, предложенная командой vLLM: управление памятью KV-кэша по аналогии с виртуальной памятью в операционных системах. Память выделяется небольшими блоками (страницами) по мере необходимости и освобождается, когда генерация завершена. Результат — увеличение размера батча в 2–4 раза на том же GPU.

Квантование кэша. Вместо хранения KV-кэша в FP16 (16-бит) его сжимают до FP4 (4-бит) с потерей точности менее 1%. NVIDIA H100 и H200 поддерживают FP4-квантование аппаратно, что вдвое сокращает потребление памяти.

RadixAttention (SGLang). Если несколько запросов начинаются с одинакового системного промпта (что типично для чат-ботов), KV-кэш общей части хранится один раз и переиспользуется. Это особенно эффективно для RAG-пайплайнов и многошаговых диалогов.

# Пример: инференс с vLLM и PagedAttention
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,        # 4 GPU
    gpu_memory_utilization=0.90,   # 90% памяти под KV-кэш
    max_model_len=32768,
    quantization="fp8",            # FP8 квантование весов
)

params = SamplingParams(temperature=0.7, max_tokens=1024)
outputs = llm.generate(["Объясни, как работает инференс LLM"], params)
print(outputs[0].outputs[0].text)

Оптимизации, которые ускоряют инференс в разы

Continuous batching (непрерывная батчевая обработка)

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

Continuous batching (in-flight batching) решает это элегантно: как только один запрос завершается, на его место немедленно подставляется новый — прямо в процессе генерации остальных. Утилизация GPU возрастает в 2–5 раз.


graph TD
    subgraph "Static Batching"
        A1["Запрос 1 ████████░░░░ ожидание"] 
        A2["Запрос 2 ████████████████████"]
        A3["Запрос 3 ████░░░░░░░░ ожидание"]
    end
    subgraph "Continuous Batching"
        B1["Запрос 1 ████████ Запрос 4 ████████"]
        B2["Запрос 2 ████████████████████"]
        B3["Запрос 3 ████ Запрос 5 ██ Запрос 6 ██████"]
    end

Speculative decoding (спекулятивное декодирование)

Одна из самых интересных оптимизаций последних лет. Идея: вместо того чтобы генерировать по одному токену большой моделью, маленькая модель-черновик (1–7B параметров) быстро генерирует 3–12 токенов-кандидатов, а основная модель проверяет их все за один проход.

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

💡 Когда speculative decoding эффективен
Максимальный эффект — при малых батчах (1–4 запроса), где ускорение достигает 2–3.6×. При батчах от 8+ запросов основной прирост даёт continuous batching, а speculative decoding добавляет мало. На бенчмарках AMD MI300X комбинация FP8-квантования и speculative decoding показала 3.6× суммарное ускорение на Llama 3.1-405B.

Квантование модели

Снижение точности весов модели — с FP16 (16-бит) до INT8 или FP4 — уменьшает объём памяти и ускоряет чтение весов. Для decode-фазы, ограниченной пропускной способностью памяти, это даёт прямой прирост скорости.

ФорматРазмер 70B моделиПотеря качестваПоддержка GPU
FP16~140 ГББазовый уровеньВсе
FP8~70 ГБ< 0.5%H100, H200, B200
INT4/FP4~35 ГБ1–3%H100, H200, B200
GPTQ/AWQ 4-bit~35 ГБ1–2%Все (программно)

Железо и фреймворки: что стоит за скоростью

GPU для инференса в 2026

Три поколения NVIDIA GPU сосуществуют на рынке инференса:

H100 (Hopper) — рабочая лошадка. 80 ГБ HBM3, 3.35 ТБ/с пропускной способности памяти. Основная платформа для большинства облачных провайдеров.

H200 — эволюция Hopper. 141 ГБ HBM3e, 4.8 ТБ/с. На 9–10% быстрее H100 по пропускной способности инференса, а главное — вмещает большие модели без тензорного параллелизма.

B200 (Blackwell) — новое поколение. 192 ГБ HBM3e, 6.0 ТБ/с, NVLink 5. Самая низкая латентность — до 2.40 мс при конфигурации из 8 GPU. В FP4-режиме обеспечивает примерно 3× меньшую стоимость за токен по сравнению с H200.

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

ФреймворкСильная сторонаTok/s на H100Когда выбирать
SGLangRadixAttention, чат-сценарии~16 200Чат-боты, RAG, многошаговые диалоги
vLLMPagedAttention, гибкость~12 500Быстрый старт, частая смена моделей
TensorRT-LLMАппаратная оптимизация NVIDIAМаксимальныйСтабильная модель в долгосрочном продакшене
LMDeployСкорость, простота~16 200Высокая пропускная способность

По бенчмаркам 2026 года, SGLang и LMDeploy лидируют по скорости генерации — около 16 200 токенов в секунду на H100 — опережая vLLM на 29%.

Латентность на практике: что видит пользователь

Все оптимизации сходятся в двух метриках, которые определяют пользовательский опыт:

  • TTFT (Time to First Token) — через сколько миллисекунд пользователь увидит начало ответа
  • TPS (Tokens per Second) — скорость «печати» ответа

По данным бенчмарков API за апрель 2026 года:

МодельTTFT (медиана)Скорость генерации
Claude Haiku 4.5~600 мс~79 tok/s
GPT-5.2~600 мс—
Gemini 2.5 Flash—~147 tok/s
Claude 4.5 Sonnet~2 000 мс—
📝 Порог восприятия
Для интерактивного чата TTFT ниже 1 секунды ощущается как «мгновенный» ответ. Модели вроде Claude Haiku 4.5 (TTFT ~600 мс) и GPT-5.2 (~600 мс) уже достигают этого порога. Настоящий вызов — преодолеть барьер в 200 мс, после которого задержка была бы неотличима от реакции обычного приложения. Пока этого не удалось достичь ни одному крупному LLM-провайдеру.

Заключение

Инференс LLM — это не просто «прогнать текст через нейросеть». Это тонко выстроенный конвейер, где каждый этап оптимизирован под свои ограничения: prefill — под вычислительную мощность, decode — под пропускную способность памяти, а KV-кэш — под доступный объём GPU.

Ключевые выводы:

  1. Две фазы — два узких места. Prefill ограничен вычислениями, decode — памятью. Оптимизировать их нужно по-разному, а в идеале — запускать на разных GPU.

  2. KV-кэш — главный потребитель памяти. Без техник вроде PagedAttention и FP4-квантования обслуживать длинные контексты (100K+ токенов) было бы нерентабельно.

  3. Speculative decoding вышел в продакшен. В 2026 году он встроен во все основные фреймворки и даёт 2–3× ускорение при малых батчах.

  4. Железо продолжает ускоряться. Переход от H100 к B200 даёт 3× снижение стоимости за токен в FP4, а 192 ГБ памяти позволяют держать большие модели без разбиения.

  5. Барьер в 200 мс TTFT пока не пройден. Это следующий рубеж, после которого взаимодействие с LLM станет неотличимо от обычного софта.

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