วัดสัญญาณเวลาแฝงที่แตกต่างกันสี่ประเภท
ตัวเลขเวลาแฝงเพียงค่าเดียวอาจซ่อนจุดที่ผู้ใช้ต้องรอ การสนทนาแบบสตรีมมิงอาจให้ความรู้สึกว่ารวดเร็วเมื่อมี TTFT ต่ำ แม้ว่าการสร้างผลลัพธ์ทั้งหมดจะใช้เวลานานกว่า ขณะที่การดึงข้อมูลแบบแบตช์อาจให้ความสำคัญเฉพาะระยะเวลาตั้งแต่ต้นจนจบ
- เวลาไปยังโทเคนแรก: ตั้งแต่เริ่มคำขอจนถึงโทเคนแรกที่สตรีมมา
- ปริมาณงานการสร้างผลลัพธ์: โทเคนเอาต์พุตหารด้วยเวลาที่ใช้สร้างผลลัพธ์
- ระยะเวลาตั้งแต่ต้นจนจบ: ตั้งแต่เริ่มคำขอจนถึงการตอบกลับที่เสร็จสมบูรณ์
- ความน่าเชื่อถือ: จำนวนการตอบกลับที่สำเร็จหารด้วยจำนวนครั้งที่พยายามทั้งหมด
ควบคุมเวิร์กโหลดของการทดสอบประสิทธิภาพ
ใช้ชุดพรอมต์แบบคงที่ที่สะท้อนเวิร์กโหลดเป้าหมาย บันทึก ID ของโมเดล เส้นทางของผู้ให้บริการ ภูมิภาค พารามิเตอร์คำขอ โทเคนอินพุต และความยาวเอาต์พุตที่ร้องขอ
- ส่งคำขอวอร์มอัปก่อนเริ่มบันทึกผลการวัด
- สุ่มลำดับผู้ให้บริการเพื่อลดอคติจากช่วงเวลาของวัน
- ทดสอบซ้ำในช่วงเวลาที่มีทราฟฟิกมากกว่าหนึ่งช่วง
- แยกผลลัพธ์แบบสตรีมมิงและไม่ใช่แบบสตรีมมิงออกจากกัน
ใช้การกระจายของข้อมูล ไม่ใช่ภาพหน้าจอลีดเดอร์บอร์ด
รายงานค่ามัธยฐาน ค่า 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
เผยแพร่ระเบียบวิธีพร้อมกับทุกรายงาน
การทดสอบประสิทธิภาพจะมีประโยชน์ก็ต่อเมื่อผู้อ่านเข้าใจสิ่งที่วัดและสามารถทำซ้ำแนวทางดังกล่าวได้ ให้ระบุข้อจำกัด และอธิบายว่าเส้นทางของผู้ให้บริการถูกกำหนดตายตัวหรือเลือกโดยอัตโนมัติ