ハクソク

世界を動かす技術を、日本語で。

Kimiベンダー検証ツール – 推論プロバイダーの正確性を検証する

12時間前原文(www.kimi.com)

概要

  • **Kimi Vendor Verifier (KVV)**のオープンソース化による信頼性強化
  • 推論実装の正確性検証の重要性
  • 公式ベンチマークと第三者API間の品質ギャップの指摘
  • 6つの重要ベンチマークによる包括的な評価
  • 継続的なベンダー評価とコミュニティ連携の推進

「Chain of Trust」の再構築：Kimi Vendor Verifier

  • Kimi K2.6モデルリリースと同時に、Kimi Vendor Verifier (KVV)プロジェクトをオープンソース化
  • オープンソースモデル利用者が、推論実装の正確性を自ら検証できる仕組みの提供
  • モデル公開だけでなく、各環境での正確な動作保証が不可欠との認識
  • Kimi API K2VV評価結果も公開し、F1スコア計算の透明性を確保

KVV開発の背景

  • K2 Thinking公開以降、コミュニティからベンチマークスコア異常の報告が頻発
  • 多くのケースでDecodingパラメータの誤用が原因と判明
  • APIレベルでの防御策（Temperature=1.0、TopP=0.95強制・Thinking内容の検証）を実装
  • さらに微細な異常も発覚し、公式APIとサードパーティAPI間の大きな差異を確認
  • オープンソースモデルの普及により、品質管理が困難化
  • 「モデル自体の欠陥」と「実装上の逸脱」の区別が難しくなり、信頼性低下のリスク増大

KVVによる解決策

  • 6つの重要ベンチマークで広範な検証を実施
    • Pre-Verification：APIパラメータ制約（temperature, top_p等）の遵守確認
    • OCRBench：マルチモーダルパイプラインの5分スモークテスト
    • MMMU Pro：Vision入力前処理の多様性検証
    • AIME2025：長文出力ストレステストでKVキャッシュや量子化劣化を検出
    • K2VV ToolCall：トリガー一貫性（F1）とJSON Schema精度の測定
    • SWE-Bench：総合的なエージェントコーディングテスト（依存関係のため未公開）
  • vLLM/SGLang/KTransformersコミュニティと連携し、根本的な修正を推進
  • 事前検証の仕組みで、ユーザー利用前にインフラ提供者が自社スタックを評価可能
  • 公開リーダーボードでベンダーごとの結果を透明化し、品質向上を促進

評価コストと効率化

  • NVIDIA H20 8-GPUサーバー2台で全評価ワークフローを検証
  • 逐次実行で約15時間を要するが、長時間推論向けにスクリプトを最適化
  • ストリーミング推論・自動リトライ・チェックポイント再開などの効率化機構を実装

オープンな招待

  • モデル重みの公開だけでなく、正しい運用知識の共有もオープンに
  • ベンダーカバレッジの拡大と、より軽量なエージェントテストの模索
  • 問い合わせ先：[email protected]

Hackerたちの意見

これが存在するのを見るのはいいね。推論プロバイダーは静かに量子レベルを入れ替えてるけど、ほとんどのユーザーはチェックしないんだよね。モデルメーカーからの標準的な検証者は正しい方向だと思うし、他のラボも同じようにやってほしいな。
俺の理解が正しければ、ここでの脅威モデルはパフォーマンスに影響を与える偶発的な問題から守ることみたいだけど、悪意のある行為者には対応してないよね。例えば、Sketchy Providerが最新のものを使ってるって言ってるけど、実際には安い（しかも劣悪な）モデルを使って利益を得てるってこと。こういうテストじゃ役に立たないよね、だってSketchy Providerはテストされてるときに気づいて正しいことをするかもしれないし（フォルクスワーゲンの排出ガススキャンダルみたいに）。合ってる？
└
これはすべてのシステムにとって素晴らしい挑戦のようだね。重い負荷の下でクォンツにサービスを提供するフロンティアラボを見てみたいな。
└
そうとも言えるし、そうじゃないとも言えるね。真に悪意のある行為者に対してはその通りだけど、「このモデルを量子化して人に言わないことで明らかに詐欺を犯しているわけではない」から「一つのモデルでデプロイを検証して、別のモデルで顧客のリクエストに応えることで故意に詐欺を犯している」にシフトするんだよね。半分悪意のある行為者が多くて、前者をやるのには喜んでいると思う。
└
偶然のドリフトをキャッチするのは、まだまだ価値があるよね。CIのパフォーマンス回帰テストと基本的に同じ考え方で、誰も妨害を期待して書かないんだよ。つまらないことのためにやるんだ、「あ、依存関係をぶつけちゃってスループットが15%落ちた」みたいな。もし誰かがわざわざチェックをバイパスしようとしたら、それは安い量子を静かに出荷するのとは法的にかなり違う状況になるね。
└
OpenRouterのようなプロバイダーは、デフォルトで一番安いプロバイダーを選ぶんだ。安い理由は、めちゃくちゃ量子化されていて、品質じゃなくてスループットにチューニングされてるから。これは多分、Kimiが自社のブランドを安売りプロバイダーから守ろうとしてるんだろうね。
15時間も高性能な rig でテストするのは再現性やスケールが難しいだろうね。でも、これは広くある懸念に対処してると思う。クラウドサービス全般に影響する問題だし、実際に送信するものが必ずしも受け取るものとは限らないからね。
└
各ベンダーごとに最初に全体を一回実行して、その後は2週間か4週間のサイクルで各部分を回していくといいよ。これで時間が経っても評価が最新の状態に保たれるんだ。
└
私のこの記事の読み方は、このテストの最初の対象はベンダー自身だってこと。テストは長くて包括的で、ベンダーに自分のホスティングに自信を持たせるためにあるんだ。
Anthropicの後、Moonshotもサンプリングパラメータの調整を制限しているモデルプロバイダーだね。でも、ベンダー検証者のアイデアは好きだな。
└
特定のサンプリングパラメータでポストトレーニングが行われた場合、そのトレーニングに使ったパラメータだけを使うのが理にかなってるね。
このアイデア、いいね。推論プロバイダーが長年の問題を解決するための効果的な社会的圧力の一つになるかもしれない。例えば、AWS BedrockはKimiのK2とK2.5モデルに致命的な欠陥があって、20%-30%の試行がツールコールを発信する代わりに会話を静かに終了させちゃうんだ。これじゃAWSはKimiにとって真剣な推論プロバイダーとしては無関係になっちゃうし、ユーザーをBedrockのかなり高価なAnthropicモデルに押しやることになるね。
これが私たちのベンチマークでの実際の問題だよ。量子化を指定しないOpenRouterのプロバイダーには注意してね。期待しているよりも低いものを使っていることがあるから。OpenRouterはこれに対する設定オプションを提供しているけど、選択肢をかなり制限することが多いんだ。とはいえ、最高のプロバイダーでも、Kimi-K2の思考は私たちのベンチマークでは期待外れで遅かったけど、温度や変動に関しては面白くて役に立ったよ。ただ、Kimi K2.6は今のところ新しいオープンソースのリーダーだね。エージェンティックな評価はまだ進行中だけど、一発コーディング推論のベンチマークはここで準備できてるよ。https://gertlabs.com/?mode=oneshot_coding
└
OpenRouterには、特定のモデルに対して高品質のプロバイダーを優先する「exacto」[1]オプションがあるよ。それを使うことで何かメリットを感じた？ 編集: Kimi K2はトレーニング中も推論中もint4を使ってる[2]。これが質に影響するのかな、違うggufクリエイターがこれを正しく変換できないかもしれないから？ [1] https://openrouter.ai/docs/guides/routing/model-variants/exa... [2] https://www.reddit.com/r/LocalLLaMA/comments/1pzfuqg/why_kim...
fireworks.aiからの関連する記事で、オープンウェイトモデルを実行することと、なぜそのような検証者が最初に必要なのかについて。https://fireworks.ai/blog/quality-first-with-kimi-k2p5