В этом материале
Самое раннее событие не всегда является полезным токеном. Название метрики должно соответствовать фактической границе наблюдения.
Поток быстро прислал headers и служебный comment, но пользователь всё ещё ждёт ответ. Если метрика названа TTFT, а останавливается на первом byte, график покажет улучшение, которого человек не заметит. Для провайдера важна точная граница каждого времени: transport activity, готовый chunk и первый результат модели описывают разные события. Их можно измерять вместе, но нельзя смешивать под одним именем.
Определите first byte
Первый byte относится к наблюдаемой передаче данных. В зависимости от инструмента измерения он может учитывать начало ответа или другую явно выбранную границу. Поэтому даже знакомое имя TTFB требует записи методики. Нельзя выводить по нему чистое время prefill или считать его моментом готовности текста.
Streaming OpenRouter описывает comments, не являющиеся JSON-контентом ответа модели. Такое событие показывает транспортную активность, но не должно автоматически закрывать таймер первого полезного вывода. Сохраните отдельно headers, comment и content, чтобы later analysis не пытался восстановить различие из одного итогового числа.
Назовите first chunk
Текущие GenAI client conventions описывают метрики chunk-level наблюдения. Их статус и версию нужно сохранять, потому что развитие conventions способно менять имена и определения. Сетевой read также не равен одному прикладному chunk: parser сначала выделяет события выбранного формата.
Если ранний delta содержит только роль, решите, относится ли он к измеряемой границе. Не подменяйте определение в процессе обновления библиотеки. Один и тот же график до и после изменения parser будет несопоставим, если раньше учитывался role frame, а теперь только непустой content.
Определите first token осторожно
GenAI server metrics отдельно описывают серверное время до первого токена. Оно относится к своей стороне наблюдения и не обязано совпадать с пользовательским временем. Между движком и клиентом есть сериализация, очереди отправки, прокси и сеть, которые могут изменить момент получения.
У reasoning-моделей дополнительно различайте начало внутреннего вывода и появление видимого content, если выбранный интерфейс позволяет это наблюдать. Не называйте неизвестный внутренний момент измеренным только потому, что клиент увидел reasoning-related поле. Имя метрики должно отражать реально доступное событие.
Сделайте детерминированную трассу
Fake upstream отправляет headers, comment, role delta и content с известными паузами. Сохраните ожидания для каждого таймера. Такой fixture проверяет instrumentation без GPU и без случайной длительности генерации. Все задержки являются параметрами стенда, а не характеристиками внешней платформы.
Затем выполните короткий запрос реальному тестовому серверу и сравните последовательность наблюдаемых событий. Если библиотека скрыла ранние frames, отчёт отмечает ограничение. Не пытайтесь восстановить ненаблюдаемое время по среднему значению другой метрики, полученной на другом наборе запросов.
Сохраните версию SLI
В итоговой записи нужны start event, stop event, единица, сторона наблюдения и instrumentation version. После изменения интерфейса или библиотеки повторяется контрольная трасса. Улучшение числа считается ускорением только после подтверждения, что определение не изменилось и профиль остался сопоставимым.
Полезны throughput и latency и инкрементальный клиент. Здесь проверяется смысл временной метрики, а не универсальный рейтинг моделей, обещанный SLA или фактическая скорость неизвестных ресурсов проекта.