Ekonomia inferencji ciągłej i skokowej: kiedy wygrywa on-premise, a kiedy ratuje chmura

Serwer inferencyjny z czterema GPU zużywa tyle samo prądu, zajmuje tyle samo miejsca w racku i amortyzuje się w tym samym tempie niezależnie od tego, czy obsługuje dwadzieścia milionów tokenów dziennie, czy dwadzieścia tysięcy. Karty nie wiedzą, że są bezczynne. Księgowy wie. Ta jedna asymetria — koszt stały po stronie on-prem, koszt krańcowy po stronie chmury — sprawia, że odpowiedź na pytanie „czy przejść na on-prem?” zależy w równym stopniu od kształtu ruchu, co od jego wolumenu.

T01 przeliczył ekonomikę pojedynczej karty w jednym punkcie wykorzystania. T02 zestawia koszt miliona tokenów z API chmurowymi przy pełnym obciążeniu. Ten artykuł (T03) to lektura dla dyrektora finansowego: co dzieje się z tymi liczbami, gdy ruch ma charakter skokowy, gdy jest stały, i jak zaprojektować system, który nie przepłaca po żadnej ze stron.

Tekst jest adresowany do osób, które uznały już, że obciążenie może zmieścić się on-prem, i muszą teraz zdecydować, ile on-prem, a co przejmie resztę.

Pułapka kosztu stałego

W chmurze koszt inferencji skaluje się z użyciem. Pojedyncze wywołanie Llama 70B u dostawcy OpenRouter kosztuje mniej więcej €0.50–€2.00 za milion tokenów (zależnie od poziomu usługi i dostawcy). Brak ruchu to brak kosztu. Dziesięciokrotny ruch to dziesięciokrotny koszt. Zależność jest liniowa i zaczyna się od zera.

Inferencja on-prem działa odwrotnie. Maszyna z 4× RTX Pro 6000 Blackwell (T01 szacuje jej trzyletnie TCO na około €58k ze wszystkim — amortyzacja capeksu, prąd, udział w obudowie, serwis) kosztuje te €58k niezależnie od tego, czy obsłuży milion tokenów, czy bilion. Koszt krańcowy dwusetmilionowego tokena w miesiącu jest taki sam jak drugiego: tyle kilowatogodzin, ile zużyto na jego policzenie, i nic więcej. Capex staje się kosztem utopionym w dniu wysyłki maszyny.

Konsekwencja księgowa jest brutalna i rzadko przyswajana przez kupujących:

(Ten sam sprzęt, to samo TCO €14.4k na kartę w ciągu trzech lat; zmienia się tylko mianownik.)

Stawka chmurowa za Llama 70B FP8 w 2026 roku mieści się w przedziale €0.50–€1.50/Mtok, zależnie od poziomu usługi u dostawcy. Warto przeczytać tabelę ponownie z tą liczbą w głowie. Przy 5% stałego wykorzystania maszyna on-prem jest droższa od każdej istniejącej opcji chmurowej. Przy 30% dorównuje najdroższym dostawcom. Przy 60% i więcej wygrywa rachunek bezapelacyjnie.

Pułapka polega na tym, że klienci porównują capex z bieżącym obciążeniem, a pół roku później odkrywają, że to obciążenie wykorzystywało 8% maszyny. Sprzęt nie zawinił. Zawiniło zwymiarowanie.

Jak wygląda realne wykorzystanie w produkcji

Dysponujemy danymi publicznymi oraz własnymi pomiarami z instalacji Kentino AI, które prowadzimy lub odwiedzamy, a obraz w całej branży w 2026 roku jest spójny:

Najważniejsze liczby z wdrożeń produkcyjnych i ankiet wśród operatorów: większość zespołów prowadzących własną inferencję raportuje średnie wykorzystanie GPU na poziomie 20–40%, przy czym dojrzałe instalacje zbliżają się do 40–65%. Wszystko powyżej 65% w trybie ciągłym to albo czysta praca wsadowa, albo klaster rozgrzany na tyle, że kolejny skok ruchu trafi do kolejki. Poniżej 20% maszyna pracuje głównie na to, by się spłacić, a nie by obsługiwać użytkowników.

