Mennyi a másodpercenkénti tokenek száma az MLPerf által mérve, és hogyan használják ezeket az LLM-ben?

Hardver útmutató » referenciaértékek » Mennyi a másodpercenkénti tokenek száma az MLPerf által mérve, és hogyan használják ezeket az LLM-ben?

Ha nyelvi modellekkel dolgozol, akkor már ezerszer hallottad a „tokenek másodpercenként” kifejezést, de ritkán magyarázzák el részletesen, hogy mit jelent valós környezetben, és mindenekelőtt hogyan méri az MLPerf. Ebben a cikkben világosan elmagyarázzuk, mik a tokenek, miért olyan fontos a tokenek másodpercenkénti mutatója a következtetésben, és hogyan használják olyan platformok, mint a Databricks és az MLPerf benchmark a méretezéshez, összehasonlításhoz és skálázáshoz. Ezenkívül a gyártóktól származó konkrét adatokat és a felhőktől a földi teljesítményig terjedő elvárásokat is figyelembe vesszük..

A probléma nem jelentéktelen: az iparág szabványosította a másodpercenkénti tokeneket az LLM teljesítményének értékelésére adatközpontokban és a peremhálózatokon. Az MLPerf, a szakértők által lektorált MLCommons csomag, a hardverek és szoftverek összehasonlításának referenciapontjává vált.Ezzel párhuzamosan az olyan operátorok, mint a Databricks, már most is közvetlenül, másodpercenkénti tokenek tartománya alapján hozzák létre modell-végpontjaikat. Nézzük meg mindezt számokkal és használati esetekkel elemezve.

Mi az a token, és miért fontos az LLM-ben?

A nyelvi modellek nem dolgozzák fel az egyes betűket vagy szavakat önmagukban; tokeneknek nevezett egységekkel működnek. Egy token általában körülbelül 4 karakter hosszú, vagy átlagosan 0,75 szó.Ez az arány nyelvenként és a modell tokenizerétől függően változik, de gyors áttekintésként szolgál: egy 10 szavas szöveg 13–14 tokenen keresztül mozog.

A pontos szegmentálás a modelltől függ: Minden LLM saját tokenizert használ, és a szavakat teljes tokenekre vagy alszavakra osztja.Az online eszközök segítségével például láthatod, hogyan tokenizál a Llama egy adott kifejezést. Ez a változékonyság, amely apró részletnek tűnik, befolyásolja a késleltetést és a számítási költségeket.

A generálási rátát általában másodpercenkénti tokenekben, nem pedig másodpercenkénti szavakban fejezik ki. Ez homogenizálja a metrikát a nyelvek, a kontextushosszak és a kimeneti stílusok között., és lehetővé teszi a következtetési költség és a szükséges kapacitás pontos kiszámítását.

Miért mérjük a teljesítményt másodpercenkénti tokenekben, és nem RPS-ben?

A hagyományos API-szolgáltatások az RPS-re (másodpercenkénti kérések száma) összpontosítanak. Az LLM-ben ez a megközelítés nem elég jó: Két kérés feldolgozása nagyon eltérő időt vehet igénybe a bemeneti és kimeneti tokenektől függően.Vagyis a tényleges hasznos adat tokenekben érkezik, nem pedig a "hívások számában".

A változékonyságnak két fő forrása van. Először is, a bemeneti kontextus hossza: Egy rövid promptban lehet csak néhány token, de egy összefoglaló dokumentumban több száz vagy akár több ezer token is lehet.Másrészt a kimenet hossza: az összefoglalás általában kevesebb tokent eredményez; egy hosszú cikk vagy leírás generálása növeli az időt, mivel a kimenet dekódolása a legköltségesebb rész.

Ezért egy következtetési végpont realisztikus skálázásához hasznos tokenekben gondolkodni. A Databricks például másodpercenként meghatározott számú tokennel látja el a kiszolgáló végpontjait, és óránként számláz a skálázás alapján.Így a kapacitást a tényleges terheléshez igazíthatja anélkül, hogy egy olyan RPS megtévesztené, amely nem meséli el a teljes történetet.

