Kubernetes может оркестрировать GPU-нагрузки, но сам по себе не обеспечивает готовый production-инференс. В статье разобраны требования к памяти и мониторингу, приведён тестовый Pod Mistral 7B и чек-лист дальнейшей подготовки. Полный production-runbook для Llama 2 70B здесь не представлен.
Ниже — архитектурный чек-лист и минимальный тестовый Pod для Mistral 7B на одной 24-ГБ GPU. Это не полный production-манифест: Service, ingress с аутентификацией, хранилище моделей, readiness, лимиты и масштабирование нужно настроить и испытать отдельно. Цифры чужого стенда нельзя переносить на свою нагрузку.
Почему Kubernetes для инференса LLM: вызовы и преимущества
Инференс LLM порождает три критических требования: жёсткие latency SLO, предсказуемое потребление VRAM и непрерывную нагрузку на GPU. Kubernetes закрывает их через нативный GPU scheduling, автомасштабирование по кастомным метрикам и механизмы отказоустойчивости. HPA завязывается на длину очереди запросов или p95 latency, а не на утилизацию CPU - это принципиально для GPU-нагрузок.
Основные вызовы: температурный режим VRAM на RTX 3090 (96-104°C при длительном инференсе), невозможность дробного выделения GPU через Kubernetes device plugin и необходимость кастомных метрик для масштабирования. Стандартный metrics-server не даёт данных о температуре памяти или throughput в токенах - нужен стек Prometheus + NVIDIA DCGM + Prometheus Adapter.
Температурные пределы и допустимые режимы определяйте по спецификации конкретной карты. Охлаждение, мониторинг и тест стабильности нужны до круглосуточной эксплуатации; по одному значению температуры нельзя предсказать срок отказа.
Выбор и конфигурация GPU-нод: на что обратить внимание
Выбор GPU определяет всю архитектуру инференса. A100 и H100 дают максимальную производительность, но RTX 3090 остаётся рабочим вариантом для self-hosted решений благодаря 24 ГБ VRAM и цене на вторичном рынке. Плата за это — требования к охлаждению и ограничения потребительской карты. Возможность и топологию межсоединения проверяйте отдельно.
Ключевые параметры при выборе: объём VRAM (определяет максимальный размер модели), пропускная способность памяти (влияет на throughput в токенах/с), поддержка FP8/INT4 (снижает требования к памяти) и теплопакет. Для RTX 3090 критичен контроль Memory Junction Temperature - температуры чипов GDDR6X, которая на 20-30°C выше температуры GPU Core.
Температурный режим VRAM на RTX 3090: цифры и риски
Контролируйте температуру во время длительного теста и сохраняйте условия измерения: модель, dtype, batch, охлаждение и температуру помещения. GPU core и memory junction — разные датчики; один нельзя выдавать за другой.
Сравнивайте охлаждение конкретных карт по проверенным измерениям. Не используйте недоказанные сроки деградации и предполагаемые ошибки ECC как диагностику потребительской RTX 3090.
Практические рекомендации по охлаждению и размещению
Первое правило: обеспечить сквозной airflow через GPU. В серверных корпусах с вертикальной установкой карт температура VRAM снижается на 5-8°C по сравнению с горизонтальным размещением. Второе: замена термопрокладок на Thermalright Odyssey или Gelid GP-Extreme даёт снижение на 8-12°C - это подтверждённая практика сообщества для RTX 3090.
Изменение частоты памяти через nvidia-smi не является андервольтингом. Поддержка управления частотами зависит от карты и драйвера; проверяйте её до изменения настроек. Эффект на температуру и throughput измеряйте на своём стенде, универсального процента нет.
Оркестрация подов с GPU: requests, limits и nodeSelector
Kubernetes работает с GPU через NVIDIA Device Plugin, который выставляет ресурс nvidia.com/gpu. Дробное выделение GPU между подами невозможно - один под получает целую карту. Это фундаментальное ограничение, которое определяет стратегию упаковки моделей.
Для изоляции GPU-нагрузок используйте taints/tolerations и nodeSelector. Объём памяти выбирайте по конкретному checkpoint, dtype, длине контекста и числу одновременных запросов. Название семейства GPU само по себе не доказывает, что модель поместится.
Управление видеопамятью: как не упереться в лимиты
Для 70 млрд параметров FP16 только веса занимают примерно 140 млрд байт, без KV-кэша и runtime. Две RTX 3090 дают всего 48 ГБ VRAM и не подходят для такого запуска целиком на GPU. Даже арифметический подсчёт числа карт недостаточен: tensor parallelism требует совместимой архитектуры модели и резервов памяти на каждой карте.
Квантизованный checkpoint — отдельный сценарий. GGUF Q4_K_M, AWQ и GPTQ не взаимозаменяемы: проверяйте поддержку формата и GPU выбранной версией бэкенда. Размер файла около 40 ГБ не гарантирует успешный запуск на 2×24 ГБ с нужным контекстом.
Для проверки Kubernetes начните с Mistral 7B в FP16 на одной RTX 3090. До применения установите совместимые драйверы NVIDIA, container runtime и device plugin; проверьте наличие GPU-ресурса и метки gpu-type=rtx3090. Пример использует latest только для знакомства; закрепите протестированную версию или digest перед повторяемым развёртыванием.
apiVersion: v1
kind: Pod
metadata:
name: vllm-mistral-test
spec:
containers:
- name: vllm-server
image: vllm/vllm-openai:latest
args:
- --model
- mistralai/Mistral-7B-Instruct-v0.3
- --dtype
- half
- --tensor-parallel-size
- "1"
- --max-model-len
- "2048"
- --max-num-seqs
- "1"
- --gpu-memory-utilization
- "0.85"
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
gpu-type: rtx3090
tolerations:
- key: gpu
operator: Equal
value: "true"
effect: NoSchedule
Нужны исходящий доступ к репозиторию модели, свободный диск и RAM хоста для загрузки. Дождитесь готовности сервера по журналам; затем используйте kubectl port-forward pod/vllm-mistral-test 8000:8000 и в другом терминале curl http://127.0.0.1:8000/v1/models. Port-forward не заменяет production-сервис. Если загрузка не проходит, сначала проверьте совместимость версии vLLM и GPU и фактическую свободную память, не увеличивайте utilisation вслепую.
Бэкенд для инференса определяет эффективность использования VRAM. Сравнение vLLM, LMDeploy и Triton с TensorRT-LLM на H100 и B200 показывает разницу в throughput до 40% на одинаковом железе. Для RTX 3090 vLLM даёт лучший баланс между скоростью запуска и производительностью. Детальный разбор архитектур PagedAttention и continuous batching - в сравнении бэкендов для инференса LLM.
Масштабирование инференса под нагрузкой
Автомасштабирование в Kubernetes для LLM-инференса требует кастомных метрик. CPU и memory - плохие индикаторы для GPU-нагрузок. Правильные метрики: latency (p50, p95, p99), throughput в токенах/с и длина очереди запросов. HPA с Prometheus Adapter позволяет завязаться на любую из них.
Пороговые значения для масштабирования: p95 latency выше 500 мс - сигнал к добавлению реплик, длина очереди больше 5 запросов - опережающий индикатор перегрузки. Важно настроить стабилизационные окна (--horizontal-pod-autoscaler-downscale-stabilization), чтобы избежать флаппинга при кратковременных всплесках.
Метрики для масштабирования: latency, throughput и queue depth
Latency - самый прямой индикатор качества сервиса. p50 показывает типичное время ответа, p99 - хвостовые задержки, которые убивают user experience. Для чат-ботов p50 до 200 мс приемлемо, p99 до 1 секунды. Для batch-обработки пороги выше.
Throughput в токенах/с показывает эффективность использования GPU. Падение throughput при росте нагрузки - сигнал, что модель упирается в пропускную способность памяти и масштабирование не поможет, нужен тюнинг параметров инференса или смена бэкенда. Длина очереди - опережающий индикатор: рост очереди предшествует росту latency на 10-30 секунд, это время на реакцию.
Управление очередями запросов и отказоустойчивость
Всплески трафика без управления очередями приводят к OOM на GPU или таймаутам на клиенте. Три паттерна решают проблему: очередь с приоритетами (интерактивные запросы выше batch), backpressure (отказ в приёме новых запросов при заполнении очереди), circuit breaker (отключение нестабильного пода).
Интеграция с Kubernetes через Service Mesh. Istio и Envoy поддерживают rate limiting, retry budgets и circuit breaking на уровне L7. Для LLM-сервиса критичен таймаут: если модель не ответила за 30 секунд, повторный запрос только усугубит перегрузку. Настройка retry policy с экспоненциальной задержкой и ограничением числа попыток обязательна.
Ниже — иллюстрация части EnvoyFilter, не готовый манифест и не действующая защита. Здесь опущены metadata.name/namespace, выбор workload и точное место вставки HTTP-фильтра. Также отсутствуют filter_enabled и filter_enforced: без настройки включения и принудительного ограничения token bucket нельзя считать работающим rate limiter. Составьте полную конфигурацию по документации Envoy для своей версии Istio и проверьте ожидаемые HTTP 429 нагрузочным тестом.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.local_ratelimit
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
stat_prefix: http_local_rate_limiter
token_bucket:
max_tokens: 10
tokens_per_fill: 10
fill_interval: 1s
Мониторинг и алертинг: держим руку на пульсе
Prometheus, Grafana и DCGM можно использовать для мониторинга поддерживаемых GPU. Набор датчиков зависит от карты и драйвера: сначала убедитесь, что DCGM_FI_DEV_MEMORY_TEMP действительно экспортирует валидное значение на вашем оборудовании. Отсутствие метрики не означает нормальную температуру.
Ключевые метрики для дашборда: DCGM_FI_DEV_MEM_CLOCK (частота памяти), DCGM_FI_DEV_GPU_TEMP и DCGM_FI_DEV_MEMORY_TEMP (температуры), DCGM_FI_DEV_GPU_UTIL (утилизация GPU), DCGM_FI_DEV_FB_USED (использование VRAM). Со стороны инференса: request_latency_seconds (p50/p95/p99), requests_per_second, tokens_per_second.
Контроль температуры VRAM: алерты и автоматические действия
Для доступного датчика memory junction можно задать алерт через PrometheusRule. Порог и задержку выбирайте для конкретной карты. Автоматические действия требуют отдельного обработчика и проверки безопасности; у бэкенда может не быть API для изменения batch size на лету.
Ниже — иллюстрация правила, не готовый к применению PrometheusRule: нужны metadata.name/namespace, установленный CRD и подходящие ruleSelector/ruleNamespaceSelector у Prometheus. Проверьте, что метрика существует и правило действительно загружено. Порог 95°C здесь пример, его нужно согласовать со спецификацией карты. Алерт сам по себе не меняет настройки GPU и не эвакуирует Pod.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
spec:
groups:
- name: gpu-temperature
rules:
- alert: VRAMTemperatureHigh
expr: DCGM_FI_DEV_MEMORY_TEMP > 95
for: 5m
labels:
severity: warning
annotations:
summary: "VRAM temperature above 95°C on {{ $labels.node }}"
description: "GPU {{ $labels.gpu }} has VRAM temp {{ $value }}°C for 5 minutes"
Перед эвакуацией узла проверьте запас GPU на других нодах и влияние на доступность. Не применяйте универсальное значение частоты памяти: поддерживаемые команды и частоты смотрите в документации драйвера и конкретной карты.
Практический пример: приёмка тестового Mistral 7B
После успешной загрузки отправьте короткий запрос, проверьте ответ и расход VRAM. Затем измерьте время до первого токена, скорость генерации и p95 при целевой длине ответа. Увеличивайте контекст и параллельность по одному параметру, сохраняя результаты и запас памяти. Приведённый Pod не содержит Deployment, Service или HPA; не считайте их настроенными.
Для перехода к 70B потребуется отдельный подтверждённый checkpoint, поддерживаемая квантизация или существенно больший объём VRAM. До аренды узлов выполните пробную загрузку и нагрузочный тест на выбранной конфигурации. Неподтверждённые цифры 45–52 токена/с и 38,5 ГБ не являются результатом этого примера.
Для тех, кто экспериментирует с предельным сжатием моделей, интересен опыт запуска Falcon3-10B в 1.58 бита на RTX 5070 через Triton-ядра и CUDA Graph. Разбор реализации показывает 97.5 токенов/с - в 9.86 раза быстрее Transformers BitLinear. Этот подход применим и к RTX 3090 при условии контроля температуры.
Баланс стоимости и производительности: как не переплачивать
Сравнивайте облачные конфигурации по реальной VRAM, совместимости бэкенда и результатам пробной загрузки; обычный CPU VPS не заменяет GPU-ноду. Timeweb Cloud можно включить в сравнение провайдеров. Это партнёрская ссылка; конфигурацию и текущую стоимость нужно проверять под свою нагрузку, минимальный тариф не является гарантией достаточности ресурсов.
TCO инференса складывается из стоимости GPU, энергопотребления, охлаждения и администрирования. RTX 3090 на вторичном рынке стоит $600-800, потребляет 350 Вт под нагрузкой. A100 стоит $8000-10000, потребляет 400 Вт, но даёт в 2-2.5 раза больше throughput на токен. Для batch-обработки с низкими требованиями к latency RTX 3090 окупается за 3-4 месяца.
Стратегии оптимизации стоимости: spot/preemptible instances для некритичных нагрузок (экономия 60-80%), bin packing нескольких моделей на одну карту при малом потреблении VRAM, смешанные пулы нод (RTX 3090 для разработки, A100 для production). Пример расчёта TCO для кластера из 4 RTX 3090: $3200 GPU + $200/мес электричество + $100/мес охлаждение = $3600 стартовых + $300/мес операционных. Окупаемость против облачных GPU за 5-6 месяцев.
Выбор бэкенда влияет на TCO напрямую. Сравнение vLLM, LMDeploy и Triton с бенчмарками на H100 и B200 даёт чек-лист из 5 вопросов для выбора под вашу задачу. Для self-hosted RTX 3090 vLLM - оптимальный старт, Triton с TensorRT-LLM - для максимальной производительности на долгоживущих сервисах.
Отдельный сценарий - предельная оптимизация под конкретное железо. Запуск DeepSeek V4 Flash на двух RTX 4090 с портированием Blackwell-ядер на Ada через Triton даёт 105 токенов/с. Этот подход масштабируется на RTX 3090 при условии решения тепловых ограничений.