Kalkulator TCO dla AI: metodyka, przykład liczbowy i FAQ

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

Odpowiedź najpierw

Kalkulator TCO dla AI odpowiada na jedno pytanie: przy jakim poziomie wykorzystania własny sprzęt zaczyna być tańszy od chmury w twoim konkretnym przypadku. Żeby dać sensowną odpowiedź, musi liczyć trzy scenariusze osobno, tymi samymi kategoriami kosztu, w tym samym trzyletnim horyzoncie: managed API rozliczane per token, wynajem karty GPU per godzina i on-prem CAPEX z pełnym OPEX.

Werdykt, który wychodzi z liczb, jest niewygodny dla obu obozów. Dla umiarkowanego wolumenu, rzędu kilkudziesięciu tysięcy zapytań miesięcznie na modelu otwartowagowym, najtańsze na czystym koszcie jest managed API per token, i to z dużym zapasem. On-prem broni się wtedy kontrolą danych i compliance, nie ceną. Wynajem GPU dogania on-prem dopiero przy trybie 24 na 7. A on-prem CAPEX zaczyna bić per token dopiero powyżej mniej więcej 1,5 miliona zapytań miesięcznie utrzymanych przez pełne trzy lata. Poniżej pokazuję dokładną metodykę i pełny przykład liczbowy, który to daje.

Ten tekst jest towarzyszem kalkulatora i rozwinięciem notatki TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie. Tamta tłumaczy, dlaczego cena karty to najmniej ważna liczba. Tu przeliczamy konkretny scenariusz od wejścia do wyniku.

Spis treści

1. Co kalkulator TCO musi liczyć, a czego zwykle nie liczy
2. Metodyka: trzy wzory, których nie wolno mieszać
3. Dane wejściowe: co wpisujesz do kalkulatora
4. Przykład liczbowy: service desk w produkcji, 3 lata
5. Zestawienie: trzy scenariusze obok siebie
6. Punkt przecięcia i analiza wrażliwości
7. Dlaczego naiwna kalkulacja się wykłada
8. Jak czytać wynik
9. FAQ
10. Disclosure i biases
11. Czego tu nie pokrywam
12. Powiązane notatki

Co kalkulator TCO musi liczyć, a czego zwykle nie liczy

Większość kalkulatorów TCO dla AI w sieci liczy jedną rzecz: koszt compute. Cena karty albo stawka za token, pomnożona przez czas. To daje liczbę, która wygląda konkretnie i jest błędna, bo pomija od 30 do 60 procent realnego rachunku.

Uczciwy kalkulator TCO musi objąć pięć kategorii po każdej stronie: compute, energię i utrzymanie infrastruktury, ludzi, compliance oraz koszty projektowe i wyjścia. Compute jest najłatwiejszy do policzenia i najmniej różnicujący. Prawdziwa różnica między on-prem a chmurą siedzi w ludziach i w compliance, a te pozycje najczęściej wypadają z kalkulacji, bo nie mają wygodnej stawki jednostkowej.

Druga rzecz, której kalkulator musi pilnować, to jednorodność horyzontu. Trzy lata po obu stronach, bo tyle wynosi typowa amortyzacja sprzętu i tyle realnie planuje się workflow produkcyjny. Krótszy horyzont zawyża przewagę chmury, dłuższy zawyża przewagę on-prem. Horyzont ustala się przed liczbami, nie dobiera po fakcie do pożądanego wyniku.

Metodyka: trzy wzory, których nie wolno mieszać

Słowo „chmura" oznacza dwa zupełnie różne modele rozliczenia, a on-prem to trzeci. Wymieszanie ich to najczęstsza przyczyna kalkulacji, które nie bronią się przed CFO. Poniżej trzy wzory, każdy osobno.

Wzór 1. Managed API per token.

Koszt compute (mies.) = liczba zapytań × średnia liczba tokenów na zapytanie × cena za token

Tokeny liczysz łącznie: wejście plus wyjście, w tym cały kontekst retrievalu. W zastosowaniach RAG to kontekst, a nie samo pytanie, robi większość rachunku. Do compute dolicz storage wektorów, egress oraz koszt governance i due diligence zewnętrznego vendora.

Wzór 2. Wynajem GPU per godzina.

Koszt compute (mies.) = liczba kart × godziny pracy w miesiącu × stawka godzinowa

Kluczowa zmienna to godziny pracy. Model dostępny całą dobę płaci również za godziny, w których nikt nie pyta. Model wystawiony tylko w godzinach pracy zakładu płaci ułamek tego. Do compute dolicz storage, egress, adres IP oraz, tak jak przy API, koszt governance vendora zewnętrznego. Sam model i tak stawiasz i utrzymujesz samodzielnie, więc dochodzi ułamek etatu.