Liczba, która zawsze zaskakuje kupujących: interaktywne obciążenie — chatbot, asystent programistyczny, bot obsługi klienta — niemal nigdy nie utrzymuje się powyżej 30%. Powodem jest pora dnia. Nawet produkt globalny ma godziny ciszy, a produkt regionalny ma 14 godzin niskiego obciążenia na dobę. Rachunek karze to bardzo surowo.

Obciążenia ciągłe — chleb powszedni

Ekonomika on-prem działa czysto przy każdym obciążeniu, które utrzymuje GPU w pracy przez większość doby. W przybliżonej kolejności częstości występowania w instalacjach Kentino AI:

• Asystent programistyczny / backend IDE dla zespołu 30+ inżynierów. Stabilne obciążenie w dni robocze 09:00–18:00, lżejsze wieczory, niemal zero w weekendy. Średnio 20–30% w skali tygodnia, ze szczytami 60–80% w godzinach pracy.
• Chatbot obsługi klienta / sprzedaży z ruchem całodobowym. Rytm dobowy zależy od obsługiwanego regionu; produkty globalne osiągają 25–35% w trybie ciągłym, regionalne 15–25%.
• Backend RAG / wyszukiwania semantycznego indeksujący i obsługujący wewnętrzną bazę wiedzy. Liczba zapytań jest umiarkowanie stabilna; reindeksacja to nocne zadanie, które dociąża maszynę do 95%. Łączne wykorzystanie 30–50%.
• Przetwarzanie wsadowe — nocne streszczanie wczorajszych dokumentów, cotygodniowe przebiegi autolabelingu, comiesięczna ponowna klasyfikacja całego korpusu. Czysta praca z kolejki, 70–90% wykorzystania, dopóki kolejka nie jest pusta, projektowana tak, by dobiegła końca.
• Inferencja dla floty robotów — wiele jednostek korzystających z tego samego endpointu VLM w godzinach pracy, bezczynnych poza nimi (I01, I06).

Prawidłowość jest taka, że obciążenia ciągłe albo obejmują dość stref czasowych, by wypełnić dobę, albo mają komponenty wsadowe celowo zapełniające luki. Technika „zapełniania luk” to największa dźwignia TCO, jaką klient ma do dyspozycji, i zarazem najczęściej pomijana. Maszyna obsługująca interaktywny czat przez 12 godzin dziennie przy 30% i pracująca nocą nad autolabelingiem przy 90% wychodzi średnio na około 60% — dwa razy wyższe efektywne wykorzystanie, dwa razy niższy koszt tokena.

Obciążenia skokowe — tam, gdzie on-prem boli

Przeciwny kształt to obciążenie, które przez krótkie okno potrzebuje ogromnej mocy, a przez resztę czasu niemal żadnej. Przykłady, które widujemy regularnie:

• Kampania marketingowa / zryw produkcji treści. Wygenerowanie wariantów kampanii reklamowej na N rynków w 48 godzin, a potem nic przez miesiąc.
• Momenty wirusowe. Aplikacja konsumencka wypuszcza funkcję, trafia do newslettera technologicznego, ruch rośnie 50× na sześć godzin i do następnego ranka wraca do normy.
• Pokazy i wydarzenia pilotażowe. Stoisko targowe prowadzące demonstracje inferencji na żywo przez trzy dni, a potem powrót do zera.
• Cykliczne zadania wsadowe, które muszą zmieścić się w oknie. Comiesięczny przegląd zgodności całego korpusu dokumentów, który musi zakończyć się przed terminem regulacyjnym.
• Analityka wieczoru wyborczego lub wydarzenia na żywo — okno 12–48 godzin, w którym wolumen jest 100× wyższy niż zwykle.

Przykład liczbowy. Obciążenie wymaga wygenerowania 10 milionów tokenów. Rozłożone na 24 godziny daje około 116 tok/s łącznie — poradzi sobie pojedynczy L4. Ściśnięte do jednogodzinnego okna to 2,778 tok/s — potrzeba maszyny z 4 GPU Pro 6000 pracującej na maksimum albo mniej więcej sześciu kart L4.

Te same 10 milionów tokenów wymaga więc albo jednej karty pracującej całą dobę, albo sześciu kart przez godzinę. Przy obciążeniach skokowych moce on-prem stoją bezczynnie przez 23 z 24 godzin. Rachunek TCO się załamuje: maszyna z sześcioma kartami przy 4% wykorzystania kosztuje €13–25/Mtok w przeliczeniu jak w powyższej tabeli. Skok obsłużony w chmurze po €1.50/Mtok pokrywa to samo obciążenie za łącznie €15. Do progu opłacalności jest bardzo daleko.

Wniosek nie do uniknięcia: wymiarowanie on-prem pod szczytowy skok to najczęstszy błąd prowadzący do przepłacenia, jaki widujemy. Klienci chcą, by maszyna pokryła najgorszy wtorkowy szczyt, więc kupują 4× więcej GPU, niż potrzebują w zwykłym tygodniu. Rachunek przychodzi w postaci nieodzyskiwalnego capeksu i floty bezczynnej w 90%.

Model hybrydowy

Uczciwa architektura dla realnego obciążenia produkcyjnego o obu kształtach to baza on-prem plus przelew skoków do chmury.

Routing hybrydowy: najpierw on-prem, przelew do chmury dopiero po przekroczeniu skonfigurowanego progu głębokości kolejki.

Właściwa logika routingu to nie „wyślij X% do chmury, resztę on-prem”. To najpierw on-prem, chmura dopiero przy wyczerpaniu mocy on-prem. Sygnałem jest głębokość kolejki albo wykorzystanie pamięci KV po stronie vLLM (K03 omawia te metryki), a nie sztywny podział procentowy.

Konkretny przepis na vLLM:

1. Przed klastrem on-prem należy postawić router wystawiający /v1/chat/completions. Sprawdzą się NGINX, HAProxy, vLLM Router albo niewielka własna bramka.
2. Należy wystawić vllm:num_requests_waiting jako miernik głębokości kolejki. Próg ustawiamy na przykład na 8–16 oczekujących żądań na replikę, zanim włączy się przelew.
3. Przy przelewie ruch kierujemy do endpointu chmurowego z tą samą nazwą modelu. OpenRouter, Together i Fireworks obsługują modele klasy Llama. Warto wskazać jednego dostawcę jako podstawowego, a drugiego jako zapasowego, aby awaria jednego nie wyłączyła usługi.
4. Żądania przelane do chmury warto tagować w systemie obserwowalności, aby codziennie widzieć, jaki procent jest opłacany na zewnątrz. Jeśli przez większość dni przekracza 15%, on-prem jest za mały; jeśli od tygodni utrzymuje się poniżej 1%, on-prem jest przewymiarowany.

Logika ekonomiczna: capex płaci się raz za obciążenie, które jest zawsze obecne, a zmienne stawki chmurowe za skoki. Dobrze poprowadzone podejście podnosi efektywne wykorzystanie maszyny on-prem do 50–70% (dostraja się właśnie próg routingu), nie naruszając przy tym zobowiązań dotyczących opóźnień w ogonie rozkładu podczas skoków.

Zimny start: rzeczywistość autoskalowania

Naiwna, chmurowa odpowiedź na ruch skokowy brzmi „autoskalować klaster on-prem” — trzymać zero replik w bezczynności i uruchamiać je na żądanie. W serwowaniu LLM rozwiązanie to zawodzi z jednego powodu: czasu ładowania modelu.

Wczytanie Llama 70B FP8 (~75 GB wag) z dysku NVMe Gen5 zajmuje 30–60 sekund czystego I/O przy teoretycznej prędkości odczytu 12–14 GB/s. Po doliczeniu kompilacji kerneli CUDA, rozgrzewki schedulera vLLM i prealokacji pamięci KV nowa replika jest gotowa przyjąć pierwsze żądanie 60–120 sekund po starcie poda. Mniejsze modele pomagają proporcjonalnie — 8B mieści się w 5–10 sekundach — ale wszystko powyżej 30B wpada w przedział „użytkownikom skończy się czas oczekiwania”.

Przy obciążeniach wsadowych to nie problem. Przy interaktywnych jest zabójcze. Dwie minuty opóźnienia na żądaniu, które wywołało skalowanie, są nie do przyjęcia.

Środki zaradcze, w kolejności nakładu pracy:

