Hardware pentru AI: cum alegi serverul și GPU-ul și cum evaluezi încărcarea

Cea mai frecventă greșeală pe care o văd la primul server „de AI” nu este alegerea unei plăci video prea slabe. Este alegerea unei plăci video înainte de a ști ce va rula pe ea.

Un server care servește un model de 8 miliarde de parametri pentru 20 de utilizatori interni are nevoie de cu totul altceva decât unul care face fine-tuning o dată pe săptămână, sau decât unul care indexează documente pentru un sistem RAG. Toate trei se numesc „server de AI” în cererea de ofertă. Hardware-ul potrivit diferă cu un ordin de mărime la preț.

Articolul acesta este ghidul pe care aș fi vrut să-l am la prima configurație: ce contează cu adevărat la hardware-ul pentru inferență și antrenare, cum arată patru configurații realiste de la workstation la server dens, la ce să fii atent când alegi și, mai ales, cum estimezi și cum măsori încărcarea înainte să dai comanda.

Trei tipuri de încărcare, trei profile de hardware

Înainte de orice specificație, încadrează ce vei rula în una dintre categoriile de mai jos. Fiecare are un alt „gât de sticlă”.

1. Inferență LLM (chat, asistenți, generare de text)

Modelul este încărcat o dată în memoria GPU și răspunde la cereri. Faza de generare a fiecărui token este limitată de lățimea de bandă a memoriei video, nu de puterea de calcul. Practic, la fiecare token GPU-ul citește toate ponderile modelului din VRAM. Un GPU cu 1,8 TB/s generează cam de două ori mai repede decât unul cu 0,9 TB/s pentru același model, chiar dacă au același număr de nuclee.

Ce contează, în ordine: capacitatea VRAM (modelul trebuie să încapă cu tot cu contextul utilizatorilor), lățimea de bandă VRAM, apoi puterea de calcul pentru faza de prefill (procesarea promptului).

2. Embeddings, RAG, clasificare, vision în batch

Modele mici (sute de milioane până la câteva miliarde de parametri), rulate pe volume mari de documente sau imagini. Aici GPU-ul este de obicei subutilizat dacă restul sistemului nu ține pasul: CPU-ul pentru parsing și tokenizare, NVMe-ul pentru citirea corpusului, RAM-ul pentru baza de date vectorială. Un GPU de 20 GB cu un CPU bun și storage rapid bate un GPU de 48 GB pus lângă un procesor de 8 nuclee.

3. Fine-tuning și antrenare

Singurul caz în care puterea brută de calcul (TFLOPS în FP16/BF16/FP8) devine factorul principal. Consumul de VRAM este de 3 până la 8 ori mai mare decât la inferență pentru același model, pentru că pe lângă ponderi stochezi gradienți, stările optimizatorului și activările. Fine-tuning cu LoRA/QLoRA reduce dramatic această cerință și face posibil antrenamentul unui model de 8B pe un singur GPU de 24 până la 48 GB.

Dacă antrenezi modele mari pe mai multe GPU-uri, interconectul dintre ele (NVLink sau PCIe) intră în ecuație. Pentru inferență și fine-tuning pe un singur GPU, nu.

Ce contează cu adevărat la GPU

VRAM: prima cifră pe care o verifici

Regula rapidă pentru memoria ocupată de ponderi:

VRAM ponderi ≈ parametri × bytes/parametru

FP16 / BF16 : 2 bytes     →  8B  = 16 GB     70B = 140 GB
INT8 / FP8  : 1 byte      →  8B  =  8 GB     70B =  70 GB
INT4 (Q4)   : ~0,55 bytes →  8B  ≈ 4,5 GB    70B ≈ 40 GB

La asta se adaugă cache-ul KV, adică memoria pe care fiecare conversație activă o ocupă pentru contextul ei. Este partea pe care majoritatea o uită și motivul pentru care un model care „încape” pe hârtie nu mai încape cu 10 utilizatori simultani. Calculul este mai jos, la secțiunea despre evaluarea încărcării.

Concret: un model de 8B în FP16 rulează confortabil pe 24 GB. Un model de 70B cuantizat la 4 biți are nevoie de minimum 48 GB, iar 96 GB îi dau spațiu pentru context și utilizatori. Un model de 70B în FP16 nu încape pe niciun GPU cu un singur slot din categoria aceasta și cere două sau mai multe plăci.

Lățimea de bandă a memoriei

Pentru inferență este a doua cifră ca importanță și cea mai ignorată din fișele tehnice. O estimare grosieră pentru viteza de generare la un singur utilizator:

tokeni/s (1 utilizator) ≈ lățime de bandă VRAM / dimensiune model în VRAM