Wzór 3. On-prem CAPEX plus OPEX.

TCO (3 lata) = CAPEX + (OPEX roczny × 3) + koszty projektowe − wartość rezydualna

CAPEX amortyzujesz, OPEX ponosisz co roku, koszty projektowe są jednorazowe, a sprzęt po trzech latach zachowuje wartość, którą odejmujesz. Koszt krańcowy kolejnej godziny liczenia jest tu najniższy ze wszystkich trzech modeli, ale każda niewykorzystana godzina to zmarnowany kapitał.

Reguła doboru: nie porównuj on-prem CAPEX z 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 stawiałbyś model samodzielnie, twoim odniesieniem jest wynajem GPU. Jeśli wystarczyłoby ci gotowe API, odniesieniem jest per token.

Dane wejściowe: co wpisujesz do kalkulatora

Żeby wynik dało się obronić, kalkulator potrzebuje ośmiu liczb wejściowych. Cztery opisują obciążenie, cztery opisują twoje warunki.

Obciążenie: liczba zapytań miesięcznie, średnia liczba tokenów wejścia na zapytanie (z kontekstem RAG), średnia liczba tokenów wyjścia, tryb dostępności (całodobowy albo w godzinach pracy). Warunki: stawka za energię biznesową w twojej taryfie, koszt pełnego etatu inżynierskiego w twojej organizacji, wymagany poziom audytu i pen-testu, klasa modelu, która załatwia twoje zadanie.

Ostatnia liczba jest najważniejsza i najczęściej przeszacowana. Wiele workflowów w produkcji, klasyfikacja zgłoszeń, wyciąganie danych z dokumentów, odpowiedzi service desku na bazie wewnętrznej dokumentacji, załatwia model otwartowagowy klasy 70B, nie największy dostępny model frontier. To przesuwa cały rachunek, bo tańszy model to niższa stawka za token i mniejszy sprzęt on-prem.

Przykład liczbowy: service desk w produkcji, 3 lata

Bierzemy jeden konkretny scenariusz i przeliczamy go trzema wzorami. Wszystkie liczby są orientacyjne, oparte na publicznych stawkach rynkowych z 2026 roku, i służą pokazaniu metody. Do własnej decyzji podstaw własne stawki.

Założenia:

• Firma produkcyjna, wewnętrzny service desk plus RAG na dokumentacji technicznej.
• Wolumen: 40 000 zapytań miesięcznie.
• Kontekst: średnio 8 000 tokenów wejścia (pytanie plus fragmenty z retrievalu) i 1 000 tokenów wyjścia, razem 9 000 tokenów na zapytanie.
• Model: otwartowagowy klasy 70B.
• Sprzęt on-prem: jeden węzeł z dwiema kartami klasy H100 80 GB.
• Horyzont: 3 lata. Stawka energii biznesowej: ok. 0,24 USD za kWh. Pełny etat inżynierski: ok. 80 000 USD rocznie.

Scenariusz A, managed API per token.

Miesięcznie: 40 000 zapytań razy 9 000 tokenów to 360 mln tokenów. Przy blended stawce ok. 0,60 USD za milion tokenów dla modelu klasy 70B daje to ok. 216 USD miesięcznie za compute, czyli ok. 7 800 USD w trzy lata. Do tego storage wektorów i egress ok. 15 000 USD na trzy lata oraz governance i due diligence vendora zewnętrznego, ułamek etatu, ok. 48 000 USD na trzy lata.

Pozycja (per token)	3 lata (USD)
Compute (per token)	7 800
Storage wektorów, egress	15 000
Governance i due diligence vendora	48 000
Razem	ok. 71 000

Scenariusz B, wynajem GPU per godzina.

Przy stawce ok. 3 USD za godzinę GPU liczy się tryb pracy. Całodobowo: 2 karty razy 8 760 godzin rocznie razy 3 USD to ok. 52 600 USD rocznie, czyli ok. 157 700 USD w trzy lata. W godzinach pracy zakładu, przyjmijmy 10 godzin przez 250 dni roboczych, to 2 500 godzin na kartę rocznie, czyli ok. 45 000 USD compute w trzy lata. W obu wariantach model stawiasz sam, więc dochodzi ok. 0,3 etatu (ok. 72 000 USD na trzy lata), storage i egress (ok. 15 000 USD) oraz due diligence vendora (ok. 15 000 USD).

Pozycja (wynajem GPU)	Tryb 24 na 7	Godziny pracy
Compute (per godzina GPU)	157 700	45 000
Ludzie (0,3 etatu)	72 000	72 000
Storage, egress, IP	15 000	15 000
Due diligence vendora	15 000	15 000
Razem	ok. 260 000	ok. 147 000

