Kimi K3 vLLM起動失敗：ドライバーか環境か

2026年8月3日更新のvLLM公式レシピでは、Kimi K3用DockerイメージはCUDA 13、つまりcu130ビルドのみで、ホスト側にはr580以上のNVIDIAドライバーが必要です。r575の共有クラスターでKimi K3 vLLM起動失敗が発生しているなら、まず起動オプションを増やすのではなく、ドライバー更新か隔離環境への切り替えを判断してください。(recipes.vllm.ai)

症状：cu130イメージをr575ホストで起動すると、CUDA初期化やカーネル読み込みで停止する。
最短解法：保守枠があるならr580以上へ更新し、共有クラスターを止められないなら互換環境へ移します。

この記事は、既存GPUクラスターで復旧を急ぐインフラ担当者、共有ノードの変更承認を行うプラットフォーム責任者、Kimi K3とAgentの連携検証を止めたくない開発チーム向けです。すでにログを取得できる状態で、アップグレード、再構築、環境変更のどれを選ぶかに迷っている場合に使ってください。

最終更新：2026年8月5日。ドライバー、イメージ、prefix cachingの情報は、vLLM公式Kimi K3レシピ、vLLMのK3公開ブログ、NVIDIA CUDA互換性資料で確認しています。

起動直後は修正より証拠の固定を優先する

失敗した現場でよくあるのが、--max-model-len、並列数、メモリー関連の引数を順番に変更し、同じノードで何度も再起動することです。この方法では、環境不一致と設定ミスの境界が消えます。特にcu130とr575の組み合わせを、単純なOOMやモデル容量の問題として扱うと、調査時間だけが延びます。

最初に次の情報を保存してください。

• 使用したDockerイメージの完全なタグ
• vLLMの取得元、ブランチ、コミットまたはパッケージ版
• nvidia-smiで確認したドライバー分岐とGPU一覧
• コンテナランタイム、NVIDIA Container Toolkit、ホストOS
• 起動コマンド、環境変数、完全な標準出力とエラーログ
• ノード間通信を使う場合のNCCL、RDMA、NVLink関連ログ

公式レシピは、Kimi K3用イメージにcu129タグがなく、K3対応wheelもcu129のnightly indexにはないと説明しています。r575ホストでは、ドライバーを更新するか、K3ブランチをcu129向けに自分でビルドする必要があります。したがって、ログにCUDA初期化、ドライバーAPI、イメージのランタイム不一致が出ているなら、まず環境互換性を疑います。(recipes.vllm.ai)

第一判定はCUDA 13とドライバー分岐の組み合わせで行う

Kimi K3のcu130イメージはr575で動かせますか。

標準のcu130イメージをそのまま使う前提では、r575を適合環境とは扱わないでください。NVIDIAの互換性表では、CUDA 13.xのマイナーバージョン互換性に必要な最小ドライバーはr580以上です。一方、CUDA 12.xはr525以上が基準ですが、CUDA 13向けのランタイムをr575で解決できるという意味ではありません。(docs.nvidia.com)

ここで確認すべきなのは、次の3点です。

1. コンテナ内のCUDAランタイムがcu130か。
2. ホストの実ドライバーがr575かr580以上か。
3. GPU、カーネル、コンテナランタイムが公式レシピの想定に入っているか。

この3点のうち、cu130とr575の不一致が確認できたら、モデルパラメーターを増減する前に復旧経路を選びます。逆に、r580以上でCUDA初期化を通過している場合は、通信バックエンド、GPU数、モデル読み込み、ツール呼び出し設定を別の調査線に分けます。すべての起動失敗をドライバー更新で解決できるわけではありません。

当日復旧なら、更新・再構築・隔離を条件で分ける

Kimi K3のデプロイでは、ドライバー更新とvLLM再ビルドのどちらを先に行うべきですか。

結論は、クラスターの変更権限と復旧期限で決まります。以下の表を、起動失敗後の一次判断に使ってください。

保守枠があり、GPUノードを段階的に検証できるなら、r580以上への更新を第一候補にします。公式レシピの前提に近く、独自ビルドを長期保守する負担を避けられるためです。

共有クラスターを止められない場合は、隔離環境を先に確保します。cu129の自前ビルドは、依存パッケージ、FlashInfer、PyTorch、vLLMブランチを固定し、更新時に再ビルドできるチームだけが選ぶ過渡策です。単に「cu129なら動くはず」と考えて、本番の標準環境に採用するのは避けてください。

MacHTMLのコンソール利用案内を確認する場合も、Kimi K3本体をMac上で実行できると解釈してはいけません。K3のGPUサービングと、Mac側で行うAgentクライアント、API接続、ツール呼び出し検証は分けて設計します。

変更前後で回帰範囲を固定する

ドライバー更新は、コンテナ内のCUDAだけを変える作業ではありません。ホストカーネル、GPUデバイス公開、NVIDIA Container Toolkit、NCCL、RDMA、既存ジョブのスケジューラーまで影響します。

変更前に、次の基線を保存してください。

• 対象ノードのドライバー、カーネル、GPU状態
• 稼働中ジョブ、予約済みジョブ、停止可能なワークロード
• コンテナランタイムとGPUデバイスの公開状態
• NCCL、RDMA、NVLink、ネットワークインターフェースの構成
• 既存モデルの短時間推論と通信確認の結果
• ロールバックするパッケージ、イメージ、設定ファイルの保管場所

実行コマンドはディストリビューション、ドライバー配布方式、オーケストレーターによって異なります。固定のコマンドをそのまま貼り付けるより、利用中のプラットフォーム公式手順に合わせてください。NVIDIAはCUDA 13.xについてr580以上を互換性の基準として示しており、後続ドライバーへの後方互換性も説明していますが、既存アプリケーションの回帰試験が不要になるわけではありません。

次の順番で拡大します。

1. 1台の隔離ノードでドライバー更新または新環境を適用する。
2. nvidia-smi、コンテナ内CUDA、GPU認識を確認する。
3. Kimi K3のモデル読み込みだけを実行する。
4. 短いテキストリクエストと画像入力を分けて確認する。
5. 複数GPUの通信を確認する。
6. 問題がなければ、同じ構成を少数ノードへ広げる。
7. 既存ワークロードを戻し、監視期間を設ける。

次のチェック項目を、変更記録にそのまま貼り付けて使えます。

• [ ] cu130イメージとホストドライバー分岐を記録した
• [ ] 既存ジョブと通信設定の基線を保存した
• [ ] 隔離ノードでKimi K3のモデル読み込みを確認した
• [ ] 単一リクエスト、画像入力、ツール呼び出しを個別に確認した
• [ ] 複数GPUまたは複数ノード通信を確認した
• [ ] 失敗時に元のドライバーとイメージへ戻す手順を確認した
• [ ] 共有クラスターへ拡大する承認条件を決めた

このチェックを満たせない共有環境では、現行ノードの変更を止めて隔離環境へ切り替えます。復旧を急ぐ場面で、全ノードを同時に変更することが最大のリスクです。

起動後はprefix cachingと通信を別々に再検証する

Kimi K3のサービスが起動したのにprefix cachingが効かないのはなぜですか。

Kimi K3では、prefix cachingはデフォルトで無効です。起動コマンドに--enable-prefix-cachingを明示してください。vLLM公式ブログでは、KDAの再帰状態と通常のKVキャッシュを扱うハイブリッド設計のため、通常のvLLMと同じ前提で判断しないよう説明されています。(vllm.ai)

ただし、フラグを追加しただけで毎回キャッシュヒットするわけではありません。次の3つを分けて確認します。

• パラメーター未設定：起動コマンドにフラグがない。
• 共有プレフィックス不一致：システムプロンプト、ツール定義、履歴、画像入力の順序がリクエストごとに異なる。
• 保持設定と容量の問題：再利用前にキャッシュが破棄されている。

同じシステムプロンプトとツール定義を使い、入力末尾だけを変えたリクエストを繰り返します。初回と2回目以降で、プロンプト処理時間、キャッシュ関連メトリクス、GPUメモリー、応答内容を保存してください。内容が少しでも変わる実運用リクエストを比較対象にすると、ヒットしない原因をprefix cachingの不具合と誤認します。

vLLMの公式起動例にも--enable-prefix-cachingが含まれています。ツール呼び出しを使う場合は、キャッシュとは別にスキーマ検証を行ってください。公式ブログは、Kimi K3が一部の入力で期待と異なるtool-call形式を返す可能性にも触れています。

最初の負荷試験はモデル・通信・Agentを分離する

起動後にいきなり本番相当の長文、画像、並列リクエストを流すと、OOMと通信障害の切り分けが難しくなります。次の順番で負荷を上げてください。

1. モデル読み込みとAPIヘルスチェック。
2. 短いテキストの単一リクエスト。
3. 目標コンテキスト長に近い単一リクエスト。
4. 同一prefixを使った複数リクエスト。
5. 低い並列数からの段階的な同時実行。
6. 画像入力とツール呼び出し。
7. 複数ノード、RDMA、NVLinkを使う通信試験。

OOMが出た場合は、まずコンテキスト長、同時実行数、KVキャッシュ保持量、モデル読み込み方式を確認します。通信エラーなら、all-to-allバックエンド、NCCL、RDMA、GPU間接続を別の記録として調べます。公式レシピは、RDMAではdeepep_v2、NVLinkではflashinfer_nvlink_one_sidedを案内しています。(recipes.vllm.ai)

vLLMの公開記事では、Kimi K3の提供に少なくとも8基のB300またはGB300構成が示されています。これは公式レシピ上の起動前提であり、あなたのコンテキスト長、同時実行数、通信構成で必要容量や性能が同じになるという意味ではありません。性能値を導入判断に使う場合は、公式ベンチマークの条件を一致させてください。

安定観察後に一時環境を長期化するか決める

隔離環境で起動できた時点では、まだ移行完了ではありません。少なくとも次の観点を同じ入力セットで比較します。

• 起動失敗が再現しなくなったか
• モデル読み込みと再起動が安定しているか
• prefix cachingのヒット条件が説明できるか
• Agentのツール呼び出し、再試行、構造化出力が正常か
• 複数ノード通信でエラーが出ないか
• 監視、ログ保存、権限管理を継続できるか
• 共有クラスターへ戻す場合の切り戻し条件が明確か

記録は「動いた／動かない」ではなく、次の形式にします。

• 採用経路：r580以上へ更新、cu129自前ビルド、または隔離環境
• 採用理由：変更可能な時間、復旧期限、依存関係の保守能力
• 確認済み範囲：モデル読み込み、短文、長文、画像、Agent、通信
• 未確認範囲：本番同時実行、長時間稼働、障害復旧
• ロールバック条件：ドライバー、イメージ、ノード割り当てを戻す基準
• 再評価日：公式cu129対応や安定版対応が確認された場合の見直し

現時点では、公式cu129イメージの提供時期や、Kimi K3の安定版での対応範囲を前提に計画しないでください。将来のイメージ追加やデフォルト設定変更は未確定です。公式レシピの更新日とイメージ一覧を、変更前に再確認します。

r575の共有GPUクラスターを使い続ける場合、現行環境には「既存ジョブへの影響」「NCCLやカーネルの回帰」「ロールバック時間」という弱点があります。cu129の自前ビルドにも、依存パッケージの固定、再ビルド、脆弱性対応を自社で担う負担があります。そのため、Kimi K3本体の長期サービングでは公式cu130前提に合わせられる環境が合理的ですが、AgentのAPI連携やクライアント側の回帰検証だけなら、底層GPUをすぐに変えず分離して進める方が安全です。

共有クラスターを今日変更できず、Kimi K3とAgentの連携確認を止めたくない場合は、MacHTMLの利用サポートで隔離した作業環境の運用条件を確認してください。MacHTMLのレンタル環境はKimi K3用NVIDIAサービングの代替ではありませんが、APIクライアント、Agentのツール連携、回帰試験、運用スクリプトの検証を本番クラスターから切り離す用途には向いています。長期的なK3推論基盤は公式要件に沿ったGPU環境で判断し、MacHTMLは「先に検証を再開し、後で移行を決める」ための一時環境として使うのが現実的です。

料金や利用条件を比較する場合は、MacHTMLの日本向けプランを確認し、必要な期間と作業範囲を先に決めてください。

関連記事: Kimi K3をAPIで運用する際の選択肢と判断基準 Kimi K3のローカル構築に必要な1.4TB級ハードウェア要件