Hogyan mérik a Databricks és az MLPerf a másodpercenkénti tokeneket?

A Databricks a RAG-ok reprezentatív mennyiségét veszi alapul referenciaként, és összefoglalja: 2048 bemeneti és 256 kimeneti tokenMindkét fázist (előtöltés és dekódolás) ötvözi, és alapértelmezés szerint optimalizálja az átviteli sebesség és a késleltetés közötti egyensúlyt kérésenként 1 darabos kötegméretek esetén, több egyidejű kérést szimulálva.

Ezzel a szabállyal a számok így néznek ki: ha egy végpontot másodpercenként 2304 tokenre konfigurálsz (2048 + 256), Egy ilyen méretű kérés körülbelül egy másodpercet vesz igénybeHa másodpercenként 5600 tokenre állítod, akkor ugyanaz a kérés körülbelül 0,5 másodpercre csökken, és másodpercenként két hasonló kérést tudsz feldolgozni.

Amikor a munkaterhelés változik, a késleltetés is megváltozik. Több kimeneti tokenek generálása jobban büntet, mint a bemeneti tokenek számának növelése.Ha kötegelt következtetést végez, számítsa ki az adathalmaz bemeneti és kimeneti tokenek átlagos számát, és hasonlítsa össze az előző referenciaértékkel az idők becsléséhez.

Gyakorlati példák: 1000 sorral, átlagosan 3000 bemeneti és 500 kimeneti tokennel, valamint 3500 token/másodperc előre beállított átviteli sebességgel, több mint 1000 másodpercig fog tartani mert az átlagaid meghaladják a referenciát. Ha ehelyett átlagosan 1500 bemenetet és 100 kimenetet adsz meg másodpercenként 1600 token kiépítéssel, 1000 másodperc alá fogsz menni összesen arra az 1000 sorra.

Igény szerinti automatikus skálázás és tényleges skálázási számítás

A Databricks Model Serving gyors automatikus skálázást kínál, amely Növelje vagy csökkentse az erőforrásokat a másodpercenkénti tokenek iránti igény alapjánA rendszer kapacitásblokkokban skálázódik, és a további kapacitást csak használat esetén számlázza ki. Több párhuzamos kérést tartalmazó tesztekben a kiépített átviteli sebesség addig növekszik, amíg az erőforrások telítettsége esetén másodpercenként körülbelül 8000 tokenre nem stabilizálódik, ami növeli a várakozási késleltetést.

Ha kevesebb tokent látsz másodpercenként, mint amennyit megjelöltél, ellenőrizz két dolgot: Kiépített párhuzamosság, amely tükrözi a végponti metrikákat és a minimális sávszélességet konfigurálva. Ezen adatok felhasználásával a tényleges skálázást a következő képlettel becsüljük meg: kiépített párhuzamosság × minimális sávszélesség mérete / 4.

Egy konkrét példa: maximum 8 párhuzamos futtatás és minimum 850 token/másodperc sávméret esetén, A tényleges limit másodpercenként 1700 token lenne. (8 × 850 / 4). Ennek a számításnak a megértése segít megelőzni a meglepetéseket, és finomhangolni a beállításokat a késleltetési SLO-khoz igazítva.

MLPerf következtetés: Mi ez és mit mér ma?

Az MLCommons által fejlesztett MLPerf egy nyílt és szabványosított csomag a mesterséges intelligencia teljesítményének mérésére az adatközpontokban és a peremhálózatokban, a látástól az LLM-ig. Célja, hogy a platformokat igazságos és reprodukálható módon hasonlítsa össze az ökoszisztéma hatékonyságának növelése érdekében.Az utóbbi években a hangsúly egyértelműen a GenAI és a nagy LLM-ek felé helyeződött át.

