Инференс LLM: как модель отвечает и где теряется время

Инференс LLM состоит из 2 основных этапов: обработки промпта и генерации ответа. Если ответа долго нет, нужна одна оптимизация; если он появляется сразу, но долго не заканчивается — другая. Измеряйте эти задержки отдельно, прежде чем менять модель, платить за более быстрый хостинг или арендовать GPU.

Начните с облачного API, если у вас нет конкретной причины самостоятельно обслуживать модель. Такой причиной могут быть требования к контролю над развёртыванием, необходимость использовать определённую открытую модель или стабильный поток запросов, ради которого оправданно содержать собственные мощности. Сам по себе медленный ответ — ещё не повод: сначала выясните, на каком участке запроса уходит время.

Документация и состав релизов, описанных ниже, сверены с действующими страницами разработчиков 21 октября 2026 года. В примере с расчётами используется опубликованный ответ API; вся арифметика приведена явно. Это не результат бенчмарка и не обещание скорости, которую получит ваше приложение.

Что такое инференс LLM: сначала промпт, затем ответ

Инференс LLM — это работа обученной большой языковой модели, которая по входным данным формирует результат. В обычном запросе на генерацию текста модель обрабатывает промпт, предсказывает продолжение и возвращает сгенерированный текст. Она работает с токенами — единицами текста, которыми могут быть слова, части слов или знаки препинания. Объяснение инференса от NVIDIA.

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

Prefill — обработка уже известного входа. Инструкции, найденные документы, история диалога и результаты вызова инструментов превращаются в токены промпта. Поскольку эти позиции уже известны, система может обрабатывать их совместно, с учётом правил механизма внимания конкретной модели. На этом этапе формируется состояние, необходимое для выдачи первого выходного токена.

Decode — генерация продолжения. При обычной авторегрессионной генерации каждый новый токен зависит от уже выбранного продолжения. Среда выполнения снова и снова запускает модель, выбирает следующий токен, обновляет состояние и повторяет цикл до выполнения условия остановки. Описание обоих этапов у NVIDIA.

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

Чем инференс отличается от обучения LLM

Обучение меняет усвоенные моделью параметры, а инференс использует их. Параметры, которые часто называют весами, — это числовые значения, полученные в ходе обучения. Документ в промпте даёт модели контекст для текущего запроса; сам по себе он не переобучает её веса. Объяснение инференса и обучения от IBM.

Это различие помогает искать причину проблем в продукте. Если ответ не учитывает регламент, улучшайте передаваемый контекст и проверяйте поведение модели. Если ответ правильный, но приходит слишком поздно, разбирайтесь со временем инференса. Обучение, качество поиска данных и производительность обслуживания запросов — разные точки приложения усилий.

Почему выходные токены обычно дороже

При генерации продолжения в рамках одного запроса обычно меньше возможностей для параллельной работы, чем при обработке уже известного промпта. При небольших батчах этап decode может тратить значительную часть времени на перемещение весов модели и состояния внимания через память. Совместная обработка большего числа известных входных позиций позволяет иначе использовать оборудование. Это отчасти объясняет, почему во многих API выходные токены стоят дороже. Механика prefill и decode в описании NVIDIA.

Точное соотношение цен определяет поставщик: это не физическая константа. Важны также условия кэширования, выбор модели и условия сервиса. Не считайте, что сокращение входа и сокращение выхода одинаково повлияют на задержку или счёт.

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

Время до первого токена и токены в секунду: измеряйте отдельно

Время до первого токена показывает, как долго ответ ещё не появляется; скорость генерации — как быстро он продолжается. Для обоих измерений заранее определите единые точки отсчёта.

• Время до первого токена, или TTFT: от отправки запроса модели до получения первого непустого выходного токена. В него могут входить ожидание в очереди, обработка промпта и передача данных по сети.
• Задержка между токенами: интервал между выходными токенами после начала генерации. Потоковый ответ может начаться быстро, но всё равно казаться медленным из-за больших промежутков между токенами.
• Полная задержка запроса: от отправки запроса до получения последнего выходного токена.
• Пропускная способность системы: суммарный объём полезного вывода по всем одновременно обрабатываемым запросам. Этот показатель может расти, даже когда отдельному пользователю приходится ждать дольше.

