Kimi Tedarikçi Doğrulayıcı - çıkarım sağlayıcılarının doğruluğunu doğrulama

• Kimi Vendor Verifier(KVV), açık kaynak model dağıtımından sonra farklı altyapılarda ortaya çıkan çıkarım uygulama sapmalarını doğrulayan ve böylece modelin kendi sınırlarıyla mühendislik hatalarını ayırt etmeyi sağlayan herkese açık bir araçtır
• Resmi API baz alınarak OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8 sonuçları sunuluyor; ayrıca her değerlendirme için Temperature, TopP, MaxTokens ayarları ve K2VV değerlendirme sonuç dosyaları da birlikte paylaşılıyor
• Toplulukta bildirilen benchmark anormalliklerinin incelenmesi sonucunda bunların önemli bir bölümünün decoding parametrelerinin yanlış kullanımından kaynaklandığı görüldü; Thinking modunda Temperature 1.0 ve TopP 0.95 zorunlu kılındı ve içerik yeniden iletimine yönelik doğrulama uygulandı
• Doğrulama prosedürü, parametre kısıtlarını kontrol eden bir ön doğrulamanın ardından OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench gibi testlerle Vision ön işleme, uzun çıktı üretimi, araç çağrısı ve agentic coding süreçlerini denetleyecek şekilde yapılandırıldı
• Tüm iş akışı, iki adet NVIDIA H20 8-GPU sunucuda sıralı çalıştırma temelinde yaklaşık 15 saat sürüyor; açık leaderboard ve erken erişim sunularak doğruluk öncelikli doğrulamanın yaygınlaştırılması hedefleniyor

---

Güven zincirini (Chain of Trust) yeniden kurmak

• Kimi Vendor Verifier(KVV) kaynağının yayımlanmasıyla birlikte, açık kaynak model kullanıcılarının çıkarım uygulama doğruluğunu doğrulayabilmesi için tasarlandı
• Kimi K2.6 modelinin yayımlanmasıyla aynı anda dağıtıldı; yalnızca modeli yayımlamak yeterli değil, farklı ortamlarda doğru çalışıp çalışmadığını doğrulama süreci de gerekiyor
• Açık kaynak model ekosisteminde ağırlıkların yayımlanması ve dağıtım yollarının çeşitlenmesi arttıkça, kalite kontrolünün sürdürülebilirliğinin düştüğü bir yapı ortaya çıkıyor
• Kullanıcılar modelin kendi performans kusurları ile mühendislik uygulama sapmalarını ayıramazsa, açık kaynak ekosistemine duyulan güven sarsılabilir

Çözüm yaklaşımı

• Tekil anormalliklerden yapısal sorunlara genişleme

  • K2 Thinking yayımlandıktan sonra, topluluktan benchmark puanlarındaki anormal davranışlar hakkında sık sık geri bildirim geldi
  • İnceleme sonucunda birçok vakanın decoding parametrelerinin yanlış kullanımından kaynaklandığı doğrulandı
  • Acil hafifletme önlemi olarak API düzeyinde ilk savunma hattı kuruldu
    • Thinking modunda Temperature=1.0, TopP=0.95 zorunlu kılındı
    • thinking içeriğinin doğru şekilde yeniden iletildiğini kontrol eden zorunlu doğrulama uygulandı
  • Belirli LiveBenchmark değerlendirmelerinde üçüncü taraf API ile resmi API arasında büyük farklar gözlemlendi
  • Çok sayıda altyapı sağlayıcısında yapılan kapsamlı testler, bu farkların yaygın biçimde mevcut olduğunu gösterdi

