Mål fire ulike latenssignaler
Et enkelt latensnummer skjuler hvor brukerne faktisk venter. Strømmet chat kan oppleves raskt med lav TTFT selv når den fullstendige fullføringen tar lengre tid, mens batch-uttrekk kanskje bare bryr seg om ende-til-ende-varighet.
- Tid til første token: fra starten av forespørselen til første strømmede token.
- Genereringsgjennomstrømning: utdata-tokens delt på genereringstid.
- Ende-til-ende-varighet: fra starten av forespørselen til ferdig svar.
- Pålitelighet: vellykkede svar delt på totale forsøk.
Kontroller benchmark-arbeidslasten
Bruk et fast promptsett som representerer den tiltenkte arbeidslasten. Registrer modell-ID, leverandørrute, region, forespørselsparametere, input-tokens og ønsket utdata-lengde.
- Kjør oppvarmingsforespørsler før du registrerer målingene.
- Randomiser rekkefølgen på leverandører for å redusere skjevhet knyttet til tidspunkt på døgnet.
- Gjenta tester i mer enn ett trafikkvindu.
- Hold strømmede og ikke-strømmede resultater adskilt.
Bruk fordelinger, ikke et skjermbilde av en toppliste
Rapporter median, p90 og p95 med utvalgsstørrelse. En rute med raskest median, men hyppige ekstreme forsinkelser, kan gi en dårligere produksjonsopplevelse enn en litt tregere, men mer stabil rute.
{
"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
}Verdiene ovenfor er et illustrativt rapporteringsformat, ikke et levende CometAPI-benchmarkresultat.
Publiser metodikken med hver rapport
En benchmark er bare nyttig når leseren kan forstå hva som ble målt og gjenskape tilnærmingen. Ta med begrensninger og forklar om leverandørruten var fastlåst eller automatisk valgt.