Infrastruktura Agentic AI - planowanie GPU, autoskalowanie i kontrola kosztów na Kubernetes

W 2026 roku „AI w produkcji” to już nie pojedynczy endpoint inferencyjny. Zespoły budują systemy agentowe - LangChain, CrewAI, AutoGen, własne frameworki - które koordynują wiele wywołań LLM, korzystają z narzędzi (web search, bazy wektorowe, API), i autonomicznie wykonują złożone zadania. Infrastruktura dla takich systemów to zupełnie inne wyzwanie niż standardowy deployment modelu.

Problem polega na tym, że GPU kosztują. Instancja p5.48xlarge (8x H100) to ~$98/godzinę na AWS. Źle zaplanowane autoskalowanie oznacza albo niedostępność (agenci czekają na GPU), albo astronomiczne rachunki (GPU stoi bezczynnie między zadaniami). Ten artykuł pokazuje, jak znaleźć równowagę.

Architektura agentic AI na Kubernetes - podział na warstwy

System agentowy składa się z trzech logicznych warstw, z których każda ma inne wymagania infrastrukturalne:

Kluczowy insight: Warstwa orchestracji jest tania (CPU), ale jest uruchomiona ciągle. Warstwa wnioskowania jest droga (GPU), ale żyjąca krótko. Optymalny design oddziela je na osobne pule nodów z niezależnym skalowaniem.

GPU scheduling na Kubernetes - jak to działa

Zasoby GPU w Kubernetes

GPU na Kubernetes to zasób rozszerzony (extended resource). Pod żąda GPU przez resources.limits:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: vllm-inference
    image: vllm/vllm-openai:latest
    resources:
      limits:
        nvidia.com/gpu: 1
      requests:
        nvidia.com/gpu: 1
        memory: "32Gi"
        cpu: "4"

Kluczowe zasady uruchamiania GPU:

• GPU nie jest dzielone między pody (domyślnie) - jeden pod = jeden GPU (lub więcej)
• GPU nie można „częściowo” przydzielić (bez MIG lub time-slicing)
• Jeśli nie ma dostępnego GPU na żadnym nodzie - pod czeka w stanie Pending

NVIDIA Device Plugin i GPU Operator

Na EKS, GKE i AKS potrzebujesz:

1. NVIDIA Device Plugin - eksponuje GPU jako zasób Kubernetes
2. NVIDIA GPU Operator (opcjonalnie) - automatycznie instaluje sterowniki i plugin
3. Node labels - identyfikacja typu GPU na nodach (nvidia.com/gpu.product=NVIDIA-A100-SXM4-80GB)

Na EKS z Karpenter (rekomendowane podejście):

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g5.xlarge", "g5.2xlarge", "g5.4xlarge"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: gpu-nodes
  limits:
    nvidia.com/gpu: 8
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m

Multi-Instance GPU (MIG) - dzielenie jednego GPU

NVIDIA A100 i H100 obsługują MIG - podział jednego fizycznego GPU na mniejsze instancje. To pozwala uruchomić kilka mniejszych modeli na jednym GPU zamiast rezerwować cały chip dla jednego poda.

Kiedy używać MIG:

• Wiele małych modeli (embedding models, klasyfikatory) na jednym nodzie
• Środowiska dev/test, gdzie pełne GPU to marnotrawstwo
• Agenci z wieloma wyspecjalizowanymi modelami (jeden do klasyfikacji, inny do generacji)

Kiedy NIE używać MIG:

• Duże modele (70B+ parametrów), które potrzebują całego VRAM
• Workload wymagający pełnej przepustowości pamięci GPU
• Produkcyjne wnioskowanie z wymaganiami na niski czas odpowiedzi

GPU Time-Slicing - alternatywa dla MIG

Time-slicing pozwala wielu podom współdzielić jeden GPU na zasadzie rotacji czasowej. Prostsze niż MIG (nie wymaga specyficznego hardware), ale z gorszą izolacją:

# NVIDIA Device Plugin ConfigMap - time-slicing
apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin
data:
  config: |
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4

