AMD、Kimi-K3の3エンジンでのテストを公開　再現にはワークロードとイメージのバージョン確認が必要

AMDは9月22日、vLLM、SGLang、ATOMでKimi-K3をテストする手順を公開し、MI350Xを8基搭載した単一ノードでの推論構成、コンテナのバージョン、測定方法をまとめた。記事中のデータは7月29日に収集されており、当時のソフトウェアスタックの記録に当たる。今回のニュースの焦点は、その手法と制約が公開された点にある。[AMDの技術記事](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)

この手順では、MADのモデルリストを通じてコンテナのビルド、起動スクリプト、設定ファイルを連携させ、madengineで実行して共通形式の結果を出力する。madengineはビルドマニフェストを保存し、ビルドと実行を分離することもできるため、同一のイメージを異なるノードで再利用しやすい。エンジニアリングチームにとって、この構造は性能劣化の原因を構成やバージョンの差異にさかのぼって調べるのに役立つ。[madengineリポジトリ](https://github.com/ROCm/madengine)

Kimi-K3の統合は、モデル項目、専用コンテナ、各エンジン用のスクリプトを追加することで実現され、テンソル並列度は8に設定されている。リポジトリの説明によると、重みファイルの容量は約1.56 TBで、再検証の前にモデルキャッシュ用の空き容量を確保する必要がある。設定はMI350X／MI355Xが属するアーキテクチャを対象としているが、記事で実測に使用されたハードウェアはMI350Xのみだ。[統合の記録](https://github.com/ROCm/MAD/pull/186)、[指定コミットのドキュメント](https://github.com/ROCm/MAD/blob/a20c885/benchmark/kimi_k3/README.md)

AMDによると、今回のワークロードは入力8,192トークン、出力1,024トークンで、同時リクエスト数を変えて測定し、プレフィックスキャッシュは無効にしている。一方、指定コミットのREADMEでは、vLLMの例が依然として入力・出力ともに1,024トークンとなっており、ほかのエンジンに記載された同時リクエスト数の範囲も異なる。少なくともドキュメント間の整合性が取れていないことを示しており、実行前には実際に展開されるコマンドを確認する必要がある。入口となるコマンドをコピーしただけで、ワークロードも同一だと考えることはできない。[記事の測定方法](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)、[READMEの例](https://github.com/ROCm/MAD/blob/a20c885/benchmark/kimi_k3/README.md)

記事には、ビルド期間中にコンテナタグが異なるハッシュを指していたことも記録されているため、再現にはイメージダイジェストの固定が必要だ。各測定点での実行は1回のみで、ウォームアップやばらつきの推定は行われていない。エンジン間でメモリ割り当て量やKVキャッシュの数値精度も統一されておらず、回答品質も評価していない。[測定上の制約](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)

エンジニアリングの観点では、共通形式のレポートは集計の手間を減らせるものの、計測の開始・終了時点、プロンプト長のサンプリング、停止条件まで自動的に統一するわけではない。この手順を継続的インテグレーションに組み込む場合は、生の出力とサーバーパラメーターを保存し、プログラムの性能劣化とテスト条件の変動を区別できるようにすべきだ。本番サービス用のエンジンを選ぶ前には、繰り返し測定を追加し、実際のプロンプト長、レイテンシ要件、品質チェックに基づいて検証する必要がある。また、総トークンスループットと、生成トークンのみを数える速度は分けて解釈する必要がある。