Dobór GPU i kwantyzacja LLM, gdy H200 jest niedostępny

Dobór GPU i kwantyzacja LLM, gdy H200 jest niedostępny
Czas czytania: ok. 9 minut. Klaster: on-prem AI. Autor: Fryderyk.
Odpowiedź najpierw
Jeśli chcesz postawić model otwartowagowy klasy 70B u siebie, a H200 ma kilkumiesięczny lead time, decyzja nie polega na czekaniu na najlepszą kartę. Polega na dopasowaniu precyzji modelu do pamięci karty, którą realnie kupisz w tym kwartale. Kwantyzacja jest tu dźwignią, nie kompromisem ostatniej szansy: to ona decyduje, czy model 70B zejdzie z dwóch kart na jedną i czy zmieści się na sprzęcie, który jest na stanie.
W skrócie. Model 70B w BF16 waży około 140 GB samych wag, więc wymaga dwóch kart 80 GB spiętych NVLinkiem. Kwantyzacja do FP8 tnie to do około 70 GB i mieści model na jednej karcie 80 GB, ale FP8 działa natywnie dopiero na Hopperze i Adzie, nie na Ampere. Kwantyzacja wagowa do INT4, w schematach AWQ lub GPTQ, schodzi do około 35 GB i pozwala uruchomić 70B nawet na pojedynczej karcie 48 GB, kosztem mierzalnego, choć zwykle niewielkiego spadku jakości. Gdy H200 jest poza zasięgiem, realna ścieżka to najczęściej H100 80 GB z FP8, A100 80 GB z kwantyzacją wagową, albo L40S 48 GB z INT4 dla mniejszego obciążenia.
Wniosek: kartę dobiera się pod to, co jest dostępne, a precyzję dobiera się pod kartę. Kolejność jest taka, nie odwrotna. Poniżej rozkładam, ile pamięci zjada model w każdej precyzji, na czym się mieści po kwantyzacji i czym płacisz za każdy krok w dół.
Spis treści
- Dlaczego to jest pytanie o dostępność, nie o ranking kart
- Ile pamięci realnie zjada model 70B
- Tabela: zapotrzebowanie VRAM per precyzja
- Kwantyzacja: co robi FP8, a co INT4
- Karta zamiast H200: co realnie kupisz
- Tabela: karty i to, na czym mieści się 70B
- Czym płacisz za każdy krok w dół
- Ścieżka decyzyjna w czterech krokach
- Czego ta notatka nie zastępuje
- FAQ
- Disclosure i biases
- Czego tu nie pokrywam
- Powiązane notatki
Dlaczego to jest pytanie o dostępność, nie o ranking kart
Latem 2026 dostępność akceleratorów przestała być tłem decyzji i stała się jej głównym ograniczeniem. Najmocniejsze karty idą w pierwszej kolejności do dużych kontraktów, a polityka eksportowa dodatkowo przesuwa alokację między rynkami: gdy w połowie lipca Stany Zjednoczone poluzowały reguły i dopuściły wysyłkę H200 do Chin z dodatkowym obciążeniem celnym, część podaży, która mogła trafić na inne rynki, została skierowana tam, gdzie popyt jest największy. Dla europejskiego zakładu średniej wielkości znaczy to jedno: karta z górnej półki bywa niedostępna od ręki, a wdrożenie i tak trzeba domknąć w tym kwartale.
To zmienia charakter pytania. „Która karta jest najlepsza do inferencji 70B" ma znaną odpowiedź i opisywałem ją od strony liczb w benchmarkach. Ale pytanie, które faktycznie pada na spotkaniu zakupowym, brzmi inaczej: „na czym postawię ten model, skoro H200 przyjdzie najwcześniej za kilka miesięcy". To jest pytanie o dopasowanie modelu do dostępnego sprzętu, a nie o wybór szczytu tabeli. Kwantyzacja jest narzędziem, które to dopasowanie umożliwia, bo pozwala zejść z wymaganej pamięci na tyle, żeby model zmieścił się na karcie, którą naprawdę da się kupić.
Wydarzenie rynkowe jest tu dowodem, nie tematem. Kontrole eksportowe przywołuję po to, żeby pokazać, dlaczego planowanie pod jedną konkretną kartę jest kruche, a nie żeby komentować politykę handlową. Wniosek architektoniczny jest niezależny od tego, w którą stronę pójdą kolejne decyzje regulacyjne: projekt wdrożenia powinien znosić podmianę karty, a to znaczy zaprojektować go wokół precyzji i pamięci, nie wokół jednego modelu akceleratora.
Ile pamięci realnie zjada model 70B
Pamięć karty musi pomieścić trzy rzeczy naraz, a nie tylko same wagi modelu. Pierwsza to wagi: liczba parametrów razy liczba bajtów na parametr, która zależy od precyzji. Druga to pamięć podręczna klucz-wartość, w skrócie KV cache, która rośnie z długością kontekstu i liczbą równoległych zapytań. Trzecia to bufor na aktywacje i narzut serwera inferencyjnego. Kto liczy tylko wagi, zaniża wymaganie i dobiera kartę, na której model wprawdzie się załaduje, ale padnie przy pierwszym dłuższym kontekście albo wyższym batchu.
Same wagi liczą się prosto. Model 70B w precyzji dwubajtowej, czyli FP16 lub BF16, to około 140 GB. W FP8, czyli jednym bajcie na parametr, to około 70 GB. W INT4, czyli pół bajta, to około 35 GB. Do tego trzeba doliczyć realny bufor na KV cache i aktywacje, który przy sensownym kontekście i umiarkowanej równoległości potrafi dołożyć od kilkunastu do kilkudziesięciu procent. Dlatego w tabeli poniżej podaję osobno wagi i osobno szacunek pamięci realnie potrzebnej do stabilnego serwowania, bo to ta druga liczba rozstrzyga, na ilu kartach model stanie.
Tabela: zapotrzebowanie VRAM per precyzja
Liczby są orientacyjne, dla modelu otwartowagowego klasy 70B, przy umiarkowanym kontekście i batchu. Pokazują metodę i rzędy wielkości, nie są gwarancją dla konkretnego stacku serwowania. Do własnej decyzji podstaw własny model, długość kontekstu i profil równoległości.
| Precyzja | Bajty/param | Wagi (~70B) | Realny VRAM z KV i buforem | Mieści się na |
|---|---|---|---|---|
| BF16 / FP16 | 2 | ok. 140 GB | ok. 170 do 200 GB | 2x 80 GB (NVLink) |
| FP8 | 1 | ok. 70 GB | ok. 90 do 100 GB | 1x 141 GB komfortowo, 1x 80 GB ciasno, 2x 48 GB |
| INT8 (wagowo) | 1 | ok. 70 GB | ok. 90 do 100 GB | jak FP8, ale bez wymogu Hoppera/Ady |
| INT4 (AWQ/GPTQ) | 0,5 | ok. 35 GB | ok. 45 do 55 GB | 1x 48 GB ciasno, 1x 80 GB komfortowo |
Dwie rzeczy z tej tabeli. Po pierwsze, każdy krok w dół po precyzji mniej więcej połowi zapotrzebowanie na pamięć, a to właśnie połowienie decyduje o zejściu z dwóch kart na jedną. Po drugie, „mieści się" to nie to samo co „mieści się komfortowo": FP8 na jednej karcie 80 GB zostawia mało miejsca na KV cache, więc przy dłuższym kontekście albo wyższej równoległości i tak będziesz potrzebować drugiej karty albo kroku do INT4.
Kwantyzacja: co robi FP8, a co INT4
Kwantyzacja to zapisanie modelu z mniejszą liczbą bitów na parametr. Mniej bitów to mniej pamięci i, przy inferencji ograniczonej pasmem pamięci, także szybsze generowanie, bo każdą warstwę czyta się z pamięci szybciej. Ceną jest utrata precyzji zapisu, która przekłada się na jakość odpowiedzi. Kluczowe jest to, że różne schematy płacą tę cenę w bardzo różnej wysokości.
FP8 to format zmiennoprzecinkowy ośmiobitowy. Zachowuje zakres dynamiczny bliski FP16, więc utrata jakości jest zwykle na granicy mierzalności, a przyspieszenie realne. Haczyk jest sprzętowy: natywne wsparcie FP8 mają dopiero Hopper, czyli H100 i H200, oraz Ada, czyli L40S i RTX 6000 Ada. Na starszym Ampere, czyli A100 i A10, FP8 nie ma akceleracji sprzętowej, więc tam sięga się po kwantyzację wagową.
INT4 w schematach AWQ lub GPTQ to kwantyzacja wagowa: do czterech bitów kompresuje się same wagi, a obliczenia i tak biegną w wyższej precyzji po dekwantyzacji. To najsilniejsza dźwignia pamięciowa, bo tnie wagi do jednej czwartej rozmiaru z FP16 i pozwala zmieścić 70B na pojedynczej karcie 48 GB. Cena jakości jest wyższa niż przy FP8 i, co ważniejsze, zależna od zadania: na jednych zadaniach spadek jest ledwie zauważalny, na innych, zwłaszcza wymagających precyzyjnego rozumowania na długim kontekście, potrafi być odczuwalny. Dlatego INT4 zawsze trzeba zmierzyć na własnym zadaniu, a nie przyjąć na wiarę z cudzego benchmarku.
Karta zamiast H200: co realnie kupisz
Gdy H200 odpada z powodu dostępności, sensowne alternatywy układają się w krótką listę, a każda ma inny profil pamięci, pasma i wsparcia dla precyzji. Nie chodzi o to, żeby wybrać „drugą najlepszą" kartę w oderwaniu, tylko o to, żeby dopasować parę karta plus precyzja do modelu, który ma stanąć.
H100 80 GB to najbliższy zamiennik: ten sam Hopper co H200, natywne FP8, tyle że 80 GB zamiast 141 GB i węższe pasmo pamięci. Zwykle ma krótszy lead time niż H200, bo jest dłużej na rynku i więcej sztuk krąży. A100 80 GB jest najszerzej dostępna, także z rynku wtórnego, ale to Ampere: bez natywnego FP8 i z wyraźnie wolniejszym pasmem, więc na 70B pracuje się na niej z kwantyzacją wagową INT8 lub INT4 i akceptuje niższą przepustowość. L40S 48 GB i pokrewna RTX 6000 Ada 48 GB to karty Ada z FP8, ale bez NVLinka i z pamięcią GDDR6 o znacznie niższym paśmie niż HBM w kartach centrów danych; nadają się do 70B w INT4 przy umiarkowanym obciążeniu albo do mniejszych modeli, słabo za to skalują w konfiguracji wielokartowej z powodu braku szybkiego łącza między kartami.
Poniżej zestawiam te opcje. Kolumna „główny kompromis" jest tu najważniejsza, bo to ona, a nie sama liczba pamięci, decyduje, czy dana karta pasuje do twojego profilu ruchu.
Tabela: karty i to, na czym mieści się 70B
Liczby pasma i pamięci są orientacyjne, oparte na publicznych specyfikacjach z 2026 roku. Konfiguracja „mieści 70B" zakłada umiarkowany kontekst i batch; przy agresywnym obciążeniu każdą z tych opcji trzeba przeliczyć własnym benchmarkiem.
| Karta | VRAM | Pasmo pamięci | FP8 natywnie | 70B mieści się jako | Główny kompromis |
|---|---|---|---|---|---|
| H100 80 GB | 80 GB | ok. 3,35 TB/s | tak (Hopper) | FP8 na 1x (ciasno), BF16 na 2x | dalej trudno dostępna, ale krótszy lead time niż H200 |
| A100 80 GB | 80 GB | ok. 2,0 TB/s | nie (Ampere) | INT8/INT4 na 1x, BF16 na 2x | brak FP8, wolniejsze pasmo, za to szeroka dostępność |
| L40S 48 GB | 48 GB | ok. 0,86 TB/s | tak (Ada) | INT4 na 1x, FP8 na 2x | brak NVLinka, niskie pasmo, słabo skaluje wielokartowo |
| RTX 6000 Ada 48 GB | 48 GB | ok. 0,96 TB/s | tak (Ada) | INT4 na 1x | karta stacji roboczej, brak NVLinka |
Odczyt jest praktyczny. Jeśli zależy ci na jakości bliskiej pełnej precyzji i masz stały ruch, celuj w H100 z FP8 albo w parę A100. Jeśli budżet i dostępność pchają cię na 48 GB, model 70B da się na tym postawić wyłącznie w INT4, więc od razu zaplanuj pomiar jakości na własnym zadaniu, zanim zamkniesz decyzję.
Czym płacisz za każdy krok w dół
Każde zejście, czy to niższa precyzja, czy słabsza karta, ma cenę i warto ją nazwać wprost, żeby nikt nie odkrył jej po zakupie.
Za krok z FP16 na FP8 płacisz zwykle najmniej: utrata jakości jest na granicy mierzalności, a w zamian dostajesz połowę pamięci i szybsze generowanie. To najtańsza dźwignia i zwykle pierwszy ruch, o ile karta wspiera FP8 natywnie. Za krok z FP8 na INT4 płacisz już zauważalnie: dostajesz kolejne połowienie pamięci i możliwość zejścia na jedną kartę 48 GB, ale ryzykujesz spadek jakości, który na zadaniach wymagających precyzyjnego rozumowania bywa odczuwalny. To dźwignia, którą stosuje się świadomie i po pomiarze, nie domyślnie.
Za wybór wolniejszej karty płacisz przepustowością, a nie jakością. A100 policzy dokładnie ten sam model co H100, tylko wolniej, bo ma węższe pasmo pamięci, a inferencja w fazie generowania jest pasmem ograniczona. Za wybór karty bez NVLinka, jak L40S, płacisz skalowaniem: dwie takie karty nie łączą się w tak wydajną parę jak dwie karty centrum danych ze szybkim łączem, więc konfiguracja wielokartowa daje mniej, niż sugeruje suma pamięci. To ma bezpośrednie przełożenie na koszt za milion tokenów i na próg obłożenia, przy którym własny sprzęt zaczyna się opłacać wobec API, co rozkładałem osobno w notatce o koszcie miliona tokenów.
Ścieżka decyzyjna w czterech krokach
Zamiast zaczynać od karty, zacznij od modelu i ruchu, a karta wyjdzie na końcu.
Krok pierwszy: ustal model i wymaganą jakość. Klasa 70B w pełnej precyzji to punkt odniesienia; jeśli twoje zadanie znosi INT4 bez odczuwalnego spadku, przestrzeń dostępnych kart robi się znacznie szersza. Krok drugi: policz realny VRAM, czyli wagi w docelowej precyzji plus bufor na KV cache pod twój kontekst i równoległość, nie same wagi. Krok trzeci: dobierz najniższą precyzję, która utrzymuje jakość na twoim zadaniu, i dopiero pod nią dobierz kartę, która jest dostępna, sprawdzając przy okazji, czy wspiera tę precyzję natywnie. Krok czwarty: zmierz. Przepustowość i jakość po kwantyzacji potwierdź własnym benchmarkiem na docelowym stacku serwowania, bo cudze liczby są punktem wyjścia, nie werdyktem.
Ta kolejność ma jedną zaletę, która liczy się przy niepewnej dostawie: jest odporna na podmianę karty. Jeśli projekt stoi na precyzji i realnym budżecie pamięci, a nie na jednym modelu akceleratora, to zmiana dostawcy sprzętu w połowie procesu jest korektą, a nie powrotem do punktu wyjścia.
Czego ta notatka nie zastępuje
To jest notatka o doborze karty pod dostępność, nie pełny benchmark ani rachunek kosztu. Ile dokładnie tokenów na sekundę wyciśniesz z każdej konfiguracji, rozkładałem od strony liczb w osobnym materiale o GPU sizingu dla Llamy 3.1 70B. Ile realnie kosztuje milion tokenów na własnym GPU i przy jakim obłożeniu bije to API, liczyłem w notatce o koszcie miliona tokenów. Pełne, trzyletnie TCO wdrożenia, z energią, ludźmi i compliance, jest przedmiotem kalkulatora TCO. Ta notatka jest krokiem przed tamtymi: najpierw ustal, na czym w ogóle postawisz model, potem licz jego throughput i koszt.
FAQ
Jaki GPU do modelu 70B, jeśli nie mam dostępu do H200?
Najbliższy zamiennik to H100 80 GB z kwantyzacją FP8, która mieści model na jednej karcie. Jeśli H100 też jest trudno dostępna, sensowna jest para A100 80 GB w kwantyzacji wagowej albo pojedyncza karta 48 GB, jak L40S, ale wtedy model 70B stawia się wyłącznie w INT4 i trzeba zmierzyć jakość na własnym zadaniu.
Ile pamięci GPU potrzebuje model 70B?
Same wagi to około 140 GB w BF16, około 70 GB w FP8 lub INT8 i około 35 GB w INT4. Do tego dolicz bufor na KV cache i aktywacje, który przy sensownym kontekście dokłada od kilkunastu do kilkudziesięciu procent. Dlatego realne, stabilne serwowanie 70B w BF16 wymaga dwóch kart 80 GB, a nie jednej.
Czy kwantyzacja do INT4 psuje jakość modelu?
Obniża ją mierzalnie, ale zwykle nieznacznie, a skala zależy od zadania. Na wielu zastosowaniach spadek jest ledwie zauważalny; na zadaniach wymagających precyzyjnego rozumowania na długim kontekście bywa odczuwalny. INT4 daje najsilniejszą oszczędność pamięci, ale zawsze trzeba go zweryfikować na własnym zadaniu, a nie przyjąć z cudzego benchmarku.
FP8 czy INT4: co wybrać?
Jeśli karta wspiera FP8 natywnie, czyli jest to Hopper lub Ada, zacznij od FP8, bo płacisz najmniejszą cenę jakości. Po INT4 sięgaj, gdy potrzebujesz zejść na jedną kartę 48 GB albo gdy używasz Ampere bez natywnego FP8, i wtedy zaplanuj pomiar jakości jako część decyzji, nie jako formalność.
Dlaczego A100 działa wolniej niż H100 na tym samym modelu?
Bo ma węższe pasmo pamięci, około 2,0 TB/s wobec 3,35 TB/s, a inferencja w fazie generowania tokenów jest ograniczona właśnie pasmem, nie mocą obliczeniową. A100 policzy ten sam model poprawnie, tylko wolniej, i dodatkowo bez natywnego FP8, więc na niej stosuje się kwantyzację wagową.
// 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 pokazywania, że on-prem da się postawić także wtedy, gdy najmocniejszy sprzęt jest niedostępny. Starałem się to zrównoważyć: mówię wprost, że schodzenie na słabsze karty i niższą precyzję ma cenę, że INT4 potrafi odczuwalnie obniżyć jakość na części zadań i że część opisanych opcji ma sens dopiero po pomiarze na własnym zadaniu. 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 inaczej rozkłada ryzyko doboru sprzętu. Wszystkie liczby pamięci i pasma są orientacyjne, oparte na publicznych specyfikacjach z 2026 roku, nie na wyniku konkretnego wdrożenia. To nie jest porada zakupowa ani inwestycyjna.
// co tu nie pokrywamCzego tu nie pokrywam
Nie podaję konkretnych tokenów na sekundę per konfiguracja, bo to zależy od stacku serwowania i jest przedmiotem osobnego materiału o GPU sizingu. Nie liczę kosztu per token ani pełnego TCO, bo prowadzę je w osobnych notatkach. Nie omawiam kart nowszej generacji ani wielowęzłowych klastrów, bo dla pojedynczego modelu klasy 70B nie zmieniają wniosku o doborze pod dostępność. Nie wchodzę w parametry świeżych modeli otwartowagowych, bo bez potwierdzonych danych o ich rozmiarze i wymaganiach byłoby to zgadywanie; punktem odniesienia jest tu klasa 70B. Nie rozstrzygam też polityki eksportowej ani jej dalszego kierunku, bo przywołuję ją wyłącznie jako powód, dla którego warto projektować wdrożenie odporne na podmianę karty.
Powiązane notatki
- GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków
- Ile kosztuje milion tokenów on-prem: H100 vs H200 vs API
- Kalkulator TCO dla AI: metodyka, przykład liczbowy i FAQ
- Bare-metal, colo czy appliance: gdzie postawić on-prem AI (CAPEX i OPEX)
- AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
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
DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje
"On-prem AI" to nie jeden model wdrożenia, tylko co najmniej trzy, z różnym profilem kosztów, ryzyka i obciążenia zespołu. Rozkładamy je na czynniki, żeby CISO i CIO wiedzieli, którą rozmowę naprawdę prowadzą przed RFP.

Bare-metal, colo czy appliance: gdzie postawić on-prem AI (CAPEX i OPEX)
Bare-metal we własnej serwerowni, colo z dedykowanym sprzętem, managed appliance dostarczany przez vendora. Trzy modele on-prem deploymentu AI w europejskiej produkcji 2026: liczby CAPEX i OPEX, profile ryzyka NIS2, kiedy który ma sens, i kiedy lepiej zrezygnować z on-prem w ogóle.

AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
Architektura, GPU sizing, bezpieczeństwo, integracje, TCO, build vs buy. Praktyczny przewodnik wdrożenia AI on-prem dla CISO i CIO w europejskiej produkcji w 2026.