1兆パラメータKimi K2.5と480BQwen3-Coderを4xB200で動かせる？徹底実験

📖この記事は約11分で読めます

1. 1兆パラメータのローカル起動に挑戦

2026年3月現在、オープンウェイトLLMの規模はとどまるところを知らない。Moonshotが公開したKimi K2.5（1兆パラメータ）とAlibabaのQwen3-Coder-480B（480Bパラメータ）は、それぞれ630GB・480GBの重みファイルを必要とする。筆者はRunPodの4xB200（VRAM 720GB）でこれらを同時に動かす実験に取り組んだ。

最初は8xB200（1,440GB）を狙っていたが、在庫切れで4枚構成に。結果として、Kimi K2.5はINT4量子化で630GB、Qwen3-CoderはFP8で480GBとなり、2つのポッドに分けて起動することに落ち着いた。

この実験の意義は、MoE（Mixture-of-Experts）アーキテクチャの恩恵で「巨大だが実用的」なモデルを現実的に動かせるかを検証すること。特に、推論時のアクティブパラメータが32B〜35Bに抑えられる点が注目だ。

日本語コミュニティではローカルLLMの導入が進んでいるが、こうした100B超のモデルはクラウドリソースが必須。RunPodのB200構成でどれほどのパフォーマンスが出るのか、筆者が実際に試した。

2. なぜKimi K2.5とQwen3-Coder-480Bか

Kimi K2.5は現時点で最大のオープンウェイトMoEモデル。384エキスパート構成で、マルチモーダル対応とツール呼び出し機能が特徴。INT4量子化で630GBに圧縮され、ツールチェーンとの連携が強力。

Qwen3-Coder-480Bは160エキスパート構成のコーディング特化モデル。FP8で480GBの重みファイルながら、32Kコンテキスト長をサポート。コード生成・デバッグの精度が高く、開発者向けに最適化されている。

両モデル共通の技術的特徴は、MoEの並列化と量子化技術。vLLMの最適化により、4xB200でも推論が可能になる。ただし、KVキャッシュやGPUメモリの利用効率が鍵となる。

筆者が選んだ理由は、現実的なハードウェアで「巨大モデル」を動かす可能性を示すため。特に、480Bモデルの4xB200構成は、コストと性能のバランスを議論する良いサンプル。

3. VRAM計算と起動設定

NVIDIA B200は1枚あたり180GB VRAMを搭載。4枚構成で720GBを確保。Kimi K2.5はINT4で630GB、Qwen3-CoderはFP8で480GB。前者は90GB、後者は240GBの余裕がある。

筆者の設定では、Kimi K2.5はmax-model-lenを16384、gpu-memory-utilizationを0.88に。Qwen3-Coderは32768コンテキスト長を許容する。vLLMの–tensor-parallel-size 4で4枚に分割。

特に重要なのは、–mm-encoder-tp-mode dataや–tool-call-parser kimi_k2などのカスタムパラメータ。これらはKimi K2.5のマルチモーダル・ツール呼び出しを正しく動作させるための必須オプション。

FP8のQwen3-CoderではVLLM_USE_DEEP_GEMM=1の設定が推奨。これはFP8演算を最適化するカーネルを有効にする。エキスパート並列とテンソル並列の組み合わせが性能を左右する。

4. 実際に動かしてみた結果

RunPodでの起動にはモデルダウンロードが最大のボトルネック。Kimi K2.5の630GBは30〜60分かかる。この間は$19.96/hrの課金が続くため、HuggingFaceの転送速度がコストに直結する。

ポッド起動後はcurlコマンドでヘルスチェック。GPU blocksが0だとOOMエラーのサイン。vLLMログの「Uvicorn running on http://0.0.0.0:8000」で起動完了を確認。

OpenAI SDK経由で実際にモデルを叩くと、Kimi K2.5はツール呼び出しの応答が遅い。一方Qwen3-Coderは32Kコンテキストを活かした長文処理がスムーズ。ただし、TTFT（First Token Time）は両モデルとも改善の余地あり。

コスト面では、2ポッド同時起動で1時間$39.92（約6,000円）。8時間作業で48,000円に達する。常時稼働は非現実的で、テスト目的での短期利用が現実的。

5. 巨大モデルの実用化可能性

MoEアーキテクチャのおかげで、1兆パラメータモデルでもアクティブパラメータは32B〜35Bに。これは従来の30B級モデルと同等の計算量に抑えられる点が画期的。

ただし、4xB200構成ではKVキャッシュの制限が厳しい。max-model-lenの調整や、GPUメモリ利用効率の最適化が必須。量子化技術（INT4/FP8）の進化がローカル起動の可能性を広げる。

日本の開発者コミュニティでは、こうしたモデルの導入が進んでいる。特に、コード生成やマルチモーダル処理の需要が高い。ただし、コスト面での検討が必要。

今後の展望として、vLLMやEXL2量子化の進化が期待される。さらに、RunPodのB200利用率が向上すれば、より大規模なモデルの起動が現実的になる可能性。

6. 筆者の率直な評価

この実験の最大の教訓は「4xB200でも十分」ということ。当初8枚を狙ったが、4枚で余裕をもって動かせることが判明。制約が逆に最小構成の導きになる。

ただし、コストが高すぎる。テスト目的なら数時間の利用で十分。常時稼働は非現実的。日本国内の開発者には、コストと性能のバランスをしっかり検討してほしい。

MoEの恩恵は大きいが、ツール呼び出しなどカスタム機能のサポートが不完全な点も。Kimi K2.5のマルチモーダル処理はまだ不安定で、現実的な用途ではQwen3-Coderが使いやすい。

今後の改善点として、vLLMの最適化や量子化技術の進化が期待される。また、RunPodのB200在庫増加で、より大規模なモデルの起動が可能になる可能性。

7. 読者が試せる方法

RunPodで4xB200構成を検討する際、まずモデルサイズを確認。Kimi K2.5はINT4で630GB、Qwen3-CoderはFP8で480GB。vLLMのパラメータ調整がカギ。

コスト削減のため、モデルダウンロード中の課金を最小化する。HuggingFaceの転送速度を意識し、不要なポッドは停止する。ストレージコストだけを残す構成が効率的。

日本語コミュニティでは、Kimi K2.5のツール呼び出しやQwen3-Coderのコード生成を活かす使い方が多い。特に開発者や研究者向けに最適化されている。

導入の際は、まずは無料トライアルで動作確認を。4xB200の課金は高額なので、テスト目的で利用することを強く推奨する。

8. まとめと展望

1兆パラメータモデルがオープンウェイトで公開され、4xB200でも動かせる時代になった。MoEの恩恵で巨大モデルの実用化が進んでいる。

ただし、コスト面での検討が不可欠。日本語コミュニティでは、こうしたモデルの導入が進んでいるが、現実的な利用方法が問われる。

今後の進化として、量子化技術の改良やvLLMの最適化が期待される。RunPodのB200在庫増加で、さらに大規模なモデルの起動が可能になる可能性。

筆者の結論は、「巨大モデルは実用的だが、コストと性能のバランスが重要」。特に日本国内では、こうしたクラウドリソースの活用がAI開発の新たな選択肢になる。

実際の活用シーン

これらのモデルは、企業のカスタマーサポート自動化に大きな可能性を秘めている。例えば、Kimi K2.5のツール呼び出し機能を活用して、問い合わせ内容を分析し、即座にデータベースやFAQを検索するプロセスを構築する。これにより、従来は人間のオペレーターが対応していた複雑な質問を、AIがリアルタイムで解決可能になる。また、マルチモーダル対応により、画像や音声を含む問い合わせも処理できる。

研究機関では、Qwen3-Coder-480Bの32Kコンテキスト長を活かして、大量の論文やデータを一括して分析するユースケースが想定される。例えば、数百KBにわたる論文全文を入力し、その中から特定の研究テーマに関する統計やキーワードを抽出する作業を高速化。これにより、研究者の作業効率が大幅に向上する。

教育分野では、Kimi K2.5のツールチェーン連携機能を活用して、生徒の学習状況に応じた個別指導を実現する。AIが生徒の過去の解答履歴を分析し、弱点分野に特化した演習問題を自動生成する。また、マルチモーダル入力により、図やグラフを含む教材も解析可能に。こうした活用により、従来の教育現場では困難だったパーソナライズド・ラーニングが実現される。

他の選択肢との比較

競合製品として注目されるのは、OpenAIのGPT-4とMetaのLLaMA3系列。GPT-4はクローズドモデルながら、128Kコンテキスト長と高い精度が特徴。ただし、ローカル起動が困難で、クラウドAPIに依存する点がネック。一方、LLaMA3はオープンウェイトながら、最大70Bパラメータにとどまり、MoEアーキテクチャを採用していない。

量子化技術の観点では、Kimi K2.5のINT4圧縮とQwen3-CoderのFP8圧縮が優れている。同規模のINT8量子化モデル（例：Llama3-70B）では、4xB200構成では推論が困難になる。また、EXL2量子化を採用するモデル（例：Phi-3）は、さらに低いVRAM使用量を実現するが、パラメータ数が100B未満で性能に差が出る。

代替技術として、モデル圧縮や蒸留技術が挙げられる。しかし、蒸留された10B〜30Bモデルでは、Kimi K2.5やQwen3-Coderの精度を維持するのが難しい。また、MoEアーキテクチャを採用していないモデル（例：Falcon）は、同等の性能を発揮するためにはさらに多くのVRAMを消費する。

導入時の注意点とベストプラクティス

まず、GPUメモリの管理が重要。4xB200構成では、Kimi K2.5とQwen3-Coderを同時に動かす場合、GPU blocksの割り当てを明確に設定する。vLLMの–block-sizeパラメータを調整し、KVキャッシュの無駄を防ぐ。また、–max-num-batched-tokensの設定でバッチ処理を最適化し、推論速度を向上させる。

コスト管理の観点では、RunPodのスポットインスタンスを活用する。通常のB200構成は高価だが、スポットインスタンスでは最大50%のコスト削減が可能。ただし、インスタンスの停止・再起動を頻繁に行う必要があり、連続的な作業には向かない。また、モデルダウンロード中の課金を回避するために、ストレージコストだけを支払う「モデル待機モード」を活用する。

パフォーマンス向上のためには、HuggingFaceのモデルキャッシュを事前にローカルに保存しておく。これにより、RunPodの課金開始後にダウンロード時間を短縮できる。また、vLLMの–host-cpu-workersパラメータを調整し、CPUリソースの利用効率を高める。特に、ツール呼び出し機能を活用する場合、CPU側のプロセスを高速化することで全体の応答速度が改善する。

今後の展望と発展の可能性

量子化技術の進化により、今後はINT3やFP6圧縮が主流になる可能性がある。これにより、4xB200構成で2兆パラメータモデルを動かすことも現実的になる。また、MoEアーキテクチャの進化により、アクティブパラメータ数をさらに抑える技術が登場する見込み。これにより、従来の30Bモデルと同等の性能を維持しながら、パラメータ数を10倍に増やすモデルが実現される。

RunPodのB200在庫増加により、8xB200構成の普及が進むと予測される。これにより、1000Bパラメータを超えるモデルもローカルで動かせるようになる。また、vLLMの進化により、現在の4xB200構成でさらにパフォーマンスが向上し、リアルタイム処理が可能になる。特に、ツール呼び出し機能の最適化により、複数モデル間の連携がスムーズに進む。

業界ごとのカスタマイズモデルが登場する可能性も。例えば、医療分野では医療用語を強化したMoEモデル、金融分野ではリスク分析に特化したモデルが開発される。また、マルチモーダル処理の進化により、音声や画像を含む複雑な入力も対応可能になる。これらは、特定の業界でのAI活用をさらに加速する。