Vilka tokens per sekund mäts av MLPerf och hur används de i LLM?

Hårdvaruguide » riktmärken » Vilka tokens per sekund mäts av MLPerf och hur används de i LLM?

Om du arbetar med språkmodeller har du hört termen "tokens per sekund" tusen gånger, men det förklaras sällan i detalj vad det betyder i verkliga miljöer och framför allt hur MLPerf mäter det. I den här artikeln förklarar vi tydligt vad tokens är, varför måttet tokens per sekund är så viktigt för inferens, och hur plattformar som Databricks och MLPerf-benchmarket använder det för att storleksanpassa, jämföra och skala. Dessutom inkluderar vi specifika siffror från tillverkare och molnbaserade prestandaförväntningar för markanvändning..

Problemet är inte litet: branschen har standardiserat tokens per sekund för att utvärdera LLM-prestanda i datacenter och vid kanten. MLPerf, den expertgranskade MLCommons-sviten, har blivit riktmärket för att jämföra hårdvara och mjukvara.Parallellt etablerar operatörer som Databricks redan sina modellslutpunkter direkt baserat på ett intervall av tokens per sekund. Låt oss bryta ner allt detta, med siffror och användningsfall i handen.

Vad är en token och varför är den viktig i LLM?

Språkmodeller bearbetar inte enskilda bokstäver eller ord som de är; de arbetar med enheter som kallas tokens. En token är vanligtvis ungefär 4 tecken lång, eller i genomsnitt 0,75 ord.Detta förhållande varierar beroende på språk och modellens tokeniserare, men det fungerar som en snabb referens: en text på 10 ord flyttar runt 13–14 tokens.

Den exakta segmenteringen beror på modellen: Varje LLM använder sin egen tokenizer och delar upp ord i kompletta tokens eller delord.Onlineverktyg låter dig till exempel se hur Llama tokeniserar en specifik fras. Denna variation, som verkar vara en liten detalj, påverkar latens och beräkningskostnader.

När man talar om generationshastighet uttrycks den vanligtvis i termer av tokens per sekund, snarare än ord per sekund. Detta homogeniserar metriken över språk, kontextlängder och utdatastilar., och gör det möjligt att noggrant beräkna inferenskostnaden och den erforderliga kapaciteten.

Varför mäta prestanda i tokens per sekund och inte i RPS?

Traditionella API-tjänster fokuserar på RPS (förfrågningar per sekund). Inom LLM är den metoden otillräcklig: Två förfrågningar kan ta väldigt olika tid beroende på indatatokens och utdatatokensDet vill säga, den faktiska nyttolasten kommer i tokens, inte i "antal samtal".

Det finns två viktiga källor till variabilitet. För det första, längden på inmatningskontexten: En kort prompt kan bara ha några få tokens, men ett sammanfattningsdokument kan svälla upp till hundratals eller tusentals.Å andra sidan, längden på utdata: sammanfattning producerar vanligtvis färre tokens; generering av en lång artikel eller beskrivning ökar tiden, eftersom avkodning av utdata är den dyraste delen.

Därför, för att realistiskt skala en inferensslutpunkt, är det bra att tänka i termer av tokens. Databricks, till exempel, provisionerar sina serveringslutpunkter med ett intervall av tokens per sekund och fakturerar timvis baserat på skalning.På så sätt kan du anpassa kapaciteten till den faktiska belastningen utan att bli lurad av en RPS som inte berättar hela historien.

Hur Databricks och MLPerf mäter tokens per sekund

Databricks tar en representativ mängd RAG:er som referens och sammanfattar: 2048 inmatningstokens och 256 utmatningstokensDen kombinerar båda faserna (förifyllning och avkodning) och optimerar som standard balansen mellan dataflöde och latens för batchstorlekar på 1 per begäran, vilket simulerar flera samtidiga begäranden.