• Utrzymywanie N replik stale rozgrzanych. Minimum, które udźwignie średnie obciążenie. Skalowanie w górę na żądanie, nigdy w dół do zera. Na wzorcu „minimum rozgrzanych replik” dojrzali operatorzy budują całe produkty.
• Tryb uśpienia vLLM. Nowsze wersje vLLM obsługują stan „sleep”, w którym wagi pozostają w pamięci GPU, a silnik zwalnia zasoby obliczeniowe. Wybudzenie jest 18–20× szybsze niż ładowanie od zera. Przydatne, gdy kilka modeli współdzieli GPU, ale w danej chwili pracuje tylko jeden.
• Wstępnie rozgrzana pamięć podręczna modeli na wspólnym NVMe / NFS. Wagi pobierane są raz do szybkiej pamięci lokalnej, którą montują wszystkie repliki. Pierwsze ładowanie następuje raz, przy starcie klastra; kolejne repliki wstają w kilka sekund.
• Skalowanie według harmonogramu dobowego. Skalowanie w górę o 08:30 w oczekiwaniu na ruch o 09:00. Najprostszy i najskuteczniejszy wzorzec przy przewidywalnych obciążeniach dobowych. Zadania CronJob wywołujące kubectl scale są niemodne, ale działają.
• NVIDIA NIM Operator z gotowymi silnikami TRT-LLM. Silniki budowane z wyprzedzeniem, cache’owane na dysku, ładowane na żądanie. Zimny start szybszy niż pełna kompilacja, ale przy 70B wciąż liczony w dziesiątkach sekund.

Dla klientów Kentino AI — niewielkie floty, przewidywalne wzorce użycia — właściwą odpowiedzią jest niemal zawsze N rozgrzanych replik + skalowanie według harmonogramu + przelew skoków do chmury. Skalowanie do zera jest dla platform serverless, gdzie zimny start bierze na siebie ktoś inny.

Autoskalowanie: HPA na podstawie czego?

HPA w Kubernetes domyślnie korzysta z metryk CPU i pamięci. Obie są błędne dla inferencji na GPU. Pod vLLM może mieć 5% CPU i być przeciążony w 100% albo mieć 95% CPU i obsługiwać ruch bez zarzutu. Potrzebna metryka to jedna z poniższych:

Właściwym narzędziem do wpięcia tego w Kubernetes jest KEDA (Kubernetes Event-Driven Autoscaling), które potrafi pobierać zapytania Prometheusa wprost i podawać je do HPA. Produkcyjny stos vLLM ma pełnoprawną integrację z KEDA, a ten sam wzorzec działa z KServe na OpenShift AI.

Działający ScaledObject do skalowania według głębokości kolejki:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-llama70b
  minReplicaCount: 2     # stała liczba rozgrzanych replik
  maxReplicaCount: 6     # limit przed przelewem do chmury
  pollingInterval: 15
  cooldownPeriod: 300    # bez miotania się przy zaszumionej kolejce
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: avg(vllm:num_requests_waiting)
      threshold: '5'     # średnio 5 oczekujących na replikę → skalowanie w górę

Dwie lekcje z produkcji, które wyciągnęliśmy boleśnie:

1. cooldownPeriod ma takie samo znaczenie jak sam wyzwalacz. Zaszumiona kolejka powoduje miotanie się między skalowaniem w górę i w dół, a każde skalowanie w górę płaci zimnym startem. 5 minut to rozsądne minimum.
2. minReplicaCount należy zwymiarować na dolinę, a nie na zero. Te dwa pody stojące bezczynnie o 03:00 to dokładnie te dwa pody, które o 09:00 obsłużą skok bez przekroczenia limitu czasu.

Skalowanie poziome kontra pionowe

Subtelny wybór architektoniczny przy wymiarowaniu: kupić więcej maszyn (poziomo) czy więcej GPU na maszynę (pionowo)?

Przy obciążeniach inferencyjnych z ruchem skokowym niemal zawsze wygrywa skalowanie poziome. Dwie maszyny po 4 GPU mogą pracować jako cztery repliki DP=2, przetrwać awarię jednej z nich bez utraty usługi i pozwalają skalować moc po połowie zamiast całymi jednostkami. Skalowanie pionowe jest właściwe przy treningu i przy inferencji bardzo dużych pojedynczych modeli, gdzie TP wymaga GPU w jednej domenie elektrycznej.

Pułapka psychologiczna „GPU stoi, a ja za nie płacę”

