Ile kosztuje milion tokenów on-prem: H100 vs H200 vs API

Czas czytania: ok. 9 minut. Klaster: architektura. Autor: Fryderyk.

Odpowiedź najpierw

Koszt miliona tokenów na własnym GPU nie wynika z ceny karty ani z peak throughput z benchmarku. Wynika z jednego dzielenia: stawka za godzinę pracy karty podzielona przez liczbę tokenów, które karta realnie wyprodukuje w tej godzinie. A ta liczba zależy od obłożenia, nie od tego, ile karta potrafi wycisnąć przy pełnym nasyceniu.

Przy pełnym nasyceniu węzeł z kartami klasy H100 serwuje model otwartowagowy klasy 70B za mniej więcej 0,55 USD za milion tokenów, a nowszy H200, dzięki wyższej przepustowości pamięci, schodzi bliżej 0,35 USD. Obie liczby są w okolicy ceny, jaką za tę samą klasę modelu bierze managed API, czyli około 0,60 USD za milion tokenów. Haczyk jest taki, że te 0,55 i 0,35 obowiązują tylko wtedy, gdy karta pracuje bez przerwy. Przy obłożeniu 25 procent efektywny koszt rośnie czterokrotnie, bo za bezczynne godziny płacisz tak samo. API nie ma tego problemu, bo płacisz wyłącznie za tokeny, które faktycznie wyszły.

Wniosek: własny GPU bije API na czystym koszcie compute dopiero powyżej bardzo wysokiego, stałego obłożenia. H200 przesuwa ten próg wyraźnie w dół wobec H100, ale go nie kasuje. Poniżej progu argumentem za on-prem jest kontrola danych i compliance, nie cena za token. Poniżej rozbieram to dzielenie krok po kroku.

Spis treści

1. Dlaczego peak throughput to zła liczba
2. Wzór: od stawki godzinowej do kosztu za milion tokenów
3. H100 vs H200: co realnie różni te karty na inferencji 70B
4. Tabela: koszt za milion tokenów przy pełnym nasyceniu
5. Zmienna, która wywraca rachunek: obłożenie
6. Tabela: efektywny koszt per obłożenie
7. Próg opłacalności wobec API
8. Dlaczego naiwna kalkulacja się wykłada
9. Czym ten tekst różni się od kalkulatora TCO
10. FAQ
11. Disclosure i biases
12. Czego tu nie pokrywam
13. Powiązane notatki

Dlaczego peak throughput to zła liczba

Karta w benchmarku serwera inferencyjnego podaje przepustowość szczytową: ile tokenów na sekundę wyciska przy pełnym batchu, maksymalnej równoległości i idealnym obciążeniu. To liczba użyteczna do sizingu i do porównania sprzętu między sobą, opisywałem ją osobno dla Llamy 3.1 70B. Do rachunku kosztowego jest jednak myląca, bo w produkcji karta prawie nigdy nie stoi nasycona.

Rachunek kosztu ma trzy piętra i większość kalkulacji zatrzymuje się na pierwszym. Pierwsze piętro to stawka za godzinę karty. Drugie to ile tokenów karta produkuje w godzinie, gdy jest w pełni obciążona, czyli przepustowość razy 3600 sekund. Trzecie, najczęściej pomijane, to jaki procent tych godzin karta faktycznie coś liczyła. Dopiero po przejściu przez wszystkie trzy piętra dostajesz liczbę, którą można pokazać CFO: efektywny koszt za milion realnie wyprodukowanych tokenów. Peak throughput opisuje tylko drugie piętro i to przy założeniu, którego produkcja nie spełnia.

Wzór: od stawki godzinowej do kosztu za milion tokenów

Cały tekst stoi na jednym wzorze, więc warto go rozpisać.

Koszt za 1M tokenów (przy nasyceniu) = stawka za godzinę węzła / (przepustowość w tok/s × 3600 / 1 000 000)

