【ITニュース解説】Production Deployment of DeepSeek-V4 and Kimi K3: 32-GPU Topologies, Memory Math, and Cluster Engineering

大規模言語モデル（LLM）は、DeepSeek-V4やKimi K3といった最新のモデルにおいて、MoE（Mixture-of-Experts）という仕組みと、独自のAttentionメカニズムを組み合わせた設計が主流になっている。MoEモデルは、たくさんの「専門家」のような小さなモデルを使い分け、入力に応じて最適な専門家を選んで処理することで、効率よく高い性能を発揮する。しかし、これらの巨大なモデルを実際のサービスで動かすためには、高度なインフラ技術と綿密な計画が必要だ。具体的には、以下の三つの大きな課題に直面する。

一つ目は、モデルが使用するメモリ容量と、コンピュータ間を繋ぐネットワークの通信速度に大きな隔たりがある点だ。数兆ものパラメータを持つモデルのデータは、一台のGPUサーバには収まりきらない。そのため、モデルのデータを複数のGPUやサーバに分割して処理する「並列処理」が不可欠となる。もしこの並列処理が最適でないと、GPU間のデータ通信が遅延の原因となり、モデルの推論速度が著しく低下してしまう。

二つ目は、これらのモデルが従来の標準的な計算方法とは異なる、特別なAttentionメカニズムを採用している点だ。DeepSeek-V4はCompressed Sparse Attention（CSA）とHeavily Compressed Attention（HCA）を組み合わせ、Kimi K3はKimi Dynamic Attention（KDA）とGated MLAを使っている。これらの独自技術は、非常に長いテキストの処理を効率化するが、既存の汎用的なソフトウェアではその性能を十分に引き出せないため、専用の最適化されたソフトウェアやカーネル（計算処理のプログラム）が必要となる。

三つ目は、システム全体の導入費用や運用コスト、そしてそれに見合う経済効果を考慮しなければならない点だ。高性能なGPUを多数搭載したサーバを何台も用意し、運用するには、初期投資、電力消費、運用管理の手間など、多額の費用がかかる。そのため、どれくらいの利用があればこの投資が回収できるのか、厳密な費用対効果の計算が重要となる。

DeepSeek-V4-Proは61層の構造を持ち、CSAとHCAを組み合わせることで、効率的に大量の情報を処理しつつ、MoE層を通じて約490億のパラメータをステップごとに活性化させる。モデル全体のパラメータは1.6兆に及ぶが、これらはすべてGPUのメモリに保持される。一方、Kimi K3は93層の構造で、69層のKDAと24層のGated MLAから構成される。KDAは、処理するテキストの長さに応じてメモリ使用量が増えにくいという特徴を持つ。さらにKimi K3は、データの精度を落とす「量子化」という技術を積極的に採用し、MXFP4という形式でモデルの重みを、MXFP8という形式で計算途中のデータを保存することで、モデルのデータサイズを大幅に削減している。

ここで注意が必要なのは、MoEモデルにおいて「アクティブに使うパラメータ数」が少ないからといって、メモリ使用量が少なくなるわけではない点だ。MoEモデルは、入力に応じてどの専門家を使うかを動的に決定するため、全ての専門家のパラメータを常にGPUのメモリ上に置いておく必要がある。メモリから一時的にデータを読み書きするような処理では、大幅な速度低下が発生し、サービス品質が損なわれるためだ。

次に、ハードウェアの構成とネットワークの接続方法について解説する。GPU単体での高速な通信（NVIDIAのNVLinkによる900GB/秒）と、サーバ間を繋ぐネットワーク（InfiniBandによる約50GB/秒）の間には、通信速度に大きな差がある。この差を考慮し、最適化された並列処理戦略を立てなければならない。

実際の運用では、8つのH100 GPUを搭載したサーバを4台連携させ、合計32GPUのクラスタを構築することが一般的だ。各サーバ内では、NVLinkを使って8つのGPU間で「Tensor Parallelism（TP=8）」という方法で並列計算を行う。これは、一つの計算を細かく分割して、複数のGPUで同時に処理することで、高速な計算を実現する。しかし、このTPを複数のサーバにまたがって行うことは、サーバ間の通信速度が遅いため厳しく禁止されている。サーバ間では、主に「Pipeline Parallelism（PP=2または4）」という、モデルの層をサーバ間で分割して処理する方式や、「Expert Parallelism（EP）」という、MoEのエキスパートをサーバに分散配置する方式で並列処理を行う。これにより、サーバ間の通信量を最小限に抑え、ボトルネックを回避する。

