Token, cost, and latency dashboards

У LLM-запроса не одна латентность, а три. TTFT (time to first token) — время до первого токена ответа: его определяют очередь у провайдера и обработка промпта, и именно он формирует ощущение «живости» в стриминге. TPOT (time per output token) — темп генерации после первого токена; обратная величина — tokens/s. Полная E2E-латентность ≈ TTFT + output_tokens × TPOT, а у агента это ещё сумма по всем шагам: три генерации по 2 секунды плюс инструмент на 4 секунды дают 10 секунд, и найти виновника можно только по спанам — самый долгий спан на критическом пути и есть цель оптимизации.

Стриминг — важная оговорка: он не сокращает полное время, но радикально меняет восприятие. Пользователь, видящий первые слова через 500 мс, спокойно ждёт остальное; пустой экран на те же суммарные 8 секунд — это брошенная сессия. Поэтому для стриминговых интерфейсов TTFT важнее E2E.

Теперь про агрегацию. Латентность LLM имеет тяжёлый правый хвост: большинство запросов быстрые, но меньшинство — ретраи, длинные контексты, троттлинг — в разы медленнее. Среднее по такому распределению бессмысленно: при среднем 2 с ваш p95 может быть 12 с, то есть каждый двадцатый пользователь страдает, а дашборд зелёный. Стандарт — перцентили: p50 показывает типичный опыт, p95/p99 — хвост. Алёрты и SLO вешают на p95/p99, потому что деградация всегда начинается с хвоста.

Стоимость запроса считается из usage generation-спанов:

cost = input_tokens / 1M × price_in
     + output_tokens / 1M × price_out
     + cached_tokens / 1M × price_cached

Цены за миллион токенов у провайдеров различаются на порядки между моделями, output обычно в 3–5 раз дороже input, а кэшированные input-токены (prompt caching) — в разы дешевле обычных. Платформы вроде Langfuse считают стоимость автоматически по прайс-листам моделей, для ручного OTel её выводят на дашборде из usage-атрибутов.

У агентов почти всегда доминирует input: контекст накапливается, и на каждом шаге модель перечитывает всю историю. Диалог из N шагов суммарно платит за историю примерно N раз — рост квадратичный, и распухший системный промпт или необрезаемая история незаметно умножают счёт. Поэтому первый инструмент анализа — отчёт «топ-20 самых дорогих трейсов»: в нём обычно сразу видно, что 80% стоимости съедают распухший контекст, зацикленные агенты или один тяжёлый сценарий.

Метрики уровня бизнеса: cost per request → cost per session → cost per user per day → cost per feature. Последняя — главная для решений: фича-суммаризация может стоить 0.1 цента за вызов, а агент-исследователь — доллар, и без разбивки по фичам эти цифры сливаются в бесполезную среднюю. Добавьте cache hit rate: рост доли кэшированных токенов — самый дешёвый способ срезать счёт без потери качества.

Хороший дашборд — это не «все метрики, какие есть», а набор панелей, каждая из которых отвечает на вопрос и подразумевает действие:

• Трафик: запросы в минуту, уникальные сессии — контекст для всего остального;
• Ошибки по типам: HTTP 5xx, таймауты, rate limit (429), content filter — у каждого типа своя причина и свой владелец;
• Латентность: TTFT p50/p95 и E2E p95, отдельными линиями по моделям;
• Токены: input и output отдельно (у них разная цена и разная динамика), cache hit rate;
• Стоимость: cost/day с разбивкой по модели и фиче, прогноз на месяц;
• Хвосты: таблицы топ-10 самых медленных и самых дорогих трейсов за сутки со ссылками — мост от метрики к конкретному дереву спанов;
• Поведение агента: среднее число шагов на прогон, доля ретраев и fallback-ответов, распределение finish_reasons.

Технически: латентность — гистограммы (OTel histogram, из них считаются перцентили), токены и стоимость — счётчики с атрибутами для разбивки. Langfuse и LangSmith дают готовые дашборды поверх трейсов; Grafana собирает то же из OTel-метрик, если наблюдаемость общекорпоративная.

Тест качества дашборда: представьте, что каждая панель «покраснела», и спросите, какое действие последует. Если ответа нет — панель декоративная и место на экране тратит зря. Начинайте с шести-восьми панелей, добавляйте по мере реальных инцидентов.

Главный обман дашбордов — агрегация по всему трафику. Общий p95 и общий cost/day усредняют десяток разных моделей, фич и типов пользователей, и регрессия одного сегмента тонет в объёме остальных. Классика: новая фича на 5% трафика деградировала вдвое, но общий p95 сдвинулся на проценты — в пределах шума. Или парадокс Симпсона в чистом виде: качество выросло в каждом сегменте, но общая метрика упала, потому что трафик перетёк в тяжёлый сегмент.

Лекарство — сегментация по измерениям, которые вы прошили атрибутами трейсов ещё на уроке 2: модель, фича или маршрут, версия промпта, язык пользователя, тарифный план. Любая метрика на дашборде должна раскладываться по этим осям в один клик. Разбор всплеска стоимости превращается в дерево вопросов: cost/day вырос — какая модель? — какая фича? — все пользователи или один? Нередко выясняется, что весь всплеск — это один интегратор, загнавший агента в цикл, и чинить надо rate limit, а не промпт.

Отдельная ловушка — сравнение несравнимого во времени: после переключения на другую модель прямое сравнение p95 «до и после» некорректно без учёта того, что у новой модели другой TPOT и другая длина ответов. Сравнивайте попарно по сегментам и нормируйте на длину ответа.

Правило на выход: метрика без сегментации — это средняя температура по больнице; сначала измерения (атрибуты), потом метрики, потом дашборд.