To tworzy 4 „wirtualne” GPU z jednego fizycznego. Każdy pod dostaje 1/4 czasu GPU. Dobre dla dev/test i lekkich modeli, ale nie dla produkcyjnego wnioskowania wrażliwego na czas odpowiedzi.

Autoskalowanie pod agentic AI

Problem: klasyczny HPA nie działa dla środowiska GPU

Horizontal Pod Autoscaler (HPA) bazuje na metrykach CPU/RAM. Dla środowiska GPU to nie wystarczy:

• GPU utilization nie jest domyślnie eksportowana do serwera metryk
• Czas odpowiedzi wnioskowania jest lepszą metryką niż GPU utilization
• Agenci generują skokowy ruch - 0 requestów przez minutę, potem 50 naraz

KEDA - skalowanie event-driven

KEDA (Kubernetes Event-Driven Autoscaling) lepiej obsługuje środowiska agentowe:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: inference-scaler
spec:
  scaleTargetRef:
    name: vllm-deployment
  minReplicaCount: 1
  maxReplicaCount: 4
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: vllm_pending_requests
      query: sum(vllm:num_requests_waiting)
      threshold: "10"
  - type: prometheus
    metadata:
      metricName: vllm_gpu_cache_usage
      query: avg(vllm:gpu_cache_usage_perc)
      threshold: "80"

Metryki do skalowania wnioskowania:

• vllm:num_requests_waiting - liczba żądań w kolejce (najlepsza metryka dla skalowania w górę)
• vllm:gpu_cache_usage_perc - wykorzystanie KV-cache (sygnał, że model jest pod presją)
• vllm:avg_generation_throughput_toks_per_s - przepustowość (sygnał, że skalowanie w dół jest bezpieczne)

Karpenter - skalowanie puli nodów pod GPU

Karpenter (AWS) lub Node Auto-Provisioner (GKE) dynamicznie dodaje i usuwa nody GPU:

Dlaczego Karpenter, a nie Cluster Autoscaler:

• Karpenter podejmuje decyzje w sekundach (CA: minuty)
• Karpenter wybiera optymalny typ instancji z listy (nie wymaga predefiniowanych node group)
• Karpenter natywnie obsługuje Spot z fallbackiem na on-demand
• Karpenter konsoliduje - jeśli dwa nody są w połowie puste, migruje pody i wyłącza jeden

Kluczowe ustawienie: consolidateAfter: 5m oznacza, że GPU node zostanie wyłączony po 5 minutach bezczynności. Dla środowiska agentowego, które ma bursts co kilkanaście minut, warto rozważyć consolidateAfter: 15m - żeby uniknąć cyklu on/off.

Scale-to-zero dla GPU

Najtańszy GPU to wyłączony GPU. Dla środowisk, które nie wymagają natychmiastowej odpowiedzi:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  minReplicaCount: 0  # scale to zero!
  cooldownPeriod: 300  # 5 minut po ostatnim requeście
  triggers:
  - type: prometheus
    metadata:
      metricName: inference_requests_total
      query: sum(rate(inference_requests_total[2m]))
      threshold: "1"

Cold start problem: Uruchomienie poda z modelem LLM trwa 30-120 sekund (ładowanie wag do VRAM). Dla agentów, którzy wywołują wnioskowanie sporadycznie, akceptowalny kompromis. Dla produkcyjnych API z wymaganiem <1s - minimum 1 replika musi być zawsze aktywna.

Kontrola kosztów GPU na Kubernetes

Ile kosztują GPU w chmurze

Przy 730h/miesiąc, jedna instancja g5.xlarge on-demand kosztuje ~$737/miesiąc. Na Spot: ~$255-365/miesiąc. Różnica jest kolosalna.

Strategie oszczędności

1. Spot Instances z graceful shutdown

Dla wnioskowania, które toleruje 30-sekundowe przerywanie:

• Karpenter z capacity-type: ["spot", "on-demand"] - preferuje Spot, fallback na on-demand
• vLLM/TGI obsługują graceful shutdown - kończą aktualny request przed wyłączeniem
• Agenty frameworki (LangChain, CrewAI) z wbudowanym retry - jeśli wnioskowanie zwróci błąd, ponawiają

2. Right-sizing modeli