Med den regeln ser siffrorna ut så här: om du konfigurerar en slutpunkt med 2304 tokens per sekund (2048 + 256), En förfrågan med de storlekarna tar ungefär en sekundOm du ställer in den på 5600 tokens per sekund sjunker samma begäran till cirka 0,5 sekunder och du kan bearbeta två liknande begäranden per sekund.

När din arbetsbelastning ändras kommer latensen att ändras. Att generera fler utdatatokens bestraffar mer än att öka antalet indatatokens.Om du gör batch-inferens, beräkna det genomsnittliga antalet indata- och utdata-tokens för din datauppsättning och jämför det med föregående benchmark för att uppskatta tider.

Praktiska exempel: med 1000 rader, ett genomsnitt på 3000 indata- och 500 utdata-tokens och ett provisionerat dataflöde på 3500 tokens per sekund, det tar dig mer än 1000 sekunder eftersom dina medelvärden överstiger referensen. Om du istället får ett genomsnitt på 1500 indata och 100 utdata med en provisionering på 1600 tokens per sekund, du kommer att gå under 1000 sekunder totalt för dessa 1000 rader.

Autoskalning på begäran och beräkning av faktisk skalning

Databricks Model Serving inkluderar snabb autoskalning som Öka eller minska resurser baserat på efterfrågan på tokens per sekundSystemet skalas i kapacitetsblock, och ytterligare kapacitet faktureras endast när den används. I tester med fler parallella förfrågningar ökar det provisionerade dataflödet tills det stabiliseras på cirka 8000 XNUMX tokens per sekund när resurserna är mättade, vilket ökar kölatensen.

Om du ser färre tokens per sekund än du markerat, kontrollera två saker: Provisionerad samtidighet som återspeglar slutpunktsmått och minsta bandbreddsstorlek konfigurerad. Med dessa data uppskattas den faktiska skalningen med hjälp av formeln: provisionerad samtidighet × minsta bandbreddsstorlek / 4.

Ett konkret exempel: med en maximal samtidighet på 8 och en minsta stripe-storlek på 850 tokens per sekund, Den effektiva gränsen skulle vara 1700 tokens per sekund (8 × 850 / 4). Att förstå denna beräkning förhindrar överraskningar och hjälper dig att finjustera dina inställningar till dina latens-SLO:er.

MLPerf-inferens: Vad det är och vad det mäter idag

MLPerf, utvecklat av MLCommons, är den öppna och standardiserade sviten för att mäta AI-prestanda i datacenter och edge-miljöer, från vision till LLM. Dess mål är att jämföra plattformar på ett rättvist och reproducerbart sätt för att driva ekosystemets effektivitet.Under senare år har fokus tydligt skiftat mot GenAI och stora juridikprogram.

I den femte upplagan konsoliderades Llama 2 70B som stjärnreferens och ersatte ResNet50. Mätvärdena för tokens per sekund förbättrades i bästa fall med upp till 3,3 gånger på ett år., med en medianprestanda 5 gånger högre tack vare hårdvaru- och mjukvaruoptimeringar. Förekomsten av processorer som Intel Xeon 6 i officiella resultat visade också att Det finns utrymme för effektiva generalistlösningar i vissa scenarier.

Version 5.1 av MLPerf Inference har tagit ytterligare ett steg framåt: den har införlivat tre nya viktiga riktmärken, resonemang med DeepSeek-R1, tal-till-text med Whisper Large v3 och en liten LLM baserad på Llama 3.1 8BSammantaget rapporterade konsortiet 27 deltagare, nådde milstolpen 90.000 XNUMX resultat och begränsade latensmätvärdena i interaktiva scenarier.

Mätvärden och mål i de nya riktmärkena

Resonemangsriktmärket med DeepSeek-R1, ett MoE med 671B parametrar, visar att Dessa modeller producerar långa kedjor av resonemang innan svaretStöder utdata på upp till 20.000 3880 tokens, med ett genomsnitt på XNUMX XNUMX tokens per utdata i datauppsättningen, det största antalet hittills inom inferens.