Scenariusz C, on-prem CAPEX plus OPEX.

CAPEX: dwie karty klasy H100 ok. 60 000 USD, serwer z RAM, NVMe i redundantnym zasilaniem ok. 20 000 USD, sieć, szafa, UPS i rozbudowa chłodzenia ok. 15 000 USD, razem ok. 95 000 USD. OPEX rocznie: energia dla węzła ok. 3 kW w trybie ciągłym to ok. 6 000 USD, kontrakt serwisowy ok. 5 000 USD, ludzie ok. 0,4 etatu ok. 32 000 USD, audyt i pen-test ok. 5 000 USD, platforma lub wsparcie open-source ok. 12 000 USD, razem ok. 60 000 USD rocznie. Koszty projektowe jednorazowe, integracja z ERP i MES, szkolenia, iteracje pierwszego półrocza, ok. 25 000 USD. Wartość rezydualna sprzętu po trzech latach ok. 15 000 USD na minus.

Pozycja (on-prem, 3 lata)	USD
CAPEX (karty, serwer, sieć, chłodzenie)	95 000
OPEX (energia, serwis, ludzie, audyt, platforma) razy 3	180 000
Koszty projektowe (integracja, szkolenia, iteracje)	25 000
Wartość rezydualna sprzętu	−15 000
Razem	ok. 285 000

Zestawienie: trzy scenariusze obok siebie

Scenariusz	Compute (3 lata)	Reszta (3 lata)	Razem (3 lata)
Managed API per token	ok. 7 800	ok. 63 000	ok. 71 000
Wynajem GPU, godziny pracy	ok. 45 000	ok. 102 000	ok. 147 000
Wynajem GPU, 24 na 7	ok. 157 700	ok. 102 000	ok. 260 000
On-prem CAPEX plus OPEX	CAPEX 95 000	ok. 190 000	ok. 285 000

Dla tego wolumenu managed API jest najtańsze, i to nie o kilka procent, tylko wielokrotnie. Compute to w nim najmniejsza pozycja. On-prem, przy tym samym obciążeniu, kosztuje na czystym rachunku około cztery razy tyle. To nie jest argument przeciw on-prem, to argument za tym, żeby uzasadniać on-prem tym, czym trzeba: kontrolą danych, wymogiem NIS2 albo RODO, brakiem zgody na wypuszczenie dokumentacji poza perymetr. Nie ceną, bo na cenie przy tym wolumenie on-prem przegrywa.

Punkt przecięcia i analiza wrażliwości

Wynik przewraca jedna zmienna: wolumen. Reszta liczb tylko przesuwa próg.

Kiedy on-prem CAPEX zaczyna bić managed API na czystym koszcie? Trzyletni koszt on-prem, ok. 285 000 USD, podzielony przez stawkę 0,60 USD za milion tokenów, to ok. 475 miliardów tokenów w trzy lata, czyli ok. 13 miliardów miesięcznie. Przy 9 000 tokenów na zapytanie to ok. 1,5 miliona zapytań miesięcznie utrzymanych przez pełne trzy lata. Poniżej tego progu, na czystym koszcie, API wygrywa.

Trzy dźwignie, które przesuwają próg:

• Długość kontekstu. Podwojenie kontekstu RAG podwaja koszt per token, ale nie rusza on-prem. Ciężki retrieval przybliża próg opłacalności on-prem.
• Tryb dostępności. Wynajem GPU w godzinach pracy kosztuje ułamek trybu całodobowego. Jeśli model nie musi być dostępny w nocy, wynajem długo bije on-prem.
• Klasa modelu. Droższy model frontier zamiast otwartowagowego 70B potrafi kilkukrotnie podnieść stawkę za token i tym samym mocno obniżyć próg, od którego on-prem się opłaca.

Wykorzystanie (zapytania / mies.)	Co zwykle wygrywa na koszcie
Poniżej 100 000	Managed API per token
100 000 do 500 000	Nadal API, chyba że ciężki kontekst lub model frontier
500 000 do 1,5 mln	Granica, decyduje kontekst, tryb i klasa modelu
Powyżej 1,5 mln, stale, przez 3 lata	On-prem CAPEX

Dlaczego naiwna kalkulacja się wykłada

Cztery błędy, które regularnie wywracają wynik i sprawiają, że kalkulacja nie broni się na spotkaniu z zarządem.

