Ускорять инференс LLM нужно в таком порядке: измерить, где уходит время, сократить лишнее (контекст, ответ, повторные вычисления), затем включить пакетирование запросов и кэш, затем квантизацию, и только после этого менять модель или покупать оборудование. Порядок важен: самые дешёвые меры чаще всего дают самый заметный выигрыш, а самые громкие, вроде перехода на другую карту, дороже и не всегда решают задачу.
Статья о том, как добиться нужной скорости на своём сервере. Сколько памяти нужно под модель, описано в статье «Сколько видеопамяти нужно для своей языковой модели», а услуга — на странице «Оптимизация инференса LLM».
Что значит «медленно»: три метрики вместо одного ощущения
Жалоба «модель тормозит» объединяет три разные проблемы. Прежде чем что-либо менять, измерьте каждую отдельно, на потоке, похожем на реальный: с вашими запросами, вашей длиной контекста и числом одновременных пользователей.
| Метрика | Что показывает | Когда болит | Что на неё влияет |
|---|---|---|---|
| Время до первого токена | Сколько пользователь ждёт, пока появится начало ответа | Интерактивный чат, голосовой ассистент, длинные запросы с документами | Длина входа, очередь, загрузка видеокарты, кэш префикса |
| Скорость генерации | Сколько токенов в секунду видит один пользователь после начала ответа | Длинные ответы, потоковый вывод, генерация текстов | Размер модели, точность хранения весов, пропускная способность памяти |
| Пропускная способность | Сколько запросов в единицу времени обслуживает сервер | Много пользователей, пакетная обработка документов, нагрузка по расписанию | Пакетирование, объём памяти под кэш, число карт |
| Хвост задержки | Время ответа в худших случаях, а не в среднем | Рабочие часы, когда запросы приходят одновременно | Очередь, длинные запросы, которые блокируют короткие |
Среднее значение скрывает проблему. Если десять сотрудников открыли отчёты в один момент, среднее время может быть приемлемым, а у последнего в очереди ответ придёт через минуту. Смотрите распределение, а не одну цифру. Для чата важно первое, для пакетной обработки документов — третье, для голосового ассистента — первое и хвост. Выбранная метрика определяет, какие меры дадут пользу, а какие потратят время зря. Устройство самого приложения описано в статье «Архитектура LLM-приложения».
Почему модель медленная: два этапа с разными узкими местами
Ответ языковой модели состоит из двух этапов. Сначала модель обрабатывает весь входной текст целиком: это этап чтения, он упирается в вычислительную мощность карты. Затем она выдаёт ответ по одному токену, и на каждом шаге ей нужно прочитать из памяти все веса: этот этап упирается в скорость памяти карты.
Отсюда практические следствия:
- Длинный входной текст замедляет начало ответа. Сократить вход быстрее и дешевле, чем покупать карту мощнее.
- Скорость генерации зависит от размера весов в памяти. Уменьшить веса (квантизация, меньшая модель) ускоряет генерацию.
- Один пользователь не загружает карту: на этапе генерации она ждёт память. Объединение запросов нескольких пользователей почти ничего не добавляет к времени чтения весов, поэтому пакетирование так сильно увеличивает пропускную способность.
- Длинный контекст увеличивает объём кэша, в котором модель хранит прочитанное. Он конкурирует за память с числом одновременных диалогов.
Это упрощённая картина, но она объясняет, почему совет «купите карту помощнее» часто неверен: для генерации важнее пропускная способность памяти и объём, а не только вычислительная мощность.
Начинаем с дешёвого: контекст, ответ и повторные вычисления
До любого технического ускорения проверьте, не просит ли приложение у модели лишнего. Это самые дешёвые меры, и они не меняют качество модели.
| Мера | Что делаем | Чем рискуем | Как проверяем |
|---|---|---|---|
| Сократить контекст | Передавать только нужные фрагменты, а не весь документ; убрать повторы и служебные пояснения из системной инструкции | Потеряем фрагмент с ответом | Набор контрольных вопросов до и после, отдельно доля найденных нужных фрагментов |
| Ограничить длину ответа | Задать максимальное число токенов и просить краткий формат (список, таблица, одно предложение) | Оборвётся полезное продолжение | Читаем выборку ответов, где лимит сработал |
| Структурированный ответ | Просить JSON с короткими полями вместо рассуждений, когда ответ нужен программе | Теряется объяснение | Сохраняем объяснение только там, где его читает человек |
| Не вызывать модель без нужды | Типовые вопросы и справочные поля обрабатывать правилом или поиском | Правило устареет | Журнал: доля запросов, обслуженных без модели, и жалобы на них |
| Меньше фрагментов из поиска | Брать меньше найденных фрагментов и сортировать по релевантности | Нужный фрагмент окажется дальше порога | Измеряем, попадает ли нужный фрагмент в выдачу |
Контекст в приложениях с поиском по документам часто сильно раздут: в запрос попадают лишние фрагменты «на всякий случай». Каждый лишний фрагмент замедляет начало ответа и занимает память под кэш. Как устроен поиск и как его настраивать, разобрано в статье «Что такое RAG».
Пакетирование запросов: то, что обычно даёт больше всего
Если на сервере модель обслуживает пользователей по одному, видеокарта большую часть времени простаивает в ожидании памяти. Современные движки запуска объединяют запросы разных пользователей в общую пачку и принимают новые запросы по мере освобождения места, не дожидаясь, пока закончатся все текущие. Это называется непрерывным пакетированием. Оно заметно увеличивает пропускную способность без потери качества, потому что ответы не меняются, меняется порядок вычислений.
Что нужно учесть:
- Выбор движка. Для серверного запуска обычно смотрят vLLM, TGI, SGLang и TensorRT-LLM; для небольшой нагрузки и простой установки — llama.cpp. Выбор зависит от модели, оборудования и требований к закрытому контуру, поэтому его делают по тесту на вашем стенде, а не по обзору.
- Лимит размера пачки. Чем больше пачка, тем выше пропускная способность и тем длиннее ожидание каждого. Предел определяется желаемой задержкой.
- Приоритеты и очередь. Короткие интерактивные запросы нельзя ставить в одну очередь с пакетной обработкой отчётов. Разделяйте их либо по приоритетам, либо по отдельным экземплярам.
- Память под кэш. Размер пачки ограничен тем, сколько памяти осталось после весов. Это объясняет, почему квантизация увеличивает число одновременных пользователей, а не только скорость.
Типичный сценарий: сервер обслуживал одного сотрудника нормально, а на двадцати упал. Причина в простое карты: запросы шли последовательно. Движок с непрерывным пакетированием обычно исправляет это без смены оборудования.
Квантизация: меньше память, больше скорость и цена в качестве
Квантизация хранит веса модели с меньшей точностью: вместо двух байт на параметр одного или половины. Это уменьшает память под веса, ускоряет генерацию (читать нужно меньше) и освобождает место под кэш. Платой становится потеря точности: чем сильнее сжатие, тем выше риск, что модель хуже справится с вашими задачами. Поэтому квантизацию принимают не по паспорту модели, а по результату на вашей выборке.
| Подход | Что даёт | Цена | Когда выбирать |
|---|---|---|---|
| Полуточность без сжатия | Эталонное качество, нет рисков потери | Больше всего памяти, ниже скорость генерации | Памяти достаточно, нагрузка небольшая, ошибка очень дорога |
| Восьмибитное сжатие | Вдвое меньше памяти под веса по сравнению с полуточностью, заметное ускорение генерации | Небольшая потеря качества, чаще незаметная на типовых задачах | Обычный первый шаг: хороший баланс |
| Четырёхбитное сжатие | Ещё вдвое меньше памяти, позволяет запустить более крупную модель на той же карте | Заметнее потери на сложных рассуждениях, коде, редких языках и длинных цепочках | Памяти не хватает; после проверки на выборке |
| Сжатие кэша контекста | Больше одновременных диалогов или более длинный контекст на той же карте | Возможна потеря деталей в конце длинного контекста | Много пользователей или длинные документы |
Проверка квантизации проста и обязательна: берётся набор контрольных вопросов из вашей работы, прогоняются обе версии, ответы сравниваются по доле верных. Общие тесты моделей показывают среднюю потерю, но не покажут, что именно ваша задача (извлечение полей, названия на русском языке, нормативные ссылки) пострадает сильнее. Если потеря больше допустимой, помогает смешанный вариант: основные слои в восьмибитном виде, чувствительные в более точном. Как это связано с затратами на оборудование, описано в статье про видеопамять.
Кэш: что можно не считать повторно
Под словом «кэш» в LLM-приложениях скрываются четыре разные вещи, и применять их нужно по-разному.
- Кэш ключей и значений (KV-кэш). Внутренний механизм: модель помнит уже прочитанное и не пересчитывает его на каждом токене. Включён всегда, а вот его размер определяет число одновременных диалогов.
- Кэш префикса. Если у всех запросов одинаковое начало (системная инструкция, справочник, формат ответа), его можно обработать один раз и переиспользовать. Это сокращает время до первого токена. Требование: общая часть стоит в начале запроса и не меняется между запросами, в том числе в мелочах вроде даты.
- Кэш ответов. Точное совпадение вопроса возвращает сохранённый ответ без вызова модели. Подходит для справочных и повторяющихся вопросов. Опасность: ответ устаревает, а доступ к нему должен подчиняться тем же правам, что и исходные данные.
- Смысловой кэш. Похожий вопрос получает ответ на ранее заданный. Рискованный вариант: два вопроса, различающиеся одной деталью (дата, номер договора, подразделение), получат один ответ. Применяйте только там, где цена такой ошибки мала, и проверяйте порог схожести на выборке.
Кэшируются и промежуточные результаты приложения: векторы документов, результаты поиска по неизменным запросам, распознанный текст файлов. Они не относятся к самой модели, но нередко дают больше выигрыша, чем её настройка, потому что на поиск и разбор документов уходит заметная часть времени ответа.
Модель поменьше, каскад и черновик: когда меняем саму модель
Если дешёвые меры исчерпаны, есть три способа изменить саму схему.
| Способ | Как работает | Выигрыш | Риск |
|---|---|---|---|
| Модель меньшего размера | Задачу решает модель поменьше, возможно, дообученная или с хорошим промптом | Быстрее и дешевле на каждом запросе, меньше памяти | Хуже справляется со сложными вопросами; проверка на выборке обязательна |
| Каскад моделей | Простые запросы обрабатывает малая модель, сложные уходят на крупную по правилу или по оценке уверенности | Средняя задержка и нагрузка падают, потому что большинство запросов простые | Ошибка маршрутизации отправит сложный вопрос малой модели; нужен контроль |
| Черновик и проверка (спекулятивное декодирование) | Малая модель предлагает несколько токенов вперёд, крупная проверяет их разом | Ускорение генерации без изменения ответов крупной модели | Выигрыш зависит от задачи; добавляет сложность в движок и память |
| Дообучение под узкую задачу | Модель поменьше дообучается на ваших примерах и решает одну задачу | Качество на задаче при малом размере | Нужны размеченные данные и оценка; не заменяет поиск по базе знаний |
Прежде чем дообучать, проверьте, не хватит ли поиска по документам и хорошего промпта. Выбор описан в статье «RAG или дообучение LLM». А вопрос «своя модель или внешний интерфейс» разобран в статье «Своя LLM или ChatGPT API»: для данных ограниченного доступа внешние модели чаще не подходят по требованиям заказчика, и скорость приходится получать на своём оборудовании.
Оборудование и порядок действий
Оборудование — последний шаг, а не первый. Если после всех мер скорости не хватает, нужно понять, чего именно: памяти, мощности или числа карт. Модель, которая не помещается в память одной карты, делится между несколькими; это работает, но между картами идёт обмен данными, и скорость зависит от их соединения. Для интерактивной нагрузки несколько хорошо соединённых карт даёт иное поведение, чем несколько слабо соединённых, поэтому схему проверяют на стенде до закупки. Цены на оборудование мы не называем: они меняются, и расчёт делается под вашу конфигурацию.
Рабочий порядок:
- Зафиксировать набор запросов, который похож на реальную нагрузку, и набор контрольных вопросов для качества.
- Измерить три метрики: время до первого токена, скорость генерации, пропускную способность, а также хвост задержки.
- Сократить контекст и длину ответа; повторить измерение.
- Включить движок с непрерывным пакетированием и кэшем префикса; настроить размер пачки и очереди.
- Попробовать восьмибитное сжатие, сравнить качество на контрольных вопросах.
- Если нужно, проверить четырёхбитное сжатие, кэш ответов, малую модель или каскад.
- Только затем решать вопрос с оборудованием; цель формулировать по метрике, например «первый токен в пределах заданного времени при заданном числе одновременных пользователей».
После каждого шага качество сравнивается с исходным. Ускорение, которое снизило долю верных ответов ниже допустимой, не считается ускорением. Практика запуска и мониторинга моделей описана в статье «Как развернуть LLM в закрытом контуре», а возможности и ограничения оборудования — на странице «Развернуть LLM на своём сервере».
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за одну систему, 350 000 ₽ и 3–4 недели, если приложений и моделей несколько. На выходе документ с измеренными метриками на вашей нагрузке, перечнем мер по порядку, ожидаемым эффектом каждой, оценкой потери качества на ваших контрольных вопросах и вилкой бюджета, включая вопрос об оборудовании. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше, если нужно, лёгкий пилот (150 000–400 000 ₽ за 2–8 недель) на одном приложении; на любой ступени можно остановиться. Мы настраиваем запуск в вашем контуре, передаём исходники и инструкции, но не продаём оборудование, не дежурим круглосуточно и не обещаем заранее выигрыш в разы: он зависит от вашей нагрузки. Описание услуги — на странице «Оптимизация инференса LLM», приложения на моделях — на странице «Разработка LLM-приложений», все цены — на странице «Тарифы».
Частые вопросы
С чего начать ускорение инференса LLM?
С измерения. Разделите «медленно» на время до первого токена, скорость генерации и пропускную способность на нагрузке, похожей на реальную. Затем сократите контекст и длину ответа, включите пакетирование и кэш, и только после этого проверяйте квантизацию.
Что быстрее даёт эффект: квантизация или пакетирование?
Если пользователей несколько, обычно пакетирование: оно увеличивает пропускную способность без потери качества. Квантизация ускоряет генерацию и освобождает память, но требует проверки качества на вашей выборке.
Снижает ли квантизация качество ответов?
Может. Восьмибитное сжатие чаще почти не заметно, четырёхбитное сильнее затрагивает сложные рассуждения, код и редкие языки. Универсального ответа нет, поэтому сравнение делают на контрольных вопросах из вашей работы.
Нужна ли карта мощнее, чтобы модель отвечала быстрее?
Не всегда. Генерация упирается в скорость и объём памяти, а долгое начало ответа часто связано с длинным контекстом. Сначала проверяют контекст, пакетирование и сжатие, и только затем оборудование.
Можно ли кэшировать ответы модели?
Можно для повторяющихся справочных вопросов, если ответ не устаревает и права доступа к нему такие же, как у исходных данных. Смысловой кэш рискован: вопросы, различающиеся одной деталью, могут получить один ответ.
Стоит ли брать модель поменьше?
Если качество на ваших вопросах остаётся приемлемым, да: она быстрее и требует меньше памяти. Проверка на выборке обязательна, а сложные запросы можно направлять на крупную модель по правилу или оценке уверенности.
Работает ли всё это в закрытом контуре?
Да. Движок запуска, кэш и мониторинг ставятся на ваши серверы, внешних сервисов не требуется. Данные не покидают контур, а версии модели и движка фиксируются вами.
Сколько стоит ускорение инференса?
Начинаем с обследования за 200 000 ₽ (350 000 ₽ при нескольких системах), оно вычитается из первого этапа. Лёгкий пилот стоит 150 000–400 000 ₽ за 2–8 недель. Цены на оборудование мы не называем: расчёт делается под вашу нагрузку.