AI Runway: как собрать свой контролируемый inference‑платформ на Kubernetes — VogueTech

Что нового

AI Runway — это новый Kubernetes‑нативный слой для развёртывания и управления LLM, который превращает "вызов внешнего API" в полноценную корпоративную inference‑платформу.

Ключевые изменения по сравнению с привычной схемой "приложение → конкретный runtime / внешний API":

Единый API для развёртывания моделей
Вместо десятков YAML под каждый runtime появляется один CRD:
- ModelDeployment описывает:
  - какую модель запустить (например, Qwen3‑0.6B в формате GGUF);
  - какой движок использовать (vLLM, SGLang, TensorRT‑LLM, llama.cpp);
  - ресурсы (CPU/GPU, память);
  - масштабирование;
  - настройки шлюза (OpenAI‑совместимый endpoint и т.п.).
Мульти‑провайдерная поддержка из коробки
AI Runway умеет работать с:
- KAITO;
- NVIDIA Dynamo;
- KubeRay;
- llm-d;
- дополнительными провайдерами через shims.
Несколько движков под одним интерфейсом
Поддерживаются:
- vLLM — высокопроизводительный GPU‑сервер для LLM;
- SGLang — сложные пайплайны и структурированный вывод на GPU;
- TensorRT‑LLM — оптимизированный inference на NVIDIA GPU;
- llama.cpp — квантованные GGUF‑модели на CPU и лёгких GPU.
Автовыбор провайдера и движка
Контроллер AI Runway сам подбирает, через кого запускать модель:
- сверяет требования по CPU/GPU;
- учитывает режим сервинга (стриминг, батчинг и т.п.);
- смотрит, что умеет конкретный провайдер.
Операционный контур из коробки
- Web‑UI и плагин для Headlamp для развёртывания и мониторинга;
- REST API;
- логирование и метрики в формате Prometheus;
- интеграция с Gateway API для единого OpenAI‑совместимого маршрутизатора;
- подсказки по стоимости и вместимости (GPU fit, прайс, capacity).
Сценарии без GPU
AI Runway + KAITO + llama.cpp позволяют:
- запускать GGUF‑модели на локальном Kubernetes без GPU;
- разворачивать на Azure Kubernetes Service (AKS) CPU‑only inference, например Qwen3‑0.6B GGUF;
- работать с квантованными моделями при ресурсах от 4 vCPU и 12 ГиБ RAM на ноду.

Как это работает

Базовая архитектура

AI Runway строится вокруг нескольких слоёв:

Unified control plane
Вы описываете развёртывание через ModelDeployment (CRD Kubernetes).
Вместо того чтобы писать YAML для каждого runtime (vLLM, llama.cpp и т.д.), вы даёте одну декларацию: какая модель, какие ресурсы, какая схема доступа.
Провайдеры вне основного дерева (out‑of‑tree)
KAITO, NVIDIA Dynamo, KubeRay, llm-d и другие работают как отдельные контроллеры.
Они объявляют свои возможности через provider shims:
- какие типы моделей поддерживают;
- какие ресурсы (CPU, типы GPU);
- какие режимы сервинга.
Заменяемый runtime‑слой
На одном и том же кластере Kubernetes можно одновременно держать:
- CPU‑базированные inference через llama.cpp;
- GPU‑нагруженные vLLM или TensorRT‑LLM;
- сложные пайплайны на SGLang.

Приложения при этом ходят в единый шлюз (OpenAI‑совместимый API или Gateway API), а не в конкретный runtime.

Поток работы

