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