Глава 11 — Слой платформы и оркестрации

Одиннадцатый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, утверждающая, что выбор платформы — не про фичи, а про то, какая операционная модель совпадает с существующей ops-культурой команды.

Зачем эта глава существует

Движок оборачивает модель на GPU и производит токены. Это полное описание его работы. В момент, когда продакшену нужны две реплики за балансировщиком, или два разных движка под одним эндпоинтом, или пайплайн, запускающий embed→retrieve→rerank→generate как один логический вызов, или квотирование, не дающее одному тенанту заморить других голодом, или автоскейлер, добавляющий реплики по мере роста глубины очереди, движок исчерпал ответы. Глава 11 обходит четыре платформы, доминирующие на этой задаче в 2026 году — Ray Serve, KServe, BentoML, Triton Inference Server, — и утверждает, что выбор между ними — вопрос соответствия ops-культуре команды, а не вопрос фич.

11.1 Ray Serve — Python-first; KServe — Kubernetes-first

Ray Serve — платформа, возникающая, когда начальный вопрос: «как выглядел бы serving-фреймворк, если бы мне никогда не приходилось уходить из Python, чтобы составить, масштабировать и развернуть модельный пайплайн?» Ответ — Python-классы, декорированные как акторы, соединённые Python-вызовами функций, реплицированные, размещённые и автоскейленные рантаймом Ray. Deployments сцепляются в пайплайны, вызывая методы друг друга; пайплайн — Python, наблюдаемость — Python, история ops — Python. Это естественный выбор, когда тот же кластер уже запускает Ray для обучения. KServe возникает из противоположного стартового пункта: Kubernetes-first, вендор-нейтральный, декларативный. KServe InferenceService — это CRD, фиксирующий, где живут веса, какой рантайм их обслуживает и как должен вести себя автоскейлинг. Платформа соединяет поды через Knative для scale-to-zero и Istio для маршрутизации трафика и выставляет стабильный HTTP-эндпоинт. Обмен — выразительность (композиция пайплайнов в KServe более YAML-ориентированная, чем в Ray Serve) на переносимость и стандартизацию.

11.2 BentoML пакует; Triton батчит разнородные модели

BentoML занимает третью позицию: главная задача платформы — сделать модель + код + зависимости одним связным артефактом (Bento) и сделать развёртывание этого артефакта куда угодно (Kubernetes, Lambda, Cloud Run, голая VM) операцией в одну команду. Это то, чем Docker-образ является для приложений в целом, но на слое model-serving. Опыт авторинга — FastAPI-подобный Python; история деплоя — движение «сначала артефакт». Лучше всего подходит для маленького ops-следа и команд, желающих кратчайший путь от «Python-класс» до «развёрнутый эндпоинт, работающий где угодно». Triton Inference Server — enterprise-grade динамический батчер, исторически доминировавший в NVIDIA-выровненном serving-е. Он хостит TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM и Python-бэкенды бок о бок, применяет свой динамический батчер к не-LLM-нагрузкам (рекомендеры, классификаторы, embedders) и использует continuous-batching-планировщик для LLM под своим бэкендом TensorRT-LLM. Лучше всего подходит для разнородных нагрузок или для команд, уже глубоко в стеке NVIDIA.

11.3 Четыре выбора разделяются по совместимости с ops-культурой

Четыре платформы делятся чисто. Python и Ray в центре тяжести → Ray Serve. Kubernetes, декларативные манифесты, мультиклаудная переносимость, мульти-тенантная изоляция → KServe. Маленький ops-след, быстрейший путь от класса до эндпоинта → BentoML. Разнородные нагрузки или NVIDIA-first шоп → Triton. Они не взаимоисключающие на организационном уровне: типичный паттерн в больших организациях — Triton для самых объёмных продакшен-LLM, Ray Serve для RAG- и агентных пайплайнов, объединяющих несколько модельных вызовов, KServe как зонтик, навязывающий мультитенантность, и BentoML внутри dev-окружений. Полезное упражнение при выборе — перечислить три операционных свойства, абсолютно нужных команде, и три, без которых команда может жить, а затем ранжировать платформы по этому списку. Сопротивляйтесь платформе, «поддерживающей всё»: каждая платформа хорошо поддерживает своё ядро и плохо — периферию, а та, чьё ядро пересекается с обязательным списком, — та, которую команда будет с удовольствием эксплуатировать.

Что подготавливает глава 11

Граница движок/платформа чиста, когда единица репликации — один под, владеющий одной моделью на одном GPU-узле. Она перестаёт быть чистой в момент, когда мы отдаём должное факту из главы 1, что prefill и decode — противоречивые нагрузки. Глава 12 разделяет их на разные GPU-пулы, гоняет KV-кэш между пулами по сетевой фабрике и выражает разделение в примитивах Kubernetes — LeaderWorkerSet, PodCliqueSet от Grove, KAI Scheduler с осведомлённостью о топологии. Слой платформы — то, что делает разделение эксплуатируемым; слой платформы — причина, по которой разделение вообще выразимо.

Дальше — Глава 12: Дизагрегированный serving и Kubernetes. Разделение prefill и decode на отдельные поды и примитивы Kubernetes, выражающие это разделение.