Инференс LLM: от логитов до батчинга

Модель выдаёт логиты: по числу на каждый токен словаря. Как из них получается текст, почему первый токен приходит долго, а следующие быстро, и как один GPU обслуживает сотни пользователей: об этом весь модуль.

Сэмплирование: температура, top-k, top-p

Логиты превращаются в вероятности через softmax. Перед этим их делят на температуру T:

p_i = exp(z_i / T) / Σ exp(z_j / T)

• T → 0: распределение схлопывается в самый вероятный токен (жадное декодирование). Ответы стабильные и однообразные.
• T = 1: исходное распределение модели.
• T > 1: хвост поднимается, текст разнообразнее и чаще бредит.

Температура не меняет порядок токенов по вероятности, только «остроту» распределения.

Top-k оставляет k самых вероятных токенов и перенормирует. Top-p (nucleus sampling) оставляет минимальный набор самых вероятных токенов, чья суммарная вероятность не меньше p. Top-p адаптивен: если модель уверена, в ядро попадёт пара токенов, если сомневается, сотни.

Для извлечения фактов, классификации и JSON берут низкую температуру. Для креатива выше. Даже при T = 0 ответы у провайдеров не всегда побитово одинаковы: батчинг и параллельные вычисления на GPU дают мелкие расхождения в числах с плавающей точкой.

Prefill и decode

Генерация идёт в две фазы:

1. Prefill. Весь промпт обрабатывается за один проход, параллельно. Фаза упирается в вычисления (compute-bound). От неё зависит TTFT, time to first token.
2. Decode. Токены генерируются по одному, каждый шаг требует прочитать все веса модели из памяти GPU. Фаза упирается в пропускную способность памяти (memory-bound). От неё зависит скорость в токенах в секунду, или TPOT, time per output token.

Отсюда практичное правило: длинный промпт бьёт по TTFT, длинный ответ по общей задержке. Выходные токены обычно дороже входных и по цене.

KV-кеш

На каждом шаге decode новому токену нужны key и value всех предыдущих токенов во всех слоях. Пересчитывать их заново было бы квадратично дорого, поэтому их хранят: это KV-кеш. Его размер:

2 (K и V) × слои × KV-головы × размер головы × длина × батч × байт на число

Для модели с 32 слоями, 8 KV-головами по 128 и fp16 это 128 КБ на токен: 4 тысячи токенов контекста дают 0,5 ГБ на одного пользователя. На длинных контекстах KV-кеш занимает больше памяти, чем веса.

Как его уменьшают:

• GQA (grouped-query attention) и MQA: несколько голов query делят одни K и V. Кеш меньше в разы.
• Квантование KV-кеша в 8 бит.
• PagedAttention (vLLM): кеш хранится страницами, как виртуальная память, без фрагментации, общие префиксы делятся между запросами.
• Prefix caching: одинаковый системный промпт считается один раз. Провайдеры API продают это как скидку на кешированные входные токены.

Батчинг

Decode упирается в чтение весов: прочитали веса, посчитали один токен. Если в батче 32 запроса, за то же чтение считаем 32 токена. Поэтому батчинг резко поднимает пропускную способность.

• Статический батчинг: ждём, пока соберётся батч, и держим его, пока не закончит самый длинный ответ. Короткие запросы простаивают.
• Continuous (in-flight) батчинг: запросы входят и выходят из батча на каждом шаге. Так работают vLLM, TGI, TensorRT-LLM, SGLang.

Компромисс: больше батч, выше throughput, но выше задержка каждого запроса.

Квантование

Веса хранят с меньшей точностью: fp16 (2 байта) → int8 (1 байт) → 4 бита (0,5 байта). Модель на 70 млрд параметров в fp16 занимает около 140 ГБ, в 4 битах около 35 ГБ плюс накладные расходы.

• Weight-only квантование (GPTQ, AWQ, форматы GGUF у llama.cpp) уменьшает память и ускоряет memory-bound decode.
• Квантование весов и активаций (например, FP8 на новых GPU) ускоряет и вычисления.
• Плата: небольшая потеря качества, сильнее на 3 битах и ниже и на маленьких моделях. Проверять надо на своей задаче.

Спекулятивное декодирование

Маленькая «черновая» модель быстро предлагает несколько токенов, большая проверяет их за один проход. Принятые токены сохраняются, на первом несовпадении берётся токен большой модели. Распределение ответа то же, что у большой модели, а скорость выше, если черновик часто угадывает.

Частые ошибки

• Ставить и температуру, и top-p агрессивно одновременно, не понимая, что оба режут хвост.
• Считать, что T = 0 гарантирует детерминизм у провайдера.
• Оценивать память только по весам и забывать про KV-кеш.
• Путать задержку (TTFT, TPOT) и пропускную способность (токены в секунду на весь сервер).

Что спросят на собесе

• Как работают температура, top-k и top-p, что выбрать для JSON-ответа.
• Что такое KV-кеш, сколько он весит и как его уменьшают (GQA, PagedAttention).
• Prefill и decode: что ограничивает каждую фазу, TTFT и TPOT.
• Continuous batching и компромисс задержки и пропускной способности.
• Квантование: сколько памяти займёт модель на N параметров в 4 битах, чем платим.