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