Krótka odpowiedź: do lokalnego LLM w kwantyzacji (GGUF, Ollama/llama.cpp) wybierz Tesla P40 24GB — więcej VRAM, większe modele, spokój na kontekst. Tesla P100 16GB bierz świadomie tylko wtedy, gdy naprawdę zależy Ci na szybkim FP16 (2:1) i wysokim paśmie HBM2 albo na mocnym FP64 do obliczeń naukowych — kosztem 8 GB mniej pamięci i braku niskich stanów oszczędzania. P100 nie ma niskich power states jak P40, więc na idle trzyma podwyższone zegary i pobiera rzędu ~30 W (zamiast ~10 W jak P40) — to nie jest 250 W (to TDP pod obciążeniem). I najważniejsze, co ludzie mylą: P40 ma bardzo słaby FP16 (rzędu 1/64 FP32), więc natywne FP16 i ExLlama chodzą na niej fatalnie — na P40 trzymaj się kwantyzacji. Na P100 jest odwrotnie: FP16 jest jej mocną stroną.
Piszę to, bo te dwie karty są notorycznie mylone — obie „Pascal", obie „stara Tesla 16/24 GB", obie tanie. A różnią się w miejscu, które decyduje o tym, czy Twój model w ogóle sensownie ruszy. Uczciwie: tak, sprzedajemy obie (pełne zastrzeżenie na końcu). Właśnie dlatego zależy mi, żebyś kupił tę właściwą, a nie zwracał niewłaściwą.
Skąd bierze się cała pomyłka
Obie karty to architektura Pascal, ale to dwa różne układy pod maską. P40 zbudowano jako akcelerator inferencji na rdzeniu graficznym GP102 (tym samym, co w GeForce GTX 1080 Ti / Titan X tamtej generacji), ale bez wyjść obrazu — to karta serwerowa, nie podłączysz do niej monitora, z pamięcią GDDR5 24 GB. P100 to układ czysto obliczeniowy (HPC), z pamięcią HBM2 16 GB i — to klucz — pełnoprawnym, szybkim FP16 oraz FP64.
I tu jest sedno mylenia: ludzie zakładają, że „nowsza/droższa/HBM2 = lepsza do LLM". Nieprawda w ogólności. Do inferencji w kwantyzacji liczy się przede wszystkim ilość VRAM (żeby model się zmieścił), a typowy stos GGUF nie obciąża najsłabszej ścieżki P40 (natywnego FP16) — a tu 24 GB P40 wygrywa użytecznością. Szybki FP16 P100 pomaga tylko wtedy, gdy faktycznie liczysz w FP16 — a przy GGUF zwykle nie liczysz.
Pułapka FP16 na P40 — najważniejszy akapit
P40 ma celowo okrojony FP16 — przepustowość FP16 jest u niej rzędu 1/64 wydajności FP32. To nie usterka, to decyzja projektowa Pascala w tym konkretnym układzie. Praktyczne konsekwencje:
- Natywne modele FP16 (bez kwantyzacji) chodzą na P40 bardzo wolno. To nie „trochę wolniej" — to różnica rzędów wielkości w tej ścieżce.
- ExLlama / ExLlamaV2 i podobne backendy liczące w FP16 na P40 rozczarują. Nie dlatego, że karta jest zła — dlatego, że używasz jej najsłabszej ścieżki.
- Rozwiązanie: jeśli bierzesz P40 przede wszystkim do lokalnych LLM, trzymaj się GGUF/kwantyzacji przez llama.cpp/Ollama. W typowym zastosowaniu GGUF słaby FP16 P40 nie jest głównym ograniczeniem, bo stos wykorzystuje ścieżki zoptymalizowane pod kwantyzację (dokładne zachowanie zależy od backendu, kwantyzacji, kerneli i wersji oprogramowania) — i P40 pokazuje wtedy swoją prawdziwą wartość: 24 GB taniej pamięci pod duży model.
Odwrotnie na P100: FP16 jest 2:1 (dwa razy szybszy niż FP32), więc karta radzi sobie tam, gdzie P40 się dławi. Ale — i to trzeba powiedzieć wprost — żadna z tych kart nie ma Tensor Cores. Tensor Cores to dopiero Volta (V100) i nowsze. Więc jeśli marzą Ci się przyspieszenia „tensorowe", ani P40, ani P100 ich nie dadzą; po to jest V100 32GB.
VRAM vs pasmo — co naprawdę limituje przy inferencji
Warto rozdzielić dwie rzeczy, które łatwo pomylić: ilość VRAM decyduje o tym, czy model w ogóle się zmieści, a pasmo pamięci wpływa na to, jak szybko generuje tokeny (inferencja LLM jest w dużej mierze ograniczona przepustowością pamięci, nie mocą obliczeniową). Na papierze HBM2 w P100 ma wyższe pasmo niż GDDR5 w P40 — i to jest realny atut P100, gdy model mieści się w jej 16 GB.
Problem w tym, że w praktyce najpierw musisz się zmieścić. Jeśli Twój model plus kontekst zajmują 18–20 GB, na P100 (16 GB) w ogóle go nie uruchomisz na jednej karcie — i całe teoretyczne pasmo HBM2 nic Ci nie da, bo część modelu wyleciałaby na CPU (co zabija wydajność). Na P40 z 24 GB ten sam model wejdzie z zapasem. Dlatego dla dużych modeli i długiego kontekstu przewaga pojemności P40 bije przewagę pasma P100 — po prostu dlatego, że „mieści się" wygrywa z „byłoby szybciej, gdyby się mieściło".
Pamiętaj też o KV cache: im dłuższy kontekst, tym większy bufor pamięci na historię rozmowy — potrafi dołożyć kilka GB. To kolejny argument za 24 GB, jeśli planujesz długie prompty albo większy batch.
Power states — cichy minus P100
Rzecz, o której cenniki milczą, a w praktyce ma znaczenie: P100 nie ma niskich stanów oszczędzania jak P40 — na idle trzyma podwyższone zegary i pobiera rzędu ~30 W (zamiast ~10 W jak P40). To nie jest 250 W (to TDP pod obciążeniem), ale i tak wyraźnie więcej niż P40 na bezczynności. (Nasz burn-in: P100 idle śr. ~29 W; P40 schodzi do ~8–10 W przy zarządzaniu stanami pstate — średnia całej próbki bywa wyższa, bo część kart pracowała bez tego zarządzania.) Dla stale obciążonego serwera obliczeniowego to nieistotne (i tak liczy pełną parą). Ale dla domowego serwerka, który przez większość doby czeka na sporadyczne zapytanie, to realny koszt prądu i ciepła. P40 pod tym względem zachowuje się grzeczniej.
Do tego oba modele są pasywne — bez wymuszonego przepływu powietrza się zdławią. Jak schłodzić taką kartę w desktopie, rozpisałem osobno w poradniku o chłodzeniu pasywnych kart serwerowych.
Tabela — P40 vs P100 tam, gdzie to boli
| Cecha | Tesla P40 24GB | Tesla P100 16GB |
|---|---|---|
| Architektura | Pascal | Pascal |
| VRAM | 24 GB GDDR5 | 16 GB HBM2 |
| Pasmo pamięci | niższe (GDDR5) | wyższe (HBM2) |
| FP16 | bardzo słabe (~1/64 FP32) | szybkie (2:1) |
| FP32 | dobre | dobre |
| FP64 | słabe | mocne (atut w nauce) |
| Tensor Cores | brak | brak |
| Power states / idle | niskie (~10 W idle) | brak niskich stanów — podwyższone zegary, ~30 W idle |
| Najlepsze do | duże modele w GGUF, inferencja | szybki FP16, HPC/FP64, mniejszy model |
| Pułapka | nie licz w natywnym FP16/ExLlama | tylko 16 GB — większy model się nie zmieści |
Nasz pomiar head-to-head (plik Bielik-11B-v2.3-Instruct-Q4_K_M.gguf, llama-bench -ngl 99 -p 512/2048 -n 128 -r 3 = średnia z 3 przebiegów; pełny power limit 250 W. Stanowisko: 2× Xeon E5-2697 v3 (24 rdzenie), 19 GB RAM, Ubuntu 24.04, sterownik 580.173.02 / CUDA 12.0, PCIe Gen3; surowe CSV i log builda llama.cpp dostępne na życzenie). Wszystkie wyniki poniżej w tok/s (wyżej = lepiej):
| Karta | Prompt eval pp512 | Prompt eval pp2048 | Generacja tg128 |
|---|---|---|---|
| P40 24GB | 593,6 | 550,8 | 28,5 |
| P100 16GB | 419,0 | 402,1 | 27,2 |
Ciekawostka, która potwierdza tezę tego wpisu: mimo szybszej pamięci HBM2 P100 ma NIŻSZY prompt eval niż P40 (mniej rdzeni CUDA — układ obliczeniowy GP100 vs graficzny GP102), a generacja praktycznie równa. Bez Tensor Cores przewaga pasma HBM2 nie przekłada się na wynik w GGUF — a P40 dokłada do tego 8 GB VRAM więcej. Wyniki na innym modelu, kwantyzacji i długości kontekstu będą inne; ten pomiar pokazuje zachowanie obu kart w identycznym środowisku testowym.
Werdykt — którą kartę i kiedy
Wybierz Tesla P40 24GB, jeśli:
- Robisz lokalny LLM w kwantyzacji (Bielik, Llama, PLLuM przez Ollama/llama.cpp) — to najczęstszy scenariusz.
- Zależy Ci na jak największym modelu na jednej karcie albo na długim kontekście — 24 GB daje realny zapas, którego 16 GB nie ma.
- Chcesz najlepszy stosunek GB VRAM do ceny i grzeczniejsze zachowanie na idle.
- Akceptujesz jeden warunek: trzymasz się GGUF, a nie natywnego FP16.
Wybierz Tesla P100 16GB, jeśli:
- Naprawdę potrzebujesz szybkiego FP16 (konkretny workflow liczący w połowicznej precyzji) albo wysokiego pasma pamięci przy modelu, który mieści się w 16 GB.
- Liczysz FP64 — symulacje, obliczenia naukowe, gdzie podwójna precyzja to Twój chleb. Tu P100 świeci najjaśniej i bije P40 bezdyskusyjnie.
- Godzisz się na mniej VRAM i wyższy pobór na idle.
A jeśli chcesz Tensor Cores albo więcej mocy niż oba → to już V100 32GB — Volta, HBM2, Tensor Cores i 32 GB pod większy model z długim kontekstem. O tym, jak wybierać kartę stricte pod inferencję LLM, napisałem osobno w jaka karta do inferencji LLM, a praktyczny setup P40 pod domowy model pokazuję w Tesla P40 do Ollama.
Źródła
- NVIDIA Tesla P40 — dane techniczne (GDDR5 24 GB, FP16 1/64 FP32): https://images.nvidia.com/content/pdf/tesla/184427-Tesla-P40-Datasheet-NV-Final-Letter-Web.pdf
- NVIDIA Tesla P100 — dane techniczne (HBM2 16 GB): https://images.nvidia.com/content/tesla/pdf/nvidia-tesla-p100-PCIe-datasheet.pdf
- NVIDIA Pascal Architecture Whitepaper — źródło pierwotne dla P100/GP100: FP16 2:1 (podwójna przepustowość) oraz jednostki FP64: https://images.nvidia.com/content/pdf/tesla/whitepaper/pascal-architecture-whitepaper.pdf
- Pobór na idle — nasz burn-in (20× P100, 41× P40; monitoring nvidia-smi): P100 idle śr. ~29 W (brak niskich stanów), P40 schodzi do ~8–10 W przy zarządzaniu pstate. To samo zjawisko braku niskich stanów na Teslach DC udokumentowane na Tesli V100 (nvidia-pstated #6): https://github.com/sasha0552/nvidia-pstated/issues/6
- NVIDIA Tesla V100 — dane techniczne (Tensor Cores, Volta): https://images.nvidia.com/content/technologies/volta/pdf/tesla-volta-v100-datasheet-letter-fnl-web.pdf
Zastrzeżenie na koniec, tak jak zawsze: tak, sprzedajemy i P40, i P100 — więc czytaj to z tą świadomością. Ale nie zależy mi, żebyś kupił „którąkolwiek" — zależy mi, żebyś kupił tę właściwą do swojego zadania, bo zwrot niewłaściwej karty to strata czasu dla nas obu. Każdą sztukę testujemy pod obciążeniem i dokładamy certyfikat burn-in (temperatura, pobór, błędy ECC) — przy używkach to różnica między obietnicą a dowodem. Dla orientacji, średnia z maksymalnych temperatur pod pełnym obciążeniem w naszej próbce to ~64 °C (P40) i ~62 °C (P100). Nie wiesz, czy Twój workflow to GGUF (→ P40) czy FP16/FP64 (→ P100)? Napisz do nas i opisz, co chcesz liczyć — pomożemy wybrać, zamiast sprzedać drożej.
(Zobacz też: Jaka karta do inferencji LLM · Tesla P40 do Ollama · Chłodzenie pasywnych kart serwerowych)
FAQ
- Krótko: P40 czy P100 do Ollamy/llama.cpp?
- Do GGUF/kwantyzacji — P40. Więcej VRAM (24 GB), grzeczniejszy idle, a słaby FP16 P40 w tym stosie nie przeszkadza, bo nie opiera się on na natywnym FP16. P100 nie da tu przewagi, a straci 8 GB pamięci.
- Dlaczego mój model FP16 tak wolno chodzi na P40?
- Bo P40 ma FP16 rzędu 1/64 FP32 — to jej najsłabsza ścieżka. Nie używaj natywnego FP16 ani ExLlamy; przejdź na GGUF. To nie usterka karty, tylko zły tryb pracy.
- Czy P100 ma Tensor Cores, skoro ma HBM2?
- Nie. HBM2 to szybka pamięć, ale Tensor Cores to osobna sprawa — pojawiają się dopiero od Volty (V100). Ani P40, ani P100 ich nie mają.
- Mam model, który mieści się w 16 GB i liczę w FP16 — wtedy P100 wygrywa?
- Tak, to jest właśnie scenariusz dla P100: szybki FP16 plus wysokie pasmo HBM2. Jeśli dodatkowo potrzebujesz FP64, wybór jest oczywisty.
- Czemu P100 grzeje i bierze prąd na bezczynności?
- Brak niskich stanów oszczędzania — na idle trzyma podwyższone zegary (~30 W u nas, wobec ~8–10 W floor P40). Dla serwera liczącego 24/7 bez znaczenia; dla sprzętu czekającego na sporadyczne zapytania to realny koszt prądu.
- Ile realnie tokenów na sekundę na każdej?
- U nas na Bieliku-11B Q4_K_M (GGUF, pełny power limit, średnia z 3 przebiegów): P40 — 593,6 tok/s prompt eval, 28,5 tok/s generacja; P100 — 419,0 / 27,2. Czyli P40 szybciej przetwarza prompt i generuje praktycznie tak samo, przy 8 GB VRAM więcej. Twój wynik zależy od wielkości modelu, poziomu kwantyzacji i długości kontekstu — ten pomiar pokazuje jednak zachowanie obu kart w identycznym środowisku.