NVIDIA Dynamo 部署配方：把韓國開放模型收進 B200 推論叢集

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把一個七百多 B 參數的混合專家模型放上多張 B200，真正花時間的環節往往不是下載權重，而是後面那一串要自己拍板的決定：張量平行要切幾份、權重壓成哪種量化格式、KV cache 用什麼精度、推測解碼開不開、跑在哪個容器映像。任何一個選錯，輕則速度掉一截，重則快取重用整個失效，甚至輸出內容悄悄壞掉。NVIDIA 在 2026 年 11 月 9 日替四款韓國開放模型把這串決定先做了一輪：官方部落格文章於 05:00 UTC 發布（台北時間同日下午 1 點，文章頁面顯示的美西日期是 11 月 8 日），NVIDIA AI 的 X 帳號在 45 分鐘後跟著分享，對象是 SK telecom 的 A.X K2、LG AI Research 的 K-EXAONE 2.0、Upstage 的 Solar Open 2，以及 Motif Technologies 的 Motif-3。

先講清楚這則公告的性質：Dynamo 配方目錄新增了四份開源設定包，把指定模型、硬體與執行方式綁成可直接套用的 Kubernetes 設定。官方部落格的說法是 take the guesswork out of deployment，拿掉部署裡的猜測；X 貼文則逐一標記四家出品方，稱它們為韓國領先的開放模型。它既不是四款模型同日首次發布，也不是新的雲端 API 服務。手上有多卡 B200 叢集、想自架這幾個模型的團隊是直接受影響的人；只呼叫雲端 API 的使用者，這次公告沒有改變任何事。

Pin

配方替你先拍板了哪些決定

Dynamo 是 NVIDIA 開源的分散式推論服務框架，處理模型放大到多節點之後的請求路由與節點間通訊。配方（recipe）則是把「這個模型在這種硬體上怎麼跑」的答案寫死成 manifest：以 K-EXAONE 2.0 為例，配方指定了檢查點 LGAI-EXAONE/K-EXAONE-2.0-750B-A37B-NVFP4、NVFP4 權重搭配 FP8 KV cache 的精度組合、TP4 的平行切法，以及草稿長度 2 的多 token 預測推測解碼。這個模型總參數 764.5B、每個 token 約 37B 生效，是 256 個專家的混合專家架構。照著 manifest 套用，這些變數不必再逐一試錯。

Pin

部署面的長相也值得知道：套用 manifest 之後等部署就緒，K-EXAONE 的就緒等待上限開到 7,200 秒，權重下載工作的上限是 6 小時，這個量級本身就是規模的提示；接著把前端服務的 8000 埠轉進來，用 OpenAI 相容的 chat completions 端點驗證。A.X K2 文件給的驗證請求是問它 2 加 2 等於多少。配方連量測工具都附上：文件提供 AIPerf 的對話軌跡重跑流程，測試軌跡放在儲存庫的 Git LFS 裡，官方數字原則上可以自己重現。

推測解碼的選擇最能看出配方的用處：同一個問題，四份文件給四種答案。K-EXAONE 用草稿長度 2 的多 token 預測，A.X K2 用猜三個 token 的 EAGLE3（讀取與生成兩種角色都開，FlashInfer 自動調校則停用），Motif-3 用兩個投機 token 的 MTP2，Solar 的檢查點則不支援推測解碼。哪個模型配哪種投機策略，是試錯成本最高的決定之一，現在至少有官方版本可以對照。

讀配置表前需要兩個詞。集中配置（aggregated）讓同一組運行單元負責請求的讀取與生成兩個階段；分離配置（disaggregated）把讀取與生成拆給不同單元，中間的 KV 資料走網路傳遞，代價是協調與傳輸變多，換到的是兩側可以依流量分開擴充。四份配方的入場門檻差很大：

最省門檻的是 Motif-3，兩張 B200 就有集中設定，容器映像直接用公開的 NGC 位址、不需要另外申請金鑰，worker 還以離線模式運行；門檻最高的是 A.X K2 的 H200 路線，不論集中或分離都要 32 張卡。還有一個容易誤判的點：A.X K2 的 B200 設定用 NVFP4 權重加 FP8 KV cache，H200 設定卻是 FP8 權重加 BF16 KV cache，兩種卡的數量不能按記憶體容量直接換算，文件為兩種硬體各寫一套配置就是這個原因。