Koszt efektywny za 1M tokenów = koszt przy nasyceniu / obłożenie

Stawka za godzinę węzła to nie stawka za jedną kartę, tylko za tyle kart, ile model realnie potrzebuje. Model klasy 70B w BF16 nie mieści się na jednej karcie 80 GB, więc węzeł H100 to dwie karty. To pierwsza pułapka: porównywanie ceny jednej karty z ceną API, gdy do uruchomienia modelu potrzeba dwóch.

Przepustowość w tym wzorze to zagregowany output serwera przy wysokim batchu, nie prędkość pojedynczego zapytania. Serwer obsługujący wiele zapytań naraz produkuje łącznie znacznie więcej tokenów na sekundę niż widzi pojedynczy użytkownik, i to ta zagregowana liczba dzieli koszt.

Obłożenie to udział godzin, w których węzeł faktycznie liczył, w całości godzin, za które płacisz. Węzeł wystawiony całodobowo, odpytywany tylko w godzinach pracy zakładu, ma obłożenie rzędu kilkunastu procent, nawet jeśli w szczycie jest nasycony.

H100 vs H200: co realnie różni te karty na inferencji 70B

Inferencja dużego modelu jest w fazie generowania tokenów ograniczona przepustowością pamięci, nie mocą obliczeniową. Dlatego dla kosztu per token liczy się przede wszystkim pasmo pamięci, a tu H200 ma przewagę konstrukcyjną.

H100 to 80 GB pamięci HBM3 i pasmo około 3,35 TB/s. H200 to 141 GB HBM3e i pasmo około 4,8 TB/s, czyli mniej więcej 43 procent więcej. Więcej pamięci oznacza, że model klasy 70B mieści się na jednej karcie H200 z zapasem na kontekst, zamiast wymagać dwóch kart H100. Szersze pasmo oznacza, że ta sama warstwa modelu jest czytana z pamięci szybciej, więc karta generuje tokeny szybciej. W praktyce na modelach tej klasy przekłada się to na przepustowość wyższą o około połowę, a w niektórych konfiguracjach TensorRT-LLM na jeszcze więcej.

Konsekwencja kosztowa jest nieoczywista. H200 ma wyższą stawkę godzinową niż H100, więc na pierwszy rzut oka jest droższy. Ale ponieważ produkuje więcej tokenów w tej samej godzinie i częściej mieści model na jednej karcie zamiast dwóch, koszt za milion tokenów wychodzi niższy. Droższa karta liczona za godzinę bywa tańsza liczona za token. To jest sedno porównania i to jest liczba, która się liczy, jeśli model ma pracować pod stałym obciążeniem.

Tabela: koszt za milion tokenów przy pełnym nasyceniu

Wszystkie liczby są orientacyjne, oparte na publicznych stawkach wynajmu GPU z 2026 roku i na zagregowanej przepustowości dla modelu otwartowagowego klasy 70B. Służą pokazaniu metody, nie są cennikiem. Do własnej decyzji podstaw własne stawki i własny benchmark.

Konfiguracja (model 70B)	Pamięć / pasmo	Stawka węzła	Przepustowość (nasycenie)	Koszt / 1M tokenów
Węzeł 2x H100 80 GB (BF16)	2x 80 GB / 3,35 TB/s	ok. 5,00 USD/h	ok. 2 500 tok/s	ok. 0,55 USD
Węzeł 2x H200 141 GB (BF16)	2x 141 GB / 4,8 TB/s	ok. 7,40 USD/h	ok. 4 000 tok/s	ok. 0,51 USD
1x H200 141 GB (FP8)	141 GB / 4,8 TB/s	ok. 3,70 USD/h	ok. 3 000 tok/s	ok. 0,34 USD
Managed API (klasa 70B)	nie dotyczy	rozliczenie per token	nie dotyczy	ok. 0,60 USD

