TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie

Czas czytania: ok. 12 minut. Klaster: vendor-eval. Autor: Fryderyk.

Odpowiedź najpierw

O tym, czy on-prem AI wychodzi taniej od chmury, nie decyduje cena karty GPU. Decydują dwie liczby: poziom wykorzystania (ile godzin na miesiąc sprzęt realnie liczy) i horyzont amortyzacji. On-prem wygrywa, gdy obłożenie jest wysokie i stałe, a horyzont co najmniej trzyletni. Chmura, rozliczana per token albo per godzina GPU, wygrywa przy niskim, nieregularnym albo trudnym do przewidzenia wolumenie, przy pilotażach i tam, gdzie nie ma zespołu do utrzymania infrastruktury.

Surowy punkt przecięcia jest prostszy, niż się wydaje: karta za około 25 tys. USD kontra wynajem po około 3 USD za godzinę GPU zrównuje się po mniej więcej 8 tys. godzin, czyli po niecałym roku pracy w trybie 24 na 7. Problem w tym, że ten rachunek pomija całą resztę: serwerownię, energię, ludzi i compliance. Po ich doliczeniu on-prem staje się tańszy dopiero przy naprawdę wysokim, stałym obłożeniu utrzymanym przez pełne trzy lata. Poniżej pokazuję, jak policzyć oba scenariusze tak, żeby liczby dało się obronić przed zarządem i przed audytorem, i gdzie realnie leży granica.

Spis treści

1. Dlaczego cena sprzętu to najmniej ważna liczba
2. Trzy modele kosztu, których nie wolno mieszać
3. Model on-prem: co wchodzi do rachunku na 3 lata
4. Model chmury: per token i per godzina GPU
5. Punkt przecięcia: jedna zmienna, która przesądza
6. Kiedy chmura wygrywa uczciwie
7. Tabela: co uwzględnić, czego nie zapomnieć
8. FAQ
9. Disclosure i biases
10. Czego tu nie pokrywam
11. Powiązane notatki

Dlaczego cena sprzętu to najmniej ważna liczba

Rozmowa o TCO on-prem AI prawie zawsze zaczyna się od złej strony: od ceny karty. To zrozumiałe, bo cena jest widoczna i konkretna, a nowa karta klasy H100 to wydatek rzędu 25 do 40 tys. USD za sztukę, zależnie od wariantu i dostawcy. Kłopot w tym, że karta to najmniej ryzykowna pozycja w całym rachunku, bo jest jednorazowa, znana z góry i amortyzowalna.

Prawdziwe koszty siedzą w miejscach, o których łatwo zapomnieć na etapie decyzji. Karta za 25 tys. potrzebuje serwera, w którym zamieszka, zasilania, chłodzenia, miejsca w szafie, aktualizacji i człowieka, który to utrzyma. W praktyce pełny setup produkcyjny potrafi kosztować 30 do 50 procent powyżej samej ceny kart. A po stronie chmury odwrotnie: nie ma żadnego widocznego wydatku na start, więc łatwo policzyć ją jako tańszą, dopóki nie zsumuje się faktur za osiemnaście miesięcy stałego wolumenu.

Dlatego jedyny uczciwy sposób porównania to zestawienie pełnego rachunku obu scenariuszy w tym samym horyzoncie, zwykle trzyletnim, bo tyle wynosi typowa amortyzacja sprzętu i tyle realnie planuje się workflow produkcyjny. Wszystko krótsze faworyzuje chmurę, wszystko dłuższe faworyzuje on-prem, więc horyzont trzeba ustalić przed liczbami, nie po nich.

Trzy modele kosztu, których nie wolno mieszać

Pierwsza pułapka porównania: „chmura" nie jest jedną rzeczą. Są trzy różne modele rozliczenia i dają trzy różne wyniki. Wymieszanie ich to najczęstsza przyczyna kalkulacji, które nie bronią się przed CFO.

Model 1. Chmura per token (managed API modelu). Płacisz za każdy tysiąc tokenów wejścia i wyjścia. Zero infrastruktury po twojej stronie. Koszt rośnie liniowo z wolumenem zapytań i długością kontekstu. To model dla API typu OpenAI, Anthropic, Azure OpenAI, Bedrock. Zaleta: brak CAPEX, natychmiastowy start, koszt zero przy zerowym użyciu. Wada regulatorna: dane wychodzą poza perymetr, vendor wchodzi do łańcucha dostaw NIS2.

