Kimi Vendor Verifier - Verifikasi akurasi penyedia inferensi

 (kimi.com)
3 poin oleh GN⁺ 8 hari lalu | 2 komentar | Bagikan ke WhatsApp
  • Alat sumber terbuka yang memungkinkan verifikasi perbedaan implementasi inferensi yang muncul di berbagai infrastruktur setelah deployment model open source, sehingga batasan bawaan model dan kesalahan engineering dapat dibedakan
  • Berdasarkan API resmi, disajikan OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8, serta pengaturan Temperature, TopP, MaxTokens untuk tiap evaluasi dan file hasil evaluasi K2VV
  • Hasil penyelidikan atas anomali benchmark yang dilaporkan komunitas menunjukkan banyak kasus berasal dari penyalahgunaan parameter decoding, dan pada mode Thinking diterapkan pemaksaan Temperature 1.0 serta TopP 0.95 bersama verifikasi penerusan konten
  • Prosedur verifikasi disusun dengan pra-verifikasi untuk memeriksa pembatasan parameter, lalu menggunakan OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench, dan lainnya untuk meninjau pra-pemrosesan Vision, output panjang, pemanggilan tool, hingga agentic coding
  • Seluruh workflow membutuhkan sekitar 15 jam dalam eksekusi berurutan pada dua server NVIDIA H20 8-GPU, dan melalui leaderboard publik serta akses awal didorong penyebaran verifikasi yang mengutamakan akurasi

Membangun kembali rantai kepercayaan

  • Bersamaan dengan open-sourcing Kimi Vendor Verifier(KVV), alat ini dirancang agar pengguna model open source dapat memverifikasi akurasi implementasi inferensi
  • Alat ini dirilis bersamaan dengan publikasi model Kimi K2.6, dan sekadar merilis model saja tidak cukup; perlu proses untuk memastikan model bekerja dengan benar di berbagai lingkungan
  • Semakin ekosistem model open source bergerak ke arah publikasi bobot dan beragam jalur deployment, semakin terlihat struktur yang menurunkan kemampuan kontrol kualitas
  • Jika pengguna tidak dapat membedakan antara cacat performa bawaan model dan perbedaan implementasi engineering, kepercayaan terhadap ekosistem open source dapat runtuh

Cara penyelesaiannya

  • Dari anomali individual ke isu struktural

    • Setelah K2 Thinking dipublikasikan, komunitas sering menyampaikan umpan balik terkait fenomena anomali skor benchmark
    • Hasil investigasi menunjukkan banyak kasus berasal dari penyalahgunaan parameter decoding
    • Sebagai langkah mitigasi segera, dibangun garis pertahanan pertama di tingkat API
      • Pada mode Thinking, Temperature=1.0 dan TopP=0.95 dipaksakan
      • Diterapkan verifikasi wajib untuk memastikan konten thinking diteruskan kembali dengan benar
    • Pada evaluasi LiveBenchmark tertentu, diamati perbedaan besar antara API pihak ketiga dan API resmi
    • Hasil pengujian luas terhadap berbagai penyedia infrastruktur mengonfirmasi bahwa perbedaan semacam ini terjadi secara luas

  • Prosedur verifikasi dan operasional

    • Mempublikasikan 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
      • Untuk ketiganya digunakan Temperature 1.0 dan TopP 0.95
      • MaxTokens adalah OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
    • Tautan file hasil evaluasi Kimi API K2VV disediakan, dan disebutkan untuk perhitungan skor F1
    • Menjalankan tahap Pre-Verification
      • Memverifikasi apakah pembatasan parameter API seperti temperature dan top_p diterapkan dengan benar
      • Evaluasi benchmark hanya dijalankan setelah seluruh pengujian lolos
    • Menggunakan OCRBench
      • Berperan sebagai smoke test 5 menit untuk pipeline multimodal
    • Menggunakan MMMU Pro
      • Memverifikasi pra-pemrosesan input Vision melalui pengujian beragam 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
      • Memungkinkan deteksi dini sebelum error tool menumpuk dalam agent
    • Menggunakan SWE-Bench
      • Berperan sebagai pengujian agentic coding menyeluruh
      • Tidak di-open-source karena ketergantungan pada sandbox
    • Bekerja bersama komunitas vLLM, SGLang, KTransformers
    • Tidak berhenti pada deteksi gejala, tetapi mengarah pada perbaikan akar masalah
    • Alih-alih menunggu keluhan setelah deployment, penyedia infrastruktur diberi akses awal
    • 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 mendorong peningkatan prioritas akurasi di pihak vendor
    • Verifikasi seluruh workflow evaluasi telah selesai
      • Menggunakan dua server NVIDIA H20 8-GPU
      • Membutuhkan sekitar 15 jam dalam eksekusi berurutan
    • Diterapkan optimasi skrip untuk skenario inferensi berdurasi panjang
      • Inferensi streaming
      • Retry otomatis
      • Termasuk mekanisme melanjutkan dari checkpoint
    • Ditegaskan prinsip bahwa jika bobot telah dipublikasikan, maka pengetahuan untuk menjalankannya dengan benar juga harus dipublikasikan
    • Perluasan cakupan vendor dan eksplorasi pengujian agentic yang lebih ringan sedang berlangsung
    • Kontak contact-kvv@kimi.com dipublikasikan

Bacaan terkait

2 komentar

 
ng0301 7 hari lalu

Semoga proyek ini benar-benar berjalan dengan baik.
 
GN⁺ 8 hari lalu
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
  • 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