Az ötödik kiadásban a Llama 2 70B-t konszolidálták sztár-benchmarkként, kiszorítva a ResNet50-et, és A másodpercenkénti tokenek mutatói egy év alatt a legjobb esetben is akár 3,3-szorosára is javultak., a hardver- és szoftveroptimalizálásnak köszönhetően ötszörösére nőtt az átlagos teljesítmény. Az olyan CPU-k jelenléte a hivatalos eredményekben, mint az Intel Xeon 5, azt is bizonyította, hogy Bizonyos forgatókönyvekben lehetőség van hatékony generalista megoldásokra.

Az MLPerf Inference 5.1-es verziója újabb lépést tett előre: három új kulcsfontosságú referenciaértéket tartalmazott, DeepSeek-R1-gyel érvelés, Whisper Large v3-mal beszédfelismerés és egy Llama 3.1 8B-n alapuló kis LLMÖsszességében a konzorcium 27 résztvevőről számolt be, elérte a 90.000 XNUMX találatot, és leszűkítette a késleltetési mutatókat az interaktív forgatókönyvekben.

Mérőszámok és célkitűzések az új referenciaértékekben

A DeepSeek-R1-gyel, egy 671B paraméterből álló MoE-vel végzett érvelési benchmark azt mutatja, hogy Ezek a modellek hosszú érvelési láncolatokat hoznak létre a válaszadás előttAkár 20.000 3880 token kimenetét is támogatja, átlagosan XNUMX token kimenettel az adathalmazban, ami a mai napig a legnagyobb a következtetések terén.

A szabályok szigorú korlátokkal mérik az átviteli sebességet offline és szerver módban: Az első token megjelenéséig eltelt idő 2 másodperc, tokenekenkénti késleltetés 80 ms a 99. oldalonEz a „gondolkodásra” épülő költségvetés és a végrehajtásához szükséges reagálóképesség egyensúlyának megteremtésére törekszik.

A Llama 3.1‑8B-vel ellátott kisméretű LLM benchmark a GPT‑J 6B-t váltja fel átjáróként. Akár 128.000 XNUMX tokenből álló kontextusokat támogat és 778 bemeneti és 73 kimeneti tokennel értékeli ki a CNN-DailyMail összesítését. A pontosságot ROUGE segítségével validálják, és zárt osztásnál egy nagy pontosságú referenciaérték 99 százalékának kell megfelelniük.

A késleltetési metrikákban két mutatót használnak: a TTFT-t (az első tokenig eltelt időt) és a TPOT-ot (tokenenkénti kimenő időt). A szerveren 2 s TTFT és 100 ms TPOT jegyeztek fel. (kb. 480 ppm), az új interaktív forgatókönyvben pedig 0,5 s-ra, illetve 30 ms-ra szűkül (kb. 1600 ppm) olyan esetekhez, mint a csevegés, kódolás vagy kreatív eszközök.

Teljesítménybeli kiemelések gyártó és üzemeltető szerint