Model 2. Chmura per godzina GPU (wynajem karty). Wynajmujesz kartę albo klaster na godziny i sam stawiasz na niej model. To najbardziej porównywalny z on-prem wariant, bo płacisz za ten sam zasób, tylko cudzy. Stawki rynkowe w 2026 dla H100 to mniej więcej 2 do 3.5 USD za godzinę GPU na wyspecjalizowanych chmurach, wyraźnie więcej u hyperscalerów. Zaleta: elastyczność, brak CAPEX. Wada: przy pracy 24 na 7 rachunek rośnie szybko, a dane nadal stoją u operatora chmury.

Model 3. On-prem CAPEX (karta u ciebie). Kupujesz sprzęt, amortyzujesz, utrzymujesz. Wysoki koszt na starcie, niski koszt krańcowy każdej kolejnej godziny liczenia. To model, w którym każda niewykorzystana godzina GPU to zmarnowany kapitał, ale każda wykorzystana jest tania.

Reguła: nie porównuj on-prem CAPEX z chmurą per token, bo mierzysz dwie różne rzeczy (kapitał kontra zużycie). Najpierw ustal, który model chmurowy jest twoją realną alternatywą. Jeśli i tak sam stawiałbyś model, twoim punktem odniesienia jest wynajem GPU (model 2). Jeśli zadowoliłbyś się gotowym API, punktem odniesienia jest per token (model 1). To dwie różne kalkulacje i dwa różne progi opłacalności.

Model on-prem: co wchodzi do rachunku na 3 lata

Pełny TCO on-prem składa się z czterech grup, nie z jednej. Poniżej lista pozycji, które muszą się znaleźć w kalkulacji, żeby liczba była uczciwa.

CAPEX, amortyzowany zwykle na 3 do 5 lat:

• Serwer z kartami GPU, RAM, dyski NVMe, redundantne zasilanie, karta zarządzająca. To rdzeń wydatku.
• Sieć: przełącznik, okablowanie, ewentualny interconnect dla multi-node.
• Zasilanie awaryjne i rozbudowa chłodzenia serwerowni pod dodatkowe kilowaty.
• Opcjonalnie drugi, mniejszy node na redundancję albo na środowisko testowe.

OPEX, rocznie:

• Energia. Tu liczysz pobór mocy (karty plus chłodzenie) razy PUE serwerowni razy cena kilowatogodziny razy godziny pracy. Dla firm w Polsce w 2026 realna, pełna stawka biznesowa (energia czynna plus dystrybucja plus opłaty systemowe) mieści się mniej więcej w przedziale 0.20 do 0.25 EUR za kilowatogodzinę netto, zależnie od taryfy i profilu zużycia. Węzeł z dwiema kartami H100 plus chłodzenie to około 3 kW, co w trybie 24 na 7 daje rzędu kilku tysięcy EUR rocznie.
• Kontrakt serwisowy na sprzęt (typu ProSupport albo równoważny).
• Utrzymanie oprogramowania: albo licencja productized platformy, albo koszt zespołu przy DIY na open-source.
• Ludzie. Nawet productized wdrożenie potrzebuje ułamka etatu platform engineera i ułamka etatu bezpieczeństwa. DIY potrzebuje realnie 1 do 2 pełnych inżynierów ML.
• Audyt i pen-test, dla podmiotów kluczowych NIS2 co najmniej raz w roku.

Koszty projektowe, jednorazowe, często pomijane:

• Czas zarządu, CISO, prawnika i compliance na samą decyzję i due diligence.
• Czas działu na integrację systemu źródłowego (ERP, MES, PLM).
• Szkolenie użytkowników i iteracje pierwszego półrocza (tuning promptów, tuning retrievalu, czyszczenie treści).

Wartość rezydualna i exit:

• Po 3 latach sprzęt ma jeszcze wartość księgową i użytkową. Karta nie znika, można ją przenieść do innego workloadu.
• Koszt wyjścia jest niski: dane i tak są u ciebie, nie ma egressu ani re-platformingu.

Praktyczna reguła: do prostej sumy CAPEX plus OPEX dolicz 20 do 40 procent na koszty projektowe i iteracje. Kalkulacja bez tego bufora zawsze zaniża on-prem i zawyża jego przewagę nad chmurą.

Model chmury: per token i per godzina GPU

Po stronie chmury rachunek jest pozornie prostszy, ale ma własne pozycje, które znikają z naiwnej kalkulacji.

Per token. Koszt = liczba zapytań miesięcznie razy średnia liczba tokenów na zapytanie (wejście plus wyjście, w tym cały kontekst retrievalu) razy cena za token. Kluczowa obserwacja: w zastosowaniach RAG kontekst potrafi być duży, więc koszt na zapytanie bywa wielokrotnie wyższy, niż sugeruje sama długość pytania. Do tego dochodzą pozycje ukryte: egress danych, storage wektorów, jeśli trzymasz je w tej samej chmurze, i koszt czasu na wdrożenie kontroli, które przepuszczą taki przepływ przez due diligence NIS2.

