測量四種不同的延遲訊號
單一的延遲數字會掩蓋使用者實際在等待哪一段時間。串流聊天即使完整生成需要更久，只要 TTFT 較低，體感仍可能很快；而批次抽取可能只關心端到端持續時間。
- 首 token 時間：從請求開始到收到第一個串流 token。
- 生成吞吐量：輸出 tokens 除以生成時間。
- 端到端持續時間：從請求開始到回應完成。
- 可靠性：成功回應數除以總嘗試次數。
控制基準工作負載
使用固定的提示詞集合，以代表預期的工作負載。記錄模型 ID、供應商路由、區域、請求參數、輸入 tokens 與要求的輸出長度。
- 在開始記錄測量前先執行暖身請求。
- 隨機化供應商順序，以降低時段偏差。
- 在超過一個流量窗口的時間內重複測試。
- 將串流與非串流結果分開處理。
使用分佈，而不是排行榜截圖
回報中位數、p90 與 p95 值，並附上樣本數。某條路由即使中位數最快，但若經常出現極端延遲，實際上的生產環境體驗可能會比稍慢但更穩定的路由更差。
{
"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
}以上數值僅為示範性的報告格式，不是即時的 CometAPI 基準測試結果。
每份報告都應公開方法
只有當讀者能理解測量了什麼，並且能重現方法時，基準測試才有價值。請包含限制條件，並說明供應商路由是固定選取還是自動選取。