如果你只是分别跑两个模型两台 DGX Spark 确实不需要连接。但只要你的目标是“把两台机器拉成一个池子一起加载同一个大模型”NVIDIA Sync 就会变成绕不开的话题。简单说这是 NVIDIA 面向 DGX Spark 这类本地计算设备设计的多机聚合方案核心目的是让两台甚至多台机器通过高速互连共享计算资源和统一内存从而在本地运行单机跑不动的模型或者提高单个请求的推理吞吐。它在实际场景里最常被提到的用法就是本地部署 200B 量级大模型或者把 70B 模型拆到两台机器上做张量并行推理。这篇文章想把一个问题讲透NVIDIA Sync 连接两台 DGX Spark到底怎么连、连之前要确认什么、连完之后跑 70B 或 200B 模型时有哪些参数值得看以及怎么判断连接是真的成功。我不会只罗列操作步骤我更想说明每个步骤背后的原因。双机推理不像插一根网线那么简单很多失败都出在网络、软件版本、模型路径和并行参数这些前置条件上。1. 先搞清楚两台 DGX Spark 连起来到底解决什么问题1.1 单台 DGX Spark 的边界在哪DGX Spark 是 NVIDIA 在本地 AI 设备上的一款产品核心卖点是把桌面级设备做成一台能跑大模型的机器。常见配置带有 128GB 统一内存CPU、GPU 和内存之间的数据交换不需要把数据频繁拷回主板这对本地部署大模型来说是非常大的优势。官方宣传里也强调过本地部署 200B 量级参数模型的能力。但这里的“能跑”需要拆开理解。200B 模型通常不是指任意权重、任意精度、任意上下文长度都能直接塞进单机。它更多是说要通过量化、低精度推理、特定推理框架配置之后的运行能力。如果你把一个没有量化的 200B 模型用 BF16 精度直接加载单就权重就可能接近 400GB单台机器无论如何装不下。所以官方宣传里的“本地部署 200B”默认条件是模型经过压缩、量化或者使用了支持高效加载和分页管理的推理引擎。当你用单台 DGX Spark 跑 70B 模型时情况会更现实。70B 模型用不同精度加载权重体积差别很大。BF16 下权重约 140GB单机放不下INT8 下约 70GB勉强能放INT4 下约 35GB相对宽裕。这也是很多人在单机上跑 70B 模型时优先选择 4bit 或 8bit 量化模型的原因。KV Cache 和激活还会占用额外内存所以就算权重能放进去长上下文、高并发、长输出仍然可能让单机直接 OOM。这说明一个关键边界单机容量不是无上限能加载模型和能把模型跑得舒服是两回事。当你开始考虑把两台 DGX Spark 连接起来时通常已经遇到了两类问题中的至少一类。第一类是模型权重超过单机可用内存第二类是即使权重能放进去单请求的生成速度也不够快。前者靠内存扩容解决后者靠并行计算解决。1.2 双机并联带来的三个变化两台机器并联后表面上只是多了 128GB 内存实际上带来三个不同方向的提升。第一个变化是聚合内存。两台机器的统一内存加起来约 256GB这让原本需要压缩到 INT4 才能跑的模型有机会用 INT8 甚至更高精度运行。精度越高输出质量通常越稳定重复性也更好。这对做模型评测、技术验证、内部工具的场景很有价值。第二个变化是单请求吞吐。通过张量并行一个模型可以被切到两张卡上同时计算矩阵乘法被拆分到不同设备理论上每个 token 的生成时间可以缩短。但这有一个前提跨节点通信成本必须足够低否则通信等待会吃掉并行收益。第三个变化是并发请求能力。如果模型能在两台机器上复制出一份完整副本就可以用数据并行方式同时服务多个请求。不过这不会减少单请求所需的内存每个副本仍然占用完整的模型权重。所以并发提升和降低显存占用是两个不同方向不能混在一起看。这三个变化不是自动同时发生的。你需要在推理框架里显式选择并行方式并设置并行度。否则两台机器即使物理连好也可能只是两台各自运行的独立机器。1.3 NVIDIA Sync 在其中的位置NVIDIA Sync 在官方语境里更接近一种面向多机协同的互连机制而不是简单的文件同步或备份工具。它要解决的问题是让多台 DGX Spark 之间的通信延迟足够低、带宽足够稳定这样上层框架才能像使用单机多卡一样使用多台机器。可以把它理解成类似于 NVLink 在单机多卡里的作用。NVLink 让单机内的 GPU 能以极高带宽交换数据NVIDIA Sync 则是把这种“多设备协同”思路扩展到多机场景。但跨机之后物理链路会依赖具体的网卡、线缆和交换机通信协议也可能涉及 RDMA 或高速以太网。所以它的实际表现不只取决于软件还取决于你排的线、装的驱动、配的网络参数和选用的交换机。这一点直接决定了后面所有步骤。如果你只想在两台机器之间共享文件NVIDIA Sync 并不是必须的如果你想跑张量并行让两个设备在每一层计算时频繁交换数据那它的通信质量就是决定能不能跑、跑多快的核心因素。2. 动手前先确认硬件、软件和网络的边界条件2.1 硬件链路需要什么最小硬件组合是两台 DGX Spark、一根符合机器高速互连端口的线缆、可选的交换机以及足够稳定的电源。如果你的机器有网卡还需要确保网卡驱动正确安装如果网卡是外接卡还要检查 PCIe 插槽是否插紧、供电是否正常。这里有一个常见误区以为两台机器用普通网线直连就等于组建了集群。普通网线直连只能满足最基本的 TCP 通信做分布式训练和推理时带宽和延迟都会成为瓶颈。单机多卡之间是 PCIe 和 NVLink 这类高速通道跨机器之后至少也要有明确支持 RDMA 或类似高速协议的网络接口否则模型每算一层都要等通信速度会非常难看。如果你打算以后再扩展到三台、四台机器那就需要考虑交换机。两台机器直连时拓扑简单但加入第三台后主机命名、子网划分、交换机端口配置都会变得复杂。现在先按双机验证没问题但规划时给未来留出扩展空间可以少走很多弯路。2.2 驱动、CUDA 和容器版本必须对齐我在实际配置多机环境时遇到最多的报错不是模型文件损坏而是两台机器的软件版本不一致。分布式任务启动时各节点会检查驱动、CUDA、运行时库和框架版本。版本差异会导致节点间握手失败、算出的结果不一致甚至某些节点直接启动不了。所以开始前先做四件事两台机器安装相同版本的系统镜像或驱动。检查 CUDA Toolkit 版本并保持对齐。确认 NVIDIA Container Toolkit 已经正常安装或者在宿主机环境下把依赖装好。如果使用容器两台机器使用同一个镜像 tag不要一台用最新的另一台用旧版本。检查版本时最常用的是nvidia-smi看驱动和 GPU 信息用nvcc --version看 CUDA 版本。如果使用了高速网卡还需要用网卡自带的管理工具查看固件版本。固件版本不一致的问题容易被忽略但一旦出问题报错信息往往非常难懂。版本对齐不是能做一次就结束的事情。系统升级、驱动更新、镜像重拉都会让版本重新漂移。建议把两台机器的软件配置记录成文档每次改动后都重新检查一遍。2.3 网络规划带宽、延迟、MTU 和主机名跨节点并行对网络的敏感度比很多人想象中高。推理时每次前向传播都可能产生多次跨节点通信虽然不像训练那样频繁通信梯度但张量并行场景下每一层 Transformer 结构都需要把中间激活同步给另一台设备。这意味着延迟哪怕只多几毫秒累计起来也会明显拖慢生成速度。配置网络前先把这几个项目检查完检查项建议操作判断标准主机互通配置/etc/hosts加入两台机器的主机名和 IP能互相 ping 通SSH 免密生成密钥并复制到对端两台机器能直接ssh node02登录防火墙放行分布式框架使用的端口端口没有被阻断MTU确认两台机器网卡 MTU 设置一致不一致时传输性能会下降时间同步使用 chrony 或 NTP 同步时间多节点任务对时间偏移敏感存储模型权重放到共享目录或在两台机器上保存完全相同的副本路径一致、权限一致很多人会把精力放在模型参数上却忽略主机名和 SSH。分布式框架启动时会根据--rdzv_endpoint或类似参数连接主节点如果对端主机名解析不到任务就会一直卡在等待状态。先确认网络能通、能免密登录再启动并发任务能省下大量排错时间。3. 实际联机流程从物理连接到软件识别3.1 物理连接步骤物理连接听起来简单但顺序错了会浪费很多时间。我的建议是两台机器都关机并断开电源。把互连线缆插到对应的高速网口或者安装外接网卡。如果使用交换机把两台机器分别接入交换机端口。确认线缆没有松动再给两台机器上电。上电后不要急着启动大模型先做设备识别。打开终端查看系统是否发现了新的网络接口或网卡设备。可以用ip link show查看网络接口状态用lspci | grep -i nvidia看 NVIDIA 相关设备。如果接线正确系统应该能看到网口进入 link up 状态。如果 link down先换线缆、换端口不要直接怀疑软件配置。这个阶段最容易忽略的是电源和散热。DGX Spark 虽然比机房服务器小很多但持续跑大模型时功耗和发热仍然不低。两台机器放在同一张桌子上要注意通风、电源插座的负载能力以及长时间运行时的噪音。对桌面环境来说这可能是比软件配置更现实的问题。3.2 网络设备识别与固件检查如果使用的是高速网卡系统识别到设备后还需要确认驱动和固件状态。常见网卡管理工具中ibstatus或ibstat用于查看 InfiniBand 设备状态RoCE 网卡则通常在以太网模式下工作。因为不同型号、不同代际的网卡差异很大这里只给一个验证思路找到该网卡对应的状态查询命令确认端口是否 active、速率是否达到预期、有没有错误计数。如果链路状态正常但速率远低于预期大概率是网线或交换机端口的问题。如果网卡根本无法识别优先检查驱动和固件其次看 PCIe 插槽。先不要急着检查推理框架。3.3 分布式启动前的通信验证很多人在物理连接之后直接运行 70B 模型这是最容易出问题的方式。先做更基础的通信验证确保两台机器真的能互通。验证顺序可以这样安排# 检查基础网络连通性 ping -c 4 node02 # 检查 SSH 免密 ssh node02 nvidia-smi # 检查高速网络接口状态 ibstatus如果 ping 不通先检查 IP 配置、交换机和线缆。如果 ping 通但 SSH 失败检查 SSH 服务和密钥。如果 ping 通、SSH 也没问题但高速网卡状态异常则检查 RDMA 或 RoCE 相关驱动。基础网络验证通过后再跑一轮更接近真实场景的分布式通信测试。NCCL 是 NVIDIA 提供的多 GPU 通信库很多训练和推理框架底层都用它。NCCL 测试工具可以测量多节点 all-reduce 等操作的带宽和延迟。类似这样的测试方式# 示例命令实际参数要以你安装的 NCCL 测试工具版本为准 mpirun --host node01,node02 -np 2 all_reduce_perf -b 8M -e 1G如果两边机器都能参与测试并且带宽在合理范围内跨节点通信基本可用。如果测试报错或者速度很低不要急着调模型先排查网络层配置。3.4 进入推理框架的集群模式底层通信验证通过后才进入推理框架配置。很多推理框架都支持指定张量并行度、流水线并行度和节点数量。以 PyTorch 生态为例分布式启动命令通常长这样# 伪配置示例实际项以你的推理框架和版本为准 torchrun --nnodes2 --nproc_per_node1 \ --rdzv_endpointnode01:29500 \ run_llm.py --model_path/data/models/70B \ --tensor_parallel_size2不同的推理框架参数名称可能不同。但核心概念是一致的--nnodes表示参与节点数--nproc_per_node表示每台机器的 GPU 进程数--rdzv_endpoint表示主节点的地址和端口。张量并行度一般用tensor_parallel_size或类似名称流水线并行度则用pipeline_parallel_size表示。并行度必须小于等于总设备数不能随意设大。这里需要特别说明不要直接照抄某个命令因为不同框架对多节点支持程度不一样。有些框架需要额外配置分布式初始化有些还需要在启动前设置NCCL_SOCKET_IFNAME指定正确的网卡接口。如果你不确定先从框架官方文档确认多机参数再动手。3.5 跑通单条推理任务配置完成后不要直接跑长文本或批量请求。先用一个很短的提示词跑单条推理。观察两件事一是日志中是否出现两个节点的信息二是两台机器的资源占用情况。在推理过程中另开一个终端分别查看两台机器的nvidia-smi。如果两台机器都有显存和内存占用说明模型确实被拆分到了两台设备上。如果只有一台机器有占用另一台完全没反应说明分布式初始化没生效或者任务只跑在了单机上。跑通单条任务后再逐步增加输入长度、上下文长度和并发数。每次只改一个变量这样才能定位问题到底出在通信、内存还是并发调度。4. 模型加载与张量并行70B、200B 和输出速度4.1 70B 模型的内存账本怎么算很多人问两台 DGX Spark 能不能跑 70B 模型。从内存容量看两台机器约 256GB 统一内存跑 70B 模型显然没有问题。但“没有问题”和“能稳定跑”之间还隔着权重精度、KV Cache 和上下文长度这些细节。我们先算权重账。70B 模型用不同精度保存文件体积差异非常大量化精度70B 权重估算单台 128GB 环境两台 256GB 环境BF16约 140GB很难完整加载权重可放但剩余空间要精打细算INT8约 70GB可加载但剩余偏紧比较充裕INT4约 35GB余量较大余量充足但这只是权重部分。推理过程中还要为每个请求分配 KV Cache为临时激活值预留内存框架本身也会占用一部分资源。如果你的上下文长度很长或者请求并发数较高KV Cache 可能再占几十 GB。所以即使 140GB 的 BF16 权重能放进双机环境也未必能支撑很长的上下文。计算内存时我更倾向于用“可用内存”而不是“总内存”。两台机器都还要跑操作系统、驱动、框架和网络栈可用内存通常比 256GB 略低。具体偏低多少取决于系统服务和运行环境。4.2 张量并行、流水线并行和数据并行怎么选双机环境里不同并行模式的效果差别很大。张量并行是把每一层的矩阵计算切分到多个设备上可以显著降低单设备的内存占用但同时通信量也最大。因为每一层计算完成之后都要把中间结果同步给其他设备。跨节点场景下张量并行对网络延迟和带宽要求很高。如果通信慢计算快的优势会被抵消。流水线并行是按层拆分不同设备负责不同的 Transformer 层通信频率相对较低只有层与层之间才需要传递结果。在跨节点场景里流水线并行通常比张量并行更容忍网络延迟但它有个缺点每一层仍然需要完整的权重单设备内存占用不会因为并行而降低。数据并行则是让每个设备都持有完整模型副本同时处理不同请求。它能提升并发吞吐但对降低单请求内存占用没有帮助。如果模型权重已经接近单机内存上限数据并行会导致每台机器都 OOM。简单总结并行方式主要目的通信压力内存收益张量并行降低单设备内存、加快单请求高明显流水线并行降低单设备按层限制中有限数据并行提高并发请求数低无对两台 DGX Spark 跑 70B 模型来说比较稳妥的组合是先尝试张量并行度 2流水线并行度 1。如果网络表现不理想再考虑调低张量并行度改用流水线并行或数据并行。不要一上来就设很高的并行度通信瓶颈会立刻暴露。4.3 单并发输出 token 速率怎么看“两台 DGX Spark 用张量并行跑 70B 模型单并发输出多少 token/s”这是很多人关心的问题。但最诚实的回答是这个数字在不同环境里差异很大不能拿一个固定的答案当标准。影响 token 速率的变量包括模型结构、量化精度、输入长度、输出长度、KV Cache 是否启用、跨节点通信带宽、推理框架版本、有没有做预热、以及两台机器的负载情况。硬件相同也不代表结果相同软件配置一点差异就能让速率差出很多。更合理的做法是自己在目标环境里测一遍。固定一组测试条件比如“输入 128 token输出 256 tokenINT8 精度无并发”然后记录两个指标TTFT也就是从发送请求到收到第一个 token 的耗时。生成阶段每秒输出的 token 数量。同时用网络监控工具观察跨节点通信带宽。如果 token 速率比单机还低优先检查通信是否成为瓶颈。比如ibstatus或等价工具显示链路带宽接近满载说明并行度设置可能过高或者数据拆分方式不适合当前网络。一个容易被忽略的点是预热。大模型推理前往往有显存分配、权重加载、CUDA kernel 编译等过程。第一次请求通常很慢第二次、第三次才会稳定。测试时应该先运行一到两次热身体请求再记录正式数据。4.4 200B 模型本地部署的合理预期DGX Spark 支持本地部署 200B 量级大模型这个说法本身是成立的但具体部署方式要会读。200B 模型通常指经过量化或压缩后的版本不一定是用原始精度完整加载。单台机器能跑 200B说明模型已经通过某种方式被压缩到了适合本地内存的程度。两台机器并联之后内存池扩大到约 256GB这意味着你可以在相同量化精度下跑更大的模型或者在相同模型规模下使用更高精度和更长上下文。比如单机只能跑 INT4 的 200B双机也许能跑 INT8 或加载更长上下文的版本。但真正决定能否部署的不完全是内存总量还包括推理框架对模型分片的支持。很多大模型权重文件是分片保存的加载时框架需要按张量并行方式把不同分片发送到不同设备。如果框架支持不好内存再大也可能加载失败。所以我建议首次部署前先确认推理框架对多机分片的支持程度从一个小规模模型验证流程再挑战 200B。5. 性能验证与排查如何判断两台机器真在协作5.1 联机成功的判断标准判断双机连接是否成功不能只看“没报错”。一个任务只在单机上跑程序也不一定报错但这不是你想要的联机效果。建议用一组明确信号来判断两台机器能互相 ping 通并且 SSH 免密登录正常。高速网卡进入 active 状态链路速率达到预期。NCCL 测试中两个节点都能真正参与通信。分布式任务启动日志里能看到rank0和rank1或者world_size2这样的信息。推理过程中两台机器都能看到明显的 GPU 或内存占用。用相同输入跑两次输出结果稳定不会出现一台机器计算结果和另一台不一致的情况。这些信号全部满足才说明两台机器真正进入了同一个计算任务。5.2 常见问题排查表现象优先排查方向高速网卡不识别驱动、固件、PCIe 插槽、线缆是否插紧网络能 ping 通但 NCCL 测试失败防火墙、hosts 配置、MTU、RDMA 设置启动后只有一台机器有占用分布式初始化失败、节点地址配置错误、SSH 免密不通推理速度比单机还慢网络带宽瓶颈、张量并行度过高、数据切分不合理启动时报 OOM权重精度太高、上下文过长、KV Cache 过大、未预留系统内存两台机器输出结果不一致权重文件路径不同、量化精度设置不一致、模型版本不同遇到问题的时候不要一上来就怀疑“NVIDIA Sync 没用”或者“模型坏了”。先看现象属于哪一类再按链路排查。5.3 日志优先参数第二排查双机问题时我自己的顺序很固定先看现象再看日志然后看输入接着看网络和存储最后才调整参数。具体来说先看日志里有没有明确报错。比如“rank mismatch”“connection timeout”“CUDA error”这些信息能很快定位问题是在网络层、运行层还是模型层。如果日志显示连接超时优先检查防火墙和 hosts。如果日志显示设备不对检查 CUDA 可见设备和分布式启动参数。如果日志不报错但任务卡住就看两台机器的资源占用。开一个终端执行top或nvidia-smi观察是 CPU 卡住、显存占满还是网络等待。要先把资源占用情况摸清楚再改参数否则你改了也没用。有一次我遇到过两机启动正常但推理速度比单机还慢的情况。查了几轮才发现是跨节点通信走了普通以太网而不是高速网卡。这提醒我通信链路选择是双机配置里最容易忽略的环节。框架默认用的网卡接口不一定是高速网口需要显式指定NCCL_SOCKET_IFNAME或等价参数让通信走对路径。5.4 长期运行的稳定性与重试如果你只是临时跑一次实验前台启动就够用。但如果想把双机环境当成一个长期可用的推理基础设施就必须考虑进程管理、日志和失败重试。大模型推理任务启动慢先要加载权重、初始化分布式环境这个过程可能持续几十秒甚至几分钟。如果中途失败一次所有节点都要重新加载浪费时间不说还容易出现脏数据残留。建议把启动命令写成脚本每次运行前清理旧日志和临时文件保证执行过程幂 NVIDIA Sync双机连接DGX Spark：70B/200B模型推理实战
如果你只是分别跑两个模型两台 DGX Spark 确实不需要连接。但只要你的目标是“把两台机器拉成一个池子一起加载同一个大模型”NVIDIA Sync 就会变成绕不开的话题。简单说这是 NVIDIA 面向 DGX Spark 这类本地计算设备设计的多机聚合方案核心目的是让两台甚至多台机器通过高速互连共享计算资源和统一内存从而在本地运行单机跑不动的模型或者提高单个请求的推理吞吐。它在实际场景里最常被提到的用法就是本地部署 200B 量级大模型或者把 70B 模型拆到两台机器上做张量并行推理。这篇文章想把一个问题讲透NVIDIA Sync 连接两台 DGX Spark到底怎么连、连之前要确认什么、连完之后跑 70B 或 200B 模型时有哪些参数值得看以及怎么判断连接是真的成功。我不会只罗列操作步骤我更想说明每个步骤背后的原因。双机推理不像插一根网线那么简单很多失败都出在网络、软件版本、模型路径和并行参数这些前置条件上。1. 先搞清楚两台 DGX Spark 连起来到底解决什么问题1.1 单台 DGX Spark 的边界在哪DGX Spark 是 NVIDIA 在本地 AI 设备上的一款产品核心卖点是把桌面级设备做成一台能跑大模型的机器。常见配置带有 128GB 统一内存CPU、GPU 和内存之间的数据交换不需要把数据频繁拷回主板这对本地部署大模型来说是非常大的优势。官方宣传里也强调过本地部署 200B 量级参数模型的能力。但这里的“能跑”需要拆开理解。200B 模型通常不是指任意权重、任意精度、任意上下文长度都能直接塞进单机。它更多是说要通过量化、低精度推理、特定推理框架配置之后的运行能力。如果你把一个没有量化的 200B 模型用 BF16 精度直接加载单就权重就可能接近 400GB单台机器无论如何装不下。所以官方宣传里的“本地部署 200B”默认条件是模型经过压缩、量化或者使用了支持高效加载和分页管理的推理引擎。当你用单台 DGX Spark 跑 70B 模型时情况会更现实。70B 模型用不同精度加载权重体积差别很大。BF16 下权重约 140GB单机放不下INT8 下约 70GB勉强能放INT4 下约 35GB相对宽裕。这也是很多人在单机上跑 70B 模型时优先选择 4bit 或 8bit 量化模型的原因。KV Cache 和激活还会占用额外内存所以就算权重能放进去长上下文、高并发、长输出仍然可能让单机直接 OOM。这说明一个关键边界单机容量不是无上限能加载模型和能把模型跑得舒服是两回事。当你开始考虑把两台 DGX Spark 连接起来时通常已经遇到了两类问题中的至少一类。第一类是模型权重超过单机可用内存第二类是即使权重能放进去单请求的生成速度也不够快。前者靠内存扩容解决后者靠并行计算解决。1.2 双机并联带来的三个变化两台机器并联后表面上只是多了 128GB 内存实际上带来三个不同方向的提升。第一个变化是聚合内存。两台机器的统一内存加起来约 256GB这让原本需要压缩到 INT4 才能跑的模型有机会用 INT8 甚至更高精度运行。精度越高输出质量通常越稳定重复性也更好。这对做模型评测、技术验证、内部工具的场景很有价值。第二个变化是单请求吞吐。通过张量并行一个模型可以被切到两张卡上同时计算矩阵乘法被拆分到不同设备理论上每个 token 的生成时间可以缩短。但这有一个前提跨节点通信成本必须足够低否则通信等待会吃掉并行收益。第三个变化是并发请求能力。如果模型能在两台机器上复制出一份完整副本就可以用数据并行方式同时服务多个请求。不过这不会减少单请求所需的内存每个副本仍然占用完整的模型权重。所以并发提升和降低显存占用是两个不同方向不能混在一起看。这三个变化不是自动同时发生的。你需要在推理框架里显式选择并行方式并设置并行度。否则两台机器即使物理连好也可能只是两台各自运行的独立机器。1.3 NVIDIA Sync 在其中的位置NVIDIA Sync 在官方语境里更接近一种面向多机协同的互连机制而不是简单的文件同步或备份工具。它要解决的问题是让多台 DGX Spark 之间的通信延迟足够低、带宽足够稳定这样上层框架才能像使用单机多卡一样使用多台机器。可以把它理解成类似于 NVLink 在单机多卡里的作用。NVLink 让单机内的 GPU 能以极高带宽交换数据NVIDIA Sync 则是把这种“多设备协同”思路扩展到多机场景。但跨机之后物理链路会依赖具体的网卡、线缆和交换机通信协议也可能涉及 RDMA 或高速以太网。所以它的实际表现不只取决于软件还取决于你排的线、装的驱动、配的网络参数和选用的交换机。这一点直接决定了后面所有步骤。如果你只想在两台机器之间共享文件NVIDIA Sync 并不是必须的如果你想跑张量并行让两个设备在每一层计算时频繁交换数据那它的通信质量就是决定能不能跑、跑多快的核心因素。2. 动手前先确认硬件、软件和网络的边界条件2.1 硬件链路需要什么最小硬件组合是两台 DGX Spark、一根符合机器高速互连端口的线缆、可选的交换机以及足够稳定的电源。如果你的机器有网卡还需要确保网卡驱动正确安装如果网卡是外接卡还要检查 PCIe 插槽是否插紧、供电是否正常。这里有一个常见误区以为两台机器用普通网线直连就等于组建了集群。普通网线直连只能满足最基本的 TCP 通信做分布式训练和推理时带宽和延迟都会成为瓶颈。单机多卡之间是 PCIe 和 NVLink 这类高速通道跨机器之后至少也要有明确支持 RDMA 或类似高速协议的网络接口否则模型每算一层都要等通信速度会非常难看。如果你打算以后再扩展到三台、四台机器那就需要考虑交换机。两台机器直连时拓扑简单但加入第三台后主机命名、子网划分、交换机端口配置都会变得复杂。现在先按双机验证没问题但规划时给未来留出扩展空间可以少走很多弯路。2.2 驱动、CUDA 和容器版本必须对齐我在实际配置多机环境时遇到最多的报错不是模型文件损坏而是两台机器的软件版本不一致。分布式任务启动时各节点会检查驱动、CUDA、运行时库和框架版本。版本差异会导致节点间握手失败、算出的结果不一致甚至某些节点直接启动不了。所以开始前先做四件事两台机器安装相同版本的系统镜像或驱动。检查 CUDA Toolkit 版本并保持对齐。确认 NVIDIA Container Toolkit 已经正常安装或者在宿主机环境下把依赖装好。如果使用容器两台机器使用同一个镜像 tag不要一台用最新的另一台用旧版本。检查版本时最常用的是nvidia-smi看驱动和 GPU 信息用nvcc --version看 CUDA 版本。如果使用了高速网卡还需要用网卡自带的管理工具查看固件版本。固件版本不一致的问题容易被忽略但一旦出问题报错信息往往非常难懂。版本对齐不是能做一次就结束的事情。系统升级、驱动更新、镜像重拉都会让版本重新漂移。建议把两台机器的软件配置记录成文档每次改动后都重新检查一遍。2.3 网络规划带宽、延迟、MTU 和主机名跨节点并行对网络的敏感度比很多人想象中高。推理时每次前向传播都可能产生多次跨节点通信虽然不像训练那样频繁通信梯度但张量并行场景下每一层 Transformer 结构都需要把中间激活同步给另一台设备。这意味着延迟哪怕只多几毫秒累计起来也会明显拖慢生成速度。配置网络前先把这几个项目检查完检查项建议操作判断标准主机互通配置/etc/hosts加入两台机器的主机名和 IP能互相 ping 通SSH 免密生成密钥并复制到对端两台机器能直接ssh node02登录防火墙放行分布式框架使用的端口端口没有被阻断MTU确认两台机器网卡 MTU 设置一致不一致时传输性能会下降时间同步使用 chrony 或 NTP 同步时间多节点任务对时间偏移敏感存储模型权重放到共享目录或在两台机器上保存完全相同的副本路径一致、权限一致很多人会把精力放在模型参数上却忽略主机名和 SSH。分布式框架启动时会根据--rdzv_endpoint或类似参数连接主节点如果对端主机名解析不到任务就会一直卡在等待状态。先确认网络能通、能免密登录再启动并发任务能省下大量排错时间。3. 实际联机流程从物理连接到软件识别3.1 物理连接步骤物理连接听起来简单但顺序错了会浪费很多时间。我的建议是两台机器都关机并断开电源。把互连线缆插到对应的高速网口或者安装外接网卡。如果使用交换机把两台机器分别接入交换机端口。确认线缆没有松动再给两台机器上电。上电后不要急着启动大模型先做设备识别。打开终端查看系统是否发现了新的网络接口或网卡设备。可以用ip link show查看网络接口状态用lspci | grep -i nvidia看 NVIDIA 相关设备。如果接线正确系统应该能看到网口进入 link up 状态。如果 link down先换线缆、换端口不要直接怀疑软件配置。这个阶段最容易忽略的是电源和散热。DGX Spark 虽然比机房服务器小很多但持续跑大模型时功耗和发热仍然不低。两台机器放在同一张桌子上要注意通风、电源插座的负载能力以及长时间运行时的噪音。对桌面环境来说这可能是比软件配置更现实的问题。3.2 网络设备识别与固件检查如果使用的是高速网卡系统识别到设备后还需要确认驱动和固件状态。常见网卡管理工具中ibstatus或ibstat用于查看 InfiniBand 设备状态RoCE 网卡则通常在以太网模式下工作。因为不同型号、不同代际的网卡差异很大这里只给一个验证思路找到该网卡对应的状态查询命令确认端口是否 active、速率是否达到预期、有没有错误计数。如果链路状态正常但速率远低于预期大概率是网线或交换机端口的问题。如果网卡根本无法识别优先检查驱动和固件其次看 PCIe 插槽。先不要急着检查推理框架。3.3 分布式启动前的通信验证很多人在物理连接之后直接运行 70B 模型这是最容易出问题的方式。先做更基础的通信验证确保两台机器真的能互通。验证顺序可以这样安排# 检查基础网络连通性 ping -c 4 node02 # 检查 SSH 免密 ssh node02 nvidia-smi # 检查高速网络接口状态 ibstatus如果 ping 不通先检查 IP 配置、交换机和线缆。如果 ping 通但 SSH 失败检查 SSH 服务和密钥。如果 ping 通、SSH 也没问题但高速网卡状态异常则检查 RDMA 或 RoCE 相关驱动。基础网络验证通过后再跑一轮更接近真实场景的分布式通信测试。NCCL 是 NVIDIA 提供的多 GPU 通信库很多训练和推理框架底层都用它。NCCL 测试工具可以测量多节点 all-reduce 等操作的带宽和延迟。类似这样的测试方式# 示例命令实际参数要以你安装的 NCCL 测试工具版本为准 mpirun --host node01,node02 -np 2 all_reduce_perf -b 8M -e 1G如果两边机器都能参与测试并且带宽在合理范围内跨节点通信基本可用。如果测试报错或者速度很低不要急着调模型先排查网络层配置。3.4 进入推理框架的集群模式底层通信验证通过后才进入推理框架配置。很多推理框架都支持指定张量并行度、流水线并行度和节点数量。以 PyTorch 生态为例分布式启动命令通常长这样# 伪配置示例实际项以你的推理框架和版本为准 torchrun --nnodes2 --nproc_per_node1 \ --rdzv_endpointnode01:29500 \ run_llm.py --model_path/data/models/70B \ --tensor_parallel_size2不同的推理框架参数名称可能不同。但核心概念是一致的--nnodes表示参与节点数--nproc_per_node表示每台机器的 GPU 进程数--rdzv_endpoint表示主节点的地址和端口。张量并行度一般用tensor_parallel_size或类似名称流水线并行度则用pipeline_parallel_size表示。并行度必须小于等于总设备数不能随意设大。这里需要特别说明不要直接照抄某个命令因为不同框架对多节点支持程度不一样。有些框架需要额外配置分布式初始化有些还需要在启动前设置NCCL_SOCKET_IFNAME指定正确的网卡接口。如果你不确定先从框架官方文档确认多机参数再动手。3.5 跑通单条推理任务配置完成后不要直接跑长文本或批量请求。先用一个很短的提示词跑单条推理。观察两件事一是日志中是否出现两个节点的信息二是两台机器的资源占用情况。在推理过程中另开一个终端分别查看两台机器的nvidia-smi。如果两台机器都有显存和内存占用说明模型确实被拆分到了两台设备上。如果只有一台机器有占用另一台完全没反应说明分布式初始化没生效或者任务只跑在了单机上。跑通单条任务后再逐步增加输入长度、上下文长度和并发数。每次只改一个变量这样才能定位问题到底出在通信、内存还是并发调度。4. 模型加载与张量并行70B、200B 和输出速度4.1 70B 模型的内存账本怎么算很多人问两台 DGX Spark 能不能跑 70B 模型。从内存容量看两台机器约 256GB 统一内存跑 70B 模型显然没有问题。但“没有问题”和“能稳定跑”之间还隔着权重精度、KV Cache 和上下文长度这些细节。我们先算权重账。70B 模型用不同精度保存文件体积差异非常大量化精度70B 权重估算单台 128GB 环境两台 256GB 环境BF16约 140GB很难完整加载权重可放但剩余空间要精打细算INT8约 70GB可加载但剩余偏紧比较充裕INT4约 35GB余量较大余量充足但这只是权重部分。推理过程中还要为每个请求分配 KV Cache为临时激活值预留内存框架本身也会占用一部分资源。如果你的上下文长度很长或者请求并发数较高KV Cache 可能再占几十 GB。所以即使 140GB 的 BF16 权重能放进双机环境也未必能支撑很长的上下文。计算内存时我更倾向于用“可用内存”而不是“总内存”。两台机器都还要跑操作系统、驱动、框架和网络栈可用内存通常比 256GB 略低。具体偏低多少取决于系统服务和运行环境。4.2 张量并行、流水线并行和数据并行怎么选双机环境里不同并行模式的效果差别很大。张量并行是把每一层的矩阵计算切分到多个设备上可以显著降低单设备的内存占用但同时通信量也最大。因为每一层计算完成之后都要把中间结果同步给其他设备。跨节点场景下张量并行对网络延迟和带宽要求很高。如果通信慢计算快的优势会被抵消。流水线并行是按层拆分不同设备负责不同的 Transformer 层通信频率相对较低只有层与层之间才需要传递结果。在跨节点场景里流水线并行通常比张量并行更容忍网络延迟但它有个缺点每一层仍然需要完整的权重单设备内存占用不会因为并行而降低。数据并行则是让每个设备都持有完整模型副本同时处理不同请求。它能提升并发吞吐但对降低单请求内存占用没有帮助。如果模型权重已经接近单机内存上限数据并行会导致每台机器都 OOM。简单总结并行方式主要目的通信压力内存收益张量并行降低单设备内存、加快单请求高明显流水线并行降低单设备按层限制中有限数据并行提高并发请求数低无对两台 DGX Spark 跑 70B 模型来说比较稳妥的组合是先尝试张量并行度 2流水线并行度 1。如果网络表现不理想再考虑调低张量并行度改用流水线并行或数据并行。不要一上来就设很高的并行度通信瓶颈会立刻暴露。4.3 单并发输出 token 速率怎么看“两台 DGX Spark 用张量并行跑 70B 模型单并发输出多少 token/s”这是很多人关心的问题。但最诚实的回答是这个数字在不同环境里差异很大不能拿一个固定的答案当标准。影响 token 速率的变量包括模型结构、量化精度、输入长度、输出长度、KV Cache 是否启用、跨节点通信带宽、推理框架版本、有没有做预热、以及两台机器的负载情况。硬件相同也不代表结果相同软件配置一点差异就能让速率差出很多。更合理的做法是自己在目标环境里测一遍。固定一组测试条件比如“输入 128 token输出 256 tokenINT8 精度无并发”然后记录两个指标TTFT也就是从发送请求到收到第一个 token 的耗时。生成阶段每秒输出的 token 数量。同时用网络监控工具观察跨节点通信带宽。如果 token 速率比单机还低优先检查通信是否成为瓶颈。比如ibstatus或等价工具显示链路带宽接近满载说明并行度设置可能过高或者数据拆分方式不适合当前网络。一个容易被忽略的点是预热。大模型推理前往往有显存分配、权重加载、CUDA kernel 编译等过程。第一次请求通常很慢第二次、第三次才会稳定。测试时应该先运行一到两次热身体请求再记录正式数据。4.4 200B 模型本地部署的合理预期DGX Spark 支持本地部署 200B 量级大模型这个说法本身是成立的但具体部署方式要会读。200B 模型通常指经过量化或压缩后的版本不一定是用原始精度完整加载。单台机器能跑 200B说明模型已经通过某种方式被压缩到了适合本地内存的程度。两台机器并联之后内存池扩大到约 256GB这意味着你可以在相同量化精度下跑更大的模型或者在相同模型规模下使用更高精度和更长上下文。比如单机只能跑 INT4 的 200B双机也许能跑 INT8 或加载更长上下文的版本。但真正决定能否部署的不完全是内存总量还包括推理框架对模型分片的支持。很多大模型权重文件是分片保存的加载时框架需要按张量并行方式把不同分片发送到不同设备。如果框架支持不好内存再大也可能加载失败。所以我建议首次部署前先确认推理框架对多机分片的支持程度从一个小规模模型验证流程再挑战 200B。5. 性能验证与排查如何判断两台机器真在协作5.1 联机成功的判断标准判断双机连接是否成功不能只看“没报错”。一个任务只在单机上跑程序也不一定报错但这不是你想要的联机效果。建议用一组明确信号来判断两台机器能互相 ping 通并且 SSH 免密登录正常。高速网卡进入 active 状态链路速率达到预期。NCCL 测试中两个节点都能真正参与通信。分布式任务启动日志里能看到rank0和rank1或者world_size2这样的信息。推理过程中两台机器都能看到明显的 GPU 或内存占用。用相同输入跑两次输出结果稳定不会出现一台机器计算结果和另一台不一致的情况。这些信号全部满足才说明两台机器真正进入了同一个计算任务。5.2 常见问题排查表现象优先排查方向高速网卡不识别驱动、固件、PCIe 插槽、线缆是否插紧网络能 ping 通但 NCCL 测试失败防火墙、hosts 配置、MTU、RDMA 设置启动后只有一台机器有占用分布式初始化失败、节点地址配置错误、SSH 免密不通推理速度比单机还慢网络带宽瓶颈、张量并行度过高、数据切分不合理启动时报 OOM权重精度太高、上下文过长、KV Cache 过大、未预留系统内存两台机器输出结果不一致权重文件路径不同、量化精度设置不一致、模型版本不同遇到问题的时候不要一上来就怀疑“NVIDIA Sync 没用”或者“模型坏了”。先看现象属于哪一类再按链路排查。5.3 日志优先参数第二排查双机问题时我自己的顺序很固定先看现象再看日志然后看输入接着看网络和存储最后才调整参数。具体来说先看日志里有没有明确报错。比如“rank mismatch”“connection timeout”“CUDA error”这些信息能很快定位问题是在网络层、运行层还是模型层。如果日志显示连接超时优先检查防火墙和 hosts。如果日志显示设备不对检查 CUDA 可见设备和分布式启动参数。如果日志不报错但任务卡住就看两台机器的资源占用。开一个终端执行top或nvidia-smi观察是 CPU 卡住、显存占满还是网络等待。要先把资源占用情况摸清楚再改参数否则你改了也没用。有一次我遇到过两机启动正常但推理速度比单机还慢的情况。查了几轮才发现是跨节点通信走了普通以太网而不是高速网卡。这提醒我通信链路选择是双机配置里最容易忽略的环节。框架默认用的网卡接口不一定是高速网口需要显式指定NCCL_SOCKET_IFNAME或等价参数让通信走对路径。5.4 长期运行的稳定性与重试如果你只是临时跑一次实验前台启动就够用。但如果想把双机环境当成一个长期可用的推理基础设施就必须考虑进程管理、日志和失败重试。大模型推理任务启动慢先要加载权重、初始化分布式环境这个过程可能持续几十秒甚至几分钟。如果中途失败一次所有节点都要重新加载浪费时间不说还容易出现脏数据残留。建议把启动命令写成脚本每次运行前清理旧日志和临时文件保证执行过程幂