Per godzina GPU. Koszt = liczba kart razy godziny pracy razy stawka godzinowa. Tu pułapką jest tryb pracy. Jeśli model musi być dostępny cały czas (service desk w godzinach pracy zakładu, a często dłużej), płacisz za godziny również wtedy, gdy nikt nie pyta. Stawki spot bywają dużo niższe, ale wiążą się z ryzykiem przerwania, więc do produkcji zwykle nie pasują. Do tego dochodzą opłaty za storage, egress i adres IP, różne u różnych operatorów.

Wspólna dla obu wariantów pozycja, którą stale się pomija: koszt regulacyjny. Zewnętrzny vendor w łańcuchu dostaw oznacza coroczne due diligence, mapowanie transferów, klauzule DPA i re-ewaluację przy każdej zmianie podprocesora. To realna praca, którą trzeba doliczyć po stronie chmury, a która w on-prem jest niższa, bo dostawca jest wewnętrzny.

Punkt przecięcia: jedna zmienna, która przesądza

Kiedy zsumujesz oba rachunki, okazuje się, że prawie wszystko zależy od jednej zmiennej: poziomu wykorzystania, czyli ile godzin GPU miesięcznie realnie zużywasz.

Surowa matematyka wynajmu kontra zakupu jest znana: karta za 25 tys. USD kontra stawka 3 USD za godzinę zrównuje się po około 8.3 tys. godzin, czyli po mniej więcej 347 dniach pracy w trybie ciągłym. Gdyby liczył się tylko sam sprzęt, próg przebiegałby poniżej roku. Ale on-prem to nie tylko karta, więc realny próg jest wyżej. W praktyce zakup zaczyna bić wynajem dopiero przy stałym obłożeniu rzędu 10 tys. godzin GPU miesięcznie utrzymanym przez trzy lata i więcej, a taki poziom osiąga mniejszość organizacji.

Poniżej uproszczona mapa, gdzie zwykle leży granica. Liczby są orientacyjne i zależą od stawek, taryf i konkretnego modelu, ale porządek wielkości się trzyma.

Wykorzystanie (godziny GPU / miesiąc)	Charakterystyka	Co zwykle wygrywa na koszcie
Poniżej 1 000	Pilotaż, wolumen nieregularny, mało zapytań	Chmura per token lub wynajem GPU on-demand
1 000 do 5 000	Jeden stały workflow, umiarkowany wolumen	Zwykle nadal chmura na czystym koszcie, on-prem wygrywa kontrolą
5 000 do 10 000	Stały service desk, kilka workflowów	Granica parity, decyduje horyzont i profil ryzyka
Powyżej 10 000, stale, przez 3 lata	Wysokie, przewidywalne obłożenie 24 na 7	On-prem CAPEX

Wniosek jest niewygodny dla obu obozów. On-prem nie jest magicznie tańszy, dopóki nie masz wysokiego, stałego obłożenia. Chmura nie jest magicznie tańsza, gdy takie obłożenie masz i utrzymasz je latami. Dlatego zanim policzysz cokolwiek, oszacuj realny wolumen zapytań i długość kontekstu, bo to one, a nie cena karty, przesądzają wynik.

Kiedy chmura wygrywa uczciwie

Warto to powiedzieć wprost, bo portal o on-prem AI ma naturalną skłonność do promowania on-prem. Są sytuacje, w których chmura jest po prostu tańsza i rozsądniejsza, i udawanie inaczej kończy się złą decyzją inwestycyjną.

• Pilotaż i proof of concept. Dopóki nie wiesz, czy workflow w ogóle się przyjmie, płacenie z góry za sprzęt jest zakładem w ciemno. Chmura pozwala zmierzyć realny wolumen, zanim policzysz on-prem.
• Niski albo nieregularny wolumen. Kilka lub kilkanaście zapytań dziennie nigdy nie zamortyzuje karty. Tu on-prem to zmarnowany kapitał.
• Brak zespołu do utrzymania. Jeśli nie masz i nie planujesz platform engineera ani kompetencji bezpieczeństwa dla warstwy modelu, koszt zbudowania tego zespołu przewyższy oszczędność na sprzęcie.
• Workflow o niskiej wrażliwości danych. Jeśli dane nie są objęte NIS2, RODO w trybie wrażliwym ani NDA, argument regulacyjny za on-prem słabnie, a zostaje sam rachunek, który przy niskim wolumenie wskazuje na chmurę.