Dwie rzeczy z tej tabeli. Po pierwsze, przy pełnym nasyceniu własny GPU jest w tej samej lidze cenowej co API, a jedna karta H200 z kwantyzacją FP8 schodzi wyraźnie poniżej. Po drugie, cała ta tabela zakłada obłożenie sto procent, a więc opisuje sufit możliwości, nie realny rachunek. Realny rachunek robi następna sekcja.

Zmienna, która wywraca rachunek: obłożenie

Stawka za godzinę karty jest stała niezależnie od tego, czy ktoś pyta. Managed API działa odwrotnie: nie ma zapytań, nie ma rachunku. To jest cała różnica między dwoma modelami i to ona decyduje o wyniku.

Efektywny koszt za milion tokenów to koszt przy nasyceniu podzielony przez obłożenie. Węzeł, który przy stu procentach kosztuje 0,55 USD za milion, przy pięćdziesięciu procentach kosztuje 1,10, a przy dwudziestu pięciu 2,20. Nie dlatego, że tokeny drożeją, tylko dlatego, że coraz większą część rachunku płacisz za godziny, w których węzeł stał bezczynnie. Cena za token po stronie API pozostaje w tym czasie płaska.

Dlatego pytanie „H100, H200 czy API” jest źle postawione, dopóki nie znasz swojego profilu obłożenia. Model wystawiony dla wewnętrznego service desku, odpytywany w godzinach pracy jednego zakładu, ma niskie obłożenie i przegrywa z API na czystym koszcie, choćby karta w szczycie była nasycona. Model obsługujący stały, całodobowy strumień zapytań z wielu źródeł ma wysokie obłożenie i wtedy własny GPU zaczyna mieć sens także kosztowo.

Tabela: efektywny koszt per obłożenie

Bierzemy węzeł 2x H100 z tabeli wyżej (0,55 USD za milion przy nasyceniu) i pojedynczy H200 FP8 (0,34 USD przy nasyceniu) i dzielimy przez obłożenie. Kolumna API jest płaska, bo taka jest natura rozliczenia per token.

Obłożenie węzła	2x H100 (efektywnie)	1x H200 FP8 (efektywnie)	Managed API
100%	ok. 0,55 USD	ok. 0,34 USD	ok. 0,60 USD
50%	ok. 1,10 USD	ok. 0,68 USD	ok. 0,60 USD
25%	ok. 2,20 USD	ok. 1,36 USD	ok. 0,60 USD
10%	ok. 5,50 USD	ok. 3,40 USD	ok. 0,60 USD

Odczyt jest brutalny. Węzeł H100 bije API na czystym koszcie compute dopiero, gdy trzyma obłożenie powyżej mniej więcej dziewięćdziesięciu procent, co w praktyce oznacza całodobowy, stały strumień zapytań. Pojedynczy H200 z FP8 osiąga parytet z API już przy około pięćdziesięciu siedmiu procentach obłożenia, więc próg jest wyraźnie łatwiejszy do utrzymania. To jest konkretny, liczbowy argument za nowszą kartą tam, gdzie obciążenie jest umiarkowane, ale nie znikome.

Próg opłacalności wobec API

Próg da się policzyć wprost. Własny GPU wygrywa z API na compute, gdy koszt przy nasyceniu podzielony przez obłożenie spada poniżej ceny API. Przekształcając: obłożenie musi być wyższe niż koszt przy nasyceniu podzielony przez cenę API.

Dla węzła 2x H100: 0,55 / 0,60, czyli około 92 procent obłożenia. Dla pojedynczego H200 FP8: 0,34 / 0,60, czyli około 57 procent. Im tańszy jesteś w przeliczeniu na token przy nasyceniu, tym niższe obłożenie wystarczy, żeby pobić API, i dlatego H200 zmienia tę kalkulację jakościowo, nie tylko o kilka procent.

Trzy dźwignie przesuwają ten próg:

