GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków

Po co w ogóle to liczyć

Pytanie "ile GPU potrzeba, żeby postawić Llamę 3.1 70B u siebie" pada w trzech rozmowach na pięć z CIO i architektami IT w średniej produkcji. Zwykle pada z dwóch powodów, które się ze sobą mylą:

1. "Czy nas na to stać?" (intencja CFO)
2. "Czy nas to udźwignie operacyjnie?" (intencja architekta IT)

To są dwa różne pytania. Pierwsze odpowiada się tabelą TCO. Drugie odpowiada się benchmarkiem inference: tokens/s, time-to-first-token (TTFT), concurrency, koszt per 1M tokenów. Ten post jest o tym drugim, bo bez liczb z drugiego pytania pierwsza tabela jest zgadywaniem.

Ramy: scenariusz on-prem, średnia firma produkcyjna 200–1000 FTE, model Llama 3.1 70B Instruct, workloady mieszane (RAG z service desk plus generowanie SOP plus drafting ofert), peak concurrency 20–80 jednoczesnych sesji.

Reszta to liczby.

Metryki, które się liczą (i te, które wprowadzają w błąd)

Throughput (tokens/s, output) to ile tokenów model wyprodukuje w jednostce czasu przy zadanym batch size. Standardowy headline benchmark. Pułapka: pojedyncza sesja vs zagregowany throughput pod batch. Marketing producenta zwykle pokazuje to drugie. Operacyjnie obchodzi nas to pierwsze (per request) i to drugie (per server, bo to definiuje, ilu użytkowników jednocześnie obsłużymy).

TTFT (time to first token) to czas od wysłania promptu do pojawienia się pierwszego tokena odpowiedzi. Dla RAG z długim kontekstem (10–30k tokenów) TTFT bywa wyższy niż całe generowanie odpowiedzi w krótkim chacie. Jeśli ktoś pokazuje benchmark bez TTFT przy długim kontekście, pomija najgorszą część doświadczenia.

Concurrency at acceptable latency to ile równoległych sesji utrzymamy przy konkretnym SLO. SLO definiujemy sami. W praktyce dla service desk w produkcji rozsądny próg to TTFT < 2 s i streaming > 25 tokenów/s per sesja. Powyżej tej granicy użytkownik nie odczuwa "myślenia" jako problemu.

Koszt per 1M tokenów (output) to jedyna metryka, która porównuje się z cennikiem chmurowych API. Liczymy go z TCO sprzętu rozłożonego na 3 lata, dzielonego przez zagregowane tokeny wyprodukowane w utilizacji typowej dla średniej firmy (zwykle 25–40% dziennie).

Czego nie patrzę w pierwszej iteracji: MMLU, HellaSwag, czyste rankingi jakościowe. To są wartości użyteczne przy wyborze modelu, nie przy sizingu sprzętu pod model, który już wybraliśmy.

Trzy konfiguracje, które realnie rozważa średnia firma

Założenia wspólne: precyzja FP16 (jako baseline), engine vLLM 0.6+ lub TensorRT-LLM 0.13+, context window 16k tokenów, tensor parallelism w obrębie jednego serwera, brak pipeline parallelism (jeden node). Wartości to mediana z publicznych benchmarków vLLM, NVIDIA Triton i niezależnych testów Anyscale/Together z H2 2025. Wahania ±15% są normalne, zależne od driverów, wersji CUDA i kernel flag.

Konfiguracja A: 2x NVIDIA H100 80GB (single node, tensor parallel 2)

Najczęstsza konfiguracja "wchodzimy w on-prem". Sprzęt mieści się w jednym 4U serwerze, NVLink między GPU obowiązkowy (PCIe-only spada o ~30% throughput).

Llama 3.1 70B, FP16, vLLM 0.6, batch=1, context 4k:

• Single-session throughput: ~32–38 tokenów/s
• TTFT (prompt 4k tokenów): ~600–900 ms
• VRAM użyte: 65 GB per karta (z headroomem na KV cache)

Llama 3.1 70B, FP16, vLLM 0.6, batch=16, context 4k:

• Aggregate throughput: ~380–460 tokenów/s
• Per-session throughput: ~24–28 tokenów/s
• TTFT (prompt 4k): ~1.2–1.6 s

Concurrency at SLO (TTFT < 2 s, per-session > 25 tps): ~12–18 jednoczesnych sesji.

