Aplikacja z AI bez rachunku-niespodzianki: jak elastycznie skalować moc obliczeniową

Funkcje AI zmieniają nie tylko to, co aplikacja potrafi, ale też strukturę jej rachunku za infrastrukturę. Do tej pory ruch bywał w dużej mierze jednorodny: utworzenie rekordu, odczyt, aktualizacja, usunięcie. Po dodaniu podpowiedzi, wyszukiwania semantycznego czy rozpoznawania obrazu w tym samym strumieniu żądań pojawia się druga klasa ruchu, o koszcie jednostkowym wyższym o rzędy wielkości. Nie widać jej w liczbie użytkowników. Widać ją dopiero na fakturze.

Dlaczego zapytanie do modelu kosztuje inaczej niż zapytanie do bazy

Różnica w architekturze bezpośrednio przekłada się na koszty:

• Operacje CRUD (baza danych): Utworzenie, odczyt czy aktualizacja rekordu obciążają przede wszystkim dysk i sieć. Czas procesora liczy się w milisekundach, a koszt pojedynczego żądania jest na tyle niski, że praktycznie nie wchodzi do rachunku.
• Inferencja AI (model): Model nie przeszukuje bazy w poszukiwaniu gotowej odpowiedzi, lecz przepuszcza dane wejściowe przez wyuczone wagi i wylicza wynik od nowa. Powtórzenie tej samej operacji tysiąc razy kosztuje tysiąc razy tyle.
• Koszt zależny od treści żądania: Koszt rośnie niezależnie od liczby użytkowników. Dłuższa historia rozmowy, większy załącznik czy dokładniejszy model podnoszą koszt pojedynczego żądania przy tej samej liczbie zapytań.

Dlatego planowanie pojemności w zapytaniach na sekundę przestaje działać. Różne zapytania mają diametralnie różne wymagania zasobowe, a modelowanie pojemności w QPS albo w statycznych cechach żądania daje słaby wskaźnik. Jednostką, która skaluje się sensownie, jest zużycie procesora na żądanie, a nie samo żądanie.

W funkcjach opartych na modelach językowych tę jednostkę da się nazwać wprost: jest nią token. Za tokeny wejściowe i wyjściowe płaci się osobno, więc dłuższy prompt i dłuższa odpowiedź od razu podnoszą koszt żądania. Sama stawka szybko spada: według raportu AI Index 2025 koszt inferencji systemu na poziomie GPT-3.5 zmalał ponad 280-krotnie między listopadem 2022 a październikiem 2024 roku. Tańszy token niewiele jednak zmienia, jeśli funkcja zużywa ich coraz więcej.

Widać to na liczbach. Według cennika OVHcloud (wrzesień 2026) porównajmy standardową instancję (b3-8: 8 GB RAM, 2 vCore) z instancją z kartą Nvidia L4 pod inferencję produkcyjną:

• Zwykła godzina: 2 instancje aplikacyjne (0,44 PLN) + 1 inferencyjna (3,60 PLN) = 4,04 PLN netto.
• Godzina 10-krotnego szczytu ruchu: 20 instancji aplikacyjnych (4,40 PLN) + 10 inferencyjnych (36,00 PLN) = 40,40 PLN netto.

Z tej różnicy (36,36 PLN) aż 89 procent przypada na GPU. Nie zaskakuje więc liczba użytkowników, tylko udział żądań, które trafiają do modelu.

Wzorzec elastyczny: bezstanowa usługa, kolejka i sygnał

Bezstanowa usługa to taka, która nie przechowuje stanu sesji między żądaniami. Każda kopia usługi może obsłużyć dowolne żądanie, więc pulę kopii da się powiększać, zmniejszać i wymieniać bez utraty czegokolwiek. To nie jest przetwarzanie po stronie klienta ani drobna sztuczka wydajnościowa, tylko warunek, bez którego autoskalowanie w ogóle nie zadziała.

Drugim elementem jest kolejka. Żądania inferencyjne trafiają nie wprost do modelu, lecz do kolejki, z której pobierają je kopie usługi. Kolejka pochłania skok ruchu, zanim platforma zdąży uruchomić kolejne kopie, i przy okazji dostarcza sygnał, po którym widać realną skalę obciążenia.

Przy inferencji to opóźnienie jest dłuższe niż zwykle. Nowa kopia musi jeszcze wczytać wagi modelu do pamięci GPU, a taki zimny start (cold start) przy dużym modelu trwa znacznie dłużej niż uruchomienie kontenera na CPU. Kolejka musi przeczekać także ten czas.

