Preluate din ceea ce ne întreabă oamenii efectiv pe chat și în tichete, aproximativ în ordinea în care le adresează. Primele trei sunt cele care decid dacă o achiziție funcționează.
- Câtă memorie GPU necesită un model de limbaj de mari dimensiuni?
- Greutățile reprezintă numărul de parametri înmulțit cu octeții per parametru: doi octeți fiecare la 16 biți, unul la 8 biți, jumătate la 4 biți. Un model de 7–8 miliarde de parametri înseamnă 16 GB de greutăți la 16 biți, 8 GB la 8 biți și 5 GB la 4 biți; un model de 70 de miliarde de parametri înseamnă 140 GB, 70 GB și 38 GB. Aceste cifre reprezintă doar greutățile și sunt un prag minim, nu o cerință — bugetați în plus un sfert până la jumătate pentru runtime, activări și cache-ul cheie-valoare.
- Ce îmi trebuie pentru a rula un model de 70B precum Llama 3.3?
- La 4 biți greutățile sunt de aproximativ 38 GB, deci cu spațiu de manevră pentru servire răspunsul este o placă de 64 GB sau mai mult — o singură placă, o singură mașină. La 8 biți greutățile sunt de 70 GB, iar o placă de 80 GB depășește pragul. La precizie completă de 16 biți nicio placă pe care o instalăm nu îl poate susține, devenind o configurație multi-placă pe care o cotăm. Fig. 3 de mai sus numește plăcile exacte; prețurile sunt pe servere dedicate GPU.
- De ce modelul meu se încarcă, dar nu reușește să servească?
- Pentru că greutățile nu sunt singurul lucru din memoria plăcii. Runtime-ul și bufferele sale sunt rezidente, iar fiecare token dintr-o conversație lasă o intrare în cache-ul cheie-valoare, astfel încât să nu fie nevoie să fie recalculat. Acel cache crește odată cu lungimea contextului și din nou cu fiecare cerere servită simultan, deci un model ale cărui greutăți abia încap va susține aproximativ o singură conversație scurtă. Dimensionați placa la o dată și un sfert până la o dată și jumătate din greutăți.
- Ce runtime de inferență pot instala?
- Oricare dintre ele. Mașina sosește cu un sistem de operare curat și acces root, iar în fața sa nu există niciun serviciu de inferență al furnizorului. vLLM este răspunsul obișnuit pentru servirea traficului real, deoarece procesarea în loturi continue permite unei singure plăci să răspundă la mai multe cereri simultan. llama.cpp este răspunsul obișnuit când memoria este limitată sau placa este mai veche. TGI și SGLang rulează nemodificate. Ollama este cea mai scurtă cale de la o mașină goală la un model care răspunde pe un port — iar vLLM și Ollama răspund ambele pe un endpoint compatibil OpenAI, astfel încât codul client existent indică spre propria mașină prin schimbarea unui singur URL de bază. Fixați driverul, versiunea CUDA sau ROCm și framework-ul la versiunile pe care a fost testat codul dumneavoastră.
- Este auto-găzduirea unui LLM mai ieftină decât un API per token?
- Depinde în întregime de volum, iar punctul de intersecție este real: un API facturează per token și nu costă nimic când este inactiv; o mașină dedicată are o sumă lunară fixă și nu costă nimic în plus când este ocupată. Traficul constant, agenții care rulează toată ziua, pipeline-urile batch și orice cu cerințe de confidențialitate tind să iasă în avantaj pe hardware propriu; o sarcină de lucru care se declanșează de zece ori pe zi nu. Cifrele lunare pentru a face acest calcul sunt pe servere dedicate GPU — această fișă în mod deliberat nu afișează prețuri.
- Câți tokeni pe secundă voi obține?
- Nu publicăm o cifră de tokeni pe secundă, deoarece fiecare astfel de număr depinde de model, cuantizare, runtime și versiunea sa, dimensiunea lotului, lungimea promptului, lungimea răspunsului și concurență, iar schimbarea oricăruia îl modifică de un multiplu. Ce îl guvernează: citirea promptului este limitată de calcul și are loc o dată per cerere; generarea răspunsului este limitată de lățimea de bandă a memoriei, deoarece fiecare token necesită citirea greutăților; iar procesarea în loturi amortizează acea citire pe cererile concurente, ceea ce face servirea economică până când cache-ul cheie-valoare rămâne fără spațiu. Întrebați cu modelul, cuantizarea și concurența așteptată pentru un răspuns bazat pe ceea ce am observat efectiv.
- Este GPU-ul partajat cu altcineva?
- Nu. Un singur chiriaș per mașină fizică, iar placa este pasată direct către propriul sistem de operare. Nu există hypervisor, partiție MIG, profil vGPU sau planificator de time-slicing, deci nimic altceva nu rulează pe placă, iar latența de inferență nu se modifică din cauza jobului batch al altcuiva.
- Ce se întâmplă dacă modelul nu încape pe o singură placă?
- Atunci este o configurație multi-placă, care se cotează, nu se comandă dintr-un checkout: câte plăci încap depinde de lățimea fizică a plăcii specifice și de bugetul de putere al șasiului. Două plăci oferă suma memoriei lor doar dacă runtime-ul poate împărți modelul pe ambele, ceea ce orice runtime serios suportă cu un anumit cost de debit. Mai mult de o placă sau mașină acoperă cum arată acea configurație.
- Fine-tuning-ul necesită mai multă memorie decât servirea?
- Considerabil mai multă. Servirea necesită greutățile; antrenarea necesită greutățile, gradienții și starea optimizatorului pentru fiecare parametru actualizat, toate rezidente simultan, plus activările păstrate pentru pasul înapoi. Un model care se servește confortabil pe o singură placă poate fi de câteva ori prea mare pentru a fi complet fine-tuned pe aceasta. Metodele eficiente în parametri actualizează o fracțiune mică din parametri și necesită o fracțiune corespunzător de mică din memoria suplimentară, motiv pentru care majoritatea fine-tuning-ului de aici folosește una.
- Pot rula o placă AMD și funcționează ROCm?
- Da. Componentele AMD Instinct sunt printre plăcile cu cea mai mare memorie pe care le instalăm și sunt frecvent cea mai bună valoare per gigabyte, dar stiva dumneavoastră trebuie să suporte ROCm, nu CUDA. Majoritatea runtime-urilor actuale de inferență o fac; unele instrumente adiacente încă nu. Întrebați înainte de a comanda și vom verifica în raport cu runtime-ul dumneavoastră specific, nu vom răspunde în general.