Эти различия соответствуют определениям метрик NVIDIA. Поэтому одна цифра «токенов в секунду» не отвечает на все вопросы о производительности.

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

Для потокового ответа из нескольких токенов средний интервал между ними можно вычислить так: (final-token time − first-token time) / (output-token count − 1). Начальное ожидание здесь не учитывается, а вычитание нужно, чтобы получить число промежутков между токенами. В определении NVIDIA эта граница указана явно.

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

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

Опубликованный пример ответа Groq показывает, почему поле total_time нужно изучить, прежде чем на него полагаться. Groq — облачный провайдер инференса — включает временные показатели в данные API об использовании ресурсов. В справочнике Chat Completions API приведён пример с 18 токенами промпта и 556 токенами ответа.

Ниже — опубликованные значения из этого примера, переведённые из секунд в миллисекунды и округлённые:

Источник: объект usage из примера Groq. Это значения из документации, а не ориентир ожидаемых задержек в рабочем приложении.

В этом примере указанное суммарное время включает обработку промпта и генерацию:

Промпт + ответ = 0.000680594 + 0.463333333 = 0.464013927 секунды. Это в точности совпадает с total_time. Ожидание в очереди в эту сумму в данном примере не входит.

Очередь + промпт + ответ = 0.501507683 секунды, или примерно 501.508 мс. Это рассчитанная нами сумма перечисленных серверных этапов. Она по-прежнему не показывает полное время ожидания в приложении: в примере нет ни сетевых замеров на стороне клиента, ни времени на остальную работу приложения.

Если разделить 556 выходных токенов на 0.463333333 секунды генерации, получится примерно 1 200 выходных токенов в секунду. Это арифметика на основе примера ответа, а не бенчмарк и не обещание. Groq описывает такой расчёт — число токенов, делённое на время генерации — в руководстве по метрикам инференса.

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

Оптимизация инференса: устраняйте причину задержки

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

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

KV-кэш: сохраняйте уже выполненную работу

Кэш ключей и значений, или KV-кэш, хранит состояние внимания для предыдущих токенов. Механизм внимания позволяет трансформеру учитывать предыдущий контекст при текущем предсказании. Сохранённые ключи и значения не приходится вычислять заново на каждом шаге генерации. Рост кэша и управление им зависят от архитектуры внимания модели и политики обслуживания запросов. Объяснение KV-кэша от NVIDIA.

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

Кэширование префиксов позволяет повторно использовать состояние между запросами с одинаковым началом. Если помощник раз за разом получает одни и те же инструкции и справочный документ, он может использовать уже обработанный префикс. При этом изменившийся суффикс всё равно нужно обработать, а новый ответ — сгенерировать.

vLLM — движок инференса и обслуживания запросов с открытым исходным кодом — прямо указывает в документации: автоматическое кэширование префиксов сокращает работу на этапе prefill, а не decode. Ограничения кэширования в vLLM.

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

Батчинг: распределяйте мощности между запросами

Непрерывный батчинг помогает серверу полнее использовать ресурсы. Завершённые последовательности покидают батч, а новые запросы входят в него, пока для остальных последовательностей продолжается генерация. Благодаря этому не приходится ждать самый длинный ответ, удерживая всю группу. Объяснение непрерывного батчинга от NVIDIA.

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

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

Chunked prefill снижает взаимное влияние новых промптов и уже генерируемых ответов. Большой prefill разбивается на небольшие части, которые можно планировать вместе с работой на этапе decode. В документации vLLM описан компромисс между временем до первого токена и задержкой между токенами при изменении токенного бюджета планировщика. Руководство по настройке vLLM.

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

Квантование: меньше памяти на каждое значение

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

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

Не обещайте ускорение, опираясь только на название формата. Результат определяют поддерживаемые вычислительные ядра, оборудование и нагрузка. При выборе формата и оценке того, расход какой именно памяти сокращается, воспользуйтесь руководством по квантованию LLM.

Спекулятивное декодирование: предложить, затем проверить

При спекулятивном декодировании система пытается принять больше токенов продолжения за один проход проверки. Менее затратный черновой механизм предлагает токены, а целевая модель проверяет их. Принятые варианты могут сократить последовательную работу по генерации; отклонённые варианты и сама проверка тоже требуют ресурсов. Документация vLLM по спекулятивному декодированию.

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

