Jak mierzyć opóźnienie Mercury 3 poza liczbą tokenów na sekundę

Mierz działanie Mercury 3 od rozpoczęcia zadania do chwili, gdy wynik nadaje się do użycia. Rejestruj czas do pierwszej odpowiedzi, czas do pełnej odpowiedzi oraz całkowity czas, łącznie z użyciem narzędzi. Liczba tokenów na sekundę opisuje tylko część procesu generowania; może nie uwzględniać oczekiwania na pojawienie się wyniku ani pracy potrzebnej po zakończeniu działania modelu.

Użyj jednego niewielkiego zestawu testowego z jasno określonymi kryteriami akceptacji i zapisuj prompt, pliki wejściowe, środowisko narzędzi oraz ustawienia modelu. To wystarczy, by ustalić podstawowe zachowanie i wykryć wąskie gardła. Rozszerzaj testy tylko wtedy, gdy do wyjaśnienia problemu lub podjęcia decyzji między zbliżonymi opcjami potrzebujesz więcej dowodów.

Jakie znaczniki czasu należy zbierać?

Do pomiaru czasu trwania używaj monotonicznego zegara po stronie klienta i odnotuj, czy przesyłanie strumieniowe jest włączone. Jeśli porównujesz dostawców, zachowaj takie same warunki nawiązywania połączenia i ponownego użycia połączenia. Nie wyciągaj wniosków o czasie do pierwszego tokenu na podstawie żądania bez przesyłania strumieniowego.

Jak wybrać uczciwy prompt testowy?

Wybierz rzeczywiste, jasno określone zadanie: wyodrębnienie wskazanych pól z zatwierdzonego dokumentu lub wprowadzenie niewielkiej zmiany w skopiowanym repozytorium. We wszystkich próbach używaj identycznego wejścia i wymagaj identycznego wyniku. Zapisuj identyfikator modelu, ustawienie poziomu wysiłku i limit wyjściowy, aby wyniki można było właściwie interpretować.

W omówieniu Mercury 3 wyjaśniono, dlaczego deklarowana przez dostawcę przepustowość nie zastępuje pomiaru na poziomie zadania.

Jak nie przypisywać opóźnień po stronie klienta i narzędzi modelowi?

Rejestruj po stronie klienta czas wysłania żądania, pojawienia się pierwszej istotnej treści, zakończenia odpowiedzi, rozpoczęcia i zakończenia każdego wywołania narzędzia oraz akceptacji końcowego artefaktu. Korzystaj konsekwentnie z tej samej metody pomiaru czasu. Renderowanie w przeglądarce, buforowanie przez serwer proxy lub klient, który nie obsługuje przesyłania strumieniowego, mogą ukrywać stopniowe pojawianie się treści, nawet jeśli usługa nadrzędna działa inaczej.

Informacje o modelach i żądaniach określają dostępne ustawienia; to Twoja instrumentacja pokazuje, jak długo rzeczywiście czeka użytkownik.

Jak narzędzia wpływają na wynik?

Oddziel czas oczekiwania na model od czasu wykonywania narzędzi. Powolny odczyt z NAS, nawigacja po stronach lub wyszukiwanie zewnętrzne mogą zdominować zadanie wieloetapowe. Zliczaj ponowne próby, nieprawidłowe argumenty narzędzi i wielokrotne odczyty plików, zamiast pomijać czas zmarnowany na nieudane próby.

Skorzystaj z listy kontrolnej platformy testowej agentów, aby ustalić, który komponent odpowiada za poszczególne opóźnienia. Jeśli wywołanie modelu stanowi niewielką część zadania, poprawa dostępu do pamięci masowej lub projektu zadania może mieć większe znaczenie niż zmiana architektury generowania.

Ile przebiegów potrzebuję?

Jeden przebieg pozwala sprawdzić łączność i oczywiste problemy z poprawnością. Kilka powtarzalnych prób może ujawnić duże, praktyczne różnice, ale nie uzasadnia precyzyjnych twierdzeń o niezawodności ani stabilnych percentyli z ogona rozkładu. Zbieraj więcej obserwacji tylko wtedy, gdy uzasadnia to stawka wdrożenia lub decyzja dotycząca niewielkiej różnicy wydajności.

