В январе 2026 года CNCF заявила: AI инференс выходит из лаборатории на фабрику. 66% компаний уже используют Kubernetes для этих нагрузок. Для многих из нас это значит, что скоро главная нагрузка в кластерах изменится — от обычных приложений к постоянному, агентному инференсу 24/7. Это не фантазия. Это уже происходит.
Введение
Обучение модели — это разовый большой проект. Запустили, посчитали, получили веса. Инференс — это постоянная работа. Модель должна отвечать быстро, дёшево и стабильно. Тысячи запросов в секунду. Агенты, которые сами вызывают другие сервисы. Минимум дашбордов для человека, главное — API. Никаких ручных ревью — всё решает автоматика. Такое представление о будущем высказал Джонатан Брайс, исполнительный директор CNCF.
Старые паттерны ломаются. То, что вчера работало для микросервисов, сегодня начинает трещать по швам. GUI-интерфейсы становятся второстепенными. Обычный scaling — недостаточным.
Kubernetes вдруг оказался в центре всего. Не потому что кто-то так решил. А потому что он уже умеет делать то, что нужно фабрике: оркестрировать, масштабировать, наблюдать, защищать. Просто теперь у него внутри — inference-движки вроде vLLM, KServe и Triton.
Эта статья для тех, кто завтра утром придёт на работу и получит задачу: «Сделайте так, чтобы наш AI работал в проде стабильно и дёшево».
Как мы дошли до этого момента, почему именно inference стал главной болью и возможностью 2026 года, какие новые проблемы он принёс DevOps-командам и, главное, что именно вам нужно сделать прямо сейчас. Ниже — разбор ситуации, чек-листы, конкретные шаги, примеры конфигурации.
Ретроспектива CNCF: от начала до 2026 года
Десять лет назад всё было скромно. В 2015 году Google передал Kubernetes в новую организацию — Cloud Native Computing Foundation. Тогда в CNCF было всего двадцать членов и один-единственный проект. Никто не произносил громких слов про «операционную систему для искусственного интеллекта». Говорили просто: оркестрация контейнеров, микросервисы, облачная инфраструктура.
Сегодня это огромная экосистема. Более 230 проектов. Более 300 000 человек, которые внесли вклад в код, документацию, тестирование или обсуждения. И главное — Kubernetes теперь официально называют де-факто операционной системой для искусственного интеллекта.
Kubernetes перестал быть просто «оркестратором контейнеров». Он стал платформой, на которой можно запускать любые динамические рабочие нагрузки. В том числе те, которые требуют GPU, TPU и постоянного инференса.
В феврале 2026 года рабочая группа Kubernetes WG Serving официально завершила свою работу. У нее была одна задача: сделать Kubernetes удобной платформой именно для инференса моделей. Задача выполнена. Группу закрыли. Это значит, что все необходимые механизмы — динамическое выделение ресурсов (DRA), поддержка специализированного оборудования, интеграция с популярными inference-движками — уже встроены в код.
Мы прошли путь от «давайте просто запустим контейнеры» до «давайте запустим фабрику искусственного интеллекта на той же самой инфраструктуре, которую уже понимаем и контролируем».
Почему inference — главный вызов и возможность одновременно
2026 год становится переломным. Компании уже не экспериментируют с искусственным интеллектом в песочнице. Они выносят его в продакшен как обычную производственную нагрузку. И здесь начинаются настоящие сложности.
Раньше вы могли позволить себе красивый дашборд, ручное ревью пул-реквестов, отдельную ML-платформу с собственным мониторингом. Теперь основным потребителем сервисов становятся не люди, а агенты. Им не нужны графики. Им нужен только чистый, стабильный API. Если ответ придёт с задержкой или ошибка повторится — агент просто упадёт или начнёт делать глупости. Поэтому стабильность API выходит на первое место: повторные попытки, предохранители, плавная деградация.
Kubernetes уже умеет всё, что требуется фабрике инференса. Он оркестрирует поды, масштабирует их автоматически, собирает метрики, применяет политики безопасности, управляет сетью. Зачем строить новую платформу с нуля, если можно взять существующий кластер Kubernetes и просто добавить на него inference-движки?
Самые популярные из них сегодня — это vLLM, KServe и Triton Inference Server. Команды разворачивают их поверх Kubernetes и сразу получают готовые механизмы автоскейлинга, наблюдаемости через Prometheus и Grafana, сетевой защиты через Istio или Envoy. Никакой новой инфраструктуры. Никакой фрагментации.
Но самое важное изменение — даже не в самих движках. Самое важное — в том, кто будет вызывать эти сервисы. На первое место выходят машиночитаемые спецификации: OpenAPI, JSON Schema, MCP. Контракты должны быть идеальными, потому что агент не сможет «просто посмотреть глазами» и понять, что пошло не так.
Это огромная возможность для тех, кто успеет перестроиться. И огромный вызов для тех, кто продолжит работать по-старому.
Возможность — потому что вы можете использовать уже готовую инфраструктуру Kubernetes и не тратить миллионы на новые инструменты.
Вызов — потому что теперь ваша платформа должна работать как настоящая фабрика: стабильно, предсказуемо и без человеческого вмешательства в каждом запросе.
Те команды, которые уже сегодня начнут переводить свои сервисы на API-first подход, внедрять автоматическое масштабирование под инференс и строить наблюдаемость именно для агентных вызовов, получат серьёзное преимущество. Остальные будут догонять.
Новые вызовы для сообщества
Теперь давайте посмотрим правде в глаза. То, что происходит в 2026 году, — это не просто «больше нагрузки». Это системный удар по всем привычным процессам разработки и поддержки open source.
Главный удар приходится на CI/CD и code review
Раньше типичный open source проект получал около двадцати пул-реквестов в день. Теперь, с инструментами искусственного интеллекта, эта цифра легко переваливает за двести. Джуниор, который раньше писал пятьдесят строк кода в день, теперь генерирует пятьсот. Каждая строка может выглядеть прилично, но общая нагрузка вырастает в разы.
Пропускная способность команды остаётся прежней. Человека нельзя обучить за неделю так, чтобы он понимал не только синтаксис, но и архитектурные компромиссы, историю решений и скрытые зависимости проекта. В итоге качество падает, а мейнтейнеры выгорают.
Джонатан Брайс из CNCF назвал это явление «Eternal September». В 1993 году, когда AOL подключил обычных пользователей к Usenet, каждый сентябрь приносил толпу новичков, которые не знали правил. Теперь «сентябрь» никогда не заканчивается. Искусственный интеллект каждый день присылает новых «первокурсников» с тоннами кода. И сообщество просто не успевает.
Вторая большая проблема — судьба самих проектов CNCF.
Kubernetes, Prometheus, Argo и множество менее известных инструментов. В эпоху AI-агентов часть из них тихо умрёт или сольётся. Почему? Потому что агент может за несколько часов сгенерировать специализированную версию инструмента, заточенную именно под вашу задачу. И поддерживать её самостоятельно. Зачем тогда тянуть универсальный проект со всей его историей компромиссов?
Выживут только те проекты, сложность которых искусственный интеллект пока не может полностью воспроизвести. Kubernetes и Prometheus, скорее всего, останутся. Многие мелкие утилиты — нет.
И здесь важно сказать честно: глава CNCF не просто описывает тренд. Он его формирует. Он заинтересован в том, чтобы экосистема оставалась релевантной.
Третий вызов — как вообще работать в таких условиях.
Старые процессы code review и ручного управления больше не так эффективны. Компании, которые это поняли, уже переходят на platform engineering как основную дисциплину. Platform-команда теперь не просто «поддерживает кластеры». Она задаёт жёсткие стандарты, guardrails и автоматизированные ворота в пайплайне. Именно она решает, какие API-контракты обязательны, какие метрики собираются и какие проверки проходят все изменения — даже те, что сгенерировал искусственный интеллект.
Вывод простой и жёсткий. 2026 год показал: искусственный интеллект резко снизил стоимость создания кода, но стоимость его проверки и поддержки осталась прежней. Кто не перестроит процессы, тот столкнется с проблемами. Кто построит правильные платформенные ограничители, тот получит преимущество.
Проблема не в самом искусственном интеллекте. Проблема в том, что мы до сих пор пытаемся решать новые задачи старыми методами.
Практическое руководство: что внедрять в 2026 году
Теперь самое главное. Всё, что было выше, — это контекст. Каждый чек-лист ниже — это готовый план действий с объяснением, почему именно это работает, и минимально необходимыми примерами конфигурации. Только то, что реально применяется в production-командах, которые уже запустили инференс на Kubernetes в 2026 году.
Чек-лист 1. Подготовка кластера к инференсу
Инференс требует GPU или TPU. Обычный scheduling здесь не работает — нужно динамически выделять устройства. Именно для этого существует Dynamic Resource Allocation (DRA).
Что делать прямо сейчас:
- Убедитесь, что кластер на Kubernetes 1.35 или новее (DRA теперь в stable-состоянии).
- Включите DRA в API-сервере (если ещё не включено).
- Разверните один из трёх проверенных inference-движков: KServe (CNCF incubating), vLLM или Triton.
- Настройте autoscaling не только по CPU, но и по кастомным метрикам (запросы в секунду, токены в секунду, загрузка GPU).
Пример минимального InferenceService на KServe с vLLM (самый популярный вариант в 2026 году):
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: my-llm-service
annotations:
autoscaling.knative.dev/min-scale: "2"
autoscaling.knative.dev/max-scale: "20"
spec:
predictor:
model:
modelFormat:
name: huggingface
storageUri: "hf://meta-llama/Meta-Llama-3-8B-Instruct"
resources:
limits:
nvidia.com/gpu: "1"
requests:
nvidia.com/gpu: "1"Чек-лист 2. Переход к безинтерфейсному API, удобному для агентов
С 2026 года главный клиент ваших сервисов — не человек, а другой агент искусственного интеллекта. Ему не нужны панели мониторинга. Ему нужен только стабильный API.
Что делать:
- Все новые и переписываемые сервисы переводите на подход API-first: OpenAPI v3 + полная JSON Schema.
- Обязательно добавляйте повторные попытки, ограничение запросов и предохранители.
- Графические интерфейсы — теперь только для отладки.
В Istio повторные попытки и предохранители — это два разных объекта. Первые живут в VirtualService, а предохранитель — только в DestinationRule. Вот оба, которые нужно применять вместе:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: llm-virtualservice
spec:
hosts:
- my-llm-service
http:
- retries:
attempts: 3
perTryTimeout: 5s
retryOn: gateway-error,connect-failure,retriable-4xx
route:
- destination:
host: my-llm-serviceapiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: llm-circuit-breaker
spec:
host: my-llm-service
trafficPolicy:
connectionPool:
http:
http1MaxPendingRequests: 100
maxRequestsPerConnection: 10
outlierDetection:
consecutive5xxErrors: 5
interval: 10s
baseEjectionTime: 30sБез этого агент будет падать при малейшей задержке, и вся цепочка агентов рухнет.
Чек-лист 3. Защита от хаоса в разработке с поддержкой ИИ
Искусственный интеллект генерирует код в десять раз быстрее, чем вы можете его проверять. Без защитных механизмов вы утонете.
Что делать:
- Platform-команда вводит обязательные стандартные маршруты разработки и движки политик (Kyverno или OPA/Gatekeeper).
- В CI/CD подключите автоматических ревьюеров — например, Danger, Reviewdog или GitHub Actions с кастомными проверками — которые хотя бы отсекают очевидный мусор до живого ревью.
- Все изменения проходят через автоматические проверки: обязательные метки, ограничения ресурсов, OpenAPI-валидация.
Пример политики Kyverno, которая запрещает запуск inference-подов без явно указанных GPU-лимитов. Проверяем именно limits — без этого планировщик не гарантирует выделение устройства:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-gpu-limits-for-inference
spec:
validationFailureAction: Enforce
rules:
- name: check-gpu-limits
match:
any:
- resources:
kinds:
- Pod
selector:
matchLabels:
app.kubernetes.io/component: inference
validate:
message: "Inference pods must explicitly set nvidia.com/gpu in resources.limits"
pattern:
spec:
containers:
- resources:
limits:
nvidia.com/gpu: "?*"Чек-лист 4. Наблюдаемость именно для инференса
Обычные метрики больше не работают. Вам нужно видеть токены в секунду, задержку на уровне отдельных запросов и загрузку GPU в реальном времени.
Что делать:
- Внедрите OpenTelemetry для всех inference-сервисов.
- Собирайте эти метрики обязательно:
- запросы в секунду
- токены в секунду
- задержка p99
- загрузка GPU и использование памяти
- Настройте оповещения не на CPU, а на эти бизнес-метрики.
Если у вас в кластере стоит Prometheus Operator (а в 2026 году это стандарт), метрики подключаются через объект ServiceMonitor:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: kserve-inference-monitor
namespace: monitoring
labels:
release: prometheus # должен совпадать с selector в вашем Prometheus CR
spec:
namespaceSelector:
matchNames:
- default # namespace, где живёт InferenceService
selector:
matchLabels:
serving.kserve.io/inferenceservice: my-llm-service
endpoints:
- port: http
path: /metrics
interval: 15sС этими метриками вы увидите, где именно тормозит агентная цепочка, а не просто «CPU высокий».
Заключение и прогноз на 2026–2027
Главный вывод очень простой. Во-первых, переводите все сервисы на API-first подход. Во-вторых, стройте платформенное управление с жёсткими guardrails. Именно эти два шага отделяют команды, которые будут управлять фабрикой инференса, от тех, кто будет тонуть в хаосе.
В 2026–2027 годах мы увидим три больших изменения.
- Взрывной рост platform engineering — теперь это не модное слово, а обязательная дисциплина.
- AI-assisted CI/CD станет нормой: код будут генерировать машины, а проверять — тоже машины под контролем платформенных политик.
- Произойдёт серьёзная консолидация: из двухсот сорока проектов CNCF многие тихо исчезнут или сольются. Останутся только те, без которых фабрика не работает.
Искусственный интеллект не уничтожит open source и точно не отнимет вашу работу. Он просто заставит стать быстрее, жёстче и практичнее.