• Az NVIDIA ismét vezetett, ezúttal a Blackwell Ultra a GB300 NVL72 rendszeren pontot szerzett. Rekord az érvelésben, 45 százalékkal nagyobb átviteli sebességgel: a DeepSeek-R1 a GB200 NVL72-höz képest, elérve az 5842 tokent másodpercenként GPU-nként offline és 2907-et szerveren, ami közel ötszörös javulást jelent a nem ellenőrzött Hopperhez képest.
• Az új interaktív Llama 3.1 405B benchmarkban az NVIDIA alkalmazta a lebontott kiszolgálás a Dynamo-val, a kontextus és a generálás elkülönítésével a különböző GPU-kon, valamint a KV gyorsítótár NVLinken keresztüli átvitelével, ami GPU-nként 1,5-szer nagyobb átviteli sebességet eredményez a hagyományos Blackwell-kiszolgáláshoz képest, és több mint 5-ször nagyobbat, mint a Hopper-t használó rendszerek.
• A kisebb modellek esetében az NVIDIA arról számolt be, hogy Több mint 18.000 3.1 token másodpercenként GPU-nként Llama 8 XNUMXB offline verzióban és 5667 token másodpercenként GPU-nként a Whisperben, így minden forgatókönyvben (offline, szerver és interaktív) megőrizhető a GPU-vezető szerep.
• Az AMD kibővítette jelenlétét az Instinct MI355X GPU első szállítmányával, amely most a 2-70B-os tartományban található. Többcsomópontos skálázást és a másodpercenkénti tokenek számának 2,7-szeres növekedését mutatta az MI325X-hez képest az FP8-ban.Nyílt osztás esetén strukturált metszést alkalmaztak a Llama 3.1‑405B (FP4) fajtán. 82 százalékkal növelte az áteresztőképességet egy 21 százalékos mélységi metszésű modellel, és 90 százalékkal egy 33 százalékkal finomhangoltabb modellel, a pontosság megőrzése mellett.
• Emellett bemutatkozott a Llama 2‑70B Interactive, a Mixtral‑8×7B és a Stable Diffusion XL modellek szállítása is, és vegyes MI300X/MI325X eredményeket mutatott be: 4 csomópontra skálázva az MI355X 3,4-szer nagyobb átviteli sebességet ért el, mint az MI300X., 8 csomópontig terjedve, jó skálázhatósággal.
• A ProLiant és a Cray termékeket egyesítő HPE 14 első helyezettről számolt be. A DL1a Gen380 a DLRM és a Llama 12‑3.1B (szerver) kategóriákban emelkedett ki a 8 GPU-s PCIe rendszerek közül; a DL8 Gen385 Whisperben jobb GPU-teljesítményt mutatott H200 NVL-lel; a Cray XD670 (8× H200) pedig hat első helyezést ért el RetinaNet, Llama 3.1‑8B, Mixtral és Whisper teszteken, valamint első helyezést ért el RTX Pro 6000 Blackwell SE és GH200 NVL2 teszteken DLRM-ben.
• A CoreWeave volt az első felhőalapú megoldás, amely eredményeket jelentett a GB300-zal kapcsolatban, és a következőket nyújtotta: 6005 token másodpercenként GPU-nként DeepSeek-R1-ben offline, valamint bemutatja a Slurm Kubernetes-en történő vezénylését és skálázását, valamint a topológia-tudatos ütemezést az NVLink maximális kihasználása érdekében.
• A Dell 12 AMD és NVIDIA gyorsítókkal felszerelt rendszert szállított, melyek közül a legkiemelkedőbb az LLaMA 2 70B Interactive PowerEdge XE9680L és B200 processzorokkal. LLaMA 3.1‑8B szerver XE9685L+B200 alaplapon, az SDXL az XE9685L-en és a Whisper az XE9680L-en, amelyek a képfeldolgozástól a hangfeldolgozáson át az LLM-ig sokoldalúságot demonstrálják.
• Az Intel hangsúlyozta, hogy továbbra is az egyetlen, amely szerver CPU-kkal küld eredményeket és kimutatta, hogy a P-magokkal rendelkező Xeon 6 öt benchmark alapján 1,9-szeres javulást mutat az 5. generációs Xeonhoz képest, megerősítve szerepét az általános célú következtetésekben. Emellett bemutatta a 8 Arc Pro B60 GPU-val és 192 GB VRAM-mal rendelkező munkaállomásokat, amelyek több felhasználó számára is kiszolgálják a Llama2‑70B-t, valamint a csomagolt illesztőprogramokat és keretrendszereket a több GPU-s telepítés egyszerűsítése érdekében.
• Az integrátorok és partnerek között az ASUSTeK Optimalizált késleltetés és átviteli sebesség kvantálással, kernelekkel és veremmelA Broadcom minimális terheléssel, a csupasz fémhez képest működő VCF virtualizációt mutatott be több munkaterhelésen (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet); a Cisco szinte lineárisan skálázódott az UCS C885A M8 (8× H200 SXM) és az UCS C845A M8 (8× H200 NVL vagy L40S) eszközökkel, One G200 hálózatok támogatásával.
• A KRAI, OpenAI API és realisztikus többletterhelés használatával, összehasonlította az SGLang-ot és a vLLM-et a Llama3.1‑70B-vel: 31.391 0.4.9 token másodpercenként offline állapotban az SGLang XNUMX-cel és 26.319 0.9.2 vLLM 8-vel egyetlen szerveren 200x H27.697-zal; dinamikus kvantálással elérte a 30.893 87.334-et SGLang-gal és XNUMX XNUMX-at vLLM-mel, több csomóponton pedig másodpercenként XNUMX XNUMX tokenre skálázódott három szerveren.
• A Lambda, 8x B200 180 GB-os SXM-mel, átviteli sebességnövekedést mutatott. akár 7 százalék SDXL-ben és 15 százalék Llama 3.1‑405B-ben az előző körhöz képest, és 16-tól 1536 GPU-ig terjedő klasztereket kínál menedzselt Kubernetes vagy Slurm segítségével.
• A MiTAC a G8825Z5 sorozatával az LLaMA 2 70B Interactive kiállításon tündökölt. 18.846,1 token másodpercenként és jó eredményeket ért el Server és Mixtral környezetben; a Nebius virtualizált teljesítményét szinte a bare metal szintjén tanúsította GB200 NVL72, HGX B200 és HGX H200 rendszerekben. 596,11 token másodpercenként a szerveren és 855,82 token offline a Llama 3.1‑405B-n 4 GB-os 200 GPU-val.
• A Red Hat a vLLM-et támogatott futási környezetként mutatta be AI Inference Serverén. CUTLASS kernelek FP8-hoz és FlashAttention‑3-hoz plusz egy továbbfejlesztett vLLM v1 motor hajtja a Llama‑3.1‑8B-t a H100 és L40S modellekben, kiváló ár-érték arány mellett.
• A Supermicro vezető eredményeket ért el a HGX-B200 8-GPU-s (levegős és folyadékos) processzorával, mind Intel, mind AMD CPU-kkal, kiemelve a következőket: Llama 3.1‑8B és Llama 2‑70B szerveren/offline/interaktív módban és Whisperen; együttműködések során kiváló skálázást mutatott 32× H100-SXM-mel és alternatívákkal az MI325X-szel.
• A Vultr a Supermicro AS-8126GS-TNMR és a 8x MI325X chipekkel debütált, versenyképes teljesítményt nyújtva felhőalapú GPU-ként; GATEOverflow elősegítette a reprodukálhatóságot az MLCFlow segítségével RTX 4090 és AMD/Intel CPU-kon; a Giga Computing 8U léghűtéses EPYC+MI325X és Xeon+HGX B200 rendszereket szállított; a QCT a Xeon 6 konfigurációkat H200 NVL-lel (4 GPU) és 8× H200 SXM5 platformokkal, NVLinkkel és GPUDirect Storage-szal fedte le, a 8× MI325X rendszer mellett.

