--- title: "Wdrażanie agentów AI na Kubernetes: architektura, skalowanie i kiedy K8s się opłaca" description: "Wdrażanie agentów AI na Kubernetes: architektura, skalowanie HPA, scheduling GPU, stan, suwerenność w UE i od jakiego obciążenia K8s opłaca się bardziej niż zarządzane API." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/budowa-infrastruktury-agentow-ai/wdrazanie-agentow-ai-na-kubernetes-architektura-skalowanie-i-kiedy-k8s-sie-oplac" category: "Agenci AI" topic: "Budowa infrastruktury agentów AI" updated: "2026-10-28T13:37:17.590Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Wdrażanie agentów AI na Kubernetes: architektura, skalowanie i kiedy K8s się opłaca Wdrażanie agentów AI na Kubernetes oznacza uruchamianie komponentów systemu agentowego (usługi agenta, serwerów narzędzi lub MCP, bazy wektorowej, silnika inferencji i kolejki komunikatów) jako skonteneryzowanych obciążeń w klastrze K8s. Kubernetes zapewnia skalowanie, scheduling GPU, zarządzanie stanem, zarządzanie sekretami i obserwowalność na potrzeby produkcyjnego działania agentów z zachowaniem suwerenności w UE. ## W skrócie - Produkcyjny system agentowy na Kubernetes składa się z kilku rozdzielonych usług: orkiestratora agenta, serwerów narzędzi/MCP, silnika inferencji (vLLM, SGLang lub NVIDIA NIM), bazy wektorowej i kolejki komunikatów do zadań asynchronicznych. - Skalowanie przebiega w dwóch osiach: bezstanowe pody agentów skalują się elastycznie przez HPA, a pody inferencji GPU trafiają na dedykowane węzły GPU dzięki node selectorom, taints/tolerations i NVIDIA Device Plugin, a ze względu na koszty pozostają w gotowości zamiast skalować się elastycznie. - Agenci przechowują stan: pamięć konwersacji i plany zadań należy trzymać w zewnętrznym magazynie (Redis, Postgres), a nie w podzie. Baza wektorowa działa jako StatefulSet z PersistentVolumes. - Kubernetes opłaca się dopiero przy wysokim, stałym obciążeniu (reguła kciuka: od około 8–12 ekwiwalentów H100 w ciągłej inferencji) albo przy rygorystycznych wymaganiach dotyczących suwerenności lub opóźnień. Poniżej tego progu zarządzane API i serverless są zwykle tańsze i szybciej trafiają na produkcję. - Suwerenność nie wynika z samego regionu: region we Frankfurcie u amerykańskiego dostawcy zapewnia rezydencję danych, a nie suwerenność odporną na CLOUD Act. W rygorystycznych przypadkach potrzebne są suwerenne chmury (STACKIT, Open Telekom Cloud, Infomaniak, Exoscale) z zarządzanym Kubernetes. - Planuj realistycznie: własny klaster GPU wymaga 6–9 miesięcy przygotowań i zespołu platformowego, który opanował vLLM, scheduling GPU i typowe błędy NCCL w trybie 24x7. Wdrażanie agentów [AI](https://blckalpaca.at/pl/slownik/ai) na Kubernetes oznacza uruchamianie [komponentów systemu agentowego](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/czym-sa-agenci-ai/elementy-agenta-ai-wyjasnienie-5-komponentow) (usługi agenta, serwerów narzędzi lub [MCP](https://blckalpaca.at/pl/slownik/mcp), bazy wektorowej, silnika inferencji i kolejki komunikatów) jako skonteneryzowanych obciążeń w klastrze K8s. Kubernetes zapewnia skalowanie, scheduling GPU, zarządzanie stanem, zarządzanie sekretami i obserwowalność na potrzeby produkcyjnego działania agentów z zachowaniem suwerenności w UE. To potężne narzędzie, ale nie cel sam w sobie. Ten artykuł pokazuje architekturę, mechanikę skalowania, a przede wszystkim to, kiedy ten wysiłek w ogóle się opłaca. - **Architektura:** podziel system agentowy na rozdzielone usługi (orkiestrator, serwery narzędzi/MCP, silnik inferencji, baza wektorowa, kolejka) i uruchamiaj każdą jako osobne obciążenie. - **Skalowanie:** bezstanowe pody agentów skalują się elastycznie przez Horizontal Pod Autoscaler; pody inferencji GPU są przydzielane do dedykowanych węzłów GPU i ze względu na koszty pozostają w gotowości. - **Decyzja:** Kubernetes opłaca się przy wysokim stałym obciążeniu lub rygorystycznych wymaganiach dotyczących suwerenności lub opóźnień. Poniżej tego progu zarządzane [API](https://blckalpaca.at/pl/slownik/api) i serverless szybciej trafiają na produkcję i są tańsze. ## Architektura kontenerowa systemu agentowego Produkcyjny [agent AI](https://blckalpaca.at/pl/slownik/agent-ai-ai-agent) nie jest monolitem, tylko zespołem [mikrousług](https://blckalpaca.at/pl/slownik/modulowa-architektura-ai). Ten podział nie jest celem samym w sobie: wynika z różnych profili skalowania, stanu i bezpieczeństwa poszczególnych komponentów. ### Usługa agenta (orkiestrator) Usługa agenta to mózg: wykonuje logikę orkiestracji, decyduje o wywołaniach narzędzi i planuje kolejne kroki. Zwykle buduje się ją na frameworku takim jak [LangGraph, CrewAI lub AutoGen](https://blckalpaca.at/pl/slownik/framework-agentowy) albo na platformie dostawcy, np. PhariaAI (Heidelberg) czy Microsoft Foundry [Agent](https://blckalpaca.at/pl/slownik/agent) Service (dawniej Azure AI Foundry Agent Service). Kluczowe z punktu widzenia architektury: ta usługa musi pozostać **bezstanowa**, aby Kubernetes mógł ją swobodnie skalować, restartować i rozkładać na wiele replik. Cały stan przenosi się do zewnętrznych magazynów. ### Serwery narzędzi i MCP [Model Context Protocol (MCP)](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/model-context-protocol-mcp/mcp-vs-api-openapi-kiedy-co-wybrac) utrwalił się jako standardowy interfejs, przez który agenci korzystają z zewnętrznych narzędzi i źródeł danych. W środowiskach korporacyjnych w regionie DACH (Niemcy, Austria, Szwajcaria) serwery MCP działają najczęściej jako **usługi wewnątrz VPC**, umieszczone obok runtime'u agenta i połączone przez mTLS. To domyślny wzorzec integracji z SAP, Salesforce, ServiceNow, M365 i wewnętrznymi bazami danych. W scenariuszach fabrycznych lub oddziałowych serwery MCP wdraża się na brzegu sieci (edge), blisko danych, a centralna [orkiestracja](https://blckalpaca.at/pl/slownik/orkiestracja) wywołuje je przez dedykowane łącza (ExpressRoute, Direct Connect). Przy obciążeniach regulowanych obowiązuje zasada: dedykowane serwery MCP dla każdej jednostki biznesowej z oddzielnymi ścieżkami audytu zamiast jednego serwera multi-tenant. ### Silnik inferencji Tu działa model językowy. W 2026 roku wybór jest jasno określony: - **vLLM** (wywodzący się z UC Berkeley) to standard de facto w produkcyjnym self-hostingu: PagedAttention, najszersze wsparcie sprzętowe, endpointy zgodne z [OpenAI](https://blckalpaca.at/pl/slownik/openai). - **SGLang** (LMSYS) według benchmarków LMSYS zapewnia o około 29 procent wyższą przepustowość dla modeli 7B–8B na H100 i lepsze opóźnienia ogonowe (tail latency); idealnie sprawdza się w czatach wieloturowych, obciążeniach intensywnie korzystających z [RAG](https://blckalpaca.at/pl/slownik/rag) i obciążeniach ustrukturyzowanych. - **NVIDIA NIM** pakuje vLLM/TensorRT-[LLM](https://blckalpaca.at/pl/slownik/llm)/SGLang w gotowe kontenery i jest najbardziej pragmatyczną drogą on-premise dla MŚP z regionu DACH, choć wiąże się z licencją NVIDIA AI Enterprise. - **TensorRT-LLM** zapewnia szczytową przepustowość na sprzęcie NVIDIA, ale działa wyłącznie z NVIDIA i jest wymagający operacyjnie. Ważna uwaga dla istniejących systemów: Hugging Face **przeniósł TGI (Text Generation Inference) w tryb utrzymania 11 grudnia 2025 r.** i odsyła nowe wdrożenia do vLLM lub SGLang. Jeśli dziś korzystasz z TGI, nie musisz w panice migrować, ale nie opieraj na nim nowych projektów. ### Baza wektorowa i kolejka komunikatów [Baza wektorowa (Qdrant, Weaviate lub pgvector)](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/systemy-wieloagentowe-multi-agent-systems/pamiec-wspoldzielona-vs-przekazywanie-komunikatow-w-systemach-wieloagentowych) przechowuje embeddingi na potrzeby RAG. To klasyczny kandydat na **StatefulSet** z PersistentVolumes, ponieważ embeddingi wraz z oryginalnymi chunkami osiągają rozmiary rzędu terabajtów i potrzebują stabilnej tożsamości poda oraz trwałej pamięci masowej. **Kolejka komunikatów** (np. RabbitMQ, NATS lub Redis Streams) oddziela długotrwałe, asynchroniczne zadania agentów (przetwarzanie dokumentów, analizy wsadowe) od synchronicznej ścieżki żądań i umożliwia pule workerów, które skalują się niezależnie. ## Mapowanie komponentów: co trafia do jakiego zasobu K8s Poniższa tabela to podstawowe odniesienie przy wdrażaniu agentów. Przypisuje każdy komponent do odpowiedniego zasobu Kubernetes i podaje kluczową wskazówkę architektoniczną. | Komponent | Zasób K8s | Uwagi | | --- | --- | --- | | Usługa agenta / orkiestrator | Deployment + HPA + Service | Utrzymywać bezstanowo; skaluje się elastycznie według metryk CPU/niestandardowych | | Serwery narzędzi/MCP | Deployment (lub DaemonSet na brzegu sieci) + Service | mTLS przez service mesh; jedno konto usługi na parę agent-narzędzie | | Silnik inferencji (vLLM/NIM) | Deployment z limitem zasobów GPU + Service | Node selector/tolerations na węzły GPU; pody utrzymywać w gotowości, nie elastycznie | | Baza wektorowa (Qdrant/Weaviate) | StatefulSet + PersistentVolumeClaim | Trwała pamięć masowa; w razie potrzeby georeplikacja na potrzeby failoveru | | Kolejka komunikatów + workery | StatefulSet (broker) + Deployment (workery) | Oddziela zadania asynchroniczne; skalować workery przez KEDA według głębokości kolejki | | Stan sesji/konwersacji | Zewnętrzny Redis / Cosmos (często zarządzany) | Nie w podzie; georeplikacja zależnie od RPO | | Sekrety / dane uwierzytelniające narzędzi | External Secrets + Vault / Cloud KMS | Bez statycznych kluczy w podzie; HSM seal dla BFSI | | AI Gateway (LiteLLM/Portkey) | Deployment + Service + Ingress | Failover między dostawcami, budżety, maskowanie PII, centralna kontrola ruchu wychodzącego | | Tożsamość (pod → narzędzie/model) | Workload Identity (IRSA / Managed Identity) | Wymiana na krótkotrwałe tokeny; brak danych uwierzytelniających w kodzie | | Obserwowalność | Sidecar/agent + OpenTelemetry Collector | Trace'y, koszty tokenów, stan usług; backend z rezydencją danych w UE (np. Langfuse self-hosted) | ## Skalowanie: HPA, scheduling GPU i dwie osie Stacki agentowe skalują się w dwóch zupełnie różnych osiach i to jest najczęstsza pułapka. **Oś bezstanowa (CPU):** usługa agenta, serwery MCP i AI Gateway to tanie obciążenia CPU. Skalują się elastycznie przez **Horizontal Pod Autoscaler (HPA)**: przy szczytach obciążenia dochodzą repliki, a w czasie bezczynności są usuwane. Do workerów sterowanych kolejką dobrze nadaje się KEDA, który skaluje według głębokości kolejki, a nie tylko według CPU. **Oś GPU (inferencja):** tu obowiązuje inna logika. Węzły GPU są rejestrowane w klastrze przez **NVIDIA Device Plugin**; pody żądają GPU przez limit zasobów `nvidia.com/gpu`. Dzięki **node selectorom, taints i tolerations** pody inferencji trafiają celowo na drogie węzły GPU, a obciążenia bezstanowe pozostają na węzłach CPU. Zasadnicza różnica: pojemność GPU zwykle **utrzymuje się w gotowości, a nie skaluje elastycznie**, ponieważ bezczynne GPU to najdroższy capex, jaki istnieje. Prawdziwa elastyczność przez Cluster Autoscaler działa tylko tam, gdzie dostawca chmury wystarczająco szybko dostarcza nowe węzły GPU. Przy dedykowanej, przydzielanej w ramach alokacji pojemności Blackwell (B200/GB200) tak nie jest. Matematyka pamięci GPU decyduje o tym, ile modeli zmieści się na jednym węźle. Reguła kciuka dla wag: liczba parametrów razy liczba bajtów na parametr. Model 70B potrzebuje przy BF16 (2 bajty) około **140 GB**, przy FP8 około **70 GB**, przy AWQ-INT4 około **35 GB**, do tego dochodzi KV cache, który rośnie wraz z rozmiarem batcha i długością sekwencji (rząd wielkości 10–40 GB w produkcji). W praktyce model 70B zmieści się na pojedynczym H200 (141 GB) tylko po kwantyzacji, np. w FP8 z około 70 GB plus KV cache. Przy BF16 wagi zostawiają niewiele miejsca na KV cache. Wtedy potrzebny jest paralelizm tensorowy na kilku GPU jednego węzła przez NVLink. Rachunkowo dwa H100 (łącznie 160 GB) nie wystarczą na wagi plus KV cache. Przy produkcyjnych rozmiarach batcha potrzeba więc dwóch H200 (282 GB) lub czterech H100 (320 GB). ## Stan, pamięć i region UE W przeciwieństwie do klasycznych aplikacji webowych agenci **przechowują stan**: pamięć konwersacji, plany zadań i historia wywołań narzędzi muszą przetrwać, nawet gdy pod się zrestartuje lub nastąpi failover regionu. Z punktu widzenia architektury oznacza to: stan sesji w regionalnym Redisie lub Cosmos DB z georeplikacją, pamięć długoterminowa i baza wektorowa replikowane synchronicznie lub asynchronicznie, zależnie od wymaganego RPO. Baza wektorowa stanowi tu wyzwanie związane z dużymi wolumenami danych, ponieważ embeddingi i chunki to największe zbiory danych. W kwestii **regionu UE i suwerenności** czai się najważniejsza pułapka: region we Frankfurcie amerykańskiego hiperskalera zapewnia rezydencję danych, **a nie** [suwerenność odporną na CLOUD Act](https://www.justice.gov/criminal/cloud-act-resources), ponieważ operator pozostaje amerykańską osobą prawną. Przy zarządzanym Kubernetes z prawdziwą suwerennością do gry wchodzą suwerenne chmury: **Infomaniak** (Genewa/Zurych, pełna szwajcarska kontrola, FADP plus [RODO](https://blckalpaca.at/pl/slownik/rodo)) i **Exoscale** (Szwajcaria, [oparty na CloudStack z własnymi orkiestratorami](https://www.exoscale.com/blog/exoscale-sks/), zarządzany K8s) oferują zarządzany Kubernetes bez ekspozycji na hiperskalerów; **Swisscom** ma suwerenną usługę K8s opartą na Kubermatic; **STACKIT** (Schwarz Digits, z centrum danych w Austrii) i **Open Telekom Cloud** stawiają na platformy oparte na OpenStack z instancjami GPU. Dla obciążeń bez ścisłych wymagań w zakresie suwerenności pragmatycznym wyborem domyślnym pozostaje zarządzany Kubernetes hiperskalerów (AKS/EKS/GKE) w regionie UE; tak rozwiązuje to również architektura referencyjna dla scale-upów działających w modelu lean. ## Sekrety, dostęp do narzędzi i obserwowalność Agenci mają nietypowo duży **promień rażenia** (blast radius): przejęty agent może wywołać wiele narzędzi. Dlatego dobrą praktyką jest jedno konto usługi **na każdą parę agent-narzędzie** zamiast współdzielonego konta, podnoszenie uprawnień just-in-time dla wrażliwych operacji oraz ścieżki audytu, które przez łańcuch wymiany tokenów sięgają aż do tożsamości użytkownika. Konkretnie na Kubernetes: - **Workload Identity** zamiast statycznych danych uwierzytelniających: Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts w EKS), GCP Workload Identity Federation, a w suwerennych chmurach konta usług Keystone lub K8s. Cel jest ten sam: żadnego klucza w kodzie, żadnego człowieka na ścieżce danych uwierzytelniających. - **Podstawa zarządzania sekretami:** HashiCorp Vault to najpopularniejsza warstwa sekretów i PKI w stackach platformowych w regionie DACH; w BFSI i sektorze publicznym z mechanizmem HSM seal opartym na module HSM **Utimaco** (Akwizgran) lub Thales. Wzorzec External Secrets synchronizuje je do sekretów K8s bez przechowywania ich w repozytorium. - **Kontrola ruchu wychodzącego:** wzorzec utrwalony w sektorze BFSI w regionie DACH to **deny-by-default** z jawną listą dozwolonych FQDN API modeli, logowaną na bramie. Zapobiega to przypadkowej eksfiltracji danych i wymusza, by cały ruch do modeli przechodził przez AI Gateway (LiteLLM, Portkey, Kong), gdzie znajdują się limity zapytań, filtry PII i budżety. W zakresie **monitorowania stanu i obserwowalności** Kubernetes zapewnia podstawę: [sondy liveness i readiness](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/budowa-infrastruktury-agentow-ai/llm-observability-tracing-metryki-logi-i-ewaluacje-agentow-ai) dla każdego poda gwarantują, że ruch trafia tylko do sprawnych podów inferencji, co jest kluczowe przy długim czasie ładowania modelu (sonda readiness może zmienić stan na zielony dopiero po załadowaniu modelu). Wyżej znajduje się warstwa tracingu oparta na OpenTelemetry, z przypisaniem kosztów z dokładnością do tokenu i backendem z rezydencją danych w UE, takim jak Langfuse (self-hosted). ## Kiedy Kubernetes, a kiedy nie Czas na szczere ostrzeżenie dotyczące złożoności. Kubernetes z własną inferencją GPU to nie projekt na weekend. Opłaca się, jeśli spełniony jest **co najmniej jeden** z tych czynników: - **Wysokie, stałe obciążenie:** według reguły kciuka krążącej w zespołach platformowych w regionie DACH inferencja self-hosted staje się tańsza w przeliczeniu na [token](https://blckalpaca.at/pl/slownik/token) niż zarządzane API od około **8–12 ekwiwalentów H100 stałego obciążenia**, ale wymaga 6–9 miesięcy przygotowań inżynieryjnych. Poniżej tego progu zarządzane API wygrywają pod względem TCO. - **Rygorystyczne wymagania dotyczące opóźnień:** budżety opóźnień poniżej 200–500 ms przy kilku rundach wywołań narzędzi wymagają inferencji umieszczonej w tej samej lokalizacji; transatlantyckie wywołania API (Frankfurt → US-East: [około 85–95 ms w obie strony](https://wondernetwork.com/pings/Frankfurt/Washington)) są wtedy wykluczone. - **Suwerenność wymagana umową:** gdy dział prawny nie akceptuje ekspozycji na CLOUD Act lub obowiązuje BSI C5 Type 2. Za **zarządzanymi API i serverless** przemawia natomiast skokowe obciążenie (bezczynne GPU to najgorszy capex), potrzeba dużej różnorodności modeli (sam Microsoft Foundry dodał w 2025 roku DeepSeek R1, [GPT](https://blckalpaca.at/pl/slownik/gpt)-4.1, Mistral Large 3, Claude Opus 4.5 i Llama 4) albo po prostu **brak zespołu platformowego**. Niewiele MŚP z regionu DACH potrafi we własnym zakresie utrzymywać vLLM, scheduling GPU i radzić sobie z błędami NCCL w trybie 24x7, i to właśnie ten brak, a nie sama technologia, jest najczęstszym powodem porażek projektów self-hostingowych. ## Konkretny przykład: klaster lean dla agenta B2B Typowy stack scale-upu (wzorowany na architekturze referencyjnej „Lean Cloud”) wygląda tak: \`\`\`text Zarządzany Kubernetes (AKS/EKS w regionie UE lub suwerenny Exoscale/Infomaniak) ├── Deployment: agent-orchestrator (LangGraph, 3 repliki, HPA 2-10, węzły CPU) ├── Deployment: mcp-tools-sap (mTLS, 1 konto usługi na narzędzie) ├── Deployment: ai-gateway-litellm (Failover: Azure OpenAI EU -> Mistral La Plateforme) ├── StatefulSet: qdrant (3 repliki, PVC, baza wektorowa) ├── StatefulSet: redis (stan sesji, georeplikacja) └── Worker-Deployment: doc-processor (KEDA, skaluje według głębokości kolejki RabbitMQ) Inferencja modelu: zarządzane API (bez własnego węzła GPU) -> przez gateway \`\`\` Tu nie działa **żadna własna karta GPU**. Inferencja odbywa się w zarządzanym API z lokalizacją w UE, abstrahowanym przez gateway. To celowe: przy umiarkowanym obciążeniu model pay-per-token jest tańszy i działa produkcyjnie po tygodniach, a nie miesiącach. Dopiero gdy miesięczne wydatki na API przekroczą run rate około 10 ekwiwalentów H100 w suwerennej chmurze albo gdy nowy wymóg regulatora zażąda kontroli, której zarządzane API nie potrafi wykazać, opłaca się migracja na własne węzły GPU z vLLM lub NIM w tym samym klastrze. Właśnie do tego Kubernetes nadaje się idealnie: architektura pozostaje taka sama, a jedynie komponent inferencji przechodzi z „zarządzanego API za gatewayem” do „Deploymentu GPU w klastrze”. ## Dla agencji i decydentów B2B Kubernetes to właściwa podstawa dla systemów agentowych, które mają długofalowo rosnąć, zachować suwerenność w UE lub spełniać rygorystyczne wymagania dotyczące opóźnień, ale start powinien prawie zawsze odbywać się przez zarządzane API i zarządzany Kubernetes, z jasno udokumentowanym wyzwalaczem migracji do własnej inferencji GPU. Jeśli nie zdefiniujesz tego progu precyzyjnie, zbudujesz drogi klaster GPU albo za wcześnie, albo za późno, gdy rachunek za API już wymknie się spod kontroli. Blck Alpaca wspiera firmy w Europie i agencje marketingowe właśnie przy tej decyzji architektonicznej: od oceny make-buy-rent dla każdego komponentu po projekt suwerennego klastra gotowego na obserwowalność. Porozmawiaj z nami, zanim zamówisz pierwszą kartę GPU. ## Najczęściej zadawane pytania ### Kiedy Kubernetes ma sens dla agentów AI, a kiedy nie? Kubernetes opłaca się, jeśli utrzymujesz własną inferencję (self-hosted) przy wysokim, stałym obciążeniu (reguła kciuka: od około 8–12 ekwiwalentów H100 stałego obciążenia self-hosting staje się tańszy w przeliczeniu na token niż zarządzane API), jeśli wymagane są budżety opóźnień poniżej 200–500 ms przy kilku rundach wywołań narzędzi albo jeśli umowa wymaga ścisłej suwerenności (odporność na CLOUD Act, BSI C5 Type 2). Przy skokowym obciążeniu o niskiej wrażliwości lub bez zespołu platformowego zarządzane API (Azure OpenAI Data Zone EUR, Bedrock EU, Mistral La Plateforme) i serverless szybciej trafiają na produkcję i są tańsze. Na własny klaster GPU zaplanuj 6–9 miesięcy przygotowań. ### Jakiego silnika inferencji używać na Kubernetes w 2026 roku? W 2026 roku vLLM jest standardem de facto dla produkcyjnych wdrożeń self-hosted: PagedAttention, szerokie wsparcie sprzętowe, endpointy zgodne z OpenAI. Według benchmarków LMSYS SGLang zapewnia o około 29 procent wyższą przepustowość dla modeli 7B–8B na H100 i sprawdza się w czatach wieloturowych oraz przy ustrukturyzowanych odpowiedziach. NVIDIA NIM to najbardziej pragmatyczna droga on-premise dla MŚP z regionu DACH (Niemcy, Austria, Szwajcaria): gotowe kontenery, szybkie wdrożenie, ale uzależnienie od licencji NVIDIA AI Enterprise. TGI od Hugging Face jest od 11 grudnia 2025 r. w trybie utrzymania, a przy nowych wdrożeniach odsyła się do vLLM lub SGLang. ### Jak obsługiwać stan i pamięć agentów na Kubernetes? Pody agentów muszą pozostać bezstanowe, aby HPA mógł je swobodnie skalować i restartować. Pamięć konwersacji, plany zadań i historia wywołań narzędzi trafiają do zewnętrznego magazynu: zwykle Redis (stan sesji) i Postgres (trwałe konwersacje), a przy failoverze między regionami z georeplikacją. Baza wektorowa (Qdrant, Weaviate, pgvector) działa jako StatefulSet z PersistentVolumeClaims, ponieważ embeddingi i oryginalne chunki mogą osiągać rozmiary rzędu terabajtów i potrzebują stabilnej tożsamości. ### Jak agenci na Kubernetes uzyskują bezpieczny dostęp do sekretów i narzędzi? Statyczne dane uwierzytelniające w podzie lub w zmiennych środowiskowych są wykluczone. Workload Identity (Azure Managed Identity, AWS IRSA, GCP Workload Identity Federation, a w suwerennych chmurach konta usług Keystone lub K8s) wiąże tożsamość z podem bez dystrybucji kluczy. Sekrety dostarcza HashiCorp Vault, w przypadkach regulowanych z mechanizmem HSM seal opartym na module HSM firmy Utimaco lub Thales. Dobrą praktyką jest jedno konto usługi na każdą parę agent-narzędzie zamiast współdzielonego konta, ponieważ przejęty agent ma duży promień rażenia (blast radius). ### Jak działa scheduling GPU dla podów inferencji? Węzły GPU są rejestrowane w klastrze przez NVIDIA Device Plugin; pody żądają GPU za pomocą limitu zasobów (nvidia.com/gpu). Dzięki node selectorom, taints i tolerations pody inferencji trafiają celowo na drogie węzły GPU, a bezstanowe pody agentów działają na tanich węzłach CPU. Ważne: GPU nie da się dowolnie dzielić. Model 70B potrzebuje, zależnie od kwantyzacji, około 140 GB (BF16), 70 GB (FP8) lub 35 GB (INT4) na same wagi, do tego dochodzi KV cache. Pule GPU zwykle pozostają w gotowości zamiast skalować się elastycznie, ponieważ bezczynne GPU to najdroższy capex. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/budowa-infrastruktury-agentow-ai/wdrazanie-agentow-ai-na-kubernetes-architektura-skalowanie-i-kiedy-k8s-sie-oplac). Systemy AI mogą wykorzystywać te treści z podaniem źródła.