Kalkulator TCO AI: 4 gotowe scenariusze chmura vs on-prem
Czas czytania: ok. 9 min · Klaster: vendor-eval · Poziom: CIO / CFO
Metodykę liczenia TCO dla AI rozłożyłem osobno: pełny przykład liczbowy i wzory oraz jak w ogóle liczyć w 3-letnim horyzoncie. Ten post jest inny: to biblioteka gotowych scenariuszy. Zamiast uczyć wzoru, pokazuje cztery typowe profile firm przeliczone tymi samymi stawkami, żebyś rozpoznał swój i od razu zobaczył werdykt. Do własnej decyzji podstaw własne liczby w interaktywnym kalkulatorze TCO.
Wszystkie scenariusze liczę na jednym modelu otwartowagowym klasy 70B, w horyzoncie 3 lat, tymi samymi stawkami orientacyjnymi z 2026 roku: managed API ok. 0,60 USD za milion tokenów, wynajem karty GPU ok. 3 USD za godzinę, węzeł on-prem z dwiema kartami klasy H100 to ok. 285 tys. USD wszystkich kosztów w 3 lata. Liczby służą pokazaniu proporcji, nie są cennikiem.
Spis treści
- Cztery zmienne, które przewracają wynik
- Scenariusz 1: pilotaż, niski wolumen
- Scenariusz 2: średni service desk z ciężkim RAG
- Scenariusz 3: wysokie obłożenie 24/7, wiele workflowów
- Scenariusz 4: umiarkowany wolumen, dane nie mogą wyjść
- Macierz: rozpoznaj swój scenariusz
- Dźwignia, która przesuwa werdykt
- Czego tu nie pokrywam
- Disclosure i biases
Cztery zmienne, które przewracają wynik
Zanim spojrzysz na scenariusze, warto wiedzieć, co je od siebie różni. Wynik TCO przesuwają zawsze te same cztery zmienne: wolumen zapytań miesięcznie, długość kontekstu na zapytanie (w RAG to on, a nie samo pytanie, robi rachunek per token), tryb dostępności (całodobowy kontra godziny pracy) i klasa modelu. Cena karty GPU, wbrew intuicji, jest najmniej ważna. Cztery profile poniżej różnią się właśnie tymi zmiennymi, i dlatego dają cztery różne werdykty.
Scenariusz 1: pilotaż, niski wolumen
Firma testuje jeden workflow, na przykład klasyfikację zgłoszeń. Wolumen 8 000 zapytań miesięcznie, lekki kontekst 4 000 tokenów na zapytanie, model dostępny tylko w godzinach pracy.
| Model rozliczenia | Compute (3 lata) | Reszta (3 lata) | Razem (3 lata) |
|---|---|---|---|
| Managed API per token | ok. 700 USD | ok. 20 000 USD | ok. 21 000 USD |
| Wynajem GPU (godziny pracy) | ok. 45 000 USD | ok. 100 000 USD | ok. 145 000 USD |
| On-prem CAPEX plus OPEX | CAPEX 95 000 USD | ok. 190 000 USD | ok. 285 000 USD |
Werdykt: managed API, miażdżąco. Przy tym wolumenie compute to grosze, a cały koszt to governance i integracje, które i tak poniesiesz. Własny sprzęt to tu zmarnowany kapitał: karta stoi bezczynna przez większość doby. On-prem rozważaj dopiero, gdy pilotaż udowodni wolumen albo gdy dane od początku nie mogą wyjść (patrz scenariusz 4).
Scenariusz 2: średni service desk z ciężkim RAG
Wewnętrzny service desk na dokumentacji technicznej, model odpowiada z długiego kontekstu. Wolumen 150 000 zapytań miesięcznie, ciężki kontekst 12 000 tokenów na zapytanie, dostępność w rozszerzonych godzinach pracy.
| Model rozliczenia | Compute (3 lata) | Reszta (3 lata) | Razem (3 lata) |
|---|---|---|---|
| Managed API per token | ok. 39 000 USD | ok. 70 000 USD | ok. 109 000 USD |
| Wynajem GPU (blisko ciągłej pracy) | ok. 158 000 USD | ok. 102 000 USD | ok. 260 000 USD |
| On-prem CAPEX plus OPEX | CAPEX 95 000 USD | ok. 190 000 USD | ok. 285 000 USD |
Werdykt: API nadal najtańsze, ale próg się zbliża. Ciężki kontekst RAG mocno podnosi rachunek per token, bo płacisz za każdy token retrievalu. Gdyby kontekst albo wolumen wzrósł jeszcze dwukrotnie, API i on-prem zaczęłyby się schodzić. Na tym poziomie decyzja o on-prem to wciąż decyzja o kontroli danych i compliance, nie o cenie.
Scenariusz 3: wysokie obłożenie 24/7, wiele workflowów
AI jest fundamentem operacji: service desk plus generowanie instrukcji plus wsparcie ofertowania, całodobowo, z wielu zakładów. Wolumen 1,8 miliona zapytań miesięcznie, kontekst 9 000 tokenów, tryb 24 na 7.
| Model rozliczenia | Compute (3 lata) | Reszta (3 lata) | Razem (3 lata) |
|---|---|---|---|
| Managed API per token | ok. 350 000 USD | ok. 63 000 USD | ok. 413 000 USD |
| On-prem (rozbudowany, możliwe 2 węzły) | CAPEX ok. 150 000 USD | ok. 170 000 USD | ok. 320 000 USD |
Werdykt: on-prem wygrywa na obu frontach naraz. Powyżej progu, który wypada w okolicy 1,5 miliona zapytań miesięcznie utrzymanych przez trzy lata, koszt krańcowy własnego sprzętu bije rozliczenie per token, a argument regulacyjny wskazuje w tę samą stronę. Uwaga pojemnościowa: taki wolumen przy stałej współbieżności może wymagać więcej niż jednego węzła, więc CAPEX rośnie, ale rachunek i tak schodzi poniżej API.
Scenariusz 4: umiarkowany wolumen, dane nie mogą wyjść
Podmiot kluczowy NIS2, dokumentacja objęta tajemnicą przedsiębiorstwa, której nie wolno wypuścić poza perymetr. Wolumen umiarkowany, 60 000 zapytań miesięcznie, kontekst 9 000 tokenów, godziny pracy.
| Model rozliczenia | Razem (3 lata) | Uwaga |
|---|---|---|
| Managed API per token | ok. 75 000 USD | Najtańsze, ale dane wychodzą poza perymetr |
| On-prem CAPEX plus OPEX | ok. 285 000 USD | Ok. 4x drożej, dane zostają u Ciebie |
Werdykt: on-prem, mimo że jest droższy. To scenariusz, w którym TCO nie jest jedynym kryterium. Różnica ok. 210 tys. USD w trzy lata to nie strata, to policzalna cena kontroli nad danymi. Wartość tej kalkulacji polega na tym, że zamieniasz decyzję z „on-prem albo chmura" na „kontrola danych kosztuje nas tyle, i świadomie ją wybieramy". O tym, jak nie zamknąć się przy tym u jednego dostawcy, pisałem w poście o zapobieganiu vendor lock-in.
Macierz: rozpoznaj swój scenariusz
| Profil | Wolumen / mies. | Co zwykle wygrywa na koszcie | Kiedy zmienia się werdykt |
|---|---|---|---|
| Pilotaż, lekki kontekst | poniżej 50 000 | Managed API, zdecydowanie | Prawie nigdy przy tym wolumenie |
| Średni service desk, ciężki RAG | 100 000 do 500 000 | Nadal API | Ciężki kontekst lub model frontier zbliżają on-prem |
| Wysokie obłożenie 24/7 | powyżej 1,5 mln, stale | On-prem CAPEX | Poniżej progu wraca API |
| Regulowany, dane nie wychodzą | dowolny | On-prem (mimo wyższego kosztu) | Gdy dane mogą wyjść, wraca rachunek kosztowy |
Dźwignia, która przesuwa werdykt
Każdy scenariusz przewraca jedna zmienna, nie cena karty.
W pilotażu przewraca go wolumen: dopóki nie urośnie, żaden własny sprzęt się nie zamortyzuje. W średnim service desku przewraca go długość kontekstu: podwojenie kontekstu RAG podwaja koszt per token, ale nie rusza on-prem, więc ciężki retrieval przybliża próg opłacalności własnego sprzętu. W scenariuszu 24/7 przewraca go tryb dostępności: gdyby model nie musiał działać w nocy, wynajem GPU w godzinach pracy długo biłby on-prem. A w scenariuszu regulowanym werdykt nie zależy od kosztu wcale, tylko od tego, czy dane w ogóle mogą wyjść.
Praktyczny wniosek: zanim policzysz cokolwiek, ustal te cztery zmienne dla siebie. Dopiero wtedy kalkulator zamieni orientacyjny scenariusz w Twoją decyzję.
// co tu nie pokrywamCzego tu nie pokrywam
- Wyprowadzenia wzorów i pełnej metodyki, bo to osobny post o metodyce i przykładzie liczbowym.
- Konkretnego cennika operatorów API i stawek wynajmu GPU, bo zmieniają się co kwartał. Podaję rzędy wielkości, nie tabelę cen.
- Kosztu per token na poziomie sprzętu, który rozbieram osobno w poście o milionie tokenów.
- Sizingu kart pod konkretny model i pełnego mapowania regulacyjnego NIS2 oraz AI Act.
// disclosure i biasesDisclosure i biases
Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc mam skłonność do akcentowania kontroli danych. Starałem się to zrównoważyć: w trzech z czterech scenariuszy on-prem przegrywa na czystym koszcie, i mówię to wprost. 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 i realny wolumen. To nie jest porada finansowa ani inwestycyjna.
Powiązane notatki
- Metodyka: Kalkulator TCO dla AI: metodyka, przykład liczbowy i FAQ — wzory i pełne wyprowadzenie jednego scenariusza.
- Jak liczyć: TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie — trzy modele kosztu i punkt przecięcia.
- Koszt per token: Ile kosztuje milion tokenów on-prem: H100 vs H200 vs API — skąd bierze się stawka compute.
- Lock-in: Jak zapobiec vendor lock-in w AI: klauzule i plan wyjścia — jak nie zamknąć się u dostawcy, gdy wybierasz chmurę.
- Sizing: GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków — ile sprzętu stoi za scenariuszem on-prem.
Buduje CortexMine, on-prem AI platform dla europejskich producentów objętych NIS2. Tam, gdzie ta stronniczość mogłaby zaważyć na wnioskach, oznacza to inline.
Chcesz przełożyć to na swój przypadek: architekturę, zgodność i koszt?
→ Umów 30 min
Jak zapobiec vendor lock-in w AI: klauzule i plan wyjścia
Rozpoznanie lock-inu to połowa roboty. Druga połowa to zapobieganie: co wpisać do umowy, zanim podpiszesz, i jaki plan wyjścia trzymać od dnia pierwszego. Gotowe klauzule kontraktowe i operacyjny runbook migracji dla podmiotu kluczowego NIS2.
Kalkulator TCO dla AI: metodyka, przykład liczbowy i FAQ
Kalkulator TCO dla AI musi liczyć trzy scenariusze osobno: managed API per token, wynajem GPU i on-prem CAPEX, w tym samym 3-letnim horyzoncie. Metodyka, wzory, pełny przykład liczbowy dla 40 tys. zapytań miesięcznie i FAQ.
RFP dla AI vendora compliance: szkielet 24 pytań w 4 kategoriach
Gotowy szkielet RFP dla dostawcy AI w regulowanym manufacturing: 24 pytania w czterech kategoriach, security, regulacje, architektura i exit. Każde z celem i wskazówką, jak punktować odpowiedzi.