• Kwantyzacja. FP8 zamiast BF16 mniej więcej podwaja przepustowość i pozwala zmieścić model na jednej karcie, więc obniża koszt przy nasyceniu i tym samym próg obłożenia. To najtańsza dźwignia, bo nie wymaga dokupienia sprzętu, tylko akceptacji minimalnej utraty jakości, którą trzeba zmierzyć na własnym zadaniu.
• Klasa modelu. Cały rachunek dotyczy modelu otwartowagowego klasy 70B. Model frontier przez API kosztuje wielokrotnie więcej za token, co podnosi cenę odniesienia i drastycznie obniża próg, od którego własny GPU się opłaca. Odwrotnie, mniejszy model 7 do 8B jest tak tani przez API, że własny GPU praktycznie nigdy nie wygra na samym compute.
• Tryb dostępności. Węzeł wyłączany poza godzinami pracy, jeśli wynajmujesz i płacisz tylko za godziny włączenia, sztucznie podnosi obłożenie liczonych godzin. To jedyny sposób, by przy niskim ruchu zbliżyć własny GPU do ekonomiki API.

Dlaczego naiwna kalkulacja się wykłada

Cztery błędy, które regularnie dają liczbę nie do obrony na spotkaniu z zarządem.

Pierwszy: podzielenie stawki karty przez peak throughput i ogłoszenie tego kosztem za token. To pomija obłożenie, czyli jedyną zmienną, która naprawdę rozstrzyga. Liczba wychodzi kilkukrotnie za niska.

Drugi: policzenie jednej karty tam, gdzie model potrzebuje dwóch. Klasa 70B w BF16 nie mieści się na 80 GB, więc realny węzeł H100 to dwie karty i dwie stawki godzinowe. Kto liczy jedną, zaniża koszt o połowę.

Trzeci: użycie przepustowości pojedynczego zapytania zamiast zagregowanej. Serwer przy wysokim batchu produkuje łącznie wielokrotnie więcej tokenów na sekundę niż widzi jeden użytkownik. Liczenie po prędkości jednego zapytania zawyża koszt i prowadzi do odwrotnego, ale równie błędnego wniosku.

Czwarty: potraktowanie H200 jako droższego, bo ma wyższą stawkę godzinową. Za godzinę owszem, ale za token zwykle taniej, bo produkuje więcej i częściej mieści model na jednej karcie. Karta droższa za godzinę potrafi być tańsza za milion tokenów, a to ta druga liczba jest przedmiotem decyzji.

Czym ten tekst różni się od kalkulatora TCO

Tu liczę wyłącznie koszt compute za milion tokenów, czyli jedną pozycję rachunku. To celowe uproszczenie, żeby pokazać mechanikę obłożenia bez szumu. Pełne TCO wdrożenia AI obejmuje jeszcze energię, ludzi, compliance, koszty projektowe i wyjścia, a compute jest tam zwykle najmniejszą i najmniej różnicującą pozycją. Rozbierałem to osobno w kalkulatorze TCO z pełnym przykładem liczbowym na trzy lata.

Praktyczna kolejność jest taka: najpierw policz koszt compute per token tym wzorem, żeby zrozumieć, czy w ogóle jesteś blisko progu obłożenia. Jeśli nie jesteś, dyskusja o własnym GPU na argumencie cenowym się kończy i przenosi na grunt kontroli danych. Jeśli jesteś, dopiero wtedy warto liczyć pełne TCO, bo compute przestaje być pomijalne i reszta pozycji zaczyna rozstrzygać.

FAQ

Ile kosztuje milion tokenów na własnym GPU?

Przy pełnym nasyceniu węzeł z kartami klasy H100 serwuje model klasy 70B za około 0,55 USD za milion tokenów, a pojedynczy H200 z kwantyzacją FP8 za około 0,34 USD. To sufit możliwości. Przy realnym obłożeniu poniżej stu procent koszt rośnie odwrotnie proporcjonalnie: przy dwudziestu pięciu procentach jest czterokrotnie wyższy.