GPUメモリの割り当ては非常に重要だ。一つのGPUがどれくらいのメモリを消費するかを詳細に計算する必要がある。GPUのメモリは、モデルの重み、計算中に一時的に生成されるデータ（活性化）、過去の文脈を記憶するKVキャッシュ、GPU間通信に必要なバッファ、そしてGPUを制御するソフトウェアのオーバーヘッドなどに使われる。例えば、DeepSeek-V4-Proを32GPUの環境で動かす場合、各80GBのGPUメモリは、モデルの重みに約32.5GB、KVキャッシュに約26.0GB、その他のデータに約13.5GBが割り当てられる。このKVキャッシュの容量が、同時に処理できるトークン数に大きく影響する。DeepSeek-V4のような効率的なAttentionメカニズムを用いることで、この32GPUクラスタでは16万を超える同時アクティブトークンを快適に処理できる。Kimi K3は2.8兆パラメータを持つが、もしFP8（8ビット浮動小数点）精度で動かすと、重みだけで2.8TBのメモリを消費し、32枚の80GB GPUの合計メモリ容量2.56TBを超過してしまう。Kimi K3がMXFP4というより低精度な量子化形式を採用していることで、モデルの重みは約1.4TBに収まり、32GPUクラスタでの運用が可能となる。

モデルのデプロイには、Rayのような分散処理フレームワークと、vLLMという高速推論ライブラリを組み合わせる。まず、各サーバでRayのノードを起動し、32GPUクラスタが正しく構成されていることを確認する。その後、vLLMを使ってモデルを起動する。この際、「--tensor-parallel-size 8」で各サーバ内の8GPUでのTPを、「--pipeline-parallel-size 4」で4ノード間のPPを指定し、サーバ間のTPは避ける。また、計算精度と量子化の設定や、長いプロンプトの処理を効率化するオプションを適切に設定することが重要だ。Kimi K3のような特殊なモデルの場合は、専用のカーネルを呼び出すためのバックエンド設定も必要となる。

Kubernetesのようなコンテナ管理システムを用いる場合は、KubeRay Operatorを使ってRayクラスタを管理する。この場合、特に重要なのは、コンテナが利用できる共有メモリ（/dev/shm）のサイズを十分に確保することだ。GPU間の高速通信（NCCL）は、この共有メモリを介して行われるため、デフォルトの小さいサイズでは正しく動作しないことが多い。

システムが稼働したら、性能評価のためにベンチマークを行う。vLLMには専用のツールがあり、これを使って「Time to First Token (TTFT)」や「Time per Output Token (TPOT)」といった指標を測定する。TTFTは最初のトークンが生成されるまでの時間、TPOTは一つのトークンが生成されるのにかかる時間を示し、これらの値が設定した目標値（例えばTTFTは250ミリ秒未満、TPOTは40ミリ秒未満）を達成しているかを確認する。

最後に、経済的な側面、つまり自社でシステムを構築・運用する「自己ホスティング」と、外部の商用APIを利用する場合の比較を検討する。32GPUクラスタを自己ホスティングする場合、サーバハードウェアの償却費、データセンターの電力・設備費、ネットワーク機器、AIインフラエンジニアの人件費などを合わせると、月額約57,000ドル程度の費用がかかる。もし商用APIの平均利用料を100万トークンあたり2.50ドルと仮定すると、月間約228億トークン、または毎日約7億6千万トークンを超える利用がある場合、自己ホスティングの方がコスト効率が良くなるという計算になる。したがって、日々のトークン利用量が5億トークン未満であれば商用API、10億～20億トークン以上で高い利用率を維持できる場合は自己ホスティングが推奨される。大規模なMoEモデルの運用は、モデルの技術的な理解だけでなく、ハードウェア、ネットワーク、分散システム、そして経済性まで含めた幅広い知識と計画が求められる複雑な作業だ。