Kimiベンダー検証器 - 推論プロバイダーの正確性を検証

 (kimi.com)
3 ポイント 投稿者 GN⁺ 8 일 전 | 2件のコメント | WhatsAppで共有
  • Kimi Vendor Verifier(KVV)は、オープンソースモデルのデプロイ後に異なるインフラで発生する推論実装の差異を検証し、モデル自体の限界とエンジニアリング上の誤りを区別できるようにする公開ツール
  • 公式API基準でOCRBench 91.0、AIME2025 avg@32 98.4、MMMU Pro Vision 78.8を提示し、各評価のTemperature、TopP、MaxTokens設定とK2VV評価結果ファイルもあわせて公開
  • コミュニティで報告されたベンチマークの異常兆候を調査した結果、その多くがデコーディングパラメータの誤用に起因しており、ThinkingモードではTemperature 1.0とTopP 0.95の強制、およびコンテンツの再送検証を適用
  • 検証手順は、パラメータ制約を確認する事前検証の後、OCRBench、MMMU Pro、AIME2025、K2VV ToolCall、SWE-Benchなどを使ってVision前処理、長文出力、ツール呼び出し、agentic codingまで点検する構成
  • 全体ワークフローはNVIDIA H20 8-GPUサーバー2台での逐次実行基準で約15時間を要し、公開リーダーボードと早期アクセス提供を通じて正確性優先の検証の拡大を推進

信頼の連鎖(Chain of Trust)の再構築

  • Kimi Vendor Verifier(KVV) のソース公開とともに、オープンソースモデル利用者が推論実装の正確性を検証できるよう設計された
  • Kimi K2.6モデルの公開と同時に配布され、モデルを公開するだけでは不十分で、多様な環境で正しく動作するか確認するプロセスが必要
  • オープンソースモデルのエコシステムでは、重みの公開とデプロイ経路の多様化が進むほど、品質を統制できる可能性が低下する構造が明らかになっている
  • 利用者がモデル自体の性能上の欠陥とエンジニアリング実装の差異を区別できなければ、オープンソースエコシステムへの信頼が崩れる可能性がある

解決方法

  • 個別の異常兆候から構造的な問題へ拡大

    • K2 Thinking公開以降、コミュニティからベンチマークスコアの異常現象に関するフィードバックが頻繁に寄せられた
    • 調査の結果、相当数の事例がデコーディングパラメータの誤用に起因することが確認された
    • 即時の緩和策としてAPIレベルの一次防衛線を構築
      • ThinkingモードでTemperature=1.0、TopP=0.95を強制
      • thinkingコンテンツが正しく再送されるかの必須検証を適用
    • 特定のLiveBenchmark評価では、サードパーティAPIと公式APIの間に大きな差が観測された
    • 多様なインフラプロバイダーを広範にテストした結果、こうした差が広く存在することを確認

  • 検証手順と運用

    • 公式API基準のベンチマーク数値を公開
      • OCRBench 正確度 91.0
      • AIME2025 avg@32 98.4
      • MMMU Pro Vision 正確度 78.8
    • 評価設定値も明記
      • 3項目すべてでTemperature 1.0、TopP 0.95を使用
      • MaxTokensはOCRBench 16384、AIME2025 98304、MMMU Pro Vision 65536
    • Kimi API K2VV評価結果ファイルのリンクを提供し、F1スコア算出用途であることを明示
    • Pre-Verification 段階を運用
      • temperature、top_pなどのAPIパラメータ制約が正しく強制されているかを検証
      • すべてのテストに合格した場合のみベンチマーク評価を実施
    • OCRBench を使用
      • マルチモーダルパイプライン向けの5分間スモークテストとして機能
    • MMMU Pro を使用
      • 多様な視覚入力テストを通じてVision入力の前処理を検証
    • AIME2025 を使用
      • 長文出力ストレステストとして機能
      • 短いベンチマークでは表面化しないKV cacheバグや量子化による性能低下を捕捉
    • K2VV ToolCall を使用
      • トリガー一貫性(F1)とJSON Schemaの正確性を測定
      • エージェントでツールエラーが蓄積する前に早期検知
    • SWE-Bench を使用
      • 全体のagentic codingテストとして機能
      • sandbox依存のためオープンソース化はしない
    • vLLM、SGLang、KTransformersコミュニティと協力
    • 症状検知にとどまらず根本原因の修正を志向
    • デプロイ後に不満の報告を待つのではなく、インフラプロバイダーに早期アクセス権を提供
    • 利用者が問題に遭遇する前に、各プロバイダーが自らのスタックを検証できるよう構成
    • ベンダー結果に関する公開リーダーボードを継続運用する予定
    • こうした透明性がベンダーの正確性の優先順位向上につながるよう設計
    • 全評価ワークフローの検証が完了
      • NVIDIA H20 8-GPUサーバー2台を使用
      • 逐次実行基準で約15時間を要する
    • 長時間推論シナリオに合わせてスクリプト最適化を適用
      • ストリーミング推論
      • 自動リトライ
      • チェックポイント再開メカニズムを含む
    • 重みが公開された以上、それを正しく実行する知識もまた公開されるべきだという原則を明示
    • ベンダーカバレッジの拡大と、より軽量なagenticテストの探索を進行中

関連記事

2件のコメント

 
ng0301 7 일 전

本当にうまくいってほしいプロジェクトですね
 
