Сколько токенов в секунду выдаёт LLM: как измерить скорость

Что показывает число токенов в секунду

Скорость выдачи в токенах в секунду показывает, как быстро LLM передаёт сгенерированные токены после получения первого. Большая языковая модель, или LLM, обрабатывает текст в виде токенов: это могут быть слова, части слов или знаки препинания. Число токенов нельзя универсальным способом перевести в число слов. В определении Cerebras это различие оговорено прямо.

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

В приложении стоит отдельно отслеживать следующие показатели:

Эти границы соответствуют определениям метрик Artificial Analysis. Первый токен рассуждений может прийти раньше первого токена ответа, поэтому такие интервалы нужно называть по-разному.

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

В основе работы модели лежат этапы prefill — обработка промпта — и decode — генерация продолжения. В разборе инференса LLM показано, как эта работа проходит через систему обслуживания запросов.

Почему одной цифры скорости недостаточно

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

Длина промпта и кешированный контекст

Короткий вопрос в чате поддержки и тот же вопрос с длинной историей переписки и найденными документами о правилах компании — разная нагрузка. Объём входных данных меняет работу, которую нужно выполнить до ответа. В руководстве по снижению задержек Groq называет размер входных данных одним из факторов, влияющих на TTFT.

Фиксируйте в результатах теста длину промпта и состояние кеша. В разборе KV-кеша объясняется, как сохранённое состояние механизма внимания используется при генерации и как повторное использование промпта связано с кешированием. Повторный запрос с уже прогретым кешем нельзя без оговорок выдавать за новую беседу с клиентом.

Рассуждения до ответа

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

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

Пакетная обработка и параллельные запросы

Пакетная обработка объединяет задачи, чтобы эффективнее загружать оборудование. Общая пропускная способность учитывает выдачу по всем запросам, а скорость для отдельного пользователя — поток в рамках его запроса. Cerebras отмечает, что пакетная обработка может повысить пропускную способность, одновременно увеличив время ожидания. Источник: объяснение пропускной способности Cerebras.

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

Регион и доставка потока

Расположение приложения и обслуживающего запросы эндпоинта влияет на сетевую задержку. В рекомендациях по анализу сети Groq разделяет время обработки на сервере и задержку, которую видит клиент.

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

Сколько токенов в секунду выдаёт GPU

У GPU — ускорителя, на котором выполняется инференс, — нет единой содержательной характеристики «токенов в секунду» вне конкретной модели и нагрузки. При сравнении оборудования рядом с результатом должны быть указаны модель, точность вычислений, контекст, конфигурация сервера инференса и число одновременных запросов.

Квантизация снижает числовую точность ради экономии памяти; её влияние на скорость и качество зависит от реализации. Cerebras поясняет это в материале о сжатии моделей. При сравнении развёртываний сжатых моделей используйте руководство по квантизации LLM и проверяйте качество ответов наряду со скоростью.

Как провайдеры указывают скорость

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

Cerebras: заявленная скорость с оговоркой об условиях использования

Провайдер инференса Cerebras указывает для OpenAI GPT-OSS 120B в таблице Developer скорость «~3000 tokens/s». На той же странице сказано, что производительность зависит от модели и конфигурации, а доступ Developer предназначен для оценки, а не для работы в продакшене. Источник: тарифы Cerebras.

Главный вопрос — сможет ли доступный вам вариант развёртывания обслуживать вашу нагрузку с нужной отзывчивостью и достаточным запасом мощности. Одна таблица этого не покажет.

Скорость Groq: смотрите строку нужной модели

Провайдер инференса Groq указывает для OpenAI GPT-OSS 120B значение «500» в столбце «SPEED (T/SEC)» таблицы поддерживаемых моделей. Это опубликованное Groq значение для данной строки. Источник: поддерживаемые модели Groq.

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

Выбирая баланс скорости и стоимости, сравнивайте цену успешно выполненной задачи и необходимую мощность с помощью руководства по тарифам Cerebras и руководства по тарифам Groq.

Где смотреть независимые замеры

Независимый сервис бенчмарков Artificial Analysis — удобная отправная точка для сравнения моделей и провайдеров инференса. Откройте рейтинг провайдеров, а затем изучите, на каком эндпоинте и при какой нагрузке получен результат.

В текущей методике измерения производительности указаны следующие условия:

• Стандартная нагрузка — примерно 10,000 входных токенов и не менее 1,500 токенов ответа.
• Для обычных нагрузок результат представлен медианой за последние 72 часа.
• Основной тестовый сервер находится в зоне us-central1-a Google Cloud.
• Для замеров производительности число токенов нормализуется с помощью o200k_base, а не собственного токенизатора каждой модели.

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

Для моделей, скрывающих часть токенов рассуждений, Artificial Analysis рассчитывает скорость выдачи по последним 80% фрагментов ответа. Простой скрипт ниже не воспроизводит ни этот метод, ни полную тестовую нагрузку сервиса. Он измеряет текстовый поток, который получает ваш клиент.

Как измерить скорость собственного потока

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

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

Установите зависимости:

python3 -m pip install groq tiktoken

Задайте переменную окружения GROQ_API_KEY. В GROQ_MODEL укажите текстовую модель без рассуждений, доступную вашему аккаунту из списка поддерживаемых моделей Groq, а в prompt.txt поместите типичный для приложения промпт. Сохраните код в measure_stream.py и запустите командой python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

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

При расчёте скорости первый текстовый фрагмент исключается и из числа токенов, и из интервала их получения. Здесь используется формула для фрагментов потока из определений Artificial Analysis. При определении момента получения последнего текста также не учитываются метаданные, поступающие в конце.

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

Что дают калькуляторы и симуляторы скорости

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

Как использовать симулятор токенов в секунду

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

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

Какая скорость в токенах в секунду считается хорошей?

Целевой показатель зависит от того, на каких этапах задачи возникает ожидание. Чтобы его выбрать, ответьте на вопросы о работе вашего продукта.

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

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

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

Для заказчика услуг провайдера: сможет ли предложенное развёртывание обеспечивать нужную работу при вашем трафике, из вашего региона и с вашими промптами? Типичен ли заявленный результат для этого развёртывания? Что происходит при ошибках запросов или нехватке свободных мощностей?

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

В чём преувеличивают значение скорости LLM?

Главное преувеличение — считать, что максимальная скорость выдачи автоматически указывает на лучший эндпоинт для приложения. Скорость не подтверждает ни качество ответа, ни корректность результата, ни успешную работу с инструментами.

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

Учитывайте скорость при оценке, но считайте задачу завершённой только тогда, когда получен корректный результат, которым можно пользоваться.

Частые вопросы

Что сделать в следующей итерации

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

Подпишитесь на рассылку, чтобы получать практические руководства по созданию полезных приложений с ИИ.