把視野拉到整個目錄可以看出這次的位置：Dynamo 配方庫本來就收了 Z.AI、Moonshot、DeepSeek、Qwen、NVIDIA 自家、Google、OpenAI、Meta 等數十個模型家族（DeepSeek-V4.1-Flash 的成本結構我們先前拆過），這次新增的是 LG AI Research、SK Telecom、Upstage、Motif Technologies 四個供應商條目，全部掛著開源配方的標章。官方部落格把這批動作定位為讓韓國開放模型更快進入生產、成為人人可用的服務，這句是行銷語言，但交付物是實的：每份配方都有可套用的 manifest 與可重跑的量測。

Pin

兩倍效能的宣稱，文件裡沒有附對照組

官方部落格的原文寫 delivering up to 2x performance out of the box，X 貼文同樣說 deliver up to 2x inference。這是 NVIDIA 的作者宣稱；四份配方頁都沒有附這個倍數的比較基準，它們公布的是絕對數字。要拿去算採購帳的，是後者。

K-EXAONE 2.0 的效能表值得逐格讀。集中配置 4 張卡在並發 7 時，每張 GPU 每秒輸出 87 個 token，首 token 中位等待 291 毫秒，每位使用者中位速度 51.4 token；分離配置 8 張卡在並發 14 時，每張 GPU 每秒 85 個，首 token 中位等待 2,230 毫秒，每位使用者 54.9。文件在表下的註記寫得直白：分離的每卡吞吐與集中打平，但用了兩倍的 GPU；選它是為了每 token 延遲與兩側獨立擴充，不是為了產能。換成帳單語言：多出的四張卡沒有增加每卡產出，買到的是每位使用者略高的生成速度與調度彈性，代價是首 token 等待變成七倍多。

A.X K2 與 Solar Open 2 的表格講同一件事。A.X K2 在並發 16 時集中每卡 76.49、分離 61.97，分離把每位使用者的平均輸出從 55.83 拉到 83，首 token 中位等待從 0.525 秒變 3.879 秒。Solar Open 2 集中每卡 216.88、分離 206.20，等待從 308 毫秒變 2,277 毫秒，文件直接建議除非需要獨立擴充，否則選集中。Solar 的分離檔還有個反直覺的細節：前端故意用輪詢路由而非 KV 感知路由，因為只有一個讀取 worker 時路由器無從選擇，兩種路由都量過，沒有一種贏過輪詢。H200 那側的並發建議也是同個方向：並發 64 時分離的首 token 中位 1.63 秒還可考慮，並發 128 時分離吞吐較低、等待中位衝到 28.19 秒，官方結論是回集中。這些數字還附帶一個選擇條件：K-EXAONE 的表是在同時滿足每位使用者每秒至少 50 token 且首 token 中位等待低於 5 秒的前提下，挑出的最高並發，並發數字本身是被門檻篩出來的。

四款裡唯一的例外是 Motif-3，它分離後每卡 319.26 反而高於集中的 293.96。但代價同樣明確：每位使用者的中位速度從 66.27 掉到 51.49，首 token 等待從 388 毫秒變 4,305 毫秒（量測並發分別是 11 與 64）。而且文件同一段就交代了前提：這些數字採用合成的推測解碼接受長度 2.13，不量測真實的推測接受率與輸出品質，預設的部署設定用的仍是真實驗證。例外成立，但成色要打折看。

量測的但書：8.8% 的快取重用與被排除的請求

K-EXAONE 的測試負載用 Mooncake 對話軌跡，設計上約 70% 的請求帶共用前綴，實測的 KV 快取重用率只有 8.8%。文件給的原因是工作集超過 TP4 的 KV 容量，區塊還來不及重用就被淘汰。這個落差對讀者的意義很實際：以為流量可以共用前綴，與執行時真的留在快取裡，是兩件事，換了硬體或流量形狀，重用率就要重新量。

同一份測試跑了 1,805 個請求，其中 38 個超過 262,144 token 的上下文上限（這是該檢查點的原生視窗），直接回 HTTP 400，效能整理把它們排除在外。Motif-3 的表另有 35 個超限請求。Solar 的軌跡形狀又不一樣，它取的是內部對話軌跡的 15% 子集，平均輸入長達 37.4k token，文件並提醒分離檔的每位使用者速度只是勉強越過每秒 50 token 的門檻，在資源爭用的機器上重跑可能落在門檻以下；它的量測腳本也不會主動清 KV cache，跑一次會繼承 worker 手上已有的內容，要冷快取就得重啟 worker。也就是說，表格是特定軌跡、特定門檻下的成績單，中位數只描述排序在中間的那個請求，慢尾巴與錯誤率要用自己的流量重新量。正式服務若常出現超長輸入，要另外決定拒絕、截斷還是改走別的流程，這不會因為照抄配置而自動解決。