GN⁺ 8 일 전
Hacker Newsのコメント
  • このアイデアは気に入った。推論プロバイダーに長年の問題を修正させるための、かなり効果的な社会的圧力になりそう。たとえば AWS Bedrock には Kimi の K2 と K2.5 のモデル配信スタックに致命的な欠陥があって、ツール呼び出しを返すべき試行の 20%〜30% で、トークン出力なしに会話を静かに終了してしまう。だから AWS は Kimi のための本格的な推論プロバイダーとしては事実上意味がなく、似たようなエージェント作業性能に対してより高価な Anthropic モデルへユーザーを押しやっているように見える
    • これは新しい話ではなく、Kimi がすでに数か月前からやっていたことだと思う。K2 Vendor Verifier、Kimi Vendor Verifier もすでにあったし、K2.5 と K2.6 のリリース前からそうだった
  • 私の理解する脅威モデルでは、これは事故による性能低下を防ぐためのもので、悪意ある行為者までカバーするものではなさそう。たとえば、怪しいプロバイダーが最新最高のモデルを動かしていると言いながら、実際にはもっと安くて性能の低いモデルを使って差額を抜いていたとしても、こうしたテストはあまり役に立たないかもしれない。テスト中だと検知すれば、フォルクスワーゲンの排ガス不正事件のように、その時だけ正しく動くように装えるからだ
    • OpenRouter のようなプロバイダーは基本的に最も安いプロバイダーを選ぶが、安い理由が品質よりスループット重視の過度な量子化とチューニングにあることが多い。だからこれは、Kimi が格安プロバイダーによってモデル性能が正しく表現されず、ブランドが傷つくのを防ごうとする試みに見える
    • 偶発的に生じるドリフトを捕まえるだけでも十分価値があると思う。これは CI の性能リグレッションテストとほぼ同じ発想で、誰かが意図的に壊すことを想定して使うものではない。普通は、依存関係を 1 つ上げたらスループットが 15% 落ちた、みたいなありふれた問題を捕まえるためのものだ。誰かが意図的に検査を回避するなら、それは単により安い量子化を黙って流すのとは法的にもかなり違う状況になる
    • その通りでもあり、そうでもないと思う。本当に悪意ある行為者なら、その懸念は正しい。ただ、この仕組みは状況を「モデルを量子化しても告知しないのは明白な詐欺とまでは言えない」から、「検証はあるモデルで通し、実際の顧客リクエストは別のモデルで処理する意図的な詐欺」へと変える。前者までなら喜んでやる半ば悪質なプレイヤーはかなり多そうだ
    • こうしたシステムにとってはかなり良いチャレンジ課題に見える。たとえば fromtier labs が高負荷時に量子化モデルを配信するケースを思い出す
  • これは私たちのベンチマークでも実際の問題だった。OpenRouter のプロバイダーの中で量子化レベルを明記していない、あるいは想定より低いレベルを使っているところには注意が必要だ。OpenRouter は関連する設定オプションを提供しているが、そうすると選択肢が大きく減ることが多い。それとは別に、最高のプロバイダーを使っても Kimi-K2-thinking は私たちのベンチマークではやや期待外れで遅かったが、温度とバリエーションの面では興味深く有用だった。一方で Kimi K2.6 は今のところ新しいオープンソースのリーダーに見える。エージェント評価も進行中で、ワンショットのコーディング推論ベンチマークはすでに用意されている
    • OpenRouter には、特定モデルでより高品質なプロバイダーを優先させる exacto オプションがある。それを使って利点を感じたことがあるのか気になる。また Kimi K2 は学習と推論の両方で int4 を使っているとのことなので、関連する議論を見ると、gguf 作成者ごとに変換方法が違って品質に影響する可能性もありそうだと思う
  • 高性能な機材で 15 時間も回るテストは、再現したり拡張したりしやすいものではないと思う。それでもこれは、複数のクラウドサービス全体に広がる懸念をうまく突いている。自分が ping した相手が、実際に自分が受け取っている相手ではないかもしれない、という点が核心だ
    • 私の解釈では、このテストの第一の対象はユーザーよりベンダー自身だ。テストが長く包括的なのも、自前ホスティング品質への確信をベンダーに持たせるためだと理解した
    • 最初にベンダーごとにスイート全体を一度走らせ、その後は 2 週間または 4 週間ごとに各パートを順番に回し、一般的な利用パターンを模倣すればよいと思う。そうすれば評価を時間とともに最新の状態に保てる
  • こういうものが存在してうれしい。推論プロバイダーは量子化レベルをこっそり差し替えることがあり、ほとんどのユーザーは確認すらしない。モデル開発元が出す標準的な検証器が正解に近く、他の研究所も同様のものを出してほしい
  • オープンウェイトモデルを運用する際になぜこうした検証器が必要なのかを説明する fireworks.ai の関連記事も参考になると思う。quality-first with kimi k2p5 だ
  • Anthropic に続いて Moonshot もサンプリングパラメータの調整を制限するモデルプロバイダーだという点は目立つ。それでも、vendor verifier というアイデア自体は気に入っている
    • ここで「サンプリングパラメータの調整を制限する」とはどういう意味なのか気になる
    • 後処理学習が特定のサンプリングパラメータで行われたなら、実運用でも学習済みパラメータに合わせるのが妥当だと思う
  • これは本当に素晴らしい発想だと感じる。私は AI ゲートウェイの Glama を運営しているが、サードパーティープロバイダーの一部が量子化について露骨に嘘をついているのを見て、すべてリストから外したことがある。プロバイダーを検証できるようになれば、より多様なプロバイダー構成を自信を持って提供できるようになるので、大きな改善になりそうだ
  • ベンダーが 6 つの KVV ベンチマークに合わせて最適化し始めたら、結局はモデル忠実性ではなくKVV 準拠性だけを測ることにならないかと心配だ。これを防ぐローテーション戦略が用意されているのか気になる