Введение: почему скорость инференса стала критичной в 2026 году
К концу лета 2026 года локальный запуск больших языковых моделей перестал быть уделом энтузиастов с фермами GPU. Компании массово уходят с облачных API по двум причинам: контроль над конфиденциальными данными и непредсказуемые счета за токены при масштабировании. Но просто скачать модель и запустить её на корпоративном сервере недостаточно. Комфортная работа требует четкого понимания метрик производительности.
Раньше все смотрели на общую скорость генерации. Сейчас сообщество практиков выработало конкретные пороговые значения для двух ключевых параметров: скорость обработки входного промпта (prefill, PP) и скорость генерации текста (text generation, TG). Нижняя граница для комфорта в задачах кодинга и анализа документов - 300-350 t/s для PP и 9 t/s для TG. Эти цифры - результат сотен тестов на реальных рабочих нагрузках, а не синтетических бенчмарков.
Рост популярности квантованных моделей и гибридных схем запуска CPU+GPU заставил пересмотреть старые критерии. Модель, которая в 2024 году считалась быстрой, сегодня может оказаться непригодной для практической работы из-за возросших объемов контекстов и новых требований к отзывчивости. В статье разберем, откуда взялись эти пороги, как их измерить и какие компромиссы неизбежны при ограниченном бюджете на железо.
Ключевые метрики производительности: prefill (PP) и генерация текста (TG)
Инференс LLM состоит из двух фаз, которые нагружают железо принципиально по-разному. Prefill (PP) - это этап обработки входного промпта, когда модель за один проход вычисляет представления для всех токенов запроса. Text Generation (TG) - последовательная генерация ответа, где каждый новый токен зависит от предыдущего. Единица измерения для обеих метрик - tokens per second (t/s).
На практике эти фазы влияют на разные аспекты пользовательского опыта. PP определяет задержку до появления первого токена ответа. TG - плавность, с которой текст выводится на экран. Для диалогового режима критичны оба параметра. Для пакетной обработки документов PP выходит на первый план, а TG может быть второстепенным.
Prefill (PP): почему важна скорость обработки промпта
Prefill становится узким местом, когда промпт содержит тысячи токенов. При анализе PDF на 50 страниц входной контекст легко достигает 10-15 тысяч токенов. С PP на уровне 150 t/s пользователь ждет 100 секунд до начала ответа - это провал по юзабилити. Целевой показатель в 300-350 t/s сокращает задержку до приемлемых 30-40 секунд для такого объема.
В сценариях кодинга с полным файлом проблема стоит острее. Разработчик отправляет в промпт несколько сотен строк кода, и задержка даже в 5 секунд ломает поток работы. PP ниже 300 t/s делает интерактивную работу с IDE-ассистентом мучительной. Спекулятивный декодинг частично решает проблему генерации, но на prefill он не влияет - здесь важна чистая вычислительная мощность и пропускная способность памяти.
Генерация текста (TG): комфортная скорость чтения и работы
TG ниже 9 t/s заставляет ждать появления текста. Средняя скорость чтения взрослого человека - 200-300 слов в минуту, что эквивалентно примерно 10-15 токенам в секунду для английского текста. При TG в 5-6 t/s модель выдает текст медленнее, чем вы читаете. Это ломает когнитивный поток: вы прочитали фрагмент, а продолжения еще нет.
Для кодинга порог в 9 t/s особенно заметен. Когда модель генерирует функцию из 50 токенов, разница между 5 t/s (10 секунд ожидания) и 12 t/s (4 секунды) - это грань между «работает» и «бесит». На форумах разработчиков в 2026 году консенсус такой: 9 t/s - минимально приемлемый уровень, 15+ t/s - комфортный, 25+ t/s - идеальный, когда генерация воспринимается мгновенной.
Пороговые значения от сообщества: 300-350 t/s PP и 9 t/s TG
Эти цифры - не теоретические выкладки, а эмпирический порог, ниже которого практики массово отказываются от локального инференса в пользу облачных API. Они сформировались из тысяч тестов на задачах, где важна интерактивность: IDE-ассистенты, RAG-системы с большими контекстами, построчная обработка документов.
При PP 200 t/s задержка на промпте из 2000 токенов составляет 10 секунд. В IDE это означает, что после нажатия Enter вы успеваете отвлечься на почту - и это при «мгновенном» автодополнении. Для анализа документов ситуация хуже: промпт из 8000 токенов обрабатывается 40 секунд. На таких задержках локальный запуск проигрывает даже самым дорогим облачным API по субъективной отзывчивости.
Кодинг: почему важны оба параметра
В сценарии автодополнения PP должен быть высоким, чтобы предложение появлялось до того, как разработчик начнет печатать следующий символ. Задержка свыше 500 мс воспринимается как тормоз. При промпте из 500 токенов это требует PP не ниже 1000 t/s - но это идеальный случай с коротким контекстом. В реальности промпт включает системные инструкции, схему инструментов и историю диалога, легко достигая 2000-3000 токенов. PP в 300-350 t/s дает задержку 6-10 секунд - уже на грани, но терпимо.
TG важен при генерации тела функции или блока кода. Медленный вывод заставляет ждать, пока модель «допечатает» решение. На практике 9 t/s означает, что функция из 100 токенов генерируется 11 секунд. Это приемлемо для обдумывания следующего шага, но не для потоковой работы. Конфигурации с гибридным запуском на CPU+GPU часто проваливаются именно по TG, даже если PP держится на приемлемом уровне.
Анализ документов: доминирование prefill
При подаче больших документов PP становится единственным узким местом. Ответ обычно краток - несколько предложений резюме или ответ на конкретный вопрос. TG здесь вторичен: даже 5 t/s дадут ответ за 2-3 секунды после того, как prefill завершен.
Проблема в том, что prefill для документа на 50 страниц (примерно 12 000 токенов) при PP 300 t/s занимает 40 секунд. Это психологически тяжело: пользователь отправил запрос и смотрит на пустой экран. Решения вроде персистентного SSD-кеширования KV сокращают эту задержку для повторных запросов с 143 секунд до 0.99 секунды на контекстах ~15 700 токенов. Для сценариев, где документ анализируется многократно, это меняет правила игры.
Компромиссы при оффлоадинге на CPU/GPU и квантовании моделей
Запуск большой модели на ограниченном VRAM требует компромиссов. Два основных инструмента - оффлоадинг части слоев на CPU и квантование весов. Оба снижают качество инференса, но по-разному влияют на PP и TG.
Влияние оффлоадинга на prefill и генерацию
При переносе слоев на CPU пропускная способность системной памяти становится узким местом. Типичная DDR5-5600 в двухканальном режиме дает около 70 ГБ/с - против 900+ ГБ/с у RTX 4090. PP страдает сильнее, потому что требует обработки всего промпта за один проход через все слои, включая те, что на CPU. TG менее чувствителен: он идет токен за токеном, и задержка CPU-слоев распределяется по времени.
Практический пример: Llama-3-70B с 30% слоев на CPU. PP падает с 500 до 150 t/s, TG - с 15 до 10 t/s. Для кодинга такая конфигурация уже непригодна: задержка prefill становится критичной. Для анализа документов в одиночном режиме - терпимо, если ответ не требуется мгновенно. Месячный мониторинг использования локальных моделей показывает, что пользователи переключаются на облака именно при падении PP ниже 200 t/s, даже если TG остается на уровне 12-15 t/s.
Квантование: компромисс между скоростью и интеллектом
4-битное квантование (GPTQ, AWQ) удваивает TG и на 30-50% поднимает PP за счет снижения требований к пропускной способности памяти. Модель помещается в VRAM меньшего объема, оффлоадинг не нужен. Но есть цена: падение точности на сложных рассуждениях.
Для кодинга 4-битное квантование рискованно. Модель начинает ошибаться в логике функций, путать синтаксис, галлюцинировать несуществующие API. Бенчмарк HumanEval для Qwen-2.5-32B падает с 85% до 72% при переходе с 8-бит на 4-бит. Для суммаризации документов падение менее заметно: MMLU снижается на 3-5 процентных пунктов, что для многих задач приемлемо. Выбор уровня квантования - это выбор между скоростью и интеллектом, и универсального ответа нет.
Почему старые критерии производительности устарели
До 2024 года сообщество ориентировалось на единственный показатель: TG выше 10 t/s. Этого хватало для диалоговых моделей с контекстом 4K-8K токенов. Prefill на таких объемах занимал доли секунды даже на среднем железе, и им пренебрегали.
Ситуация изменилась с появлением моделей с контекстом 128K+ и гибридных схем запуска. Когда промпт может содержать 50 000 токенов, prefill становится доминирующей задержкой. Квантованные модели добавили нелинейность: 4-битная модель может иметь PP выше, чем 8-битная на том же железе, но с заметно худшим качеством. Старый критерий «TG > 10 t/s» ничего не говорит о том, сколько вы будете ждать первого токена. Сейчас нужен сбалансированный подход: PP для отзывчивости, TG для плавности.
Практические рекомендации: как достичь целевых показателей
Достижение 300-350 t/s PP и 9 t/s TG требует правильного подбора железа под модель и задачу. Ориентиры для популярных конфигураций по состоянию на август 2026 года:
Рекомендации по GPU для популярных моделей
Для моделей уровня 7B-8B параметров (Llama-3, Qwen-2.5, Gemma-2) с 4-битным квантованием достаточно RTX 3060 12GB или RTX 4060 Ti 16GB. Типичные показатели: PP 400-500 t/s, TG 12-18 t/s. Без квантования (FP16) нужна RTX 3080 12GB или RTX 4070 12GB - PP 300-350 t/s, TG 9-12 t/s.
Для моделей 13B-20B с 4-битным квантованием минимальный порог - RTX 3080 12GB или RTX 4070 12GB. PP 250-350 t/s, TG 8-12 t/s. Для комфортной работы без компромиссов по PP лучше смотреть на RTX 4080 16GB или RTX 5070 16GB. Модели с большим контекстом (32K+) требуют дополнительного объема VRAM под KV-кеш: на каждые 10 000 токенов контекста уходит 2-4 ГБ VRAM для 8B-модели с 4-битным квантованием.
Для 70B-моделей одной потребительской карты недостаточно. Нужен либо оффлоадинг (с падением PP до 100-150 t/s), либо связка из двух GPU. Кластер из 16 AMD MI50 выдает 12-14 t/s на 436-гигабайтной GLM-5.2 - это другой класс задач, где TG в 12 t/s уже достижение.
Инструменты для измерения PP и TG
Базовый инструмент - встроенный бенчмарк llama.cpp. Запускается флагом --benchmark и выдает раздельные метрики для prefill и generation. Для vLLM метрики доступны через Prometheus-эндпоинт. Text-generation-webui показывает t/s в реальном времени в интерфейсе, но не разделяет PP и TG - для точных замеров лучше писать скрипт с замерами времени до первого токена и между токенами.
При интерпретации результатов важно смотреть не на пиковые значения, а на стабильные. Первый запуск после загрузки модели может показывать завышенные цифры из-за кеширования. Реальные показатели - после 5-10 итераций на промптах разной длины. Выбор бэкенда для инференса также влияет на метрики: vLLM с continuous batching дает лучшую утилизацию GPU, но для одиночных запросов разница с llama.cpp минимальна.
Заключение: баланс скорости, качества и стоимости
300-350 t/s PP и 9 t/s TG - это ориентир для комфортной интерактивной работы в 2026 году, а не жесткий стандарт. Если ваши задачи допускают пакетную обработку с задержкой в минуты, можно запускать 70B-модель с оффлоадингом и PP 100 t/s. Если критична стоимость, 4-битное квантование на бюджетной карте даст приемлемый опыт для диалогов, но подведет на сложном кодинге.
Главный вывод: измеряйте обе метрики под свою нагрузку. Синтетические бенчмарки на пустом промпте не показывают реальной картины. Тестируйте на типичных для вас объемах контекста и смотрите на PP и TG раздельно. Только так можно понять, достаточно ли вашего железа для комфортной работы или пора апгрейдиться.