2026 年 7 月 27 日Kimi K3 正式開放完整模型權(quán)重。這是近期大模型領(lǐng)域最值得關(guān)注的事件之一。K3 擁有 2.8T 總參數(shù)、約 104B 激活參數(shù)、896 個路由專家每個 Token 選擇其中 16 個專家同時支持最高 100 萬 Token 上下文。按照官方公布的評測結(jié)果它已經(jīng)進入全球最強模型的第一梯隊也因此被很多人直接稱為“世界第三的大模型”。但比“世界第三”更有沖擊力的是另一件事這樣一個第一梯隊模型的完整權(quán)重真的被放出來了。很多開發(fā)者看到這里第一反應(yīng)是權(quán)重開放 可以下載 可以私有部署 終于不用調(diào)用閉源 API然而AMD 隨后公布的 Day-0 部署方案卻給這種興奮潑了一盆冷水。K3 當(dāng)前公開驗證過的最低整機配置之一是8 張 AMD Instinct MI355X 每張 288GiB HBM3E 總 HBM 超過 2TB TP8 張量并行即便如此AMD 也明確說明這次驗證的目標(biāo)不是追求峰值性能而是確認(rèn)模型權(quán)重為什么能裝進去、如何在 8 張 GPU 之間分配以及能否完成最小正確性測試。換句話說這套配置證明的是K3 能加載 K3 能生成 K3 能完成正確性驗證但它沒有證明K3 的首字延遲是多少 每秒能夠生成多少 Token 可以支持多少并發(fā)用戶 長上下文性能如何 單位 Token 成本是多少 是否適合長期生產(chǎn)運行AMD 沒有在這次驗證中公布這些生產(chǎn)指標(biāo)。這就產(chǎn)生了一個非常有意思的矛盾一個被認(rèn)為進入世界前三、已經(jīng)開放完整權(quán)重的模型為什么絕大多數(shù)企業(yè)還是部署不了答案并不只是顯卡太貴。真正的問題是當(dāng)模型大到必須跨越多張 GPU 時部署就不再是一道顯存加法題而變成了一道分布式系統(tǒng)題。一、K3 開放的是模型權(quán)重不是一條廉價部署捷徑過去部署 7B、14B、32B 模型時我們通常只需要回答一個問題模型需要多少顯存如果模型能裝進顯存推理框架又支持相應(yīng)架構(gòu)那么部署大概率就能繼續(xù)進行。但 K3 已經(jīng)完全不是這個尺度。它的模型 Checkpoint 大約為 1.56TB。即使使用 8 張每張擁有 288GiB HBM 的 MI355X也需要通過 TP8把模型權(quán)重分散到所有 GPU 上。這意味著一個請求不再由一張 GPU 獨立完成。而是可能變成GPU 0 計算一部分 GPU 1 計算一部分 GPU 2 計算一部分 …… GPU 7 計算一部分 ↓ 所有 GPU 交換結(jié)果 ↓ 完成同步 ↓ 繼續(xù)計算下一層從這一刻開始決定系統(tǒng)性能的就不只是 GPU 算力。而是GPU 計算能力 × 并行策略 × GPU 通信帶寬 × PCIe / 高速互聯(lián)拓?fù)?× P2P 能力 × 請求調(diào)度 × 推理引擎優(yōu)化任何一項嚴(yán)重退化整套系統(tǒng)都會被拖慢。所以K3 真正值得研究的地方不只是它擁有 2.8T 參數(shù)。而是它把一個事實暴露得非常徹底前沿大模型已經(jīng)不再只是一份神經(jīng)網(wǎng)絡(luò)權(quán)重而是一臺由模型、GPU、互聯(lián)、通信庫和調(diào)度系統(tǒng)共同組成的分布式計算機器。二、為什么會出現(xiàn)“GPU 沒跑滿”這是很多多卡用戶最困惑的問題。明明服務(wù)器里安裝了四張 GPU四張卡都被正確識別顯存也全部占用了模型成功啟動沒有出現(xiàn) OOM。但運行模型時卻發(fā)現(xiàn)GPU 利用率忽高忽低 有的 GPU 長期等待 Token 生成速度沒有明顯提升 從兩張卡增加到四張卡延遲反而升高很多人會認(rèn)為是不是顯卡算力不夠 是不是 CUDA 沒安裝好 是不是量化模型有問題但真實原因可能恰恰相反GPU 計算得太快剩下的大量時間都暴露成了通信和等待。假設(shè)一個 Transformer 層被切分到四張 GPUGPU 0計算矩陣的一部分 GPU 1計算矩陣的一部分 GPU 2計算矩陣的一部分 GPU 3計算矩陣的一部分 ↓ 等待所有 GPU 完成局部計算 ↓ All-Reduce / All-Gather ↓ 合并計算結(jié)果 ↓ 進入下一層一張 GPU 即使已經(jīng)完成自己的部分也不能直接進入下一層。因為下一層需要的是完整結(jié)果。它必須等待其他 GPU 完成并等待集合通信結(jié)束。NCCL 的集合通信要求參與操作的各個 Rank 共同完成相應(yīng)操作。All-Reduce 會聚合所有 Rank 的結(jié)果并將結(jié)果返回給各個 RankAll-Gather 則會收集各 Rank 的數(shù)據(jù)并將完整結(jié)果分發(fā)給所有參與者。假設(shè)某一次執(zhí)行周期是有效計算10ms 跨卡通信15ms 同步等待5ms那么總時間為10 15 5 30ms真正用于 GPU 有效計算的時間占比是有效計算利用率 10 ÷10 15 5 33.3%也就是說剩下約三分之二的時間GPU 并不是沒有任務(wù)。它是在等待。整個執(zhí)行過程可能不斷重復(fù)計算 10ms 通信 15ms 等待 5ms 計算 10ms 通信 15ms 等待 5ms 計算 10ms 通信 15ms 等待 5ms于是你在nvidia-smi中看到的 GPU 利用率可能是100% → 20% → 0% → 100% → 15% → 0%GPU 可能在等待其他 GPU 完成局部計算NCCL 集合通信PCIe 數(shù)據(jù)傳輸CPU 內(nèi)存中轉(zhuǎn)跨 NUMA 節(jié)點傳輸上一個 Pipeline Stage最繁忙的 MoE 專家推理框架完成調(diào)度。因此GPU 利用率出現(xiàn)波動不一定說明 GPU 算力不足。更準(zhǔn)確的判斷是GPU 的計算階段很短通信和同步階段太長。多卡執(zhí)行時間可以粗略理解為總執(zhí)行時間 有效計算時間 數(shù)據(jù)傳輸時間 集合通信時間 同步等待時間 調(diào)度開銷當(dāng)通信和等待時間超過計算時間時繼續(xù)增加 GPU 數(shù)量并不會自動提升速度。因為 GPU 越多通信參與者越多同步點越多通信路徑越復(fù)雜最慢 GPU 拖累全局的概率越高。這就是多卡系統(tǒng)最反直覺的現(xiàn)象顯卡越快通信瓶頸反而可能越明顯。三、8 張 GPU 能運行為什么不能證明 K3 能服務(wù)評價一次大模型部署至少應(yīng)該分成三個層次。第一層能加載模型權(quán)重能夠進入顯存 不會發(fā)生 OOM第二層能生成模型可以完成前向傳播 能夠正確輸出 Token第三層能服務(wù)TTFT 達(dá)標(biāo) TPOT 達(dá)標(biāo) 吞吐量達(dá)標(biāo) 并發(fā)能力達(dá)標(biāo) 穩(wěn)定性達(dá)標(biāo) 單位成本達(dá)標(biāo)其中TTFT 是從請求發(fā)出到第一個 Token 出現(xiàn)的時間TPOT 是開始生成后每個新 Token 所需的時間Throughput 是整個系統(tǒng)每秒能夠為所有用戶生成多少 TokenConcurrency 是系統(tǒng)在延遲不失控的前提下可以同時服務(wù)多少請求。很多所謂的“最低配置”只能證明前兩層。它證明模型能裝進去也能輸出答案。但如果沒有公布TTFT TPOT 單請求 Tokens/s 總吞吐量 并發(fā)用戶數(shù) P95 / P99 延遲 長時間運行穩(wěn)定性 單位百萬 Token 成本就不能直接得出“適合生產(chǎn)部署”的結(jié)論。AMD 的 8 張 MI355X 方案本質(zhì)上是一次 Day-0 容量與正確性驗證而不是完整的生產(chǎn)性能報告。AMD 還特別說明模型在 TP8 下每張 GPU 約占用 190.974GiB 權(quán)重一條百萬 Token 序列的已知額外運行狀態(tài)估算還會占用每張 GPU 約 14.427GiB但這尚未包括通信緩沖區(qū)、Kernel Workspace、CUDA Graph、內(nèi)存碎片和框架運行時開銷。所以“8 卡能跑”的準(zhǔn)確含義是8 張 MI355X 能夠容納 K3 并完成最小功能驗證它不等于8 張 MI355X 已經(jīng)能以合理成本 高并發(fā)、低延遲地服務(wù) K3“能運行”和“能服務(wù)”之間隔著一整套推理系統(tǒng)工程。四、多卡性能不能只看顯卡還要看整臺機器的拓?fù)浜芏嗳速徺I GPU 服務(wù)器時只看四件事有幾個 PCIe 插槽 可以安裝幾張顯卡 總顯存有多少 電源功率夠不夠但這些信息只能說明顯卡能不能物理安裝進去。它不能說明這些顯卡能不能高效協(xié)同。真正決定多卡訓(xùn)練和推理性能的是GPU 型號 PCIe 代際 每張 GPU 的實際通道數(shù) PCIe 交換芯片 CPU 數(shù)量 NUMA 結(jié)構(gòu) GPU P2P 能力 NCCL 實際通信路徑例如主板上雖然有四個物理 x16 插槽但實際運行狀態(tài)可能是GPU 0PCIe 4.0 x16 GPU 1PCIe 4.0 x16 GPU 2PCIe 4.0 x8 GPU 3PCIe 4.0 x8物理上是 x16 長度的插槽不代表它真的獲得了 16 條 PCIe Lane。有些主板會因為 CPU 可用 PCIe Lane 數(shù)量有限在安裝多張 GPU 后自動降速。所以看到“4 個 PCIe x16 插槽”時還要繼續(xù)問四張卡同時安裝后 每張卡實際運行在 x16 還是 x8雙路 CPU 服務(wù)器還可能出現(xiàn)另一種結(jié)構(gòu)CPU 0 ├── GPU 0 └── GPU 1 CPU 1 ├── GPU 2 └── GPU 3GPU 0 和 GPU 1 通信時路徑可能是GPU 0 → PCIe Switch → GPU 1但 GPU 0 和 GPU 2 通信時路徑可能變成GPU 0 → PCIe → CPU 0 → CPU 間互聯(lián) → CPU 1 → PCIe → GPU 2這條路徑跨越了兩顆 CPU 和兩個 NUMA 域。通常意味著傳輸路徑更長延遲更高可用帶寬更低CPU 間互聯(lián)也會成為共享瓶頸NUMA 內(nèi)存訪問更復(fù)雜。NVIDIA 的nvidia-smi topo -m會顯示 GPU、CPU、NUMA 和網(wǎng)絡(luò)設(shè)備之間的拓?fù)潢P(guān)系。其中PIX 表示經(jīng)過單個 PCIe SwitchPXB 表示經(jīng)過多個 PCIe SwitchPHB 表示經(jīng)過 CPU 的 PCIe Host BridgeSYS 則表示路徑還需要穿越 NUMA 節(jié)點之間的 CPU 互聯(lián)。因此可以粗略理解為NV#通常最好 PIX路徑較短 PXB經(jīng)過多個 PCIe Switch PHB經(jīng)過 CPU Host Bridge NODE同一 NUMA 節(jié)點內(nèi)跨 Host Bridge SYS跨 NUMA 或 CPU 間互聯(lián)假設(shè)拓?fù)浣Y(jié)果是GPU0 GPU1 GPU2 GPU3 GPU0 X PIX SYS SYS GPU1 PIX X SYS SYS GPU2 SYS SYS X PIX GPU3 SYS SYS PIX X這說明GPU0 和 GPU1 路徑較近 GPU2 和 GPU3 路徑較近 兩組 GPU 之間需要跨 NUMA 或 CPU 互聯(lián)那么更合理的 TP2 組合是GPU0 GPU1實例 A GPU2 GPU3實例 B而不是GPU0 GPU2 GPU1 GPU3必須記住GPU 編號相鄰不代表物理路徑相鄰。多卡性能不是由顯卡列表決定的。它是由顯卡之間的數(shù)據(jù)路徑?jīng)Q定的。五、最危險的情況GPU 之間不能直接 P2P理想的 GPU 間通信路徑是GPU 0 顯存 ↓ GPU P2P ↓ GPU 1 顯存GPU 0 可以直接訪問或傳輸數(shù)據(jù)到 GPU 1 的顯存。CUDA 是否支持兩張 GPU 直接訪問彼此顯存可以通過cudaDeviceCanAccessPeer()判斷并通過cudaDeviceEnablePeerAccess()啟用。它是否可用取決于具體的 GPU、PCIe 或 NVLink 拓?fù)湟约跋到y(tǒng)配置。如果 P2P 無法使用數(shù)據(jù)傳輸可能需要經(jīng)過主機內(nèi)存GPU 0 顯存 ↓ PCIe ↓ CPU 內(nèi)存 ↓ PCIe ↓ GPU 1 顯存這會帶來兩個直接問題。第一多了一次或多次數(shù)據(jù)復(fù)制。第二CPU、系統(tǒng)內(nèi)存帶寬和 PCIe 會同時成為瓶頸。原本應(yīng)該由 GPU 直接完成的數(shù)據(jù)交換現(xiàn)在需要 CPU 內(nèi)存參與中轉(zhuǎn)。如果每生成一個 Token都要在幾十層甚至上百層模型中反復(fù)進行這種傳輸性能損失會被不斷放大。NVIDIA 的 CUDA 文檔明確說明啟用 P2P 后GPU 間復(fù)制不再需要通過 Host Staging也就是不必經(jīng)過主機內(nèi)存中轉(zhuǎn)因此通常會更快。但 P2P 并不是“顯卡插在同一臺機器里”就自動成立。它還可能受到以下因素影響GPU 是否支持相應(yīng) P2P 路徑PCIe 拓?fù)潋?qū)動版本BIOS 配置虛擬機環(huán)境容器對系統(tǒng)拓?fù)涞谋┞禝OMMUACSGPU 與 PCIe Switch 的連接方式。NCCL 官方文檔指出NCCL 會優(yōu)先使用 GPU Direct 和 P2P 進行 GPU 間通信。但錯誤的虛擬機、容器、BIOS 或 PCIe 配置都可能導(dǎo)致 P2P 不可用或性能很差。其中 ACS 是一個非常典型的坑。ACS 可能把原本可以直接進行的 PCIe 點對點流量強制重定向到 CPU Root Complex。結(jié)果就是原本 GPU 0 → PCIe Switch → GPU 1 變成 GPU 0 → CPU Root Complex → GPU 1NVIDIA 的 NCCL 故障排查文檔明確指出VT-d、IOMMU 和 ACS 可能干擾 GPU Direct把點對點流量重定向到 CPU Root Complex從而造成顯著性能下降嚴(yán)重時甚至可能導(dǎo)致任務(wù)掛起。所以絕對不能簡單認(rèn)為四張卡都插在同一臺服務(wù)器里就一定可以高速互訪。物理上位于同一臺服務(wù)器不等于邏輯上能夠直接訪問彼此顯存。六、不同并行方式對通信的敏感度完全不同很多多卡性能問題本質(zhì)上不是顯卡性能差而是并行策略和硬件條件不匹配。常見并行方式至少包括數(shù)據(jù)并行 DP 張量并行 TP 流水線并行 PP 專家并行 EP它們對 GPU 通信的依賴程度完全不同。1. 數(shù)據(jù)并行最適合消費級多卡推理推理場景中的數(shù)據(jù)并行可以理解為每張 GPU 保存一份完整模型然后分別處理不同請求。GPU 0完整模型副本處理用戶 A GPU 1完整模型副本處理用戶 B GPU 2完整模型副本處理用戶 C GPU 3完整模型副本處理用戶 D不同 GPU 之間幾乎不需要頻繁交換中間狀態(tài)。它的優(yōu)點是單卡利用率通常更穩(wěn)定總并發(fā)能力強對 PCIe 和 NVLink 要求較低單個請求不需要跨 GPU 同步某張 GPU 故障不一定影響全部服務(wù)尾延遲更容易控制。缺點也很明顯每張 GPU 都必須完整保存一份模型。但只要模型能放進單卡這通常就是四卡服務(wù)器最高效的使用方式。例如企業(yè)內(nèi)部的RAG知識庫問答Agent代碼助手文檔分析OCREmbeddingReranker。這些系統(tǒng)通常面對的是多個并發(fā)用戶。真正需要優(yōu)化的是同時服務(wù)更多請求而不是讓一個請求同時占滿所有 GPU所以只要模型能放進一張卡優(yōu)先考慮多個模型副本。2. 張量并行最容易被通信拖死張量并行會把同一層中的矩陣計算切分到多張 GPU。一層 Transformer ├── GPU 0 計算 25% ├── GPU 1 計算 25% ├── GPU 2 計算 25% └── GPU 3 計算 25%每張 GPU 完成自己的局部計算以后還需要交換和合并結(jié)果。因此幾乎每一層都可能執(zhí)行All-ReduceAll-GatherReduce-Scatter。假設(shè)模型有 80 層。那么生成一個 Token 的過程中就可能發(fā)生大量跨 GPU 同步。張量并行最麻煩的地方不一定是單次傳輸量特別大。而是通信發(fā)生得非常頻繁。所以它非常依賴NVLinkNVSwitch高質(zhì)量 PCIe P2P良好的 GPU 拓?fù)銷CCL 拓?fù)鋬?yōu)化足夠大的 Batch計算與通信重疊。在只有 PCIe、沒有 NVLink 的消費級多卡服務(wù)器上經(jīng)常會出現(xiàn)TP1速度最快但模型放不下 TP2模型能運行性能尚可 TP4模型終于能放下但生成速度下降原因是 TP 從 2 增加到 4 后每張 GPU 的計算量減少了 但通信參與者增加了 同步點增加了 數(shù)據(jù)路徑更加復(fù)雜 最慢 Rank 的影響更明顯了所以TP4 很多時候不是性能優(yōu)化而是顯存不足時的容量妥協(xié)。3. 流水線并行通信少一些但容易出現(xiàn)氣泡流水線并行按照模型層數(shù)進行切分。GPU 0第 120 層 GPU 1第 2140 層 GPU 2第 4160 層 GPU 3第 6180 層GPU 0 完成前 20 層后將 Hidden State 發(fā)送給 GPU 1。GPU 1 再計算第 2140 層。與張量并行相比它不需要在每一層內(nèi)部進行完整的 All-Reduce。相鄰 Stage 主要傳遞 Hidden State。但它存在一個嚴(yán)重問題Pipeline Bubble也就是流水線氣泡。例如時間 1 GPU0 工作 GPU1、GPU2、GPU3 等待 時間 2 GPU0、GPU1 工作 GPU2、GPU3 等待 時間 3 GPU0、GPU1、GPU2 工作 GPU3 等待 時間 4 四張 GPU 才全部進入工作狀態(tài)想要減少流水線氣泡就需要持續(xù)輸入多個 Micro-batch讓不同 Stage 同時處理不同批次。但對于單用戶、本地聊天和低并發(fā)推理請求數(shù)量不足 Batch 太小 Micro-batch 不夠流水線就很難被填滿。于是即使安裝了四張 GPU也可能不斷出現(xiàn)部分 GPU 空轉(zhuǎn)。4. 專家并行對通信最兇險專家并行是 K3 這類 MoE 模型最需要警惕的部分。K3 擁有 896 個路由專家每個 Token 選擇其中 16 個專家。這些專家會被分布到不同 GPU。Router 完成選擇后可能得到Token 1 → GPU 0 上的專家 Token 2 → GPU 3 上的專家 Token 3 → GPU 1 上的專家 Token 4 → GPU 2 上的專家系統(tǒng)先執(zhí)行 Token Dispatch把 Token 發(fā)送到專家所在 GPU專家完成計算后再執(zhí)行 Expert Combine把專家結(jié)果發(fā)送回來 重新恢復(fù)原來的 Token 順序 合并計算結(jié)果這個過程通常依賴 All-to-All 通信。All-to-All 的意思是每張 GPU 都可能向其他所有 GPU 發(fā)送數(shù)據(jù) 同時 每張 GPU 也可能從其他 GPU 接收數(shù)據(jù)NCCL 對 All-to-All 的定義是每個 Rank 都提供面向所有目標(biāo) Rank 的數(shù)據(jù)塊并將對應(yīng)數(shù)據(jù)塊發(fā)送給相應(yīng) Rank。專家并行還有一個比通信更加麻煩的問題專家負(fù)載不均衡。例如某個 Batch 的路由結(jié)果是專家 A收到 10000 個 Token 專家 B收到 8000 個 Token 專家 C收到 100 個 Token 專家 D收到 20 個 Token專家 C 和專家 D 很快就計算完成。但整個系統(tǒng)不能直接繼續(xù)。因為專家 A 還沒有完成。結(jié)果可能變成GPU 0完成等待 GPU 1完成等待 GPU 2仍在處理熱門專家 GPU 3完成等待整個系統(tǒng)的速度最終由最慢的那個 Rank 決定。這就是分布式計算中的 Straggler也就是掉隊者問題。因此四種并行方式的通信敏感度可以粗略排序為數(shù)據(jù)并行 較低 流水線并行 中等 張量并行 較高 專家并行 最高這也解釋了為什么 K3 這種擁有 896 個專家的模型需要高帶寬、低延遲的高速互聯(lián)域。而不能簡單地認(rèn)為找?guī)资畯埾M級 GPU 把顯存加起來 就等于擁有一套 K3 推理集群顯存容量可能夠了。但通信系統(tǒng)很可能完全撐不住。七、為什么 104B 激活參數(shù)不等于一個普通的 104B 模型很多人看到 K3 的參數(shù)配置總參數(shù)2.8T 激活參數(shù)104B會下意識認(rèn)為雖然 K3 有 2.8T 參數(shù)但每次只用 104B所以部署難度應(yīng)該和一個 104B Dense 模型差不多。這個結(jié)論不成立?？梢园?K3 想象成一家擁有 896 名專家的公司。每次處理一個任務(wù)只邀請 16 名專家參加。這樣做的好處是公司可以擁有巨大的知識容量 但不需要每個任務(wù)都讓全部專家參與這就是 MoE 的價值。但是雖然一次只邀請 16 名專家開會896 名專家依然都需要辦公室。同樣總參數(shù)量 決定所有模型權(quán)重需要占用多少空間 激活參數(shù)量 決定一個 Token 大約需要執(zhí)行多少計算2.8T 總參數(shù)解釋了為什么 K3 的 Checkpoint 接近 1.56TB。104B 激活參數(shù)解釋了為什么每個 Token 不必讓全部 2.8T 參數(shù)參與計算。但 104B 激活參數(shù)沒有包括Router 計算Token DispatchExpert CombineAll-to-All 通信專家負(fù)載不均衡跨卡同步通信緩沖區(qū)等待最慢 Rank。因此激活參數(shù)描述的是“算多少”不是“搬多少”更不是“等多久”。K3 每個 Token 的計算量可能接近一個超大 Dense 模型。但它的系統(tǒng)行為和普通 Dense 模型完全不同。八、看 K3 這樣的超大模型必須同時算四本賬以后看到一個超大模型不能只看參數(shù)量。至少要同時計算四本賬。第一筆賬權(quán)重存儲理論權(quán)重大小可以粗略估算為權(quán)重大小 ≈ 參數(shù)數(shù)量 × 每個參數(shù)位數(shù) ÷ 8K3 有 2.8T 參數(shù)。假設(shè)全部按照 4bit 保存2.8T × 4bit ÷ 8 ≈ 1.4TB但真實模型中還包括部分高精度參數(shù)量化 ScaleEmbeddingNorm 參數(shù)視覺編碼器元數(shù)據(jù)文件格式開銷內(nèi)存對齊。因此K3 實際 Checkpoint 大約為 1.56TB。這筆賬決定的是模型權(quán)重能不能放進顯存第二筆賬每個 Token 的計算量激活參數(shù)決定一次前向傳播中大約有多少參數(shù)真正參與計算。MoE 的價值可以理解為很大的總參數(shù)容量 相對受控的單 Token 計算量但它沒有完整計算路由開銷 通信開銷 同步開銷 負(fù)載不均衡所以這筆賬回答的是大約需要算多少而不是最終需要運行多久第三筆賬KV Cache 和運行狀態(tài)生產(chǎn)環(huán)境中的顯存占用不只有模型權(quán)重。完整占用更接近總顯存占用 模型權(quán)重 KV Cache KDA / MLA 運行狀態(tài) 活躍請求狀態(tài) 通信緩沖區(qū) Kernel Workspace CUDA Graph 框架運行時 內(nèi)存碎片K3 支持最高 100 萬 Token 上下文但“一條百萬 Token 請求能夠運行”不代表“幾十條百萬 Token 請求能夠同時運行”。并發(fā)環(huán)境中運行狀態(tài)還會受到以下因素影響上下文長度 × 模型層數(shù) × 隱藏狀態(tài)規(guī)模 × 活躍請求數(shù)量所以支持百萬上下文是模型能力。能否以合理成本并發(fā)服務(wù)百萬上下文則是系統(tǒng)能力。第四筆賬GPU 通信多卡總時間可以粗略理解為總時間 計算時間 數(shù)據(jù)傳輸時間 集合通信時間 同步等待時間 調(diào)度開銷這筆賬最容易被忽略。卻經(jīng)常決定模型最終到底能跑多快。一個模型可能已經(jīng)成功放進顯存模型加載成功 GPU 全部識別 顯存全部占用但系統(tǒng)仍然可能處于GPU 很快完成計算 然后長時間等待通信所以能不能裝下是容量問題能不能高效運行是系統(tǒng)問題。九、沒有 NVLink消費級多卡還有價值嗎當(dāng)然有。但必須用對方式。以 RTX 4090 為例它沒有 NVLink多卡之間主要依賴 PCIe。這意味著它不適合所有跨卡并行方式。如果一個模型可以裝進單張 GPU可以讓多張 GPU 分別處理不同請求GPU 0處理用戶 A GPU 1處理用戶 B GPU 2處理用戶 C GPU 3處理用戶 D這種情況下不同 GPU 之間幾乎不需要頻繁交換中間狀態(tài)。四張 GPU 仍然可以顯著提高總吞吐。所以真正應(yīng)該問的不是服務(wù)器里有幾張 GPU而是一個請求需要跨越幾張 GPU一個請求跨越的 GPU 越多對通信的要求通常越高。因此消費級多卡最重要的原則不是盡量讓所有 GPU 都參與同一個請求而是盡量減少一個請求 需要跨越的 GPU 數(shù)量十、四張消費級 GPU應(yīng)該怎么分配假設(shè)你有四張 GPU可以根據(jù)模型容量分成三種情況。場景一模型可以裝進一張 GPU優(yōu)先部署四個獨立副本GPU 0模型副本 A GPU 1模型副本 B GPU 2模型副本 C GPU 3模型副本 D然后通過 API Gateway、LiteLLM 或負(fù)載均衡器分發(fā)請求。如果并發(fā)量不高也可以按照服務(wù)拆分GPU 0主語言模型 GPU 1視覺語言模型 GPU 2Embedding Reranker GPU 3OCR、批處理或備用實例這通常比強行把四張卡綁成一個 TP4 實例更加穩(wěn)定。場景二模型必須兩張 GPU 才能裝下優(yōu)先考慮兩個 TP2 實例GPU 0 GPU 1模型實例 A GPU 2 GPU 3模型實例 B而不是一個 TP4 實例GPU 0 GPU 1 GPU 2 GPU 3兩個 TP2 通常意味著每個實例參與通信的 GPU 更少總并發(fā)能力更高尾延遲更穩(wěn)定故障隔離更容易GPU 更容易持續(xù)執(zhí)行有效計算。但 GPU 配對不能只看編號。應(yīng)該結(jié)合nvidia-smi topo -m優(yōu)先選擇 PIX、PXB 或高速互聯(lián)路徑較近的 GPU。場景三模型必須四張 GPU 才能裝下這時候 TP4 是容量上的被迫選擇。目標(biāo)不應(yīng)該再是四張 GPU 必須長期保持 100% 利用率更合理的目標(biāo)是模型穩(wěn)定加載 不發(fā)生 OOM TTFT 可以接受 TPOT 可以接受 并發(fā)達(dá)到業(yè)務(wù)要求 NCCL 沒有走異常路徑 沒有嚴(yán)重 Host Staging 單位請求成本合理如果跨卡通信已經(jīng)占用大量時間那么 GPU 利用率只有 40% 或 50%不一定說明程序?qū)戝e了。它可能已經(jīng)接近當(dāng)前硬件拓?fù)涞男阅苌舷?。十一、真正排查多卡性能不能只?nvidia-sminvidia-smi的 GPU 利用率只能告訴你某個采樣窗口內(nèi) GPU 是否在執(zhí)行 Kernel。它不能直接告訴你GPU 為什么沒有執(zhí)行 Kernel 是在等待數(shù)據(jù) 還是在等待同步 還是在等待 CPU 還是在等待其他 GPU一套完整的多卡排查流程至少應(yīng)該包括以下步驟。第一步查看 GPU 拓?fù)鋘vidia-smi topo -m重點查看GPU 之間是 NV#、PIX、PXB、PHB、NODE 還是 SYS GPU 分別屬于哪個 NUMA 節(jié)點 GPU 和網(wǎng)卡之間的距離第二步查看 PCIe 實際速率nvidia-smi -q或者使用lspci -vv確認(rèn)每張 GPU 實際運行在PCIe 4.0 x16 PCIe 4.0 x8 PCIe 5.0 x16不要只看主板插槽外觀。第三步檢查 GPU P2Pnvidia-smi topo -p2p p其中p用于檢查 PCIe P2P 能力。NVIDIA 文檔也建議使用 CUDA Samples 中的工具測試 GPU 間 Peer Access、帶寬和延遲。例如p2pBandwidthLatencyTest它可以幫助確認(rèn)GPU 是否支持 Peer Access單向 P2P 帶寬雙向 P2P 帶寬GPU 間延遲。第四步測試 NCCL 集合通信可以使用nccl-tests./build/all_reduce_perf \ -b 8M \ -e 8G \ -f 2 \ -g 4分別測試-g 1 -g 2 -g 4重點關(guān)注algbw busbw 不同數(shù)據(jù)量下的帶寬 GPU 數(shù)量增加后的擴展效率如果從兩張 GPU 增加到四張 GPU 后通信帶寬沒有合理擴展甚至明顯下降就需要繼續(xù)檢查PCIe 拓?fù)銹2PPCIe LaneNUMACPU 綁定ACSIOMMUBIOS 設(shè)置。第五步查看 NCCL 實際通信路徑運行任務(wù)前開啟日志export NCCL_DEBUGINFO export NCCL_DEBUG_SUBSYSINIT,GRAPH,P2P重點觀察 NCCL 選擇的路徑P2P / IPC SHM NET Socket可以粗略理解為P2P / IPC GPU 之間直接傳輸通常更理想 SHM 通過主機共享內(nèi)存中轉(zhuǎn) NET / Socket 通過網(wǎng)絡(luò)或 Socket 通信如果同一臺服務(wù)器中的 GPU 通信大量退化到 SHM就需要進一步檢查P2P 是否被禁用ACS 是否強制流量繞路IOMMU容器權(quán)限/sys是否正確掛載PCIe 拓?fù)潋?qū)動和 NCCL 版本。第六步對比 TP1、TP2、TP4如果顯存允許應(yīng)分別測試TP1 TP2 TP4每一種配置至少記錄TTFTTPOT單請求 Tokens/s總吞吐量并發(fā)能力P50 延遲P95 延遲P99 延遲GPU 利用率GPU 顯存占用CPU 內(nèi)存占用。不要只比較模型能不能啟動。真正需要回答的是GPU 數(shù)量增加以后業(yè)務(wù)指標(biāo)到底有沒有改善十二、買顯卡之前應(yīng)該先決定怎么并行很多人的采購順序是先買顯卡 → 再選擇模型 → 最后研究怎么并行更合理的順序應(yīng)該反過來先確定業(yè)務(wù)負(fù)載 → 再確定模型規(guī)模 → 再選擇并行策略 → 最后選擇硬件采購之前至少應(yīng)該回答以下問題。1. 模型能不能裝進一張卡如果可以優(yōu)先考慮多個獨立副本。2. 模型至少需要幾張卡能用 TP2就不要為了“讓所有 GPU 都參與”而強行使用 TP4。3. 業(yè)務(wù)目標(biāo)是低延遲還是高并發(fā)低延遲更怕跨卡通信。高并發(fā)通常更適合多個獨立副本。4. 模型是 Dense 還是 MoEMoE 對以下能力更加敏感All-to-All 專家負(fù)載均衡 專家放置 GPU 高速互聯(lián) 跨節(jié)點 RDMA5. 每張 GPU 實際獲得多少 PCIe Lane物理 x16 插槽不等于實際運行在 x16。6. GPU 是否跨 CPU 和 NUMA跨 NUMA 會增加通信路徑和延遲。7. GPU P2P 是否真正可用必須通過命令和基準(zhǔn)測試確認(rèn)。8. NCCL 實測帶寬是多少購買多卡服務(wù)器時應(yīng)該要求供應(yīng)商提供真實 NCCL 測試結(jié)果而不只是顯卡規(guī)格表。十三、多卡服務(wù)器真正的采購清單下一次采購多卡服務(wù)器不要只問可以安裝幾張顯卡 總顯存有多少 電源功率夠不夠還要繼續(xù)追問每張 GPU 實際運行在 PCIe x16 還是 x8 四張卡同時安裝后是否會降速 GPU 分別掛在哪一顆 CPU 下 GPU 是否跨 NUMA 節(jié)點 GPU 之間是 NV#、PIX、PXB、PHB 還是 SYS 是否存在 PCIe Switch GPU P2P 是否可用 ACS 和 IOMMU 如何配置 NCCL All-Reduce 實測帶寬是多少 目標(biāo)模型準(zhǔn)備使用 DP、TP、PP 還是 EP TP2 和 TP4 的真實性能分別是多少 是否支持 GPU Direct RDMA 跨節(jié)點網(wǎng)絡(luò)使用什么網(wǎng)卡和交換機顯卡型號只能告訴你單個計算節(jié)點有多強拓?fù)浜屯ㄐ挪拍芨嬖V你這些節(jié)點能不能組成一個高效系統(tǒng)結(jié)語K3 開放了世界級模型但沒有消滅系統(tǒng)工程門檻Kimi K3 的開放確實具有標(biāo)志性意義。一個擁有 2.8T 參數(shù)、896 個專家、百萬 Token 上下文、進入全球第一梯隊的模型其完整權(quán)重已經(jīng)可以被開發(fā)者獲取。但 K3 同時也證明了一件更現(xiàn)實的事模型權(quán)重開放不等于部署門檻消失。8 張 MI355X 可以讓 K3 完成加載和正確性驗證。但這首先解決的是模型能不能放進去它還沒有完整回答模型放進去以后 能不能以合理的吞吐、延遲和成本運行同樣四張 24GB 顯卡的確可以提供 96GB 總顯存。但它們不會自動變成一張擁有 96GB 統(tǒng)一顯存、四倍算力和四倍速度的超級顯卡。顯存只能相對直接地相加。性能卻取決于單卡計算能力 × 并行策略 × GPU 通信帶寬 × PCIe 拓?fù)?× P2P 能力 × NUMA 路徑 × 批處理與調(diào)度 × 推理框架優(yōu)化對于消費級多卡服務(wù)器更合理的原則通常是模型盡量控制在一到兩張 GPU 內(nèi) 使用多個模型副本提高并發(fā) 按照真實拓?fù)溥x擇 GPU 組合 讓不同 GPU 承擔(dān)不同服務(wù) 容量不足時再提高張量并行規(guī)模以后再看到支持八卡 總顯存 192GB 四卡并行加速不要只看 GPU 數(shù)量。真正應(yīng)該追問的是這些 GPU 之間如何通信 數(shù)據(jù)會經(jīng)過哪些設(shè)備 P2P 是否可用 是否跨 CPU 和 NUMA NCCL 實測帶寬是多少 一個請求需要跨越幾張 GPU 選擇的是 DP、TP、PP 還是 EP當(dāng)你開始關(guān)注拓?fù)?、P2P、NCCL、NUMA 和并行策略時才算真正從“會買顯卡”進入了“會設(shè)計大模型計算系統(tǒng)”的階段。最后記住一句話K3 開放的是世界第一梯隊模型的權(quán)重但真正讓這種模型運行起來的不是某一張最強顯卡而是讓幾十張甚至上百張 GPU 像一臺機器一樣協(xié)同工作的系統(tǒng)能力。文章標(biāo)簽Kimi K3、大模型部署、MoE、GPU 通信、NCCL、張量并行、數(shù)據(jù)并行、流水線并行、專家并行、PCIe、P2P、NUMA、RTX 4090、AMD MI355X、分布式推理