Misura quattro diversi segnali di latenza
Un singolo valore di latenza nasconde dove gli utenti stanno aspettando. Una chat in streaming può sembrare veloce con un TTFT basso anche quando il completamento totale richiede più tempo, mentre un'estrazione batch può considerare solo la durata end-to-end.
- Time to first token: dall'avvio della richiesta al primo token in streaming.
- Throughput di generazione: token di output divisi per il tempo di generazione.
- Durata end-to-end: dall'avvio della richiesta alla risposta completata.
- Affidabilità: risposte riuscite divise per il totale dei tentativi.
Controlla il workload del benchmark
Usa un set di prompt fisso che rappresenti il workload previsto. Registra l'ID del modello, la route del provider, la regione, i parametri della richiesta, i token di input e la lunghezza di output richiesta.
- Esegui richieste di warm-up prima di registrare le misurazioni.
- Randomizza l'ordine dei provider per ridurre il bias legato all'ora del giorno.
- Ripeti i test durante più di una finestra di traffico.
- Mantieni separati i risultati in streaming e non in streaming.
Usa distribuzioni, non uno screenshot della classifica
Riporta valori mediani, p90 e p95 con la dimensione del campione. Una route con la mediana più rapida ma con ritardi estremi frequenti può offrire un'esperienza di produzione peggiore rispetto a una route leggermente più lenta ma più stabile.
{
"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
}I valori sopra sono un formato di reporting illustrativo, non un risultato di benchmark live di CometAPI.
Pubblica la metodologia con ogni report
Un benchmark è utile solo quando il lettore può capire cosa è stato misurato e riprodurre l'approccio. Includi i limiti e spiega se la route del provider era fissata o selezionata automaticamente.