Domknięcie luki gotowości infrastruktury pod AI

Posiadanie akceleratorów, klastra Kubernetes i dostępu do modelu nie oznacza gotowości produkcyjnej. Infrastruktura jest gotowa dopiero wtedy, gdy organizacja potrafi utrzymać określoną jakość, czas odpowiedzi, przepustowość i koszt w warunkach szczytu, awarii, zmiany modelu oraz pogorszenia danych. Decyzja inwestycyjna powinna więc wynikać z profilu usługi i testów na własnym obciążeniu, a nie z porównania liczby GPU.

Skala adopcji nie usuwa tej luki. W badaniu CNCF Annual Survey 2025, opublikowanym w styczniu 2026 r., 66% spośród 213 respondentów hostujących modele AI używało Kubernetes do części lub całości inferencji, lecz tylko 7% deklarowało codzienne wdrażanie modeli, a 47% robiło to okazjonalnie. To odpowiedzi określonej grupy badanych, nie miara całego rynku, ale dobrze ilustrują różnicę między posiadaniem warstwy uruchomieniowej a zdolnością do częstego, kontrolowanego dostarczania zmian.

Rozdziel klasy obciążeń, zanim policzysz moc

„AI” nie jest jednym profilem infrastruktury. Trenowanie, dostrajanie, przetwarzanie wsadowe, wyszukiwanie wektorowe, inferencja online i agent wykonujący serię wywołań mają inne ograniczenia. Pierwszym artefaktem powinien być katalog usług z właścicielem, krytycznością, danymi, modelem, wzorcem ruchu i trybem degradacji.

Dla inferencji online ważne są opóźnienie ogonowe, liczba równoległych żądań, długość wejścia i wyjścia, przepustowość oraz czas oczekiwania w kolejce. Przetwarzanie wsadowe może tolerować dłuższe oczekiwanie, ale wymaga terminu zakończenia i kontroli zaległości. Trenowanie jest wrażliwe na dostępność całego zestawu zasobów, przepustowość sieci i checkpointing. Agent może zwielokrotnić ruch, ponieważ jedno żądanie użytkownika uruchamia wiele kroków i narzędzi.

Nie należy mieszać środowiska eksperymentalnego z usługą krytyczną. Eksperyment może priorytetyzować szybkość próby, podczas gdy produkcja wymaga izolacji, ograniczeń zużycia, zatwierdzonego pochodzenia modelu, obserwowalności i planu odtworzenia. Wspólna pula zasobów może być racjonalna, ale tylko z jawną polityką priorytetów i ochroną produkcji przed zadaniem badawczym.

Zbuduj model popytu z jednostek pracy

Plan pojemności powinien zaczynać się od oczekiwanego ruchu i charakterystyki żądania. Dla usługi językowej trzeba mierzyć między innymi tokeny wejściowe i wyjściowe, współbieżność, czas do pierwszego tokenu, tempo generacji oraz rozkład długości kontekstu. Średnia ukrywa szczyty i koszt najdłuższych żądań, dlatego potrzebny jest rozkład oraz scenariusze kampanii, zamknięcia miesiąca lub awarii zależności.

Po stronie zasobów należy obserwować wykorzystanie i pamięć akceleratora, czas kolejki, błędy braku pamięci, transfer danych, obciążenie CPU, cache i sieć. Niskie użycie GPU nie musi oznaczać nadmiaru mocy; wąskim gardłem może być przygotowanie danych, scheduler albo zewnętrzne API. Wysokie użycie nie jest z kolei sukcesem, jeżeli czas odpowiedzi przekracza cel i brak przestrzeni na awarię.

Model powinien umożliwiać decyzje: skalowanie, kolejkowanie, zmianę wielkości batcha, routing do mniejszego modelu, ograniczenie kontekstu lub odrzucenie części ruchu. Rezerwa pojemności musi wynikać z celu odporności i czasu dostawienia zasobu. Nie ma uniwersalnego bezpiecznego procentu.

Zarządzaj modelem, danymi i konfiguracją jako jednym wydaniem

Zmiana usługi AI rzadko ogranicza się do pliku modelu. Wynik zależy od promptu systemowego, kodu orkiestracji, parametrów generowania, tokenizerów, indeksu wyszukiwania, filtrów, narzędzi i danych ewaluacyjnych. Wszystkie te elementy powinny mieć identyfikowalną wersję oraz ślad promocji między środowiskami.

Rejestr modelu powinien przechowywać pochodzenie, warunki użycia, artefakty ewaluacji, zatwierdzenia i powiązania z wdrożeniem. Pipeline musi umieć odtworzyć dokładną kombinację, która przeszła testy. Ręczna podmiana modelu lub promptu na produkcji niszczy możliwość porównania i utrudnia wycofanie.