Klienci odwiedzający instalację po raz pierwszy otwierają zwykle pulpit Grafany, widzą wykorzystanie GPU na poziomie 18% we wtorek o 14:30 i pytają, dlaczego zapłacili za sprzęt, który przez 80% czasu nic nie robi.

Uczciwa odpowiedź brzmi: przy każdym obciążeniu wrażliwym na opóźnienia pewien poziom bezczynności to cena za krótkie opóźnienia w ogonie rozkładu. Maszyna przy 95% stałego wykorzystania ma kolejkę. Kolejka oznacza opóźnienie żądań. Kto oczekuje 300 ms do pierwszego tokena, nie dostanie przy tym 95% wykorzystania tej samej maszyny. Trzeba wybrać jedno.

Kompromis, który da się zoptymalizować, to przeniesienie stałej pracy w okna bezczynności:

• Zadania wsadowe (autolabeling, ekstrakcja z dokumentów, generowanie embeddingów dla nowych treści) planowane na noc, gdy chatbot milczy.
• Przebiegi fine-tuningu w weekendy, gdy nie ma użytkowników.
• Cykliczna reindeksacja baz wektorowych we wczesnych godzinach porannych.

To dyscyplina traktowania maszyny on-prem jako zasobu o podwójnym przeznaczeniu: w dzień interaktywne serwowanie wrażliwe na opóźnienia, w nocy praca wsadowa. Dobrze poprowadzone podejście sprawia, że ten sam sprzęt pokazujący 25% wykorzystania na pulpicie interaktywnym pokazuje 65% na pulpicie wszystkich obciążeń. Dyrektor finansowy widzi tę drugą liczbę.

Czym nie jest rozwiązanie: sztuczne podbijanie liczby żądań, żeby „wyglądało na zajęte”. Klienci próbują tego od czasu do czasu. Pogarsza to opóźnienia w ogonie rozkładu, czyni monitoring bezużytecznym i nie zmienia rachunku.

Macierz decyzyjna

To kształt obciążenia, bardziej niż wolumen, wyznacza właściwą architekturę. Wystarczy dopasować swoją sytuację do najbliższego wiersza:

Dwie rzeczy, które ta macierz ujmuje trafnie, a planowanie ad hoc myli:

• Czysto skokowe obciążenia należą do chmury. Kupowanie sprzętu pod obciążenie pracujące cztery godziny w miesiącu to błąd w sztuce.
• Hybryda „ciągłe + skokowe” niemal zawsze potrzebuje obu rozwiązań. Próba wyboru tylko jednego z nich zwykle kończy się wyborem błędnym.

Uczciwa ocena

Większość klientów Kentino powinna planować 30–50% stałego wykorzystania on-prem i przelewać do chmury wszystko powyżej. Klienci, którzy dochodzą do 60–80% wykorzystania on-prem, to ci, którzy obok obciążeń interaktywnych prowadzą pracę wsadową — autolabeling nocą, fine-tuning w weekendy, generowanie embeddingów nad ranem. Klienci siedzący na 10–15% wykorzystania to ci, którzy wymiarowali pod szczyt.

Najdroższym pojedynczym błędem jest kupowanie pod najgorszy wtorkowy szczyt. Drugim najdroższym — wybór samej chmury, gdy stałe obciążenie spłaciłoby capex w 14 miesięcy. Właściwa odpowiedź leży niemal zawsze pośrodku: mniejsza maszyna on-prem niż ta pierwotnie wyspecyfikowana przez klienta, z drogą przelewu skoków do chmury.

Kontrola rachunku: przy stawkach chmurowych €0.50/Mtok i maszynie 4× Pro 6000 kosztującej €58k przez 3 lata, maszyna spłaca się przy mniej więcej 14 miliardach obsłużonych tokenów. Rozłożone równomiernie daje to ~150 tok/s w trybie ciągłym — spokojnie w zasięgu maszyny przy 25–35% wykorzystania. Poniżej tego wolumenu lepiej wynajmować. Powyżej — mieć na własność. To ten sam próg opłacalności, do którego dochodzą T01 i T02 od strony pojedynczej karty i pojedynczego tokena.

To część Kentino Wiki — serii referencyjnej o obliczeniach AI, robotyce i systemach, które je łączą. Uwagi i sprostowania prosimy kierować na adres info@kentino.com.