Aynı model, farklı sağlayıcılar: Kimi K2'nin tool-call doğruluğu yüzde 84,63 ile 100 arasında değişiyor

Aynı ağırlıklar, on altı puanlık fark

Moonshot'un açık ağırlıklı K2 modelinin tool calling konusunda zayıf olduğu yönündeki haberler dolaşmaya başlayınca şirket, sorunun modelde mi yoksa dağıtımlarda mı olduğunu anlamak için bir benchmark geliştirdi. Elde edilen veriler üzerine yapılan ve Moonshot'un K2 Vendor Verifier deposunda yayımlanan dev.to analizine göre cevap büyük ölçüde dağıtımlardı.

Test aracı, farklı inference sağlayıcılarında barındırılan aynı model ağırlıklarına aynı 4.000 isteği gönderiyor ve her yanıtı, referans olarak Moonshot'un kendi API'sine göre puanlıyor. Sıcaklık 1.0'daki Kimi K2 Thinking'de Moonshot'un resmi endpoint'i ve Fireworks kusursuz biçimde şema geçerli tool call döndürürken, Chutes yüzde 83,05 ve Together yüzde 84,63 elde etti — aynı ağırlıklarda on altı puanlık bir fark. Eski K2 0905 sürümünde ise fark yaklaşık 28 puana çıkıyor ve dağıtımların bir kümesi yüzde 72 ile 76 arasında yer alıyor.

dev.to yazısının çerçevesiyle altta yatan sorun dağıtımın kendisi: ağırlıklar ne kadar açık biçimde dolaşırsa, o kadar fazla serving stack'ten geçiyor ve dışarıdan bakıldığında bir model kusuru mühendislik sapmasından ayırt edilemiyor. Kullanıcılar her durumda modeli suçluyor.

Farklı hataları yakalayan iki metrik

KVV iki davranışı ayrıştırıyor. Tool-call F1, bir dağıtımın resmi API ile aynı anlarda tool çağırmaya karar verip vermediğini soruyor ve finish reason'lardan türetiliyor. Şema doğruluğu ise yalnızca zaten bir tool call yapmış yanıtlara bakıyor ve argümanların JSON şemasına göre doğrulanıp doğrulanmadığını kontrol ediyor.

Bir dağıtım birini geçip diğerini başarısız olabilir. dev.to yazısı K2 0905 tablosunda Groq örneğine işaret ediyor: yüzde 100 şema doğruluğunun yanında yüzde 69,52'lik bir trigger F1 var; yani argümanlar kendi başına temizken tool call'lar yanlış anlarda tetikleniyor. Nebius aynı deseni yüzde 84,47 şema doğruluğu ve yüzde 50,60 F1 ile gösteriyor.

Şema hataları uygulama koduna kadar ulaşan hatalardır: yanıt bir tool call bildirir, dispatcher argümanları çıkarır ve doğrulama, zorunlu bir özellik eksik olduğu için payload'u reddeder. Bazen bir yeniden deneme durumu kurtarır ama bu bir gidiş-dönüş ve bağlam maliyeti getirir ve model ne olduğunu bilmeden gerçekleşir.

Çağrı başına puanlar oturum boyunca birikir

Yazının en keskin argümanı, şema doğruluğunun agent'lar için yanlış birim olduğudur. Tek bir çağrı p olasılığıyla doğrulanıyorsa, N ardışık çağrıdan oluşan bir oturumun tamamı p üzeri N olasılığıyla doğrulanır. SiliconFlow'un çağrı başına yüzde 98,96'lık puanı 25 çağrılık oturumların yaklaşık yüzde 77'sini sağlam bırakıyor; Together'ın yüzde 84,63'ü ise yalnızca yüzde 1,5'ini bırakıyor.

İki uyarı kabul ediliyor. Sağlayıcılar farklı sayılarda tool call tetiklediği için örnekler mükemmel eşleşmiş değil ve üretimdeki hatalar genellikle ölümcül olmak yerine yeniden deneniyor; bu da bu rakamları öngörülen bir çökme oranı değil, oturum başarısının alt sınırı yapıyor. Her durumda, çağrı başına küçük farklar tekrar altında büyüyor.

Sağlayıcı puanları markaya değil yapılandırmaya aittir

DeepInfra, sıcaklık 0.6'da k2-0905-preview sunarken yüzde 100 aldı ama sıcaklık 1.0'daki k2-thinking'de yüzde 86,91 aldı. Together bir tabloda yüzde 71,96, diğerinde yüzde 84,63 görünüyor. Bir puan, model sürümü, decoding parametreleri ve serving stack'inin birleşiminin bir özelliğidir; bir sağlayıcı gerçeği olarak ileriye taşıyabileceğiniz bir şey değil.

Moonshot'un kendi düzeltmeleri dağıtım tarafındaydı: thinking modunda sıcaklık 1.0 ve top-p 0.95 zorunlu kılınması ve thinking içeriğinin API'ye geri geçirilmesinin gerektirilmesi. Depo ayrıca Moonshot'un API'sinin otomatik olarak yeniden yazdığı ama diğer sağlayıcıların yazmayabileceği bir tool-call ID formatı belirtiyor ve sağlayıcılara, prompt'lara güvenmek yerine şema zorlaması için guided decoding eklemelerini öneriyor; vLLM v0.11.0 ve SGLang v0.5.3rc0 veya daha yeni sürümlere işaret ediyor.

Yönlendirme bir değişken daha ekliyor. OpenRouter'un varsayılanı, fallback'ler etkin biçimde fiyat tabanlı yük dengelemesi; bu yüzden serving endpoint'i, istemci tarafında herhangi bir yapılandırma değişikliği olmadan çalıştırmalar arasında değişebilir. Yazı, değerlendirme çalıştırmaları için bir sağlayıcının sabitlenmesini öneriyor; örneğin fallback'ler devre dışıyken bir sağlayıcı izin listesi ayarlayarak.

Neden önemli

Agent geliştiren herkes için bu, sağlayıcı seçimini yalnızca maliyet veya gecikme kararı olmaktan çıkarıp bir doğruluk kararı olarak yeniden çerçeveliyor. Testlerde iyi performans gösteren bir model, başka bir yerde sunulduğunda sessizce kötüleşebilir ve sabitlenmemiş bir router'a bağlı bir eval hareketli bir hedefi ölçüyor demektir. Pratik yanıt ucuz: model sürümünü ve decoding parametrelerini sabitleyin, çağrı başına finish reason ve şema doğrulama sonucunu kaydedin, şema doğruluğunu trigger F1 ile birlikte raporlayın ve sağlayıcı veya model her değiştiğinde yeniden çalıştırın. KVV tablosu bir model incelemesi değil, bir dağıtım kontrolü — ama dağıtımlar arasındaki farkın bir agent'ın çalışıp çalışmayacağını belirleyecek kadar geniş olduğunu gösteriyor.