照抄配方，仍然可能靜默出錯

K-EXAONE 配方有一條容易被忽略的強制規定：MoE 運算核心釘選在 FLASHINFER_CUTLASS。原因是 vLLM 的自動選擇會挑 FLASHINFER_TRTLLM，它在這個檢查點上會靜默損毀長文輸出，文件形容為流暢、貌似合理、內容錯誤，而且沒有任何錯誤訊息。被釘選的核心較慢，這個代價已經含在前面的效能數字裡。這條規定也點出配方的真實定位：它把已知的地雷先標出來，但服務能回應不等於底層正確，只拿簡單問候語驗收，驗不出這種損毀。驗收要分層做：模型輸出的欄位解析、工具呼叫的實際執行、結果回傳，分開確認才知道錯在哪一層。

Solar Open 2 的文件另列了一批 API 邊界：請求 logprobs 會回 HTTP 500；Responses API 設定存放後取回會 404；超過三個停止 token ID 也是回 500 而非 400。它還把推理強度固定在 high，官方量到 GPQA Diamond 的中位輸出約 6,400 token，最長觀察到 209,000，把 max_tokens 設在幾千的量級會讓模型在推理中途被截斷，拿到 finish_reason=length 卻沒有最終內容，最常見的受害者在等 JSON 的結構化輸出請求。文件也提醒 1M 上下文需要足夠的 KV 容量支撐，卡數不足就調降 max-model-len。

現在要動的人，與不用動的人

不用動的：所有走雲端 API 的使用者。這批配方服務的是自架場景，前提是 Kubernetes 叢集、Hugging Face 權杖與共用儲存。另外別把 LG 另行開放的 K-EXAONE 2.5 免費 API 與這次的 2.0 權重部署混為一談：兩者是不同版本、不同交付方式的比較對象，2.5 的 API 成績與條款不能直接套在 2.0 的權重上，我們先前整理過 K-EXAONE 2.5 免費 API 的界線。

要動的：本來就有 B200 叢集的自架團隊。合理的第一步是挑一款貼近自家流量的配方，把映像版本、權重識別與文件日期一併留下紀錄，先用有已知答案的長文與工具呼叫案例驗正確性，再上流量比吞吐；有餘裕的話，先重跑一次官方軌跡對齊環境，再換自家流量比對，兩組數字的差距就是這份配方在你機器上的真實修正量。幾個硬門檻先記著：A.X K2 的每個 B200 worker 要 400 GiB 主機記憶體、H200 worker 請求 512 GiB；K-EXAONE 需要 700 GB 的 ReadWriteMany 儲存放約 530 GB 的檢查點；文件並提醒 K-EXAONE 的 TP4 是下限也是最佳，TP2 塞不進單張 180 GB 的 B200，TP8 每卡反而更慢，這個模型的瓶頸在通訊不在容量。分離配置的 8 張卡建議放同節點，KV 走 InfiniBand RDMA，跨節點可行但會慢。

Dynamo 在 NVIDIA 自己的技術版圖裡也不是第一次上桌：先前介紹的 NVIDIA 記憶體協同設計分析裡，它就是 KV cache 升級成貫穿多層資源的其中一個環節。這次配方的方向一致，把推論棧裡最難抄對的那幾步，從各自摸索變成有版本可指的設定。

起點也可以從卡數反推。手邊只有個位數張 B200 的團隊，Motif-3 的兩張卡集中設定是最低入場卷，但要記得它標實驗性、效能數字用合成接受長度；四張卡可以碰 K-EXAONE 2.0 與 Solar Open 2 的集中設定，後者吃到 1M 上下文；八張卡以上才談得上 A.X K2 的集中設定與各款的分離檔。H200 用戶這次只有 A.X K2 一條路，而且直接 32 張起跳。

還沒確認的事，與這篇的保存期限

兩倍效能的對照組沒有揭露，這停留在作者宣稱層級，文件內無法覆核。配方文件本身會漂：這四頁掛在 dev 版文件下，stable v1.6.1 的目錄雖然也列出四款，卡片描述已經有出入，Motif-3 在 stable 版只描述了兩張 B200 的設定。回查的觸發點有兩個：Dynamo 發下一版，或任一份配方頁的效能表更新；引用時把文件版本一起記下來，是這類文件最穩的使用方式。唯一確定的是方向：配方這種形式把部署經驗寫成可檢查的設定，比口頭的最佳實踐容易累積，也容易在新版本出現時，逐項對出改了什麼。