實(shí)戰(zhàn)：用NVIDIA Sync組網(wǎng)部署70B大模型)
從 2025 年 NVIDIA GTC 發(fā)布以來DGX Spark 在本地大模型部署圈子里始終保持著很高的話題度。它把“桌面級設(shè)備跑百億甚至千億參數(shù)模型”這件事從概念變成了可落地的硬件方案。不過很多團(tuán)隊(duì)在實(shí)際使用時會遇到同一個問題單臺 DGX Spark 擁有 128GB 統(tǒng)一內(nèi)存看起來確實(shí)不小但當(dāng)你需要部署 200B 級別的模型或者業(yè)務(wù)要求同時處理多個并發(fā)推理請求時單機(jī)的內(nèi)存容量和總算力都會變得緊張。把兩臺 DGX Spark 通過 NVIDIA Sync 連接起來組成一個“兩臺設(shè)備協(xié)同工作的小集群”是解決這類需求的重要思路。本文將從核心概念、環(huán)境準(zhǔn)備、物理組網(wǎng)、軟件配置、推理框架部署到吞吐估算完整拆解整個連接與使用流程。無論你已經(jīng)在使用 DGX Spark還是正在調(diào)研本地私有化大模型部署方案這篇教程都可以作為參考。1. NVIDIA Sync 是什么DGX Spark 多機(jī)互聯(lián)的核心概念1.1 先理解 DGX Spark 的定位DGX Spark 不是傳統(tǒng)意義上的 PC 工作站。它基于 NVIDIA GB10 Grace Blackwell 超級芯片CPU 和 GPU 集成在一個封裝內(nèi)通過 NVLink-C2C 高速總線連接CPU 可以直接訪問 GPU 內(nèi)存。這種架構(gòu)帶來的直接好處是CPU 和 GPU 共享統(tǒng)一內(nèi)存池模型權(quán)重不需要在 CPU 內(nèi)存和顯存之間反復(fù)拷貝推理時的數(shù)據(jù)搬運(yùn)開銷大幅降低。內(nèi)存容量是 DGX Spark 最核心的指標(biāo)之一。128GB 統(tǒng)一內(nèi)存意味著即使不依賴外部服務(wù)器單臺設(shè)備也能加載相當(dāng)規(guī)模的量化模型。發(fā)布時 NVIDIA 官方的宣傳重點(diǎn)是“本地運(yùn)行 200B 參數(shù)模型”這一定位讓很多個人開發(fā)者和中小團(tuán)隊(duì)看到了私有化部署的可能性。與此同時DGX Spark 的價格也進(jìn)入了不少團(tuán)隊(duì)可以評估的區(qū)間具體售價請以官方渠道各時點(diǎn)信息為準(zhǔn)這也是它熱度持續(xù)走高的原因之一。但“可以運(yùn)行”和“運(yùn)行得好”是兩回事。200B 模型加載進(jìn)去之后單機(jī)還要同時承擔(dān) KV Cache、推理中間結(jié)果、服務(wù)框架自身的開銷。如果上下文長度拉長或者業(yè)務(wù)請求并發(fā)上來128GB 很快就會成為瓶頸。這時連接第二臺 DGX Spark用兩臺設(shè)備共同承擔(dān)推理任務(wù)就是最直接的擴(kuò)容方式。1.2 兩臺設(shè)備互聯(lián)的真實(shí)場景把兩臺 DGX Spark 連接在一起通常有四種典型場景。第一種是超大模型部署。當(dāng)模型權(quán)重加上運(yùn)行開銷超過了單臺設(shè)備的內(nèi)存容量又因?yàn)閿?shù)據(jù)安全原因不能放到云上雙機(jī)甚至多機(jī)協(xié)同就成了必經(jīng)之路。第二種是吞吐量優(yōu)化。單個 70B 級別的模型在單臺設(shè)備上推理時單并發(fā)輸出速度可能只有個位數(shù)到十幾 token/s。通過張量并行Tensor Parallelism把模型切分到兩臺設(shè)備上每臺設(shè)備只需要計算自己負(fù)責(zé)的那一部分理論上可以顯著提升單并發(fā)和低并發(fā)場景的吞吐。第三種是開發(fā)與生產(chǎn)環(huán)境隔離。你可以用一臺 DGX Spark 跑正式的推理服務(wù)另一臺做模型微調(diào)、評測和版本驗(yàn)證兩臺設(shè)備之間共享數(shù)據(jù)和調(diào)試通道。第四種是多模型并行。一臺設(shè)備跑對話模型另一臺設(shè)備跑向量化模型或 Reranker通過內(nèi)部網(wǎng)絡(luò)互相調(diào)用組成一套完整的 RAG 服務(wù)鏈路。無論哪種場景背后都需要一套可靠的多機(jī)通信機(jī)制。NVIDIA Sync 就是這套機(jī)制的入口。1.3 NVIDIA Sync 在連接中扮演什么角色嚴(yán)格來說NVIDIA Sync 不是“一個命令”或“一個工具”而是一整套面向 DGX Spark 多機(jī)協(xié)同的軟硬件方案。它的作用是讓兩臺 DGX Spark 從“網(wǎng)絡(luò)上互相能 ping 通”上升到“一個分布式推理系統(tǒng)”。這個升級過程包含三個層面。第一層是物理互連兩臺設(shè)備需要有高速網(wǎng)絡(luò)接口相連確保數(shù)據(jù)通路帶寬足夠。第二層是系統(tǒng)配置包括固定 IP、主機(jī)名解析、SSH 可信關(guān)系、防火墻放通等基礎(chǔ)工作。第三層是分布式運(yùn)行時也就是讓 PyTorch、NCCL、Ray 這些組件能夠感知到對方設(shè)備上的 GPU 算力和內(nèi)存資源并在框架層面完成多機(jī)調(diào)度。理解這一點(diǎn)很重要。很多初次接觸多機(jī)訓(xùn)練的開發(fā)者會以為“連接兩臺設(shè)備”只需要插一根線、設(shè)置一下 IP 就結(jié)束了但真正讓分布式推理跑起來還依賴軟件棧的完整配置。本文后續(xù)章節(jié)會按照這三個層面依次展開你可以把 NVIDIA Sync 理解成貫穿整個過程的方法論和官方能力集合而具體到操作就是每一層配置的逐步落實(shí)。2. 連接前的環(huán)境準(zhǔn)備與版本檢查2.1 硬件與場地準(zhǔn)備連接兩臺 DGX Spark 之前先確認(rèn)硬件條件。你需要準(zhǔn)備兩臺 DGX Spark并確保它們使用相同或兼容的電源規(guī)格和散熱環(huán)境。DGX Spark 的定位雖然是桌面設(shè)備但高負(fù)載推理時發(fā)熱和功耗仍然可觀不要把它塞進(jìn)密閉弱電箱或堆疊在一起使用設(shè)備之間至少要保持正常的通風(fēng)間距。網(wǎng)絡(luò)互連方面至少需要一條可靠的高速以太網(wǎng)線纜。如果條件允許建議通過支持萬兆或更高規(guī)格的交換機(jī)連接。直連線纜適合兩臺設(shè)備互連的簡單場景交換機(jī)組網(wǎng)則方便后續(xù)擴(kuò)展第三臺、第四臺設(shè)備。具體使用哪種線纜規(guī)格請以兩臺設(shè)備的實(shí)際網(wǎng)口類型和 NVIDIA 官方配件說明為準(zhǔn)不要隨意混用不兼容的線纜。連接思路是先規(guī)劃拓?fù)湓僭O(shè)置 IP最后驗(yàn)證鏈路。不要跳過規(guī)劃直接插線配置否則后續(xù)排查問題時線纜和 IP 的混亂會讓你浪費(fèi)大量時間。2.2 系統(tǒng)與軟件初始檢查DGX Spark 出廠搭載 NVIDIA 定制的 DGX OS底層是 Linux 系統(tǒng)。拿到設(shè)備后先通過顯示器和鍵鼠或者通過默認(rèn)管理網(wǎng)絡(luò) SSH 登錄系統(tǒng)做一輪基礎(chǔ)狀態(tài)檢查。# 查看系統(tǒng)發(fā)行版信息 cat /etc/os-release # 查看內(nèi)核版本 uname -a # 查看 GPU 是否被正確識別 nvidia-smi # 查看內(nèi)存與統(tǒng)一內(nèi)存信息 free -h如果nvidia-smi能正常輸出并且能看到 Grace Blackwell 芯片信息說明基礎(chǔ)驅(qū)動沒有問題。建議記錄下每臺設(shè)備的主機(jī)名、系統(tǒng)版本、驅(qū)動版本后續(xù)做多機(jī)互通時這些信息會幫助你快速判斷版本兼容性問題。2.3 軟硬件檢查清單檢查項(xiàng)說明驗(yàn)證方式系統(tǒng)版本兩臺設(shè)備應(yīng)保持同一大版本cat /etc/os-release驅(qū)動狀態(tài)GPU 能被正常識別nvidia-smi網(wǎng)絡(luò)接口確認(rèn)互聯(lián)接口名稱和速率ip link/ethtool主機(jī)名提前規(guī)劃避免重名hostnamectl防火墻放通集群通信端口sudo ufw statusSSH 服務(wù)開啟并允許密鑰登錄systemctl status ssh注意如果你的設(shè)備是剛拆箱的建議先按照 NVIDIA 官方文檔完成系統(tǒng)初始化和驅(qū)動更新再進(jìn)行雙機(jī)連接操作。版本需要根據(jù)你的實(shí)際設(shè)備情況調(diào)整本文示例以常見 Linux 環(huán)境為例重點(diǎn)演示配置思路。3. 物理連接與網(wǎng)絡(luò)組網(wǎng)3.1 選擇連接拓?fù)鋬膳_ DGX Spark 最簡單的連接方式是直連用一根高速網(wǎng)線把兩臺設(shè)備的互聯(lián)網(wǎng)口直接連起來。這種方式延遲低、沒有交換機(jī)轉(zhuǎn)發(fā)開銷適合兩臺設(shè)備固定的場景。如果后續(xù)還要擴(kuò)展更多設(shè)備則建議使用交換機(jī)。通過交換機(jī)連接時所有設(shè)備處于同一個二層網(wǎng)絡(luò)中IP 規(guī)劃更靈活排查問題也更方便。無論采用哪種拓?fù)涠冀ㄗh為集群規(guī)劃專用的靜態(tài) IP 網(wǎng)段例如設(shè)備主機(jī)名IP 地址設(shè)備 Adgx-a192.168.100.10設(shè)備 Bdgx-b192.168.100.11使用獨(dú)立網(wǎng)段避免和辦公網(wǎng)絡(luò)沖突是雙機(jī)組網(wǎng)的基本功。固定 IP 不僅方便記憶更重要的是后續(xù) NCCL、Ray 等分布式組件需要穩(wěn)定的地址發(fā)現(xiàn)機(jī)制。3.2 配置網(wǎng)絡(luò)接口連接好線纜后需要確認(rèn)系統(tǒng)是否識別到了新的網(wǎng)絡(luò)接口。使用ip addr查看所有網(wǎng)絡(luò)接口找到與互聯(lián)線纜對應(yīng)的那個接口名。不同系統(tǒng)下接口名可能不同常見形式包括enp1s0f0np0、eth0等。接下來為接口配置靜態(tài) IP。以設(shè)備 A 為例# 查看接口狀態(tài) ip addr show # 使用 nmcli 配置靜態(tài) IP需要根據(jù)實(shí)際接口名和連接名調(diào)整 sudo nmcli con mod Wired Connection \ ipv4.addresses 192.168.100.10/24 \ ipv4.gateway \ ipv4.method manual # 啟用連接 sudo nmcli con up Wired Connection # 再次確認(rèn) IP 是否生效 ip addr show設(shè)備 B 同樣操作設(shè)置192.168.100.11/24。這里要特別注意如果系統(tǒng)里存在多個網(wǎng)卡務(wù)必確認(rèn)你修改的是互聯(lián)接口而不是管理網(wǎng)絡(luò)接口否則可能把設(shè)備“配斷網(wǎng)”。3.3 連通性驗(yàn)證與 SSH 配置IP 配置完成后先驗(yàn)證鏈路是否通暢。# 從設(shè)備 A ping 設(shè)備 B ping 192.168.100.11 # 查看網(wǎng)卡速率與協(xié)商狀態(tài) ethtool 接口名ping通了只代表二層和三層網(wǎng)絡(luò)正常還不能說明帶寬和穩(wěn)定性。建議進(jìn)一步用iperf3做一次簡單的帶寬壓測# 設(shè)備 B 先啟動服務(wù)端 iperf3 -s # 設(shè)備 A 以客戶端模式測試 30 秒 iperf3 -c 192.168.100.11 -t 30通過測試數(shù)據(jù)可以確認(rèn)實(shí)際傳輸帶寬是否接近網(wǎng)卡協(xié)商速率。如果帶寬明顯偏低檢查線纜是否插到了正確的接口、是否啟用了巨型幀Jumbo Frame、是否有網(wǎng)卡降速現(xiàn)象。網(wǎng)絡(luò)通暢后配置 SSH 免密登錄。這一步非常關(guān)鍵因?yàn)楹罄m(xù)分布式組件在多機(jī)之間拉起進(jìn)程時通常依賴 SSH 免密能力。# 在設(shè)備 A 上生成密鑰如果還沒有 ssh-keygen -t ed25519 # 將公鑰復(fù)制到設(shè)備 B ssh-copy-id dgx-b192.168.100.11 # 驗(yàn)證免密登錄 ssh dgx-b192.168.100.11 hostname同樣操作將設(shè)備 B 的公鑰復(fù)制到設(shè)備 A實(shí)現(xiàn)雙向免密。4. 軟件配置與多機(jī)協(xié)同驗(yàn)證4.1 更新系統(tǒng)與基礎(chǔ)組件網(wǎng)絡(luò)層就緒后進(jìn)入軟件配置階段。首先確保兩臺設(shè)備的系統(tǒng)組件、驅(qū)動和 CUDA 工具鏈處于相近版本。# 更新系統(tǒng)軟件源和軟件包 sudo apt update sudo apt upgrade -y # 查看驅(qū)動與 CUDA 版本 nvidia-smi nvcc --version如果兩臺設(shè)備的驅(qū)動或 CUDA 版本差異較大分布式框架在初始化 NCCL 時可能報錯。最好的做法是讓兩臺設(shè)備保持相同版本避免“能 ping 通但框架通信失敗”的尷尬情況。4.2 配置主機(jī)名解析分布式框架在多機(jī)通信時經(jīng)常需要通過主機(jī)名解析 IP 地址。建議在兩臺設(shè)備的/etc/hosts中同時寫入對方的信息避免依賴 DNS 服務(wù)。# 文件路徑/etc/hosts 192.168.100.10 dgx-a 192.168.100.11 dgx-b修改完成后分別在兩臺設(shè)備上執(zhí)行ping dgx-a和ping dgx-b驗(yàn)證主機(jī)名解析是否生效。4.3 使用 NVIDIA Sync 建立多機(jī)協(xié)同會話NVIDIA Sync 的正式啟用通常會借助 NVIDIA 提供的管理工具或控制臺完成設(shè)備注冊與發(fā)現(xiàn)。具體入口和界面會隨軟件版本迭代而變化建議以官方文檔和工具界面為準(zhǔn)。這里要理解的核心鏈路是設(shè)備發(fā)現(xiàn) → 網(wǎng)絡(luò)檢測 → 會話建立 → 資源分配到分布式運(yùn)行時。如果暫時沒有系統(tǒng)管理工具也可以通過完全手動的分布式配置達(dá)到同樣的多機(jī)協(xié)同效果。本質(zhì)上我們需要的是一套能讓兩臺設(shè)備上的 GPU 互相感知的運(yùn)行時環(huán)境。這一步可以通過 NCCL 測試來完成驗(yàn)證。4.4 用 NCCL 測試驗(yàn)證雙機(jī)通信NCCLNVIDIA Collective Communications Library是 NVIDIA 提供的多 GPU 和多節(jié)點(diǎn)通信庫PyTorch 分布式訓(xùn)練和 vLLM 多卡推理底層都依賴它。下面用一段最簡單的 PyTorch 程序驗(yàn)證兩臺 DGX Spark 能否通過 NCCL 正常通信。# 文件路徑任意目錄/test_allreduce.py import torch import torch.distributed as dist def main(): # 初始化分布式進(jìn)程組使用 NCCL 后端 dist.init_process_group(backendnccl) rank dist.get_rank() local_rank dist.get_local_rank() # 當(dāng)前進(jìn)程綁定到本機(jī)對應(yīng)的 GPU torch.cuda.set_device(local_rank) # 每個進(jìn)程創(chuàng)建一個初始值等于 rank 的 tensor tensor torch.ones(1, devicecuda) * rank # 所有進(jìn)程執(zhí)行 all_reduce 求和 dist.all_reduce(tensor, opdist.ReduceOp.SUM) if rank 0: print(frank{rank}, all_reduce result{tensor.item()}) else: print(frank{rank}, all_reduce result{tensor.item()}) if __name__ __main__: main()在設(shè)備 A 上啟動torchrun --nnodes2 --nproc-per-node1 --node-rank0 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py在設(shè)備 B 上啟動torchrun --nnodes2 --nproc-per-node1 --node-rank1 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py正常情況下兩臺終端窗口都會輸出all_reduce result1.0。因?yàn)?rank 0 的初始值是 0rank 1 的初始值是 1求和結(jié)果為 1。如果能看到這個結(jié)果說明 NCCL 可以正?？绻?jié)點(diǎn)通信分布式運(yùn)行時已經(jīng)打通。小提示這里的nproc-per-node1表示每個節(jié)點(diǎn)啟動 1 個進(jìn)程。如果單臺設(shè)備上實(shí)際只有一個 GPU 實(shí)例寫 1 即可如果設(shè)備被系統(tǒng)識別為多個計算實(shí)例可以按實(shí)際數(shù)量調(diào)整。5. 雙機(jī)部署 70B/200B 模型的實(shí)戰(zhàn)案例5.1 實(shí)戰(zhàn)目標(biāo)打通雙機(jī)通信后就可以進(jìn)入真正的推理部署階段。本文的實(shí)戰(zhàn)目標(biāo)有兩個用兩臺 DGX Spark 部署一個 70B 級別的量化模型開啟張量并行Tensor Parallelism驗(yàn)證雙機(jī)推理效果。討論 200B 級別模型在雙機(jī) 256GB 統(tǒng)一內(nèi)存下的部署可能性與注意事項(xiàng)。說明以下示例以 vLLM 為主要推理框架因?yàn)樗鼘Χ鄼C(jī)多卡支持較成熟并且提供 OpenAI 兼容的 API 服務(wù)。實(shí)際使用時可以根據(jù)模型格式和版本選擇 SGLang、TGI 等框架思路是相通的。5.2 建立 Ray 集群vLLM 多機(jī)推理通常通過 Ray 集群協(xié)調(diào)跨節(jié)點(diǎn)資源。先在一臺設(shè)備上啟動 Ray head 節(jié)點(diǎn)然后在另一臺設(shè)備上加入集群。# 在設(shè)備 A主節(jié)點(diǎn)啟動 Ray head ray start --head --port6379看到 Ray 啟動成功的日志后在設(shè)備 B 上執(zhí)行加入命令# 在設(shè)備 B 加入設(shè)備 A 管理的集群 ray start --address192.168.100.10:6379使用ray status可以確認(rèn)兩臺設(shè)備是否都已加入集群。如果能看到兩個節(jié)點(diǎn)并且每個節(jié)點(diǎn)都貢獻(xiàn)了 GPU 資源說明 Ray 集群就緒。Linux 命令補(bǔ)充# 查看 Ray 集群狀態(tài) ray status5.3 用 vLLM 啟動雙機(jī)張量并行推理假設(shè) 70B 模型權(quán)重已經(jīng)存放在每臺設(shè)備的本地磁盤路徑/data/models/qwen-70b-awq下實(shí)際路徑請?zhí)鎿Q為你自己的模型目錄在設(shè)備 A 上啟動 vLLM 服務(wù)vllm serve /data/models/qwen-70b-awq \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --api-key local-test關(guān)鍵參數(shù)含義--tensor-parallel-size 2張量并行度為 2讓模型權(quán)重切分到兩臺設(shè)備上。如果 Ray 集群中有兩個節(jié)點(diǎn)vLLM 會自動跨節(jié)點(diǎn)調(diào)度。--max-model-len 8192限制最大上下文長度避免 KV Cache 占用過多內(nèi)存。--api-key local-test為 API 設(shè)置訪問密鑰僅用于本地測試環(huán)境。如果你的 vLLM 版本較老不支持vllm serve子命令可以使用python -m vllm.entrypoints.openai.api_server啟動參數(shù)完全一致。不同版本的 vLLM 在多機(jī)調(diào)度的細(xì)節(jié)上有差異較新版本會自動識別 Ray 集群老版本可能需要額外指定--distributed-executor-backend ray。遇到問題先看啟動日志根據(jù)日志提示調(diào)整即可。5.4 發(fā)送推理請求驗(yàn)證服務(wù)啟動后通過 curl 發(fā)送一個聊天補(bǔ)全請求curl http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 介紹一下 DGX Spark 的主要特點(diǎn)}], max_tokens: 256 }如果一切正常你會收到包含生成文本的 JSON 響應(yīng)。此時打開nvidia-smi觀察兩臺設(shè)備的 GPU 利用率應(yīng)該能看到兩臺設(shè)備都在參與計算。對于 200B 模型雙機(jī)部署的思路完全一樣但需要注意兩點(diǎn)第一200B 模型的量化版本通常在 100GB 到 120GB 之間雙機(jī) 256GB 統(tǒng)一內(nèi)存可以比較從容地加載還能剩余一部分空間給 KV Cache第二當(dāng)模型權(quán)重超過單機(jī)內(nèi)存容量時--tensor-parallel-size 2幾乎是必須的配置盡量避免單機(jī)強(qiáng)行加載導(dǎo)致內(nèi)存溢出。6. 聚焦兩臺 DGX Spark 張量并行 70B 模型的單并發(fā)吞吐估算6.1 為什么單并發(fā)吞吐主要受內(nèi)存帶寬限制很多人在雙機(jī)部署 70B 模型后最關(guān)心的就是單并發(fā)輸出速度到底每秒能生成多少 token回答這個問題之前先要理解大模型推理的性能瓶頸。在 decode 階段也就是逐 token 生成階段模型需要把全部權(quán)重從內(nèi)存中讀取一遍參與每一輪計算。相比計算量權(quán)重讀取對內(nèi)存帶寬的需求更為突出。換句話說單并發(fā)推理的極限速度很大程度上取決于“在多長時間內(nèi)把模型權(quán)重完整讀一遍”。6.2 理論估算方法假設(shè)一個 70B 模型以 4bit 量化保存權(quán)重總量大約為 35GB。如果單臺 DGX Spark 的統(tǒng)一內(nèi)存帶寬在 250GB/s 量級具體數(shù)值請以官方規(guī)格表為準(zhǔn)那么單機(jī)每生成一個 token理論最低耗時約為35GB / 250GB/s ≈ 0.14 秒換算成吞吐就是大約 7 token/s 的上限。這只是一個純讀取權(quán)重的理論值實(shí)際還會疊加計算開銷、KV Cache 訪問、框架調(diào)度等所以真實(shí)值通常低于這個數(shù)字。6.3 雙機(jī)張量并行的理論收益使用張量并行、把模型切分到兩臺設(shè)備時每臺設(shè)備只需要讀取自己負(fù)責(zé)的那一半權(quán)重。每臺設(shè)備讀取量35GB / 2 17.5GB 理想讀取耗時17.5GB / 250GB/s ≈ 0.07 秒如果不考慮通信開銷雙機(jī)單并發(fā)吞吐可以達(dá)到約 14 token/s。但這個理想值無法完全實(shí)現(xiàn)因?yàn)槊看吻跋蛴嬎愣夹枰ㄟ^集群網(wǎng)絡(luò)同步中間結(jié)果。假設(shè)每一次通信需要 20 到 40 毫秒那么實(shí)際耗時就在 0.09 到 0.11 秒之間對應(yīng)的吞吐大約在 9 到 11 token/s。所以雙機(jī)張量并行對單并發(fā)吞吐的提升通常不是嚴(yán)格的 2 倍而是接近 1.3 到 1.8 倍具體取決于互聯(lián)帶寬、模型量化精度和框架實(shí)現(xiàn)。6.4 如何實(shí)測真實(shí)吞吐理論估算只能幫你做容量規(guī)劃真實(shí)環(huán)境必須依賴實(shí)測。vLLM 啟動后直接向 API 發(fā)送多次請求統(tǒng)計生成 token 總數(shù)和總耗時即可。# 使用 curl 請求 10 次統(tǒng)計總耗時然后計算平均 token/s time for i in $(seq 1 10); do curl -s http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 寫一段關(guān)于人工智能發(fā)展的短文}], max_tokens: 512 } | jq -r .usage.completion_tokens done通過多次請求取平均值可以得到相對穩(wěn)定的單并發(fā)吞吐數(shù)據(jù)。測試時要注意預(yù)熱前幾次請求可能包含權(quán)重加載、CUDA kernel 初始化等額外耗時正式統(tǒng)計時先發(fā)幾個請求預(yù)熱再開始計時結(jié)果更有參考價值?？偟膩碚f如果你在網(wǎng)上看到有人提到“兩臺 DGX Spark 張量并行跑 70B 模型單并發(fā)輸出大約在 8 到 15 token/s”這個量級是符合內(nèi)存帶寬模型的。實(shí)際數(shù)字會因?yàn)榱炕粚?、上下文長度、模型架構(gòu)、框架版本和網(wǎng)絡(luò)質(zhì)量的不同而變化不必糾結(jié)于某個具體數(shù)字。7. 常見問題與排查思路7.1 高頻問題與處理對照表雙機(jī)互聯(lián)和分布式推理涉及網(wǎng)絡(luò)、系統(tǒng)驅(qū)動、運(yùn)行時、框架四個層面任何一層出現(xiàn)問題都可能導(dǎo)致集群不可用。下面以表格形式梳理高頻問題方便快速定位。問題現(xiàn)象常見原因排查與解決思路兩臺設(shè)備互相 ping 不通線纜未插好、接口選錯、IP 沖突檢查線纜與接口確認(rèn) IP 是否在同一網(wǎng)段關(guān)閉無關(guān)網(wǎng)卡SSH 連接失敗sshd 未啟動、防火墻攔截、密鑰權(quán)限錯誤檢查 sshd 服務(wù)狀態(tài)放通 22 端口修復(fù)密鑰目錄權(quán)限NCCL 初始化超時/etc/hosts 未配置、防火墻攔截通信端口、master 地址不可達(dá)補(bǔ)齊 hosts放通分布式通信端口用NCCL_DEBUGINFO查看日志分布式測試耗時異常高實(shí)際走了以太網(wǎng)回環(huán)或降速鏈路用ethtool檢查網(wǎng)卡速率用iperf3驗(yàn)證帶寬vLLM 啟動時找不到足夠的 GPURay 集群未正確加入或--tensor-parallel-size大于實(shí)際可用 GPUray status確認(rèn)節(jié)點(diǎn)數(shù)檢查CUDA_VISIBLE_DEVICES環(huán)境變量推理時顯存/內(nèi)存不足模型權(quán)重太大、KV Cache 過大、并發(fā)請求過多降低--max-model-len減少并發(fā)數(shù)換更低量化位寬雙機(jī)推理反而比單機(jī)慢通信開銷過大、網(wǎng)絡(luò)帶寬不足、量化后 GPU 計算占比變高檢查網(wǎng)絡(luò)帶寬考慮使用流水線并行替代張量并行或減少并行度7.2 NCCL 調(diào)試日志的使用方法當(dāng) NCCL 通信出現(xiàn)異常時最有效的排查方式就是打開調(diào)試日志。# 在啟動 torchrun 或 vllm 前設(shè)置環(huán)境變量 export NCCL_DEBUGINFO # 如果需要更多細(xì)節(jié)可以設(shè)置為 TRACE # export NCCL_DEBUGTRACE日志中會顯示 NCCL 選擇了哪個網(wǎng)絡(luò)接口、連接了哪個 IP、在哪一步超時?？吹筋愃芅ET/IB的日志表示 NCCL 嘗試使用 InfiniBand 或 RoCE 設(shè)備看到NET/Socket則說明當(dāng)前使用的是傳統(tǒng) TCP Socket。生產(chǎn)環(huán)境排錯時先明確這條信息能幫你快速判斷問題出在物理鏈路還是協(xié)議配置上。7.3 防火墻與端口放通建議分布式訓(xùn)練與推理需要放通多類端口。這里整理一份常見端口清單具體端口號可能因框架版本不同而變化請以實(shí)際配置為準(zhǔn)。服務(wù)默認(rèn)端口說明SSH22遠(yuǎn)程登錄Ray Head6379集群協(xié)調(diào)vLLM API8000OpenAI 兼容接口torchrun 主節(jié)點(diǎn)29500PyTorch 分布式協(xié)調(diào)NCCL 動態(tài)端口隨機(jī)高端口建議先NCCL_DEBUGINFO看實(shí)際端口在兩臺設(shè)備互相通信時優(yōu)先保證這些端口在集群內(nèi)部網(wǎng)段可以訪問。如果公司網(wǎng)絡(luò)存在安全組或防火墻務(wù)必在測試環(huán)境中先驗(yàn)證規(guī)則再上生產(chǎn)。8. 最佳實(shí)踐與工程建議8.1 網(wǎng)絡(luò)與拓?fù)鋵用娴慕ㄗh雙機(jī)互聯(lián)的穩(wěn)定性直接決定分布式推理的上限。建議把集群組網(wǎng)獨(dú)立到專用網(wǎng)段不要與辦公網(wǎng)絡(luò)共用廣播域。固定 IP 之后務(wù)必寫入/etc/hosts避免依賴 DHCP 分配產(chǎn)生地址漂移。如果業(yè)務(wù)對延遲敏感優(yōu)先考慮直連拓?fù)錅p少交換機(jī)轉(zhuǎn)發(fā)跳數(shù)。如果使用交換機(jī)確保交換機(jī)端口速率與網(wǎng)卡匹配不要出現(xiàn)千兆網(wǎng)口接萬兆網(wǎng)卡導(dǎo)致降速的問題。有條件的話建議開啟對稱巨型幀支持Jumbo Frame但需要同時確認(rèn)交換機(jī)、網(wǎng)卡和驅(qū)動都支持并保持兩端 MTU 一致否則反而會引發(fā)分片問題。8.2 模型與數(shù)據(jù)管理建議多機(jī)推理時模型權(quán)重建議直接放在每臺設(shè)備的本地 NVMe 存儲中。雖然通過 NFS 共享權(quán)重看起來很省事但訓(xùn)練或推理啟動時會并發(fā)讀取大量文件NFS 很容易成為瓶頸。如果必須使用共享存儲可以考慮只在啟動階段復(fù)制權(quán)重到本地推理過程中不要依賴共享存儲。另外建議建立規(guī)范的模型目錄結(jié)構(gòu)。例如統(tǒng)一使用/data/models/模型名-量化精度的形式并在啟動腳本中通過環(huán)境變量傳入模型路徑避免在多臺設(shè)備上路徑不一致導(dǎo)致服務(wù)啟動失敗。# 推薦在啟動腳本中顯式定義環(huán)境變量 export MODEL_PATH/data/models/qwen-70b-awq export TENSOR_PARALLEL_SIZE2 export API_KEYlocal-test統(tǒng)一變量管理減少手動改命令導(dǎo)致的低級錯誤。8.3 監(jiān)控與日志管理雙機(jī)集群的運(yùn)維復(fù)雜度高于單機(jī)。建議至少配置以下監(jiān)控項(xiàng)GPU 利用率與溫度nvidia-smi dmon統(tǒng)一內(nèi)存使用率nvidia-smi中的 Memory-Usage網(wǎng)絡(luò)吞吐iperf3或nload推理服務(wù)日志vLLM 的訪問日志與錯誤日志可以使用 systemd 管理推理服務(wù)保證服務(wù)異常退出時能自動重啟。日志輸出到文件后配合logrotate做輪轉(zhuǎn)避免日志文件無限增長占滿磁盤。8.4 安全與運(yùn)維邊界涉及生產(chǎn)環(huán)境的多機(jī)集群變更務(wù)必遵循最低權(quán)限原則。日常維護(hù)使用普通用戶只有安裝軟件和修改系統(tǒng)配置時才使用 sudo。SSH 登錄建議全部改為密鑰認(rèn)證并禁止密碼登錄。推理服務(wù)不要直接暴露到公網(wǎng)。如果業(yè)務(wù)需要遠(yuǎn)程訪問通過企業(yè)內(nèi)部網(wǎng)絡(luò)或安全網(wǎng)關(guān)轉(zhuǎn)發(fā)并在網(wǎng)關(guān)層做訪問控制和審計。模型權(quán)重和訓(xùn)練數(shù)據(jù)屬于敏感資產(chǎn)建議定期備份備份文件加密存儲。9. 總結(jié)與下一步本文完整梳理了使用 NVIDIA Sync 連接兩臺 DGX Spark 的整個流程。從概念層面看NVIDIA Sync 不是單一命令而是物理連接、網(wǎng)絡(luò)配置、分布式運(yùn)行時和應(yīng)用框架四個層次的協(xié)同。從操作層面看固定 IP、SSH 免密、NCCL 驗(yàn)證、Ray 集群、vLLM 張量并行是五個關(guān)鍵步驟每一步都有對應(yīng)的驗(yàn)證方法和常見問題。如果你剛開始接觸雙機(jī)部署建議按照下面幾步繼續(xù)深入先用 7B 或 13B 規(guī)模的模型跑通全流程確認(rèn) NCCL 通信正常再切換到 70B 量化模型實(shí)測張量并行下的單并發(fā)吞吐最后再挑戰(zhàn) 200B 級別模型并結(jié)合多并發(fā)壓測觀察集群的吞吐上限。每一步都記錄實(shí)際數(shù)據(jù)和日志遇到問題及時對照官方文檔和社區(qū)資料。雙機(jī)部署最大的價值不是簡單地把算力翻倍而是讓你在本地環(huán)境中提前積累分布式推理的工程經(jīng)驗(yàn)。把 70B 模型跑通之后你已經(jīng)基本掌握了多機(jī)協(xié)同的核心鏈路后續(xù)擴(kuò)展到 4 臺、8 臺設(shè)備時本質(zhì)上只是在重復(fù)“組網(wǎng) → 驗(yàn)證 → 啟動服務(wù) → 監(jiān)控調(diào)優(yōu)”這套流程。如果本文對你有幫助可以收藏備用。后續(xù)我也會持續(xù)關(guān)注 DGX Spark 相關(guān)的性能調(diào)優(yōu)和部署實(shí)踐歡迎一起 雙DGX Spark互聯(lián)實(shí)戰(zhàn)：用NVIDIA Sync組網(wǎng)部署70B大模型
從 2025 年 NVIDIA GTC 發(fā)布以來DGX Spark 在本地大模型部署圈子里始終保持著很高的話題度。它把“桌面級設(shè)備跑百億甚至千億參數(shù)模型”這件事從概念變成了可落地的硬件方案。不過很多團(tuán)隊(duì)在實(shí)際使用時會遇到同一個問題單臺 DGX Spark 擁有 128GB 統(tǒng)一內(nèi)存看起來確實(shí)不小但當(dāng)你需要部署 200B 級別的模型或者業(yè)務(wù)要求同時處理多個并發(fā)推理請求時單機(jī)的內(nèi)存容量和總算力都會變得緊張。把兩臺 DGX Spark 通過 NVIDIA Sync 連接起來組成一個“兩臺設(shè)備協(xié)同工作的小集群”是解決這類需求的重要思路。本文將從核心概念、環(huán)境準(zhǔn)備、物理組網(wǎng)、軟件配置、推理框架部署到吞吐估算完整拆解整個連接與使用流程。無論你已經(jīng)在使用 DGX Spark還是正在調(diào)研本地私有化大模型部署方案這篇教程都可以作為參考。1. NVIDIA Sync 是什么DGX Spark 多機(jī)互聯(lián)的核心概念1.1 先理解 DGX Spark 的定位DGX Spark 不是傳統(tǒng)意義上的 PC 工作站。它基于 NVIDIA GB10 Grace Blackwell 超級芯片CPU 和 GPU 集成在一個封裝內(nèi)通過 NVLink-C2C 高速總線連接CPU 可以直接訪問 GPU 內(nèi)存。這種架構(gòu)帶來的直接好處是CPU 和 GPU 共享統(tǒng)一內(nèi)存池模型權(quán)重不需要在 CPU 內(nèi)存和顯存之間反復(fù)拷貝推理時的數(shù)據(jù)搬運(yùn)開銷大幅降低。內(nèi)存容量是 DGX Spark 最核心的指標(biāo)之一。128GB 統(tǒng)一內(nèi)存意味著即使不依賴外部服務(wù)器單臺設(shè)備也能加載相當(dāng)規(guī)模的量化模型。發(fā)布時 NVIDIA 官方的宣傳重點(diǎn)是“本地運(yùn)行 200B 參數(shù)模型”這一定位讓很多個人開發(fā)者和中小團(tuán)隊(duì)看到了私有化部署的可能性。與此同時DGX Spark 的價格也進(jìn)入了不少團(tuán)隊(duì)可以評估的區(qū)間具體售價請以官方渠道各時點(diǎn)信息為準(zhǔn)這也是它熱度持續(xù)走高的原因之一。但“可以運(yùn)行”和“運(yùn)行得好”是兩回事。200B 模型加載進(jìn)去之后單機(jī)還要同時承擔(dān) KV Cache、推理中間結(jié)果、服務(wù)框架自身的開銷。如果上下文長度拉長或者業(yè)務(wù)請求并發(fā)上來128GB 很快就會成為瓶頸。這時連接第二臺 DGX Spark用兩臺設(shè)備共同承擔(dān)推理任務(wù)就是最直接的擴(kuò)容方式。1.2 兩臺設(shè)備互聯(lián)的真實(shí)場景把兩臺 DGX Spark 連接在一起通常有四種典型場景。第一種是超大模型部署。當(dāng)模型權(quán)重加上運(yùn)行開銷超過了單臺設(shè)備的內(nèi)存容量又因?yàn)閿?shù)據(jù)安全原因不能放到云上雙機(jī)甚至多機(jī)協(xié)同就成了必經(jīng)之路。第二種是吞吐量優(yōu)化。單個 70B 級別的模型在單臺設(shè)備上推理時單并發(fā)輸出速度可能只有個位數(shù)到十幾 token/s。通過張量并行Tensor Parallelism把模型切分到兩臺設(shè)備上每臺設(shè)備只需要計算自己負(fù)責(zé)的那一部分理論上可以顯著提升單并發(fā)和低并發(fā)場景的吞吐。第三種是開發(fā)與生產(chǎn)環(huán)境隔離。你可以用一臺 DGX Spark 跑正式的推理服務(wù)另一臺做模型微調(diào)、評測和版本驗(yàn)證兩臺設(shè)備之間共享數(shù)據(jù)和調(diào)試通道。第四種是多模型并行。一臺設(shè)備跑對話模型另一臺設(shè)備跑向量化模型或 Reranker通過內(nèi)部網(wǎng)絡(luò)互相調(diào)用組成一套完整的 RAG 服務(wù)鏈路。無論哪種場景背后都需要一套可靠的多機(jī)通信機(jī)制。NVIDIA Sync 就是這套機(jī)制的入口。1.3 NVIDIA Sync 在連接中扮演什么角色嚴(yán)格來說NVIDIA Sync 不是“一個命令”或“一個工具”而是一整套面向 DGX Spark 多機(jī)協(xié)同的軟硬件方案。它的作用是讓兩臺 DGX Spark 從“網(wǎng)絡(luò)上互相能 ping 通”上升到“一個分布式推理系統(tǒng)”。這個升級過程包含三個層面。第一層是物理互連兩臺設(shè)備需要有高速網(wǎng)絡(luò)接口相連確保數(shù)據(jù)通路帶寬足夠。第二層是系統(tǒng)配置包括固定 IP、主機(jī)名解析、SSH 可信關(guān)系、防火墻放通等基礎(chǔ)工作。第三層是分布式運(yùn)行時也就是讓 PyTorch、NCCL、Ray 這些組件能夠感知到對方設(shè)備上的 GPU 算力和內(nèi)存資源并在框架層面完成多機(jī)調(diào)度。理解這一點(diǎn)很重要。很多初次接觸多機(jī)訓(xùn)練的開發(fā)者會以為“連接兩臺設(shè)備”只需要插一根線、設(shè)置一下 IP 就結(jié)束了但真正讓分布式推理跑起來還依賴軟件棧的完整配置。本文后續(xù)章節(jié)會按照這三個層面依次展開你可以把 NVIDIA Sync 理解成貫穿整個過程的方法論和官方能力集合而具體到操作就是每一層配置的逐步落實(shí)。2. 連接前的環(huán)境準(zhǔn)備與版本檢查2.1 硬件與場地準(zhǔn)備連接兩臺 DGX Spark 之前先確認(rèn)硬件條件。你需要準(zhǔn)備兩臺 DGX Spark并確保它們使用相同或兼容的電源規(guī)格和散熱環(huán)境。DGX Spark 的定位雖然是桌面設(shè)備但高負(fù)載推理時發(fā)熱和功耗仍然可觀不要把它塞進(jìn)密閉弱電箱或堆疊在一起使用設(shè)備之間至少要保持正常的通風(fēng)間距。網(wǎng)絡(luò)互連方面至少需要一條可靠的高速以太網(wǎng)線纜。如果條件允許建議通過支持萬兆或更高規(guī)格的交換機(jī)連接。直連線纜適合兩臺設(shè)備互連的簡單場景交換機(jī)組網(wǎng)則方便后續(xù)擴(kuò)展第三臺、第四臺設(shè)備。具體使用哪種線纜規(guī)格請以兩臺設(shè)備的實(shí)際網(wǎng)口類型和 NVIDIA 官方配件說明為準(zhǔn)不要隨意混用不兼容的線纜。連接思路是先規(guī)劃拓?fù)湓僭O(shè)置 IP最后驗(yàn)證鏈路。不要跳過規(guī)劃直接插線配置否則后續(xù)排查問題時線纜和 IP 的混亂會讓你浪費(fèi)大量時間。2.2 系統(tǒng)與軟件初始檢查DGX Spark 出廠搭載 NVIDIA 定制的 DGX OS底層是 Linux 系統(tǒng)。拿到設(shè)備后先通過顯示器和鍵鼠或者通過默認(rèn)管理網(wǎng)絡(luò) SSH 登錄系統(tǒng)做一輪基礎(chǔ)狀態(tài)檢查。# 查看系統(tǒng)發(fā)行版信息 cat /etc/os-release # 查看內(nèi)核版本 uname -a # 查看 GPU 是否被正確識別 nvidia-smi # 查看內(nèi)存與統(tǒng)一內(nèi)存信息 free -h如果nvidia-smi能正常輸出并且能看到 Grace Blackwell 芯片信息說明基礎(chǔ)驅(qū)動沒有問題。建議記錄下每臺設(shè)備的主機(jī)名、系統(tǒng)版本、驅(qū)動版本后續(xù)做多機(jī)互通時這些信息會幫助你快速判斷版本兼容性問題。2.3 軟硬件檢查清單檢查項(xiàng)說明驗(yàn)證方式系統(tǒng)版本兩臺設(shè)備應(yīng)保持同一大版本cat /etc/os-release驅(qū)動狀態(tài)GPU 能被正常識別nvidia-smi網(wǎng)絡(luò)接口確認(rèn)互聯(lián)接口名稱和速率ip link/ethtool主機(jī)名提前規(guī)劃避免重名hostnamectl防火墻放通集群通信端口sudo ufw statusSSH 服務(wù)開啟并允許密鑰登錄systemctl status ssh注意如果你的設(shè)備是剛拆箱的建議先按照 NVIDIA 官方文檔完成系統(tǒng)初始化和驅(qū)動更新再進(jìn)行雙機(jī)連接操作。版本需要根據(jù)你的實(shí)際設(shè)備情況調(diào)整本文示例以常見 Linux 環(huán)境為例重點(diǎn)演示配置思路。3. 物理連接與網(wǎng)絡(luò)組網(wǎng)3.1 選擇連接拓?fù)鋬膳_ DGX Spark 最簡單的連接方式是直連用一根高速網(wǎng)線把兩臺設(shè)備的互聯(lián)網(wǎng)口直接連起來。這種方式延遲低、沒有交換機(jī)轉(zhuǎn)發(fā)開銷適合兩臺設(shè)備固定的場景。如果后續(xù)還要擴(kuò)展更多設(shè)備則建議使用交換機(jī)。通過交換機(jī)連接時所有設(shè)備處于同一個二層網(wǎng)絡(luò)中IP 規(guī)劃更靈活排查問題也更方便。無論采用哪種拓?fù)涠冀ㄗh為集群規(guī)劃專用的靜態(tài) IP 網(wǎng)段例如設(shè)備主機(jī)名IP 地址設(shè)備 Adgx-a192.168.100.10設(shè)備 Bdgx-b192.168.100.11使用獨(dú)立網(wǎng)段避免和辦公網(wǎng)絡(luò)沖突是雙機(jī)組網(wǎng)的基本功。固定 IP 不僅方便記憶更重要的是后續(xù) NCCL、Ray 等分布式組件需要穩(wěn)定的地址發(fā)現(xiàn)機(jī)制。3.2 配置網(wǎng)絡(luò)接口連接好線纜后需要確認(rèn)系統(tǒng)是否識別到了新的網(wǎng)絡(luò)接口。使用ip addr查看所有網(wǎng)絡(luò)接口找到與互聯(lián)線纜對應(yīng)的那個接口名。不同系統(tǒng)下接口名可能不同常見形式包括enp1s0f0np0、eth0等。接下來為接口配置靜態(tài) IP。以設(shè)備 A 為例# 查看接口狀態(tài) ip addr show # 使用 nmcli 配置靜態(tài) IP需要根據(jù)實(shí)際接口名和連接名調(diào)整 sudo nmcli con mod Wired Connection \ ipv4.addresses 192.168.100.10/24 \ ipv4.gateway \ ipv4.method manual # 啟用連接 sudo nmcli con up Wired Connection # 再次確認(rèn) IP 是否生效 ip addr show設(shè)備 B 同樣操作設(shè)置192.168.100.11/24。這里要特別注意如果系統(tǒng)里存在多個網(wǎng)卡務(wù)必確認(rèn)你修改的是互聯(lián)接口而不是管理網(wǎng)絡(luò)接口否則可能把設(shè)備“配斷網(wǎng)”。3.3 連通性驗(yàn)證與 SSH 配置IP 配置完成后先驗(yàn)證鏈路是否通暢。# 從設(shè)備 A ping 設(shè)備 B ping 192.168.100.11 # 查看網(wǎng)卡速率與協(xié)商狀態(tài) ethtool 接口名ping通了只代表二層和三層網(wǎng)絡(luò)正常還不能說明帶寬和穩(wěn)定性。建議進(jìn)一步用iperf3做一次簡單的帶寬壓測# 設(shè)備 B 先啟動服務(wù)端 iperf3 -s # 設(shè)備 A 以客戶端模式測試 30 秒 iperf3 -c 192.168.100.11 -t 30通過測試數(shù)據(jù)可以確認(rèn)實(shí)際傳輸帶寬是否接近網(wǎng)卡協(xié)商速率。如果帶寬明顯偏低檢查線纜是否插到了正確的接口、是否啟用了巨型幀Jumbo Frame、是否有網(wǎng)卡降速現(xiàn)象。網(wǎng)絡(luò)通暢后配置 SSH 免密登錄。這一步非常關(guān)鍵因?yàn)楹罄m(xù)分布式組件在多機(jī)之間拉起進(jìn)程時通常依賴 SSH 免密能力。# 在設(shè)備 A 上生成密鑰如果還沒有 ssh-keygen -t ed25519 # 將公鑰復(fù)制到設(shè)備 B ssh-copy-id dgx-b192.168.100.11 # 驗(yàn)證免密登錄 ssh dgx-b192.168.100.11 hostname同樣操作將設(shè)備 B 的公鑰復(fù)制到設(shè)備 A實(shí)現(xiàn)雙向免密。4. 軟件配置與多機(jī)協(xié)同驗(yàn)證4.1 更新系統(tǒng)與基礎(chǔ)組件網(wǎng)絡(luò)層就緒后進(jìn)入軟件配置階段。首先確保兩臺設(shè)備的系統(tǒng)組件、驅(qū)動和 CUDA 工具鏈處于相近版本。# 更新系統(tǒng)軟件源和軟件包 sudo apt update sudo apt upgrade -y # 查看驅(qū)動與 CUDA 版本 nvidia-smi nvcc --version如果兩臺設(shè)備的驅(qū)動或 CUDA 版本差異較大分布式框架在初始化 NCCL 時可能報錯。最好的做法是讓兩臺設(shè)備保持相同版本避免“能 ping 通但框架通信失敗”的尷尬情況。4.2 配置主機(jī)名解析分布式框架在多機(jī)通信時經(jīng)常需要通過主機(jī)名解析 IP 地址。建議在兩臺設(shè)備的/etc/hosts中同時寫入對方的信息避免依賴 DNS 服務(wù)。# 文件路徑/etc/hosts 192.168.100.10 dgx-a 192.168.100.11 dgx-b修改完成后分別在兩臺設(shè)備上執(zhí)行ping dgx-a和ping dgx-b驗(yàn)證主機(jī)名解析是否生效。4.3 使用 NVIDIA Sync 建立多機(jī)協(xié)同會話NVIDIA Sync 的正式啟用通常會借助 NVIDIA 提供的管理工具或控制臺完成設(shè)備注冊與發(fā)現(xiàn)。具體入口和界面會隨軟件版本迭代而變化建議以官方文檔和工具界面為準(zhǔn)。這里要理解的核心鏈路是設(shè)備發(fā)現(xiàn) → 網(wǎng)絡(luò)檢測 → 會話建立 → 資源分配到分布式運(yùn)行時。如果暫時沒有系統(tǒng)管理工具也可以通過完全手動的分布式配置達(dá)到同樣的多機(jī)協(xié)同效果。本質(zhì)上我們需要的是一套能讓兩臺設(shè)備上的 GPU 互相感知的運(yùn)行時環(huán)境。這一步可以通過 NCCL 測試來完成驗(yàn)證。4.4 用 NCCL 測試驗(yàn)證雙機(jī)通信NCCLNVIDIA Collective Communications Library是 NVIDIA 提供的多 GPU 和多節(jié)點(diǎn)通信庫PyTorch 分布式訓(xùn)練和 vLLM 多卡推理底層都依賴它。下面用一段最簡單的 PyTorch 程序驗(yàn)證兩臺 DGX Spark 能否通過 NCCL 正常通信。# 文件路徑任意目錄/test_allreduce.py import torch import torch.distributed as dist def main(): # 初始化分布式進(jìn)程組使用 NCCL 后端 dist.init_process_group(backendnccl) rank dist.get_rank() local_rank dist.get_local_rank() # 當(dāng)前進(jìn)程綁定到本機(jī)對應(yīng)的 GPU torch.cuda.set_device(local_rank) # 每個進(jìn)程創(chuàng)建一個初始值等于 rank 的 tensor tensor torch.ones(1, devicecuda) * rank # 所有進(jìn)程執(zhí)行 all_reduce 求和 dist.all_reduce(tensor, opdist.ReduceOp.SUM) if rank 0: print(frank{rank}, all_reduce result{tensor.item()}) else: print(frank{rank}, all_reduce result{tensor.item()}) if __name__ __main__: main()在設(shè)備 A 上啟動torchrun --nnodes2 --nproc-per-node1 --node-rank0 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py在設(shè)備 B 上啟動torchrun --nnodes2 --nproc-per-node1 --node-rank1 \ --master-addr192.168.100.10 --master-port29500 \ test_allreduce.py正常情況下兩臺終端窗口都會輸出all_reduce result1.0。因?yàn)?rank 0 的初始值是 0rank 1 的初始值是 1求和結(jié)果為 1。如果能看到這個結(jié)果說明 NCCL 可以正?？绻?jié)點(diǎn)通信分布式運(yùn)行時已經(jīng)打通。小提示這里的nproc-per-node1表示每個節(jié)點(diǎn)啟動 1 個進(jìn)程。如果單臺設(shè)備上實(shí)際只有一個 GPU 實(shí)例寫 1 即可如果設(shè)備被系統(tǒng)識別為多個計算實(shí)例可以按實(shí)際數(shù)量調(diào)整。5. 雙機(jī)部署 70B/200B 模型的實(shí)戰(zhàn)案例5.1 實(shí)戰(zhàn)目標(biāo)打通雙機(jī)通信后就可以進(jìn)入真正的推理部署階段。本文的實(shí)戰(zhàn)目標(biāo)有兩個用兩臺 DGX Spark 部署一個 70B 級別的量化模型開啟張量并行Tensor Parallelism驗(yàn)證雙機(jī)推理效果。討論 200B 級別模型在雙機(jī) 256GB 統(tǒng)一內(nèi)存下的部署可能性與注意事項(xiàng)。說明以下示例以 vLLM 為主要推理框架因?yàn)樗鼘Χ鄼C(jī)多卡支持較成熟并且提供 OpenAI 兼容的 API 服務(wù)。實(shí)際使用時可以根據(jù)模型格式和版本選擇 SGLang、TGI 等框架思路是相通的。5.2 建立 Ray 集群vLLM 多機(jī)推理通常通過 Ray 集群協(xié)調(diào)跨節(jié)點(diǎn)資源。先在一臺設(shè)備上啟動 Ray head 節(jié)點(diǎn)然后在另一臺設(shè)備上加入集群。# 在設(shè)備 A主節(jié)點(diǎn)啟動 Ray head ray start --head --port6379看到 Ray 啟動成功的日志后在設(shè)備 B 上執(zhí)行加入命令# 在設(shè)備 B 加入設(shè)備 A 管理的集群 ray start --address192.168.100.10:6379使用ray status可以確認(rèn)兩臺設(shè)備是否都已加入集群。如果能看到兩個節(jié)點(diǎn)并且每個節(jié)點(diǎn)都貢獻(xiàn)了 GPU 資源說明 Ray 集群就緒。Linux 命令補(bǔ)充# 查看 Ray 集群狀態(tài) ray status5.3 用 vLLM 啟動雙機(jī)張量并行推理假設(shè) 70B 模型權(quán)重已經(jīng)存放在每臺設(shè)備的本地磁盤路徑/data/models/qwen-70b-awq下實(shí)際路徑請?zhí)鎿Q為你自己的模型目錄在設(shè)備 A 上啟動 vLLM 服務(wù)vllm serve /data/models/qwen-70b-awq \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --api-key local-test關(guān)鍵參數(shù)含義--tensor-parallel-size 2張量并行度為 2讓模型權(quán)重切分到兩臺設(shè)備上。如果 Ray 集群中有兩個節(jié)點(diǎn)vLLM 會自動跨節(jié)點(diǎn)調(diào)度。--max-model-len 8192限制最大上下文長度避免 KV Cache 占用過多內(nèi)存。--api-key local-test為 API 設(shè)置訪問密鑰僅用于本地測試環(huán)境。如果你的 vLLM 版本較老不支持vllm serve子命令可以使用python -m vllm.entrypoints.openai.api_server啟動參數(shù)完全一致。不同版本的 vLLM 在多機(jī)調(diào)度的細(xì)節(jié)上有差異較新版本會自動識別 Ray 集群老版本可能需要額外指定--distributed-executor-backend ray。遇到問題先看啟動日志根據(jù)日志提示調(diào)整即可。5.4 發(fā)送推理請求驗(yàn)證服務(wù)啟動后通過 curl 發(fā)送一個聊天補(bǔ)全請求curl http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 介紹一下 DGX Spark 的主要特點(diǎn)}], max_tokens: 256 }如果一切正常你會收到包含生成文本的 JSON 響應(yīng)。此時打開nvidia-smi觀察兩臺設(shè)備的 GPU 利用率應(yīng)該能看到兩臺設(shè)備都在參與計算。對于 200B 模型雙機(jī)部署的思路完全一樣但需要注意兩點(diǎn)第一200B 模型的量化版本通常在 100GB 到 120GB 之間雙機(jī) 256GB 統(tǒng)一內(nèi)存可以比較從容地加載還能剩余一部分空間給 KV Cache第二當(dāng)模型權(quán)重超過單機(jī)內(nèi)存容量時--tensor-parallel-size 2幾乎是必須的配置盡量避免單機(jī)強(qiáng)行加載導(dǎo)致內(nèi)存溢出。6. 聚焦兩臺 DGX Spark 張量并行 70B 模型的單并發(fā)吞吐估算6.1 為什么單并發(fā)吞吐主要受內(nèi)存帶寬限制很多人在雙機(jī)部署 70B 模型后最關(guān)心的就是單并發(fā)輸出速度到底每秒能生成多少 token回答這個問題之前先要理解大模型推理的性能瓶頸。在 decode 階段也就是逐 token 生成階段模型需要把全部權(quán)重從內(nèi)存中讀取一遍參與每一輪計算。相比計算量權(quán)重讀取對內(nèi)存帶寬的需求更為突出。換句話說單并發(fā)推理的極限速度很大程度上取決于“在多長時間內(nèi)把模型權(quán)重完整讀一遍”。6.2 理論估算方法假設(shè)一個 70B 模型以 4bit 量化保存權(quán)重總量大約為 35GB。如果單臺 DGX Spark 的統(tǒng)一內(nèi)存帶寬在 250GB/s 量級具體數(shù)值請以官方規(guī)格表為準(zhǔn)那么單機(jī)每生成一個 token理論最低耗時約為35GB / 250GB/s ≈ 0.14 秒換算成吞吐就是大約 7 token/s 的上限。這只是一個純讀取權(quán)重的理論值實(shí)際還會疊加計算開銷、KV Cache 訪問、框架調(diào)度等所以真實(shí)值通常低于這個數(shù)字。6.3 雙機(jī)張量并行的理論收益使用張量并行、把模型切分到兩臺設(shè)備時每臺設(shè)備只需要讀取自己負(fù)責(zé)的那一半權(quán)重。每臺設(shè)備讀取量35GB / 2 17.5GB 理想讀取耗時17.5GB / 250GB/s ≈ 0.07 秒如果不考慮通信開銷雙機(jī)單并發(fā)吞吐可以達(dá)到約 14 token/s。但這個理想值無法完全實(shí)現(xiàn)因?yàn)槊看吻跋蛴嬎愣夹枰ㄟ^集群網(wǎng)絡(luò)同步中間結(jié)果。假設(shè)每一次通信需要 20 到 40 毫秒那么實(shí)際耗時就在 0.09 到 0.11 秒之間對應(yīng)的吞吐大約在 9 到 11 token/s。所以雙機(jī)張量并行對單并發(fā)吞吐的提升通常不是嚴(yán)格的 2 倍而是接近 1.3 到 1.8 倍具體取決于互聯(lián)帶寬、模型量化精度和框架實(shí)現(xiàn)。6.4 如何實(shí)測真實(shí)吞吐理論估算只能幫你做容量規(guī)劃真實(shí)環(huán)境必須依賴實(shí)測。vLLM 啟動后直接向 API 發(fā)送多次請求統(tǒng)計生成 token 總數(shù)和總耗時即可。# 使用 curl 請求 10 次統(tǒng)計總耗時然后計算平均 token/s time for i in $(seq 1 10); do curl -s http://192.168.100.10:8000/v1/chat/completions \ -H Authorization: Bearer local-test \ -H Content-Type: application/json \ -d { model: /data/models/qwen-70b-awq, messages: [{role: user, content: 寫一段關(guān)于人工智能發(fā)展的短文}], max_tokens: 512 } | jq -r .usage.completion_tokens done通過多次請求取平均值可以得到相對穩(wěn)定的單并發(fā)吞吐數(shù)據(jù)。測試時要注意預(yù)熱前幾次請求可能包含權(quán)重加載、CUDA kernel 初始化等額外耗時正式統(tǒng)計時先發(fā)幾個請求預(yù)熱再開始計時結(jié)果更有參考價值?？偟膩碚f如果你在網(wǎng)上看到有人提到“兩臺 DGX Spark 張量并行跑 70B 模型單并發(fā)輸出大約在 8 到 15 token/s”這個量級是符合內(nèi)存帶寬模型的。實(shí)際數(shù)字會因?yàn)榱炕粚?、上下文長度、模型架構(gòu)、框架版本和網(wǎng)絡(luò)質(zhì)量的不同而變化不必糾結(jié)于某個具體數(shù)字。7. 常見問題與排查思路7.1 高頻問題與處理對照表雙機(jī)互聯(lián)和分布式推理涉及網(wǎng)絡(luò)、系統(tǒng)驅(qū)動、運(yùn)行時、框架四個層面任何一層出現(xiàn)問題都可能導(dǎo)致集群不可用。下面以表格形式梳理高頻問題方便快速定位。問題現(xiàn)象常見原因排查與解決思路兩臺設(shè)備互相 ping 不通線纜未插好、接口選錯、IP 沖突檢查線纜與接口確認(rèn) IP 是否在同一網(wǎng)段關(guān)閉無關(guān)網(wǎng)卡SSH 連接失敗sshd 未啟動、防火墻攔截、密鑰權(quán)限錯誤檢查 sshd 服務(wù)狀態(tài)放通 22 端口修復(fù)密鑰目錄權(quán)限NCCL 初始化超時/etc/hosts 未配置、防火墻攔截通信端口、master 地址不可達(dá)補(bǔ)齊 hosts放通分布式通信端口用NCCL_DEBUGINFO查看日志分布式測試耗時異常高實(shí)際走了以太網(wǎng)回環(huán)或降速鏈路用ethtool檢查網(wǎng)卡速率用iperf3驗(yàn)證帶寬vLLM 啟動時找不到足夠的 GPURay 集群未正確加入或--tensor-parallel-size大于實(shí)際可用 GPUray status確認(rèn)節(jié)點(diǎn)數(shù)檢查CUDA_VISIBLE_DEVICES環(huán)境變量推理時顯存/內(nèi)存不足模型權(quán)重太大、KV Cache 過大、并發(fā)請求過多降低--max-model-len減少并發(fā)數(shù)換更低量化位寬雙機(jī)推理反而比單機(jī)慢通信開銷過大、網(wǎng)絡(luò)帶寬不足、量化后 GPU 計算占比變高檢查網(wǎng)絡(luò)帶寬考慮使用流水線并行替代張量并行或減少并行度7.2 NCCL 調(diào)試日志的使用方法當(dāng) NCCL 通信出現(xiàn)異常時最有效的排查方式就是打開調(diào)試日志。# 在啟動 torchrun 或 vllm 前設(shè)置環(huán)境變量 export NCCL_DEBUGINFO # 如果需要更多細(xì)節(jié)可以設(shè)置為 TRACE # export NCCL_DEBUGTRACE日志中會顯示 NCCL 選擇了哪個網(wǎng)絡(luò)接口、連接了哪個 IP、在哪一步超時?？吹筋愃芅ET/IB的日志表示 NCCL 嘗試使用 InfiniBand 或 RoCE 設(shè)備看到NET/Socket則說明當(dāng)前使用的是傳統(tǒng) TCP Socket。生產(chǎn)環(huán)境排錯時先明確這條信息能幫你快速判斷問題出在物理鏈路還是協(xié)議配置上。7.3 防火墻與端口放通建議分布式訓(xùn)練與推理需要放通多類端口。這里整理一份常見端口清單具體端口號可能因框架版本不同而變化請以實(shí)際配置為準(zhǔn)。服務(wù)默認(rèn)端口說明SSH22遠(yuǎn)程登錄Ray Head6379集群協(xié)調(diào)vLLM API8000OpenAI 兼容接口torchrun 主節(jié)點(diǎn)29500PyTorch 分布式協(xié)調(diào)NCCL 動態(tài)端口隨機(jī)高端口建議先NCCL_DEBUGINFO看實(shí)際端口在兩臺設(shè)備互相通信時優(yōu)先保證這些端口在集群內(nèi)部網(wǎng)段可以訪問。如果公司網(wǎng)絡(luò)存在安全組或防火墻務(wù)必在測試環(huán)境中先驗(yàn)證規(guī)則再上生產(chǎn)。8. 最佳實(shí)踐與工程建議8.1 網(wǎng)絡(luò)與拓?fù)鋵用娴慕ㄗh雙機(jī)互聯(lián)的穩(wěn)定性直接決定分布式推理的上限。建議把集群組網(wǎng)獨(dú)立到專用網(wǎng)段不要與辦公網(wǎng)絡(luò)共用廣播域。固定 IP 之后務(wù)必寫入/etc/hosts避免依賴 DHCP 分配產(chǎn)生地址漂移。如果業(yè)務(wù)對延遲敏感優(yōu)先考慮直連拓?fù)錅p少交換機(jī)轉(zhuǎn)發(fā)跳數(shù)。如果使用交換機(jī)確保交換機(jī)端口速率與網(wǎng)卡匹配不要出現(xiàn)千兆網(wǎng)口接萬兆網(wǎng)卡導(dǎo)致降速的問題。有條件的話建議開啟對稱巨型幀支持Jumbo Frame但需要同時確認(rèn)交換機(jī)、網(wǎng)卡和驅(qū)動都支持并保持兩端 MTU 一致否則反而會引發(fā)分片問題。8.2 模型與數(shù)據(jù)管理建議多機(jī)推理時模型權(quán)重建議直接放在每臺設(shè)備的本地 NVMe 存儲中。雖然通過 NFS 共享權(quán)重看起來很省事但訓(xùn)練或推理啟動時會并發(fā)讀取大量文件NFS 很容易成為瓶頸。如果必須使用共享存儲可以考慮只在啟動階段復(fù)制權(quán)重到本地推理過程中不要依賴共享存儲。另外建議建立規(guī)范的模型目錄結(jié)構(gòu)。例如統(tǒng)一使用/data/models/模型名-量化精度的形式并在啟動腳本中通過環(huán)境變量傳入模型路徑避免在多臺設(shè)備上路徑不一致導(dǎo)致服務(wù)啟動失敗。# 推薦在啟動腳本中顯式定義環(huán)境變量 export MODEL_PATH/data/models/qwen-70b-awq export TENSOR_PARALLEL_SIZE2 export API_KEYlocal-test統(tǒng)一變量管理減少手動改命令導(dǎo)致的低級錯誤。8.3 監(jiān)控與日志管理雙機(jī)集群的運(yùn)維復(fù)雜度高于單機(jī)。建議至少配置以下監(jiān)控項(xiàng)GPU 利用率與溫度nvidia-smi dmon統(tǒng)一內(nèi)存使用率nvidia-smi中的 Memory-Usage網(wǎng)絡(luò)吞吐iperf3或nload推理服務(wù)日志vLLM 的訪問日志與錯誤日志可以使用 systemd 管理推理服務(wù)保證服務(wù)異常退出時能自動重啟。日志輸出到文件后配合logrotate做輪轉(zhuǎn)避免日志文件無限增長占滿磁盤。8.4 安全與運(yùn)維邊界涉及生產(chǎn)環(huán)境的多機(jī)集群變更務(wù)必遵循最低權(quán)限原則。日常維護(hù)使用普通用戶只有安裝軟件和修改系統(tǒng)配置時才使用 sudo。SSH 登錄建議全部改為密鑰認(rèn)證并禁止密碼登錄。推理服務(wù)不要直接暴露到公網(wǎng)。如果業(yè)務(wù)需要遠(yuǎn)程訪問通過企業(yè)內(nèi)部網(wǎng)絡(luò)或安全網(wǎng)關(guān)轉(zhuǎn)發(fā)并在網(wǎng)關(guān)層做訪問控制和審計。模型權(quán)重和訓(xùn)練數(shù)據(jù)屬于敏感資產(chǎn)建議定期備份備份文件加密存儲。9. 總結(jié)與下一步本文完整梳理了使用 NVIDIA Sync 連接兩臺 DGX Spark 的整個流程。從概念層面看NVIDIA Sync 不是單一命令而是物理連接、網(wǎng)絡(luò)配置、分布式運(yùn)行時和應(yīng)用框架四個層次的協(xié)同。從操作層面看固定 IP、SSH 免密、NCCL 驗(yàn)證、Ray 集群、vLLM 張量并行是五個關(guān)鍵步驟每一步都有對應(yīng)的驗(yàn)證方法和常見問題。如果你剛開始接觸雙機(jī)部署建議按照下面幾步繼續(xù)深入先用 7B 或 13B 規(guī)模的模型跑通全流程確認(rèn) NCCL 通信正常再切換到 70B 量化模型實(shí)測張量并行下的單并發(fā)吞吐最后再挑戰(zhàn) 200B 級別模型并結(jié)合多并發(fā)壓測觀察集群的吞吐上限。每一步都記錄實(shí)際數(shù)據(jù)和日志遇到問題及時對照官方文檔和社區(qū)資料。雙機(jī)部署最大的價值不是簡單地把算力翻倍而是讓你在本地環(huán)境中提前積累分布式推理的工程經(jīng)驗(yàn)。把 70B 模型跑通之后你已經(jīng)基本掌握了多機(jī)協(xié)同的核心鏈路后續(xù)擴(kuò)展到 4 臺、8 臺設(shè)備時本質(zhì)上只是在重復(fù)“組網(wǎng) → 驗(yàn)證 → 啟動服務(wù) → 監(jiān)控調(diào)優(yōu)”這套流程。如果本文對你有幫助可以收藏備用。后續(xù)我也會持續(xù)關(guān)注 DGX Spark 相關(guān)的性能調(diào)優(yōu)和部署實(shí)踐歡迎一起