Инференс — вторая половина жизни любой нейросети. Первая половина происходит в лаборатории: модель обучают на данных и получают файл весов. Всё, что дальше, — инференс: веса загружены на сервер, входящий запрос превращается в токены, модель прогоняет его через свои слои и выдаёт ответ. Слова «обучили модель» и «модель работает» описывают два разных процесса с разными бюджетами, и путаница между ними — одна из самых дорогих ошибок при планировании ИИ-проекта.
Различие принципиально для экономики. Обучение — разовая или редкая операция, требующая мощных ускорителей и больших данных. Инференс — ежедневная: пока ассистент отвечает клиентам, инференс идёт круглосуточно, и его счёт растёт с каждым запросом. У облачных провайдеров оплата чаще всего привязана именно к токенам на входе и выходе — то есть к инференсу. Поэтому решение «какая модель, где она стоит и как быстро отвечает» — это в первую очередь решение об инференсе.
Что происходит при инференсе: шаг за шагом
Проследим типичный путь запроса к корпоративному ассистенту:
- 1. Приём запроса. Приложение передаёт вопрос пользователя и служебный контекст на сервис модели.
- 2. Токенизация. Текст разбирается на токены — куски слов, которыми оперирует модель. От числа токенов зависит и цена, и время ответа; как именно это устроено, разобрано в статье токенизация.
- 3. Сборка контекста. К запросу присоединяются системная инструкция, история диалога и найденные фрагменты базы знаний. Всё это вместе занимает контекстное окно модели — и тоже оплачивается.
- 4. Прямой проход. Модель вычисляет распределение вероятностей следующего токена и выбирает его; цикл повторяется, пока ответ не завершится. Управляет «осторожностью» выбора параметр, разобранный в статье температура LLM.
- 5. Постобработка. Ответ проверяется фильтрами guardrails, при необходимости оформляется как структурированные данные и возвращается приложению.
Три рабочие характеристики инференса
Латентность — время от запроса до первого полезного знака ответа. Для голосового робота критичны сотни миллисекунд, для отчёта за ночь — не важно; подробно этот разрыв разобран в статье латентность инференса.
Пропускная способность — сколько запросов сервис обрабатывает в единицу времени. Одно и то же железо даёт разную пропускную способность в зависимости от размера модели, длины контекста и утилизации; повышение загрузки без деградации времени ответа — отдельная инженерная дисциплина.
Стоимость — в облаке это тариф за токены, на своём сервере — амортизация ускорителей, электричество и сопровождение. Снизить её позволяют квантизация (компактное представление весов) и промпт-кэширование (повторное использование обработанной неизменной части запроса).
Где выполнять инференс: облако или свой контур
Облачный API — быстрый старт без капитальных затрат, но данные уходят к провайдеру, а счёт линейно растёт с трафиком. Собственный сервер с on-premise LLM — данные остаются в контуре компании, стоимость предсказуема, но требуется выбор и обслуживание ускорителей: под эти задачи существует отдельный класс оборудования, разобранный в статье GPU для ИИ. Промежуточный вариант — открытые модели у российского хостера. Критерий выбора не «модно», а три числа: пиковый трафик, требования к конфиденциальности и горизонт планирования.
Отдельный режим — батч-инференс: ночные пакетные прогонки, когда время ответа не важно, а важна цена. Разумное сочетание режимов — интерактивный инференс днём и пакетная обработка накопившихся задач по ночам — снижает счёт без потери качества сервиса. Для высоконагруженных сценариев применяют специализированные движки — например, vLLM serving.
Зачем бизнесу и где применяется у НЬЮ-ССТ
- Понятная статья расходов. Инференс — операционный расход, который можно считать и оптимизировать: выбор модели, квантизация, кэширование и режимы обработки меняют счёт в разы.
- Контроль скорости сервиса. Требования к ответу ассистента фиксируются заранее — и проверяются на реальном трафике, а не на демонстрации.
- Конфиденциальность. Где физически идёт инференс — там и остаются данные; для чувствительных категорий это определяет архитектуру всего решения.
- Масштабируемость. Правильно спроектированный инференс-контур переживает рост трафика заменой одного узла, а не переписыванием системы.
У НЬЮ-ССТ инференс-контур проектируется вместе с LLM-интеграцией: подбирается модель под задачу, выбирается размещение, настраиваются фильтры и мониторинг задержек и стоимости. Разработка такого решения — от 0,9–1,2 млн ₽; сопровождение действующего контура — от 50 000 ₽/мес.
Риски и безопасность инференса
Инференс-сервер — это точка, где модель встречается с внешним миром, и защищать нужно именно её. Через тщательно сконструированный запрос злоумышленник пытается вытащить системную инструкцию или заставить модель нарушить правила — эти сценарии разобраны в статьях промпт-инъекция и джейлбрейк LLM. Логирование запросов и ответов нужно и для расследований, и для контроля качества, но вести его следует без хранения личных данных сверх необходимого.
Вторая группа рисков — эксплуатационная: перегрузка без очередей и лимитов, молчаливая деградация после обновления модели у провайдера, отсутствие отката на предыдущую версию. Третья — экономическая: без мониторинга стоимости счёт за токены растёт незаметно, пока не становится строкой, которую спрашивает финансовый директор.
Типовые ошибки
Первая ошибка — выбирать модель по лидерборду, а не по связке «качество на ваших задачах × скорость × цена». Вторая — измерять латентность на пустом сервере и планировать мощности от этого числа. Третья — считать только цену токенов и забывать про разработку обвязки: фильтры, очереди, мониторинг и дежурство стоят денег независимо от модели. Четвёртая — запускать интерактивный сервис там, где хватало бы ночных пакетных обработок.
Экономика: что считать
Полная стоимость инференса складывается из стоимости вычислений (облачные токены или амортизация своего железа), сопровождения и стоимости ошибок. Оптимизация начинается не с покупки ускорителей, а с измерений: какая доля запросов вообще доходит до большой модели, какова средняя длина контекста, сколько ответов уходит на переспрос. Часто после аудита выясняется, что половину задач закрывает маленькая модель, а большая нужна лишь для сложных случаев — это и есть LLM-роутинг.
Инференс LLM против классических моделей
Классическая модель — классификатор или скоринг — отвечает одним числом или меткой: пришёл документ, вышел код категории. Её инференс лёгкий и почти мгновенный, его легко считать штуками. Инференс языковой модели устроен растянуто: ответ собирается токен за токеном, каждый следующий кусок текста требует полного прохода по модели, и время ответа растёт с длиной и ответа, и контекста. Отсюда практика потоковой выдачи: пользователь начинает читать ответ до его полного завершения, а система меряет не «время ответа», а «время до первого токена» и «темп генерации».
Вторая особенность — непостоянство нагрузки по длине. У классификатора каждый запрос весит одинаково; у ассистента один диалог может занять сто токенов, другой — десять тысяч, если пользователь загрузил документ. Планировать ёмкость «по числу запросов» наивно: считают токены и пиковые длины контекстов. Третья — эффект кэша: повторяющиеся префиксы (системный промпт, типовые инструкции) при поддержке провайдером промпт-кэширования стоят заметно дешевле, и проектирование запросов с учётом кэша — легальная экономия без потери качества.
Контроль инференса в эксплуатации
Инференс-контур живёт под тремя графиками. Первый — время до первого токена и общее время ответа по перцентилям: не среднее, а именно хвосты, потому что впечатление портят редкие медленные ответы, а не средняя цифра. Второй — стоимость на диалог и на тысячу запросов: счёт, который можно показать финансовому директору. Третий — доля отказов и фильтраций: сколько запросов не дошло до модели по лимитам и правилам. К ним добавляется журнал инцидентов: обновление модели у провайдера, деградация сети, исчерпание квот — всё, что меняло поведение сервиса.
Ежемесячная гигиена проста: пересмотреть топ медленных сценариев, проверить долю запросов, уходящих в повтор из-за неудачных ответов, сверить фактическую стоимость с планом. Эти три вопроса на одной странице — и есть операционный контроль инференса.
Инференс в договорных терминах
Заказчику инференс полезно видеть в терминах обязательств, а не только техники: время ответа фиксируется как интервал, а не точка; доступность — как процент за месяц с оговоркой о плановых окнах; стоимость — как расчёт на единицу полезной работы (обработанный документ, отвеченный диалог), а не «за токены вообще». Такая формулировка закрывает главный источник споров: поставщик мерит средние, заказчик помнит худший день.
Второй договорный слой — поведение при деградации: что происходит, когда время ответа превышает порог, кто уведомляется, как включается деградация сервиса (упрощённые ответы, очередь, передача на человека). Система без описанной деградации падает некрасиво; с ней — переключается на запасной режим, который пользователи переживают без потерь.
С чего начать
Зафиксируйте три числа: текущий или планируемый трафик, требуемое время ответа и ограничения по данным. С этими числами выбор между облаком и своим контуром, между большой и маленькой моделью становится арифметикой, а не вкусовщиной. Разбор вашего сценария с расчётом стоимости инференса — в бесплатном аудите ИИ-ландшафта.