H100 czy H200 do inferencji modelu 70B?

Za godzinę H200 jest droższy, ale za milion tokenów zwykle tańszy, bo ma o około 43 procent szersze pasmo pamięci, więc generuje szybciej, i 141 GB, więc mieści model 70B na jednej karcie zamiast na dwóch. Jeśli model ma pracować pod stałym obciążeniem, H200 zwykle wygrywa na koszcie per token.

Kiedy własny GPU jest tańszy od API?

Na czystym koszcie compute dopiero powyżej bardzo wysokiego obłożenia: około 92 procent dla węzła 2x H100 i około 57 procent dla pojedynczego H200 FP8, wobec ceny API rzędu 0,60 USD za milion tokenów dla klasy 70B. Poniżej tych progów API wygrywa, a własny GPU uzasadnia kontrola danych, nie cena.

Dlaczego API bywa tańsze mimo drogiego sprzętu po stronie dostawcy?

Bo płacisz wyłącznie za tokeny, które wyszły, a nie za bezczynne godziny karty. Operator API uśrednia obłożenie po wielu klientach i utrzymuje karty blisko nasycenia, czego pojedyncza firma z jednym zadaniem zwykle nie osiąga. To przewaga modelu rozliczenia, nie magia cenowa.

Czy kwantyzacja FP8 psuje jakość modelu?

Zwykle nieznacznie, ale to trzeba zmierzyć na własnym zadaniu, nie przyjąć na wiarę. FP8 mniej więcej podwaja przepustowość i pozwala zmieścić model 70B na jednej karcie H200, więc jest najtańszą dźwignią obniżenia kosztu per token, o ile utrata trafności mieści się w twoim progu akceptacji.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad platformą AI uruchamianą poza chmurą publiczną, więc mam naturalną skłonność do akcentowania sensu własnego sprzętu. Starałem się to zrównoważyć liczbami, które idą pod prąd tej skłonności: przy umiarkowanym obłożeniu managed API jest na czystym koszcie compute tańsze od własnego GPU, i to pokazuję wprost, zamiast chować. Na rynku on-prem AI istnieje kilka kategorii rozwiązań, od samodzielnego składania na open-source, przez rozwiązania productized, po modele zarządzane, i każda ma inny profil kosztu. Wszystkie liczby są orientacyjne, oparte na publicznych stawkach wynajmu GPU i cennikach API z 2026 roku, nie na wyniku konkretnego wdrożenia. To nie jest porada finansowa ani inwestycyjna.

// co tu nie pokrywamCzego tu nie pokrywam

Nie liczę pełnego TCO, czyli energii, ludzi, compliance i kosztów projektowych, bo to osobny wątek prowadzony w kalkulatorze TCO. Nie wchodzę w sizing pod konkretny model ani w dobór kwantyzacji, bo to zależy od zadania i zasługuje na własną notatkę. Nie porównuję konkretnych operatorów API po nazwie ani nie podaję ich cennika, bo zmienia się co kwartał, podaję metodę i rzędy wielkości. Nie omawiam kart nowszej generacji ani egzotycznych konfiguracji wielowęzłowych, bo dla modelu klasy 70B nie zmieniają wniosku o obłożeniu. Pomijam też koszt i ryzyko utrzymania własnego sprzętu, które w modelu wynajmu GPU wyglądają inaczej niż we własnej serwerowni.

Powiązane notatki

• GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków
• Kalkulator TCO dla AI: metodyka, przykład liczbowy i FAQ
• TCO on-prem AI vs chmura: jak liczyć w 3-letnim horyzoncie
• Odporność architektury AI: co zaudytujesz on-prem, a co ukrywa chmura
• Monitoring i observability dla on-prem LLM: co logować i jak