Nie każdy agent potrzebuje GPT-4 class model. Hierarchia:

• Klasyfikacja/routing: mały model (Phi-3-mini, 3.8B) - zmieści się na T4/L4
• Proste generowanie: średni model (Llama 3.1 8B) - jeden A10G
• Złożone rozumowanie: duży model (Llama 3.1 70B) - wymaga A100 80GB lub multi-GPU

3. Batching requestów

vLLM z continuous batching grupuje requesty od wielu agentów:

• Jeden pod vLLM obsługuje 10-50 jednoczesnych requestów (zależnie od długości kontekstu)
• Lepsze wykorzystanie GPU niż jeden request na raz
• Skonfiguruj --max-num-seqs 32 w vLLM dla optymalnej przepustowości

4. KV-cache offloading

Dla agentów z długimi kontekstami (RAG z dużymi dokumentami):

• Prefix caching w vLLM - wielokrotne zapytania z tym samym system promptem nie przeliczają KV-cache
• Quantized KV-cache (FP8) - 2x mniej VRAM na cache, minimalna strata jakości

5. Harmonogram pracy GPU

Jeśli agenci pracują głównie w godzinach roboczych (9-18):

• Scale-to-zero na noc i weekendy
• CronJob z KEDA do przebudowania podów rano
• Oszczędność: 60-70% kosztów GPU (10h/dzień zamiast 24h)

Observability dla GPU workload

Metryki, które musisz zbierać

Standardowy Prometheus + DCGM Exporter (NVIDIA):

• DCGM_FI_DEV_GPU_UTIL - wykorzystanie rdzeni GPU (%)
• DCGM_FI_DEV_MEM_COPY_UTIL - wykorzystanie pamięci GPU (%)
• DCGM_FI_DEV_GPU_TEMP - temperatura (throttling >80°C)
• DCGM_FI_PROF_PIPE_TENSOR_ACTIVE - wykorzystanie Tensor Cores (dla wnioskowania LLM)

Na poziomie vLLM/TGI:

• vllm:num_requests_running - aktywne requesty
• vllm:num_requests_waiting - kolejka (krytyczna metryka)
• vllm:gpu_cache_usage_perc - % zajętego KV-cache
• vllm:avg_prompt_throughput_toks_per_s - przepustowość tokenów wejściowych

Alerty (minimum)

• GPU utilization <10% przez 15 minut - prawdopodobnie marnotrawstwo
• KV-cache >90% - model zaczyna odrzucać requesty lub zwracać OOM
• Kolejka >20 requestów przez 2 minuty - potrzebne skalowanie
• GPU temperatura >85°C - ryzyko throttlingu

Wzorzec referencyjny - klaster EKS pod system agentowy

Architektura dla typowego systemu agentowego (np. autonomiczny agent do analizy dokumentów finansowych):

Pule nodów:

1. System pool (2x m5.large) - CoreDNS, kube-system, monitoring
2. Agent pool (Karpenter, c5.xlarge-c5.4xlarge, Spot) - orchestracja agentów, narzędzia, bazy wektorowe
3. Inference pool (Karpenter, g5.xlarge-g5.2xlarge, Spot z fallbackiem) - pody vLLM z modelami

Separacja:

• Agenci (CPU) skalują się niezależnie od wnioskowania (GPU)
• Pody wnioskowania mają dedykowane pule nodów (nie współdzielą nodów z CPU workload)
• Scale-to-zero na wnioskowanie poza godzinami pracy

Szacunkowy koszt (workload 8h/dzień, 5 dni/tydzień):

• System + Agent poole: ~$200-400/miesiąc
• Inference pool (2x g5.xlarge Spot, 8h/dzień): ~$150-250/miesiąc
• Łącznie: ~$350-650/miesiąc (vs ~$1,500-2,000 gdyby GPU działało 24/7)

Typowe błędy

1. GPU node bez taintów - zwykłe pody CPU lądują na drogich GPU nodach. Zawsze ustawiaj taint nvidia.com/gpu=true:NoSchedule na GPU puli nodów.

