Kimi K3 vLLM OOMは調整か拡張か

vLLM公式recipeは2026年8月14日に更新され、Kimi K3向けにCUDA 13専用イメージ、R580以上のNVIDIAドライバー、対応ハードウェアが明記されています。(recipes.vllm.ai)

読み込み時にOOM → 同時実行数ではなく、ドライバー、イメージ、GPUトポロジーを先に確認します。
実行時にOOM → 文脈長、同時実行数、prefix cachingを同じリクエスト集で調整し、それでも余裕がなければ拡張します。

個人研究者やPOCチームは、まずAPI、ツール呼び出し、推論チェーンを成立させることが目標です。小規模Agentチームは、実際の接頭辞再利用を残したまま安定境界を探します。プラットフォームや本番チームは、起動成功ではなく目標負荷で判断してください。

Kimi K3 vLLM OOMの判定軸

最初に見るのは、OOMがログのどこで発生したかです。モデル初期化、重み読み込み、ランク起動の途中で停止し、Ready状態にならないなら「読み込み時OOM」と扱います。最初のリクエストを送る前に落ちるため、同時実行数を下げても効果は限定的です。

一方、エンジンが初期化され、最初の応答も返るのに、長い入力や複数セッションでOOMが出るなら「実行時OOM」です。この場合は文脈長、同時実行数、KVキャッシュ、Agentの接頭辞再利用が主な調整対象になります。

Kimi K3は2.8兆パラメーター規模のMoEで、1トークンあたり896専門家のうち16専門家を使用し、最大100万トークンの文脈に対応すると公式説明されています。したがって、起動できたことと、長文Agentを安定運用できることは別の判定です。(recipes.vllm.ai)

個人検証とPOCの小さな成功

個人研究者やPOCチームでは、最初から本番の文脈長や同時実行数を再現する必要はありません。APIが返るか、ツール呼び出しの形式が扱えるか、推論結果を後段へ渡せるかを確認するため、入力を短くし、同時実行を1系統に限定し、追加機能を一度に有効化しない方が切り分けやすいです。

ただし、ここで得られる結論は「機能検証に使える」という範囲に限られます。公式recipeではKimi K3のNVIDIA向けに、少なくとも8基のGB300と、実運用ではマルチノードが示されています。AMD向けにも少なくとも8基のMI355XまたはMI350Xが記載されています。(recipes.vllm.ai)

POC環境がこの前提から外れていて、重みの読み込みそのものが完了しないなら、max-model-lenや同時実行数を細かく変え続けるべきではありません。停止条件は明確です。

• [ ] vLLMの公式Kimi K3イメージを使用している
• [ ] CUDA 13のビルドとホスト側ドライバーの条件を確認した
• [ ] エンジン初期化完了と最初の応答をログで確認した
• [ ] 低負荷で成功したことを「本番容量」と混同していない
• [ ] 対応トポロジー外なら、別環境で検証する判断をした

この段階では、MacHTMLのコンソール利用方法を確認し、必要な期間だけ検証環境を確保する方法も比較対象になります。長期運用ではなく、原因切り分けのための一時利用に限定すれば、自前クラスターを先に改修するよりリスクを抑えやすいです。

小規模Agentチームの負荷調整

小規模Agentチームは、単純な短文ベンチマークではなく、固定システムプロンプト、ツール定義、過去の会話、ツール結果を含む実リクエストを使ってください。これらは文脈占用量を増やすだけでなく、同じ接頭辞が繰り返されることでprefix cachingの効果にも影響します。

公式のvLLMブログでは、Kimi K3のprefix cachingはハイブリッド構造に合わせて設計され、KDA状態と通常のKVキャッシュを扱うと説明されています。また、クイックスタートでは--enable-prefix-cachingを明示しています。つまり、設定を書かずに有効だと決めつけず、実際の起動引数とメトリクスを確認する必要があります。(vllm.ai)

調整は一度に一項目だけにします。

1. 代表的なAgentリクエストを保存します。
2. 文脈長の上限を下げ、同じ入力を再送します。
3. 同時実行数を下げ、ピーク時のGPUメモリを記録します。
4. prefix cachingを有効にした状態で、ヒット状況と保持量を確認します。
5. キャッシュ保持方針を変え、同じリクエスト集で再測定します。
6. OOM回数、応答失敗、キュー滞留、応答時間の変化を比較します。

キャッシュをすべて切れば起動できる、という結果は修復とは限りません。固定のツール定義やシステムプロンプトが頻繁に再利用されるなら、キャッシュを残した構成の方が本番の挙動に近いからです。逆に、毎回異なるプロンプトしか来ないなら、保持量だけが増えて効果が出ない可能性があります。

