Kimi K3 vLLM 上線驗收清單

程序已啟動、單次請求也成功，但這不等於 Kimi K3 vLLM 可以上線；最快的判斷方式是先核對 CUDA 13 與 R580 驅動鏈，再完成壓力下的資源驗證、prefix caching 實際命中及 Agent 工具呼叫測試，四項都有證據才可給出 Go 結論。

這篇適合已跑通 Kimi K3 vLLM、準備由測試轉生產的推理工程師。
需要簽署上線結論、控制容量風險的 SRE、平台負責人，以及正在比較自建、臨時擴容或遠端算力環境的技術決策者，都可直接使用以下清單。

最後更新於 2026 年 8 月 13 日；版本與部署條件已核對官方 Kimi K3 recipe、官方發布說明、正式指標文件及 CUDA 相容性文件。Kimi K3 目前仍應按官方 recipe 的 pre-release 狀態驗收，不應把社群 issue 或未合併改動當成穩定版保證。 (recipes.vllm.ai)

先把「可上線」與「能跑起來」分開

Kimi K3 vLLM 上線驗收的獲勝者，是證據完整的環境，不是啟動最快的環境。

可將驗收結論分成四類：

• 可上線：版本鏈符合官方要求；模型載入、長輸入、併發與持續執行沒有未解釋的資源故障；prefix caching 有實際命中；工具呼叫與結構化回應通過 schema 檢查。
• 限流觀察：核心回答與容量可控，但只有非關鍵工具格式、重試路徑或少數邊界樣本仍需觀察。此時必須設定併發上限、錯誤率警報與回滾條件。
• 環境返工：容器標籤、CUDA 建置、宿主機驅動或啟動參數不符合官方 recipe。這類問題應重建映像與依賴鎖定，不應繼續試改一批互不相關的參數。
• 資源擴容：環境鏈正確，但在接近真實 Agent 負載時，顯存、KV 或混合快取、請求排隊、跨節點通訊仍持續飽和。此時應調整上下文、併發或拓撲，再評估增加算力。

驗收樣本不能只用短提示詞。至少要包含固定的系統提示、工具定義、工具結果、多輪對話、結構化輸出及較長的上下文。否則測試只會放大單次請求的樂觀結果。

兼容鏈：CUDA 13 與 R580 驅動要逐層核對

官方 Kimi K3 recipe 目前列出專用容器 vllm/vllm-openai:kimi-k3，並說明該映像是 CUDA 13（cu130）專用建置；同一份 recipe 也要求宿主機使用 R580 或更新的 NVIDIA 驅動。官方頁面同時標示 Kimi K3 recipe 為 pre-release，且列出模型服務需要特定硬體拓撲，不能把一般 vLLM 映像的驗收結果直接套用到 K3。(recipes.vllm.ai)

驗收時應分成三層：

• 容器層：記錄映像完整標籤、vLLM 版本、CUDA runtime、PyTorch 與相關後端版本。
• 宿主機層：記錄實際載入的 NVIDIA 驅動、GPU 型號、GPU 數量、節點名稱及跨節點連線方式。
• 啟動層：保存完整啟動日誌，確認 vLLM 看到的 CUDA、GPU、TP／EP 設定與快取參數，沒有 fallback、載入失敗或 NCCL 初始化警告。

只看 nvidia-smi 顯示的 CUDA 相容資訊不夠。CUDA 應用程式的建置版本、驅動支援範圍與容器實際使用的 runtime，必須交叉核對。可參考官方 CUDA 相容性文件，並將主機端輸出、容器端輸出和啟動日誌放在同一張簽核記錄中。

若團隊自行把 K3 移植到其他 CUDA 環境，這不應與官方容器驗收混寫。記錄至少要包括：

• 自行建置的提交版本與 Dockerfile。
• PyTorch、CUDA、FlashInfer 及其他依賴的鎖定方式。
• 已知差異與未驗證功能。
• 回滾到官方容器的方式與所需時間。

判定原則：只要 R580 驅動不滿足，或容器實際不是 CUDA 13 建置，先判為環境返工；不要用提高 gpu_memory_utilization 或降低併發來掩飾版本不符。

容量驗收：把 OOM 變成可定位的資源結論

Kimi K3 是 2.8 兆參數的混合 MoE，官方資料列出每個 token 啟用 16／896 experts，並支援最高 1M-token context window。這些規格只能說明模型的資源特性，不能直接推導某一組 GPU 的生產容量。實際門檻仍取決於權重格式、平行化方式、上下文設定、併發、快取策略與節點拓撲。(recipes.vllm.ai)

壓力測試建議分四階段，並在每一階段保存請求條件：

1. 模型載入階段：記錄載入前後的 GPU 記憶體、主機記憶體、載入時間及各 rank 狀態。此時 OOM 多半指向權重、初始化或拓撲容量不足。
2. 長輸入階段：固定輸出長度，逐步增加輸入內容，觀察 KV 或混合快取占用、分配失敗與單請求延遲。
3. 併發階段：維持相同 Agent 樣本，逐步增加同時請求數，記錄 running、waiting、排隊時間、cache usage 及 preemption。
4. 持續執行階段：以固定流量運行足夠長的觀察窗口，檢查顯存是否逐步上升、快取是否反覆驅逐、請求是否在沒有新負載時仍失敗。

官方指標文件列出 vllm:kv_cache_usage_perc、vllm:num_requests_running、vllm:num_requests_waiting、vllm:num_preemptions 以及 prefix cache 計數器。這些指標應和 GPU 監控、應用程式請求日誌對齊保存，而不是只截取一張 OOM 錯誤畫面。(docs.vllm.ai)

判斷 OOM 的方式如下：

• 載入即失敗：優先檢查映像、權重格式、GPU 數量、TP／EP／PP 配置，通常屬於環境或拓撲問題。
• 長輸入才失敗：先縮減 max-model-len 或重新估算快取需求，再以同一批樣本重測。
• 併發增加才失敗：觀察排隊、KV 使用率和 preemption；若降低併發後可穩定運行，可先限流，但不能宣稱原容量已通過。
• 持續運行後才失敗：檢查快取驅逐、請求重試、外部 KV 連接器及應用程式是否重複提交。若每次降載後仍回復同一瓶頸，便應評估擴容。

Kimi K3 官方說明也提醒，真正的生產流量需要按硬體代際與跨節點方式規劃，不能以脫離拓撲的「通用顯存數字」作為通過線。

prefix caching：參數存在不代表快取命中

官方發布說明顯示，Kimi K3 的啟動範例需要明確加入 --enable-prefix-caching。官方 recipe 目前也把 prefix caching 的相關行為列入 K3 部署注意事項，因此啟動命令中出現參數，只能證明設定意圖，不能證明請求已成功重用前綴。(vllm.ai)

驗收應建立一組冷熱對照：

• 冷請求：首次送入完整系統提示、工具 schema、共享背景及問題。
• 熱請求：保持前綴逐字相同，只修改最後的使用者問題或工具輸入。
• 負向對照：刻意修改系統提示或工具定義，確認不會把不同前綴誤判成命中。
• 重複測試：至少保存多次冷請求與熱請求結果，避免單次計數變化造成誤判。

在 /metrics 或監控系統中，核對：

• vllm:prefix_cache_queries
• vllm:prefix_cache_hits
• vllm:prompt_tokens_cached（部署版本若提供）
• vllm:kv_cache_usage_perc
• 冷請求與熱請求的首 token 延遲及總延遲

官方指標文件說明，prefix cache queries 與 hits 是以查詢或命中的 token 數量統計；因此不能只看「有沒有 hit」這個布林結果，應同時保留輸入 token 數、命中 token 數及請求延遲。

K3 的混合注意力結構還會讓快取驗收更複雜。官方發布文說明，KDA 狀態與一般全注意力 KV block 需要由混合快取管理器共同處理，KDA 狀態不適合在每個 token 邊界都建立完整快照。因此熱請求可能出現部分命中，而不是簡單的全命中或全未命中。

若命中計數增加，但熱請求延遲沒有任何合理變化，應檢查：

• 請求是否真的共享相同前綴。
• 工具 schema、訊息順序或隱藏控制 token 是否改變。
• 請求是否因快取容量不足而立即驅逐。
• 延遲瓶頸是否其實在排隊、網關或輸出解碼。

Agent 介面：比對工具呼叫正確性，不只看文字答案

Kimi K3 的生產驗收必須把模型輸出、vLLM 解析器、網關轉換及呼叫方協議分開記錄。官方 K3 recipe 特別提醒，模型偶爾可能輸出解析器未預期的工具呼叫格式，建議加入 schema validation 與 retry。這代表單次示範成功不足以作為工具呼叫通過證據。(recipes.vllm.ai)

至少執行以下樣本：

• 有一個工具的單輪呼叫。
• 多個工具可選的單輪呼叫。
• 工具回傳結果後的第二輪追問。
• 需要結構化輸出的 JSON schema。
• 工具格式錯誤、超時或空回應時的失敗回退。

每次測試都保存：

• 原始請求與工具 schema。
• 回應正文、推理欄位及 tool_calls。
• 工具名稱、參數 JSON 與 schema 驗證結果。
• 網關收到的原始封包與轉換後內容。
• 重試次數、最終錯誤及是否產生重複副作用。

