Нагрузочный тест LLM: протокол перед закупкой сервера

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

Подготовьте паспорт эксперимента

Зафиксируйте модель, ревизию, формат весов, движок, драйвер, GPU, CPU, RAM и настройки контекста. Запишите, какие сервисы работают рядом и участвуют ли они в тесте. Если тестируется весь RAG, не исключайте поиск только ради красивой цифры GPU.

Сохраните обезличенный набор запросов с фактическими длинами. Разделите его на короткие, типичные и длинные. Для каждой группы укажите долю в рабочем потоке и ожидаемую длину ответа. Случайные синтетические строки полезны для отдельных пределов, но не заменяют рабочие документы.

Задайте критерии до запуска

Определите максимальные p95 первого токена и полного ответа, допустимую долю ошибок и требования качества. Числа должны следовать из пользовательского процесса. У ночной обработки и голосового помощника будут разные ограничения.

MLPerf разделяет сценарии и предъявляет требования к точности и задержке. 1 Собственный пилот не становится сертифицированным MLPerf-результатом из-за использования похожих метрик. Но принцип фиксированных условий полезен для честного сравнения.

Выполните пять этапов

1. Проверка функций. Убедитесь, что модель отвечает, формат корректен и контрольные задачи решаются.
2. Прогрев. Дождитесь готовности системы и отделите холодный старт от устойчивой работы.
3. Ступени нагрузки. Повышайте входной поток, сохраняя результаты каждой ступени.
4. Перегрузка и восстановление. Проверьте ограничение очереди, таймауты и возврат к нормальному режиму.
5. Перезапуск. Измерьте восстановление сервиса и повторите контрольную выборку.

У vLLM есть инструмент bench serve с параметрами нагрузочного прогона. 2 Конкретные флаги зависят от версии. Записывайте команду вместе с окружением и не запускайте нагрузку на чужой или рабочий endpoint без согласованного окна.

Сохраните правильные метрики

Метрика	Зачем нужна
TTFT p50/p95	Начало ответа и хвост ожидания
Полное время p50/p95	Время готовности результата
Входные и выходные токены	Сопоставимость объёма работы
Успешные/ошибочные/отменённые запросы	Надёжность и скрытые потери
Очередь и активные запросы	Насыщение мощности
Пиковая память и энергия	Запас и стоимость эксплуатации

Не рассчитывайте среднюю скорость только по лучшим успешным ответам. Если таймауты исключены, отдельно покажите их долю. Для сравнения стоимости используйте результаты, прошедшие критерии качества и времени.

Проверьте, что тест не ограничен клиентом

Нагрузочный генератор тоже потребляет CPU и сеть. Если он не успевает создавать нужный поток, сервер выглядит свободным и быстрым. Контролируйте фактическую отправку запросов и синхронизацию времени. При распределённом генераторе сохраните его топологию.

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

Как выглядит полезный итог

Отчёт содержит конфигурацию, датасет, команды, таблицу результатов и границу безопасной рабочей нагрузки. Отдельно перечислены непроверенные функции и ограничения. Вывод формулируется для конкретного профиля, а не «сервер подходит всем компаниям».

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