Инженер платформы или разработчик создаёт ModelDeployment:
- указывает модель (например, Qwen3‑0.6B‑GGUF из Hugging Face);
- задаёт требования к ресурсам (CPU/GPU, память);
- включает/отключает автоскейлинг;
- настраивает экспонирование через OpenAI‑совместимый endpoint.
AI Runway Controller:
- читает ModelDeployment;
- выбирает подходящего провайдера (KAITO, Dynamo, KubeRay, llm-d);
- подбирает движок (vLLM, SGLang, TensorRT‑LLM, llama.cpp) по требованиям;
- создаёт нужные объекты Kubernetes (Deployment, Service и др.) через провайдера.
Провайдер:
- разворачивает контейнеры с нужным движком;
- монтирует модель (из локального cache, PVC, S3/Hugging Face);
- настраивает сетевой доступ.
Наблюдаемость и управление:
- статус развёртывания, логи и метрики доступны через Web‑UI, Headlamp или kubectl;
- Prometheus собирает метрики запросов, загрузки GPU/CPU и т.д.;
- Gateway API даёт единый OpenAI‑совместимый вход для приложений.

Где крутится

AI Runway работает на любом Kubernetes‑кластере:

локально: kind, minikube, k3d, Docker Desktop Kubernetes;
в облаке: Azure Kubernetes Service (AKS) — основной пример в исходном материале;
CPU‑only и GPU‑кластеры: можно начать с CPU, затем добавить GPU‑ноды.

Что это значит для вас

Когда нужен свой inference‑платформ

AI Runway имеет смысл, если вы:

Уже доказали пользу LLM
У вас есть:
- внутренние ассистенты знаний;
- генерация кода;
- поддержка клиентов;
- обработка документов;
- агентные пайплайны.
Но стоимость токенов и зависимость от одного внешнего API начинают мешать.
Хотите контролировать стоимость токенов
В продакшене один запрос RAG может включать:
- системный промпт;
- пользовательский ввод;
- извлечённый контекст;
- вывод инструментов;
- итоговый ответ.
Агент может вызывать LLM десятки раз на один сценарий: планирование, маршрутизация, суммаризация, валидация, генерация.
Внутренний Copilot для сотен сотрудников быстро превращает строку "LLM" в серьёзную статью операционных расходов.

AI Runway даёт возможность:
- вынести часть нагрузок на self‑hosted модели;
- использовать квантованные и специализированные модели там, где не нужен топовый закрытый LLM;
- играть ресурсами (CPU/GPU, батчинг, tiering) для снижения стоимости.
Нужны чёткие границы данных и комплаенс
Если вы работаете с:
- чувствительными документами;
- внутренними базами знаний;
- диалогами с клиентами;
- бизнес‑контекстом,
self‑hosted inference позволяет держать данные внутри управляемой сети и операционной модели.
Логирование, аудит, разграничение доступа и хранение контекста остаются в вашей инфраструктуре.
Не хотите привязываться к одному движку
vLLM, SGLang, TensorRT‑LLM, llama.cpp решают разные задачи:
- vLLM — высокий throughput на GPU для общих задач;
- SGLang — сложные пайплайны, структурированный вывод;
- TensorRT‑LLM — максимум эффективности на NVIDIA GPU;
- llama.cpp — квантованные GGUF‑модели на CPU и лёгких GPU.
AI Runway позволяет:
- выбрать движок под конкретную нагрузку;
- сохранить единый опыт для разработчиков (OpenAI‑совместимый endpoint или общий gateway).
Нужна нормальная эксплуатация, а не просто endpoint
В продакшене вам всё равно нужны:
- управление жизненным циклом развёртываний;
- статусы и алерты;
- логи и трассировка;
- метрики и автоскейлинг;
- поэтапный rollout;
- квоты по ресурсам;
- безопасный ingress.
AI Runway превращает это в платформенные примитивы, а не в набор самописных YAML под каждый runtime.

Конкретные сценарии, где self‑hosted помогает

Из исходного материала — типовые кейсы:

| Сценарий | Как помогает self‑hosted inference | |----------|------------------------------------| | Частые внутренние Q&A | Большой поток запросов можно обслуживать меньшими или квантованными моделями | | Суммаризация и извлечение из документов | Стабильный паттерн задач, удобно под специализированные локальные модели | | Промежуточные шаги агентов | Планирование, классификация, переформулировка не требуют самого сильного закрытого LLM | | Edge и приватные сети | Данные остаются внутри контролируемого периметра | | Чувствительные к цене приложения | Пулы CPU/GPU, батчинг и tiering снижают стоимость запроса |

Где не стоит применять

AI Runway — это не замена всем внешним API. Он не нужен, если:

у вас только один небольшой прототип, и стоимость токенов несущественна;
у команды нет опыта с Kubernetes и нет планов его заводить;
вы не готовы тратить ресурсы на эксплуатацию собственного inference‑слоя.

Логика использования скорее такая:

высокочастотные, предсказуемые, локальные или чувствительные к приватности нагрузки — на self‑hosted через AI Runway;
редкие или требующие топовых закрытых моделей запросы — через внешние API (GPT‑4‑класс, Claude‑класс и т.п.).

Доступность из России

AI Runway — это open‑source‑проект на GitHub и работает поверх Kubernetes.
Доступ к исходникам и образам может потребовать VPN, если GitHub или связанные реестры Docker/контейнеров блокируются провайдерами.
Сам по себе продукт разворачивается в вашей инфраструктуре и не завязан на единого облачного провайдера.

Место на рынке

AI Runway играет в сегменте платформ для развёртывания LLM на Kubernetes.
Фокус — не на создании собственных моделей, а на управлении inference‑слоем.

По ключевым параметрам:

Поддержка движков: vLLM, SGLang, TensorRT‑LLM, llama.cpp под одним API.
Многие существующие решения завязаны на один runtime или требуют отдельной интеграции под каждый.
Провайдеры: KAITO, NVIDIA Dynamo, KubeRay, llm-d и shims.
Это даёт вариант как для CPU‑кластеров, так и для тяжёлых GPU‑кластеров.
API‑слой: OpenAI‑совместимая схема вызова через Gateway API.
Приложения могут переехать с внешнего API на внутренний endpoint без серьёзной переработки кода.
Kubernetes‑нативность: всё крутится вокруг CRD ModelDeployment.
Команда платформы использует привычные инструменты: RBAC, namespaces, NetworkPolicy, GitOps, Prometheus.

Чётких числовых сравнений по скорости с GPT‑4‑классом или Claude‑классом в исходном материале нет.
Акцент сделан на контроле стоимости, мульти‑движках и эксплуатации, а не на бенчмарках качества ответов.

Установка / Как запустить

Исходный текст даёт две основные траектории запуска: локально и в Azure AKS.
Подробные гайды вынесены в gists, но общая логика такая.

Вариант 1. Локальный Kubernetes + AI Runway + KAITO + CPU

Цель: показать полный путь от ModelDeployment до OpenAI‑совместимого сервиса без GPU.

Подходит для:

локальных экспериментов разработчиков (kind, minikube, k3d, Docker Desktop Kubernetes);
демо платформы (как работает ModelDeployment, провайдеры, OpenAI‑совместимый API);
валидации на CPU‑only окружении;
тестов SLM / GGUF через llama.cpp.

Ресурсы:

минимум 4 vCPU и 12 ГиБ памяти на ноду Kubernetes;
этого хватает для небольших моделей, но помните про память под:
- запуск runtime;
- загрузку модели;
- KV‑кэш;
- контекстные окна.

Что вы получаете:

разработчики осваивают ModelDeployment без GPU;
приложение не знает, какой backend под капотом — LocalAI, llama.cpp или KAITO Workspace;
CPU‑окружения могут крутить лёгкие и квантованные модели;
можно отладить модели, промпты и API‑поведение локально, а потом перенести конфиг на AKS.

Подробный пример конфигурации и команд — в guideline:
https://gist.github.com/kinfey/28b2338845cc63139aee2ea462a3c466

Вариант 2. Azure AKS + AI Runway + KAITO + CPU

Следующий шаг после локальной валидации — облачный inference‑слой на AKS.

Что даёт AKS:

управляемый control plane Kubernetes;
node pools (CPU и GPU);
сетевые настройки и балансировщики;
интеграцию с Azure AD и Managed Identity;
мониторинг и логирование в Azure Monitor;
экосистему Azure (storage, сети, WAF и т.д.).

Пример из исходного текста:

кластер AKS в режиме CPU‑only;
AI Runway + KAITO;
модель Qwen3‑0.6B GGUF из Hugging Face;
итог — облачный inference‑сервис без GPU‑нод.

Рекомендации для продакшена на AKS:

Безопасный ingress:
не открывайте HTTP 80 напрямую; добавьте:
- TLS;
- API‑ключи;
- OAuth2 Proxy;
- WAF;
- или внутренний LoadBalancer.
Гибернация и управление моделями:
фиксируйте версии моделей, образов контейнеров и имена файлов GGUF.
Управление стоимостью:
используйте CPU для лёгких задач, а GPU — для крупных и высоконагруженных моделей.
Наблюдаемость:
интегрируйте Azure Monitor, Prometheus, логи и метрики на уровне запросов.
Планирование квот:
заранее проверяйте региональные квоты по vCPU/GPU.
Кэширование моделей:
используйте PVC или отдельные volume‑кэши, чтобы не скачивать модели заново при каждом развёртывании.
GitOps:
управляйте ModelDeployment, провайдерами и ingress через GitOps‑практики.
Контроль доступа:
namespaces, RBAC и NetworkPolicy для изоляции команд и приложений.

Подробный пример — в guideline:
https://gist.github.com/kinfey/d439a545d8c93e15d8a2854b65f03d4d

Как продать AI Runway внутри инженерной команды

Если вы развиваете платформу внутри крупной компании, автор исходного материала предлагает такую стратегию:

Начните с предсказуемости стоимости
Аргумент: высокочастотные нагрузки не должны всегда идти в самый дорогой внешний tier.
AI Runway позволяет вынести часть запросов на собственные модели и управляемые ресурсы.
Подчеркните технический выбор, а не единый стандарт
Команды могут выбирать разные модели и движки, оставаясь в рамках одного платформенного входа.
Это уменьшает риск "зажима" в один runtime.
Играйтесь на поле Kubernetes‑операций
AI Runway встраивается в уже существующий стек:
- AKS;
- RBAC;
- мониторинг;
- GitOps;
- сеть и безопасность.
Платформенная команда не заводит новый зоопарк, а расширяет уже знакомые практики.
Порог входа — CPU‑демо
Локальный KAITO + CPU‑кластер позволяет разработчикам:
- увидеть полный путь от ModelDeployment до OpenAI‑совместимого endpoint;
- не думать о GPU и сложном планировании.
Azure как целевая среда
AKS переносит те же абстракции в облако и позволяет со временем:
- добавить GPU;
- подключить gateway;
- усилить мониторинг;
- ввести multi‑tenant‑governance.

Логика внедрения: начать с малого, доказать ценность абстракции, потом наращивать производительность и управление.

Вывод

AI Runway возвращает задачу inference‑платформы в зону Kubernetes‑инженерии:

ModelDeployment стандартизирует развёртывание моделей;
провайдеры прячут различия рантаймов;
несколько движков позволяют балансировать между стоимостью и производительностью.

Путь, который предлагает проект:

локальный Kubernetes + KAITO + CPU‑демо;
затем Qwen3‑0.6B GGUF на CPU в AKS;
дальше — много моделей, много движков, много провайдеров и единый gateway под корпоративным управлением.

Self‑hosted inference через AI Runway не про отказ от внешних моделей.
Это про контроль над стоимостью, архитектурой и технологическим выбором со стороны вашей инженерной команды.

Полезные ссылки:

AI Runway GitHub: https://github.com/kaito-project/airunway
Архитектура AI Runway: https://github.com/kaito-project/airunway/blob/main/docs/architecture.md
Провайдеры AI Runway: https://github.com/kaito-project/airunway/blob/main/docs/providers.md
CRD‑референс AI Runway: https://github.com/kaito-project/airunway/blob/main/docs/crd-reference.md
KAITO: https://github.com/kaito-project/kaito
LocalAI: https://localai.io
AKS Application Routing: https://learn.microsoft.com/azure/aks/app-routing
Qwen3‑0.6B GGUF: https://huggingface.co/Qwen/Qwen3-0.6B-GGUF