gke-inference

Навык gke-inference предназначен для развёртывания и оптимизации AI/ML inference-нагрузок в Google Kubernetes Engine. Источник рассматривает обслуживание моделей на GKE через Google Inference Quickstart и связанные практики для LLM serving. Область включает GPU, TPU и model servers; среди примеров моделей названы Llama, Gemma и Mistral. Навык подходит, когда нужно найти поддерживаемую связку модели и ускорителя, сгенерировать Kubernetes manifest для inference, выбрать сервер модели или настроить масштабирование. Он прямо не предназначен для обычных batch jobs и HPC task queues: для такой задачи источник указывает отдельный gke-batch-hpc skill. До начала работы нужны golden path GKE Autopilot cluster, а GPU-нагрузки в этом сценарии используют ComputeClasses и Node Auto Provisioning. Также требуется аутентифицированный gcloud CLI и достаточная GPU/TPU quota в выбранном регионе. Первый этап — discovery: команда gcloud container ai profiles models list показывает поддерживаемые модели, а команда gcloud container ai profiles list --model=<MODEL_NAME> помогает найти допустимые сочетания модели, accelerator и model server. В источнике приведён пример поиска профиля для gemma-2-9b-it. Это важная проверка перед генерацией manifest: нельзя считать любую комбинацию модели, сервера и ускорителя совместимой без результата профиля. Manifest создаётся командой gcloud container ai profiles manifests create. В ней задаются модель, сервер, тип ускорителя и необязательный target normalized time per output token. Источник перечисляет vllm, tgi, triton и tensorrt-llm как примеры model servers, а среди accelerator type — nvidia-l4, nvidia-tesla-a100 и nvidia-h100-80gb. После генерации файл inference.yaml нужно просмотреть на placeholders, включая HF tokens и PVCs, затем применить через kubectl apply -f и наблюдать за pod через kubectl get pods -w и kubectl logs -f. Некоторые модели требуют Hugging Face token; источник рекомендует создать Kubernetes Secret и сослаться на него в manifest, а не помещать секрет в открытый файл. Отдельный сценарий посвящён ComputeClass для Autopilot: в примере задаётся g2 machine family, один NVIDIA L4, минимальные четыре CPU cores и 16 GB памяти. Таблица ускорителей сопоставляет варианты с типичными задачами и ориентировочными характеристиками: NVIDIA T4 с 16 GB для бюджетного inference, NVIDIA L4 с 24 GB для небольших и средних моделей, RTX PRO 6000 с 96 GB для multimodal AI и high-fidelity 3D, A100 с 40 или 80 GB для больших моделей, H100/H200 с 80 или 141 GB для высокопроизводительных задач, а B200 и GB200 — для масштабных сценариев. Для Cloud TPU приведены v5e, v5p, v6e Trillium и v7x Ironwood, но значения памяти и относительной стоимости в источнике зависят от варианта. Эти данные помогают сформировать shortlist, но не заменяют проверку доступности в регионе и конкретной profile-комбинации. Масштабирование LLM inference в исходнике строится вокруг HorizontalPodAutoscaler и custom pod metric gpu_duty_cycle: пример задаёт minReplicas 1, maxReplicas 10 и среднее значение 80. В рекомендациях отдельно упомянуты DCGM metrics, выбор minReplicas для always-on или on-demand нагрузки, более длинное scale-down stabilization из-за медленной загрузки модели и queue depth для latency-sensitive запросов. Для оптимизации названы quantized models GPTQ и AWQ, batching, tensor parallelism для распределения большой модели между GPU и настройка --gpu-memory-utilization в vLLM для KV cache. Эти методы имеют trade-offs между задержкой, пропускной способностью, памятью и стоимостью; навык не обещает универсальное значение параметра. Ограничения и диагностика также являются частью назначения. Invalid model/accelerator tuple означает, что нужно повторно проверить profile; превышение GPU quota требует запроса увеличения или другого региона; OOM на GPU указывает на необходимость большего ускорителя, quantization или tensor parallelism; медленный cold start связан с загрузкой большой модели, для него источник предлагает local SSD и pre-pull images. В результате gke-inference полезен для последовательного выбора модели и оборудования, генерации manifest, безопасной проверки placeholders и наблюдения за rollout. Перед применением любого ресурса нужно подтвердить cluster, регион, quota, образ сервера и секреты; сам навык не выполняет security-аудит кластера и не превращает примерный YAML в готовую production-конфигурацию без проверки окружения.