Am 16. September 2026 veröffentlichte MLCommons die Ergebnisse von MLPerf Inference v6.1 mit neuen End-to-End-Tests für retrieval-augmentierte Generierung und agentische Inferenz am Edge.[1] Für einen privaten KI-Einkäufer ist die nützliche Entwicklung die breitere Maßeinheit: Erkenntnisse über einen Workflow können Fragen beantworten, die ein kurzer Modell-Antwort-Test offenlässt. Unsere Empfehlung ist, diese Ergebnisse zur Gestaltung eines Pilotprojekts zu nutzen und dann die tatsächliche Implementierung separat zu messen.

Dieser Artikel basiert auf dem Material, das am 26. September verfügbar war. Er berichtet nicht über eine Benchmark-Einreichung von Software Tailor und erhebt keinen Anspruch darauf, dass ein Bereitstellung des AI Server wird ein veröffentlichtes Ergebnis reproduzieren.

Lesen Sie die Arbeitslast, bevor Sie die Punktzahl vergleichen

Die Veröffentlichung beschreibt RAG-Arbeiten, die Retrieval und Generierung umfassen, sowie eine Edge-Agent-Workload mit wiederholten Interaktionen und wachsendem Verlauf.[1] Diese Unterscheidungen sind für Käufer nützlich. Ein Dokumentenassistent und ein Coding-Workflow können beide ein Sprachmodell aufrufen, aber ihre jeweilige Arbeitsumgebung verdient eine separate Untersuchung.

Beginnen Sie einen Vergleich mit dem betrachteten Geschäftsprozess. Nennen Sie die Eingabe, die erwartete Ausgabe und den Punkt, an dem der Vorgang abgeschlossen ist. Eine Dokumentantwort kann nur dann als abgeschlossen gelten, wenn die zitierten Passagen geöffnet werden können. Eine Agentenaufgabe kann ein verifiziertes Werkzeugergebnis erfordern, bevor ihre Antwort verwendbar ist. Dies sind vorgeschlagene Akzeptanzgrenzen, keine zusätzlichen Anforderungen, die von MLPerf auferlegt werden.

Setzen Sie die Grenze des Benchmarks neben diese Beschreibung. Markieren Sie jede Phase, die das Ergebnis abdeckt, und jede Phase, die zur vorgeschlagenen Anwendung gehört. Eine sichtbare Lücke ist nützlich: Sie zeigt die Arbeit auf, die der Pilot messen muss. Das Verbergen der Lücke in einem einzigen Überschriftsergebnis nimmt den Grund für den Vergleich weg.

Trennung der Vorbereitung des Korpus von der Beantwortung einer Frage

Die im August von MLCommons vorgestellte RAG-Benchmark unterscheidet eine Ingestionspipeline, die eine Vektordatenbank erstellt, von einer Frage-Antwort-Pipeline, die darauf arbeitet. Letztere kann Abruf und Schlussfolgerung über mehrere Schritte hinweg wiederholen. Dies macht die Vorbereitungsarbeit neben der Antwortarbeit sichtbar.

Für eine Organisation, die ihre eigene Dokumentensammlung bewertet, enthält unser vorgeschlagener Pilot zwei Datensätze. Einer beschreibt die Vorbereitung einer definierten Sammlung zur Nutzung. Der andere beschreibt das Beantworten eines festen Satzes von Fragen zu dieser Sammlung. Bewahren Sie die Dokumentversionen und Vorbereitungseinstellungen bei beiden Datensätzen auf, damit die Antworten auf denselben Ausgangspunkt zurückverfolgt werden können.

Fügen Sie dann ein kontrolliertes Dokumenten-Update hinzu. Beobachten Sie, wann die Änderung im Frage-Antwort-Pfad verfügbar wird und was der Benutzer während der Übergangsphase sieht. Behandeln Sie dies als einen Anwendungstest mit eigenem Ergebnis. Ein Ingestion-Ergebnis für einen externen Benchmark begründet kein Update-Versprechen für einen anderen Dokumentenspeicher.

Diese Unterscheidung ist besonders nützlich, wenn die Beschaffung eine einzige Antwortzeitgarantie verlangt. Das Team kann angeben, ob die Garantie mit einer bereits vorbereiteten Sammlung beginnt oder die Erstellung neuer durchsuchbarer Dokumente einschließt. Kapazitätsplanung Artikel entwickelt diese Unterscheidung zu einer Geschäftsentscheidung weiter.

Behandle eine Agentenfolge als eine Sequenz