Стандартные методы сэмплирования с отклонением стремятся сохранить целевое распределение в пределах численной точности. Не распространяйте эту гарантию на любую функцию со словом «спекулятивный» в названии: в той же документации vLLM отделяет стандартные гарантии от методов проверки, которые намеренно допускают потери.

Архитектура инференса LLM: кто будет обслуживать модель

Сначала определите границу ответственности, затем выбирайте оборудование. API разработчика модели, провайдер инференса и собственная среда выполнения — все они превращают промпты в ответы. Но в каждом случае на вашей стороне остаётся разный объём работы.

API модели: доступ к моделям их разработчика

Claude API от Anthropic предоставляет программный доступ к моделям Claude, размещённым у разработчика. Messages API принимает запросы и генерирует ответы; потоковая выдача и интерфейсы работы с инструментами описаны в документации разработчика. Обзор Claude API.

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

Ограничение здесь — степень контроля. Покупка доступа к модели не даёт вам ни планировщик провайдера, ни экземпляр этой модели в собственной инфраструктуре. Выбирайте такой вариант, если модель и условия сервиса подходят под задачу. Медленный ответ API ещё не повод затевать проект с GPU: сначала измерьте, где возникает задержка.

Провайдер инференса: выбирайте хостинг отдельно

Groq предлагает облачный API генерации сообщений с документированным каталогом моделей. На страницах моделей указаны возможности и ограничения каждой из них, поэтому проверяйте конкретный эндпоинт, который собираетесь использовать. Каталог моделей Groq.

Так можно оценить хостинг для доступной модели, не обслуживая оборудование самостоятельно. Ограничения задаёт конкретная конфигурация: доступность модели, лимиты запросов и поддерживаемые функции. Если семейство моделей встречается у других поставщиков, это ещё не значит, что выбранный провайдер обслуживает нужный вам чекпойнт или поддерживает все поля запроса.

Cerebras предоставляет облачный API инференса и SDK, в том числе для потоковой генерации. В кратком руководстве показаны настройка API-ключа и порядок отправки запроса. Быстрый старт с инференсом Cerebras.

Рассматривайте Cerebras как ещё одного кандидата для проверки на реальной длине ваших промптов, требованиях к ответам и характере трафика. Критерий остаётся прежним: подходит ли сервис под задачу. Уточните доступную модель, нужные функции и условия предоставления мощностей. Быстрая потоковая выдача на коротком примере ещё не доказывает пригодность для рабочей функции, которая обрабатывает много документов. Коммерческие условия разобраны в руководстве по ценам Cerebras и руководстве по ценам Groq.

Пример цены облачного сервиса: Groq указывает для Qwen3.8-27B от Alibaba $0.80 за миллион входных токенов и $4.00 за миллион выходных токенов. Сверяйтесь с актуальным каталогом моделей, когда сравниваете оплату облачного использования с затратами на собственные мощности и их обслуживание.

Эта цена относится к конкретной модели. Она не является тарифом для приведённого выше примера с замерами и не позволяет ранжировать Groq относительно другой модели или другого варианта развёртывания.

Собственный движок инференса LLM: среда выполнения и мощности под вашим управлением

vLLM предоставляет среду обслуживания моделей с непрерывным батчингом, потоковой выдачей, кэшированием префиксов и API-сервером. Это полезные компоненты, если обслуживание одновременных запросов — ваша задача. Поддержку моделей, оборудования и способов оптимизации всё равно нужно проверить применительно к своему развёртыванию. Возможности vLLM по документации.

Основная сложность — сервис вокруг движка: выделять мощности, развёртывать изменения, управлять приёмом трафика, отслеживать сбои и держать достаточный резерв на периоды высокой нагрузки. Среда выполнения может распределять работу по доступным устройствам, но не может за вас определить требования к надёжности приложения.

Ollama — среда выполнения для запуска моделей на вашем компьютере или сервере с использованием CPU и GPU. В FAQ описаны одновременная обработка, очереди и дополнительная память, необходимая для параллельных запросов. Рекомендации Ollama по одновременным запросам.

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

