Kimi K3 vLLM 本番導入の受け入れ基準

Kimi K3 vLLM 本番導入の受け入れ基準は、プロセスの起動成功ではなく、互換性、負荷時のリソース余力、prefix cachingの実ヒット、Agent APIの正確性がすべて確認できることです。1項目でも公式要件から外れる場合は環境を再構築し、継続的なOOMや待ち行列が出る場合は設定の小手先変更ではなく、構成変更または増強へ進みます。

この基準は、Kimi K3 vLLMをすでに起動でき、検証環境から本番へ移行したい推論エンジニア向けです。SRE、GPUクラスタ運用者、容量判断を行う技術責任者、短期の検証環境を調達する担当者にも適しています。

※ 最終更新：2026年8月13日。vLLM公式レシピ、公式リリース記事、NVIDIAのCUDA互換性資料を照合しています。Kimi K3の対応状態はpre-release表記のため、導入前に公式Kimi K3レシピを再確認してください。

起動成功と本番合格は別の判定です

Kimi K3の受け入れ結果は、次の4種類に分けると運用しやすくなります。

• 導入可：公式のコンテナ、vLLM、CUDA、ドライバー条件を満たし、代表的なAgent負荷でOOM、異常終了、想定外のtool callがなく、キャッシュ指標にも再利用が現れている状態です。
• 制限付き観察：重大な機能は動作するものの、同時実行数、入力長、キャッシュ利用量などに明確な制限が必要な状態です。公開範囲と上限を決めてから運用します。
• 環境再構築：イメージとホストのドライバー系列が合わない、独自ビルドの依存関係が記録されていない、起動ログに互換性警告が残る状態です。
• リソース増強：互換性は合っている一方、長い入力、同時実行、継続運転でKVキャッシュ、待ち行列、GPUメモリが継続的に逼迫する状態です。

短いプロンプトを1回送って応答が返るだけでは、最も危険な長文入力と多段ツール呼び出しの負荷を評価できません。固定のシステムプロンプト、ツール定義、会話履歴、構造化出力を含む代表サンプルを保存し、同じ条件で再実行できるようにします。

第一段階：CUDA 13とNVIDIA R580の互換性を三方向から確認します

公式レシピでは、Kimi K3向けDockerイメージはCUDA 13、ホスト側はNVIDIA R580以上が前提です。レシピにはvLLM 0.27.1以上、専用イメージ、最低8基のGB300、実運用ではマルチノード構成という記載があります。これは一般的なGPU目安ではなく、現在の公式レシピに記載された条件として扱います。公式レシピの前提条件

CUDA 13のビルドとR580ドライバーの関係は、次の3か所を照合します。

1. コンテナ内でCUDAランタイムとvLLMのビルド情報を保存します。
2. ホストでドライバーの実バージョン、GPU型式、GPU枚数を記録します。
3. vLLM起動ログでCUDA初期化、通信バックエンド、カーネル読み込みの結果を確認します。

nvidia-smiの表示だけで合格にしてはいけません。同コマンドが示すCUDAバージョンは、アプリケーションがビルドされたCUDAランタイムそのものではありません。NVIDIAの互換性表ではCUDA 13.xの最低ドライバー系列はR580です。NVIDIA CUDA互換性表また、データセンター向けドライバー表でもR580はCUDA 13をサポートする系列として整理されています。NVIDIAドライバーとCUDAの対応表

R575などのホストをそのまま公式イメージへ接続する判定は「たぶん動く」ではなく不合格です。独自に別CUDA環境でビルドする場合は、コミット、PyTorch依存、コンパイル日時、再現手順、ロールバック用イメージを別記録にします。公式イメージの検証結果と混在させないことが重要です。

Kimi K3のCUDAとドライバーはどこまでそろえば合格か

合格条件は「CUDA 13のコンテナ」と「R580以上のホストドライバー」が同じ検証記録に存在し、起動ログと推論ログがその構成で取得されていることです。ホストだけ新しくても、古いvLLMホイールや別タグのイメージを使っていれば、Kimi K3用環境の合格証拠にはなりません。

次の状態なら、OOM対策やキャッシュ調整より先に環境を作り直します。

• Kimi K3用ではないイメージを使用している。
• CUDA 13のビルド情報を保存していない。
• R580未満のドライバーで起動を試している。
• vLLMのバージョンと取得元を固定していない。
• ノードごとにドライバーやコンテナタグが異なる。
• 起動ログに通信、カーネル、NCCL関連の警告が残っている。

第二段階：OOMを発生箇所ごとの資源結論に変えます

OOMは1種類ではありません。モデル読み込み直後なら重みとGPUトポロジー、長い入力の直後ならコンテキスト設定やKVキャッシュ、同時実行を増やした後ならスケジューラーとキャッシュ圧迫、継続運転後なら断片化や再利用不足を疑います。

圧力試験は次の順で記録します。

1. モデル読み込み：全ノードのGPU枚数、通信初期化、起動完了時のメモリ状態を保存します。
2. 長文入力：本番で想定するシステムプロンプト、履歴、ツール定義を含めます。
3. 同時実行：段階的に並列数を増やし、待ち時間と処理中リクエスト数を記録します。
4. 継続運転：同じ入力だけでなく、冷たい入力、共有プレフィックス、ツール付き入力を混ぜます。
5. 再起動確認：OOM後にプロセスが正常終了し、再起動後も同じ条件で復旧できるか確認します。

保存すべき証拠は、OOM前後のGPUメモリ曲線、リクエストの入力長、max_tokens、同時実行数、GPUトポロジー、vLLMログです。一般的な「何GBあれば足りる」という数字は、Kimi K3の構成、並列方式、入力長、画像入力、キャッシュ設定を無視するため、受け入れ基準には使えません。

注意：長いコンテキストを使えることと、長いコンテキストを高い同時実行数で安定処理できることは別です。Kimi K3の公式資料は最大1Mトークンのコンテキストを記載していますが、実際の導入可否は対象GPUと負荷サンプルで決めます。公式モデル概要

prefix cachingはフラグではなく再利用で判定します

Kimi K3では、prefix cachingを明示的に有効化する起動例が示されています。公式記事の起動例にも--enable-prefix-cachingが含まれていますが、フラグが存在するだけでは機能が実効化した証拠になりません。Kimi K3公式起動例

確認用の対照リクエストを作ります。1回目は冷たいリクエスト、2回目以降は同じシステムプロンプト、同じツール定義、同じ共有コンテキストを使い、末尾のユーザー質問だけを変えます。入力全体を毎回変えると、キャッシュミスなのかサンプル設計の失敗なのか判定できません。

/metricsでは、次の指標を同じ時間窓で保存します。

• vllm:prefix_cache_queries
• vllm:prefix_cache_hits
• vllm:prompt_tokens_cached
• vllm:request_prefill_kv_computed_tokens
• vllm:kv_cache_usage_perc
• vllm:e2e_request_latency_seconds

vLLMの公式メトリクス資料では、prefix cacheの問い合わせ数、ヒット数、キャッシュ済みプロンプトトークン、KVキャッシュ利用率などが公開されています。vLLM本番メトリクス

合格判定は、2回目以降にヒット指標が増え、キャッシュ済みトークンが記録され、プリフィル時間や全体遅延にも再利用による変化が現れることです。ヒット数だけが増えても入力が短すぎる、またはキャッシュ利用率が逼迫している場合は、性能改善として認定しません。

Kimi K3のprefix cachingが本当に生きているかを切り分けます

Kimi K3は通常のKVキャッシュだけでなく、KDAの状態も扱うハイブリッド構成です。公式記事では、KDA状態をすべてのトークン位置に保存するのではなく、プロンプト末尾や一定間隔のチェックポイントを保持する方式が説明されています。ハイブリッドキャッシュの公式説明

そのため、次のようなテスト結果は「無効」と即断しません。

• 初回リクエストだけで終了している。
• 共有部分がトークン単位で一致していない。
• ツール定義の順序やJSON表記が毎回変わっている。
• キャッシュが容量不足で退避している。
• KDA状態の保持境界とテスト入力の境界が合っていない。

冷たい入力と熱い入力を保存し、キャッシュ指標、GPUキャッシュ利用率、プリフィル時間、応答内容を横並びにします。数値上のヒットがあっても、Agentの応答品質やtool callが崩れるなら、キャッシュ機能だけで導入可とは判定しません。

第三段階：Agent APIはtool callと構造化出力まで検証します

本番サンプルには、単純な質問ではなく次の要素を含めます。

• 2回以上の会話ターン
• 複数のツール定義
• 必須項目と任意項目を含むJSON Schema
• ツール結果を受けた再応答
• タイムアウト後の再試行
• ツールを使わない回答への切り替え
• 推論欄、本文、tool_callsの分離

Kimi K3の公式レシピは、ツール呼び出しの形式がパーサーの想定と一致しない場合があるため、スキーマ検証と再試行を推奨しています。Kimi K3公式の注意事項したがって、1回成功したデモを合格証拠にはしません。

vLLMのツール呼び出し資料でも、構造化出力はJSON Schemaに沿った形式を強制できますが、内容の妥当性や実際のツール実行は呼び出し側の責任とされています。vLLMツール呼び出し仕様モデル出力、vLLMパーサー、APIゲートウェイ、呼び出し側のJSON検証を別々にログへ残すと、故障箇所を誤認しにくくなります。

合否を署名できる形にまとめます

受け入れ担当者は、次のチェック項目を1つの記録にまとめます。

• [ ] コンテナタグ、vLLMバージョン、モデル識別子を保存した
• [ ] CUDA 13のコンテナ情報とR580以上のホストドライバーを照合した
• [ ] 全ノードのGPU型式、枚数、通信トポロジーを記録した
• [ ] モデル読み込み、長文、同時実行、継続運転のログを保存した
• [ ] OOM前後のメモリ曲線とリクエスト条件を紐付けた
• [ ] 冷たい入力と熱い入力でprefix cache指標を比較した
• [ ] prefix_cache_queries、prefix_cache_hits、prompt_tokens_cachedを確認した
• [ ] tool call、推論欄、本文、構造化出力をスキーマ検証した
• [ ] 失敗時の再試行とAPI側のフォールバックを確認した
• [ ] 判定者、検証日時、使用サンプル、次の対応を記入した

判定が環境不一致なら再構築です。互換性を満たした後も継続的に待ち行列、KVキャッシュ逼迫、OOMが出るなら、コンテキスト長や並列数を現実的に下げたうえで、なお不足する場合はGPU構成やノード数を見直します。

判定	証拠の状態	次の対応
導入可	4指標すべて合格、再現ログあり	公開範囲と監視を確定
制限付き観察	非重大な遅延や機能制限のみ	同時実行数と利用者を限定
環境再構築	CUDA、R580、イメージ、依存関係に不一致	公式構成へ戻して再試験
リソース増強	互換性は合格、負荷時にOOMや待ち行列が継続	トポロジー、並列数、GPU容量を再設計

本番投入後は、GPUメモリ、kv_cache_usage_perc、待機リクエスト数、プリエンプション、prefix cacheヒット、初回トークンまでの時間、tool callのスキーマ失敗を監視します。公式要件から外れる更新、再現性のないtool call、OOMの再発、キャッシュ逼迫の継続をロールバック条件にします。

Kimi K3のGPU推論基盤そのものは、CUDA 13とR580以上を前提にした専用構成です。一方、一般的なクラウド環境や手元のMacは、CUDA依存、GPUトポロジーの不足、長時間負荷時の容量設計、Agent向け運用監視を別途用意する必要があります。K3の本番推論をMacへ置き換える判断は適切ではありませんが、Agentクライアント、API接続確認、CI、管理画面、短期の検証作業を分離するなら、ProxyMacのMacレンタルを組み合わせる方が、端末購入や社内環境の一時改修より扱いやすい場合があります。

現在のドライバー、コンテナ情報、負荷サンプル、OOM記録を揃えた後、ProxyMacのコンソールやサポート情報で必要な作業環境を確認してください。継続的なGPU推論基盤は専用構成で整え、短期のAgent検証や周辺開発だけをProxyMacへ分離するのが、受け入れ後の運用リスクを抑えやすい選択です。