Производительность языковых моделей: метрики latency и throughput в тестах

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

Для продукта это различие практическое. В чате важна отзывчивость на старте диалога и равномерное появление текста. В пакетной обработке документов приоритетом может стать число запросов, которые инфраструктура обрабатывает за единицу времени. Один и тот же результат тестирования не описывает оба сценария одинаково.

Почему одного показателя скорости LLM недостаточно

Слово «скорость» часто скрывает разные этапы обработки. После отправки запроса система может ждать свободных вычислительных ресурсов, преобразовывать входной текст в представление для модели, генерировать ответ и передавать его по сети. Пользователь видит итоговую последовательность событий, но каждая метрика фиксирует только отдельную её часть.

Для корректного бенчмаркинга генеративных моделей сначала нужно определить, что именно измеряется: отзывчивость одного запроса, скорость потока токенов или суммарная производительность сервера под нагрузкой. Эти показатели отвечают на разные вопросы.

TTFT расшифровывается как time to first token, то есть время до первого токена. Throughput, или пропускная способность, показывает объём работы за единицу времени. Latency — задержка, то есть время, которое проходит между началом операции и заданным результатом. Эти понятия связаны, но подменять одно другим нельзя.

Например, высокая суммарная пропускная способность не гарантирует, что отдельный пользователь увидит быстрый ответ. Сервер может эффективно обслуживать много запросов, но распределять вычислительные ресурсы так, что ожидание каждого из них станет заметным. И наоборот, одиночный запрос может выполняться быстро, тогда как система окажется неэффективной при одновременной работе большого числа клиентов.

Производительность модели — это профиль поведения системы при конкретной нагрузке, а не одна цифра без контекста.

TTFT: время до первого токена

TTFT измеряет промежуток от отправки запроса до появления первого токена ответа. Для чат-бота или помощника в приложении этот показатель часто определяет первое ощущение отзывчивости: генерация ещё не завершена, но пользователь уже видит, что система начала отвечать.

В TTFT могут входить несколько компонентов. Запрос может ожидать в очереди, серверу требуется обработать входной текст, а затем результат проходит по сети до клиента. Этап подготовки входа называется prefill: модель обрабатывает контекст, прежде чем перейти к генерации новых токенов. Чем длиннее промпт, тем больше вычислений обычно требуется на этом этапе, следовательно, TTFT может увеличиваться.

При сравнении моделей длина входа должна быть одинаковой или хотя бы зафиксированной. Иначе тесты смешивают два фактора: производительность самой конфигурации и объём работы, который ей поручили. Это особенно важно для сценариев с длинными документами, историей диалога или большим системным контекстом. Результат для короткой команды не позволяет напрямую оценить задержку при анализе многостраничного текста.

TTFT также зависит от режима обслуживания. Если сервер принимает запросы редко, он может не ждать накопления группы задач. При пакетировании — объединении нескольких запросов для совместной обработки — использование ускорителя может стать эффективнее, однако ожидание отдельных запросов меняется. На результат влияют и сетевые задержки, поэтому тест, проведённый непосредственно рядом с сервером, может отличаться от замера в реальном приложении.

Для продукта полезно разделять два вопроса. Первый: как быстро пользователь получает начало ответа? Второй: насколько этот показатель стабилен в часы нагрузки? Среднее значение описывает центральный уровень, но не показывает, как часто клиентам приходится ждать существенно дольше. Поэтому TTFT следует публиковать вместе с распределением результатов и условиями запуска.

ITL и TPOT: как быстро продолжается генерация

Первый токен ещё не говорит о скорости всего ответа. После него модель последовательно формирует остальные токены, и для пользовательского опыта важен интервал между ними. В GenAI-Perf этот интервал обозначается ITL (inter-token latency): среднее время между последовательными токенами ответа, при этом первый токен в расчёт не включается. В терминологии NVIDIA для близкого показателя используется название TPOT — время на выходной токен.

