Фетиш скорости: почему все помешаны на токенах в секунду?
Открываешь любой форум по local LLM - сплошные цифры. "У меня 12 токен/с на Llama 3.2 11B!", "А я выжал 28 токен/с из Qwen2.5-Coder-32B!". Звучит как соревнование по разгону процессоров в 2005-м. Но давайте начистоту: в 99% случаев эти цифры не имеют никакого отношения к реальному пользовательскому опыту.
Проблема в том, что сообщество смешало два разных понятия: лабораторную производительность и практическую полезность. Пять токенов в секунду на сложной модели могут быть ценнее пятидесяти на тупой. Скорость генерации - не линейная метрика, а логарифмическая. Разница между 1 и 10 токен/с - катастрофа. Между 20 и 40 - уже почти незаметна.
Самый большой миф: токен/с - это как ГГц у процессора. Чем больше, тем лучше всегда. На деле всё сложнее. Иногда высокая скорость генерации - признак того, что модель "халтурит" и выдает очевидные, простые продолжения.
Чтение vs генерация: где собака зарыта
Представьте, что вы даете модели прочитать документ на 10 тысяч токенов. Сам процесс загрузки контекста - это forward pass, и его скорость измеряется в токенах в секунду на обработку (prefill throughput). Это одна метрика. А генерация ответа - это autoregressive sampling, совсем другая.
Когда вы видите "5 токен/с" в тесте - спросите себя: это скорость на каком этапе? С каким контекстом? При каком размере батча? Без этих деталей цифра бессмысленна.
1 Когда скорость важна по-настоящему (спойлер: не всегда)
- Интерактивные диалоги: Человек печатает со скоростью 2-3 слова в секунду. Модель, которая генерирует быстрее 10 токен/с, будет постоянно ждать пользователя. Абсурд.
- Пакетная обработка: Нужно сгенерировать 1000 ответов на вопросы? Да, здесь каждый лишний токен/с экономит минуты.
- Стриминг ответов: Если вы показываете ответ по мере генерации (как в ChatGPT), то скорость ниже 15-20 токен/с создает неприятные паузы между словами.
- Кодинг-ассистенты: Здесь странная ситуация. Программист читает код быстрее, чем пишет. Модель, которая генерирует 5 токен/с, может быть вполне адекватной, если она выдает качественный, продуманный код.
Запомните простое правило: скорость генерации важна, когда она становится заметна человеку. Если ответ появляется быстрее, чем пользователь успевает его прочитать - вы достигли потолка полезной скорости.
2 Как выжимают токены: от железа до трюков с квантизацией
Допустим, вам действительно нужна скорость. С чего начать? Вот иерархия эффективности оптимизаций на 2026 год:
| Метод | Прирост скорости | Потеря качества | Сложность |
|---|---|---|---|
| Аппаратное ускорение (ASIC/NPU) | 5-10x | Нет | Очень высокая |
| Квантизация до 4-бит (GPTQ/AWQ) | 2-3x | Минимальная | Низкая |
| Оптимизация внимания (FlashAttention-3) | 1.5-2x | Нет | Средняя |
| Continuous batching | 3-8x (нагрузка) | Нет | Высокая |
| Правильный PCIe (4 vs 5) | 1.2-1.5x | Нет | Средняя |
Обратите внимание: самые жирные приросты дают алгоритмические оптимизации, а не железо. Continuous batching - это магия, которая превращает 5 токен/с в 40 при обработке 8 запросов одновременно. Если вы строите сервис, понимание этого механизма критично.
Но есть нюанс: все эти оптимизации работают только если упираетесь в вычислительные ресурсы. Если вы гоняете 7B модель на RTX 4090 и получаете 50 токен/с - вы уперлись в memory bandwidth. Дальнейшие оптимизации бессмысленны. Нужна либо более легкая модель, либо другой подход.
Типичные ошибки: как НЕ надо измерять скорость
Я видел десятки "бенчмарков", которые вводят в заблуждение. Вот топ-3 ошибки:
- Тестирование на коротких промптах. Генерация 50 токенов из промпта "Hello" показывает максимальную скорость, но не имеет ничего общего с реальностью. В жизни у вас всегда есть контекст.
- Игнорирование времени первого токена (TTFT). В интерактивных сценариях время от отправки запроса до первого токена важнее средней скорости. Модель может выдавать 100 токен/с, но думать первую секунду.
- Использование разных температурных параметров. Температура 0.0 (жадный поиск) всегда быстрее, потому что не нужно сэмплирование. Но кто использует температуру 0.0 в реальных задачах?
Практический план: что делать сегодня
Вместо абстрактных советов - конкретный план действий для разных сценариев. Выберите свой:
Сценарий А: Интерактивный чат на домашнем ПК
- Берите модель, которая помещается в VRAM целиком. Если 8ГБ - ищите 7B в 4-бит. Если 24ГБ - можно 32B в 4-бит.
- Забудьте про скорость выше 20 токен/с. Вы не заметите разницу.
- Используйте Ollama или llama.cpp с настройкой
--n-gpu-layers 99чтобы загрузить всё в GPU. - Если модель для кода - лучше медленная, но умная, чем быстрая и глупая.
Сценарий Б: Сервер для API (10-100 запросов в минуту)
- Обязательно используйте vLLM или Text Generation Inference с continuous batching.
- Квантизация - ваш лучший друг. AWQ обычно лучше сохраняет качество на 4-битах.
- Считайте не токен/с, а запросов в секунду. Это важнее.
- Масштабирование через несколько GPU с правильной настройкой PCIe lanes. На 2026 год PCIe 5.0 x16 дает реальный прирост в multi-GPU.
Сценарий В: Пакетная обработка данных
- Здесь скорость - это деньги. Каждый лишний токен/с экономит часы работы инстансов.
- Используйте самые агрессивные оптимизации: 3-битная квантизация, speculative decoding, кэширование внимания.
- Рассмотрите специализированное железо. Если обрабатываете терабайты текста, ASIC вроде Taalas окупится за месяцы.
- Параллелизация на уровне запросов - не на уровне токенов.
FAQ: коротко о главном
Почему у меня разная скорость в llama.cpp и Ollama на одной модели?
Разные версии, разные настройки по умолчанию, разное распределение слоев между CPU и GPU. В llama.cpp проверьте флаги -ngl, -c, -b. В Ollama - настройки в Modelfile. Чаще всего дело в количестве слоев на GPU.
Стоит ли переходить с PCIe 4.0 на PCIe 5.0 для LLM?
Только если у вас multi-GPU конфигурация и вы упираетесь в обмен данными между картами. Для одной карты разница менее 5%. Подробный тест здесь.
Правда ли, что новые архитектуры ускоряют генерацию в 10 раз?
Архитектуры вроде WeDLM от Tencent действительно дают 3-10x ускорения на слабом железе, но за счет качества. Это trade-off. Для некритичных задач - отлично. Для production - нужно тестировать.
Почему скорость падает с ростом контекста?
Attention-механизм имеет сложность O(n²). Каждый новый токен должен "посмотреть" на все предыдущие. Есть оптимизации (кэширование, sparse attention), но полностью линейной зависимости не добиться. При контексте 32K токенов даже простой forward pass занимает время.
Последний совет, который никто не даёт
Самый эффективный способ ускорить работу с LLM - не разгонять модель, а уменьшить количество токенов.
Звучит банально, но это работает:
- Используйте более эффективную токенизацию. Для русского языка некоторые модели токенизируют в 1.5-2 раза экономнее английского (хотя бывают и обратные случаи, особенно с нелатинскими алфавитами).
- Учите модель быть лаконичной. Few-shot промпты с примерами коротких ответов творят чудеса.
- Обрезайте контекст. Вам действительно нужны все 32K токенов истории? Или достаточно последних 4K?
- Предварительная обработка промпта. Удалите лишние пробелы, форматирование, HTML-теги.
Прогноз на 2027: скорость генерации перестанет быть маркетинговым параметром. Как когда-то мегагерцы у процессоров. Вместо этого будут говорить о "качестве за единицу времени" или "токен-эффективности". И это будет правильно.
Если после прочтения вы все еще хотите гнаться за цифрами - вот исчерпывающий гайд по разгону. А если хотите понять, как работает магия батчинга на низком уровне - можно попробовать написать свой мини-vLLM.
Но помните: идеальная скорость - это когда пользователь не замечает, что ждет. Всё, что быстрее - уже ваше эго, а не практическая польза.