Az akadémiai szférának is megvolt a maga ideje. A Floridai Egyetem a HiPerGatorral integrált DGX B200 SuperPOD-jával... volt az első intézmény, amely benyújtotta a következtetések eredményeit Zárt particionálás alatti szerverkésleltetések kielégítése, Docker/Sudo nélküli Apptainer használatával, és többfelhasználós SLURM-ba illesztés. Az ellenkező végletben egyetlen beküldés egy M1 MacBook Pro-n, ONNX Runtime és CoreML GPU-n, valamint Neural Engine-en, meghaladta a célpontossági szintet az élkategóriában, és igazolta, hogy a minőségi következtetések fogyasztói hardvereken is értékelhetők.

A felhasználók által érzékelt sebesség és a gyakorlati korlátok

A felhasználói élményt nem csak benchmarkokban mérik; a mindennapi életben is, A folyékonyság érzése akkor jelentkezik, amikor túllépsz egy bizonyos másodpercenkénti tokenek küszöbértéket.Egy felhasználó megjegyezte, hogy beszélgetés esetén másodpercenként 4 token a korlátja, történetírás esetén pedig körülbelül 10 token; ez alatt az interakció lassúnak érződik.

Ha megpróbálsz helyben futtatni egy LLM-et, három valóság van. Egy asztali számítógép CPU-ján, Másodpercenként 1-2 token sebességgel mozog normális., hosszú válaszokhoz kivitelezhetetlen. Egy csúcskategóriás játékra optimalizált GPU-val közel 5 tokent lehet elérni másodpercenként. Egy NVIDIA H100-zal igen, már 60 tokenről beszélünk másodpercenként, de ez adatközponti hardver, nem asztali hardver.

