В этом материале
Сравнивайте оборудование на разных сочетаниях входа и ответа. Хороший результат короткого чата не описывает работу с документами, а суммарное число токенов скрывает различия нагрузки.
Владелец сервера часто видит инференс как одну операцию: пришёл запрос, GPU поработал, появился ответ. Для выбора нагрузки полезнее разделить процесс на обработку входного контекста и генерацию новых токенов. Такое разделение помогает понять, где теряется время и какие задачи стоит проверять на имеющемся оборудовании.
Две стадии одного ответа
Обработку входной последовательности обычно называют prefill. Последующую генерацию ответа — decode. В документации vLLM об оптимизации эти стадии рассматриваются отдельно при настройке планирования запросов. Для владельца практический вывод состоит в необходимости проверять разные формы нагрузки, а не искать единственное универсальное число производительности.
Например, извлечение короткого вывода из длинного документа и написание большого текста по короткой инструкции могут иметь похожее общее количество токенов, но потребовать разной конфигурации обслуживания.
Составьте матрицу, а не один запрос
Для пилота предложите четыре синтетических профиля.
| Профиль | Вход | Ответ | Что проверяем |
|---|---|---|---|
| Короткий диалог | Короткий | Короткий | Базовую отзывчивость |
| Анализ документа | Длинный | Короткий | Обработку входа |
| Генерация текста | Короткий | Длинный | Устойчивую выдачу |
| Рабочая сессия | Длинный | Длинный | Совместные ограничения |
Начните с одного обращения и постепенно добавляйте параллельные. Фиксируйте реальные длины после токенизации: одинаковое количество символов не гарантирует одинакового объёма работы разных моделей.
Разделите ожидание и вычисления
Время до первого токена включает больше, чем одну операцию модели. Клиент может ждать очередь, обработку входа и передачу данных. Поэтому «медленно начинает отвечать» ещё не означает, что нужен новый GPU.
В протоколе испытания отмечайте момент отправки, появление первого токена и завершение ответа. Добавьте состояние очереди. Тогда станет видно, связана ли задержка с длинным входом, общей нагрузкой или внешним соединением.
Для владельца это уменьшает риск ненужной модернизации. Иногда прежде покупки карты стоит изменить лимит одновременных запросов или отдельно обслуживать разные профили.
Проверяйте смешанный поток
Следующий этап — одновременно запускать короткие и длинные задачи. Иначе сервер может показать хороший результат на каждом классе отдельно и неудобное поведение при их сочетании.
Предлагаемый критерий прост: короткие обращения должны сохранять согласованную отзывчивость, пока длинная задача обрабатывается в допустимых пределах. Конкретные границы выбирают под продукт. Их не следует назначать по чужому рекламному тесту.
Сохраните версии модели и окружения, ограничения контекста, состав потока и потребление машины. Без этих сведений сравнение разных дней окажется ненадёжным.
Как использовать результат при подключении
Результат матрицы позволяет предложить серверу определённую роль: интерактивные короткие запросы, работу с документами или иной проверенный сценарий. Это техническое основание для разговора о пуле, а не доказательство будущих продаж токенов.
Укажите GPU, VRAM и предполагаемую доступность, а эту матрицу используйте как тему первого обсуждения. Продолжить помогут материалы о памяти модели и плане пилота.