Trzecim jest samo autoskalowanie. Potrzebna liczba kopii wylicza się z prostej proporcji: bieżąca liczba kopii pomnożona przez iloraz bieżącej i docelowej wartości metryki, zaokrąglona w górę. Zmiany mieszczące się w domyślnej tolerancji 0,1 są pomijane, a przy skalowaniu w dół okno stabilizacji, w dokumentacji pokazane jako 300 sekund, każe wziąć najwyższą wartość z ostatnich pięciu minut, żeby platforma nie usuwała kopii i nie tworzyła jej z powrotem chwilę później.

Sygnał	Co mierzy	Co realnie skaluje
Zużycie CPU	obciążenie kopii, które już działają	reaguje po fakcie i nie pozwala zejść do zera
Długość kolejki	ile żądań czeka na obsługę	liczbę kopii przetwarzających kolejkę, także od zera
Czas odpowiedzi	jak długo czeka użytkownik	pojemność pod założony czas odpowiedzi
Żądania na sekundę	natężenie ruchu	miesza klasy żądań o różnym koszcie

Wybór sygnału ma konsekwencję praktyczną, bo skalowanie do zera jest dostępne wyłącznie dla metryk obiektowych i zewnętrznych. Zużycie procesora i pamięci nie wystarczy, ponieważ mierzy się je tylko na kopiach już uruchomionych.

Samo ustawienie minReplicas: 0 kontroluje bramka funkcji HPAScaleToZero. Aktualna dokumentacja opisuje ją jako domyślnie włączoną, ale musi działać zarówno w kube-apiserver, jak i w kube-controller-manager. W praktyce skalowanie od zera po długości kolejki najczęściej realizuje się przez KEDA, autoskaler sterowany zdarzeniami z gotowymi skalerami między innymi dla RabbitMQ i Kafki.

Dokumentacja wskazuje przy tym wprost, komu to się opłaca: obciążeniom, które przez długi czas są bezczynne, a ich utrzymanie jest drogie, „takim jak konsumenci rzadko używanej kolejki lub zadania wymagające dedykowanego sprzętu, na przykład GPU”. To jest dokładnie profil funkcji AI w aplikacji mobilnej, w której ruch nocny jest zwykle wielokrotnie niższy niż w szczycie.

Żeby ten wzorzec miał na czym działać, wynajmuje się public cloud jako zasoby na żądanie: ponad 50 usług zarządzanych, moc obliczeniową, przestrzeń dyskową, bazy danych i sieć w regionach 1-AZ lub 3-AZ, z rozliczeniem godzinowym, miesięcznym albo w ramach umowy terminowej.

Dwa szczegóły cennika warto znać, zanim autoskalowanie trafi na produkcję. Rozliczanie sekundowe dla instancji Compute zaczyna się od 60 sekund, więc kopia podniesiona na pięciosekundowy skok i tak kosztuje minutę, a to przesądza, że skaluje się partiami pobranymi z kolejki, nie pojedynczym żądaniem.

Rabat sięgający 30 procent w ramach Savings Plans wychodzi taniej na godzinę tylko wtedy, gdy instancja faktycznie stoi włączona przez cały okres umowy. Dla instancji aplikacyjnej pracującej bez przerwy plan roczny obniża b3-8 ze 160,60 PLN do 136,51 PLN miesięcznie. Dla karty graficznej, która ma być wyłączona przez większość doby, zobowiązanie terminowe jest instrumentem odwrotnym do elastyczności.

Kiedy wystarczy CPU, a kiedy GPU zarabia na siebie

Nie każda funkcja AI potrzebuje akceleratora. Widać to w sposobie, w jaki raportuje się wyniki inferencji: obok liczby akceleratorów podaje się typ i liczbę procesorów, „jeśli to CPU wykonuje większość obliczeń ML”. Systemy liczące inferencję wyłącznie na procesorach są osobną, realnie zgłaszaną kategorią. Małe modele klasyfikujące, wyszukiwanie po wektorach na niewielkim zbiorze i przetwarzanie wsadowe bez twardego limitu czasu mieszczą się w niej bez straty jakości.

GPU zarabia na siebie tam, gdzie liczy się opóźnienie przy dużym modelu i równoległym ruchu. Cennik GPU OVHcloud pokazuje, jak szeroki jest ten przedział: Quadro RTX 5000 od 2 PLN netto za godzinę, L4 i A10 od 3,60 PLN, L40S od 6,40 PLN, H100 od 12,87 PLN. Między skrajnymi pozycjami jest ponad sześciokrotna różnica, a rozstrzyga o niej rozmiar modelu i wymagany czas odpowiedzi, nie ambicja.

