Kimi K3 vLLM OOM：2026 調參還是擴容？

症狀：權重尚未完成初始化就 OOM，先不要調並發；模型已啟動、首個請求或高峰流量才 OOM，才從上下文、並發與 prefix caching 下手。
最快解法：驗證團隊先縮小負載完成最小復現；生產 Agent 團隊若在目標流量下仍沒有穩定記憶體餘量，就改用符合官方拓撲的多節點或臨時算力，不要無限犧牲業務參數。

這篇適合三類人：個人研究者與 POC 團隊，要確認現有資源是否只夠功能驗證；小型 Agent 團隊，要找出上下文、並發與 prefix caching 的穩定邊界；平台與生產交付團隊，則要判斷繼續改集群，還是直接擴展合規的雲端算力。

先記住一條判斷線： 權重載入期 OOM 是環境或模型容納能力問題；請求執行期 OOM 才通常屬於容量配置問題。兩者不能用同一套參數處理。

最後更新於 2026 年 8 月 16 日，資料核實自 vLLM Kimi K3 官方 recipe（2026 年 8 月 14 日更新）及官方發布文章。 官方頁面目前列出 Kimi K3 專用 Docker 映像、CUDA 13 建置、R580 以上 NVIDIA 驅動，以及生產流量的多節點建議。(官方 Kimi K3 recipe)

先分清 OOM 發生在哪一段

不要先看到 CUDA out of memory 就降低 --max-num-seqs。你要先看日誌位置、模型初始化狀態，以及第一個請求能否回傳。

目前官方 recipe 將 Kimi K3 描述為 2.8 兆參數的 MoE 模型，每個 token 啟用 16 個專家，模型上下文上限為 1M tokens；recipe 亦要求使用 Kimi K3 專用映像，NVIDIA 路徑需要 R580 以上驅動。這些是部署前提，不是你可以靠降低並發繞過的普通 KV cache 壓力。(官方硬體與部署要求)

如果模型根本沒有完成初始化，降低並發通常不會觸及主要問題。你最多只能證明啟動命令曾被執行，不能證明目前環境有能力承載服務。

個人研究者與 POC：先求流程跑通

這類團隊的目標是驗證 API、工具呼叫、推理鏈路及基本多模態流程，不是提前模擬生產吞吐。你的最小復現應該固定模型、映像與啟動方式，只縮小一個負載變數，避免同時改動太多設定。

建議順序如下：

1. 保存完整啟動命令、容器標籤、驅動版本及 OOM 前後日誌。
2. 先用純文字、短輸入及單一請求驗證 API 是否能完成初始化。
3. 再加入工具定義、工具結果及多輪訊息，確認工具呼叫格式沒有另行造成失敗。
4. 每次只改一項，例如上下文上限或測試並發，不要同時更換快取、並行與映像。
5. 以「模型完成初始化、首個請求正常回傳」作為 POC 通過條件。

vLLM 官方發布文章的快速啟動示例包含 tensor parallel、--enable-prefix-caching、工具選擇及 Kimi K3 parser；官方 recipe 亦提醒工具呼叫偶爾可能出現 parser 不預期的格式，需要 schema 驗證與重試。這表示「能回應」與「Agent 流程完整可用」仍是兩個驗收層次。(vLLM 官方 Kimi K3 發布文章)

停止條件很重要： 如果你已確認是權重載入期 OOM，而且現有 GPU 拓撲不在官方支援路徑內，就不要繼續堆疊零散的顯存參數。轉到合規映像、驅動與硬體環境做對照驗證，通常比在不相容集群上反覆重建更快。

小型 Agent 團隊：保留前綴收益，再壓縮負載

多輪 Agent 服務的記憶體壓力不只來自單次提示。固定系統提示、工具定義、歷史對話、工具結果和多個同時進行的 session，會共同影響 prefill、KV cache 及 prefix caching 的收益。

因此，Kimi K3 開啟 prefix caching 後仍然 OOM，不代表快取一定應該關閉。官方說明 Kimi K3 的混合架構同時管理完整注意力層的 paged KV 與 KDA recurrent state；快取保留策略需要在重算成本與快取佔用之間取捨。官方文章也以每隔 32K tokens 的 checkpoint 作為 interval retention 範例，並說明設定為 0 可停用週期性 checkpoint，只保留 prompt-end state。這些是官方機制與例子，不是適合所有工作負載的固定答案。(官方 prefix caching 說明)

你的復測應該保留真實請求分布，而不是拿一個很短的提示證明「問題已解決」：

• 固定同一批 system prompt、工具 schema、對話歷史及輸出上限。
• 先降低並發，觀察峰值記憶體和請求穩定性。
• 再縮短上下文，確認 OOM 是否只在長 prompt 出現。
• 保留 prefix caching，調整 retention 策略後再跑同一批請求。
• 記錄 cache hit、等待請求、重算比例、峰值記憶體及錯誤率。
• 若降低負載後仍只剩極少餘量，將它標記為「可驗證」而不是「可生產」。

你應把命中率與記憶體峰值一起看，單看命中率沒有容量意義。對小型 Agent 團隊而言，真正可接受的結果不是「某次短提示成功」，而是同一組真實 session 在固定條件下，經過多輪請求仍沒有記憶體尖峰失控。