RTX 4000 Ada   360 GB/s  ÷ 16 GB (8B FP16)  ≈ 22 tok/s
RTX 6000 Ada   960 GB/s  ÷ 16 GB            ≈ 60 tok/s
RTX PRO 6000  1792 GB/s  ÷ 16 GB            ≈ 110 tok/s

Cifrele reale sunt cu 20 până la 40% mai mici din cauza overhead-ului, dar proporțiile se păstrează. Cu mai mulți utilizatori în paralel (batching), throughput-ul total crește mult peste aceste valori, pentru că ponderile se citesc o singură dată pentru întregul batch.

ECC și ediția „server” a plăcii

Plăcile din familia RTX PRO și RTX Ada au memorie ECC, driver-e certificate și, important pentru rack, versiuni cu răcire pasivă care se bazează pe ventilatoarele serverului. O Server Edition pasivă precum RTX PRO 4500 Blackwell Server Edition este proiectată să stea într-un șasiu 2U cu flux de aer front-to-back. O placă GeForce cu trei ventilatoare axiale nu este, și într-un server de 2U se va supraîncălzi sau va bloca sloturile vecine.

Consumul și numărul de sloturi

Diferența dintre 130 W și 600 W pe placă nu este doar factura de curent. Este sursa serverului, alimentarea din rack și cât aer trebuie mișcat. Ordinul de mărime pentru plăcile discutate aici:

GPU	VRAM	Bandă memorie	TDP	Sloturi	Potrivit pentru
RTX 4000 Ada	20 GB GDDR6 ECC	360 GB/s	130 W	1	embeddings, RAG, modele ≤ 8B Q4, vision
RTX 5000 Ada	32 GB GDDR6 ECC	576 GB/s	250 W	2	8B FP16 multi-user, 14B–32B cuantizate
RTX PRO 4500 Blackwell SE	32 GB GDDR7 ECC	896 GB/s	200 W	1, pasiv	inferență densă în rack, 2–8 plăci pe server
RTX 6000 Ada	48 GB GDDR6 ECC	960 GB/s	300 W	2	70B Q4 pe o placă, fine-tuning LoRA
RTX PRO 6000 Blackwell	96 GB GDDR7 ECC	1.792 GB/s	600 W	2	70B Q8, 100B+ Q4, antrenare serioasă
GeForce RTX 5080	16 GB GDDR7	960 GB/s	360 W	3	doar dezvoltare/test, fără ECC, nu pentru rack

Observația importantă din tabel: RTX PRO 4500 Blackwell are aproape aceeași bandă de memorie ca RTX 6000 Ada, la două treimi din consum și într-un singur slot. Pentru inferență pe modele mici și medii, patru astfel de plăci într-un 2U dau mai mult throughput agregat decât două RTX 6000 Ada. Pentru un model de 70B, însă, contează cei 48 sau 96 GB pe o singură placă.

Ce contează la restul serverului

GPU-ul ia toată atenția, dar de trei ori din patru problemele pe care le-am întâlnit la configurații „de AI” au fost în jurul lui, nu în el.

• Linii PCIe. Fiecare GPU vrea x16. Un procesor desktop are 20 până la 24 de linii, deci a doua placă rulează pe x8 sau x4, iar NVMe-urile concurează cu ea. Xeon Scalable și EPYC oferă 80 până la 128 de linii pe socket. Pentru mai mult de un GPU, platforma server nu este un moft.
• Sursa. Regula: suma TDP-urilor GPU + CPU + 150 W, apoi ×1,3 pentru vârfuri tranzitorii, care la plăcile Blackwell sunt reale. Două RTX PRO 6000 (1.200 W) plus un EPYC (300 W) cer o pereche de surse de minimum 2.000 W. ASUS ESC4000A-E11 vine cu 2 × 2.200 W tocmai pentru acest scenariu.
• Răcirea și adâncimea de rack. Plăcile de 600 W pasive cer un șasiu proiectat pentru GPU, cu ventilatoare de mare presiune statică. Un server 1U standard nu este candidat pentru mai mult de o placă single-slot de 130 până la 200 W.
• RAM de sistem. Minimum cât suma VRAM-ului, ideal dublul, cu RDIMM ECC. Modelul se încarcă prin RAM, iar la RAG baza de date vectorială și cache-ul de documente trăiesc acolo. Un modul Kingston 64 GB DDR5 ECC Registered este unitatea de bază la Gen11/Gen12; populează toate canalele, nu doar două sloturi cu module mari.
• Storage NVMe. Încărcarea unui model de 70B de pe SATA durează minute; de pe un Samsung PM9A3 durează secunde. Pentru dataset-uri de antrenare sau corpusuri RAG mari, un PM1743 PCIe 5.0 evită ca GPU-ul să stea după disc. Despre de ce contează latența și sustained write la SSD-uri de server am scris într-un articol separat.
• Rețea. 1 GbE se saturează instant dacă serverul servește embeddings sau răspunsuri către o aplicație cu trafic. Un adaptor Intel E810 dual 25 GbE este ieftin față de restul configurației și elimină problema.
• CPU: nuclee, nu frecvență. Pentru inferență GPU, procesorul face tokenizare, scheduling și pre/post-procesare. 16 nuclee sunt suficiente pentru două GPU-uri. Pentru RAG și ingestie de documente, 32 de nuclee se amortizează repede.

