Inference: context, sampling, KV cache и serving

Два этапа: prefill и decode

Inference (прогон модели для ответа) идёт в два этапа.

Prefill (обработка входа): весь prompt проходит через модель за один параллельный проход. GPU здесь загружена вычислениями, а от длины входа зависит TTFT (time to first token, время до первого token).

Decode (генерация): дальше модель выдаёт по одному token за шаг. На каждом шаге нужно прочитать из памяти все веса ради одного нового token. Поэтому decode упирается не в скорость вычислений, а в memory bandwidth (пропускную способность памяти). Если в batch (пакете) идут сразу десятки запросов, одно чтение весов обслуживает их всех — поэтому загруженный сервер выдаёт в сумме намного больше tokens, чем один поток.

Отсюда грубая оценка потолка скорости для одного запроса: пропускная способность ÷ объём весов. Qwen3-8B в bf16 весит 16,4 ГБ. На GPU с памятью 1,79 ТБ/с потолок ≈ 109 tokens/с, на устройстве с 273 ГБ/с ≈ 17 tokens/с. В 4 битах (Q4_K, ~4,6 ГБ) потолки вырастают примерно в 3,5 раза. Реальная скорость ниже потолка, но порядок оценка даёт верный, и она объясняет главное: квантизация при хороших kernels (программах вычислений на GPU) ускоряет генерацию, потому что читать приходится меньше байт.

Context window: бюджет, а не склад

Context window (окно context) — предел длины одного вызова в tokens, причём ответ модели тоже входит в этот предел. У Qwen3-8B по карточке — 32 768 tokens «natively» и до 131 072 с методом растяжения YaRN.

Длинный context стоит четырьмя способами: деньгами (API считает каждый token), временем (prefill растёт с длиной входа), памятью (KV cache, ниже) и качеством — с ростом context точность вспоминания падает, это называют context rot. Поэтому большая часть работы с агентами — решать, что положить в context, а что оставить за его пределами.

Sampling: как выбирается следующий token

Модель выдаёт вероятности для всего словаря; решение, какой token взять, принимает decoding strategy (стратегия выбора).

• Greedy (жадный выбор) — всегда самый вероятный token. В библиотеке transformers это выбор по умолчанию; документация предупреждает, что на длинных текстах он начинает повторяться.
• Sampling (случайный выбор по распределению) — do_sample=True. Его настраивают ручками ниже.
• temperature — делит logits перед softmax. Меньше 1 — распределение острее, больше 1 — площе.
• top_k — выбирать только из k самых вероятных tokens.
• top_p (nucleus sampling) — из самых вероятных tokens, пока их суммарная вероятность не дойдёт до p.

Пример с числами: три кандидата с logits 2,0; 1,0 и 0,1.

Производитель модели обычно пишет рекомендации. Карточка Qwen3-8B: в режиме thinking (рассуждение перед ответом) temperature 0,6, top_p 0,95, top_k 20; без него — 0,7, 0,8 и 20; и прямо: «DO NOT use greedy decoding, as it can lead to performance degradation and endless repetitions». Для извлечения данных и вызова tools берут низкую temperature, для текстов и идей — выше. И помни: даже temperature 0 на сервере не гарантирует одинаковых ответов — порядок вычислений в batch немного меняет числа. Поэтому evals прогоняют несколько раз.

KV cache: память, которая растёт с каждым token

Из-за causal mask token смотрит только назад, и keys и values прошлых tokens не меняются. Их считают один раз и хранят — это KV cache (кэш ключей и значений внимания). На каждом шаге decode модель считает query только нового token. Без кэша каждый шаг пересчитывал бы весь текст заново.

Размер на один token: 2 (key и value) × число слоёв × число KV heads × размер head × байт на число. Для Qwen3-8B из config.json: 2 × 36 × 8 × 128 × 2 байта = 147 456 байт, около 144 КиБ на token.

• context 32 768 tokens → 4,8 ГБ на один разговор;
• 131 072 tokens → 19,3 ГБ, больше самих весов (16,4 ГБ);
• десять пользователей по 32 768 tokens → 48 ГБ только на кэш.

Обрати внимание на «8 KV heads» при 32 query heads. Это GQA (grouped-query attention): несколько query heads делят одну пару key и value. С 32 KV heads кэш был бы вчетверо больше. Документация Hugging Face поэтому прямо советует GQA или MQA для чатов с длинным context.

Вывод: на сервере KV cache, а не веса, ограничивает, сколько разговоров идёт одновременно и какой длины. Рычаги: квантованный кэш (int8 или int4), выгрузка в оперативную память, короче максимальный context, общий префикс (одинаковый system prompt считают один раз — prefix caching).

Serving: от скрипта к серверу

model.generate() годится для опытов. Для пользователей ставят inference server. Стандарт для GPU — vLLM. Его основа — PagedAttention (статья 2023): KV cache хранится блоками фиксированного размера, как страницы виртуальной памяти в операционной системе. Это убирает фрагментацию, даёт «near-zero waste in KV cache memory» и, по статье, в 2–4 раза больше throughput (пропускной способности), чем у предыдущих систем, при той же задержке. Ещё vLLM делает continuous batching (новые запросы вливаются в batch на каждом шаге, а не ждут, пока закончится весь пакет), prefix caching, квантизацию (FP8, INT8, INT4, GPTQ/AWQ), tensor parallelism на нескольких GPU и отдаёт OpenAI-compatible API — клиентский код не меняется. Для GGUF на ноутбуке и Mac — llama.cpp и Ollama.

Метрики сервера: TTFT, tokens/с на пользователя, общий throughput, p95 latency. Главный компромисс: больше batch — выше общий throughput, но каждый пользователь получает tokens медленнее. Инженер выбирает максимальную длину context, число одновременных запросов, квант и параметры sampling под задачу — и проверяет это нагрузочным тестом.