Нагрузочный тест LLM: почему прогрев кэша может скрыть реальную стоимость
На тесте повторяют один короткий вопрос тысячу раз и получают отличную задержку. В реальном трафике вопросы разные, документы обновляются, а кэш часто пуст. Такой прогон измеряет удобный частный случай, а не готовность продукта к нагрузке.
Отдельно проверяйте холодный и прогретый контур, новые и повторные запросы, короткие и длинные задачи. Состав нагрузки должен отражать пользовательские сценарии, а не только максимальное число запросов в секунду.
Учебная ситуация
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Режим | Что происходит | Что измерять |
|---|---|---|
| Холодный | Нет готового результата | Полный путь и расход |
| Прогретый | Часть данных переиспользуется | Эффект кэша |
| Смешанный | Разные вопросы и размеры | Поведение очередей |
| После обновления | Кэш частично сброшен | Период восстановления |
Повторяемость полезна для диагностики, но её долю нужно указывать. Если девять из десяти запросов обслужил кэш, низкая стоимость не описывает генерацию нового ответа. С другой стороны, кэш является законной частью системы, и исключать его из всех тестов тоже неверно.
Сравнивайте режимы как отдельные условия. Не переносите показатель одного на другой без объяснения и не выдавайте учебные числа за реальные измерения.
Проверка перед внедрением
Соберите обезличенный профиль намерений и размеров входа. Подготовьте контролируемый набор уникальных запросов и повторов. На каждом прогоне сохраняйте конфигурацию кэша, версии данных, число исполнителей и ограничения внешних сервисов.
Измеряйте ожидание очереди, полное время, ошибки, отмены и расход. После обновления индекса проверьте, не возникает ли всплеск одновременных одинаковых вычислений. Ограничьте стоимость теста и используйте безопасные инструменты без реальных побочных действий. Отдельно повторите тест с замедленным источником: средняя нормальная нагрузка не показывает поведение при деградации.
Границы применимости
Учебная среда может отличаться от production по лимитам и сети. Результаты следует описывать вместе с условиями. Нагрузочный тест проверяет техническое поведение, но не доказывает правильность ответов или экономику продаж.
Пропускная способность зависит от характера задач и настройки исполнителей; профиль нагрузки необходимо задавать явно. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Canary-релиз LLM: почему сравнение общих процентов может обмануть, Откат LLM-релиза: почему старый код может не работать с новым индексом.