В упрощённой формуле GenAI-Perf средний ITL рассчитывается как разница между полной задержкой и TTFT, делённая на число выходных токенов за вычетом первого. Иными словами, из общего времени генерации убирают стартовое ожидание и оценивают средний интервал оставшейся последовательности.

Это усреднение удобно для сравнений, но скрывает колебания. Два запуска могут иметь одинаковый средний ITL, хотя в одном токены появляются почти равномерно, а в другом генерация периодически замедляется. Для интерактивного сервиса разница заметна: плавный поток текста воспринимается иначе, чем чередование коротких пауз и ускорений.

На интервал генерации влияют модель, аппаратная конфигурация, серверная реализация, длина ответа и число одновременно обслуживаемых запросов. Поэтому оценка скорости LLM требует фиксировать не только входной промпт, но и ожидаемую длину ответа. Если одна система генерирует короткую последовательность, а другая длинную, сравнение полной задержки без учёта объёма вывода будет неоднозначным.

Есть и методологическая деталь: инструменты могут по-разному определять ITL. В описании NVIDIA отмечается, что GenAI-Perf не включает TTFT в средний ITL, тогда как LLMPerf включает его. Значения с одинаковой подписью в отчёте поэтому могут отражать разные интервалы. Перед сравнением следует сверить формулу, границы замера и способ подсчёта токенов.

Полная задержка: время до завершения ответа

Полная задержка запроса измеряется от его отправки до получения последнего токена. Она включает начальное ожидание, обработку входа, генерацию ответа и передачу данных. В описании NVIDIA показатель представлен как TTFT плюс время генерации после первого токена.

Для пользователя это наиболее прямой ответ на вопрос, сколько времени заняло получение результата целиком. Однако метрика зависит от длины ответа: длинная генерация обычно требует больше времени, чем короткая, даже если модель производит токены с одинаковой скоростью. Следовательно, сопоставлять полную задержку имеет смысл при контролируемом объёме входа и выхода.

В бизнес-процессах значение полной задержки зависит от типа задачи. Если помощник должен предложить короткую подсказку во время заполнения формы, важны и быстрый старт, и быстрое завершение. Если система обрабатывает документ в фоне, задержка отдельного запроса может быть менее критичной, чем общий объём обработанных данных за час. Одинаковый сервер в этих двух режимах следует оценивать разными наборами показателей.

Полезно также отличать время обработки на сервере от времени, которое проходит в клиентском приложении. В тесте могут учитываться сетевые задержки и передача токенов, но реальный пользователь взаимодействует с интерфейсом, который способен буферизовать вывод или отображать его порциями. Если приложение не показывает токены сразу, серверный профиль генерации не полностью описывает видимую задержку ответа нейросети.

Throughput: производительность под параллельной нагрузкой

Пропускную способность языковой модели выражают, например, в запросах в секунду или выходных токенах в секунду. При этом нужно указывать, является ли значение суммарным для всей системы или рассчитанным на одного пользователя. Без такого уточнения показатель легко прочитать неверно: системный поток может расти, даже если индивидуальный запрос начинает ждать дольше.

При увеличении числа одновременных запросов суммарная производительность может расти, пока вычислительные ресурсы не достигнут насыщения. После этого дальнейшее увеличение нагрузки способно привести к снижению пропускной способности. На практике важно наблюдать не только максимум, но и поведение системы до и после точки насыщения: как меняются TTFT, интервалы генерации и полная задержка.

Измерения можно строить по числу одновременных запросов или по частоте их поступления. Первый режим показывает поведение при заданном параллелизме, второй позволяет оценить реакцию на поток запросов с определённой интенсивностью. GenAI-Perf поддерживает настройку входных данных и нагрузки, а результаты можно сохранять в CSV и JSON для последующего анализа.

Пример демонстрационного запуска GenAI-Perf для GPT-2 на Triton с TensorRT-LLM показывает, почему набор метрик информативнее одного значения: TTFT составил 16,26 мс в среднем, ITL — 1,85 мс, задержка запроса — 499,20 мс, пропускная способность выходных токенов — 520,87 токена в секунду, а запросов — 1,99 в секунду. Это результат конкретной конфигурации и условий запуска. Он не является отраслевым нормативом и не задаёт ожидаемую скорость для других моделей, серверов или приложений.

