Почему обычного RPS недостаточно
У LLM два разных этапа: prefill обрабатывает весь prompt, decode выпускает токены последовательно. Два запроса одинакового размера в байтах могут занимать совершенно разную мощность из-за числа токенов и длины ответа. Поэтому RPS без профиля input/output sequence length почти ничего не говорит.
Сначала соберите workload model
Разделите трафик на сценарии: короткий чат, длинный RAG-запрос, суммаризация, генерация кода, вызов tools. Для каждого сохраните распределения входных и выходных токенов, долю streaming, частоту повторов, число параллельных пользователей и интервалы между запросами. Используйте обезличенную выборку production, а синтетику сверяйте с ней.
Главные метрики
TTFT показывает время до первого содержательного токена и включает очередь, сеть и prefill. ITL или TPOT показывает паузу между следующими токенами. End-to-end latency важна для нестриминговых задач. System TPS измеряет общий выпуск токенов, user TPS - скорость ответа для одного клиента. Все latency публикуйте минимум в p50, p95 и p99.
Concurrency и request rate отвечают на разные вопросы
Closed-loop тест держит фиксированное число активных клиентов: новый запрос начинается после ответа. Open-loop отправляет запросы с заданной интенсивностью и лучше показывает перегрузку. Если входной поток выше мощности, очередь растёт без границ. Для capacity sweep повышайте concurrency ступенями, добавляя прогрев и устойчивую фазу на каждой ступени.
Как найти точку насыщения
Постройте график total TPS против TTFT или p95 latency. Сначала throughput растёт вместе с concurrency, затем почти перестаёт расти, а очередь и TTFT резко увеличиваются. Последняя ступень, где SLO ещё выполняется и нет накопления очереди, - практический предел одной конфигурации.
Проверяйте весь путь
Отдельный benchmark модели не видит gateway, аутентификацию, RAG, reranker, tool calls, лимиты провайдера и клиентский streaming parser. Нужны два теста: контролируемый model benchmark и end-to-end load test. Разница между ними показывает overhead приложения.
Ошибки, квоты и стоимость
Считайте 429, 5xx, timeouts, отмены клиентом и незавершённые streams. Для внешнего API проверяйте RPM и TPM одновременно. Добавьте cost ceiling: входные, выходные и cached tokens, повторные запросы и вызовы инструментов. Тест, который выдержал latency, но превысил бюджет, не прошёл.
Минимальный протокол испытания
Зафиксируйте версии модели, runtime и железа; прогрейте систему; выполните sweep по реалистичным профилям; сохраните raw per-request metrics; повторите тест; проверьте деградацию и восстановление; оформите capacity table - допустимая нагрузка, запас, SLO и стоимость на каждый сценарий.