Dört farklı gecikme sinyalini ölçün
Tek bir gecikme değeri, kullanıcıların nerede beklediğini gizler. Streaming chat, tam tamamlanma daha uzun sürse bile düşük bir TTFT ile hızlı hissedilebilir; buna karşılık batch çıkarım için yalnızca uçtan uca süre önemli olabilir.
- İlk tokene kadar geçen süre: isteğin başlangıcından ilk streaming token'a kadar.
- Üretim throughput'u: çıktı token'larının üretim süresine bölünmesi.
- Uçtan uca süre: isteğin başlangıcından tamamlanmış yanıtın alınmasına kadar.
- Güvenilirlik: başarılı yanıtların toplam deneme sayısına bölünmesi.
Benchmark iş yükünü kontrol edin
Amaçlanan iş yükünü temsil eden sabit bir prompt seti kullanın. Model ID, sağlayıcı rotası, bölge, istek parametreleri, giriş token sayısı ve istenen çıktı uzunluğunu kaydedin.
- Ölçümleri kaydetmeden önce ısınma istekleri çalıştırın.
- Günün saatine bağlı yanlılığı azaltmak için sağlayıcı sırasını rastgeleleştirin.
- Testleri birden fazla trafik penceresi sırasında tekrarlayın.
- Streaming ve streaming olmayan sonuçları ayrı tutun.
Leaderboard ekran görüntüsü değil, dağılımları kullanın
Örneklem büyüklüğüyle birlikte medyan, p90 ve p95 değerlerini raporlayın. En hızlı medyana sahip ancak sık görülen aşırı gecikmeleri olan bir rota, biraz daha yavaş ama daha kararlı bir rotadan daha kötü bir production deneyimi sunabilir.
{
"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
}Yukarıdaki değerler, canlı bir CometAPI benchmark sonucu değil, örnek bir raporlama formatıdır.
Her raporla birlikte yöntemi yayınlayın
Bir benchmark ancak okur neyin ölçüldüğünü anlayabiliyor ve yaklaşımı yeniden üretebiliyorsa faydalıdır. Sınırlamaları ekleyin ve sağlayıcı rotasının sabitlenmiş mi yoksa otomatik seçilmiş mi olduğunu açıklayın.