Reglerna mäter dataflödet i offline-läge och serverläge med strikta gränser: Tid till första token på 2 sekunder och latens per token på 80 ms vid p99Detta syftar till att balansera den "tänkande" budgeten med den respons som krävs för att utnyttja den.

Det lilla LLM-riktmärket med Llama 3.1‑8B ersätter GPT‑J 6B som gateway. Stöder kontexter för upp till 128.000 XNUMX tokens och utvärderar sammanfattningar på CNN-DailyMail med 778 indatatokens och 73 utdatatokens. Noggrannheten valideras med ROUGE och krävs, i sluten division, för att matcha 99 procent av ett riktmärke med hög noggrannhet.

I latensmätningar används två indikatorer: TTFT (tid till första token) och TPOT (tid per token ut). På servern noteras 2 s TTFT och 100 ms TPOT. (runt 480 ppm), och i det nya interaktiva scenariot pressas den till 0,5 s respektive 30 ms (runt 1600 ppm) för fall som chatt, kodning eller kreativa verktyg.

Prestandahöjdpunkter från tillverkare och operatör

• NVIDIA ledde igen, den här gången med Blackwell Ultra på GB300 NVL72-systemet, och gjorde poäng Rekord i resonemang med 45 procent högre dataflöde DeepSeek-R1 än GB200 NVL72och når 5842 tokens per sekund per GPU offline och 2907 på servern, med förbättringar nära 5x jämfört med overifierade Hopper.
• I det nya interaktiva Llama 3.1 405B-riktmärket tillämpade NVIDIA uppdelad servering med Dynamo, separerar kontext och generering på olika GPU:er och överför KV-cache via NVLink, vilket uppnår 1,5 gånger mer dataflöde per GPU än traditionell servering på Blackwell och mer än 5 gånger mer än system med Hopper.
• För mindre modeller rapporterade NVIDIA Över 18.000 3.1 tokens per sekund per GPU på Llama 8 XNUMXB offline och 5667 tokens per sekund per GPU i Whisper, vilket bibehåller GPU-ledarskapet i alla scenarier (offline, server och interaktivt).
• AMD utökade sin närvaro med den första leveransen av Instinct MI355X GPU, som nu ligger i 2-70B-serien. Den visade skalning av flera noder och en 2,7x ökning av tokens per sekund jämfört med MI325X i FP8.I öppen delning tillämpades strukturerad beskärning på Llama 3.1‑405B (FP4), ökar genomströmningen med 82 procent med en modell med 21 procents djupbeskuren dimension och med 90 procent med en modell med 33 procents finjustering, bibehåller precision.
• Den debuterade även leveranser av Llama 2‑70B Interactive, Mixtral‑8×7B och Stable Diffusion XL, och presenterade blandade MI300X/MI325X-resultat: Vid skalning till 4 noder uppnådde MI355X 3,4 gånger högre dataflöde än MI300X, som utökas till 8 noder med god skalbarhet.
• HPE, som kombinerar ProLiant och Cray, rapporterade 14 förstaplatser. DL1a Gen380 utmärkte sig i DLRM och Llama 12‑3.1B (Server) bland 8-GPU PCIe-system; DL8 Gen385 märkbart bättre GPU-prestanda i Whisper med H200 NVL; och Cray XD670 (8× H200) fick sex förstaplatser i RetinaNet, Llama 3.1‑8B, Mixtral och Whisper, plus förstaplatser med RTX Pro 6000 Blackwell SE och GH200 NVL2-resultat i DLRM.
• CoreWeave var det första molnet som rapporterade resultat med GB300, och levererade 6005 tokens per sekund per GPU i DeepSeek-R1 offline och demonstrerar orkestrering och skalning med Slurm på Kubernetes och topologimedveten schemaläggning för att få ut det mesta av NVLink.
• Dell levererade 12 system med AMD- och NVIDIA-acceleratorer, bland annat LLaMA 2 70B Interactive med PowerEdge XE9680L och B200. LLaMA 3.1‑8B-server på XE9685L+B200, SDXL på XE9685L och Whisper på XE9680L, vilket visar mångsidighet från bild till röst genom LLM.
• Intel betonade att det fortfarande är den enda som skickar resultat med server-CPU:er och visade att Xeon 6 med P-kärnor förbättrar sig med 1,9 gånger jämfört med 5:e generationens Xeon över fem riktmärken, vilket befäster dess roll inom generell inferens. Den introducerade också arbetsstationer med 8 Arc Pro B60 GPU:er, med 192 GB VRAM för att hantera Llama2-70B för flera användare, och paketerade drivrutiner och ramverk för att förenkla distribution av flera GPU:er.
• Bland integratörerna och partnerna finns ASUSTeK Optimerad latens och dataflöde med kvantisering, kärnor och stackBroadcom demonstrerade VCF-virtualisering med minimal overhead jämfört med bare metal på flera arbetsbelastningar (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet); Cisco skalade nästan linjärt med UCS C885A M8 (8× H200 SXM) och UCS C845A M8 (8× H200 NVL eller L40S), med stöd av One G200-nätverk.
• KRAI jämförde SGLang och vLLM med Llama3.1‑70B med hjälp av OpenAI API och realistiska omkostnader: 31.391 0.4.9 tokens per sekund offline med SGLang XNUMX och 26.319 0.9.2 med vLLM 8 på en enda server med 200x H27.697; med dynamisk kvantisering nådde den 30.893 87.334 med SGLang och XNUMX XNUMX med vLLM, och på multinod skalades den upp till XNUMX XNUMX tokens per sekund på tre servrar.
• Lambda, med 8x B200 180 GB SXM, visade förbättringar i dataflödet upp till 7 procent i SDXL och 15 procent i Llama 3.1‑405B jämfört med föregående omgång, och erbjuder kluster från 16 till 1536 GPU:er med hanterade Kubernetes eller Slurm.
• MiTAC, med sin G8825Z5-serie, glänste på LLaMA 2 70B Interactive med 18.846,1 tokens per sekund och goda resultat i Server och Mixtral; Nebius certifierade sin virtualiserade prestanda nästan i nivå med bare metal i GB200 NVL72, HGX B200 och HGX H200, med 596,11 tokens per sekund på servern och 855,82 tokens offline på Llama 3.1‑405B med 4 GB200 GPU:er.
• Red Hat demonstrerade vLLM som en stödd runtime på sin AI Inference Server, med CUTLASS-kärnor för FP8 och FlashAttention‑3 plus en förbättrad vLLM v1-motor, driver Llama-3.1-8B i H100 och L40S med utmärkt kostnads-prestandaförhållande.
• Supermicro noterade ledande resultat med HGX-B200 8-GPU (luft och vätska) med både Intel- och AMD-processorer, vilket lyfte fram Llama 3.1‑8B och Llama 2‑70B på server/offline/interaktiv och Whisper; i samarbeten visade den utmärkt skalning med 32× H100‑SXM och alternativ med MI325X.
• Vultr debuterade med Supermicro AS-8126GS-TNMR och 8x MI325X, vilket certifierade konkurrenskraftig prestanda som en moln-GPU; GATEOverflow främjade reproducerbarhet med MLCFlow på RTX 4090 och AMD/Intel-processorer; Giga Computing levererade 8U luftkylda EPYC+MI325X- och Xeon+HGX B200-system; QCT täckte Xeon 6-konfigurationer med H200 NVL (4 GPU:er) och 8× H200 SXM5-plattformar med NVLink och GPUDirect Storage, utöver 8× MI325X-system.

