# Межтокенные паузы и throughput: не усреднять разные величины

Как различать TPOT, интервалы SSE и aggregate throughput: границы измерения, нулевой и единичный выход, взвешивание и воспроизводимый пример.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-intertoken-gap-throughput-metrics/
Language: ru

Один клиент получает фрагменты рывками, а сервер показывает устойчивый общий tokens/s. Оба наблюдения могут быть верными, потому что измеряют разные величины. Для провайдера важно разделить время после первого токена, паузы между прикладными событиями и совокупный выпуск всех запросов. Иначе среднее красивого графика скроет задержки отдельных пользователей или ошибку instrumentation на коротких ответах.

## Опишите единицу наблюдения

[GenAI server conventions](https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/main/docs/gen-ai/gen-ai-metrics.md) описывают time per output token после первого токена и его серверную область. Это не просто интервал между двумя сетевыми reads. Один read способен содержать несколько событий, а одно событие — представлять больше одного токена в конкретном интерфейсе.

В измерительной записи назовите источник token count и временные границы. Не восстанавливайте токены по пробелам и не считайте число SSE-events точным выходным объёмом без документированной связи. Такое приближение может быть полезно отдельно, но его нельзя выдавать за native счётчик движка.

## Разберите крайние случаи

Для ответа с одним токеном нет интервала между выходными токенами после первого. Для нулевого выхода арифметика ещё очевиднее не даёт обычного TPOT. Определите, пропускается ли такое наблюдение, хранится ли отдельная классификация и как оно влияет на сводку. Ноль как подставленное значение способен искусственно улучшить среднее.

Не путайте пустой visible content с нулём всей работы. Reasoning или иная поддержанная детализация может менять смысл output count. Если данных недостаточно, отчёт сохраняет unknown и причину, а не вычисляет удобную величину из неполного текста.

## Отделите клиентские паузы

[GenAI client conventions](https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/main/docs/gen-ai/client-inference.md) описывают chunk-level время со стороны вызывающего приложения. Эти измерения полезны для ощущения потока, но включают доставку и обработку клиента. Большой gap может появиться из-за buffering даже при ровной работе движка.

Сохраните sequence numbers и моменты готовых событий. Для synthetic stream с известными паузами сравните прямой и проксированный пути. Такой тест проверяет измеритель, прежде чем задержка будет приписана модели. Не называйте client chunk latency чистой скоростью decode без отдельного основания.

## Выберите веса сводки

Среднее значений TPOT по запросам и отношение суммарного decode-времени к суммарным последующим токенам имеют разные веса. Короткий и длинный ответ влияют на них по-разному. Назовите выбранный способ и не меняйте его между сравниваемыми конфигурациями только ради удобного результата.

[Prometheus о histograms](https://prometheus.io/docs/practices/histograms/) объясняет хранение распределений и ограничения агрегации готовых quantiles. Сохраняйте достаточную статистику для нужного вопроса. Одно среднее не показывает длинные паузы, а сумма throughput разных интервалов не становится скоростью каждого пользователя.

## Сведите метрики без подмены

Практический артефакт содержит отдельные столбцы: server TPOT, client event gaps, input/output counts и aggregate completion rate за одинаковый интервал. У каждой величины есть единица и определение. Тогда можно увидеть реальный компромисс, а не спорить о единственном слове «скорость».

Связанные материалы — [throughput и latency](/ru/journal/throughput-latency-tradeoff/) и [prefill/decode](/ru/journal/llm-prefill-decode/). Здесь результатом является согласованная семантика наблюдений, без универсальных чисел производительности и без утверждений о работающем сервисе или будущих оплачиваемых токенах.