Mi történik a felhőben? A legerősebb szolgáltatók megdöntik ezeket a számokat speciális hardvereiknek és optimalizált következtetési rendszereiknek köszönhetően. A ChatGPT-119-en átlagosan másodpercenként körülbelül 4, a Gemini-n pedig 168 tokenről számoltak be., míg a népszerű nyílt forráskódú modellek, mint például a DeepSeek, körülbelül 21 tokent generálnak másodpercenként. Ha ezt szavakra konvertáljuk, 119 token másodpercenként körülbelül 90 szót jelent.

Működési következtetés: a legtöbb felhasználó számára A mesterséges intelligencia futtatása a számítógépen lehetséges, de a lassúság miatt nem praktikus.A kényelmes sebesség és a szoros késleltetés érdekében továbbra is a felügyelt szolgáltatások jelentik az ésszerű megoldást.

Hogyan méretezhető a végpont TPS szerint, és mire számíthatunk a késleltetésből

Méretezési gyakorlati lépések. Először is, vázolja fel a felhasználási esetet: A bemeneti és kimeneti tokenek átlagos száma, hosszeloszlás és várható párhuzamosságMásodszor, futtass egy terheléses tesztet egy reprezentatív adathalmazzal, figyelembe véve a TTFT-t és a kérésenként másodpercenként fenntartott tokeneket.

Ezután igazítsa a konfigurációt a mintájához. Ha a számítási feladat hasonlít a Databricks referenciájához (2048 be, 256 ki), Válasszon ki egy másodpercenkénti tokenek tartományt úgy, hogy a kérés a kívánt késleltetési keretbe essen.Ne feledd, hogy a kimenet másolása általában többe kerül, mint a bemenet másolása, és hogy a hatékony párhuzamosság a tényleges automatikus skálázástól függ.

Figyelemmel kísérés és módosítás. Tartsa szemmel a mutatókat biztosított párhuzamosság, sorok, TTFT és TPOT, és hasonlítsa össze az SLO-kkal. Ha kevés a kapacitás, bővítse a tartományt; ha felesleges erőforrásai vannak, csökkentse azt, és a blokkok beállításával takarítson meg erőforrásokat. A valódi skálázási képlet segít megérteni, hogy miért nem teljesít a végpont a konfigurációnak megfelelően, ha nem hozott létre elegendő replikát.

Végül, légy tisztában a forgatókönyvvel. Interaktív chatbot stílusú módban, törekedjen a TTFT 0,5 másodpercre és 30 ms-ra tokenenként Ez prémium felhasználói élményt nyújt. Szerver módban tokenenként 2 s és 100 ms az ésszerű iránymutatás, offline módban pedig a maximális átviteli sebességet keresi, miközben fenntartja a benchmark által megkövetelt pontosságot.

Az MLPerf trendeket tekintve a vektor egyértelmű: Több kontextus, több token és jobb hatékonyságnövelő technikák – a lebontott kiszolgálás, az FP4/FP8, a strukturált metszés, az egyéni kernelek, a KV gyorsítótár ütemezése – a tokenek maximális számát minden második évben növelik, mind chipenként, mind rendszerenként.

A Databricks és az MLPerf által rajzolt összkép konzisztens: A másodpercenkénti tokenek számában való gondolkodás a helyes módja az LLM-ben a költségek, a késleltetés és a skálázhatóság mérlegelésének.Egy jó reprezentatív benchmarkkal, TTFT/TPOT metrikákkal és jól kalibrált automatikus skálázással gyors és stabil válaszok szállíthatók az infrastruktúra túlméretezése nélkül.

Kapcsolódó cikk:

NVIDIA Blackwell Ultra GB300: Architektúra, memória és NVLink 5