Паттерны Kubernetes для LLM-нагрузок: что меняется

Типичное облачно-нативное приложение на Kubernetes строится по хорошо известной схеме.

Итого шесть паттернов Kubernetes в действии: Controller, Stateless Service, Init Container, Stateful Service, Batch Job, Daemon Service.

Нагрузка с LLM использует те же паттерны, но представляет собой принципиально иной тип рабочей нагрузки.

Модель — это не бинарный файл приложения. Это десятки или сотни гигабайт выученных параметров, данные только для чтения, которые необходимо загрузить в память GPU, прежде чем сервер сможет обработать хотя бы один запрос. Llama 70B от Meta весит около 140 ГБ в полной точности (FP16) или 35–40 ГБ при 4-битном квантовании. Загрузка занимает минуты, а не секунды.

Модели требуется специальное железо: узел с нужным GPU, достаточный объём VRAM (Video RAM — память на GPU, где хранятся веса модели и промежуточные вычисления), а иногда и конкретная топология GPU-интерконнекта.

Инициализация тоже выглядит иначе. В традиционном приложении init-контейнер скачивает конфигурационный файл или выполняет миграцию — несколько мегабайт, дело секунд. В стеке с LLM аналогичный шаг загружает десятки или сотни гигабайт весов модели. После того как веса на месте, сервер модели (vLLM, TGI) проходит многофазный запуск: загружает веса в VRAM, компилирует CUDA-графы и предварительно выделяет KV-кэш (область памяти, где модель хранит вычисленные состояния механизма внимания, чтобы не пересчитывать их для каждого нового токена). Всё это занимает минуты. Ваш startup probe должен иметь failureThreshold: 60 при periodSeconds: 10 — то есть бюджет ожидания в 10 минут.

Профиль запросов тоже отличается. В традиционном веб-сервисе запросы имеют примерно одинаковую стоимость, и балансировка по round-robin работает. LLM-инференс нарушает это допущение: запрос на 10 токенов выполняется за 200 мс, а запрос на 4 000 токенов занимает GPU на 30 секунд. При этом оба приходят как идентичные запросы POST /v1/chat/completions. Round-robin создаёт горячие точки.

Сигналы для масштабирования тоже перестают работать. Стандартный HPA по CPU плохо подходит для GPU-инференса. Нужно масштабирование по метрикам, специфичным для LLM: глубина очереди токенов (vllm:num_requests_waiting), время до первого токена (time-to-first-token), утилизация KV-кэша.

Масштабирование до нуля (scale-to-zero) практически нереализуемо, когда загрузка модели занимает пять минут.

Меняется и инфраструктурный слой. Вместо Node Exporter и Fluentd теперь запускаются: NFD (Node Feature Discovery) для маркировки железа, GFD (GPU Feature Discovery) для добавления меток модели GPU и объёма VRAM, NVIDIA device plugin для предоставления nvidia.com/gpu как планируемого ресурса и DCGM exporter (Data Center GPU Manager) для передачи GPU-метрик в Prometheus. Это ваш новый стек DaemonSet, формирующий GPU-инфраструктурный слой.

Такие проекты, как KServe (инкубируется в CNCF), решают эти задачи, применяя паттерн Controller к обслуживанию моделей. Вы описываете InferenceService CRD, декларируете модель, среду выполнения и политику масштабирования — а KServe выполняет согласование: создаёт Deployment, Service, инициализатор хранилища, настраивает startup-пробы и планирование на GPU.

Несмотря на всё это, фундамент остаётся прежним. Controller, Stateless Service, Init Container, Stateful Service, Batch Job, Daemon Service — все паттерны на месте. Параметры изменились, но паттерны выдержали.

Многие паттерны Kubernetes применяются к нагрузкам с LLM без принципиальных изменений. Паттерн работает как есть — его просто нацеливают на другую нагрузку.

Это прямые соответствия. Примитив Kubernetes остаётся тем же, но нагрузка за ним меняется: веб-приложения и базы данных уступают место серверам моделей, векторным базам данных и GPU-инфраструктуре.