Запуск больших языковых моделей в production требует баланса между производительностью, стоимостью и отказоустойчивостью. Kubernetes решает эти задачи через оркестрацию GPU-нод, автоматическое масштабирование и управление очередями запросов. Этот runbook основан на реальном опыте построения инфраструктуры для Llama 2 70B и Mistral 7B на RTX 3090 с фокусом на контроль температуры VRAM, настройку HPA и мониторинг через Prometheus + Grafana.
Материал даёт готовые конфигурации, бенчмарки и конкретные цифры для принятия решений. Вы узнаете, почему VRAM на RTX 3090 достигает 104°C при инференсе, как настроить алерты до того, как GPU начнёт деградировать, и как выжать 97.5 токенов/с на квантизованных моделях. Статья продолжает серию материалов о production-инференсе: выбор бэкенда, работа с очередями и балансировка TCO.
Почему 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.
Отдельный риск - деградация GDDR6X при температурах выше 100°C. Tj max составляет 110°C, но практика сообщества определяет безопасный диапазон до 95°C для круглосуточной работы. Инференс создаёт стационарный тепловой режим без окон охлаждения, что даёт +10-15°C к игровым температурам. Без мониторинга и алертинга вы рискуете потерять GPU за 6-12 месяцев.
Выбор и конфигурация GPU-нод: на что обратить внимание
Выбор GPU определяет всю архитектуру инференса. A100 и H100 дают максимальную производительность, но RTX 3090 остаётся рабочим вариантом для self-hosted решений благодаря 24 ГБ VRAM и цене на вторичном рынке. Плата за это - температурный режим и отсутствие NVLink.
Ключевые параметры при выборе: объём VRAM (определяет максимальный размер модели), пропускная способность памяти (влияет на throughput в токенах/с), поддержка FP8/INT4 (снижает требования к памяти) и теплопакет. Для RTX 3090 критичен контроль Memory Junction Temperature - температуры чипов GDDR6X, которая на 20-30°C выше температуры GPU Core.
Температурный режим VRAM на RTX 3090: цифры и риски
Реальные замеры через GPU-Z (поле Memory Junction Temperature) дают чёткую картину. Mistral 7B в FP16 с batch size 1 после 20 минут инференса: VRAM 86-92°C, GPU Core 62-68°C. Llama 2 70B в Q4_K_M после 30+ минут: VRAM 96-104°C, GPU Core 70-78°C. Разброс в 6-8°C между одинаковыми картами обусловлен качеством термопрокладок, airflow в корпусе и ambient-температурой в дата-центре.
Founders Edition греется на 3-5°C сильнее кастомных версий (ASUS TUF, MSI Suprim X) из-за консервативного профиля вентиляторов. При длительной работе выше 100°C ускоряется деградация чипов памяти - это не мгновенный отказ, а постепенное накопление ошибок ECC и снижение стабильности на высоких частотах.
Практические рекомендации по охлаждению и размещению
Первое правило: обеспечить сквозной airflow через GPU. В серверных корпусах с вертикальной установкой карт температура VRAM снижается на 5-8°C по сравнению с горизонтальным размещением. Второе: замена термопрокладок на Thermalright Odyssey или Gelid GP-Extreme даёт снижение на 8-12°C - это подтверждённая практика сообщества для RTX 3090.
Третье: андервольтинг памяти через nvidia-smi -lmc. Снижение частоты VRAM на 200-400 МГц уменьшает температуру на 4-6°C при потере throughput не более 3-5%. Для инференса, упирающегося в пропускную способность памяти, это компромисс, который часто оправдан. Четвёртое: мониторинг температуры на уровне Kubernetes через DCGM - обязательный этап, без него вы работаете вслепую.
Оркестрация подов с GPU: requests, limits и nodeSelector
Kubernetes работает с GPU через NVIDIA Device Plugin, который выставляет ресурс nvidia.com/gpu. Дробное выделение GPU между подами невозможно - один под получает целую карту. Это фундаментальное ограничение, которое определяет стратегию упаковки моделей.
Для изоляции GPU-нагрузок используйте taints и tolerations на нодах с GPU, а также nodeSelector для привязки конкретных моделей к конкретным картам. Пример: Llama 2 70B требует RTX 3090 или A100 с минимум 40 ГБ VRAM, Mistral 7B работает на картах с 16 ГБ.
Управление видеопамятью: как не упереться в лимиты
Потребление VRAM зависит от размера модели и метода квантизации. Llama 2 70B в FP16 требует около 140 ГБ - это 6 карт RTX 3090. В Q4_K_M - около 40 ГБ, что укладывается в 2 карты. Стратегии: одна модель на GPU (проще, но дороже), шардирование через tensor parallelism (vLLM/TGI поддерживают из коробки), offloading части слоёв в CPU RAM (снижает throughput, но позволяет запустить модель на меньшем числе карт).
Пример YAML для пода с Llama 2 70B на двух RTX 3090:
apiVersion: v1
kind: Pod
spec:
containers:
- name: vllm-server
image: vllm/vllm-openai:latest
resources:
limits:
nvidia.com/gpu: 2
env:
- name: MODEL_NAME
value: "meta-llama/Llama-2-70b-chat-hf"
- name: TENSOR_PARALLEL_SIZE
value: "2"
- name: DTYPE
value: "float16"
nodeSelector:
gpu-type: rtx3090
tolerations:
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoSchedule"
Бэкенд для инференса определяет эффективность использования 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 с экспоненциальной задержкой и ограничением числа попыток обязательна.
Пример конфигурации Envoy для rate limiting:
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 + NVIDIA DCGM даёт полную картину по GPU-нодам. DCGM экспортирует метрики температуры GPU Core и Memory Junction Temperature, утилизации GPU, потребления VRAM и энергопотребления. Prometheus Operator упрощает развёртывание и настройку ServiceMonitor.
Ключевые метрики для дашборда: 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: алерты и автоматические действия
Алерт на температуру VRAM настраивается через PrometheusRule. Порог: DCGM_FI_DEV_MEMORY_TEMP > 95°C в течение 5 минут. При срабатывании возможны автоматические действия: уменьшение batch size через API бэкенда, снижение частоты памяти через nvidia-smi на ноде, эвакуация подов с GPU-ноды с cordon и drain.
Пример PrometheusRule:
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"
Эвакуация подов - крайняя мера. Перед ней попробуйте снизить частоту памяти: nvidia-smi -i GPU_ID -lmc 8000 (понижение с 9750 МГц до 8000 МГц). Это снизит температуру на 6-10°C при потере throughput 5-10%.
Практический пример: конфигурация для Llama 2 70B на RTX 3090
Полный комплект конфигураций для запуска Llama 2 70B Q4_K_M на двух RTX 3090 через vLLM. Dockerfile собирает образ с vLLM и поддержкой AWQ/GPTQ квантизации. Deployment запрашивает 2 GPU, Service выставляет порт 8000, HPA масштабирует по длине очереди.
Результаты бенчмарков после 30 минут стабильной работы: throughput 45-52 токенов/с на decode, p50 latency 320 мс, p95 780 мс, VRAM 96-102°C на первой карте и 94-100°C на второй (разница из-за положения в корпусе). GPU Core держится на 70-76°C. Потребление VRAM: 38.5 ГБ из 48 ГБ доступных.
Тюнинг для снижения температуры: уменьшить max_num_seqs с 256 до 128 (снижает нагрузку на память), включить enforce_eager=False для использования CUDA graphs (ускоряет decode на 15-20%), выставить gpu_memory_utilization=0.85 чтобы оставить резерв для фрагментации KV-кэша. Эти настройки снижают VRAM на 3-5°C без заметной потери throughput.
Для тех, кто экспериментирует с предельным сжатием моделей, интересен опыт запуска Falcon3-10B в 1.58 бита на RTX 5070 через Triton-ядра и CUDA Graph. Разбор реализации показывает 97.5 токенов/с - в 9.86 раза быстрее Transformers BitLinear. Этот подход применим и к RTX 3090 при условии контроля температуры.
Баланс стоимости и производительности: как не переплачивать
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 при условии решения тепловых ограничений.