Inference

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

Коротко

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

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

Что называют инференсом

Модель во время обучения настраивает параметры на примерах. После этого её сохраняют и используют на данных, которых не было в конкретном обучающем шаге. Такое применение и называют inference.

Входом может быть текст, изображение, звук, таблица или набор признаков. Выход тоже бывает разным:

• вероятность классов;
• число или прогноз;
• эмбеддинг;
• маска сегментации;
• следующий токен текста;
• шум, скорость или другое промежуточное предсказание генеративной модели.

Пользователь обычно видит не сырой тензор, а результат всей цепочки. Между кнопкой «Отправить» и ответом помещаются токенизация, изменение размера изображения, очередь сервера, вычисление модели, sampling и постобработка. В разговоре всё это нередко называют одним словом «инференс», хотя сам forward pass является лишь центральной частью.

Из чего состоит запрос

У самой общей схемы четыре части.

1. Подготовка входа. Текст превращается в токены, изображение — в тензор нужного размера, звук — в отсчёты или признаки. Входы объединяются в batch, если движок обрабатывает несколько примеров вместе.
2. Проход модели. Слои последовательно вычисляют активации, используя сохранённые веса. Для одного входа может понадобиться один проход или серия повторяющихся проходов.
3. Выбор и сборка результата. Классификатор выбирает метку, языковая модель — следующий токен, диффузионный pipeline — обновлённое скрытое представление.
4. Постобработка. Токены превращаются в строку, координаты — в рамки, latent — в пиксели, а ответ получает нужный формат.

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

Почему LLM отвечает постепенно

Автогрессивная языковая модель предсказывает продолжение по уже видимому тексту. Её запрос обычно делится на две фазы.

Prefill

Сначала модель обрабатывает весь вход: системные инструкции, историю, документы и пользовательский вопрос. На этом этапе формируется KV-кэш — сохранённые key и value из attention-слоёв. Длинный вход увеличивает объём этой работы и часто сильнее влияет на время до первого токена.

Decode

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

Sampling определяет, как из распределения вероятностей выбирается продолжение. Жадный выбор берёт наиболее вероятный вариант, а stochastic sampling использует temperature, top-p и другие ограничения. Это часть процедуры генерации, а не изменение весов.

У других моделей цикл иной

Классификатор изображения обычно получает подготовленный тензор и выдаёт оценки классов за один forward pass. Детектор добавляет декодирование координат и фильтрацию пересекающихся рамок. Модель эмбеддингов превращает вход в вектор, который затем сравнивает уже другое приложение.

Диффузионная генерация начинает со случайного или частично зашумлённого представления и несколько раз вызывает модель по расписанию sampler. Каждый шаг уточняет представление; после последнего шага декодер может перевести latent в пиксели. Число вызовов зависит от архитектуры и выбранного метода, поэтому фиксированное правило вроде «у любой диффузии несколько десятков проходов» быстро становится неверным.

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

Что остаётся неизменным

В обычном inference-запросе optimizer не делает шаг и параметры модели не обновляются. Это не означает, что вокруг модели ничего не меняется.

• KV-кэш и активации создаются для текущей последовательности.
• Приложение может записать историю диалога, пользовательские настройки или найденные документы.
• RAG и инструменты добавляют свежие данные в следующий вход.
• Сервер может динамически объединять запросы в batch и переносить кэши между уровнями памяти.
• Stateful-модель может обновлять предусмотренное архитектурой состояние, не обучая веса.

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

___NSLPROTECT10___ и отключение градиентов — не одно и то же

Во фреймворках режим поведения слоёв и работа автоматического дифференцирования управляются отдельно. В PyTorch model.eval() переключает, например, Dropout и BatchNorm в evaluation-поведение, но сам по себе не отключает вычисление градиентов. torch.inference_mode() убирает autograd и дополнительный служебный overhead, но не вызывает eval() автоматически.

Типичная форма выглядит так:

model.eval()

with torch.inference_mode():
    output = model(batch)

Это деталь реализации, а не определение инференса. Другие runtimes могут заранее оптимизировать граф, объединять операции и вообще не включать training-механику в исполняемый пакет.

Из чего складывается задержка

Время модели — только один участок пути. Полная задержка может включать:

• загрузку модели и прогрев kernels;
• подготовку входа;
• сеть и очередь;
• prefill или основной forward pass;
• decode либо другой повторяющийся цикл;
• постобработку и передачу результата клиенту.

На вычислительную часть влияют размер и архитектура модели, длины последовательностей, batch, dtype, kernels, скорость памяти и распределение по устройствам. Больший batch часто повышает общую производительность системы, но отдельный запрос может ждать дольше. Дополнительная RAM или VRAM помогает вместить веса и кэши; ускорение появляется только тогда, когда меняется реальное узкое место.

Как измеряют LLM-инференс

Одна цифра «токенов в секунду» редко описывает пользовательский опыт целиком. Обычно разделяют несколько метрик.

• TTFT, time to first token — время от отправки запроса до первого содержательного токена. В него могут входить очередь, сеть и prefill.
• ITL, inter-token latency, или TPOT, time per output token — пауза между последующими токенами. Методики иногда считают её немного по-разному.
• End-to-end latency — время до полного ответа.
• Throughput — сколько запросов или токенов обслуживает вся система за интервал.
• Память — веса, временные буферы, активации, KV-кэш и overhead runtime.

Для честного сравнения вместе с метриками указывают длины входа и выхода, concurrency, batch, формат весов, устройство, runtime и наличие прогрева. Без этих условий результаты разных стендов плохо сопоставимы.

Пример без привязки к сервису

Допустим, редактор отправляет расшифровку интервью и просит короткое резюме.

1. Приложение добавляет системную инструкцию и превращает весь текст в токены.
2. Запрос ждёт свободного слота или сразу попадает в batch.
3. Во время prefill модель обрабатывает инструкцию и интервью, создавая KV-кэш.
4. Decode добавляет резюме токен за токеном; streaming сразу передаёт готовые фрагменты интерфейсу.
5. Клиент собирает строку и показывает ответ.

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

С чем часто путают

• Inference и training. Training меняет параметры по ошибке и градиентам; обычный inference применяет сохранённые параметры.
• Inference и forward pass. Forward pass — вычисление модели один раз. Полный запрос может добавить preprocessing, sampling, кэш, цикл и postprocessing.
• Inference и API-запрос. API является способом обратиться к сервису. Само вычисление может происходить удалённо, локально или внутри приложения.
• Inference и serving. Serving охватывает загрузку моделей, очереди, batching, маршрутизацию, масштабирование и наблюдаемость вокруг инференса.
• Inference и prediction. В классическом ML слова часто взаимозаменяемы; inference шире подчёркивает процедуру применения модели.
• Контекст и память модели. История, RAG-хранилище и профиль пользователя могут принадлежать приложению, а не весам модели.

Частые заблуждения

«Инференс всегда детерминирован»

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

«GPU всегда быстрее CPU»

Это зависит от модели, batch, доступных kernels, подготовки данных и стоимости передачи между памятью устройств. Небольшая модель или короткий запрос иногда быстрее и проще исполняются на CPU; крупные матричные задачи чаще выигрывают от подходящего ускорителя.

«Batch ускоряет каждый запрос»

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

«Streaming ускоряет модель»

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

«Квантизация всегда делает инференс быстрее»

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

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

Где может выполняться inference?

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

Почему первый запрос иногда медленнее следующих?

В начале могут загружаться веса, компилироваться графы, подбираться kernels и заполняться кэши. Это называют cold start и warm-up. Отдельно существует TTFT каждого запроса — его не стоит смешивать со стартом всего процесса.

KV-кэш хранит весь разговор?

Он хранит внутренние key/value-представления для токенов, которые участвуют в текущем вычислении или переиспользуемом префиксе. Это не долговременная память о пользователе. Когда кэш удалён, историю при необходимости снова подают текстом или другим входом.

Почему длинный вопрос может замедлить появление ответа?

Prefill должен обработать вход и построить кэш. Чем больше токенов видит модель, тем больше данных проходит через слои и attention. Точный рост зависит от архитектуры и оптимизаций.

Что расходует память кроме весов?

Входы, активации, рабочие буферы kernels, runtime, KV-кэш, batch и промежуточные результаты других моделей pipeline. Поэтому размер файла с весами не равен требуемой памяти процесса.

Главное

Inference — не волшебная кнопка и не один универсальный forward pass. Это применение готовой модели внутри цепочки: подготовка входа, вычисление, возможный цикл генерации и постобработка. Веса обычно остаются прежними, а временное состояние и контекст живут вокруг них.

Для языковых моделей особенно важны две разные фазы: prefill обрабатывает вход, decode строит продолжение по токену. Пользовательскую отзывчивость описывают TTFT и ITL, полное ожидание — end-to-end latency, а способность системы выдерживать поток — throughput. Эти метрики получают смысл только вместе с условиями измерения.

Источники

• PyTorch: inference_mode
• PyTorch: Module.eval
• Hugging Face Transformers: Caching
• Hugging Face Transformers: Cache strategies
• NVIDIA NIM Benchmarking: Overview
• NVIDIA NIM Benchmarking: Metrics
• NVIDIA NIM Benchmarking: Parameters and best practices
• ONNX Runtime: Graph optimizations
• Denoising Diffusion Probabilistic Models