平台團隊：先查環境控制權，再談自構建

如果你管理的是既有 GPU 集群，真正的第一個問題不是「還有哪個參數能試」，而是你能否修改宿主機驅動、容器映像、節點互聯與並行拓撲。

官方 recipe 指出，Kimi K3 專用 NVIDIA 映像是 CUDA 13 建置，沒有 CUDA 12.9 對應標籤；若宿主機仍是 CUDA 12.9 與 R575 路徑，官方建議升級驅動，或自行從 K3 分支以 cu129 建構 vLLM。後者會把維護責任轉移到你的團隊，不能視為與官方映像等價。(官方 CUDA 13 與驅動要求)

跨節點部署還要核對 all-to-all backend。官方 recipe 建議 RDMA 使用 deepep_v2，NVLink 使用 flashinfer_nvlink_one_sided；對跨節點 NVLink 的 DEP 路徑，官方另建議 deep_gemm_mega_moe，並提醒它不相容於跨節點 RDMA。這些是拓撲相關選擇，不能抽離硬體互聯單獨複製。(官方多節點 backend 建議)

vLLM 的分散式文件也指出，單節點多 GPU、跨節點 tensor parallel、pipeline parallel 及 MoE 的 expert parallel，解決的是不同層次的問題。若單一節點放不下模型，才進入多節點並行；若是 MoE 生產流量，還要考慮資料、專家與張量並行的組合。(vLLM 分散式並行文件)

生產交付團隊：目標流量不足時就該擴容

生產判斷不能只問「模型能不能啟動」。你至少要把以下四項寫進容量測試：

1. 預期上下文長度與長短請求比例。
2. 同時在線的 Agent session 數量。
3. system prompt、工具定義及歷史訊息的重複程度。
4. 節點故障、請求重試及 rolling update 時所需的記憶體餘量。

如果只是單一使用者低負載測試，縮短上下文或限制並發可能足以讓服務穩定。但如果目標流量下，任何合理降載都會造成業務不可接受的等待、截斷或工具失敗，答案就不是繼續調參，而是擴展符合官方拓撲的環境。

官方發布文章展示過 16 張 NVIDIA GB300 上的 Kimi K3 單使用者效能：不使用 DSpark 為 118 tok/s，使用 DSpark 為 370 tok/s，約為 3.14 倍；這是特定 SPEED Bench 測試與拓撲，不能拿來推算你的集群吞吐。官方同時指出，tensor parallel 偏向互動延遲，但有效 KV cache 容量可能限制總吞吐；大規模 expert parallel 則可能受網路頻寬影響。(官方效能測試與拓撲說明)

高吞吐環境可評估 prefill/decode 分離。官方已描述以 TEP prefill 對 DEP decode 的驗證拓撲，並使用 NIXL 傳輸 KV；但這要求 KDA state、完整注意力 KV 及 block table 正確交換。若你的 RDMA、NVLink 或節點映像不一致，增加節點反而可能把 OOM 變成通訊與部署故障。(官方 prefill/decode 分離說明)

Kimi K3 Agent 的擴容觸發線

你可以用以下清單作為生產前的決策工具：

• [ ] 權重載入已在官方映像、CUDA 13 及 R580 以上驅動環境完成。
• [ ] 已保存 tensor、expert、pipeline 或 data parallel 的實際拓撲。
• [ ] 已用同一組真實 Agent 請求比較低並發、短上下文與快取策略。
• [ ] 已記錄每個 rank 的峰值記憶體，而不是只看平均值。
• [ ] prefix caching 的命中情況已與重算時間及快取佔用一併觀察。
• [ ] 高峰測試後仍保留故障重試、部署更新及流量波動的餘量。
• [ ] 若現有集群不能達成以上條件，已在合規雲端環境完成對照復測。
• [ ] 若只有降低業務上下文或並發才能避免 OOM，已把這項代價交由產品負責人確認。

只要最後三項無法完成，你就不應把「低負載啟動成功」寫成生產容量結論。

復測結果：調參、遷移與擴容的分界

以下三張表不要用來推算固定 GPU 數量，而是用來整理你的證據與下一步。Kimi K3 官方 recipe 目前列出 NVIDIA 路徑至少 8 張 GB300、AMD 路徑至少 8 張 MI355X 或 MI350X，並明確建議生產流量使用多節點；這些是官方列出的支援路徑，不等於任何硬體組合都能承載你的目標流量。(官方硬體拓撲與多節點要求)

如果你要在現有集群上大改驅動、容器或網路層，先閱讀部署與支援說明，把「環境不兼容」與「容量不足」拆成兩個變更項。需要比較週期性算力成本時，再查看MacHTML 的方案頁面，不要只用單次啟動成功作為租用或採購依據。

現有方案若是舊 CUDA 映像、無法升級的宿主機驅動，或只有單節點且沒有合適互聯，缺點通常不只是一次 OOM：你會同時承擔自構建維護、跨節點通訊不穩，以及每次 vLLM 更新都要重新驗證的成本。這時，短期租用一個可按週期交付的合規算力環境，先用同一組 Kimi K3 Agent 請求做對照，往往比直接改動生產集群更容易得到可核對的升級、遷移或擴容答案。