Kimi K3 Qwen3.8 自托管驗收：2026 上線清單

先看時間表：本週先驗收，不要先買卡

官方 Kimi K3 模型資料列出 2.8T 總參數、104B 啟用參數，以及每個 token 從 896 個專家中選取 16 個。這個數字足以說明一件事：能下載或載入權重，不等於已具備可上線的推理服務。

本週建議先完成五道門檻：權重與許可、顯存余量、真實 AI Agent 負載、故障恢復、首週成本。任一硬門檻失敗，就先改用 API、短期租用算力繼續驗證，或停止投入；不要用追加硬體掩蓋未確認的部署問題。

這篇適合三類團隊：準備為 AI Agent 建立獨立推理端點的技術負責人；等待 Qwen3.8 開放權重、需要先準備環境的 MLOps 團隊；以及已經載入 Kimi K3，卻尚未完成並發與穩定性測試的工程團隊。

五道門檻先分成硬條件與可優化項

我們建議把驗收分數設為 5 分制，每道門檻通過得 1 分；但分數不能取代硬條件。許可不清、權重不完整、核心推理框架不相容，任何一項出現，都應直接判定為暫停，而不是以其他項目得分抵銷。

這張表的用途，是把「模型很強」與「服務值得自建」拆開。模型能力屬於選型問題；能否穩定交付，則是推理框架、硬體配置、資料邊界與值班負擔共同決定。

第一階段：先核驗權重、許可與部署鏈路

Kimi K3 能載入成功就代表可以上線嗎？

不能。Kimi K3 的官方資料顯示，它採用 MXFP4 權重與 MXFP8 啟用值，並以 MoE 架構運作；官方建議的推理引擎也包括 vLLM、SGLang 與 TokenSpeed。這些資料只能證明模型有明確的部署方向，不能證明目標硬體、特定版本與實際 Agent 服務已經相容。詳細架構與引擎資訊應以官方模型與部署說明為準。

正式測試前，先建立一份版本鎖定表，至少記下：

• 權重來源、提交版本、檔案數量與校驗資訊；
• 量化格式、轉換工具及製作說明；
• 推理引擎版本、CUDA 或其他加速元件版本；
• 張量並行、專家並行、跨節點通訊設定；
• 目標硬體的 GPU 記憶體、主機記憶體、儲存空間與網路頻寬；
• 結構化輸出、工具呼叫、串流輸出是否有正式支援。

許可也要先看，而不是等到產品上線才補法務。以 Kimi K3 為例，官方 Kimi K3 License對 Model as a Service、商業規模與內部使用有不同條件。若團隊要把模型能力直接提供給第三方，不能只因為權重可下載，就假設所有服務型態都沒有額外限制。

Qwen3.8 則採取另一種驗收策略：在權重、許可與框架正式出現在官方模型程式庫前，只準備下載腳本、容器、監控與測試資料集，不提前承諾最低硬體。社群關於開放日期、量化版本與最低需求的討論，只能用來追蹤變化，不能當作採購依據。相關社群部署問題可以參考非官方討論串，但每一項結論仍要回到官方模型卡核對。

提醒： 社群轉換權重不應預設等同官方發布。若缺少來源、校驗、轉換工具版本或已知限制，測試失敗時我們無法判斷是模型問題、量化問題，還是轉換鏈路造成的錯誤。

第二階段：第一小時只判斷能否形成完整閉環

第一小時的目的不是追求最高吞吐，而是確認一個請求能否走完完整流程。建議依下列次序操作：

1. 建立乾淨環境，安裝已鎖定版本的推理框架與相依套件。
2. 下載或掛載權重，保存完整載入日誌、警告與錯誤訊息。
3. 發送一個最小單請求，確認模型能生成可解析的結果。
4. 加入固定 JSON Schema，驗證結構化輸出是否穩定。
5. 接入一個無副作用工具，檢查工具選擇、參數格式與回傳內容。
6. 完成一次服務重啟，再重做單請求與工具呼叫。
7. 記錄權重常駐、KV Cache、執行時工作區與安全余量的顯存占用。

顯存預檢可以用下列方式估算：

所需顯存 ≈ 權重常駐 + KV Cache + 執行時工作區 + 安全余量 − 可接受的卸載部分

這不是採購公式，而是排錯工具。若模型只能靠大量卸載、頻繁在主機記憶體與 GPU 之間交換，或必須套用無法重現的補丁才能完成單請求，應視為停止擴容訊號。MoE 模型的啟用參數較少，不代表所有權重都不需要被管理；專家分布、通訊、快取與上下文長度仍會影響實際容量。

若團隊需要更深入拆解權重、KV Cache 與容量規劃，可延伸閱讀萬億參數模型的顯存估算方法；這篇驗收文章則不重複做跨模型成本排名。

第三階段：首日用真實 AI Agent 請求壓出容量問題

萬億參數 MoE 模型上線要測哪些指標？

首日壓測不能只用一條短提示確認「有輸出」。我們建議從團隊實際流量抽樣，保留四類輸入特徵：

• 常見提示長度與最長提示長度；
• 工具回傳內容的平均值與高峰值；
• 推理輸出長度、思考內容比例與截斷規則；
• 單一使用者連續多輪請求，以及同時活躍的 Agent 數量。

每一輪逐步增加上下文與並發，至少記錄：

• 首 token 延遲；
• 持續輸出速度；
• P95 或更高尾延遲；
• 佇列等待時間；
• 顯存峰值與 KV Cache 增長；
• 工具呼叫錯誤率；
• 有效吞吐，而非只計算產生過的 token；
• 專家並行與跨節點通訊是否出現長時間等待。

每項數字都必須來自壓測工具輸出、伺服器日誌或監控系統，不要用人工體感填寫。Kimi K3 的官方技術報告指出其上下文窗口為 1,048,576 tokens，但這不代表團隊應直接以最大上下文作為生產設定；上下文越長，KV Cache、排隊與恢復時間越需要實測。官方技術報告可作為架構核對依據，不能取代目標業務負載測試。

我們通常把首日測試分成四級：

• 基線級：單請求、短上下文、無工具；
• 工作級：團隊常見上下文、固定工具與結構化輸出；
• 峰值級：高並發、長工具回傳與連續多輪；
• 失敗級：超過容量後觀察佇列、錯誤、回復與請求遺失。

若只有基線級通過，不能簽署採購。若工作級通過而峰值級尾延遲失控，應先限制併發或改用雙軌，而不是立即購買更多硬體。

第四階段：首週確認故障恢復與人工成本

大模型自托管壓測多久才適合決定採購？

單日能否生成答案，只能作為進入首週測試的條件。採購決策至少要等到首週完成連續負載、重啟、回滾、節點中斷與版本重建，因為真正的成本通常出現在故障後，而不是正常輸出期間。

首週安排可以沿用以下節奏：

1. 第 1 天：完成基線、工作級、峰值級與失敗級負載。
2. 第 2 天：重啟推理程序，確認模型重新載入、健康檢查與流量切換。
3. 第 3 天：回滾一次框架或模型版本，驗證設定是否可重建。
4. 第 4 天：模擬節點中斷或網路異常，記錄請求遺失與恢復時間。
5. 第 5 天：以團隊既有監控、權限與告警流程執行，不再依靠測試人員手動盯住。
6. 第 6 至 7 天：整理有效呼叫量、閒置時段、失敗請求與人工介入次數。

首週台帳應同時包含 GPU 使用率與非 GPU 項目，例如模型更新所需時間、儲存空間、日誌保留量、值班時數、權限審批及故障後重新驗證的工作量。若每天仍需要人工修改啟動參數、清理快取或重新套用補丁，這不是「稍後優化」的小問題，而是長期運維成本。

資料邊界也要在這一週驗證。內部知識服務可能需要限制日誌中的提示內容、工具回傳與錯誤堆疊；權限控制若只存在於前端，推理端點仍可能被繞過。涉及個人資料或敏感企業資料時，可同步參考JexMac 的資料與私隱說明，把資料保留、遠端存取與測試帳號生命週期寫入驗收紀錄。

最終決策：繼續自托管、雙軌，或停止投入

自托管模型什麼情況下應該改用 API？

我們建議用「硬門檻優先、評分輔助」作最後簽核：

• 繼續自托管：五道門檻全部通過，真實負載的尾延遲與錯誤率達標，且首週人工介入可由固定值班流程承擔。
• 自托管與 API 雙軌：業務量有明顯高低峰、Qwen3.8 權重或框架仍在變動，或自建端點只適合穩定內部流量；尖峰與新版本先交給 API。
• 停止長期投入：許可條件無法成立、框架只能靠不可維護補丁、擴容後仍無法達到尾延遲，或實際利用率不足以支撐硬體與工程人力。

提交簽字前，請完成這份可勾選清單：

• [ ] 已從官方來源取得權重、模型卡、許可與校驗資訊。
• [ ] 已固定推理框架、量化格式、並行策略與版本組合。
• [ ] 已分開記錄權重、KV Cache、工作區與安全余量。
• [ ] 已用真實提示、工具回傳、輸出長度與並發分布完成首日壓測。
• [ ] 已記錄首 token 延遲、輸出速度、尾延遲、佇列、峰值顯存、錯誤率與有效吞吐。
• [ ] 已完成重啟、回滾、節點中斷與版本重建。
• [ ] 已把有效呼叫量、閒置時段、失敗請求及人工介入次數放入首週台帳。
• [ ] 已指定負責人、證據連結、復核日期與重新評估觸發條件。
• [ ] Qwen3.8 若尚未正式開放權重，已禁止團隊把社群傳聞寫成採購結論。

最後一項尤其重要：Qwen3.8 的權重狀態、許可與框架適配，應在官方倉庫出現可核驗內容後重新驗收；Kimi K3 則應以官方模型卡與許可更新為準，而不是沿用早期社群轉換版本的結論。

先租用驗收環境，通常比直接買卡更容易控制風險

若目前方案是直接採購多卡伺服器，常見缺點是資金先被鎖在尚未確認相容的硬體、模型版本變更後可能出現閒置，以及跨節點通訊與值班成本會在上線後才暴露。若改用一般雲端長租，又可能遇到計費粒度、資料邊界、固定區域或環境重建不夠靈活的問題。

對於完整 Kimi K3 這類超大規模 MoE 模型，我們不會把單台 Mac 宣稱成固定替代方案；但在正式採購前，若團隊要先驗證 Agent harness、權限、資料流程、較小模型、控制面或測試程式，租用 JexMac 的 Mac 環境可以先把這些不依賴最終 GPU 叢集的問題隔離出來，再決定是否進入長期算力投資。需要短期測試時，可先查看JexMac 的方案資訊，並在提交需求時附上模型、推理框架、並發範圍與測試週期，讓環境匹配建立在可驗證條件上，而不是先承諾一個未經驗收的固定配置。