Почему LLM API тормозит в production: p99, очереди и безопасный fallback
В 10:00 AI-функция отвечает за четыре секунды. В 10:40 медиана почти не изменилась, но часть пользователей ждёт минуту. Команда смотрит на среднее время, не видит аварии и обвиняет сеть. Через час очередь переполнена, повторы удваивают нагрузку, а резервная модель генерирует ответ в другом формате.
Так выглядит типичный инцидент с LLM API. Он редко начинается с полного отказа. Сначала портится хвост распределения — p95 и p99. Большинство запросов остаётся быстрым, поэтому проблема долго выглядит субъективной.
Инцидент: модель не упала, продукт всё равно остановился
10:00. Обычная нагрузка. p50 — 3,8 секунды, p99 — 11 секунд.
10:18. Несколько длинных запросов занимают рабочие слоты. p50 остаётся около четырёх секунд, p99 растёт до 35.
10:27. Клиенты не дожидаются ответа и повторяют запрос. Сервер тоже запускает автоматический Retry.
10:34. Один пользовательский запрос создаёт две или три генерации. Очередь растёт быстрее входящего трафика.
10:41. Включается Fallback, но резервный маршрут не поддерживает тот же JSON Schema. Продукт получает быстрые, но непригодные ответы.
10:55. Команда отключает повторы, ограничивает длинный контекст и возвращает очередь под контроль.
Во всём эпизоде модель формально была доступна. Сломалась система ожиданий вокруг неё.
Почему среднее время ответа скрывает проблему
Если 99 запросов занимают две секунды, а один — 100 секунд, среднее всё ещё может казаться приемлемым. Но именно сотый пользователь создаёт повтор, открывает второй запрос или уходит. Для интерактивного продукта хвостовая задержка важнее средней.
Нужно разделять как минимум четыре этапа:
• время в очереди — запрос ещё не попал к модели;
• TTFT — время до первого токена;
• скорость генерации — токены в секунду после старта;
• полное время задачи — включая инструменты, проверку и повторные шаги.
Фраза «API медленный» ничего не диагностирует. Медленной может быть очередь, префилл длинного контекста, сама генерация, внешний Tool или ваш Retry.
Длинный контекст создаёт соседям длинное ожидание
Большое контекстное окно часто воспринимают как бесплатное пространство: раз модель принимает документ целиком, его отправляют целиком. В production это меняет не только цену, но и планирование вычислений. Длинный prefill занимает память и рабочее время, короткие запросы ждут рядом, а p99 растёт раньше p50.
Размер контекста должен быть частью класса обслуживания. Быстрый чат, анализ документа и автономный Agent не должны безусловно стоять в одной очереди.
Наблюдение: многие инциденты LLM выглядят как нехватка модели, хотя на самом деле это отсутствие дисциплины очередей.
Retry может превратить деградацию в аварию
Повтор безопасен только тогда, когда команда знает, был ли запрос принят и не создал ли он действие. При Timeout клиент часто не может отличить «сервер ничего не сделал» от «ответ потерялся после выполнения».
Для генерации текста дубликат означает лишний счёт. Для Agent это может означать второе письмо, второй заказ или второй платёж. Нужны Idempotency Key, ограниченное число попыток, Exponential Backoff и общий Retry Budget. Главное правило: не все ошибки заслуживают повторения.
Fallback — это контракт, а не запасной URL
Переключить model ID легко. Сохранить поведение продукта сложнее. Резервная модель может иначе трактовать системную инструкцию, не поддерживать нужный Tool Choice, нарушить JSON Schema или иметь другой лимит контекста.
Перед включением Fallback нужно проверить:
1 совместимость входного формата и инструментов;
2 структурированный вывод и валидацию Schema;
3 лимит контекста и максимальный ответ;
4 политику безопасности и поведение отказа;
5 цену, тайм-аут и ожидаемое качество;
6 идемпотентность действий после переключения.
Иногда правильный fallback — не другая модель, а урезанный режим продукта: короткий ответ без инструментов, постановка задачи в очередь или честное сообщение пользователю.
Мультимодельный маршрут без хаоса
Единый API сокращает техническую стоимость резервных маршрутов. Через OdiRouter.ai команда получает доступ к 200+ моделям и может держать основной и резервный маршруты разных семейств без отдельных интеграций и платёжных контуров.
Но сам факт наличия 200 моделей не является отказоустойчивостью. Она появляется, когда для каждого маршрута существует Capability Profile: поддержка инструментов, JSON, контекст, цена, тайм-аут и результаты внутренних Eval. Каталог даёт выбор; инженерная дисциплина превращает его в надёжность.
Что должно быть на дашборде
Минимальный production-набор — p50/p95/p99 отдельно по модели и типу задачи, время очереди, TTFT, токены в секунду, доля Timeout, число повторов на запрос, глубина очереди, успешность Schema Validation и стоимость принятой задачи. Метрики нужно связывать одним Trace ID, иначе команда увидит семь графиков и не восстановит один пользовательский путь.
План на первые пятнадцать минут
1 Остановить неконтролируемые Retry.
2 Разделить новые запросы по длине контекста и приоритету.
3 Ограничить параллелизм, чтобы очередь перестала ускоряться.
4 Проверить, где возникла задержка: Queue, TTFT, Generation или Tool.
5 Включать только заранее проверенный Fallback.
6 Сохранить Trace проблемных задач для последующего воспроизведения.