On-prem broni się tam, gdzie schodzą się trzy warunki naraz: wysokie stałe obłożenie, długi horyzont i dane, których nie wolno albo nie opłaca się wypuścić poza perymetr. Gdy brakuje któregokolwiek z nich, przewaga topnieje.

Tabela: co uwzględnić, czego nie zapomnieć

Kategoria kosztu	On-prem (3 lata)	Chmura (3 lata)
Compute	CAPEX na karty i serwer, amortyzowany	OPEX per token lub per godzina GPU
Energia i chłodzenie	Pobór mocy razy PUE razy stawka kWh	W cenie usługi
Serwerownia lub colo	Szafa, UPS, klimatyzacja	Brak
Ludzie	0.3 do 0.5 FTE platform przy productized, więcej przy DIY	Mniejszy, ale nie zero: integracje i governance
Oprogramowanie	Open-source lub licencja productized	W cenie API
Compliance	Niższy koszt due diligence, dostawca wewnętrzny	Coroczne due diligence vendora zewnętrznego
Exit i migracja	Dane zostają, sprzęt zachowuje wartość	Re-platforming, egress danych
Koszty projektowe	Decyzja, integracje, szkolenia, iteracje	Integracje, szkolenia, kontrole pod DD

Dwie kolumny, ten sam horyzont, te same kategorie. Dopiero taka tabela pozwala porównać jabłka z jabłkami. Naiwna kalkulacja porównuje cenę karty z zerem po stronie chmury i zawsze wychodzi błędnie.

FAQ

Czy on-prem AI jest tańszy od chmury?

Nie w sposób ogólny. Jest tańszy przy wysokim, stałym wykorzystaniu utrzymanym przez co najmniej trzy lata. Przy niskim albo nieregularnym wolumenie chmura zwykle wygrywa na koszcie. Różnica częściej leży w profilu ryzyka regulacyjnego niż w samej cenie.

Jaki horyzont przyjąć do kalkulacji?

Standardem jest trzy lata, bo tyle wynosi typowa amortyzacja sprzętu i tyle realnie planuje się workflow produkcyjny. Krótszy horyzont faworyzuje chmurę, dłuższy on-prem, więc horyzont trzeba ustalić przed liczeniem, nie dobierać po fakcie do pożądanego wyniku.

Z czym właściwie porównywać on-prem, z API czy z wynajmem GPU?

Z tym modelem chmury, który byłby twoją realną alternatywą. Jeśli i tak stawiałbyś model samodzielnie, punktem odniesienia jest wynajem GPU. Jeśli wystarczyłoby ci gotowe API, punktem odniesienia jest rozliczenie per token. To dwie różne kalkulacje.

Co najczęściej znika z rachunku on-prem?

Ludzie, energia, koszty projektowe i iteracje pierwszego półrocza. Dolicz do prostej sumy CAPEX plus OPEX około 20 do 40 procent, żeby kalkulacja była uczciwa.

Co najczęściej znika z rachunku chmury?

Koszt regulacyjny zewnętrznego vendora w łańcuchu dostaw, egress danych, storage wektorów oraz godziny GPU opłacane wtedy, gdy nikt nie pyta, przy modelu dostępnym cały czas.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc mam naturalną skłonność do akcentowania kontroli danych i przewagi on-prem tam, gdzie wchodzi compliance. Starałem się to zrównoważyć, dlatego osobna sekcja mówi wprost, kiedy chmura wygrywa, a mapa punktu przecięcia pokazuje, że dla większości organizacji o niskim wolumenie on-prem nie jest tańszy. Liczby w tekście są orientacyjne i oparte na publicznych stawkach rynkowych oraz taryfach z 2026 roku, nie na wyniku konkretnego wdrożenia. Do własnej decyzji podstaw własne stawki, taryfę i realny wolumen. To nie jest porada finansowa ani inwestycyjna.

// co tu nie pokrywamCzego tu nie pokrywam

• Konkretnego cennika modeli API i konkretnych stawek vendorów, bo zmieniają się co kwartał i szybko by się zdezaktualizowały. Podaję metodę, nie tabelę cen.
• Doboru samego sprzętu i sizingu kart pod konkretny model, bo to osobny temat prowadzony liczbami z benchmarków.
• Trzech modeli utrzymania on-prem (DIY, productized, managed) i tego, kto za co odpowiada, bo to osobna notatka.
• Pełnego mapowania regulacyjnego NIS2 i AI Act, które wpływa na koszt pośrednio, ale rządzi się własną logiką.
• Scenariuszy federacji modeli między zakładami grupy kapitałowej, gdzie rachunek TCO wygląda inaczej.

Powiązane notatki

• Bare-metal, colo czy appliance: gdzie postawić on-prem AI (CAPEX i OPEX)
• DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje
• GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe
• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny