16 września 2026 MLCommons opublikowało wyniki MLPerf Inference w wersji 6.1 z nowymi testami end-to-end dla retrieval-augmented generation oraz edge agentic inference.[1] Dla prywatnego nabywcy AI istotnym rozwojem jest szersza jednostka pomiaru: dowody dotyczące workflow mogą odpowiedzieć na pytania, które pozostawia krótki test odpowiedzi modelu. Nasza rekomendacja to wykorzystanie tych wyników do kształtowania pilotażu, a następnie osobne mierzenie faktycznego wdrożenia.

Ten artykuł odzwierciedla materiał dostępny na dzień 26 września. Nie raportuje zgłoszenia benchmarku Software Tailor ani nie twierdzi, że wdrożenie AI Server odtworzy opublikowany wynik.

Przeczytaj obciążenie zanim porównasz wynik

Wydanie opisuje pracę RAG obejmującą retrieval i generację oraz obciążenie edge agentic z powtarzanymi turami i rosnącą historią.[1] To przydatne rozróżnienia dla nabywców. Asystent dokumentów i workflow kodowania mogą oba wywoływać model językowy, ale ich otoczenie zasługuje na osobne badanie.

Rozpocznij porównanie od rozpatrywanej operacji biznesowej. Nazwij dane wejściowe, oczekiwany wynik i punkt, w którym operacja jest zakończona. Odpowiedź dokumentowa może być ukończona dopiero, gdy cytowane fragmenty można otworzyć. Zadanie agenta może wymagać zweryfikowanego wyniku narzędzia, zanim odpowiedź będzie użyteczna. To proponowane granice akceptacji, a nie dodatkowe wymagania narzucone przez MLPerf.

Umieść granicę benchmarku obok tego opisu. Oznacz każdy etap, który obejmuje wynik, oraz każdy etap należący do proponowanej aplikacji. Widoczna luka jest przydatna: identyfikuje pracę, którą pilot musi zmierzyć. Ukrycie luki w pojedynczym wyniku nagłówkowym usuwa powód przeprowadzania porównania.

Oddziel przygotowanie korpusu od odpowiadania na pytanie

Sierpniowe wprowadzenie MLCommons do benchmarku RAG rozróżnia pipeline ingestujący tworzący bazę wektorową od pipeline odpowiadającego na pytania działającego na niej. Ten drugi może powtarzać retrieval i rozumowanie przez wiele kroków.[2] To sprawia, że praca przygotowawcza jest widoczna obok pracy odpowiadania.

Dla organizacji oceniającej własny zbiór dokumentów, nasz sugerowany pilot ma dwa zapisy. Jeden opisuje przygotowanie określonego zbioru do użycia. Drugi opisuje odpowiadanie na ustalony zestaw pytań wobec tego zbioru. Zachowaj wersje dokumentów i ustawienia przygotowania przy obu zapisach, aby odpowiedzi można było odnieść do tego samego punktu startowego.

Następnie dodaj kontrolowaną aktualizację dokumentów. Obserwuj, kiedy zmiana staje się dostępna dla ścieżki odpowiadania na pytania i co użytkownik widzi podczas przejścia. Traktuj to jako test aplikacji z własnym wynikiem. Wynik ingestu dla zewnętrznego benchmarku nie ustanawia obietnicy aktualizacji dla innego magazynu dokumentów.

To rozróżnienie jest szczególnie przydatne, gdy dział zakupów wymaga jednego zobowiązania dotyczącego czasu odpowiedzi. Zespół może określić, czy zobowiązanie zaczyna się od już przygotowanego zbioru, czy obejmuje uczynienie nowych dokumentów przeszukiwalnymi. Artykuł o planowaniu pojemności rozwija tę różnicę w decyzję biznesową.

Traktuj sekwencję agenta jako sekwencję