Även den akademiska världen hade sin upplevelse. University of Florida, med sin DGX B200 SuperPOD integrerad med HiPerGator, var den första institutionen som lämnade in inferensresultat Möta serverlatenser under sluten partitionering, använda Apptainer utan Docker/Sudo och anpassa sig till fleranvändar-SLURM. I motsatt riktning, en enda inlämning på en M1 MacBook Pro, med ONNX Runtime och CoreML på GPU och Neural Engine, överträffade målnoggrannheten i kantkategorin och visade att kvalitetsinferens kan utvärderas på konsumenthårdvara.

Hastighet uppfattad av användare och praktiska begränsningar

Användarupplevelse mäts inte bara i riktmärken; i vardagen, Känslan av flytande förmåga uppstår när man överskrider ett visst tröskelvärde för antalet tokens per sekund.En användare kommenterade att deras gräns för konversation är 4 tokens per sekund, och för berättelseskrivande är den runt 10 tokens per sekund; under det känns interaktionen långsam.

Om du försöker köra en LLM lokalt finns det tre verkligheter. På en stationär CPU, Det är normalt att röra sig med 1–2 marker per sekund, omöjligt för långa svar. Med ett avancerat spel-GPU kan du få nära 5 tokens per sekund. Med ett NVIDIA H100, ja, vi pratar redan om 60 tokens per sekund, men det är datacenterhårdvara, inte stationär hårdvara.

