РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-01
Почему LLM API отвечает медленно: TTFT, поток и полное время ответа
Скорость генерации токенов не объясняет весь путь запроса. Отдельные измерения покажут, где пользователь ждёт: до первого текста, между шагами агента или при завершении.
Снимите время отправки, первого текстового события и завершения. Отдельно измерьте инструменты и показ текста в браузере. Сравните одинаковые запросы при одной и нескольких параллельных задачах. Поток улучшает ранний показ ответа, но не гарантирует уменьшения полного времени работы.
1. Зафиксируйте события и единицы измерения
Записывайте монотонные временные метки: начало запроса, получение заголовков, первый полезный текст, последнее событие и показ в интерфейсе. Первый байт может быть служебным SSE-событием, поэтому назовите клиентскую метрику явно: время до первого текстового фрагмента. Она не равна внутреннему TTFT движка. Добавьте request_id, модель, длину входа и выхода, режим рассуждения и число шагов. Не включайте секреты в телеметрию. Для функций отдельно отмечайте получение вызова, начало исполнения и возврат результата: ожидание базы данных нельзя приписывать генерации.
2. Отделите долгий старт от длинного ответа
Если текст появляется быстро, но завершение долгое, посмотрите на размер вывода и число обращений к модели. Если первый текст задерживается, сравните короткий и длинный вход, режимы рассуждения и нагрузку. Не делайте вывод о внутренней причине по одной клиентской метке: очередь, сеть и обработка входа могут выглядеть одинаково. OpenAI рекомендует сокращать лишний вывод и число последовательных запросов как способы оптимизации задержки. Проверяйте это на своей задаче: слишком короткий ответ, который требует повторного уточнения, может увеличить время до полезного результата.
3. Проверьте, где буферизуется поток
Сопоставьте время событий в серверном обработчике и браузере. Если сервер получает дельты постепенно, а интерфейс показывает весь ответ разом, проблема может находиться в прокси, адаптере или клиентском рендеринге. Для диагностики воспроизведите локальный поток из нескольких известных фрагментов с заданными интервалами без модели. Посмотрите, доходят ли они отдельно. Затем проверьте границы SSE и декодирование: один сетевой chunk не обязательно равен одному событию. Удалите ожидание полного тела только там, где приложение действительно может безопасно показывать частичный результат.
4. Сравните одиночный запрос и нагрузку
Используйте фиксированный набор коротких и длинных задач. Сначала выполните их последовательно, затем при допустимом параллелизме. Разделяйте холодный и повторный контекст, если выбранный маршрут поддерживает кэш. Сохраняйте медиану, верхние перцентили, ошибки и долю завершённых задач. Не смешивайте быстро отклонённые запросы с успешными: средняя задержка станет обманчиво лучше. Если очередь продолжает расти, система не справляется с поступлением задач, и один показатель токенов в секунду не описывает опыт пользователя. Любую платную нагрузочную проверку предварительно ограничьте бюджетом.
5. Меняйте по одному фактору и оценивайте полезный результат
Сначала попробуйте сократить повторяющийся контекст, убрать лишний последовательный вызов или уменьшить объём ответа. Независимые операции чтения можно выполнять параллельно, если это не нарушает ограничения сервиса. Для простой классификации рассмотрите правила или меньшую модель, но подтвердите точность на прежнем наборе. В интерфейсе показывайте факт начала работы и частичный текст, не обещая готовность раньше финального события. Сравнивайте время до принятого результата: быстрый неверный ответ, затем два исправления и повторный инструмент могут оказаться медленнее одного качественного выполнения.
Частые вопросы
Streaming всегда ускоряет API?
Он позволяет показать результат до завершения. Полное время может остаться прежним, а буферизация может скрыть пользу потока.
Почему высокая скорость токенов сочетается с долгим ожиданием?
Скорость вывода не включает весь старт, сеть, очередь и инструменты. Измеряйте первый полезный текст и полное время отдельно.
Как проверить задержку интерфейса бесплатно?
Подайте локальный синтетический SSE-поток с известными интервалами. Это проверит доставку и отображение, но не скорость настоящей модели.
Достаточно среднего времени ответа?
Нет. Нужны перцентили, доля ошибок и длина результатов. Отдельно рассмотрите задачи, которые завершились после нескольких шагов или повторов.