• Doğrulama prosedürü ve operasyon

  • Resmi API bazlı benchmark sonuçları yayımlandı
    • OCRBench doğruluk 91.0
    • AIME2025 avg@32 98.4
    • MMMU Pro Vision doğruluk 78.8
  • Değerlendirme ayarları da birlikte belirtildi
    • Üçünde de Temperature 1.0, TopP 0.95 kullanıldı
    • MaxTokens değerleri sırasıyla OCRBench için 16384, AIME2025 için 98304, MMMU Pro Vision için 65536
  • Kimi API K2VV değerlendirme sonuçları dosyasına bağlantı verildi; F1 puanı hesaplaması amacı da belirtildi
  • Pre-Verification aşaması işletiliyor
    • temperature, top_p gibi API parametre kısıtlarının doğru şekilde zorlandığı doğrulanıyor
    • Benchmark değerlendirmesi ancak tüm testler geçildikten sonra başlatılıyor
  • OCRBench kullanımı
    • Multimodal pipeline için 5 dakikalık smoke test işlevi görüyor
  • MMMU Pro kullanımı
    • Çeşitli görsel girdileri test ederek Vision girdi ön işlemeyi doğruluyor
  • AIME2025 kullanımı
    • Uzun çıktı stres testi işlevi görüyor
    • Kısa benchmark'larda görünmeyen KV cache hataları ve quantization performans düşüşünü yakalıyor
  • K2VV ToolCall kullanımı
    • Tetikleme tutarlılığını (F1) ve JSON Schema doğruluğunu ölçüyor
    • Ajanlarda araç hataları birikmeden önce erken tespit sağlıyor
  • SWE-Bench kullanımı
    • Uçtan uca agentic coding testi işlevi görüyor
    • sandbox bağımlılığı nedeniyle açık kaynaklaştırılmadı
  • vLLM, SGLang, KTransformers topluluklarıyla birlikte çalışılıyor
  • Sadece semptom tespitiyle yetinilmiyor, kök nedenlerin düzeltilmesi hedefleniyor
  • Dağıtımdan sonra şikayet beklemek yerine altyapı sağlayıcılarına erken erişim yetkisi veriliyor
  • Böylece kullanıcılar sorun yaşamadan önce her sağlayıcının kendi stack'ini doğrulaması amaçlanıyor
  • Tedarikçi sonuçlarına ilişkin açık leaderboard sürekli işletilecek
  • Bu şeffaflık, tedarikçilerin doğruluk önceliğini artıracak şekilde tasarlandı
  • Tüm değerlendirme iş akışının doğrulaması tamamlandı
    • İki adet NVIDIA H20 8-GPU sunucu kullanıldı
    • Sıralı çalıştırmada yaklaşık 15 saat gerekiyor
  • Uzun süreli çıkarım senaryoları için script optimizasyonları uygulandı
    • Streaming inference
    • Otomatik yeniden deneme
    • Checkpoint'ten devam mekanizması dahil
  • Ağırlıklar yayımlandığına göre, bunları doğru çalıştırmaya yönelik bilginin de açık olması gerektiği ilkesi vurgulanıyor
  • Tedarikçi kapsamını genişletme ve daha hafif agentic testler araştırma çalışmaları sürüyor

[ng0301]

Umarım gerçekten iyi sonuçlanır.

[GN⁺]

Hacker News görüşleri

• Bu fikir hoşuma gitti. Çıkarım sağlayıcılarını eski sorunları düzeltmeye zorlamak için oldukça etkili bir sosyal baskı olabilir gibi görünüyor. Örneğin AWS Bedrock, Kimi’nin K2 ve K2.5 model sunum yığınında kritik bir kusura sahip; araç çağrısı göndermesi gereken denemelerin %20~%30’unda hiçbir token çıktısı vermeden konuşmayı sessizce sonlandırıyor. Bu yüzden AWS, Kimi için ciddi bir çıkarım sağlayıcısı olarak fiilen anlamsız hale geliyor ve kullanıcıları benzer ajan iş yüklerinde daha pahalı Anthropic modellerine itiyor gibi görünüyor
  • Bunun yeni bir şey olduğunu sanmıyorum; Kimi’nin zaten aylardır yaptığı bir şey gibi görünüyor. K2 Vendor Verifier, Kimi Vendor Verifier zaten vardı, hatta K2.5 ve K2.6 çıkmadan önce bile
• Benim anladığım tehdit modeli, kazara oluşan performans düşüşünü önlemeye yönelik; kötü niyetli aktörleri kapsıyor gibi görünmüyor. Örneğin şüpheli bir sağlayıcı en yeni ve en iyi modeli çalıştırdığını söyleyip gerçekte daha ucuz ve daha düşük performanslı bir model kullanarak aradaki farkı cebe atıyorsa, bu tür testler çok yardımcı olmayabilir. Test edildiğini fark ederse, Volkswagen emisyon skandalındaki gibi sadece o sırada düzgün çalışacak şekilde ayarlayabilir
  • OpenRouter gibi sağlayıcılar varsayılan olarak en ucuz sağlayıcıyı seçiyor, ama bunun ucuz olmasının nedeni çoğu zaman kalite yerine throughput için aşırı quantization ve tuning yapılmış olması. Bu yüzden bu, kimi’nin ucuz sağlayıcıların model performansını doğru temsil etmeyerek markaya zarar vermesini engelleme girişimi gibi görünüyor
  • Sadece kazara oluşan drift’i yakalamak bile bence çok değerli. Bu neredeyse CI’daki performans regresyon testleri ile aynı fikir ve birinin bilerek sistemi bozacağını varsayarak kullanılmıyor. Genelde amaç, tek bir bağımlılığı güncellediniz ve throughput %15 düştü gibi sıradan sorunları yakalamak. Biri kasıtlı olarak denetimi atlatırsa, bu durum sessizce daha ucuz bir quantization sunmaktan hukuki açıdan da oldukça farklı olur
  • Hem doğru hem değil gibi düşünüyorum. Gerçekten kötü niyetli bir aktörse endişe yerinde. Ama bu mekanizma durumu, "modeli quantize edip bunu bildirmemek açık bir dolandırıcılık sayılmaz" noktasından, "doğrulamayı bir modelle geçip gerçek müşteri isteklerini başka bir modelle işleyen kasıtlı dolandırıcılık" noktasına taşıyor. Sadece ilkini yapmaya gönüllü olan yarı kötü niyetli oyunculardan epey vardır bence
  • Bu tür sistemler için oldukça iyi bir challenge gibi görünüyor. Örneğin fromtier labs’ın yüksek yük altında quantized model sunma örneğini hatırlatıyor