Pierwszy: porównanie ceny karty z zerem po stronie chmury. Karta widnieje w rachunku on-prem, a chmura na starcie nie ma widocznego wydatku, więc wychodzi tańsza, dopóki nie zsumujesz osiemnastu miesięcy faktur. Drugi: pominięcie ludzi. Nawet productized on-prem potrzebuje ułamka etatu platform engineera i bezpieczeństwa, a DIY realnie jednego do dwóch inżynierów. Trzeci: liczenie tokenów po długości pytania zamiast po pełnym kontekście. W RAG kontekst bywa wielokrotnie większy od pytania, więc rachunek per token rośnie razem z nim. Czwarty: brak kosztu regulacyjnego po stronie chmury. Vendor zewnętrzny to coroczne due diligence, mapowanie transferów, klauzule DPA i re-ewaluacja przy każdej zmianie podprocesora. To realna praca, którą trzeba doliczyć.

Piąty, cichy: dobranie horyzontu do wyniku. Jeśli ktoś liczy on-prem na pięć lat, a chmurę na dwa, dostanie liczbę, jaką chciał dostać. Ten sam horyzont po obu stronach jest warunkiem uczciwości, nie szczegółem.

Jak czytać wynik

Kalkulator nie mówi „on-prem albo chmura". Mówi, o ile jedno jest droższe od drugiego przy twoim wolumenie, i pokazuje, jak daleko jesteś od progu przecięcia. To pozwala oddzielić decyzję kosztową od decyzji o ryzyku.

Jeśli wychodzisz mocno poniżej progu, jak w przykładzie powyżej, decyzję o on-prem podejmujesz na podstawie compliance i kontroli danych, ze świadomością, ile ta kontrola kosztuje. Jeśli jesteś blisko progu, decyduje profil ryzyka i horyzont. Jeśli jesteś powyżej progu, on-prem wygrywa na obu frontach naraz i rachunek jest prosty. W każdym z tych przypadków next step jest ten sam: podstaw własne stawki, taryfę i realny wolumen, bo dopiero twoje liczby zamieniają orientacyjny przykład w decyzję.

FAQ

Jak policzyć TCO wdrożenia AI?

Zsumuj pięć kategorii kosztu, compute, infrastrukturę, ludzi, compliance oraz koszty projektowe i wyjścia, po każdej stronie porównania, w tym samym trzyletnim horyzoncie. Dla chmury wybierz właściwy model rozliczenia, per token albo per godzina GPU, a dla on-prem policz CAPEX plus trzy lata OPEX minus wartość rezydualna. Compute to najmniejsza różnica, prawdziwa różnica siedzi w ludziach i compliance.

Który model chmury porównywać z on-prem, API czy wynajem GPU?

Ten, 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 i dwa różne progi opłacalności.

Od jakiego wolumenu on-prem AI zaczyna się opłacać?

W przykładzie z modelem klasy 70B próg wobec managed API wypada w okolicy 1,5 miliona zapytań miesięcznie utrzymanych przez trzy lata. Wobec wynajmu GPU w trybie całodobowym on-prem jest konkurencyjny znacznie wcześniej. Próg mocno zależy od długości kontekstu, trybu dostępności i klasy modelu.

Co najczęściej znika z rachunku?

Po stronie on-prem: ludzie, energia i koszty projektowe pierwszego półrocza. Po stronie chmury: koszt regulacyjny vendora zewnętrznego, egress, storage wektorów i godziny GPU opłacane, gdy nikt nie pyta. Dolicz do prostej sumy compute od 20 do 40 procent na pozycje, które nie mają wygodnej stawki jednostkowej.

Czy niższy koszt chmury oznacza, że on-prem nie ma sensu?

Nie. Oznacza, że on-prem trzeba uzasadniać kontrolą danych i compliance, nie ceną, dopóki wolumen jest umiarkowany. Przy wysokim, stałym obłożeniu rachunek kosztowy i argument regulacyjny wskazują w tę samą stronę.

// 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ć: przykład liczbowy pokazuje wprost, że dla umiarkowanego wolumenu on-prem jest droższy od managed API, i to wielokrotnie. Wszystkie liczby są orientacyjne, oparte na publicznych stawkach rynkowych i 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 stawek konkretnych operatorów, bo zmieniają się co kwartał. Podaję metodę i orientacyjne rzędy wielkości, nie tabelę cen.
• Sizingu kart pod konkretny model, bo to osobny temat prowadzony liczbami z benchmarków.
• Trzech modeli utrzymania on-prem, DIY, productized i managed, i tego, kto za co odpowiada.
• Pełnego mapowania regulacyjnego NIS2 i AI Act, które wpływa na koszt pośrednio.
• Federacji modeli między zakładami grupy kapitałowej, gdzie rachunek TCO wygląda inaczej.

Powiązane notatki

• TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie
• GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków
• 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
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe