Kimi Vendor Verifier - Verifikasi akurasi penyedia inferensi

• Kimi Vendor Verifier (KVV) adalah alat publik yang memungkinkan verifikasi deviasi implementasi inferensi yang muncul di berbagai infrastruktur setelah deployment model open source, sehingga dapat membedakan keterbatasan model itu sendiri dari kesalahan engineering
• Berdasarkan API resmi, KVV menyajikan OCRBench 91.0, AIME2025 avg@32 98.4, dan MMMU Pro Vision 78.8, serta turut membuka pengaturan Temperature, TopP, MaxTokens untuk tiap evaluasi beserta file hasil evaluasi K2VV
• Hasil investigasi atas anomali benchmark yang dilaporkan komunitas menunjukkan bahwa sebagian besar berasal dari penyalahgunaan parameter decoding, dan pada mode Thinking diterapkan pemaksaan Temperature 1.0 dan TopP 0.95 serta verifikasi penerusan ulang konten
• Prosedur verifikasi disusun dengan pre-verification untuk memeriksa pembatasan parameter, lalu memakai OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench, dan lainnya untuk memeriksa pra-pemrosesan Vision, output panjang, pemanggilan tool, hingga agentic coding
• Seluruh workflow memerlukan sekitar 15 jam dalam eksekusi berurutan pada dua server NVIDIA H20 8-GPU, dan penyebaran verifikasi yang mengutamakan akurasi didorong melalui leaderboard publik serta pemberian early access

---

Membangun Ulang Chain of Trust

• Dirancang bersamaan dengan dibukanya source code Kimi Vendor Verifier (KVV) agar pengguna model open source dapat memverifikasi akurasi implementasi inferensi
• Dirilis bersamaan dengan pembukaan model Kimi K2.6, dengan gagasan bahwa publikasi model saja tidak cukup dan diperlukan proses untuk memastikan model bekerja benar di beragam lingkungan
• Seiring ekosistem model open source makin membuka bobot model dan memperluas jalur deployment, terlihat struktur di mana kemampuan kontrol kualitas semakin menurun
• Jika pengguna tidak dapat membedakan antara cacat performa model itu sendiri dan deviasi implementasi engineering, kepercayaan terhadap ekosistem open source dapat runtuh

Cara penyelesaiannya

• Dari anomali individual ke isu struktural

  • Setelah K2 Thinking dibuka, komunitas kerap mengirimkan umpan balik terkait anomali skor benchmark
  • Hasil investigasi mengonfirmasi bahwa cukup banyak kasus berasal dari penyalahgunaan parameter decoding
  • Sebagai langkah mitigasi segera, dibangun garis pertahanan pertama di level API
    • Pada mode Thinking, Temperature=1.0 dan TopP=0.95 dipaksakan
    • Diterapkan verifikasi wajib untuk memastikan konten thinking diteruskan ulang dengan benar
  • Pada evaluasi LiveBenchmark tertentu, diamati perbedaan besar antara API pihak ketiga dan API resmi
  • Hasil pengujian luas pada beragam penyedia infrastruktur mengonfirmasi bahwa perbedaan seperti ini terjadi secara luas

