Kubernetes насчитал 1,2 миллиона развёртываний LLM за прошлый квартал — по данным CNCF, — но целых 80% торчали в изоляции llama.cpp.
LLMKube v0.6.0 это меняет с ног на голову. Этот open-source-оператор, раньше заточенный под GGUF-модели, теперь принимает любой движок инференса, какой подкинешь. vLLM? Есть. Text Generation Inference? Без проблем. Даже экзотика вроде PersonaPlex от NVIDIA для голосовых чатов с задержкой ниже 300 мс.
В чём соль: рынок требует именно этого. Движки инференса разбрелись кто куда — vLLM захватил 45% умов в бенчмарках по пропускной способности, TGI рулит интеграциями с Hugging Face. Привязывать оператор к одному бэкенду? Это мышление 2023 года. Поворот LLMKube напоминает взрыв операторов в Kubernetes после 2018-го, когда cert-manager открыл автоматизацию сертификатов для всех.
Что поменялось под капотом?
Раньше контроллер LLMKube везде хардкодил llama.cpp — в образах контейнеров, пробах, аргументах. Хочешь vLLM? Крути свой Deployment вручную. Мучение.
Теперь — чистый интерфейс RuntimeBackend. Каждый движок его реализует:
type RuntimeBackend interface { ContainerName() string DefaultImage() string DefaultPort() int32 BuildArgs(isvc, model, modelPath, port) []string BuildProbes(port) (startup, liveness, readiness) NeedsModelInit() bool }
Контроллер разбирается по полю runtime в CRD. llama.cpp — по умолчанию. Остальные вставляются через switch. И готово — сменный.
Проверил на себе. Запустил PersonaPlex на домашней RTX 5060 Ti. Это 7B-монстр speech-to-speech от NVIDIA на базе Moshi, с прерыванием ниже 300 мс. PyTorch в нутрях, WebSocket-пробы, токены HF. Небо и земля по сравнению с минимализмом llama.cpp на C++.
CRD? Просто до безобразия:
spec:
runtime: personaplex
image: registry.defilan.net/personaplex:7b-v1-4bit-cuda13
personaPlexConfig:
quantize4Bit: true
resources:
gpu: 1
memory: "32Gi"
Контроллер впихивает python -m moshi.server, TCP-пробы на 8998, пропускает инициализацию (модель тянет из HF при старте), резервирует GPU. Запустилось за минуты. Реал-тайм голосовой ИИ на потребительском железе — как будто текстовая генерация.
Почему vLLM на Kubernetes наконец обрёл смысл
vLLM лидировал в запросах на GitHub для LLMKube. И не зря: PagedAttention уделывает llama.cpp по пропускной способности — 2–3x токенов/с в моих тестах TinyLlama.
v0.6.0 интегрирует его с VLLMConfig: maxModelLen, dtype, тензорный параллелизм. Выдаёт OpenAI-совместимый /v1-эндпоинт. Я раскрутил TinyLlama-1.1B:
spec:
runtime: vllm
vllmConfig:
maxModelLen: 2048
dtype: float16
resources:
gpu: 1
memory: "8Gi"
Аргументы генерит сам: --model, --max-model-len, квантизация. HTTP-пробы на 8000. Токен HF из Secret. Две минуты — и эндпоинт живой. Факт с рынка: vLLM с его 60% долей в продакшен-инференсе (по Artificial Analysis) наконец-то толком зашёл в K8s.
TGI не отстаёт — bitsandbytes, GPTQ, AWQ. Инициализация не нужна, тянет из Hub. Метрики для HPA подхватывает авто: vllm:num_requests_running, tgi:queue_size. Без костылей.
Общий runtime? Ваш джокер. Укажите Docker-образ, аргументы/пробы/env. Контроллер берёт GPU, сервис, скейлинг на себя.
Это тот стандарт Kubernetes для LLM, которого мы ждали?
LLMKube не первый — есть KServe, Kserve. Но они раздутые мультифреймворковые громадины. LLMKube? Лёгкий оператор, CRD на первом месте, GPU из коробки. Пять бэкендов сразу, доки для остальных.
Моё мнение: смелый прогноз. К четвёртому кварталу 2025-го 30% корпоративных развёртываний LLM на K8s пойдут через такие сменные операторы. Почему? Экономия. Шардинг на одном GPU (новые CUDA 13-образы для RTX 50-й серии), air-gapped Helm-настройки, дашборды Grafana по токенам/с. Зрелость ops.
Критика хайпа: разработчики трубят «любой движок», но добавить свой? Реализуй интерфейс, зарегистрируй в switch, докрути CRD-конфиг. Не ноль усилий. Но пять примеров задают шаблон. Лучше, чем форкать весь ре
