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