从 2025 年 NVIDIA GTC 发布以来，DGX Spark 在本地大模型部署圈子里始终保持着很高的话题度。它把“桌面级设备跑百亿甚至千亿参数模型”这件事，从概念变成了可落地的硬件方案。不过，很多团队在实际使用时会遇到同一个问题：单台 DGX Spark 拥有 128GB 统一内存，看起来确实不小，但当你需要部署 200B 级别的模型，或者业务要求同时处理多个并发推理请求时，单机的内存容量和总算力都会变得紧张。
把两台 DGX Spark 通过 NVIDIA Sync 连接起来，组成一个“两台设备协同工作的小集群”，是解决这类需求的重要思路。本文将从核心概念、环境准备、物理组网、软件配置、推理框架部署到吞吐估算，完整拆解整个连接与使用流程。无论你已经在使用 DGX Spark，还是正在调研本地私有化大模型部署方案，这篇教程都可以作为参考。
1. NVIDIA Sync 是什么：DGX Spark 多机互联的核心概念
1.1 先理解 DGX Spark 的定位
DGX Spark 不是传统意义上的 PC 工作站。它基于 NVIDIA GB10 Grace Blackwell 超级芯片，CPU 和 GPU 集成在一个封装内，通过 NVLink-C2C 高速总线连接，CPU 可以直接访问 GPU 内存。这种架构带来的直接好处是：CPU 和 GPU 共享统一内存池，模型权重不需要在 CPU 内存和显存之间反复拷贝，推理时的数据搬运开销大幅降低。
内存容量是 DGX Spark 最核心的指标之一。128GB 统一内存意味着，即使不依赖外部服务器，单台设备也能加载相当规模的量化模型。发布时 NVIDIA 官方的宣传重点是“本地运行 200B 参数模型”，这一定位让很多个人开发者和中小团队看到了私有化部署的可能性。与此同时，DGX Spark 的价格也进入了不少团队可以评估的区间（具体售价请以官方渠道各时点信息为准），这也是它热度持续走高的原因之一。
但“可以运行”和“运行得好”是两回事。200B 模型加载进去之后，单机还要同时承担 KV Cache、推理中间结果、服务框架自身的开销。如果上下文长度拉长，或者业务请求并发上来，128GB 很快就会成为瓶颈。这时，连接第二台 DGX Spark，用两台设备共同承担推理任务，就是最直接的扩容方式。
1.2 两台设备互联的真实场景
把两台 DGX Spark 连接在一起，通常有四种典型场景。
第一种是超大模型部署。当模型权重加上运行开销超过了单台设备的内存容量，又因为数据安全原因不能放到云上，双机甚至多机协同就成了必经之路。
第二种是吞吐量优化。单个 70B 级别的模型，在单台设备上推理时，单并发输出速度可能只有个位数到十几 token/s。通过张量并行（Tensor Parallelism）把模型切分到两台设备上，每台设备只需要计算自己负责的那一部分，理论上可以显著提升单并发和低并发场景的吞吐。
第三种是开发与生产环境隔离。你可以用一台 DGX Spark 跑正式的推理服务，另一台做模型微调、评测和版本验证，两台设备之间共享数据和调试通道。
第四种是多模型并行。一台设备跑对话模型，另一台设备跑向量化模型或 Reranker，通过内部网络互相调用，组成一套完整的 RAG 服务链路。
无论哪种场景，背后都需要一套可靠的多机通信机制。NVIDIA Sync 就是这套机制的入口。
1.3 NVIDIA Sync 在连接中扮演什么角色
严格来说，NVIDIA Sync 不是“一个命令”或“一个工具”，而是一整套面向 DGX Spark 多机协同的软硬件方案。它的作用，是让两台 DGX Spark 从“网络上互相能 ping 通”上升到“一个分布式推理系统”。
这个升级过程包含三个层面。第一层是物理互连，两台设备需要有高速网络接口相连，确保数据通路带宽足够。第二层是系统配置，包括固定 IP、主机名解析、SSH 可信关系、防火墙放通等基础工作。第三层是分布式运行时，也就是让 PyTorch、NCCL、Ray 这些组件能够感知到对方设备上的 GPU 算力和内存资源，并在框架层面完成多机调度。
理解这一点很重要。很多初次接触多机训练的开发者会以为“连接两台设备”只需要插一根线、设置一下 IP 就结束了，但真正让分布式推理跑起来，还依赖软件栈的完整配置。本文后续章节会按照这三个层面依次展开，你可以把 NVIDIA Sync 理解成贯穿整个过程的方法论和官方能力集合，而具体到操作，就是每一层配置的逐步落实。
2. 连接前的环境准备与版本检查
2.1 硬件与场地准备
连接两台 DGX Spark 之前，先确认硬件条件。你需要准备两台 DGX Spark，并确保它们使用相同或兼容的电源规格和散热环境。DGX Spark 的定位虽然是桌面设备，但高负载推理时发热和功耗仍然可观，不要把它塞进密闭弱电箱或堆叠在一起使用，设备之间至少要保持正常的通风间距。
网络互连方面，至少需要一条可靠的高速以太网线缆。如果条件允许，建议通过支持万兆或更高规格的交换机连接。直连线缆适合两台设备互连的简单场景，交换机组网则方便后续扩展第三台、第四台设备。具体使用哪种线缆规格，请以两台设备的实际网口类型和 NVIDIA 官方配件说明为准，不要随意混用不兼容的线缆。
连接思路是先规划拓扑，再设置 IP，最后验证链路。不要跳过规划直接插线配置，否则后续排查问题时，线缆和 IP 的混乱会让你浪费大量时间。
2.2 系统与软件初始检查
DGX Spark 出厂搭载 NVIDIA 定制的 DGX OS，底层是 Linux 系统。拿到设备后，先通过显示器和键鼠，或者通过默认管理网络 SSH 登录系统，做一轮基础状态检查。
# 查看系统发行版信息 cat /etc/os-release # 查看内核版本 uname -a # 查看 GPU 是否被正确识别 nvidia-smi # 查看内存与统一内存信息 free -h如果nvidia-smi能正常输出，并且能看到 Grace Blackwell 芯片信息，说明基础驱动没有问题。建议记录下每台设备的主机名、系统版本、驱动版本，后续做多机互通时，这些信息会帮助你快速判断版本兼容性问题。
2.3 软硬件检查清单
| 检查项 | 说明 | 验证方式 |
|---|---|---|
| 系统版本 | 两台设备应保持同一大版本 | cat /etc/os-release |
| 驱动状态 | GPU 能被正常识别 | nvidia-smi |
| 网络接口 | 确认互联接口名称和速率 | ip link/ethtool |
| 主机名 | 提前规划，避免重名 | hostnamectl |
| 防火墙 | 放通集群通信端口 | sudo ufw status |
| SSH 服务 | 开启并允许密钥登录 | systemctl status ssh |
注意：如果你的设备是刚拆箱的，建议先按照 NVIDIA 官方文档完成系统初始化和驱动更新，再进行双机连接操作。版本需要根据你的实际设备情况调整，本文示例以常见 Linux 环境为例，重点演示配置思路。
3. 物理连接与网络组网
3.1 选择连接拓扑
两台 DGX Spark 最简单的连接方式是直连：用一根高速网线把两台设备的互联网口直接连起来。这种方式延迟低、没有交换机转发开销，适合两台设备固定的场景。
如果后续还要扩展更多设备，则建议使用交换机。通过交换机连接时，所有设备处于同一个二层网络中，IP 规划更灵活，排查问题也更方便。无论采用哪种拓扑，都建议为集群规划专用的静态 IP 网段，例如：
| 设备 | 主机名 | IP 地址 |
|---|---|---|
| 设备 A | dgx-a | 192.168.100.10 |
| 设备 B | dgx-b | 192.168.100.11 |
使用独立网段避免和办公网络冲突，是双机组网的基本功。固定 IP 不仅方便记忆，更重要的是后续 NCCL、Ray 等分布式组件需要稳定的地址发现机制。
3.2 配置网络接口
连接好线缆后，需要确认系统是否识别到了新的网络接口。使用ip addr查看所有网络接口，找到与互联线缆对应的那个接口名。不同系统下接口名可能不同，常见形式包括enp1s0f0np0、eth0等。
接下来为接口配置静态 IP。以设备 A 为例：
# 查看接口状态 ip addr show # 使用 nmcli 配置静态 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。这里要特别注意：如果系统里存在多个网卡，务必确认你修改的是互联接口，而不是管理网络接口，否则可能把设备“配断网”。
3.3 连通性验证与 SSH 配置
IP 配置完成后，先验证链路是否通畅。
# 从设备 A ping 设备 B ping 192.168.100.11 # 查看网卡速率与协商状态 ethtool <接口名>ping通了只代表二层和三层网络正常，还不能说明带宽和稳定性。建议进一步用iperf3做一次简单的带宽压测：
# 设备 B 先启动服务端 iperf3 -s # 设备 A 以客户端模式测试 30 秒 iperf3 -c 192.168.100.11 -t 30通过测试数据，可以确认实际传输带宽是否接近网卡协商速率。如果带宽明显偏低，检查线缆是否插到了正确的接口、是否启用了巨型帧（Jumbo Frame）、是否有网卡降速现象。
网络通畅后，配置 SSH 免密登录。这一步非常关键，因为后续分布式组件在多机之间拉起进程时，通常依赖 SSH 免密能力。
# 在设备 A 上生成密钥（如果还没有） ssh-keygen -t ed25519 # 将公钥复制到设备 B ssh-copy-id dgx-b@192.168.100.11 # 验证免密登录 ssh dgx-b@192.168.100.11 hostname同样操作，将设备 B 的公钥复制到设备 A，实现双向免密。
4. 软件配置与多机协同验证
4.1 更新系统与基础组件
网络层就绪后，进入软件配置阶段。首先确保两台设备的系统组件、驱动和 CUDA 工具链处于相近版本。
# 更新系统软件源和软件包 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修改完成后，分别在两台设备上执行ping dgx-a和ping dgx-b验证主机名解析是否生效。
4.3 使用 NVIDIA Sync 建立多机协同会话
NVIDIA Sync 的正式启用，通常会借助 NVIDIA 提供的管理工具或控制台完成设备注册与发现。具体入口和界面会随软件版本迭代而变化，建议以官方文档和工具界面为准。这里要理解的核心链路是：设备发现 → 网络检测 → 会话建立 → 资源分配到分布式运行时。
如果暂时没有系统管理工具，也可以通过完全手动的分布式配置达到同样的多机协同效果。本质上，我们需要的是一套能让两台设备上的 GPU 互相感知的运行时环境。这一步可以通过 NCCL 测试来完成验证。
4.4 用 NCCL 测试验证双机通信
NCCL（NVIDIA Collective Communications Library）是 NVIDIA 提供的多 GPU 和多节点通信库，PyTorch 分布式训练和 vLLM 多卡推理底层都依赖它。下面用一段最简单的 PyTorch 程序验证两台 DGX Spark 能否通过 NCCL 正常通信。
# 文件路径：任意目录/test_allreduce.py import torch import torch.distributed as dist def main(): # 初始化分布式进程组，使用 NCCL 后端 dist.init_process_group(backend="nccl") rank = dist.get_rank() local_rank = dist.get_local_rank() # 当前进程绑定到本机对应的 GPU torch.cuda.set_device(local_rank) # 每个进程创建一个初始值等于 rank 的 tensor tensor = torch.ones(1, device="cuda") * rank # 所有进程执行 all_reduce 求和 dist.all_reduce(tensor, op=dist.ReduceOp.SUM) if rank == 0: print(f"rank={rank}, all_reduce result={tensor.item()}") else: print(f"rank={rank}, all_reduce result={tensor.item()}") if __name__ == "__main__": main()在设备 A 上启动：
torchrun --nnodes=2 --nproc-per-node=1 --node-rank=0 \ --master-addr=192.168.100.10 --master-port=29500 \ test_allreduce.py在设备 B 上启动：
torchrun --nnodes=2 --nproc-per-node=1 --node-rank=1 \ --master-addr=192.168.100.10 --master-port=29500 \ test_allreduce.py正常情况下，两台终端窗口都会输出all_reduce result=1.0。因为 rank 0 的初始值是 0，rank 1 的初始值是 1，求和结果为 1。如果能看到这个结果，说明 NCCL 可以正常跨节点通信，分布式运行时已经打通。
小提示：这里的nproc-per-node=1表示每个节点启动 1 个进程。如果单台设备上实际只有一个 GPU 实例，写 1 即可；如果设备被系统识别为多个计算实例，可以按实际数量调整。
5. 双机部署 70B/200B 模型的实战案例
5.1 实战目标
打通双机通信后，就可以进入真正的推理部署阶段。本文的实战目标有两个：
- 用两台 DGX Spark 部署一个 70B 级别的量化模型，开启张量并行（Tensor Parallelism），验证双机推理效果。
- 讨论 200B 级别模型在双机 256GB 统一内存下的部署可能性与注意事项。
说明：以下示例以 vLLM 为主要推理框架，因为它对多机多卡支持较成熟，并且提供 OpenAI 兼容的 API 服务。实际使用时，可以根据模型格式和版本选择 SGLang、TGI 等框架，思路是相通的。
5.2 建立 Ray 集群
vLLM 多机推理通常通过 Ray 集群协调跨节点资源。先在一台设备上启动 Ray head 节点，然后在另一台设备上加入集群。
# 在设备 A（主节点）启动 Ray head ray start --head --port=6379看到 Ray 启动成功的日志后，在设备 B 上执行加入命令：
# 在设备 B 加入设备 A 管理的集群 ray start --address=192.168.100.10:6379使用ray status可以确认两台设备是否都已加入集群。如果能看到两个节点，并且每个节点都贡献了 GPU 资源，说明 Ray 集群就绪。
Linux 命令补充：
# 查看 Ray 集群状态 ray status5.3 用 vLLM 启动双机张量并行推理
假设 70B 模型权重已经存放在每台设备的本地磁盘路径/data/models/qwen-70b-awq下（实际路径请替换为你自己的模型目录），在设备 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 集群中有两个节点，vLLM 会自动跨节点调度。--max-model-len 8192：限制最大上下文长度，避免 KV Cache 占用过多内存。--api-key local-test：为 API 设置访问密钥，仅用于本地测试环境。
如果你的 vLLM 版本较老，不支持vllm serve子命令，可以使用python -m vllm.entrypoints.openai.api_server启动，参数完全一致。
不同版本的 vLLM 在多机调度的细节上有差异，较新版本会自动识别 Ray 集群，老版本可能需要额外指定--distributed-executor-backend ray。遇到问题先看启动日志，根据日志提示调整即可。
5.4 发送推理请求验证
服务启动后，通过 curl 发送一个聊天补全请求：
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 统一内存可以比较从容地加载，还能剩余一部分空间给 KV Cache；第二，当模型权重超过单机内存容量时，--tensor-parallel-size 2几乎是必须的配置，尽量避免单机强行加载导致内存溢出。
6. 聚焦：两台 DGX Spark 张量并行 70B 模型的单并发吞吐估算
6.1 为什么单并发吞吐主要受内存带宽限制
很多人在双机部署 70B 模型后，最关心的就是单并发输出速度：到底每秒能生成多少 token？回答这个问题之前，先要理解大模型推理的性能瓶颈。
在 decode 阶段（也就是逐 token 生成阶段），模型需要把全部权重从内存中读取一遍，参与每一轮计算。相比计算量，权重读取对内存带宽的需求更为突出。换句话说，单并发推理的极限速度，很大程度上取决于“在多长时间内把模型权重完整读一遍”。
6.2 理论估算方法
假设一个 70B 模型以 4bit 量化保存，权重总量大约为 35GB。如果单台 DGX Spark 的统一内存带宽在 250GB/s 量级（具体数值请以官方规格表为准），那么单机每生成一个 token，理论最低耗时约为：
35GB / 250GB/s ≈ 0.14 秒换算成吞吐，就是大约 7 token/s 的上限。这只是一个纯读取权重的理论值，实际还会叠加计算开销、KV Cache 访问、框架调度等，所以真实值通常低于这个数字。
6.3 双机张量并行的理论收益
使用张量并行、把模型切分到两台设备时，每台设备只需要读取自己负责的那一半权重。
每台设备读取量：35GB / 2 = 17.5GB 理想读取耗时：17.5GB / 250GB/s ≈ 0.07 秒如果不考虑通信开销，双机单并发吞吐可以达到约 14 token/s。但这个理想值无法完全实现，因为每次前向计算都需要通过集群网络同步中间结果。假设每一次通信需要 20 到 40 毫秒，那么实际耗时就在 0.09 到 0.11 秒之间，对应的吞吐大约在 9 到 11 token/s。
所以，双机张量并行对单并发吞吐的提升，通常不是严格的 2 倍，而是接近 1.3 到 1.8 倍，具体取决于互联带宽、模型量化精度和框架实现。
6.4 如何实测真实吞吐
理论估算只能帮你做容量规划，真实环境必须依赖实测。vLLM 启动后，直接向 API 发送多次请求，统计生成 token 总数和总耗时即可。
# 使用 curl 请求 10 次，统计总耗时，然后计算平均 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": "写一段关于人工智能发展的短文"}], "max_tokens": 512 }' | jq -r '.usage.completion_tokens' done通过多次请求取平均值，可以得到相对稳定的单并发吞吐数据。测试时要注意预热：前几次请求可能包含权重加载、CUDA kernel 初始化等额外耗时，正式统计时先发几个请求预热再开始计时，结果更有参考价值。
总的来说，如果你在网上看到有人提到“两台 DGX Spark 张量并行跑 70B 模型，单并发输出大约在 8 到 15 token/s”，这个量级是符合内存带宽模型的。实际数字会因为量化位宽、上下文长度、模型架构、框架版本和网络质量的不同而变化，不必纠结于某个具体数字。
7. 常见问题与排查思路
7.1 高频问题与处理对照表
双机互联和分布式推理涉及网络、系统驱动、运行时、框架四个层面，任何一层出现问题都可能导致集群不可用。下面以表格形式梳理高频问题，方便快速定位。
| 问题现象 | 常见原因 | 排查与解决思路 |
|---|---|---|
| 两台设备互相 ping 不通 | 线缆未插好、接口选错、IP 冲突 | 检查线缆与接口，确认 IP 是否在同一网段，关闭无关网卡 |
| SSH 连接失败 | sshd 未启动、防火墙拦截、密钥权限错误 | 检查 sshd 服务状态，放通 22 端口，修复密钥目录权限 |
| NCCL 初始化超时 | /etc/hosts 未配置、防火墙拦截通信端口、master 地址不可达 | 补齐 hosts，放通分布式通信端口，用NCCL_DEBUG=INFO查看日志 |
| 分布式测试耗时异常高 | 实际走了以太网回环或降速链路 | 用ethtool检查网卡速率，用iperf3验证带宽 |
| vLLM 启动时找不到足够的 GPU | Ray 集群未正确加入，或--tensor-parallel-size大于实际可用 GPU | ray status确认节点数，检查CUDA_VISIBLE_DEVICES环境变量 |
| 推理时显存/内存不足 | 模型权重太大、KV Cache 过大、并发请求过多 | 降低--max-model-len，减少并发数，换更低量化位宽 |
| 双机推理反而比单机慢 | 通信开销过大、网络带宽不足、量化后 GPU 计算占比变高 | 检查网络带宽，考虑使用流水线并行替代张量并行，或减少并行度 |
7.2 NCCL 调试日志的使用方法
当 NCCL 通信出现异常时，最有效的排查方式就是打开调试日志。
# 在启动 torchrun 或 vllm 前设置环境变量 export NCCL_DEBUG=INFO # 如果需要更多细节，可以设置为 TRACE # export NCCL_DEBUG=TRACE日志中会显示 NCCL 选择了哪个网络接口、连接了哪个 IP、在哪一步超时。看到类似NET/IB的日志，表示 NCCL 尝试使用 InfiniBand 或 RoCE 设备；看到NET/Socket则说明当前使用的是传统 TCP Socket。生产环境排错时，先明确这条信息能帮你快速判断问题出在物理链路还是协议配置上。
7.3 防火墙与端口放通建议
分布式训练与推理需要放通多类端口。这里整理一份常见端口清单，具体端口号可能因框架版本不同而变化，请以实际配置为准。
| 服务 | 默认端口 | 说明 |
|---|---|---|
| SSH | 22 | 远程登录 |
| Ray Head | 6379 | 集群协调 |
| vLLM API | 8000 | OpenAI 兼容接口 |
| torchrun 主节点 | 29500 | PyTorch 分布式协调 |
| NCCL 动态端口 | 随机高端口 | 建议先NCCL_DEBUG=INFO看实际端口 |
在两台设备互相通信时，优先保证这些端口在集群内部网段可以访问。如果公司网络存在安全组或防火墙，务必在测试环境中先验证规则，再上生产。
8. 最佳实践与工程建议
8.1 网络与拓扑层面的建议
双机互联的稳定性直接决定分布式推理的上限。建议把集群组网独立到专用网段，不要与办公网络共用广播域。固定 IP 之后，务必写入/etc/hosts，避免依赖 DHCP 分配产生地址漂移。
如果业务对延迟敏感，优先考虑直连拓扑，减少交换机转发跳数。如果使用交换机，确保交换机端口速率与网卡匹配，不要出现千兆网口接万兆网卡导致降速的问题。有条件的话，建议开启对称巨型帧支持（Jumbo Frame），但需要同时确认交换机、网卡和驱动都支持，并保持两端 MTU 一致，否则反而会引发分片问题。
8.2 模型与数据管理建议
多机推理时，模型权重建议直接放在每台设备的本地 NVMe 存储中。虽然通过 NFS 共享权重看起来很省事，但训练或推理启动时会并发读取大量文件，NFS 很容易成为瓶颈。如果必须使用共享存储，可以考虑只在启动阶段复制权重到本地，推理过程中不要依赖共享存储。
另外，建议建立规范的模型目录结构。例如统一使用/data/models/<模型名>-<量化精度>的形式，并在启动脚本中通过环境变量传入模型路径，避免在多台设备上路径不一致导致服务启动失败。
# 推荐在启动脚本中显式定义环境变量 export MODEL_PATH=/data/models/qwen-70b-awq export TENSOR_PARALLEL_SIZE=2 export API_KEY=local-test统一变量管理，减少手动改命令导致的低级错误。
8.3 监控与日志管理
双机集群的运维复杂度高于单机。建议至少配置以下监控项：
- GPU 利用率与温度：
nvidia-smi dmon - 统一内存使用率：
nvidia-smi中的 Memory-Usage - 网络吞吐：
iperf3或nload - 推理服务日志：vLLM 的访问日志与错误日志
可以使用 systemd 管理推理服务，保证服务异常退出时能自动重启。日志输出到文件后，配合logrotate做轮转，避免日志文件无限增长占满磁盘。
8.4 安全与运维边界
涉及生产环境的多机集群变更，务必遵循最低权限原则。日常维护使用普通用户，只有安装软件和修改系统配置时才使用 sudo。SSH 登录建议全部改为密钥认证，并禁止密码登录。
推理服务不要直接暴露到公网。如果业务需要远程访问，通过企业内部网络或安全网关转发，并在网关层做访问控制和审计。模型权重和训练数据属于敏感资产，建议定期备份，备份文件加密存储。
9. 总结与下一步
本文完整梳理了使用 NVIDIA Sync 连接两台 DGX Spark 的整个流程。从概念层面看，NVIDIA Sync 不是单一命令，而是物理连接、网络配置、分布式运行时和应用框架四个层次的协同。从操作层面看，固定 IP、SSH 免密、NCCL 验证、Ray 集群、vLLM 张量并行是五个关键步骤，每一步都有对应的验证方法和常见问题。
如果你刚开始接触双机部署，建议按照下面几步继续深入：先用 7B 或 13B 规模的模型跑通全流程，确认 NCCL 通信正常；再切换到 70B 量化模型，实测张量并行下的单并发吞吐；最后再挑战 200B 级别模型，并结合多并发压测观察集群的吞吐上限。每一步都记录实际数据和日志，遇到问题及时对照官方文档和社区资料。
双机部署最大的价值不是简单地把算力翻倍，而是让你在本地环境中提前积累分布式推理的工程经验。把 70B 模型跑通之后，你已经基本掌握了多机协同的核心链路，后续扩展到 4 台、8 台设备时，本质上只是在重复“组网 → 验证 → 启动服务 → 监控调优”这套流程。
如果本文对你有帮助，可以收藏备用。后续我也会持续关注 DGX Spark 相关的性能调优和部署实践，欢迎一起