判定時要區分兩類問題。若模型回應本身格式不合規，屬於模型或解析器路徑；若原始回應正確，但網關遺失欄位、錯誤轉義 JSON 或重試兩次，則屬於介面層。兩者不能都歸因於 GPU 算力。

需要先完成基礎連線與權限確認時，可參考 ProxyMac 的使用說明頁，把 SSH、容器啟動、監控端點和回滾權限列入交付前檢查。若驗收結果涉及臨時算力配置，則應再對照香港節點方案資訊或實際交付區域的方案頁，不能先假定固定性能或固定價格。

上線前可勾選的簽核清單

• [ ] 已保存 Kimi K3 官方 recipe 版本、檢查日期與來源連結。
• [ ] 已記錄專用容器標籤，並確認容器內為 CUDA 13 建置。
• [ ] 已記錄宿主機 GPU、R580 或更新驅動及容器執行時看到的版本。
• [ ] 已保存完整啟動日誌，沒有未解釋的 CUDA、NCCL 或 rank 初始化錯誤。
• [ ] 已使用包含系統提示、工具定義、多輪對話及結構化輸出的固定 Agent 樣本。
• [ ] 已完成模型載入、長輸入、併發及持續運行四個壓力階段。
• [ ] 已保存 OOM 前後顯存曲線、輸入條件、輸出長度及併發設定。
• [ ] 已觀察 kv_cache_usage_perc、running、waiting 及 preemption 指標。
• [ ] 已明確啟用 prefix caching，並完成冷請求、熱請求及負向對照。
• [ ] 已保存 prefix_cache_queries、prefix_cache_hits 及可用的 cached prompt tokens。
• [ ] 已驗證工具 schema、tool_calls、推理欄位、重試與失敗回退。
• [ ] 每個驗收項目都有測試條件、結果、時間及複核人。
• [ ] 已寫好限流、擴容和回滾的觸發條件。

只要兼容鏈不通過，結論就是返工。只要壓力下資源持續飽和，結論就是調整拓撲或擴容。只有非關鍵功能存在可控、可監測、可回退的問題，才適合暫時限流觀察。

FAQ：把長尾疑問轉成可執行判斷

Kimi K3 vLLM 啟動成功後還要檢查什麼？

應繼續核對容器與宿主機版本、啟動日誌、模型載入後顯存、長上下文、併發、持續運行、prefix caching 命中及 Agent 工具呼叫。單次 API 成功只表示基礎鏈路可用，不能取代生產負載下的容量與介面驗收。

Kimi K3 的 CUDA 和驅動版本怎樣才算兼容？

目前官方 recipe 的驗收基準是 CUDA 13 專用 Kimi K3 容器，以及 R580 或更新的宿主機驅動。工程團隊應同時保存容器資訊、宿主機驅動資訊與啟動日誌；若自行改用其他 CUDA 建置，必須另立建置與回滾紀錄。

如何確認 Kimi K3 prefix caching 真的生效？

固定系統提示、工具定義和共享上下文，先發冷請求，再發只修改末端問題的熱請求。同步觀察 queries、hits、cached prompt tokens 與延遲，並加入負向對照。只有參數存在而沒有計數與行為證據，不能判定 prefix caching 已生效。

Kimi K3 壓測出現 OOM 能不能繼續上線？

不能直接上線。必須先定位 OOM 是載入、長輸入、併發、快取挤壓或拓撲容量問題，再用相同條件重測。若只降低併發便穩定，最多是限流觀察；若瓶頸持續出現，應改拓撲或擴容。

Kimi K3 部署驗收不通過應重裝還是擴容？

版本、映像或驅動不符合官方要求時，先重建環境；環境正確但壓力下資源仍不足，才擴容或調整平行化拓撲。工具格式問題則應先加 schema 驗證、重試和回退，避免把介面故障誤判成 GPU 不足。

對照驗收結果來看，自建方案的主要風險通常不是「能否啟動」，而是版本鏈需要自行維護、硬體拓撲要自行驗證、壓測失敗後缺乏即時替換容量，還可能把驅動、容器與網關問題混在同一個故障窗口內。若團隊只是需要短期 K3 測試、臨時擴容或 Agent 生產交付前的驗收環境，攜帶現有驅動版本、容器資訊、負載樣本與壓測記錄，再評估 ProxyMac 的可交付 Mac 算力方案，通常比立即購置整套硬體更容易先完成環境比對；但長期穩定重負載、需要指定 GPU 拓撲或實體介面的工作，仍應以自建集群或專用硬體評估為主。可先查看ProxyMac 方案總覽，再依驗收證據決定是重建兼容鏈、短期增加容量，還是改用另一種部署拓撲。

常見問題