Komentarz: sweet spot dla firmy 200–500 FTE, jeśli AI jest jednym z trzech narzędzi (nie centralnym). Wąskie gardło: KV cache przy dłuższym kontekście (16k+). Każdy dodatkowy 1k kontekstu zjada ~1.2 GB VRAM w batchu 16.

Konfiguracja B: 4x NVIDIA H100 80GB (single node, tensor parallel 4)

Skok wydajności, ale i ceny. Sensowny, jeśli AI ma być fundamentem operacji (service desk plus instrukcje plus oferty równolegle) lub jeśli planujemy upgrade do większego modelu w ciągu 18 miesięcy.

Llama 3.1 70B, FP16, vLLM 0.6, batch=1, context 4k:

• Single-session throughput: ~58–66 tokenów/s
• TTFT (prompt 4k): ~350–500 ms

Llama 3.1 70B, FP16, vLLM 0.6, batch=32, context 4k:

• Aggregate throughput: ~720–860 tokenów/s
• Per-session throughput: ~22–27 tokenów/s
• TTFT (prompt 4k): ~900 ms – 1.3 s

Concurrency at SLO: ~30–40 jednoczesnych sesji.

Komentarz: tensor parallel 4 nie skaluje liniowo (efektywność spada do ~70% vs 2x). Dla większości średnich firm to za dużo, jeśli nie ma jasnego planu wykorzystania.

Konfiguracja C: 2x NVIDIA H200 141GB (single node, tensor parallel 2)

H200 ma 76% więcej VRAM (141 GB vs 80 GB) i ~40% wyższą przepustowość pamięci niż H100. To zmienia matematykę: ten sam model przy wyższej concurrency, większy kontekst za darmo, KV cache nie jest wąskim gardłem do batcha 32+.

Llama 3.1 70B, FP16, vLLM 0.6, batch=1, context 4k:

• Single-session throughput: ~42–48 tokenów/s
• TTFT (prompt 4k): ~480–700 ms

Llama 3.1 70B, FP16, vLLM 0.6, batch=32, context 16k:

• Aggregate throughput: ~620–740 tokenów/s
• Per-session throughput: ~19–23 tokenów/s
• TTFT (prompt 16k): ~2.4–3.1 s

Concurrency at SLO (TTFT < 2 s przy 16k kontekście): ~20–28 sesji.

Komentarz: dla RAG z długim kontekstem (15k–30k tokenów wejścia, typowe dla dokumentacji technicznej) H200 to często lepsza decyzja niż 4x H100. Mniej kart do utrzymania, mniej networking overhead. Cena listowa H200 to ~30–35% więcej niż H100 na dzień maja 2026.

Kwantyzacja: co zmienia FP8 i INT4

Kwantyzacja redukuje rozmiar wag (i czasem aktywacji) z 16 bitów do 8 lub 4. Daje to dwie rzeczy: mniej VRAM (czyli większy batch albo dłuższy kontekst) i wyższy throughput (mniej danych przez pamięć).

FP8 (NVIDIA Hopper native):

• VRAM ~ 50% mniej niż FP16 (Llama 3.1 70B w FP8 mieści się w ~40 GB, czyli na pojedynczej H100 80GB)
• Throughput +30–55% vs FP16 na tym samym sprzęcie
• Utrata jakości na MMLU/HellaSwag ~ 0.5–1.5 pp, w praktyce nieodczuwalna dla RAG i drafting
• Wymaga TensorRT-LLM lub vLLM 0.6+ z FP8 quantization (np. NVIDIA llm-foundry)

INT4 (GPTQ, AWQ, ExLlamaV2):

• VRAM ~ 25% FP16 (~17–20 GB dla 70B)
• Throughput +50–90% vs FP16 (ale TTFT czasem rośnie, bo dekwantyzacja w runtime)
• Utrata jakości na MMLU ~ 2–4 pp, zauważalna w zadaniach reasoning. Dla pure RAG (gdzie model robi extractive summarization z dokumentu) - akceptowalne. Dla long-form generation (instrukcje, oferty) - testować.
• Wymaga AWQ albo GPTQ quantized weights (publicznie dostępne na HuggingFace dla Llama 3.1 70B)

Praktyczna rekomendacja:

• Konfiguracja A (2x H100) w FP8: zwykle wystarcza dla firmy 200–500 FTE.
• Konfiguracja A w INT4: testować jakość przed wdrożeniem, ale jeden serwer może obsłużyć ~30–40 sesji concurrency.
• Konfiguracja B/C: rzadko ma sens kwantyzować, bo VRAM nie jest wąskim gardłem.

Realistyczna utilizacja i koszt per 1M tokenów

Tu jest miejsce, w którym większość business case'ów łamie się.

Założenie typowe: 30% utilizacji dziennej (7 godzin produktywnego ruchu na dzień, 5 dni w tygodniu, czyli ~21% w skali 24/7). Reszta to idle (noc, weekendy), warm standby i headroom na piki.

Dla Konfiguracji A (2x H100 80GB), FP8, średni aggregate throughput ~600 tokenów/s przy realnym mixie batch sizes:

• Dzienna produkcja: 600 tps × 25 200 s = 15.1M tokenów/dzień
• Miesięczna: ~330M tokenów

TCO sprzętu (3 lata): serwer 2x H100 80GB SXM5 + chassis + switching + zasilanie + utrzymanie + amortyzacja licencji ~ 240–290 tys. EUR. Rozkład na 36 miesięcy: ~7.5 tys. EUR/miesiąc. Plus operator (0.2–0.3 FTE w średniej firmie, gdzie zespół IT już jest): ~3 tys. EUR/miesiąc.

Koszt per 1M tokenów output: ~32 EUR (10.5 tys. / 330M × 1M).

Dla porównania: GPT-4o w cenniku publicznym to ~10 USD per 1M output tokenów. Claude Sonnet 4: ~15 USD per 1M. Czyli on-prem jest droższy w cenie jednostkowej dla 330M/miesiąc.

Ale to kompletna mylna oś porównania, jeśli regulacyjna potrzeba istnieje (NIS2, AI Act high-risk, sektor regulowany). On-prem nie konkuruje z chmurowym API na cenie. Konkuruje na profil ryzyka (dane nie wychodzą), kontrolę (model nie zmienia się bez naszej zgody) i przewidywalność (cennik nie skacze z każdą iteracją vendora).

Z drugiej strony: jeśli urośniemy do 1.5–2 mld tokenów/miesiąc (np. dodajemy automatyzację ofertowania dla biura technicznego do service desk), koszt per 1M tokenów spada do ~7–9 EUR. Wtedy on-prem wygrywa ekonomicznie z chmurą również w cenie jednostkowej.

// co tu nie pokrywamCzego tu nie pokrywam

• Multi-node setups (8+ GPU, pipeline parallelism). Dla średniej firmy w pierwszym roku to overkill, w drugim być może. Osobny post.
• Fine-tuning / training overhead. Inference to ~5% kosztu compute w typowym scenariuszu produkcyjnym. Fine-tuning robimy raz na kwartał, training raczej nie robimy w ogóle.
• Networking i storage sizing dla RAG. KV cache i embeddingi to osobny temat z osobnymi wąskimi gardłami. Też osobny post.
• AMD MI300X i alternatywy non-NVIDIA. Krótko: rozsądne dla pojedynczych workloadów, niedojrzałe dla mixed inference w produkcji średniej firmy. W roku 2027 być może warto wrócić.

// disclosure i biasesDisclosure i biases

Pracuję nad on-prem AI platformą (CortexMine) dla europejskich producentów. Liczby w tym poście pochodzą z publicznych benchmarków (vLLM, NVIDIA Triton, Anyscale, Together AI) i z naszych wewnętrznych testów na sprzęcie testowym. Tam, gdzie nasze wyniki różniły się od publicznych benchmarków o więcej niż 15%, zostawiałem wartości publiczne (są bardziej reprezentatywne dla typowego setupu, niż nasza optymalizacja).

Stronniczość, której świadom jestem: piszę z perspektywy "on-prem jest realnym wyborem". Dla firm bez konkretnej potrzeby regulacyjnej i poniżej 200 FTE - to często nie jest realnym wyborem ekonomicznie. To inna rozmowa.

Powiązane notatki

• Pillar: AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny — szerszy kontekst architektoniczny i 7 warstw deploymentu.
• Cluster: Trzy modele deploymentu on-prem AI: koszty, profil ryzyka, kiedy który — gdzie sprzęt z tego posta wpina się w model deploymentu.