Wdrożenie warto prowadzić stopniowo, kierując ograniczoną część ruchu do nowej wersji i porównując ją na tych samych kategoriach żądań. Kryteria promocji oraz automatycznego zatrzymania powinny być ustalone przed startem, aby zespół nie interpretował pogarszających się wyników dopiero pod presją incydentu.

Połącz SLO techniczne z oceną jakości

Usługa może odpowiadać szybko i jednocześnie udzielać złych odpowiedzi. Potrzebne są dwa powiązane zestawy sygnałów. Warstwa techniczna obejmuje dostępność, opóźnienie, kolejkę, błędy, przepustowość i zużycie zasobów. Warstwa modelu obejmuje miary dobrane do zadania: poprawność, kompletność, odwołanie do źródła, bezpieczeństwo, zgodność formatu oraz częstość eskalacji do człowieka.

NIST AI 600-1 opisuje ryzyka charakterystyczne dla generatywnej AI oraz działania zarządcze, które można powiązać z AI Risk Management Framework. Nie daje jednego progu jakości dla każdego produktu. Organizacja musi zdefiniować, jaki błąd jest dopuszczalny w danym kontekście, kto ocenia wynik i kiedy proces powinien przejść w tryb ręczny.

Zestaw ewaluacyjny powinien odzwierciedlać realny ruch, w tym trudne i rzadkie przypadki, a jego wersja musi być kontrolowana. Ocena offline nie zastępuje monitorowania produkcji, ponieważ zmieniają się dane użytkowników, narzędzia i kontekst. Sygnały jakościowe z próbek, reklamacji i korekt człowieka trzeba wiązać z wersją całego wydania.

Zaprojektuj degradację przed awarią

Nie każda funkcja AI wymaga takiego samego planu ciągłości. Dla funkcji pomocniczej wystarczy komunikat i proces ręczny. Dla usługi krytycznej potrzebne mogą być: mniejszy model rezerwowy, drugi region lub dostawca, ograniczony zestaw funkcji, kolejka z priorytetem, odrzucanie niskiego priorytetu albo bezpieczna odpowiedź bez generacji.

Plan trzeba przetestować pod obciążeniem. Failover może zwiększyć opóźnienie, zmienić zachowanie modelu albo naruszyć wymagania dotyczące danych. Wycofanie wersji powinno obejmować nie tylko obraz aplikacji, lecz także model, prompt, indeks i konfigurację. Zespół operacyjny musi wiedzieć, kto może przełączyć tryb, jakie sygnały to uruchamiają i jak potwierdzić powrót do normalnej pracy.

Chaos test dla AI nie musi zaczynać się od wyłączenia centrum danych. Można zasymulować brak akceleratora, wzrost kolejki, limit API, niedostępność narzędzia agenta albo uszkodzony indeks i sprawdzić, czy system ogranicza wpływ zamiast zwielokrotniać żądania.

Benchmarkuj własną usługę i pełny koszt

Wyniki MLPerf Inference są użytecznym punktem odniesienia dla porównywalnych konfiguracji i obciążeń, ale nie przewidują automatycznie zachowania aplikacji z innym modelem, kontekstem, batchingiem, siecią i wymaganiem jakościowym. Test zakupowy powinien uruchamiać reprezentatywny zestaw żądań na kilku wariantach infrastruktury oraz obejmować stan ustalony, szczyt i awarię.

Porównanie musi utrzymywać stały próg jakości. Taniej wykonane żądanie nie jest równoważne, jeżeli model częściej wymaga korekty. Do kosztu trzeba włączyć akceleratory, CPU, pamięć, storage, sieć, licencje, czas bezczynności, rezerwę, obsługę platformy, ewaluację oraz pracę człowieka. Zużycie energii jest jednocześnie ograniczeniem operacyjnym i składnikiem kosztu; raport IEA „Energy and AI” pokazuje, dlaczego planowanie centrów danych wymaga uwzględnienia dostępności energii i sieci, a nie tylko sprzętu.

Wydaj decyzję gotowości na podstawie próby

Przed uruchomieniem produkcyjnym właściciel usługi powinien przedstawić dowody: zdefiniowany SLO, wynik ewaluacji jakościowej, test szczytu i degradacji, oszacowanie kosztu jednostki pracy, obserwowalność wersji, procedurę rollbacku, ograniczenia danych i obsadzony dyżur. Brak któregoś elementu może prowadzić do ograniczonego pilotażu, nie musi jednak oznaczać bezwarunkowej zgody.

Po starcie przegląd gotowości należy powtarzać po istotnej zmianie modelu, architektury, profilu ruchu lub dostawcy. Najważniejszym wskaźnikiem nie jest liczba dostępnych GPU, lecz zdolność do przewidywalnego dostarczenia użytecznego wyniku i kontrolowanego zachowania, gdy założenia przestają być prawdziwe.