DeepInfer от DeepSeek — специализированный фреймворк инференса, история публичного репозитория которого началась 20 октября 2026 года. README описывает открытый релиз как средство офлайн-инференса с компонентами для обслуживания в масштабе, поддерживающее DeepSeek-V4.1-Flash, GPU NVIDIA SM100 и NPU Huawei Ascend 950. История репозитория, README разработчика.

Этот релиз не является полноценным сервисом инференса. DeepSeek прямо перечисляет необходимые, но не включённые в релиз компоненты: систему KV-кэша, разделение encoding/prefill/decode и балансировку нагрузки между репликами. Речь об отсутствующих механизмах уровня сервиса; это не следует понимать так, будто движок инференса вообще не кэширует состояние внимания. Перечень отсутствующих компонентов DeepInfer.

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

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

Какие обещания быстрого инференса преувеличены

Более высокая скорость генерации полезна, только если улучшает получение результата, которого ждёт пользователь. Потоковая выдача раньше показывает прогресс, но оставшуюся генерацию всё равно нужно выполнить. Если рабочий процесс требует проверки полного структурированного ответа, возможно, придётся дождаться его окончания.

Самый быстрый инференс LLM зависит от нагрузки

В корректном сравнении видны поведение модели, длина промпта, длина ответа, условия кэширования и число одновременных запросов. Иначе «более быстрый» результат может объясняться просто более лёгким запросом или другим знаменателем в расчёте скорости. Совокупная пропускная способность провайдера не обещает конкретному клиенту быстрое появление первого токена.

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

Уже сейчас займитесь измерениями и устранением лишней работы. Перенос инфраструктуры отложите, пока измерения не покажут причину для него. Если короткий вызов API уже отвечает вашим требованиям к качеству и задержке, выход нового движка обслуживания не создаёт проблему, которую вам нужно решать.

Частые вопросы об инференсе

Что такое инференс в машинном обучении?

ML означает машинное обучение. При инференсе обученная модель получает новые входные данные и формирует результат. Генерация текста с помощью LLM — один из вариантов этого более общего процесса.

Как расшифровывается LLM в контексте искусственного интеллекта?

LLM расшифровывается как large language model — большая языковая модель. При генерации текста, о которой идёт речь в этой статье, она обрабатывает контекст и предсказывает токены, формируя продолжение.

Что означает «язык инференса»?

В этом контексте обычно имеется в виду инференс языковой модели. Это не название обязательного языка программирования: приложение может обращаться к модели через API или среду выполнения.

Чем инференс отличается от предсказания в ML?

Инференс — процесс выполнения обученной модели. Предсказание — результат этого процесса. При авторегрессионной генерации текста ответ складывается из последовательных предсказаний следующего токена.

Какие существуют три вида логического вывода?

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

Какие пять примеров инференса можно привести?

Примеры задач для языковой модели: классификация письма, краткое изложение документа, перевод фрагмента текста, подготовка ответа и генерация кода. Это примеры задач, а не заявления о производительности конкретной модели.

Можно привести один пример инференса?

Приложение службы поддержки передаёт обученной модели вопрос клиента и относящийся к нему текст регламента, а модель генерирует черновик ответа. Обработка переданного контекста и генерация ответа — это работа в рамках инференса.

Как запустить инференс?

Для приложения на базе LLM выберите обученную модель, передайте нужный промпт через API или среду выполнения и оцените полученный результат. Можно использовать уже обученную модель, не обучая её самостоятельно.

Что такое инференс простыми словами?

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

Что изменить на следующей неделе

Разработчикам стоит добавить измерения запроса, операторам — проверить его под нагрузкой, а тем, кто выбирает сервис, — сопоставить полученные требования к обслуживанию. Эти задачи связаны, но не заменяют друг друга.

1. 1

   Измерьте весь путь запроса

   Для характерной задачи зафиксируйте число входных и выходных токенов, время получения первого непустого и последнего выходного токена, а также доступные временные показатели провайдера. Наряду со временем работы модели измеряйте поиск данных и вызовы инструментов. Раздельно помечайте запросы с использованием кэша и без него.

2. 2

   Меняйте то, что отнимает больше всего времени

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

3. 3

   Воспроизведите реальную нагрузку

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

Подпишитесь на рассылку, чтобы получать практические разборы систем, на которых работают ИИ-продукты.