• Bu, bizim benchmark’larımızda da gerçek bir sorundu. Quantization seviyesini belirtmeyen ya da beklenenden daha düşük seviye kullanan OpenRouter sağlayıcılarına dikkat etmek gerekiyor. OpenRouter bununla ilgili ayar seçenekleri sunuyor ama o zaman da seçenekler ciddi şekilde azalabiliyor. Bunun dışında, en iyi sağlayıcıyı kullansanız bile Kimi-K2-thinking benchmark’larımızda biraz hayal kırıklığı yarattı ve yavaştı, ama sıcaklık ve varyasyon açısından ilginç ve faydalıydı. Buna karşılık Kimi K2.6 şu anda yeni açık kaynak lideri gibi görünüyor. Ajan değerlendirmeleri de sürüyor ve one-shot kodlama çıkarımı benchmark’ı zaten hazır
  • OpenRouter’da belirli bir model için daha yüksek kaliteli sağlayıcıları tercih etmeyi sağlayan exacto seçeneği var. Bunu kullanıp fayda gördünüz mü merak ediyorum. Ayrıca Kimi K2’nin hem eğitimde hem çıkarımda int4 kullandığı söyleniyor; ilgili tartışmaya bakınca, farklı gguf üreticilerinin dönüşümü farklı yapıp kaliteyi etkiliyor olabileceğini düşündürüyor
• Yüksek performanslı donanımda 15 saat süren bir testi yeniden üretmek ya da ölçeklemek kolay görünmüyor. Yine de bu, farklı bulut hizmetlerine yayılmış genel bir kaygıya iyi dokunuyor. Ping attığım şeyin gerçekten aldığım şey olmayabileceği asıl mesele
  • Benim yorumuma göre bu testin ilk hedefi kullanıcıdan çok satıcının kendisi. Testin uzun ve kapsamlı olmasının nedeni de satıcıya kendi self-hosting kalitesi konusunda güven vermek diye anladım
  • Önce her satıcı için tüm suite’i bir kez çalıştırıp ardından her bölümü 2 ya da 4 haftalık döngülerle sırayla çalıştırarak normal kullanım kalıplarını taklit edebilirsiniz bence. Böylece değerlendirmeyi zaman içinde güncel tutabilirsiniz
• Böyle bir şeyin var olmasına sevindim. Çıkarım sağlayıcıları quantization seviyelerini sessizce değiştirip duruyor ve çoğu kullanıcı bunu kontrol bile etmiyor. Model üreticisinin yayımladığı standart doğrulayıcı doğru yaklaşıma en yakın şey ve diğer laboratuvarların da benzerlerini çıkarmasını isterim
• Open-weight modeller çalıştırırken neden böyle doğrulayıcılara ihtiyaç duyulduğunu anlatan fireworks.ai yazısı da ilgili bence. quality-first with kimi k2p5
• Anthropic’ten sonra Moonshot’ın da sampling parametrelerinin ayarlanmasını sınırlayan bir model sağlayıcısı olması dikkat çekici. Yine de vendor verifier fikrinin kendisini beğendim
  • Burada "sampling parametrelerinin ayarlanmasını sınırlıyor" derken tam olarak ne kastediliyor merak ediyorum
  • Eğer sonradan yapılan eğitim belirli sampling parametreleriyle gerçekleştirildiyse, gerçek kullanımın da eğitilmiş parametrelerle uyumlu olması mantıklı geliyor
• Bu gerçekten harika bir fikir gibi geliyor. Ben AI gateway Glama’yı işletiyorum ve bazı üçüncü taraf sağlayıcıların quantization konusunda apaçık yalan söylediğini gördüğüm için hepsini listeden çıkarmıştım. Sağlayıcıları doğrulayabilmek, çok daha çeşitli sağlayıcı yapılandırmalarını güvenle sunmayı mümkün kılar ve büyük bir iyileştirme olur
• Satıcılar 6 KVV benchmark’ına göre optimize etmeye başlarsa, sonunda ölçülen şey model sadakati değil sadece KVV uyumluluğu olmaz mı diye endişeleniyorum. Bunu önlemek için bir rotasyon stratejisi olup olmadığını merak ediyorum