Zawsze uwzględniaj niepowodzenia. Szybki, udany przebieg wybrany spośród kilku nieudanych prób nie jest reprezentatywnym dowodem. Przewodnik po ukierunkowanym sprawdzaniu przepływu pracy przedstawia lekkie podejście do akceptacji.

Jak raport dotyczący czasu powinien uwzględniać nieudany lub niekompletny przebieg?

Zachowaj czas, który upłynął, i oznacz wynik. Jeśli zadanie przekroczy limit czasu po 30 sekundach, a następnie powiedzie się po 20-sekundowej ponownej próbie, użytkownik czekał co najmniej 50 sekund, zanim mógł sprawdzić wynik. Podanie tylko końcowego przebiegu trwającego 20 sekund ukrywa rzeczywisty koszt. Ten przykład ilustruje obliczenia, a nie zaobserwowaną awarię Mercury.

Nie podawaj stabilnego opóźnienia p95 na podstawie zaledwie kilku obserwacji. Przy zbyt małej liczbie przebiegów percentyl może odzwierciedlać głównie metodę interpolacji, a nie wiarygodne zachowanie w skrajnym ogonie rozkładu. Mały pilotaż może jednak ujawnić oczywisty problem ze zgodnością lub poważne wąskie gardło; napisz po prostu, co dokładnie wykazał.

Skorzystaj z odpowiednio dobranego zestawu testów akceptacyjnych, aby ocenić, czy wynik nadaje się do użytku, oraz z porównania architektur, aby zinterpretować wybór modelu. Jeśli głównym źródłem opóźnień jest wyszukiwanie, zapoznaj się z ograniczeniami i błędami narzędzia wyszukiwania, zamiast bez zastanowienia zwiększać budżet generowania. Praktycznym wynikiem pomiaru czasu jest wskazanie konkretnego wąskiego gardła i kolejnej zmiany, a nie tylko wysoka liczba tokenów na sekundę.

Jakie informacje poza opóźnieniem należy podać?

Podaj, czy wynik przeszedł weryfikację, uwzględnij powiązane opłaty za korzystanie z usługi, wywołania narzędzi i poprawki ręczne. Podaj środowisko i datę. Jeśli podczas uruchomienia przekroczono limit czasu, odnotuj to zamiast przypisywać mu atrakcyjny wynik szybkości.

W przypadku plików NAS przechowuj dane testowe i zaakceptowany wynik w osobnych katalogach. Skorzystaj z porównania architektur, aby zinterpretować wyniki pomiarów, oraz z poradnika przygotowania plików, aby ograniczyć zakres udostępniania danych podczas pilotażu.

Często zadawane pytania

Czy można bezpośrednio porównywać liczbę tokenów na sekundę w przypadku różnych tokenizatorów?

Podchodź do takich danych ostrożnie. Definicje tokenów, treść wyników i warunki pomiaru mogą się różnić w zależności od dostawcy.

Co zrobić, jeśli API nie obsługuje strumieniowania?

Mierz czas uzyskania pełnej odpowiedzi i wykonanie zadania. Nie podawaj czasu do pierwszego tokenu, którego Twój klient nie jest w stanie zaobserwować.

Czy nieudane uruchomienia należy wykluczyć?

Nie. Zapisuj przekroczenia limitu czasu, ponowne próby i odrzucone wyniki, ponieważ wpływają na rzeczywisty czas realizacji i koszt.

Czy przed pilotażem potrzebuję dużego benchmarku?

Nie. Zacznij od małego, reprezentatywnego zadania i rozszerz zakres pomiarów tylko wtedy, gdy wymaga tego istotna niepewność.

Powiązane artykuły

• Mercury 3: dlaczego dyfuzyjne modele językowe są ważne dla szybkich przepływów pracy z AI
• Modele dyfuzyjne a autoregresyjne LLM-y: który lepiej sprawdzi się w Twoim osobistym przepływie pracy z AI?

Źródła

• Ogłoszenie Inception Mercury 3: generowanie dyfuzyjne i deklarowana szybkość
• Informacje o modelu Inception: kontekst, limity generowania i ustawienia żądań

Okładka: Oficjalna grafika z ogłoszeniem Mercury 3. Źródło grafiki.