Mål fire forskellige latenstidssignaler
Et enkelt latenstal skjuler, hvor brugerne venter. Streamingchat kan føles hurtig med en lav TTFT, selv når den fulde completion tager længere tid, mens batchudtræk måske kun er afhængigt af end-to-end-varighed.
- Tid til første token: fra forespørgselsstart til første streamede token.
- Genereringsthroughput: output tokens divideret med genereringstid.
- End-to-end-varighed: fra forespørgselsstart til færdigt svar.
- Pålidelighed: succesfulde svar divideret med det samlede antal forsøg.
Kontrollér benchmark-workloaden
Brug et fast prompt-sæt, der repræsenterer den tiltænkte workload. Registrer model-ID, provider-route, region, forespørgselsparametre, input tokens og den ønskede outputlængde.
- Kør opvarmningsforespørgsler, før målingerne registreres.
- Tilfældiggør rækkefølgen af udbydere for at reducere skævhed fra tidspunkt på dagen.
- Gentag tests i mere end ét trafikvindue.
- Hold streaming- og non-streaming-resultater adskilt.
Brug fordelinger, ikke et leaderboard-screenshot
Rapportér median, p90 og p95-værdier sammen med stikprøvestørrelsen. En route med den hurtigste median, men hyppige ekstreme forsinkelser, kan give en dårligere produktionsoplevelse end en lidt langsommere, men mere stabil route.
{
"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
}Værdierne ovenfor er et illustrativt rapporteringsformat, ikke et live CometAPI benchmark-resultat.
Offentliggør metode sammen med hver rapport
En benchmark er kun nyttig, når læseren kan forstå, hvad der blev målt, og kan reproducere metoden. Medtag begrænsninger, og forklar, om provider-route var fastlåst eller automatisk valgt.