Для продуктовой оценки полезно рассматривать компромисс между пропускной способностью всей системы и скоростью обслуживания отдельного пользователя. Подход MLPerf Endpoints, например, оценивает такую кривую при разных уровнях параллелизма, а не сводит результат к одной точке. Это помогает увидеть, какой ценой система увеличивает общий объём работы.

Рост числа токенов в секунду полезен только тогда, когда понятно, сколько запросов делит этот поток и как меняется ожидание каждого клиента.

Как устроить сопоставимый бенчмаркинг

Бенчмаркинг генеративных моделей имеет смысл только при описанной методике. В отчёте должны быть зафиксированы модель, аппаратная конфигурация, серверная система, длина входа и выхода, уровень параллелизма, режим потоковой передачи и способ замера. Если один тест подаёт короткие запросы при низкой нагрузке, а другой проверяет длинные контексты на насыщенном сервере, их числа не дают прямого сравнения.

Перед запуском стоит определить сценарий, который воспроизводит реальную работу продукта:

• Для интерактивного чата измерять TTFT и распределение интервалов между токенами при характерной длине диалога.
• Для фоновой обработки смотреть на полную задержку и суммарную пропускную способность при ожидаемом числе одновременных задач.
• Для сервиса с потоковой выдачей учитывать, как именно клиент получает и отображает токены.
• Для длинных документов отдельно проверять влияние объёма входа на предварительную обработку и время до начала ответа.
• Для сравнения конфигураций сохранять одинаковые условия теста и указывать метод подсчёта входных и выходных токенов.

Среднее значение не показывает, как система ведёт себя на медленных запросах. Поэтому вместе со средним полезно публиковать перцентили: p50 описывает середину распределения, а p90, p95 или p99 показывают более длинное ожидание для части запросов. В документации AIPerf также перечислены p25, p50, p75, p90, p95 и p99, наряду с минимумом, максимумом и стандартным отклонением.

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

Инструменты тоже требуют аккуратного сопоставления. GenAI-Perf и LLMPerf могут по-разному учитывать первый токен в ITL, а определения пропускной способности способны различаться по границам измерения. Кроме того, счётчик токенов эталонного клиента может не совпадать со счётчиком внутренней serving-системы. Разница в отчётах не обязательно означает разницу в производительности модели: сначала нужно установить, что именно измерял каждый инструмент.

Результаты лучше сохранять в машиночитаемом формате и сопровождать описанием нагрузки. Это облегчает повторный анализ, позволяет строить графики задержек и проверять, не изменились ли условия между запусками. Сам по себе файл с набором итоговых чисел не заменяет методику: без сведений о запросах и параллелизме его трудно интерпретировать.

От метрик к решению о внедрении

Практическая оценка производительности языковых моделей начинается с требования продукта, а не с поиска самой впечатляющей цифры. Если пользователь ждёт короткий ответ в интерфейсе, приоритетом становятся быстрое начало и предсказуемая генерация. Если модель выполняет пакетную работу, решающими могут оказаться суммарная пропускная способность и стоимость поддержания нужной нагрузки. Во втором случае высокий ITL сам по себе не гарантирует эффективного процесса, как и высокий throughput не гарантирует комфортного интерактивного опыта.

Для сравнения конфигураций достаточно сначала выбрать один реалистичный сценарий, затем измерить TTFT, ITL или TPOT, полную задержку и пропускную способность при нескольких уровнях параллелизма. Результаты следует показать вместе с перцентилями и параметрами запуска. Такая схема не создаёт универсального рейтинга моделей, зато даёт основание выбрать конфигурацию для конкретного сервиса.

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

Единого порога хорошей задержки или пропускной способности для всех языковых моделей нет. И не может быть без оговорок о задаче, нагрузке, размере контекста и методе замера. Надёжный вывод появляется тогда, когда метрики описывают именно тот режим работы, который предстоит обслуживать продукту.