Mierz cztery różne sygnały opóźnienia
Jedna wartość opóźnienia ukrywa, gdzie użytkownicy czekają. Czat strumieniowy może sprawiać wrażenie szybkiego przy niskim TTFT, nawet jeśli pełne ukończenie trwa dłużej, podczas gdy ekstrakcja wsadowa może interesować wyłącznie czas end-to-end.
- Czas do pierwszego tokenu: od rozpoczęcia żądania do pierwszego przesłanego tokenu.
- Przepustowość generacji: tokeny wyjściowe podzielone przez czas generacji.
- Czas end-to-end: od rozpoczęcia żądania do ukończonej odpowiedzi.
- Niezawodność: liczba udanych odpowiedzi podzielona przez łączną liczbę prób.
Kontroluj obciążenie benchmarku
Użyj stałego zestawu promptów, który reprezentuje docelowe obciążenie. Zapisz identyfikator modelu, trasę dostawcy, region, parametry żądania, tokeny wejściowe i żądaną długość wyjścia.
- Uruchom żądania rozgrzewające przed rozpoczęciem zapisu pomiarów.
- Losuj kolejność dostawców, aby zmniejszyć wpływ pory dnia.
- Powtarzaj testy w więcej niż jednym oknie ruchu.
- Trzymaj wyniki streamingu i bez streamingu osobno.
Używaj rozkładów, a nie zrzutu z rankingu
Raportuj medianę, p90 i p95 wraz z liczebnością próby. Trasa z najszybszą medianą, ale częstymi skrajnymi opóźnieniami może zapewniać gorsze wrażenia produkcyjne niż trasa nieco wolniejsza, ale bardziej stabilna.
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}Powyższe wartości są ilustracyjnym formatem raportowania, a nie bieżącym wynikiem benchmarku CometAPI.
Publikuj metodologię wraz z każdym raportem
Benchmark jest użyteczny tylko wtedy, gdy czytelnik rozumie, co zostało zmierzone, i może odtworzyć podejście. Uwzględnij ograniczenia i wyjaśnij, czy trasa dostawcy była przypięta, czy wybierana automatycznie.