Szybka pierwsza odpowiedź to niepełne kryterium akceptacji dla aplikacji, która będzie wielokrotnie sprawdzać dowody i wywoływać narzędzia. Nasza proponowana ocena utrzymuje pełne zadanie widoczne. Zarejestruj kolejne żądania, dozwolone operacje i ostateczny wynik, a następnie sprawdź, gdzie aplikacja czekała lub potrzebowała interwencji.

Użyj zadania o znanym wyniku przed dodaniem pracy o otwartym charakterze. Mały, sztucznie stworzony inwentarz wystarczy, aby ustalić, czy agent prosi o zamierzony przedmiot, otrzymuje poprawny wynik i przenosi go do swojej kolejnej odpowiedzi. Ten Procedura integracji AI Server używa tego przykładu do oddzielenia sprawdzania połączenia od wykonywania narzędzi.

Dodawaj dłuższe dane wejściowe i kolejne tury celowo. Zachowaj te przypadki nazwane w raporcie zamiast mieszać je w niewyjaśnioną średnią. Jeśli test kończy się wcześniej, zanotuj, dlaczego się zatrzymał i co pozostało niedokończone. Wynik jest łatwiejszy do interpretacji, gdy oceniający może odróżnić ukończone zadanie od częściowej odpowiedzi, która przypadkowo nadeszła szybko.

Zachowaj warunki porównania

MLCommons rozróżnia działy Zamknięte i Otwarte oraz kategorie dostępności systemu. Jego strony z wynikami zawierają również link do dziennika zmian, ponieważ opublikowane wyniki mogą być później modyfikowane lub unieważniane.[3] Rekord zakupu powinien zatem zachować dokładny wynik, który był konsultowany, oraz datę jego sprawdzenia.

Nasza proponowana karta krótkiej listy zawiera wersję benchmarku, obciążenie, scenariusz, konfigurację systemu i zgłoszoną metrykę. Dodaj dział i kategorię dostępności. Jeśli dwa kandydackie wyniki różnią się w tych polach, opisz różnicę przed ich oceną. To dyscyplina interpretacji dowodów, a nie twierdzenie, że różne systemy nigdy nie mogą być porównywane.

Zachowaj osobną kolumnę dla zamierzonej instalacji. Powinna opisywać model, topologię wdrożenia i obciążenie aplikacji, które organizacja zamierza używać. Gdy opublikowana konfiguracja nie może być odtworzona w proponowanym budżecie lub środowisku operacyjnym, zaznacz to wyraźnie. Wynik może nadal informować badanie, ale nie powinien cicho stać się celem akceptacji.

Przekształć benchmark w brief pilotażowy

Praktycznym wynikiem jest ograniczony eksperyment. Wybierz zadanie, którego poprawność można sprawdzić, zdefiniuj etapy obciążenia i określ granicę czasową. Zapytaj kandydata dostawcę, które części proponowanej ścieżki obejmują opublikowane dowody. Przypisz pozostałe pytania do lokalnego pilota z nazwanymi kryteriami akceptacji.

Dla Software Tailor przydatna dyskusja o wdrożeniu zaczyna się od tego briefu i zamierzonej granicy danych. Przynieś reprezentatywne dane wejściowe, które można udostępnić zgodnie z zasadami organizacji, lub sztuczne odpowiedniki, które ćwiczą ten sam workflow. Zachowaj akceptację biznesową, kontrole bezpieczeństwa i zmierzoną wydajność jako osobne ustalenia.

Benchmark powinien pozostawić kupującego z lepszymi pytaniami dotyczącymi proponowanej instalacji. Ostateczna decyzja zakupowa wymaga odpowiedzi dla tej instalacji.

Bibliografia

[1] MLCommons. Ogłoszenie wyników MLPerf Inference v6.1. Opublikowano 16.09.2026. Dostęp 26.09.2026.

[2] MLCommons. Wprowadzenie do benchmarku MLPerf End-to-End RAG Inference. Opublikowano 26.08.2026. Dostęp 26.09.2026.

[3] MLCommons. MLPerf Inference: Centrum danych. Aktualne wyniki i przegląd metodologii. Dostęp 26.09.2026.

Powiązane artykuły

Get it from Microsoft