注意：短いテスト文だけでOOMが消えても、Agentサービスの容量問題が解決したとは判断しないでください。前後比較には同じリクエスト集、同じイメージ、同じ並列構成を使います。

プラットフォーム運用の環境確認

既存GPUクラスターを持つチームは、設定を変える前に「どこまで自分たちで変更できるか」を確認します。コンテナだけ更新できるのか、ホストドライバーを更新できるのか、ノード間のRDMAやNVLink経路を変更できるのかで、現実的な選択肢が変わります。

公式recipeでは、Kimi K3のCUDAイメージはCUDA 13のみで、cu129タグはないとされています。ホスト側はR580以上が必要で、R575相当の環境ではドライバー更新、またはK3用ブランチからの自前ビルドが必要と説明されています。(recipes.vllm.ai)

自前ビルドを選べるのは、ホスト、カーネル、通信層まで管理できるチームです。コンテナだけを差し替えて環境不一致を隠す方法は、次回のvLLM更新や障害対応で再び同じ問題を招きます。ドライバーを更新できない、公式イメージを固定できない、ノード間通信を確認できないという条件が重なるなら、移行または一時的な外部環境の方が保守負担を見積もりやすいです。

マルチノードではGPU数だけを足し算しないでください。公式recipeはRDMA向けとNVLink向けでall2allバックエンドを分け、構成に応じた通信設定を示しています。通信経路が合わないままGPUだけ追加すると、メモリ不足ではなく初期化失敗や通信待ちが残る可能性があります。(recipes.vllm.ai)

本番チームの調整と拡張

本番の判断材料は、少なくとも次の4点です。

• 想定する最大文脈長
• 同時に動くAgentセッション数
• システムプロンプトやツール定義の再利用率
• 障害時の再試行、フェイルオーバー、復旧要件

この負荷でエンジンが安定し、ピーク時にも十分なメモリ余力が残るなら、現在の構成を維持して監視へ進めます。文脈長や同時実行数を合理的な範囲で下げれば安定するものの、業務要件を満たさなくなるなら、調整ではなく容量不足です。

公式ブログは、PrefillとDecodeを分離する構成、専門家並列、データ並列などを大規模提供の選択肢として説明しています。検証済み構成の一例として、TEP8のPrefillからDEP16のDecodeへ分ける構成も示されていますが、これは特定の通信・ノード構成での話です。GPU数だけを同じように並べれば再現できるという意味ではありません。(vllm.ai)

また、公式ブログの速度値は16基のNVIDIA GB300 NVL72という特定トポロジーで測定されています。118 token/sや370 token/sという値を、別のGPU世代や単一ノードへそのまま外挿してはいけません。(vllm.ai)

本番で拡張へ進む条件は、次のように置くと判断しやすくなります。

• 目標負荷でOOMが再現し、文脈長を下げると業務要件を満たせない
• prefix cachingを残した状態でピークメモリの余裕が消える
• 同時実行数を制限するとキュー滞留やタイムアウトが発生する
• PrefillとDecodeの偏りを調整しても、通信またはメモリがボトルネックになる
• 障害復旧用の予備容量を確保できない

再測定から移行判断へ

再測定では、数値だけでなく再現条件を保存します。最低限、コンテナイメージ、vLLMの版、CUDAとドライバーの組み合わせ、起動引数、並列方式、ノード間通信、入力リクエスト、最大出力長、ピークGPUメモリを記録してください。

vLLMの更新でKimi K3のrecipe、キャッシュ保持、対応イメージ、最低ハードウェア条件が変わった場合は、同じ記録を使って再実行します。公式recipeはvLLM 0.27.1以上を表示していますが、実際に利用する版の対応状況は、公開ページと起動ログの両方で確認してください。(recipes.vllm.ai)

判断は3段階で十分です。

• 低負荷の機能検証だけ成功：最小環境を維持し、本番容量とは分離します。
• 目標負荷を合理的に下げれば安定：制限値を文書化し、監視付きで運用します。
• 重みを読み込めない、または本番余力がない：公式条件に合う環境へ移行するか、マルチノードを含めて拡張します。

既存環境では、CUDA 13やR580以上の条件を満たせないことと、純粋なGPU容量不足が混ざりやすくなります。MacHTMLのヘルプページで利用条件を確認し、必要なら料金プランと比較しながら、同じリクエスト集を短期間のクラウド算力環境で再現してください。

現在のクラスターを使い続ける方法は、ホスト更新の権限不足、公式イメージとの差分、ノード間通信の確認負担、検証中に本番資源を占有するリスクが弱点です。Kimi K3 vLLM OOMが環境不一致なのか容量不足なのか切り分けられない段階では、MacHTMLのレンタル環境で同じ構成とリクエストを期間限定で比較し、その結果をもとに調整、移行、拡張の順番を決める方が、無計画なGPU追加より安全です。

よくある質問