Ile żądań obsłuży jedna karta, zależy w dużej mierze od serwera inferencyjnego. vLLM (continuous batching) czy NVIDIA Triton Inference Server (dynamic batching) łączą napływające żądania w partie, więc GPU liczy kilka zapytań w jednym przebiegu. Warto przy tym patrzeć nie na średni czas odpowiedzi, lecz na p99, bo to ogon rozkładu widzi użytkownik, który czeka najdłużej.

Różnica między wynajmem a własnym sprzętem sprowadza się do tego samego rachunku. Karta L4 utrzymywana przez pełną dobę przez miesiąc to 730 godzin i 2 628 PLN netto. Ta sama karta podnoszona tylko na dziesięć najbardziej obciążonych godzin dziennie to 300 godzin i 1 080 PLN.

Własny sprzęt kosztuje tyle samo w obu scenariuszach, bo stoi w serwerowni niezależnie od tego, czy liczy. W wielu wypadkach oba modele się łączy: stały ruch na własnej maszynie, a szczyty i eksperymenty tam, gdzie chmura publiczna rozlicza się za godziny.

Budżety, alerty i koszt liczony na funkcję

FinOps bywa mylony z cięciem kosztów, a jego własna definicja mówi o odpowiedzialności finansowej budowanej przez współpracę zespołów inżynieryjnych, finansowych i biznesowych. Trzy fazy to Inform, Optimize i Operate, przy czym pierwszą pomija się najczęściej, a to ona rozstrzyga o pozostałych.

W praktyce sprowadza się to do czterech rzeczy. Budżet i alert ustawione zanim funkcja trafi na produkcję, a nie po pierwszym rachunku. Koszt przypisany do konkretnej funkcji zamiast do całego projektu, żeby dało się odpowiedzieć, ile kosztuje podpowiadanie treści, a ile rozpoznawanie obrazu. Pamięć podręczna na powtarzalne zapytania, bo najtańsza inferencja to ta, która się nie wydarzyła. I dobranie rozmiaru modelu do zadania, zanim dokupi się moc.

Jedna pozycja znika z rachunku niezależnie od tych decyzji: ruch przychodzący i wychodzący jest w cenie i bez limitu, za 0 PLN. Transfer danych bywa tą częścią faktury, której nikt nie prognozował, a przy funkcji przesyłającej zdjęcia i odpowiedzi w obie strony rośnie razem z ruchem.

Dane w Europie jako argument sprzedażowy

Dla polskiego produktu miejsce przechowywania danych jest argumentem handlowym, nie tylko zgodnościowym. Instancje uruchamia się w regionach 1-AZ lub 3-AZ, a wybór regionu rozstrzyga, gdzie fizycznie leżą dane użytkowników.

W OVHcloud takim wyborem jest region Warszawa (WAW), region 1-AZ z instancjami ogólnego przeznaczenia i instancjami GPU, więc dane polskich użytkowników mogą zostać w Polsce. Zarządzane usługi inferencji, czyli AI Endpoints (bezserwerowe API do wybranych modeli) i AI Deploy (wdrażanie własnych modeli w obrazie Docker), działają natomiast w regionie Gravelines we Francji: nadal w UE, ale już nie w kraju.

Instrumentem, który tym rządzi, jest RODO, a organem nadzorczym Urząd Ochrony Danych Osobowych. Warto to powiedzieć wyraźnie, bo w materiałach o sztucznej inteligencji regularnie myli się je z aktem o sztucznej inteligencji. AI Act nie zastępuje RODO i sam to rozstrzyga: art. 2 ust. 7 stanowi, że prawo Unii o ochronie danych osobowych stosuje się do danych przetwarzanych w związku z tym rozporządzeniem i że rozporządzenie to nie narusza rozporządzenia 2016/679.

AI Act odpowiada za co innego i też istotnego: zakazuje praktyk wykorzystujących słabości użytkowników związane z wiekiem czy sytuacją ekonomiczną oraz nieuzasadnionego klasyfikowania osób. To dwa różne zestawy obowiązków i w rozmowie o produkcie lepiej ich nie mieszać.

Optymalizacja przed dokupieniem mocy

Wszystkie te decyzje mają wspólną kolejność. Mniejszy model, krótszy kontekst i pamięć podręczna obniżają koszt każdego przyszłego żądania, a większa instancja obniża tylko czas odpowiedzi tego jednego. Dopiero kiedy model jest dobrany do zadania, elastyczne skalowanie ma co skalować. W odwrotnej kolejności też zadziała, tylko drożej, i to właśnie ona przesądza, czy na koniec miesiąca przychodzi rachunek, czy rachunek-niespodzianka.