2. Brak resource requests na podach wnioskowania - scheduler nie wie, ile VRAM potrzebuje model. Efekt: dwa duże modele na jednym GPU = OOM kill. Szczegóły rozwiązania opisaliśmy w runbooku vLLM GPU OOM na EKS.

3. Autoscaler skalujący na GPU utilization - GPU utilization 50% nie znaczy, że jest wolne miejsce. KV-cache może być pełny. Skaluj na podstawie metryk aplikacyjnych (kolejka requestów).

4. Jeden duży model zamiast wielu małych - 70B model na 4x A100 kosztuje 10x więcej niż odpowiedni routing: klasyfikator na T4 + mały model na A10G + duży model tylko gdy jest naprawdę potrzebny.

5. Brak budżetu per-agent - bez limitów, jeden agent w pętli może wygenerować 100 000 tokenów w minutę. Wdrożenie rate-limitingu na poziomie orchestracji jest konieczne.

Jak możemy pomóc

W Devopsity projektujemy i wdrażamy infrastrukturę Kubernetes pod systemy AI - od pojedynczych modeli inferencyjnych po pełne systemy agentowe. Typowe zaangażowanie:

• Zaprojektowanie architektury GPU cluster (pule nodów, autoskalowanie, networking) - 2-3 dni
• Wdrożenie vLLM/TGI z autoskalowaniem KEDA + Karpenter - 3-5 dni
• Konfiguracja observability i alertów GPU - 1-2 dni
• Optymalizacja kosztów (Spot, scale-to-zero, right-sizing modeli) - 2-3 dni

Jeśli Twój zespół buduje system agentowy i stoi przed decyzją: managed API (Bedrock, OpenAI) vs self-hosted - porównanie tych podejść znajdziesz tutaj.

Budujesz infrastrukturę pod AI?

Umów się na bezpłatną 30-minutową rozmowę. Bez sprzedaży - techniczna dyskusja o Twojej architekturze.

Umów rozmowę

Najczęściej zadawane pytania

Czy potrzebuję GPU, żeby uruchomić agentów AI?

Niekoniecznie. Orchestracja agentów (LangChain, CrewAI) działa na CPU. GPU potrzebujesz tylko do wnioskowania LLM. Jeśli korzystasz z API (OpenAI, Bedrock, Vertex AI) - nie potrzebujesz własnych GPU. Self-hosted modele na GPU mają sens przy dużym wolumenie (>1M tokenów/dzień) lub wymaganiach na prywatność danych.

Ile GPU potrzebuję dla systemu agentowego?

Zależy od modelu i obciążenia. Jeden pod vLLM na A10G (24 GB VRAM) obsługuje model 7-8B parametrów z przepustowością ~2000 tokenów/s. Dla 10 jednoczesnych agentów z krótkim kontekstem - jedno GPU wystarczy. Dla 100 agentów z długim kontekstem (RAG) - potrzebujesz 3-5 GPU lub większych instancji.

Spot Instances dla inference - czy to bezpieczne?

Tak, jeśli masz fallback. Karpenter z capacity-type: ["spot", "on-demand"] automatycznie podnosi on-demand node gdy Spot jest niedostępny. vLLM obsługuje graceful shutdown - kończy aktualny request przed wyłączeniem. Agenci z retry logic przeżyją 30-sekundową przerwę.

Karpenter czy Cluster Autoscaler dla GPU?

Karpenter. Cluster Autoscaler wymaga predefiniowanych node group i skaluje w minutach. Karpenter podejmuje decyzje w sekundach, wybiera optymalny typ instancji z puli, i natywnie obsługuje konsolidację (wyłączanie pustych nodów). Dla GPU, gdzie koszt bezczynności jest wysoki - ta różnica jest krytyczna.

Ile kosztuje infrastruktura pod agentic AI?

Minimalne MVP (1x g5.xlarge Spot, 8h/dzień): ~$150/miesiąc. Produkcyjne rozwiązanie (2-4 GPU, 24/7, redundancja): ~$1,500-3,000/miesiąc. Dla porównania: Bedrock/OpenAI API przy 5M tokenów/dzień kosztuje ~$4,000-8,000/miesiąc. Próg opłacalności self-hostingu: zazwyczaj >2M tokenów/dzień.