这次我们来看一个非常具体的问题如何把两台 NVIDIA DGX Spark 连接起来跑本地大模型推理。DGX Spark 发布之后很多人关心两件事单台 128GB 统一内存能不能本地跑 200B 参数级别的大模型以及如果一台不够用能不能两台并联跑 400B 甚至更大的模型。答案是可以连但连接方式不是“插一根线就完事”。这里必须先澄清一个容易误导的概念在 DGX Spark 双机场景下大家常说的“NVIDIA Sync”并不是一个能单独下载的软件包而是指两台机器在分布式推理时用到的同步与通信机制它由网络层、NCCL 集合通信库、Ray 和 PyTorch 分布式框架共同完成。所以这篇文章不会只讲概念而是直接给你一套可落地的双机 DGX Spark 部署路线环境准备、网络配置、NCCL 通信验证、vLLM 双机张量并行推理、OpenAI 兼容 API 调用、批量任务设计、性能观察和常见问题排查。阅读这篇教程之前先明确一下 DGX Spark 的定位它是一台面向个人开发者的 ARM 架构 AI 超级计算机采用 NVIDIA Grace Blackwell GB10 超级芯片拥有 128GB 统一内存官方宣传可以本地运行 200B 参数级别的大模型适合放在桌面或实验环境。但它的机器间互联是 10GbE 网络级别不能等同于数据中心里多卡 DGX 的 NVLink 互联。因此两台 DGX Spark 并联后能不能跑得快、跑得稳关键不在硬件插拔而在网络、分布式通信库和推理框架的配置。1. 核心能力速览能力项说明设备定位个人级 AI 超级计算机官方定位桌面与开发环境芯片方案NVIDIA Grace Blackwell GB10 超级芯片公开资料为 20 核 Arm CPU 与 Blackwell GPU 集成统一内存128GB LPDDR5x官方宣传可运行约 200B 参数级模型单机模型能力适合运行 70B 级别量化模型200B 级别需视量化和上下文长度而定双机互联网络10GbE 以太网部分资料提到内置 ConnectX-7 智能网卡具体以官方最新规格为准“NVIDIA Sync”定位不是独立软件包而是双机通信与同步机制的总称由 NCCL、Ray、分布式框架实现双机推理方案vLLM 张量并行通过 Ray 集群调度两个 GPU接口能力支持 OpenAI 兼容 API可用于 HTTP 调用批量任务可以基于 API 做批量请求、失败重试、结果落盘适合场景本地大模型开发验证、模型并行测试、私有数据推理不适合场景高并发生产服务、低延迟跨节点训练、本机 NVLink 级互联替代方案以上能力来自公开规格和常见部署实现。显存占用、token 生成速度、网络吞吐这些指标必须在你自己的两台机器上实测不能只看宣传数字。2. 适用场景与使用边界2.1 适合谁使用这套双机方案最适合三类用户第一类是本地大模型研究者。例如想在私有机房或办公室跑 200B 以上参数模型但不希望数据上传到外部 API。DGX Spark 单机有 128GB 统一内存两台并联后统一内存总量可达到 256GB能给更大模型提供加载空间。第二类是分布式推理开发者。你需要验证张量并行、流水线并行、Ray 集群、模型并行切分策略可以在两台 DGX Spark 上做小规模验证再迁移到更大的数据中心环境。第三类是内容生产或科研团队。数据敏感、需要本地部署同时又希望提供一个 OpenAI 兼容 API 给内部工具调用两台 DGX Spark 并联比单机更灵活。2.2 能解决什么问题单机内存放不下大模型时把不同层或不同张量分布到两台机器上。同一份模型需要服务更多并发测试请求双机可以提供更多计算资源。想验证多机训练或推理的工程链路包括网络调优、NCCL 通信、容器化部署。2.3 不适合什么场景生产级高并发服务10GbE 网络在跨节点通信时延迟较高不适合大量并发推理请求。超低延迟交互张量并行中每层都需要跨机同步网络延迟会直接影响首 token 时延。高带宽训练如果训练任务需要频繁 AllReduce10GbE 会成为瓶颈不如 InfiniBand 或 NVLink 集群。无网络工程基础的用户双机互联需要配置静态 IP、主机名、NCCL 和 Ray不是“双击启动”的应用。2.4 合规与安全边界本地部署大模型时必须注意三点模型权重镜像的许可证是否允许商用输入数据是否包含个人隐私或敏感信息如果后续涉及人脸、声音、身份证件等素材必须有明确授权。DGX Spark 是通用计算设备能力本身没有争议但使用场景必须合法合规不能在未授权的情况下对他人数据做识别、生成或分析。3. 环境准备与前置条件3.1 硬件准备开始之前你需要准备以下硬件两台 DGX Spark系统能正常进入桌面或命令行。一台支持 10GbE 的交换机或者一根 10GbE 直连网线。交换机方案更稳定方便后续扩展更多机器。稳定的电源。DGX Spark 虽然比传统 DGX 小但仍是高功耗设备长时间训练或推理需要可靠供电。足够的磁盘空间。大模型权重通常是几十 GB 到几百 GB建议准备高速 NVMe 或外部 USB4 存储。3.2 软件栈机器系统默认是 DGX OS基于 Ubuntu自带 NVIDIA 驱动和容器工具。建议提前确认以下软件状态NVIDIA 驱动和nvidia-smi能正常输出。NVIDIA Container Toolkit 已安装用于运行 GPU 容器。Docker 可用并且能识别 GPU。Python 3.10 或更高版本。后续容器内会使用 vLLM、Ray、PyTorch。3.3 网络拓扑规划最典型的双机拓扑是两台 DGX Spark 都连接到同一台 10GbE 交换机配置同一个网段的静态 IP。假设规划如下主机名IP 地址角色dgx-sync-1192.168.1.11Ray head 节点vLLM 服务主节点dgx-sync-2192.168.1.12Ray worker 节点vLLM 辅助 GPU 节点这里的主机名和 IP 只是示例实际网络请按现场环境规划。如果双机直连需要手动配置网卡 IP并且没有交换机作为中间层后续扩展不灵活不推荐作为长期方案。4. 初始化配置与双机互联4.1 首次启动与基础检查两台 DGX Spark 首次开机后先完成系统账号创建和网络连接。打开终端确认系统能识别 GPUnvidia-smi如果输出中包含 Blackwell 架构 GPU说明驱动正常。再确认网卡ip link不同设备的网卡名称可能不同常见命名是enp开头实际以输出为准。4.2 配置主机名与静态 IP分别在两台机器上设置主机名方便分布式通信识别节点sudo hostnamectl set-hostname dgx-sync-1另一台执行sudo hostnamectl set-hostname dgx-sync-2然后编辑/etc/hosts让两台机器能通过主机名互相访问。以dgx-sync-1为例sudo tee /etc/hosts /dev/null EOF 127.0.0.1 localhost 192.168.1.11 dgx-sync-1 192.168.1.12 dgx-sync-2 EOF静态 IP 的配置因系统版本而异可以使用nmtui或编辑 netplan 配置。配置完成后重启网络或重启机器。4.3 测试连通性与网络带宽从dgx-sync-1pingdgx-sync-2ping -c 5 dgx-sync-2能收到回包说明二层网络通了。接着用iperf3测试实际带宽在dgx-sync-2上启动 iperf3 服务端iperf3 -s在dgx-sync-1上跑客户端测试iperf3 -c dgx-sync-2 -t 3010GbE 网络的理想带宽是 10Gbps但实际 TCP 吞吐会受网卡、交换机和协议栈影响。记住这个数字后续判断 NCCL 通信性能时有用。4.4 理解“NVIDIA Sync”在双机中的作用很多人第一次看到“NVIDIA Sync 连接两台 DGX Spark”时会误以为这是一个和驱动一样需要安装的软件。实际上在双机 DGX Spark 场景中你需要构建的是三层同步能力层级组件作用网络层TCP/IP、10GbE、可能的 RoCE/RDMA提供基础数据传输通道集合通信层NCCL提供 AllReduce、AllGather、Broadcast 等 GPU 间通信原语应用编排层Ray、PyTorch Distributed、vLLM决定模型如何切分、任务如何调度、节点如何发现把这套机制统称为“NVIDIA Sync”本质上就是让两个 GPU 能在模型并行时保持状态一致。理解这一点后你就不会浪费时间去找不存在的安装包而是把精力放在 NCCL 配置和分布式框架上。5. 部署分布式推理环境5.1 安装 NVIDIA Container Toolkit如果系统中没有 NVIDIA Container Toolkit需要先安装sudo apt update sudo apt install -y nvidia-container-toolkit sudo systemctl restart docker然后验证 Docker 能否识别 GPUdocker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果容器内能输出 GPU 信息说明 GPU 容器环境正常。DGX Spark 是 ARM 架构镜像需要选择支持 arm64 的版本下载前先确认镜像是否存在对应架构。5.2 拉取模型与推理镜像模型建议预先下载到本地避免运行 vLLM 时再花时间下载。使用 Hugging Face CLI 下载模型时在项目根目录执行pip install -U huggingface_hub[cli] hf download Qwen/Qwen2.5-72B-Instruct --local-dir /models/Qwen2.5-72B-Instruct这里使用 72B 模型作为示例。70B 级别模型在单台 128GB 机器上可以量化运行双机并联后加载空间更充足但实际能否加载还要看量化格式和上下文长度。vLLM 官方镜像支持多平台时可以直接使用docker pull vllm/vllm-openai:latest如果镜像不兼容当前平台需要从源码编译这会增加不少时间建议优先使用官方预编译镜像。5.3 启动 Ray 集群vLLM 做跨节点张量并行时通常依赖 Ray 来调度 GPU。在dgx-sync-1上启动 Ray headray start --head --port6379在dgx-sync-2上加入集群ray start --address192.168.1.11:6379启动成功后在任一节点执行ray status应该能看到两个节点和两个 CPU worker。Ray 的 GPU 数量需要能被 vLLM 正确识别如果显示 0 张 GPU需要检查容器是否添加了--gpus all参数或 Ray 是否使用了正确的资源配置。5.4 启动 vLLM 双机张量并行推理在 Ray 集群正常的前提下在dgx-sync-1节点启动 vLLM 服务vllm serve /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9--tensor-parallel-size 2表示把模型张量切分到两个 GPU 上。因为两台 DGX Spark 各有一个逻辑 GPU所以这里的 TP size 就是双机并联。如果模型是量化格式需要把权重文件和参数正确传给 vLLM例如vllm serve /models/Qwen2.5-72B-Instruct-AWQ \ --quantization awq \ --tensor-parallel-size 2 \ --distributed-executor-backend ray启动后观察日志等待显示Uvicorn running on http://0.0.0.0:8000说明服务已开始提供推理接口。6. 功能测试与效果验证6.1 单机基线测试双机并联之前先测试单机推理能力。在dgx-sync-1上启动一个 TP size 为 1 的 vLLM 服务请求一次 70B 模型记录首 token 延迟和生成速度作为后续双机对比的基线。测试请求示例import requests import time url http://127.0.0.1:8000/v1/chat/completions payload { model: /models/Qwen2.5-72B-Instruct, messages: [{role: user, content: 用一句话介绍 DGX Spark}], max_tokens: 128, temperature: 0.7 } start time.time() resp requests.post(url, jsonpayload, timeout300) elapsed time.time() - start data resp.json() output_tokens data[usage][completion_tokens] print(f耗时: {elapsed:.2f}s) print(f生成 token 数: {output_tokens}) print(f平均速度: {output_tokens / elapsed:.2f} token/s)这个脚本也可以用于双机测试。将服务地址改成两台 DGX Spark 中启动 vLLM 的地址即可。6.2 NCCL 双机通信测试vLLM 双机张量并行是否稳定很大程度取决于 NCCL 能不能在两张 GPU 之间完成集合通信。建议在容器里跑一遍 NCCL 测试。先拉取 nccl-tests 源码并编译git clone https://github.com/NVIDIA/nccl-tests.git cd nccl-tests make MPI1编译前需要安装 OpenMPIsudo apt install -y openmpi-bin libopenmpi-dev然后双机跑 AllReduce 性能测试mpirun --allow-run-as-root \ --host dgx-sync-1,dgx-sync-2 \ -n 2 \ ./build/all_reduce_perf -b 8 -e 128M -f 2如果 NCCL 能完成不同 message size 的 AllReduce说明双机 GPU 通信链路正常。如果报超时需要检查防火墙、IP 配置和 NCCL 环境变量。6.3 70B 模型双机推理测试双机并联后优先测试长上下文和较长输出因为跨节点张量并行在长序列下通信更频繁更能暴露问题。测试建议输入 2000 token 左右的文本要求模型输出 512 token。连续请求 10 次观察是否出现nccl timeout或请求失败。检查两台机器的 GPU 利用率和显存分配是否均匀。记录单次请求的端到端耗时和生成 token 数。关于“两台 DGX Spark 张量并行 70B 模型单并发输出多少 token”这个问题不能直接从网上抄结论。每个模型的量化格式、上下文长度、vLLM 版本、网络质量都会影响最终数值。正确做法是复用上面的 Python 脚本在双机环境下跑至少 5 次去掉最高最低值取平均值。6.4 API 接口测试vLLM 启动后默认提供 OpenAI 兼容接口可以直接用 curl 验证curl http://192.168.1.11:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen2.5-72B-Instruct, messages: [{role: user, content: 你好请介绍一下你自己}], max_tokens: 256 }返回 JSON 中包含choices、usage等字段说明接口正常。该接口可被 LangChain、FastAPI 或其他内部工具直接调用。6.5 token 吞吐测算方法更准确的吞吐测算是通过usage字段计算单请求生成速度 completion_tokens / 完整请求耗时 端到端吞吐 所有请求的 completion_tokens 总和 / 总耗时批量场景还需要统计prompt_tokens以便评估输入侧和输出侧的实际负载。建议把每次请求的prompt_tokens、completion_tokens、耗时、首 token 延迟写日志后续方便做性能分析。7. 接口 API 与批量任务7.1 OpenAI 兼容接口vLLM 的 API 地址格式为http://服务节点IP:8000/v1/chat/completions对于支持聊天补全的模型直接使用 messages 结构。对于纯补全模型可以使用/v1/completions接口。7.2 Python 批量调用示例批量任务的关键是控制并发度避免同时发送大量请求导致 NCCL 超时或显存 OOM。下面是一个带重试和并发限制的示例import json import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed API_URL http://192.168.1.11:8000/v1/chat/completions MODEL /models/Qwen2.5-72B-Instruct def call_once(prompt: str, max_tokens: int 512, timeout: int 300): payload { model: MODEL, messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: 0.7, } last_exc None for attempt in range(3): try: resp requests.post(API_URL, jsonpayload, timeouttimeout) resp.raise_for_status() data resp.json() return { prompt: prompt, output: data[choices][0][message][content], usage: data[usage], } except Exception as exc: last_exc exc time.sleep(2 * (attempt 1)) return {prompt: prompt, error: str(last_exc)} def run_batch(prompts, max_workers2): results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: futures {executor.submit(call_once, p): p for p in prompts} for future in as_completed(futures): results.append(future.result()) return results if __name__ __main__: prompts [ 写一段 Python 快排代码, 解释什么是 NCCL, 列出三种减少大模型显存占用的方法, ] results run_batch(prompts, max_workers2) with open(batch_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(batch results saved)这个脚本做了三件事限制并发数、失败重试、结果落盘。批量任务建议先使用max_workers1测试一条数据确认接口稳定后再逐步加大并发。7.3 批量任务设计建议将待处理文本保存在inputs.jsonl中一行一个请求。输出写入outputs.jsonl保留原始输入和 usage 信息。并发量从 1 开始递增观察 GPU 利用率和网络带宽不要一开始就压满。增加超时和重试机制单条请求失败不应中断整个队列。对结果做人工抽检防止模型生成内容跑偏。8. 资源占用与性能观察8.1 显存与内存监控DGX Spark 是统一内存架构但nvidia-smi仍然可以观察 GPU 侧的活动。使用如下命令可以持续监控nvidia-smi dmon -c 30该命令每秒输出一行 GPU 利用率、显存读写和温度信息。如果设备不支持 dmon可以定时执行watch -n 1 nvidia-smi双机张量并行时两台机器的 GPU 显存分配应该大致均衡。如果出现一台占用 90% 而另一台只有 20%说明模型切分或设备识别有问题。8.2 网络吞吐监控跨节点推理中网络是最大的变量。在节点上统计 10GbE 网卡吞吐ip -s link show enp1s0f0np0也可以用bmon或nload等工具实时查看。重点关注推理请求期间的平均吞吐。如果网络吞吐长时间跑满说明跨机通信量过大可能需要调整模型并行策略或使用量化模型。8.3 跨节点性能瓶颈双机 DGX Spark 使用 10GbE 网络互联和机器内 NVLink-C2C 的延迟、带宽差距很大。跨节点张量并行时每一次 Transformer 层的前向传播都可能涉及张量切分后的 AllReduce 同步。序列越长通信量越大性能下降越明显。从实践角度看可能出现的现象有单机跑 70B 模型的速度反而比双机更快因为单机不需要网络同步。长上下文请求下双机吞吐明显下降。小 batch 请求时通信开销占比高性能不升反降。这不是配置错误而是网络拓扑和通信模式的物理限制。分布式训练和推理的性能需要结合具体任务评估。8.4 性能优化手段使用 AWQ、GPTQ 等量化模型减少每层传输的字节数。降低max-model-len避免过长的 KV Cache 占用和跨机同步。优先使用更高效的 decode 策略减少无效 token。在 vLLM 中调整gpu-memory-utilization留出系统缓存余量。如果通信成为瓶颈考虑把跨节点方案从张量并行改成流水线并行按层切分模型减少每层间的 AllReduce但这需要推理框架支持。确保网卡驱动和固件更新到官方推荐版本避免 TCP 卸载和中断处理异常。9. 常见问题与排查方法问题现象可能原因排查方式解决方案ping不通IP 配置错误或网络接口未启用检查ip a和/etc/hosts重新配置静态 IP重启网卡vLLM 启动后一直等待 GPURay 没有发现dgx-sync-2的 GPU执行ray status查看节点和资源重新加入 Ray 集群确认容器支持--gpus allNCCL AllReduce 超时防火墙屏蔽端口或 NCCL 无法使用预期协议查看 NCCL 日志临时关闭防火墙测试放行 Ray、NCCL 和 vLLM 所需端口模型加载 OOM未使用量化模型或上下文过长查看日志中的显存分配报告换量化模型降低max-model-len请求返回 500模型路径错误或分布式 worker 崩溃查看 vLLM 日志和 Ray 日志检查模型目录权限重启 Ray 和 vLLM两台机器显存占用不均衡TP 切分异常或有 worker 未启动nvidia-smi对比两机显存重启 Ray确认两个 GPU 都被 vLLM 调度iperf3 带宽很低网线、交换机或驱动问题尝试不同网口和交换机端口更换网线更新网卡驱动Python 调用 API 超时请求过长跨节点通信慢缩短max_tokens观察服务日志增加请求超时时间降低并发Docker 无法拉取 arm64 镜像镜像平台不匹配查看镜像 manifest使用支持 arm64 的镜像或源码编译排查时先看服务日志再看网络日志最后看 GPU 状态。不要一上来就改一堆参数先能复现问题再逐项排除。10. 最佳实践与使用建议第一次搭建双机 DGX Spark建议严格按以下顺序执行单机跑通 vLLM 和模型加载。双机配置好主机名、静态 IP、/etc/hosts。用iperf3确认网络带宽。用 NCCL tests 确认 GPU 间通信。启动 Ray 集群并确认节点资源。最后启动 vLLM 双机推理。这套顺序能最大程度减少变量。如果直接跳过前几步就并行启动出问题时很难判断是网络、NCCL、Ray 还是模型路径的问题。模型文件、日志和脚本建议分目录管理/models/ 模型权重 /workspace/logs 推理日志 /workspace/results 批量输出结果 /workspace/scripts 启动脚本和批量脚本双机环境中模型文件路径必须保持完全一致否则 vLLM 在不同节点上找不到权重。如果使用外部存储最好让两台机器挂载同一个模型目录权限保持一致。对于接口服务无论内网还是外网都建议限制访问范围。vLLM 默认绑定0.0.0.0在没有认证的情况下任意能访问该 IP 的设备都能调用模型接口。可以通过防火墙限制端口访问或者只绑定内网 IP。生产环境还需要加 API 网关或认证层。批量任务必须有日志和失败重试。遇到网络抖动导致单条请求失败时不要直接丢弃要把输入和错误信息记录下来稍后重新提交。发布或商用前对模型输出做人工复核尤其是面向外部用户的内容。如果涉及人脸、声音、隐私数据必须确认数据来源合法并获得必要授权。大模型本身只是工具不能成为未经授权采集或处理个人数据的理由。11. 总结与后续方向两台 DGX Spark 并联是可行的但要用对方法。先理解“NVIDIA Sync”在双机场景下不是独立软件而是网络层、NCCL、Ray 和推理框架共同构成的同步链路再用 NCCL tests 验证 GPU 通信最后通过 vLLM 的 tensor parallel 参数把两张 GPU 组织起来服务同一个模型。整个过程最值得验证的是两个点第一NCCL 双机通信是否稳定第二70B 模型在双机环境下的真实 token 吞吐。最容易踩的坑有三个一是把双机连接想得太简单忽略网络配置和防火墙二是不先做单机基线出问题后无法定位三是盲目使用高并发导致跨节点通信直接打满 10GbE 带宽。后续如果想把双机能力用到更大规模可以继续探索流水线并行、DeepSpeed ZeRO、多节点微调和多机数据并行等方向。每一类方案对网络的要求不同性能表现也会完全不同。建议先把这套双机环境保存为一套可复现的部署脚本后续任何实验都可以快速拉起环境。这篇文章值得收藏。按照上面的流程先跑通单机再验证双机通信最后测一轮并发你就能得到属于自己环境的真实结论。