چار مختلف latency signals ناپیں
ایک واحد latency number یہ چھپا دیتا ہے کہ users کہاں انتظار کر رہے ہیں۔ Streaming chat کم TTFT کے ساتھ تیز محسوس ہو سکتی ہے، چاہے مکمل completion میں زیادہ وقت لگے، جبکہ batch extraction کو صرف end-to-end duration درکار ہو سکتی ہے۔
- Time to first token: request start سے پہلے streamed token تک کا وقت۔
- Generation throughput: output tokens کو generation time سے تقسیم کیا جاتا ہے۔
- End-to-end duration: request start سے completed response تک کا وقت۔
- Reliability: successful responses کو total attempts سے تقسیم کیا جاتا ہے۔
Benchmark workload کو کنٹرول کریں
ایک fixed prompt set استعمال کریں جو مطلوبہ workload کی نمائندگی کرے۔ model ID، provider route، region، request parameters، input tokens اور requested output length ریکارڈ کریں۔
- Measurements ریکارڈ کرنے سے پہلے warm-up requests چلائیں۔
- وقتِ روزانہ کے bias کو کم کرنے کے لیے provider order کو randomize کریں۔
- ایک سے زیادہ traffic window کے دوران tests دہرائیں۔
- Streaming اور non-streaming نتائج کو الگ رکھیں۔
Leaderboard screenshot کے بجائے distributions استعمال کریں
Sample size کے ساتھ median، p90 اور p95 values رپورٹ کریں۔ جس route کا median سب سے تیز ہو لیکن جس میں شدید delays بار بار آئیں، وہ production میں ایک قدرے سست مگر زیادہ stable 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
}اوپر دی گئی values reporting format کی ایک illustrative مثال ہیں، کوئی live CometAPI benchmark result نہیں۔
ہر report کے ساتھ methodology شائع کریں
Benchmark تبھی مفید ہے جب reader سمجھ سکے کہ کیا measure کیا گیا تھا اور approach دوبارہ reproduce کر سکے۔ limitations شامل کریں اور واضح کریں کہ provider route pinned تھا یا automatically selected تھا۔