Inference (вывод модели) — это этап после обучения, когда уже обученная модель получает новые входные данные и выдает результат: класс, число, вероятность, следующий токен или другой ответ. В инфраструктуре под inference обычно понимают эксплуатационный запуск модели внутри runtime или inference-сервера, который принимает запрос, выполняет вычисление и возвращает выход.
Если вы видите этот термин в документации ONNX Runtime, NVIDIA Triton Inference Server, TensorFlow Serving или managed endpoint, почти всегда речь идет именно о таком запуске модели на новых данных. Важно не путать общий термин inference с PyTorch inference mode: это уже специальный режим внутри PyTorch, а не синоним всей продакшен-инфраструктуры.
Английский термин: inference. Также встречается: model inference, scoring (так ONNX называет inference в контексте более ранних версий IR), «вывод модели», «инференс». Близкие, но не тождественные термины: training, serving, prediction, inference mode.
Простыми словами
Грубо говоря, обучение модели — это этап, когда вы «учите» систему на примерах, а inference — когда уже проверяете, что она ответит на новом случае. Можно представить это как калькулятор с уже заданными правилами: вы не меняете формулы внутри, а просто подаете новые числа и получаете результат.
Для пользователя inference обычно выглядит очень просто: вы отправили фото, текст или таблицу — получили ответ. Но внутри между этими двумя точками есть отдельный технический слой: формат модели, runtime, выбор CPU или GPU, API и сервер, который умеет обслуживать много запросов подряд.
Как это работает
В документации ONNX это хорошо видно по самой истории формата: версии IR до v6 покрывали только inference (или scoring), а поддержка training появилась начиная с IR v7. Это удобная граница: inference — не про изменение параметров модели, а про использование уже готовой модели для новых входов.
[входные данные]
↓
[приложение или клиент]
↓
[runtime / inference-сервер]
↓
[execution provider, CPU или GPU]
↓
[граф модели + сохранённые параметры]
↓
[выход модели]
↓
[ответ через библиотечный API, HTTP или gRPC]- Модель уже подготовлена. Inference начинается после обучения: модель сохранена в пригодном для исполнения виде.
- Запрос попадает в среду исполнения. Это может быть библиотечный runtime, например ONNX Runtime, или сервер вроде TensorFlow Serving и Triton, которые публикуют inference-endpoint по HTTP или gRPC.
- Среда исполнения выбирает, где считать. В ONNX Runtime данные проходят через
InferenceSession; для не-CPU сценариев, начиная с ONNX Runtime 1.10, execution provider нужно выбирать явно. ONNX при этом не навязывает конкретную реализацию runtime: сама спецификация формата runtime-agnostic. - Модель вычисляет выход. На вход подаются тензоры или совместимые объекты данных; в ONNX Runtime документация привязывает ввод и вывод к
OrtValue. - Результат возвращается вызывающей стороне. В managed-сервисах это может называться онлайн-предсказанием: например, Vertex AI online predictions описывает такой вызов как синхронный запрос к развернутому endpoint.
Отдельный частный случай — PyTorch inference mode. По заметкам PyTorch Autograd, это «экстремальная» версия no-grad: она не записывает backward-граф, но тензоры, созданные в этом режиме, имеют ограничения на дальнейшее использование. Поэтому inference mode — это полезный инструмент оптимизации внутри PyTorch-кода, но не полное определение термина inference в инфраструктурном смысле.
Где применяется
- Локальный или встраиваемый запуск моделей через runtime. ONNX Runtime нужен там, где вы хотите исполнять ONNX-модель в приложении или сервисе и управлять execution provider в зависимости от CPU/GPU-сценария.
- Сетевой serving TensorFlow-моделей. TensorFlow Serving позиционируется как гибкая и высокопроизводительная serving-система для ML-моделей и публикует inference-endpoint по HTTP и gRPC.
- Мультифреймворк-сервер для продакшена. NVIDIA Triton Inference Server предоставляет HTTP- или gRPC-endpoint и поддерживает несколько фреймворков и backend-ов, включая TensorRT, PyTorch, ONNX, OpenVINO, Python и RAPIDS FIL.
- Управляемые облачные endpoint. В Vertex AI online predictions inference оформлен как синхронный запрос к развернутой модели. Но для варианта Google Distributed Cloud air-gapped документация отдельно помечает функцию как Preview и указывает отсутствие SLA и обязательств по техподдержке.
- PyTorch-сервисы в существующих стеках. TorchServe описан как инструмент для serving и масштабирования PyTorch-моделей в production и предоставляет inference API для развернутых моделей.
Если смотреть на видимые страницы релизов как на снимок на 2026-08-16, там показаны ONNX Runtime 1.26.0, Triton Inference Server 2.68.0, TensorFlow Serving 2.19.1 и TorchServe v0.12.0. Это полезный ориентир, но не постоянная истина: такие страницы меняются, поэтому перед внедрением версии нужно перепроверять.
Для LLM-практики вам также могут пригодиться материалы: Как развернуть vLLM для быстрого inference, vLLM vs TGI (Hugging Face): что выбрать для inference и 6 лучших inference-серверов для локальных моделей.
Практический пример
Ниже — упрощенный сценарий для ONNX Runtime. Это не готовый copy-paste под любую модель: имена входов, формы тензоров и доступные execution provider зависят от вашего графа и окружения. Но по механике это и есть inference в чистом виде.
# Упрощённая схема на Python с ONNX Runtime
# Имена входов/выходов зависят от вашей модели.
import onnxruntime as ort
# Для CPU-only сценария provider можно не указывать.
# Для не-CPU сценария его выбирают явно.
session = ort.InferenceSession(
"model.onnx",
providers=["CUDAExecutionProvider"]
)
# Дальше приложение готовит входные данные в формате,
# который понимает модель и runtime (в документации ONNX Runtime
# ввод/вывод привязан к OrtValue), запускает inference
# и получает выход модели.
# На этом этапе параметры модели не обучаются заново:
# вы только исполняете уже готовый граф на новых данных.- Приложение создает
InferenceSessionдля готовой модели. - Если запуск не CPU-only, задается execution provider.
- Вход приводится к ожидаемому формату данных.
- Runtime исполняет граф и возвращает выход.
- Если поверх этого поставить серверный слой, тот же inference станет сетевым API для других приложений.
Практическое правило простое: пока вы только получаете ответ модели на новый запрос, это inference. Как только вокруг него появляются endpoint, маршрутизация, версии модели и обслуживание трафика, вы переходите в зону serving.
Чем отличается от…
| Термин | Что означает | Чем отличается от inference |
|---|---|---|
| Training | Этап обучения модели с поддержкой соответствующих механизмов. | Inference использует уже обученную модель на новых данных. ONNX прямо отделяет эти понятия: IR до v6 был про inference/scoring, а training добавлен с IR v7. |
| Serving | Инфраструктурная обвязка, которая делает модель доступной по API, версии и трафику. | Serving — это способ доставить inference пользователю или сервису. TensorFlow Serving и Triton публикуют HTTP/gRPC-endpoint, но сами по себе являются не «синонимом вывода», а системой его доставки. |
| PyTorch inference mode | Специальный режим PyTorch для вычислений без записи backward-графа. | Это частный библиотечный режим. Общий термин inference шире и описывает сам запуск модели в любом runtime или сервере, а не только внутри PyTorch. |
| Prediction / online prediction | Конкретный запрос за ответом модели. | Во многих сервисах prediction — это единичный вызов inference. Например, Vertex AI описывает online predictions как синхронные запросы к развернутому endpoint. |
Ограничения и заблуждения
- Заблуждение: inference = serving. Нет. Вы можете делать inference локально библиотечным вызовом вообще без сервера. Serving нужен, когда этот запуск надо оформить как сервис.
- Заблуждение: inference автоматически означает ускорение. Формат ONNX сам по себе не обещает конкретный метод исполнения: спецификация ONNX не предполагает определённый runtime. Скорость зависит от runtime, execution provider, железа и конкретной модели.
- Заблуждение: в inference модель продолжает учиться. В общем случае нет. Это постобучающий этап использования модели на новых данных.
- Заблуждение: PyTorch inference mode и есть весь inference. Нет. Это только один из режимов PyTorch, причём с ограничениями на использование созданных там тензоров.
- Ограничение managed-сервисов: свойства продукта зависят от варианта развертывания. В исходниках для GDC air-gapped online predictions прямо указаны Preview-статус, отсутствие SLA и обязательств по техподдержке.
- Ограничение выбора инструмента: статус релизов и поддержки меняется. Особенно для TorchServe стоит перепроверять репозиторий перед новым внедрением, а версии из этой статьи воспринимать как снимок на дату источников.
Редакционная оговорка и практический вердикт: этот материал объясняет термин, а не сравнивает производительность, стоимость или регионы облаков — в исходном пакете нет бенчмарков и цен, а такие данные быстро устаревают. Если вам нужна короткая формула для практики, держите её так: inference — это запуск готовой модели на новых данных; serving — это инфраструктура, которая делает этот запуск доступным извне.
Связанные материалы
- Transfer learning (перенос обучения) — чтобы не путать вывод модели с дообучением и переносом обучения.
- Как развернуть vLLM для быстрого inference — практический сценарий для LLM-сервинга.
- vLLM vs TGI (Hugging Face): что выбрать для inference — сравнение двух стеков для выдачи модели по API.
- llama.cpp — inference-движок для локального запуска LLM — пример локального runtime для вывода модели без облачного endpoint.
Источники
- ONNX IR Specification
- ONNX Runtime Python API Summary
- PyTorch Autograd Notes
- GitHub – tensorflow/serving: A flexible, high-performance serving system for machine learning models
- Releases · tensorflow/serving · GitHub
- GitHub – pytorch/serve: Serve, optimize and scale PyTorch models in production
- Releases · pytorch/serve · GitHub
- NVIDIA Triton Inference Server User Guide
- Releases · triton-inference-server/server · GitHub
- Learn about online predictions | Google Distributed Cloud air-gapped | Google Cloud Documentation
Вопросы и ответы
Inference и prediction — это одно и то же?
Не всегда. На практике prediction часто означает конкретный ответ модели на один запрос, а inference — весь процесс исполнения модели на новых данных. В managed-документации это видно на примере Vertex AI online predictions, где prediction описан как синхронный запрос к endpoint.
Чем inference отличается от serving?
Inference — это само вычисление ответа моделью. Serving — это инфраструктура вокруг этого вычисления: endpoint, протоколы HTTP/gRPC, версии модели и обслуживание запросов.
Нужно ли выбирать execution provider в ONNX Runtime?
Для CPU-only сценария это не обязательно. Начиная с ONNX Runtime 1.10, для не-CPU запуска execution provider нужно выбирать явно.
PyTorch inference mode — это просто no-grad?
Нет. По документации PyTorch, inference mode — более «жёсткий» режим, чем no-grad: он не записывает backward-граф, но накладывает ограничения на тензоры, созданные внутри него.
Можно ли по одному слову inference понять, какой именно сервер нужен?
Нет. Сам термин говорит о фазе исполнения модели, а не о конкретном продукте. Для выбора сервера вам всё равно придется отдельно решать, нужен ли вам ONNX Runtime, Triton, TensorFlow Serving, TorchServe или managed endpoint.