BenchZgxFury

De bedste værdier observeret blandt de valgte målinger. Højere gennemløb (tok/s) er bedre; en lavere latency (TTFT = forsinkelse før det første token, TPOT = forsinkelse mellem to tokens) er bedre.

En oversigt automatisk skrevet ud fra de viste mål (det følger filtrene): hvad man skal huske, familie for familie.

En LLM-server betjener flere brugere på samme tid: den konkurrence er antallet af samtidige anmodninger. Den samlet hastighed (tokens genereret pr. sekund, alle anmodninger kombineret) stiger med samtidighed, mens forsinkelse pr. bruger forringes. Den TTFT er ventetiden før det første ord, den TPOT tiden mellem to ord (p50 = medianværdi, p99 = ugunstigt tilfælde oplevet af 1 % af anmodningerne). Hvert punkt er medianen af ​​flere gentagelser. De grå stiplede linjer er offentliggjorte figurer (reference) for samme model og samme profil.

Den goodput er mængden af nyttigt arbejde, der er tjent med respekt for et servicekvalitetsmål (SLO): her TTFT p99 ≤ ms og inter-token latency p99 ≤ ms. Søjlen angiver, hvor mange samtidige brugere maskinen understøtter uden at overskride disse tærskler; kurven viser andelen af ​​kompatible anmodninger (“attainment”), når belastningen øges.

Serverløs llama.cpp mikrobenchmark: pp = prompt behandling (prefill, tokens/s), tg = tekstgenerering (tokens/s). Endelsen _d4096 betyder, at konteksten allerede indeholder 4096 tokens, hvilket bremser begge faser.

Score (%) på standardopgaver: matematisk ræsonnement (GSM8K), viden og ræsonnement (MMLU-Pro), naturvidenskab, kodning, billedforståelse. En kvantificeret model (NVFP4, FP8, GGUF osv.) er hurtigere og mere kompakt, men kan miste præcision: når dens BF16-version også evalueres, er forskellen ("delta") ud over point rapporteres som en alarm.

Den RTFx (realtidsfaktor) angiver, hvor mange sekunder lyd der transskriberes pr. sekund: 1000× betyder, at en times lyd behandles på 3,6 s. Den WER (ordfejlrate, %) måler præcision: lavere = bedre.

Indlejringsmodeller transformerer tekst til en vektor til semantisk søgning (RAG). Vi måler antallet af anmodninger per sekund i henhold til længden af ​​teksten (256, 512 eller 2048 tokens) og samtidighed, p99 latency og søgekvalitet (gennemsnitlig MTEB-score, højere = bedre).

Samme indikatorer som for LLM'er, men anmodningerne indeholder et billede (512 px eller 1024 px) eller en video. Billedbehandling forlænger især TTFT.

Antal 1024x1024 frames (30 trin) produceret pr. sekund baseret på batchstørrelse, latens pr. frame, GPU-hukommelse ved peak og varighed pr. klip for videogenerering.

Latency før det første lydsvar i henhold til antallet af samtidige samtaler (arbejdere). Hvis serveren ikke kunne starte (forventet på aarch64-arkitektur for visse afhængigheder), angiver go/no-go-tabellen blokeringstrinnet.

Matrix-Game 4.0 (Skywork) erstatter grafikgengivelsen af et rigtigt spil med et video streaming skabelon : det oprindelige spil kører i lav-poly, og GPU'en "genmaler" hver frame i realtid fra denne visning og spillerens kontroller. To scener måles: Doom (det gamle egypten, førstepersonsskyderi) og kart (væddeløb, løb). Tre billedhastigheder i sekundet: FPS model = billeder produceret af modellen alene, Online FPS = billeder, der faktisk serveres til klienten under sessionen (hvad spilleren ser), Kodet FPS = billeder output fra H.264 video encoder. Vi bemærker også forsinkelsen før det første billede, serverstart, latency pr. billedblok (chunk) og VRAM ved peak. DE klip viser dobbeltvisning lav-poly | gengivet at dømme efter øjet. En software OpenGL-gengivelse (uden NVIDIA EGL) rapporteres: dens FPS er ikke repræsentativ.

Hver model modtager de samme instruktioner og skal producere, ved temperatur 0, syv komplette HTML5-spil i en enkelt fil (snake, breakout, flappy, invaders, tetris, doom, kart), ifølge flere mode : færdigheder (et enkelt svar med identiske best practice-ark for alle modeller), agent (pi-agenten skriver filen, tester den selv og retter den, med samme færdigheder) og evt oneshot (kun depositum). Billedteksterne lyder "model · mode." Den genererede fil indlæses i en Chromium uden skærm i 15 s med indsatte nøgler: vi tjekker, at den tager ansvaret, starter og kører uden at styrte, tæller vi gengivne billeder og konsolfejl. En lokal dommermodel scorer derefter koden ud af 10 (fuldstændighed i forhold til instruktionerne, spilbarhed, kodens kvalitet); den samlede score er gennemsnittet. Omtalen "selvvurdering" indikerer, at dommeren er den evaluerede model, hvilket kan påvirke scoren. Klik på et miniaturebillede for at afspille til det genererede spil og sammenlign modellerne i hånden.

Diarisering opdeler en optagelse i taleture, der er tildelt hver højttaler. DE DER (diariseringsfejlrate, %) er den del af tiden, der er fejltildelt: lavere = bedre. Det bryder sammen i ord savnet, falsk alarm (fejl opdaget tale) og forveksling mellem højttalere. Den RTFx angiver, hvor mange sekunders lyd der behandles pr. sekund; i mode streaming, måler vi også behandlingsforsinkelsen for hver lydklump.

Strøm, temperatur og GPU-ur registreret hvert sekund under en måling (nvidia-smi dmon), og derefter, når det er blevet registreret, aktiviteten af Stationens processor og hukommelse hvert 2. sekund (samlet CPU, travle kerner, server- og klientbeholdere, brugt hukommelse). Spredningsplottet relaterer gennemsnitlig effekt og gennemløb for at estimere energieffektiviteten (tokens pr. sekund og pr. watt).

Hver linje er en JSON-record. Klik på en overskrift for at sortere, tryk for at filtrere, eksporter til CSV. Mislykkede målinger viser deres fejlmeddelelse ved svævning.