В этом материале
Интервал между chunks не равен времени одного токена. Сравнивайте только одинаковые определения и явно задавайте веса при агрегации.
Один клиент получает фрагменты рывками, а сервер показывает устойчивый общий tokens/s. Оба наблюдения могут быть верными, потому что измеряют разные величины. Для провайдера важно разделить время после первого токена, паузы между прикладными событиями и совокупный выпуск всех запросов. Иначе среднее красивого графика скроет задержки отдельных пользователей или ошибку instrumentation на коротких ответах.
Опишите единицу наблюдения
GenAI server conventions описывают time per output token после первого токена и его серверную область. Это не просто интервал между двумя сетевыми reads. Один read способен содержать несколько событий, а одно событие — представлять больше одного токена в конкретном интерфейсе.
В измерительной записи назовите источник token count и временные границы. Не восстанавливайте токены по пробелам и не считайте число SSE-events точным выходным объёмом без документированной связи. Такое приближение может быть полезно отдельно, но его нельзя выдавать за native счётчик движка.
Разберите крайние случаи
Для ответа с одним токеном нет интервала между выходными токенами после первого. Для нулевого выхода арифметика ещё очевиднее не даёт обычного TPOT. Определите, пропускается ли такое наблюдение, хранится ли отдельная классификация и как оно влияет на сводку. Ноль как подставленное значение способен искусственно улучшить среднее.
Не путайте пустой visible content с нулём всей работы. Reasoning или иная поддержанная детализация может менять смысл output count. Если данных недостаточно, отчёт сохраняет unknown и причину, а не вычисляет удобную величину из неполного текста.
Отделите клиентские паузы
GenAI client conventions описывают chunk-level время со стороны вызывающего приложения. Эти измерения полезны для ощущения потока, но включают доставку и обработку клиента. Большой gap может появиться из-за buffering даже при ровной работе движка.
Сохраните sequence numbers и моменты готовых событий. Для synthetic stream с известными паузами сравните прямой и проксированный пути. Такой тест проверяет измеритель, прежде чем задержка будет приписана модели. Не называйте client chunk latency чистой скоростью decode без отдельного основания.
Выберите веса сводки
Среднее значений TPOT по запросам и отношение суммарного decode-времени к суммарным последующим токенам имеют разные веса. Короткий и длинный ответ влияют на них по-разному. Назовите выбранный способ и не меняйте его между сравниваемыми конфигурациями только ради удобного результата.
Prometheus о histograms объясняет хранение распределений и ограничения агрегации готовых quantiles. Сохраняйте достаточную статистику для нужного вопроса. Одно среднее не показывает длинные паузы, а сумма throughput разных интервалов не становится скоростью каждого пользователя.
Сведите метрики без подмены
Практический артефакт содержит отдельные столбцы: server TPOT, client event gaps, input/output counts и aggregate completion rate за одинаковый интервал. У каждой величины есть единица и определение. Тогда можно увидеть реальный компромисс, а не спорить о единственном слове «скорость».
Связанные материалы — throughput и latency и prefill/decode. Здесь результатом является согласованная семантика наблюдений, без универсальных чисел производительности и без утверждений о работающем сервисе или будущих оплачиваемых токенах.