• Prosedur dan operasi verifikasi

  • Membuka angka benchmark berdasarkan API resmi
    • Akurasi OCRBench 91.0
    • AIME2025 avg@32 98.4
    • Akurasi MMMU Pro Vision 78.8
  • Nilai konfigurasi evaluasi juga dicantumkan
    • Ketiga item sama-sama memakai Temperature 1.0 dan TopP 0.95
    • MaxTokens masing-masing adalah OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
  • Tautan file hasil evaluasi K2VV Kimi API disediakan, dengan penjelasan bahwa file itu dipakai untuk menghitung skor F1
  • Menjalankan tahap Pre-Verification
    • Memverifikasi apakah pembatasan parameter API seperti temperature dan top_p dipaksakan dengan benar
    • Evaluasi benchmark hanya dijalankan setelah semua pengujian lolos
  • Menggunakan OCRBench
    • Berperan sebagai smoke test 5 menit untuk pipeline multimodal
  • Menggunakan MMMU Pro
    • Memverifikasi pra-pemrosesan input Vision melalui pengujian berbagai input visual
  • Menggunakan AIME2025
    • Berperan sebagai stress test output panjang
    • Menangkap bug KV cache dan penurunan performa kuantisasi yang tidak terlihat pada benchmark pendek
  • Menggunakan K2VV ToolCall
    • Mengukur konsistensi trigger (F1) dan akurasi JSON Schema
    • Mendeteksi lebih awal sebelum kesalahan tool terakumulasi dalam agent
  • Menggunakan SWE-Bench
    • Berperan sebagai pengujian penuh agentic coding
    • Tidak di-open-source-kan karena ketergantungan sandbox
  • Bekerja bersama komunitas vLLM, SGLang, dan KTransformers
  • Tidak berhenti pada deteksi gejala, tetapi menargetkan perbaikan akar masalah
  • Alih-alih menunggu keluhan setelah deployment, penyedia infrastruktur diberi hak early access
  • Disusun agar tiap penyedia dapat memverifikasi stack mereka sendiri sebelum pengguna mengalami masalah
  • Leaderboard publik untuk hasil vendor akan terus dioperasikan
  • Transparansi ini dirancang agar meningkatkan prioritas akurasi para vendor
  • Verifikasi atas seluruh workflow evaluasi telah selesai
    • Menggunakan dua server NVIDIA H20 8-GPU
    • Memerlukan sekitar 15 jam dalam eksekusi berurutan
  • Dilakukan optimasi skrip agar sesuai dengan skenario inferensi berdurasi panjang
    • Streaming inferensi
    • Retry otomatis
    • Termasuk mekanisme resume dari checkpoint
  • Ditegaskan prinsip bahwa setelah bobot model dibuka, pengetahuan untuk menjalankannya dengan benar juga harus dibuka
  • Sedang memperluas cakupan vendor dan mengeksplorasi pengujian agentic yang lebih ringan

[ng0301]

Semoga proyek ini benar-benar berjalan dengan baik.

[GN⁺]

Komentar Hacker News

• Saya suka ide ini. Ini tampaknya bisa menjadi bentuk tekanan sosial yang cukup efektif untuk mendorong penyedia inferensi memperbaiki masalah lama. Misalnya, AWS Bedrock punya cacat fatal pada stack penyajian model K2 dan K2.5 milik Kimi, sehingga 20%~30% percobaan yang seharusnya mengeluarkan tool call malah diam-diam mengakhiri percakapan tanpa keluaran token apa pun. Akibatnya, AWS praktis jadi tidak berarti sebagai penyedia inferensi yang serius untuk Kimi, dan tampaknya justru mendorong pengguna ke model Anthropic yang lebih mahal untuk kinerja tugas agen yang serupa
  • Saya rasa ini bukan hal baru; Kimi sudah melakukannya selama berbulan-bulan. Sudah ada K2 Vendor Verifier dan Kimi Vendor Verifier, bahkan sejak sebelum rilis K2.5 dan K2.6
• Model ancaman yang saya pahami tampaknya ditujukan untuk mencegah penurunan kinerja akibat kesalahan, bukan untuk mencakup pelaku yang benar-benar berniat jahat. Misalnya, jika ada penyedia mencurigakan yang mengaku menjalankan model terbaik terbaru tetapi sebenarnya memakai model yang lebih murah dan performanya lebih rendah untuk mengambil selisih keuntungan, pengujian seperti ini mungkin tidak banyak membantu. Mereka bisa mendeteksi bahwa sedang diuji lalu membuat sistem berperilaku benar hanya saat itu, seperti skandal emisi Volkswagen
  • Penyedia seperti OpenRouter pada dasarnya memilih penyedia termurah, dan sering kali murahnya itu karena mereka memakai kuantisasi berlebihan dan tuning demi throughput, bukan kualitas. Jadi ini tampaknya merupakan upaya kimi untuk mencegah penyedia murahan merusak merek mereka karena tidak merepresentasikan performa model dengan benar
  • Menangkap drift yang terjadi secara tidak sengaja saja sudah sangat berharga. Ini hampir sama persis dengan pengujian regresi kinerja di CI, dan bukan sesuatu yang dipakai dengan asumsi ada orang yang sengaja akan merusaknya. Biasanya ini dipakai untuk menangkap masalah biasa seperti ketika satu dependensi dinaikkan versinya lalu throughput turun 15%. Jika ada orang yang sengaja mengakali pemeriksaan, itu secara hukum juga menjadi situasi yang cukup berbeda dibanding sekadar diam-diam mengirim kuantisasi yang lebih murah
  • Menurut saya iya dan tidak. Jika pelakunya benar-benar berniat jahat, kekhawatiran itu valid. Namun perangkat ini mengubah situasi dari "mengkuantisasi model tanpa memberi tahu bukanlah penipuan yang jelas" menjadi "lulus verifikasi dengan satu model lalu memproses permintaan pelanggan nyata dengan model lain" yang merupakan penipuan yang disengaja. Saya rasa cukup banyak pemain setengah nakal yang bersedia melakukan yang pertama, tetapi tidak yang kedua
  • Ini tampak seperti tantangan yang cukup bagus untuk sistem seperti itu. Misalnya, ini mengingatkan saya pada kasus fromtier labs yang menyajikan model terkuantisasi saat beban tinggi
