推論基礎設施
NVIDIA Dynamo、Kimi K3向けマルチノード展開レシピを提供——100万tokenの推論には少なくとも16基のGB200／GB300が必要
Dynamoの実験版がKimi K3のマルチモーダル処理、推論、ツール呼び出しの解析に対応し、集約型およびprefill／decode分離型のKubernetesレシピを公開した。このレシピは2.8T MoEの展開要件をラックトポロジー単位で定量化しているが、現時点では正式なQAを通過しておらず、GB200構成には既知の起動エラーも残っている。
Kimi K3の重みが公開されたことで、展開上の課題は「ダウンロードできるか」から「マルチノード環境で実際にサービスを提供するにはどうすればよいか」へと移った。NVIDIAは7月27日、Dynamo `v1.4.0-kimi-k3-dev.1`プレビュー版をリリースした。Kimi K3をvLLMバックエンドに統合し、テキストおよび画像の前処理、reasoning parser、tool-call parserに加え、GB200とGB300向けのKubernetesテンプレートを追加している。これは以前のモデルリリースに続く展開面でのマイルストーンであり、新しいモデルバージョンではない。
4種類のレシピは、集約型推論とprefill／decode分離の両方をカバーする。GB200の集約構成では、4ノードにまたがる16基のGPUでTP16を使用する。分離構成にはprefill用16基とdecode用16基、合計32基のGPUが必要だ。GB300の集約構成では、16基のGPUで2つのTP8 replicaを構築する。一方、分離構成ではprefill用8基とdecode用16基を使用する。いずれもKubernetes ComputeDomainを通じてNVLinkトポロジーを維持する。分離型展開ではNIXLがKV cacheを転送し、GB300はNVLink、GB200はRDMA InfiniBandを使用する。
重みのrouted expertsにはMXFP4を採用し、dense部分はBF16を維持する。KV cacheにはFP8を使用する。レシピではprefix caching、KV-aware routing、マルチモーダルencoderのデータ並列分割も有効化され、1,048,576 tokenのコンテキストを処理可能としている。こうした選択は、超大規模MoEにおけるシステム上のボトルネックを反映している。メモリ形式、KV転送、ネットワークトポロジー、リクエストルーティングは、多くの場合、単一コアのtoken生成速度以上にコストを左右する。
ただし、これは依然としてbranch-specific snapshotであり、QA-gatedの安定版ではない。また、エンドツーエンドのスループット、time to first token、コンテキスト長ごとのコスト曲線も公開されていない。公式情報では、GB200分離構成のfrontendで`MODEL_PATH`が未設定になる問題も挙げられており、コンテナがリテラル文字列をそのまま使用して起動する可能性がある。評価チームは、まず修正を適用し、storage classとモデルキャッシュを検証したうえで、自社のagentトラフィックを用いてKV cacheのヒット率とprefill／decode比率を測定すべきだ。現時点のハードウェア表が証明するのはレシピの存在だけであり、その経済性までは証明していない。