Den 16 september 2026 publicerade MLCommons MLPerf Inference v6.1-resultat med nya end-to-end-tester för retrieval-augmented generation och edge agentic inference.[1] För en privat AI-köpare är den användbara utvecklingen den bredare mätenheten: bevis om ett arbetsflöde kan besvara frågor som ett kort modell-svarstest lämnar öppna. Vår rekommendation är att använda dessa resultat för att forma en pilot och sedan mäta den faktiska driftsättningen separat.

Denna artikel speglar material tillgängligt den 26 september. Den rapporterar inte en Software Tailor benchmarkinlämning eller påstår att en AI Server-distribution kommer att reproducera ett publicerat resultat.

Läs arbetsbelastningen innan du jämför poängen

Versionen beskriver RAG-arbete som spänner över retrieval och generering, samt en edge agentic-arbetsbelastning med upprepade turer och växande historik.[1] Dessa är användbara skillnader för köpare. En dokumentassistent och ett kodningsarbetsflöde kan båda anropa en språkmodell, men deras omgivande arbete förtjänar separat undersökning.

Börja en jämförelse med den affärsverksamhet som övervägs. Namnge indata, förväntat utdata och den punkt då operationen är slutförd. Ett dokument-svar kan vara färdigt först när dess citerade avsnitt kan öppnas. En agentuppgift kan kräva ett verifierat verktygsresultat innan dess svar är användbart. Detta är föreslagna acceptansgränser, inte ytterligare krav från MLPerf.

Placera benchmarkens gräns bredvid den beskrivningen. Markera varje steg som resultatet täcker och varje steg som tillhör den föreslagna tillämpningen. En synlig lucka är användbar: den identifierar arbete som piloten måste mäta. Att dölja luckan i en enda sammanfattande poäng tar bort anledningen till att göra jämförelsen.

Separera förberedelse av korpus från att besvara en fråga

MLCommons introduktion i augusti till RAG-benchmarken skiljer en ingestpipeline som skapar en vektordatabas från en frågesvarspipeline som arbetar över den. Den senare kan upprepa retrieval och resonemang över flera hopp.[2] Detta gör förberedelsearbetet synligt tillsammans med svarsarbetet.

För en organisation som utvärderar sin egen dokumentsamling har vi föreslagit en pilot med två poster. Den ena beskriver att göra en definierad samling redo för användning. Den andra beskriver att besvara en fast uppsättning frågor mot den samlingen. Behåll dokumentversioner och förberedelseinställningar med båda posterna så att svaren kan spåras till samma utgångspunkt.

Lägg sedan till en kontrollerad dokumentuppdatering. Observera när ändringen blir tillgänglig för frågesvarspipelinen och vad användaren ser under övergången. Behandla detta som ett applikationstest med eget resultat. Ett ingestresultat för en extern benchmark fastställer inte ett uppdateringslöfte för en annan dokumentdatabas.

Denna distinktion är särskilt användbar när inköp begär ett enda svarstidsåtagande. Teamet kan specificera om åtagandet börjar med en redan förberedd samling eller inkluderar att göra nya dokument sökbara. Artikeln om kapacitetsplanering utvecklar den distinktionen till ett affärsbeslut.

Behandla en agentsekvens som en sekvens

Ett snabbt första svar är ett ofullständigt acceptanskriterium för en applikation som upprepade gånger kommer att granska bevis och anropa verktyg. Vår föreslagna utvärdering håller hela uppgiften synlig. Registrera de successiva förfrågningarna, de tillåtna operationerna och det slutgiltiga resultatet, och inspektera sedan var applikationen väntade eller behövde ingripande.

Använd en uppgift med ett känt resultat innan du lägger till öppet arbete. Ett litet fabricerat lager är tillräckligt för att fastställa om en agent efterfrågar avsedd artikel, får korrekt resultat och för det vidare i sitt nästa svar. Den AI Server-integrationsprocedur använder det exemplet för att separera anslutningskontroller från verktygsexekvering.

Lägg medvetet till längre indata och uppföljande turer. Håll dessa fall namngivna i rapporten istället för att blanda dem i ett obegripligt genomsnitt. Om ett test avslutas tidigt, registrera varför det stoppades och vad som återstod ofärdigt. Ett resultat är lättare att tolka när utvärderaren kan skilja en slutförd uppgift från ett delvis svar som råkade komma snabbt.

Behåll jämförelsevillkoren kopplade

MLCommons skiljer mellan Closed och Open divisioner samt systemtillgänglighetskategorier. Dess resultatsidor länkar också till en ändringslogg eftersom publicerade resultat kan ändras eller ogiltigförklaras i efterhand.[3] En upphandlingspost bör därför bevara det exakta resultat som konsulterades och datumet det kontrollerades.

Vårt föreslagna urvalsschema inkluderar benchmarkversion, arbetsbelastning, scenario, systemkonfiguration och rapporterad mätvärde. Lägg till division och tillgänglighetskategori. Om två kandidatresultat skiljer sig i dessa fält, beskriv skillnaden innan de rangordnas. Detta är en disciplin för att tolka bevisen, inte ett påstående att olika system aldrig kan jämföras.

Behåll en separat kolumn för avsedd installation. Den bör beskriva modellen, distributionsarkitekturen och applikationsarbetsbelastningen som organisationen förväntar sig att använda. Där en publicerad konfiguration inte kan reproduceras inom föreslagen budget eller driftmiljö, markera det tydligt. Resultatet kan fortfarande informera en undersökning, men det bör inte tyst bli ett acceptansmål.

Gör benchmarken till en pilotbrief

Det praktiska resultatet är ett avgränsat experiment. Välj en uppgift vars korrekthet kan inspekteras, definiera arbetsbelastningsstegen och ange tidsgränsen. Fråga den kandidatleverantör vilka delar av den föreslagna vägen som de publicerade bevisen täcker. Tilldela återstående frågor till en lokal pilot med namngivna acceptanskriterier.

För Software Tailor är en användbar disussion om distribution börja med den briefen och den avsedda datagränsen. Ta med representativa indata som kan delas enligt organisationens regler, eller fabricerade motsvarigheter som tränar samma arbetsflöde. Håll affärsacceptans, säkerhetskontroller och uppmätt prestanda som separata fynd.

En benchmark bör lämna köparen med bättre frågor om den föreslagna installationen. Det slutgiltiga inköpsbeslutet behöver svar för den installationen.

Referenser

[1] MLCommons. MLPerf Inference v6.1 resultatmeddelande. Publicerad 2026-09-16. Hämtad 2026-09-26.

[2] MLCommons. Introduktion av MLPerf End-to-End RAG Inference Benchmark. Publicerad 2026-08-26. Hämtad 2026-09-26.

[3] MLCommons. MLPerf Inference: Datacenter. Aktuella resultat och metodöversikt. Hämtad 2026-09-26.

Relaterade artiklar

Get it from Microsoft