• Ini juga merupakan masalah nyata di benchmark kami. Di antara penyedia OpenRouter, yang tidak mencantumkan tingkat kuantisasi atau memakai tingkat yang lebih rendah dari perkiraan perlu diwaspadai. OpenRouter memang menyediakan opsi konfigurasi terkait, tetapi itu sering kali sangat mengurangi pilihan yang tersedia. Terlepas dari itu, bahkan dengan penyedia terbaik sekalipun, Kimi-K2-thinking agak mengecewakan dan lambat di benchmark kami, meski menarik dan berguna dari sisi temperatur dan variasi. Sebaliknya, Kimi K2.6 sejauh ini tampak sebagai pemimpin open-source yang baru. Evaluasi agen juga sedang berjalan, dan benchmark penalaran coding one-shot sudah tersedia
  • OpenRouter memiliki opsi exacto yang membuatnya lebih memilih penyedia berkualitas lebih tinggi untuk model tertentu. Saya penasaran apakah ada yang pernah merasakan manfaatnya. Selain itu, karena Kimi K2 dikatakan memakai int4 baik dalam pelatihan maupun inferensi, melihat diskusi terkait membuat saya berpikir bahwa tiap pembuat gguf mungkin mengonversinya secara berbeda, yang bisa memengaruhi kualitas
• Menurut saya, pengujian yang berjalan sampai 15 jam di perangkat berperforma tinggi tidak mudah untuk direproduksi atau diskalakan. Meski begitu, ini menyentuh kekhawatiran yang sangat luas di berbagai layanan cloud: target yang saya ping mungkin bukan target yang sebenarnya saya terima
  • Interpretasi saya, target pertama dari pengujian ini adalah vendor itu sendiri, bukan pengguna. Alasan pengujiannya panjang dan komprehensif juga karena tujuannya memberi vendor keyakinan terhadap kualitas self-hosting mereka
  • Awalnya cukup jalankan seluruh suite satu kali untuk tiap vendor, lalu setelah itu putar masing-masing bagian setiap 2 atau 4 minggu sambil meniru pola penggunaan umum. Dengan begitu evaluasinya bisa tetap mutakhir seiring waktu
• Senang hal seperti ini ada. Penyedia inferensi sering diam-diam menukar tingkat kuantisasi, dan kebanyakan pengguna bahkan tidak memeriksanya. Verifier standar yang dirilis pembuat model tampaknya adalah jawaban yang paling tepat, dan saya harap lab lain juga merilis hal serupa
• Tulisan terkait dari fireworks.ai yang menjelaskan mengapa verifier seperti ini diperlukan saat mengoperasikan model open-weight juga layak dibaca. Judulnya quality-first with kimi k2p5
• Menarik bahwa setelah Anthropic, Moonshot juga termasuk penyedia model yang membatasi penyesuaian parameter sampling. Meski begitu, saya suka ide vendor verifier itu sendiri
  • Saya penasaran apa yang dimaksud dengan "membatasi penyesuaian parameter sampling" di sini
  • Jika pelatihan pascapemrosesan dilakukan dengan parameter sampling tertentu, menurut saya masuk akal bila penggunaan nyata juga disesuaikan dengan parameter yang dipakai saat pelatihan
• Ini benar-benar terasa seperti ide yang sangat bagus. Saya menjalankan AI gateway Glama, dan saya pernah melihat beberapa penyedia pihak ketiga secara terang-terangan berbohong soal kuantisasi, sehingga saya menurunkan semuanya dari daftar. Jika saya bisa memverifikasi penyedia, itu akan menjadi peningkatan besar karena saya bisa dengan percaya diri menawarkan konfigurasi penyedia yang lebih beragam
• Saya khawatir kalau vendor mulai mengoptimalkan diri untuk 6 benchmark KVV, pada akhirnya yang diukur bukan lagi fidelitas model melainkan hanya kepatuhan terhadap KVV. Saya penasaran apakah sudah ada strategi rotasi untuk mencegah itu