Inference Plane

Слой исполнения моделей (Inference Plane) отвечает за путь от загрузки модели и очереди запросов до выдачи результата. Здесь среда исполнения (runtime), планировщик (scheduler) и процессы модели (workers) делят ускорители и память между запросами. Результатом может быть текст, вектор, оценка релевантности документа или распознанная речь.

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

Как устроено исполнение моделей

Внутри слоя исполнения разделяют несколько задач:

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

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

Генерация текста, векторизация, ранжирование и распознавание речи используют ускорители по-разному. Для них отдельно выбирают очереди, правила планирования и целевые показатели сервиса (SLO). Возможность объединить эти нагрузки проверяют измерениями.

Кто задаёт доступ, качество и границы данных

Ценность сценария и объём инвестиций определяют в области стратегии и границ платформы (Strategy & Boundaries). Права доступа, стабильные имена моделей, квоты и резервные маршруты (fallback) задаёт слой управления (Control Plane). Он передаёт параметры и политики исполнения; отдельный вызов этого слоя на пути каждого запроса необязателен.

Остальные решения также имеют свою область:

• Контекст и исполнение агентов (Context & Agent Runtime): цикл агента, поиск контекста (retrieval), реестр инструментов и состояние сессии. Слой исполнения моделей получает уже собранный вызов.
• Качество и жизненный цикл (Quality & Lifecycle): проверка версии модели или среды исполнения перед выпуском.
• Эксплуатация и экономика (Operations & Economics): SLO, доступная мощность и стоимость.
• Безопасность и ответственность (Security & Ownership): границы данных, изоляция арендаторов и владелец реакции на сбой.

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

Профиль нагрузки важнее названия модели

Генеративный запрос проходит как минимум две разные фазы. Сначала модель обрабатывает входной контекст (prefill), затем последовательно выпускает новые токены (decode). Длинный вход с коротким ответом и короткий чат с длинной генерацией нагружают систему неодинаково. Общий показатель «токенов в секунду» может скрыть очередь перед обработкой входа или медленную генерацию.

При векторизации (embeddings) результат обычно имеет фиксированную форму, но входы различаются длиной и возможностью объединения в пакеты. Повторное ранжирование (reranking) работает с группами пар «запрос — документ». При распознавании речи (STT) добавляются длительность аудио, предварительная обработка и иногда требования ко времени выдачи потокового ответа. Объединяйте эти нагрузки в общий пул после измерения их влияния друг на друга и выбора приоритетов.

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

Где помогает кэш префикса

Кэш префикса (Prefix Cache) повторно использует KV-блоки при совпадающем начале запроса по правилам среды исполнения. Он сокращает повторную обработку входа для подходящей нагрузки. Эта экономия не ускоряет последовательную генерацию. Повторное использование зависит и от маршрута: запрос должен попасть в среду, которой доступны нужные блоки.

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

Что измерять от очереди до результата

Для каждого класса запросов фиксируйте маршрут к модели и ожидаемый SLO. Разделяйте время в очереди, обработку входа, время до первого токена (TTFT), длительность генерации и итоговый статус. Для задач без выдачи токенов сохраняйте соответствующие фазы: ожидание, предварительную обработку, исполнение и обработку результата.

Для пула нужны число ожидающих и исполняемых запросов, отказы в допуске, признаки исчерпания ресурсов и причины недоступности процессов модели. Для памяти — заполнение KV-кэша, вытеснение блоков или вынужденная приостановка запросов (preemption), а также признаки повторного использования. Долю попаданий в кэш считайте вместе с объёмом подходящих токенов: указывайте, что входит в знаменатель и какой маршрут охватывает метрика.

Документация метрик vLLMВнешняя ссылка, откроется в новой вкладке показывает, какие сигналы может отдавать среда исполнения. Имена и набор метрик зависят от версии. Перед объединением метрик разных сред определите смысл каждого поля, охват измерения и ответственного за него.

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

Как связаны скорость, память и отказы

Большой пакет может повысить пропускную способность, но задержать отдельный запрос. Порционная обработка входа (chunked prefill) может дать планировщику больше свободы и изменить распределение задержек. Больше памяти под KV-кэш позволяет держать длинные контексты или больше одновременных запросов, но эта память нужна также весам модели и рабочим буферам. Квантование снижает потребление памяти и требует отдельной проверки качества и совместимости.

Несколько реплик, то есть отдельных экземпляров среды с моделью, дают резерв и возможность масштабирования. Кэш префикса обычно привязан к состоянию конкретного экземпляра, поэтому случайное распределение запросов одной сессии может мешать повторному использованию. Закрепление сессии за репликой (sticky routing) помогает сохранить доступ к нужному кэшу, но создаёт риск перегрузки этой реплики. Общий внешний слой хранения KV-блоков расширяет область отказа, добавляет сетевые обращения и затраты на эксплуатацию. Для выбора измерьте повторяемость префиксов и стоимость исполнения без готового кэша.

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

Kubernetes выбирает узел (Node) для пода (Pod): отбрасывает неподходящие варианты и оценивает оставшиеся. Этот процесс описан в документации kube-schedulerВнешняя ссылка, откроется в новой вкладке. Планировщик модели управляет допуском и исполнением запросов внутри среды. При диагностике различайте размещение подов и очередь запросов к модели.

Какие данные передавать между областями

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

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

Где разобрать кэш подробнее

• Кэш префикса — устройство, путь запроса, причины отказов и чеклист проверки.
• Перестановка инструментов между шагами агента — синтетический пример с исходными данными в репозитории.
• audit-prompt-caching — локальный скилл и скрипты для проверки сборки запросов.
• Короткий промпт не значит дешёвыйВнешняя ссылка, откроется в новой вкладке — статья о префиксе агентного запроса.

С чего начать нагрузочную проверку

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

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

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