Cele mai bune GPU-uri Cloud pentru Servirea și Implementarea LLM-urilor

Ce solicită de fapt servirea unui LLM de la un GPU închiriat

Servirea unui model lingvistic mare este o sarcină fundamental diferită față de antrenarea unuia. Antrenarea este limitată de debit și tolerantă la latență; servirea este sensibilă la latență, limitată de memorie și cu trafic fluctuant. Când închiriezi un GPU pentru a implementa un LLM în spatele unui API, blocajul rar este reprezentat de FLOPS brut. Este vorba despre cât din model și din cache-ul KV poți păstra în VRAM, cât de rapid transmite acea memorie și câte cereri concurente poți grupa înainte ca tokenii pe secundă per utilizator să scadă drastic.

Cache-ul KV este partea pe care majoritatea o subestimează. Fiecare cerere activă stochează cheile și valorile atenției pentru contextul său, iar această amprentă crește odată cu lungimea secvenței și numărul de utilizatori concurenți. Un model care încape confortabil în stare inactivă poate rămâne fără memorie în momentul în care începi să primești trafic real cu prompturi lungi. De aceea, implementările de servire au adesea nevoie de mai mult spațiu VRAM decât sugerează doar greutățile modelului.

Cum să dimensionezi GPU-ul în funcție de model

Întrebarea practică de bază este dacă modelul încape pe un singur GPU sau trebuie împărțit pe mai multe. Citind comparația de mai sus în raport cu modelul tău, ia în considerare acești factori:

• Capacitatea VRAM determină ce modele încape. Un model cuantificat 7B–13B în FP8 sau INT8 poate fi servit de pe un accelerator de nivel mediu, în timp ce un model 70B în BF16 necesită în general o placă cu memorie mare sau un nod multi-GPU. Modelele foarte mari, de frontieră, necesită efectiv mai multe GPU-uri de top legate împreună.
• Lățimea de bandă a memoriei stabilește viteza de generare a tokenilor. Decodarea autoregresivă citește setul complet de greutăți pentru fiecare token produs, astfel că memoria de clasă HBM (așa cum se găsește pe plăcile pentru centre de date) generează tokeni mult mai rapid decât plăcile consumer bazate pe GDDR la aceeași dimensiune a modelului. Pentru chat interactiv, lățimea de bandă contează adesea mai mult decât puterea de calcul.
• Preciziile suportate determină cât de agresiv poți micșora modelul. Plăcile cu suport pentru tensor FP8 și INT8 îți permit să servești modele mai mari cu mai puțin VRAM și la un debit mai mare, cu condiția ca stiva ta de servire și schema de cuantizare a modelului să fie compatibile.
• Interconectarea contează odată ce un model se întinde pe mai multe GPU-uri. Servirea paralelă tensor schimbă activările între GPU-uri la fiecare strat, astfel că legăturile de clasă NVLink în interiorul unui nod oferă o latență semnificativ mai bună decât configurațiile doar PCIe. Pentru implementările pe un singur GPU, interconectarea este irelevantă.

Servirea pe un singur GPU versus multi-GPU

Dacă modelul tău și cache-ul său KV maxim încape pe un singur GPU, păstrează-l acolo. Servirea pe un singur GPU evită complet costurile de comunicare între dispozitive și este mai simplu de operat. Trece la paralelism tensor sau servire multi-nod doar când modelul nu încape cu adevărat, deoarece fiecare GPU adăugat introduce costuri de sincronizare și complică scalarea automată. Când ai nevoie de mai multe GPU-uri, preferă instanțele din lista de mai sus care combină plăci cu memorie mare și o interconectare rapidă în nod, în loc să unești plăci slab cuplate.

Caracteristici ale furnizorului care contează pentru servire, nu pentru antrenare

Dincolo de siliciu, modelul operațional al furnizorului decide dacă o implementare este viabilă. Când analizezi comparația de mai sus pentru o sarcină de servire, nu de antrenare, prioritizează diferit:

• Timpul de pornire la rece și de configurare devin preocupări de prim rang. Un punct final de servire care scalează la zero între vârfurile de trafic plătește costul pornirii la rece la fiecare scalare în sus, astfel că aprovizionarea rapidă și cache-ul de imagini afectează direct latența de coadă.
• Granularitatea facturării schimbă economia traficului fluctuant. Facturarea pe secundă sau pe minut se potrivește punctelor finale cu scalare automată care pornesc și opresc instanțe; facturarea grosieră pe oră penalizează acest tipar.
• Fiabilitatea on-demand în loc de spot este de obicei alegerea corectă. Instanțele întreruptibile sau spot sunt excelente pentru antrenare și joburi batch, dar riscante pentru un punct final orientat către utilizator, unde o recuperare în timpul unei cereri întrerupe traficul live. Spot poate servi bine inferența batch neinteractivă.
• Stocarea persistentă și încărcarea rapidă a modelului reduc durerea restartului. Greutățile de mai multe gigabytes care se reîncarcă din stocare obiect rece la fiecare restart adaugă minute de nefuncționare; volumele cache-uite sau atașate scurtează acest timp.
• Rețelistică și egress afectează costul la scară. Inferența cu debit mare poate transfera multe date în exterior; verifică termenii de egress înainte de a te angaja într-o implementare cu trafic intens.

Batch versus timp real și unde se situează costul

Decide devreme pentru ce mod optimizezi. Servirea interactivă în timp real valorizează timpul scurt până la primul token și rate constante de tokeni per utilizator, ceea ce favorizează memoria cu lățime de bandă mare și dimensiuni modeste ale batch-ului. Inferența batch sau offline valorizează debitul total și poate grupa batch-uri mari pe hardware mai ieftin sau întreruptibil, schimbând latența per cerere cu un cost mult mai bun per token. Multe echipe rulează ambele: un strat reactiv la cerere pentru utilizatorii live și un strat batch susținut de spot pentru generare în volum.

În ceea ce privește costul închiriat, servirea acoperă întreg spectrul. Un model mic cuantificat pe o placă de nivel mediu este ieftin și larg disponibil; modelele de frontieră pe noduri multi-GPU cu memorie mare sunt rare, mai scumpe și uneori cu capacitate limitată în vârfurile de cerere. Deoarece tarifele se schimbă constant și variază în funcție de regiune și angajament, tratează comparația live de mai sus ca sursă de adevăr, nu ca o cifră fixă, și compară instanțele după VRAM, clasa de lățime de bandă, interconectare și modelul de facturare împreună, nu doar după prețul afișat.

Întrebări frecvente

Cât VRAM am nevoie pentru a servi un LLM?

Bugetează pentru greutățile modelului la precizia aleasă plus un spațiu substanțial pentru cache-ul KV, care crește odată cu lungimea contextului și utilizatorii concurenți. Ca regulă generală, modelele mici și medii cuantificate se servesc de pe o singură placă de nivel mediu, în timp ce modelele mari la precizie mai înaltă au nevoie de o placă cu memorie mare sau mai multe GPU-uri. Dimensionează întotdeauna pentru concurența maximă, nu pentru stare inactivă.

Sunt GPU-urile spot sau întreruptibile potrivite pentru servirea LLM?

Pentru puncte finale în timp real orientate către utilizator, în general nu, deoarece o recuperare poate întrerupe cererile live și forța restarturi la rece. Instanțele spot sunt bine potrivite pentru inferența offline sau batch, unde întreruperile doar întârzie debitul, fără să întrerupă o sesiune interactivă. Multe echipe păstrează capacitate on-demand pentru traficul live și folosesc spot pentru joburi în volum.

De ce contează mai mult lățimea de bandă a memoriei decât puterea de calcul pentru servire?

Decodarea token cu token citește greutățile modelului din memorie pentru fiecare token generat, astfel că viteza de generare este limitată de cât de rapid transmite GPU-ul memoria, nu de FLOPS-urile maxime. De aceea plăcile pentru centre de date echipate cu HBM produc tokeni mai rapid decât plăcile consumer care țin același model și de aceea lățimea de bandă este o coloană cheie de comparat mai sus.

Ar trebui să servesc pe un singur GPU sau să împart pe mai multe?

Folosește un singur GPU ori de câte ori modelul și cache-ul său KV maxim încape, deoarece asta evită comunicarea între dispozitive și simplifică scalarea. Treci la paralelism tensor multi-GPU doar când modelul nu încape cu adevărat și, când o faci, alege instanțe care combină plăci cu memorie mare și o interconectare rapidă în nod.