1兆パラメータ開放モデル自前運用の判断

1兆パラメータ開放モデル自前運用での勝者は、常設クラスターではなく、まずAPIまたは期間限定クラウドで実負荷を確認する方式です。モデルの重み、KVキャッシュ、実行時メモリ、分散通信、障害対応まで検証できるチームだけが、長期の自前運用へ進むべきです。

この記事は、Kimi K3やDeepSeek V4の活性化パラメータが少ないために、GPUメモリを小さく見積もろうとしているプラットフォームエンジニア向けです。MLOps責任者やAI Agentチームが、API、短期検証、長期クラスターのどれを選ぶか判断する材料も整理します。

活性化パラメータと常駐重み

最初の失敗は、活性化パラメータをそのままGPUメモリの計算式へ入れることです。MoEモデルでは、1トークンごとに一部の専門家だけが計算へ参加します。しかし、計算に使わない専門家の重みまで自動的に消えるわけではありません。

区別すべき変数は次の4つです。

Kimi K3については、コミュニティ解説で総パラメータ約2.8T、活性化規模約50B、MXFP4重みと説明されています。ただし、これは公式モデルカードそのものではありません。容量や互換性の結論へ使う前に、Kimi K3に関する公開解説と公式ウェイト、ライセンス、推奨ランタイムを別々に再確認する必要があります。

DeepSeek V4もMoEモデルとして公開されていますが、FlashやProなど系列ごとに仕様が異なります。公式のDeepSeek透明性ページとDeepSeek V4の公式API仕様で、対象バージョンを固定してから見積もるべきです。

低ビット化と実効容量

「4bitなら1パラメータ0.5バイト」という計算は、重みの理論下限を作るための出発点にすぎません。実際の容量には、グループ単位のスケール値、ゼロ点やメタデータ、未量子化層、テンソルの配置、ファイル形式、ロード方式が加わります。

Hugging Faceの量子化資料でも、4bitや8bitの方式は複数あり、量子化設定によって対象となる層や計算時のデータ型が変わります。公式の量子化ドキュメントでは、int4、int8、float8などが別の設定として扱われています。

したがって、MXFP4、FP4、FP8という表記だけで「このノード数で動く」と断定するのは危険です。対象モデルのモデルカード、推論エンジンの対応表、量子化実装のロード条件を突き合わせる必要があります。

重み容量と実行時メモリ

重みを配置できても、起動直後にメモリ不足となるケースがあります。原因は、生成中に増えるKVキャッシュ、アクティベーション用テンソル、通信バッファー、グラフコンパイル領域、フレームワークの予約領域です。

KVキャッシュは、過去トークンのKeyとValueを保持して再計算を避ける仕組みです。Hugging FaceのKVキャッシュ公式ガイドでも、動的キャッシュ、固定キャッシュ、量子化キャッシュ、CPUオフロードでメモリ使用量と速度の関係が変わると説明されています。

次の条件を固定しない容量表は、実運用の見積もりになりません。

• 最大コンテキスト長
• 入力と出力のトークン分布
• 同時実行数
• バッチ方式と連続バッチの有無
• KVキャッシュの精度とオフロード設定
• 推論エンジンとバージョン
• ツール呼び出し後の再試行回数

特にAI Agentでは、1回の回答だけで終わりません。計画、検索、ツール実行、結果の検証、再試行が続きます。短い質問を1件通しただけでは、実際のメモリピークを確認できません。

単一ノードと多ノードの分岐

量子化後のモデルファイルが1台のストレージに置けても、単一マシンで安定稼働できるとは限りません。GPUメモリへ全重みを配置できるか、ロード中の一時領域を確保できるか、KVキャッシュを増やせるかを別々に確認します。

ノードを増やせば、GPUメモリの合計は増えます。しかし、MoEモデルでは専門家のルーティングとテンソル交換が発生します。ノード間の帯域、通信遅延、ストレージ読み込み、故障時の再配置が新しい制約になります。

推論エンジンが対応していても、特定モデルの全機能や量子化形式まで安定しているとは限りません。分散実行の確認には、vLLMの分散推論資料や、対象モデルの公式実装記録を使い、起動だけでなく継続負荷まで確認します。

短文試行とAgent負荷

典型的な誤判定は、短いプロンプトを1件送って応答が返った時点で「自前運用できる」と判断することです。これはロード確認にはなりますが、サービス確認ではありません。

実際の試験では、次の入力群を用意します。

1. 通常の短文質問。
2. 長いシステム指示と会話履歴。
3. 複数回のツール呼び出し。
4. 入力長と出力長が異なる混在リクエスト。
5. ピーク時の同時実行。
6. タイムアウト後の再試行。
7. ノード停止後の復旧操作。

各試験で記録するのは、初回トークン遅延、安定時のトークン速度、GPUメモリピーク、ホストメモリ、通信使用量、エラー率、復旧時間です。速度の平均値だけでは、ピーク時に詰まる理由が分かりません。

自前運用の撤退線

自前運用を続ける条件は、モデル名だけでは決まりません。次の4つが同時に閉じている必要があります。

• 公式ウェイトとライセンスを確認できる。
• 重みと実行時メモリが同じ構成で収まる。
• 実際のAgent負荷で必要な応答速度を満たす。
• 更新、監視、障害復旧の担当者を確保できる。

どれか1つでも欠ける場合は、長期クラスターを購入する前にAPIまたは期間限定クラウドへ戻します。DeepSeek V4は公式APIで1Mコンテキストやモデル別の同時実行制限が案内されていますが、APIの利用条件と自前ウェイトの運用条件は同じではありません。公式API仕様を、コストだけでなく同時実行とデータ取り扱いの確認にも使います。

自前運用へ進む前の判定表

自前運用を選ぶべきなのは、研究目的で一時的に起動するチームではなく、同じモデルを一定期間使い続け、負荷の予測と障害対応まで持てる組織です。反対に、モデルを比較中で入力分布も決まっていない場合は、固定設備を先に持つと判断を縛ります。

ProxyMacへ相談する前の準備

現在の構成が短期クラウドやAPI中心の場合、主な弱点は、実負荷を再現しにくいこと、利用時間と料金が読みにくいこと、分散構成の検証結果を長く保持しにくいことです。自前GPUクラスターへ移ると、初期投資、更新、障害対応、アイドル時間の負担が増えます。

そのため、制御端末と重量級の推論基盤を分ける方式が現実的です。Mac側で開発、監視、設定管理を行い、重み層は必要な期間だけクラウド環境で検証します。ProxyMacのコンソール案内やヘルプページを確認し、試験端末と推論基盤の責任範囲を分けておくと、長期クラスターへ進む前の比較がしやすくなります。

自前で固定GPUを持つべきなのは、長時間の安定負荷、物理接続、専用ネットワーク、厳格なデータ保管が必要な場合です。一方、Kimi K3やDeepSeek V4のような大規模MoEモデルを評価中で、まだ負荷と採用モデルが固まっていない場合は、ProxyMacを含むMac環境を制御端末として使い、推論部分だけを期間限定で検証する方が、判断を誤ったときの撤退コストを抑えやすくなります。

FAQ

関連記事

• 大規模モデルをAPIとローカルの総コストで比較する
• 開放モデルの自社運用コストと利用条件を確認する