Vad händer i molnet? De kraftfullaste leverantörerna slår dessa siffror tack vare specialiserad hårdvara och optimerade inferensstackar. Genomsnitt på cirka 119 tokens per sekund har rapporterats på ChatGPT-4 och 168 på Gemini., medan populära modeller med öppen källkod som DeepSeek ligger runt 21 tokens per sekund. Om man konverterar det till ord blir 119 tokens per sekund cirka 90 ord per sekund.

Operativ slutsats: för de flesta användare, Att köra AI på datorn är möjligt, men opraktiskt på grund av långsamhetFör att arbeta med bekväma hastigheter och med snäva latenser är hanterade tjänster fortfarande det förnuftiga alternativet.

Hur du dimensionerar din slutpunkt med TPS och vad du kan förvänta dig av latens

Praktiska steg för dimensionering. Beskriv först ditt användningsfall: Genomsnittligt antal in- och utdatatokens, längdfördelning och förväntad samtidighetKör sedan ett belastningstest med en representativ datamängd, som involverar TTFT och tokens per sekund som upprätthålls per begäran.

Justera sedan konfigurationen med ditt mönster. Om din arbetsbelastning liknar Databricks-referensen (2048 in, 256 ut), Välj ett intervall av tokens per sekund så att en begäran faller inom den önskade latensbudgetenKom ihåg att det vanligtvis kostar mer att duplicera utdata än att duplicera indata, och att effektiv samtidighet är beroende av faktisk autoskalning.

Övervaka och justera. Håll koll på mätvärden. provisionerad samtidighet, köer, TTFT och TPOToch jämför det med dina SLO:er. Om du har ont om kapacitet, utöka intervallet; om du har överskottsresurser, sänk det och justera block för att spara. Den verkliga skalningsformeln hjälper dig att förstå varför slutpunkten inte fungerar som konfigurerad om den inte skapade tillräckligt många repliker.

Slutligen, var medveten om scenariot. I interaktivt chatbot-läge, sikta på en TTFT på 0,5 sekunder och 30 ms per token Detta ger dig en förstklassig användarupplevelse. I serverläge är 2 sekunder och 100 ms per token rimliga riktlinjer, och offline strävar den efter maximal dataflöde samtidigt som den noggrannhet som krävs av riktmärket bibehålls.

Om man tittar på MLPerf-trender är vektorn tydlig: Mer kontext, fler tokens och bättre effektivitetstekniker —disaggregerad servering, FP4/FP8, strukturerad beskärning, anpassade kärnor, KV-cacheschemaläggning — pressar upp tokentaket med andra året före, både per chip och per system.

Den övergripande bilden som Databricks och MLPerf tecknar är konsekvent: Att tänka i termer av tokens per sekund är det korrekta sättet att resonera kring kostnad, latens och skalbarhet inom LLM.Med ett bra representativt riktmärke, TTFT/TPOT-mätvärden och välkalibrerad autoskalning är det möjligt att leverera snabba och stabila svar utan att överdimensionera infrastrukturen.

Relaterad artikel:

NVIDIA Blackwell Ultra GB300: Arkitektur, minne och NVLink 5