Когда LLM становится частью продакшн-инфраструктуры, классического мониторинга уже недостаточно. Узким местом становится не код приложения, а слой маршрутизации и выбора моделей — и именно там нужна наблюдаемость.
В cах деградация начинается не с падения HTTP-эндпоинтов, а с накопления неочевидных эффектов: рост латентности на отдельных моделях, скачки стоимости из-за маршрутизации, таймауты конкретных промптов, rate limits у провайдера. Если приложение использует несколько моделей и провайдеров, традиционный подход с логами и метриками внутри сервиса быстро теряет связность. Инженер видит симптомы, но не видит контекста принятия решений — какой моделью обрабатывался запрос, почему произошёл fallback, сколько это стоило.
В OpenRouter сделали ставку на перенос observability в инфраструктурный слой — туда, где происходит маршрутизация и балансировка между моделями. Ключевая идея — не заставлять команды вручную инструментировать каждый вызов, а генерировать трассировку автоматически на уровне API. Это снижает операционную нагрузку и устраняет расхождения между фактическим поведением системы и тем, что заинструментировано в коде. Trade-off очевиден: меньше гибкости в кастомной телеметрии, но значительно выше консистентность и полнота данных.
Реализация построена вокруг OpenTelemetry. Фича Broadcast в OpenRouter автоматически создаёт trace для каждого запроса и отправляет его в внешние системы, например Grafana Cloud, через OTLP endpoint. Важный момент — отсутствие SDK и изменений в коде приложения: трассировка включается на уровне аккаунта. В trace попадают атрибуты, специфичные для LLM-нагрузки: модель, провайдер, токены, стоимость, latency, а также prompt и completion (если не включён privacy mode). На стороне Grafana Cloud это обрабатывается через Tempo и становится доступным в TraceQL, что позволяет работать с LLM-трейсами так же, как с распределёнными системами.
Практическая ценность проявляется в нескольких сценариях. Во-первых, прозрачность стоимости: можно разложить расходы по моделям, API-ключам или пользовательским атрибутам без отдельной биллинговой аналитики. Во-вторых, управление латентностью — сравнение p50/p95/p99 между моделями даёт основу для маршрутизации по SLA, а не по догадкам. В-третьих, дебаг: trace сразу показывает, был ли это rate limit, ошибка провайдера или проблема в самом запросе. Наконец, планирование — по агрегированным данным о токенах и частоте вызовов можно прогнозировать нагрузку и пересматривать стратегию выбора моделей.
Метрики в классическом смысле здесь вторичны — ценность в связности данных. Даже без формализованных KPI команды получают целостное представление о поведении LLM-нагрузки: где тратятся деньги, где теряется время и где система ведёт себя нестабильно. Это сдвигает observability из уровня “посмотреть графики” в уровень принятия архитектурных решений.