Patru configurații comparate

Prețurile se schimbă, deci nu le pun aici. Ordinea de mărime este de 1× pentru workstation, 2 până la 3× pentru serverul 2U cu două plăci, 5 până la 8× pentru serverul dens.

	A. Workstation	B. Server 2U, 1–2 GPU	C. Server 2U dens, 4–8 GPU	D. Server CPU + GPU mic
Bază	Dell Pro Max T2, RTX 5090, 128 GB	HPE DL385 Gen11, EPYC 9115 sau Dell PowerEdge R760xs	ASUS ESC4000A-E11, 2 × 2.200 W	HPE DL380 Gen11, 128 GB
GPU	1 × RTX 5090 32 GB (sau RTX 5000 Ada / RTX PRO 6000)	1–2 × RTX 6000 Ada 48 GB sau RTX PRO 6000 96 GB	4–8 × RTX PRO 4500 SE 32 GB pasiv	1 × RTX 4000 Ada 20 GB
VRAM total	32–96 GB	48–192 GB	128–256 GB	20 GB
Model tipic	8B–14B FP16, 32B Q4, 70B Q4 pe PRO 6000	70B Q4/Q8, 2 modele în paralel	modele ≤ 32B, replicate pe fiecare GPU	embeddings, rerankers, 8B Q4
Utilizatori simultani	1–5	10–50	50–200+	zeci de cereri scurte/s
Punct forte	ieftin, silențios, lângă dezvoltator	un singur model mare, ECC, redundanță PSU, iDRAC/iLO	throughput agregat maxim la inferență	RAG, ingestie, CPU pentru aplicație
Limită	fără ECC pe 5090, fără management, un singur GPU real	2 plăci de 600 W cer șasiu dedicat	niciun model nu poate depăși 32 GB fără split	nu scalează la LLM-uri mari

Cum aleg între ele:

• A dacă echipa are sub 5 oameni și testează. Un Dell Pro Max T2 cu RTX 5090 este cea mai rapidă cale de la zero la un LLM local. Când proiectul devine serviciu pentru toată firma, mutarea la B este naturală.
• B dacă ai un caz de utilizare clar cu un model mare. Este configurația pe care o recomand cel mai des: DL385 Gen11 pe EPYC pentru liniile PCIe, două RTX 6000 Ada sau o RTX PRO 6000 de 96 GB dacă modelul de 70B trebuie să ruleze la Q8.
• C dacă ai mulți utilizatori pe modele mici sau medii, sau mai multe modele diferite (chat, cod, vision) servite simultan. Fiecare GPU rulează propria instanță și un load balancer distribuie cererile.
• D dacă „AI” înseamnă căutare semantică peste documente. Bugetul merge în CPU, RAM și NVMe, iar GPU-ul de 130 W face embeddings de sute de ori mai rapid decât CPU-ul fără a cere nimic special de la șasiu.

Cum evaluezi încărcarea înainte de achiziție

Aceasta este partea care lipsește din majoritatea cererilor de ofertă. Cinci pași.

Pasul 1: dimensionează VRAM-ul cu cache-ul KV inclus

Pentru fiecare token din contextul fiecărei conversații active, modelul ține în VRAM cheile și valorile din toate straturile:

KV/token = 2 × straturi × capete_KV × dim_cap × bytes

Llama 3 8B  (32 straturi, 8 capete KV, 128 dim, FP16):
  2 × 32 × 8 × 128 × 2 = 131.072 bytes ≈ 128 KB / token

10 utilizatori × 8.000 tokeni context = 80.000 tokeni
  80.000 × 128 KB ≈ 10 GB de cache KV

Total: 16 GB ponderi + 10 GB KV + ~2 GB overhead = 28 GB

Deci modelul de 8B „care încape pe 24 GB” nu mai încape cu 10 utilizatori și context lung. Are nevoie de 32 GB, sau de cache KV cuantizat la FP8, sau de limitarea contextului. Fă calculul acesta pentru modelul, numărul de utilizatori și lungimea de context pe care le aștepți realist, apoi adaugă 20%.

Pasul 2: definește ținta de latență și throughput

Două metrici contează pentru utilizatori:

• Time to first token (TTFT): cât așteaptă până apare primul cuvânt. Sub 1 secundă pare instant, peste 3 secunde pare stricat. Depinde de prefill, deci de puterea de calcul și de lungimea promptului.
• Tokeni pe secundă per utilizator: peste 20 tok/s este mai rapid decât citește omul; sub 8 tok/s frustrează. Depinde de banda de memorie și de câți utilizatori împart GPU-ul.

Pentru un serviciu intern, o țintă rezonabilă este: 20 de utilizatori concurenți, TTFT sub 1,5 s la prompturi de 2.000 de tokeni, minimum 15 tok/s fiecare. Din asta rezultă că serverul trebuie să susțină 300 tok/s agregat. O RTX 6000 Ada cu un 8B FP16 sub vLLM face 800 până la 1.500 tok/s agregat în batching; un 70B Q4 pe aceeași placă face 150 până la 250. Prima variantă are loc de creștere, a doua este la limită.

Pasul 3: măsoară, nu estima, pe hardware similar

Înainte de comandă, rulează modelul țintă pe orice GPU ai la îndemână și măsoară cu un benchmark de servire, nu cu un chat manual. Cu vLLM:

vllm serve meta-llama/Llama-3.1-8B-Instruct --max-model-len 8192

python benchmarks/benchmark_serving.py \
  --backend vllm --model meta-llama/Llama-3.1-8B-Instruct \
  --dataset-name sharegpt --num-prompts 200 \
  --request-rate 4        # cereri/secundă, crește până cedează TTFT

Raportul îți dă TTFT median și p99, tokeni/s per cerere și throughput total. Repetă cu request-rate crescător până când p99 TTFT depășește ținta. Acela este numărul real de utilizatori pe care îi duce placa. Scalează apoi liniar cu banda de memorie a plăcii pe care vrei să o cumperi: un GPU cu bandă dublă va duce aproximativ dublu.

Pasul 4: urmărește metricile corecte în producție

Utilizarea GPU raportată de nvidia-smi este înșelătoare: arată 100% și când un singur utilizator ocupă placa la 10% din capacitatea reală. Ce contează:

nvidia-smi dmon -s pucm
# pwr  = consum real (dacă stă la 40% din TDP, ești limitat de altceva)
# mem  = utilizare bandă memorie (ținta la inferență: >70%)
# sm   = utilizare nuclee (ținta la antrenare: >80%)

# per-proces, VRAM alocat vs. total
nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 5

Pentru monitorizare continuă, exportatorul DCGM pentru Prometheus expune aceleași metrici plus temperatura, throttling-ul și erorile ECC. Semnale de alarmă:

• SM peste 90%, bandă memorie sub 40% la inferență: probabil prefill dominat de prompturi lungi; ajută cache-ul de prefix sau un GPU cu mai mult calcul.
• Bandă memorie peste 85% constant: placa este saturată; următorul pas este a doua placă sau un model cuantizat.
• VRAM la 95% cu cereri în coadă: cache-ul KV nu mai încape; vLLM va face preemption și latența explodează. Aici ai greșit la Pasul 1.
• Consum sub 50% din TDP la încărcare mare: GPU-ul așteaptă după CPU, disc sau rețea.
• Clocks throttled cu temperatura peste 83°C: problema de răcire de care vorbeam la secțiunea despre ediția server.

Pasul 5: planifică pentru dublul încărcării

Toate proiectele de AI interne pe care le-am văzut au crescut mai repede decât estimarea. Dacă ai calculat 20 de utilizatori, alege configurația care duce 40, sau una în care a doua placă se adaugă fără a schimba serverul. Este argumentul principal pentru un șasiu 2U cu sloturi și sursă supradimensionate față de un workstation plin de la început.

Lista scurtă de verificare

1. Ce rulezi: inferență LLM, embeddings/RAG sau antrenare? Fiecare are alt gât de sticlă.
2. VRAM = ponderi + cache KV pentru utilizatorii și contextul real + 20%.
3. Bandă de memorie, nu TFLOPS, pentru viteza de generare.
4. ECC și ediție pasivă dacă merge în rack; consumer doar pentru dezvoltare.
5. Linii PCIe x16 per GPU: platformă EPYC sau Xeon pentru mai mult de o placă.
6. Sursă: (GPU + CPU + 150 W) × 1,3, redundantă.
7. RAM ECC cel puțin cât VRAM-ul total, toate canalele populate.
8. NVMe enterprise pentru modele și dataset-uri, 25 GbE dacă servește o aplicație.
9. Benchmark de servire pe hardware existent înainte de comandă, apoi scalare după bandă de memorie.
10. Configurație care duce dublul încărcării estimate.

Dacă ai deja o încărcare măsurată sau un model țintă și vrei o configurație dimensionată pe ea, trimite-ne cererea cu modelul, numărul de utilizatori și lungimea de context. Cu aceste trei cifre, jumătate din munca de dimensionare este deja făcută.