Eine schnelle erste Antwort ist ein unvollständiges Akzeptanzkriterium für eine Anwendung, die wiederholt Beweise prüft und Werkzeuge aufruft. Unsere vorgeschlagene Bewertung hält die gesamte Aufgabe sichtbar. Zeichne die aufeinanderfolgenden Anfragen, die erlaubten Operationen und das Endergebnis auf und untersuche dann, wo die Anwendung wartete oder Eingriffe benötigte.

Verwende eine Aufgabe mit bekanntem Ergebnis, bevor offene Arbeiten hinzugefügt werden. Ein kleiner, künstlich erzeugter Bestand reicht aus, um festzustellen, ob ein Agent nach dem vorgesehenen Artikel fragt, das korrekte Ergebnis erhält und dieses in seine nächste Antwort einfließen lässt. Das AI Server-Integrationsverfahren nutzt dieses Beispiel, um Verbindungsprüfungen von der Ausführung von Werkzeugen zu trennen.

Füge längere Eingaben und Folgeaktionen gezielt hinzu. Benenne diese Fälle im Bericht, anstatt sie in einem unerklärten Durchschnitt zu vermischen. Wenn ein Test vorzeitig endet, zeichne auf, warum er gestoppt wurde und was unvollendet blieb. Ein Ergebnis ist leichter zu interpretieren, wenn der Bewertende eine abgeschlossene Aufgabe von einer Teilantwort unterscheiden kann, die zufällig schnell eingetroffen ist.

Behalte die Vergleichsbedingungen bei

MLCommons unterscheidet zwischen Closed- und Open-Divisionen sowie Systemverfügbarkeitskategorien. Die Ergebnisseiten verlinken auch auf ein Änderungsprotokoll, da veröffentlichte Ergebnisse später modifiziert oder ungültig gemacht werden können.[3] Ein Beschaffungsnachweis sollte daher das genau konsultierte Ergebnis und das Datum der Überprüfung bewahren.

Unser vorgeschlagenes Shortlist-Blatt enthält die Benchmark-Version, Arbeitslast, Szenario, Systemkonfiguration und gemessene Metrik. Füge die Division und Verfügbarkeitskategorie hinzu. Wenn sich zwei Kandidatenergebnisse in diesen Feldern unterscheiden, beschreibe den Unterschied, bevor du sie bewertest. Dies ist eine Disziplin zur Interpretation der Beweise, keine Behauptung, dass unterschiedliche Systeme niemals verglichen werden können.

Behalte eine separate Spalte für die vorgesehene Installation bei. Sie sollte das Modell, die Bereitstellungstopologie und die Arbeitslast der Anwendung beschreiben, die die Organisation zu verwenden erwartet. Wenn eine veröffentlichte Konfiguration innerhalb des vorgeschlagenen Budgets oder der Betriebsumgebung nicht reproduziert werden kann, markiere dies deutlich. Das Ergebnis kann dennoch eine Untersuchung informieren, sollte aber nicht stillschweigend zum Akzeptanzziel werden.

Verwandle den Benchmark in ein Pilotbriefing

Das praktische Ergebnis ist ein begrenztes Experiment. Wähle eine Aufgabe, deren Korrektheit überprüfbar ist, definiere die Arbeitslastphasen und gib die Zeitgrenze an. Frage den Kandidatenlieferanten, welche Teile des vorgeschlagenen Pfads durch die veröffentlichten Beweise abgedeckt sind. Weise die verbleibenden Fragen einem lokalen Pilotprojekt mit benannten Akzeptanzkriterien zu.

Für Software Tailor ist eine nützliche Bereitstellungsdiskussion beginnt mit diesem Briefing und der vorgesehenen Datenbegrenzung. Bringe repräsentative Eingaben mit, die unter den Regeln der Organisation geteilt werden können, oder künstlich erzeugte Äquivalente, die denselben Arbeitsablauf durchlaufen. Halte Geschäftsakzeptanz, Sicherheitsprüfungen und gemessene Leistung als separate Erkenntnisse fest.

Ein Benchmark sollte den Käufer mit besseren Fragen zur vorgeschlagenen Installation zurücklassen. Die endgültige Kaufentscheidung benötigt Antworten für diese Installation.

Quellen

[1] MLCommons. MLPerf Inference v6.1 Ergebnisankündigung. Veröffentlicht am 16.09.2026. Zugriff am 26.09.2026.

[2] MLCommons. Einführung des MLPerf End-to-End RAG Inference Benchmarks. Veröffentlicht am 26.08.2026. Zugriff am 26.09.2026.

[3] MLCommons. MLPerf Inference: Rechenzentrum. Aktuelle Ergebnisse und Methodikübersicht. Zugriff am 26.09.2026.

Verwandte Artikel

Get it from Microsoft