Зачем Kubernetes именно для LLM
Инференс языковых моделей — капризная нагрузка: GPU-узлы дорогие, трафик рваный (днём ассистенты, ночью батч-обработка), а модели обновляются часто. Kubernetes — открытая система оркестрации контейнеров — закрывает это тремя механизмами: планировщик размещает поды по доступным GPU и не даёт нагрузке «подавить» соседей; масштабирование добавляет реплики инференса под пик и убирает их ночью; обновления проходят вкатыванием новой версии рядом со старой — без остановки сервиса.
Честная граница применимости: если у вас один-два GPU-сервера и одна модель — vLLM как systemd-сервис проще и дешевле. Kubernetes оправдан, когда моделей и сервисов несколько, узлов больше трёх, а обновления — обычное дело.
Что оркеструем на K8s в ИИ-проектах
- Инференс: деплойменты vLLM/Ollama с лимитами GPU, несколькими репликами под пик, политиками обновления моделей.
- RAG-слой: Qdrant/Milvus и PostgreSQL c pgvector — как stateful-нагрузки с томами и бэкапами.
- API-слой: FastAPI-сервисы — масштабируются отдельно от моделей, потому что их нагрузка другая.
- Батч-задачи: ночная транскрибация, переиндексация корпусов, прогон OCR — задания на свободных мощностях по расписанию.
- Мониторинг: утилизация GPU, длины очередей, латентности и стоимость токенов — метрики, по которым живёт SLA.
Как применяем: этапы и схема
- Обследование инфраструктуры. Существующие кластеры, GPU-парк, сеть и хранилища; требования ИБ к периметру.
- Проект контура. Разделение узлов (системные / CPU-нагрузка / GPU), размеры пулов, схема хранения моделей (реестр образов), лимиты и квоты по командам.
- Развёртывание платформы. Кластер Kubernetes — upstream или российская платформа (Deckhouse, «Штурвал»); устройство GPU через плагин устройства NVIDIA; проверка планировщика на тестовых подах.
- Поставка сервисов. Helm-чарты: инференс (vLLM), RAG-слой, API, мониторинг; канареечные обновления моделей.
- Нагрузочные испытания. Профиль трафика заказчика → коэффициенты автоскейлинга; проверка отказов узлов.
- Передача эксплуатации. Runbooks, регламенты обновления моделей, мониторинг-дашборды, обучение команды заказчика.
Текстовая схема: запрос → Ingress → API-сервис (реплики CPU) → очередь → инференс-поды (GPU-пул, автоскейлинг) → ответ; рядом — RAG-хранилища и реестр моделей; всем управляет планировщик K8s.
| Формат | Цена | Срок |
|---|---|---|
| Аудит инфраструктуры и проект GPU-контура | от 90 000 ₽ | 3–5 рабочих дней |
| Пилот: кластер + инференс + один сервис | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: платформа, мониторинг, регламенты | 0,9–1,2 млн ₽ | 4–6 недель |
| Сопровождение кластера и сервисов | от 50 000 ₽/мес | ежемесячно |
Совместимость с нашим стеком
Всё, что мы внедряем, контейнеризуется по умолчанию: инференс через vLLM или Ollama для лёгких случаев, RAG-хранилища, API-слой на FastAPI, ASR-воркеры для транскрибации. Модели — GigaChat API для облачного сценария или открытые веса (Qwen, Llama, GigaChat Lite) на своих GPU — о выборе и лицензиях на странице open-source LLM для бизнеса.
Для 1С-ландшафтов K8s-контур остаётся за периметром учётной системы: 1С зовёт те же HTTP-эндпоинты, ей безразлично, что за ними — Bare-metal или кластер. Это позволяет внедрять ИИ-слой, не трогая аттестованные контуры.
Лицензии и импортозамещение
Сам Kubernetes — проект CNCF под лицензией Apache-2.0, бесплатен и без вендорской привязки. Для госзаказчиков важнее платформа управления: в реестре российского ПО есть отечественные платформы на базе Kubernetes — например, Deckhouse (ГК «Флант») и «Штурвал» («Лаборатория Числитель»); они дают сертифицированную сборку, российскую поддержку и совместимость с требованиями регуляторов. В закупочной документации корректно указывать именно платформу управления как реестровый продукт, а upstream-компоненты — как открытые технологии в составе.
Импортозамещение железа — отдельная тема: доступны российские и китайские GPU-ускорители; их совместимость с инференс-стеком проверяем на стенде до закупки — материал о доступности ускорителей и полной стоимости владения есть на сайте в обзоре российских GPU для инференса.
Тонкости, которые всплывают в проектах
Первое — фрагментация GPU: под, занявший карту на 20%, всё равно держит её целиком; размеры подов и модели подбираем под карты, иначе пул «утечёт». Второе — холодный старт инференса: загрузка весов занимает минуты, поэтому автоскейлинг держит тёплые реплики и масштабируется заранее под известные пики (утренний вход пользователей). Третье — драйверы: версионная связка «драйвер NVIDIA + CUDA + образ инференса» фиксируется и проверяется на стенде. Четвёртое — не оркеструйте то, что не нужно: простой внутренний сервис из одного контейнера на K8s — иногда лишний слой. Мы честно скажем, если ваш случай такой.
Пример конфигурации: пулы и лимиты под инференс
Рабочий пример из проекта: три пула узлов. Системный пул (CPU) — мониторинг, реестр образов, контроллеры; сюда ИИ-нагрузке ход запрещён квотами. Пул CPU-нагрузки — API-сервисы, RAG-слой, очереди: масштабируются свободно, GPU не занимают. GPU-пул — только инференс и батч-задачи; каждый под заявляет конкретный объём видеопамяти через limits, планировщик упаковывает поды по картам и не даёт «съесть» чужой ресурс.
Правила, которые экономят нервы: автоскейлинг инференса — по метрике длины очереди, а не по CPU (GPU-поды почти не грузят процессор, классические метрики врут); тёплые реплики — минимум одна всегда, чтобы утренний пик не ждал загрузки весов; ночная батч-обработка запускается с приоритетом ниже интерактивного трафика — днём карты обслуживают пользователей, ночью — переиндексацию и транскрибацию архивов.
Обновление модели выглядит так: образ с новыми весами выкатывается в отдельный деплоймент, прогревается, получает канареечную долю трафика, метрики качества и латентности сравниваются — и только затем старая версия сворачивается. Откат — той же механикой в обратную сторону, за минуты, без ночных звонков администратору.
Несколько слов про дисциплину версионирования, без которой кластер быстро деградирует. Всё, что крутится в контуре, описано манифестами в репозитории: деплойменты, лимиты, конфигурации автоскейлинга, версии образов. Ручные правки «в бою» запрещены процессом — любое изменение идёт через репозиторий и ревью. Это даёт восстановление контура с нуля за часы, а не дни, и историю: когда, что и зачем менялось в GPU-пуле.
Отдельно ведём журнал моделей: какая версия весов, каким чартом выкачана, на какой доле трафика, с какими метриками. Через полгода, когда возникнет вопрос «а почему качество ответов изменилось», этот журнал отвечает за минуту — без археологии по логам подов.
Про связь с 1С и корпоративными системами ещё раз: они не переезжают в кластер и не меняются. ИИ-контур на Kubernetes остаётся набором веб-сервисов с той стороны периметра; учётные системы зовут их по HTTPS, как любой внешний сервис. Это позволяет вводить ИИ-функции постепенно, не трогая аттестованные контуры и не переучивая пользователей — они просто получают новые кнопки в привычных интерфейсах.
И про начало пути: если кластера нет, а GPU уже куплены, разумный старт — vLLM на голом железе с контейнеризацией, а Kubernetes подключить вторым этапом, когда сервисов станет больше одного. Такой порядок не выбрасывает ни одной вложенной копейки и не тормозит первый результат.
Как стартуем
- Пришлите состав GPU-парка и перечень сервисов — за день оценим, нужен ли K8s вообще.
- На стенде развернём минимальный контур: один инференс + API + мониторинг, прогон вашего трафика.
- Смета пилота — от 480 000 ₽ за 4–6 недель; выбор платформы (upstream или реестровая) — по вашим требованиям ИБ.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.