# Prefill и decode: какую работу выполняет ваш GPU при инференсе

Почему обработка длинного входа и генерация ответа нагружают сервер по-разному и как владельцу GPU выбрать полезный сценарий технического пилота.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/llm-prefill-decode/
Language: ru

Владелец сервера часто видит инференс как одну операцию: пришёл запрос, GPU поработал, появился ответ. Для выбора нагрузки полезнее разделить процесс на обработку входного контекста и генерацию новых токенов. Такое разделение помогает понять, где теряется время и какие задачи стоит проверять на имеющемся оборудовании.

## Две стадии одного ответа

Обработку входной последовательности обычно называют prefill. Последующую генерацию ответа — decode. В документации [vLLM об оптимизации](https://docs.vllm.ai/en/stable/configuration/optimization/) эти стадии рассматриваются отдельно при настройке планирования запросов. Для владельца практический вывод состоит в необходимости проверять разные формы нагрузки, а не искать единственное универсальное число производительности.

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

## Составьте матрицу, а не один запрос

Для пилота предложите четыре синтетических профиля.

| Профиль | Вход | Ответ | Что проверяем |
| --- | --- | --- | --- |
| Короткий диалог | Короткий | Короткий | Базовую отзывчивость |
| Анализ документа | Длинный | Короткий | Обработку входа |
| Генерация текста | Короткий | Длинный | Устойчивую выдачу |
| Рабочая сессия | Длинный | Длинный | Совместные ограничения |

Начните с одного обращения и постепенно добавляйте параллельные. Фиксируйте реальные длины после токенизации: одинаковое количество символов не гарантирует одинакового объёма работы разных моделей.

## Разделите ожидание и вычисления

Время до первого токена включает больше, чем одну операцию модели. Клиент может ждать очередь, обработку входа и передачу данных. Поэтому «медленно начинает отвечать» ещё не означает, что нужен новый GPU.

В протоколе испытания отмечайте момент отправки, появление первого токена и завершение ответа. Добавьте состояние очереди. Тогда станет видно, связана ли задержка с длинным входом, общей нагрузкой или внешним соединением.

Для владельца это уменьшает риск ненужной модернизации. Иногда прежде покупки карты стоит изменить лимит одновременных запросов или отдельно обслуживать разные профили.

## Проверяйте смешанный поток

Следующий этап — одновременно запускать короткие и длинные задачи. Иначе сервер может показать хороший результат на каждом классе отдельно и неудобное поведение при их сочетании.

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

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

## Как использовать результат при подключении

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

Укажите GPU, VRAM и предполагаемую доступность, а эту матрицу используйте как тему первого обсуждения. Продолжить помогут материалы о [памяти модели](/ru/journal/vram-and-models/) и [плане пилота](/ru/journal/pilot-checklist/).