8台DGX Spark组本地大模型推理集群：从组网到部署全解析

这次我们来看一个组了 8 台 DGX Spark 的本地 AI 集群方案。先给结论这不是为了跑分好看而是想在一台桌面级 AI 超算不够用、又不想把模型和数据放到云上的情况下把 8 台 DGX Spark 连成一个内网推理集群。这个组合的核心价值是把 70B 到 200B 参数级别的大模型放到本地跑数据不出内网同时还能通过 OpenAI 兼容接口接入团队自己的业务系统。DGX Spark 是 NVIDIA 在 GTC 2025 发布的个人 AI 超级计算机单台内置 GB10 Grace Blackwell 超级芯片配备 128GB 统一内存。官方定位是桌面级设备可以在本地运行最高 200B 参数级别的模型通常需要量化配合。如果单台跑大模型时速度不够、并发不够、显存吃紧那么组 8 台集群的思路就是用多节点的内存和算力把更大的模型放下来或者把并发能力提上去。这篇文章会从实际部署角度拆解8 台 DGX Spark 集群要准备什么、怎么组网、怎么部署推理框架、怎么测试单并发和多并发性能、怎么接批量任务以及最常见的坑。如果你正在评估“本地组一组 DGX Spark 跑大模型”到底值不值这篇可以直接收藏。1. 核心能力速览先列一张表快速判断这个方案适不适合你。以下参数来自 NVIDIA 官方资料和常见部署实践实际表现需要以你拿到的设备版本和软件环境为准。能力项说明项目类型桌面级 AI 超算集群多节点大模型推理单台硬件NVIDIA DGX SparkGB10 Grace Blackwell 芯片128GB 统一内存集群规模本次讨论 8 台聚合内存约 1TB 级别理论值主要用途本地跑 70B~200B 大模型推理、多模型并行、批量推理、私有化 API 服务官方定位本地运行最高 200B 参数模型通常配合量化操作系统出厂自带 DGX OS底层为 Ubuntu 定制版启动方式命令行、容器、推理框架服务是否支持 API支持部署 vLLM/SGLang 等框架后可暴露 OpenAI 兼容接口是否支持批量任务支持可配合脚本、队列或工作流系统网络要求千兆起步集群互联建议更高带宽组网适合场景团队内部推理平台、数据不出内网、高并发推理接入不适合场景大规模训练任务、传统 GPU 渲染、游戏加速这里要注意一个概念DGX Spark 用的是统一内存不是传统意义上的“显存”。你用nvidia-smi看到的内存占用是 CPU 和 GPU 共享的同一块 128GB 内存。正因为有这个统一内存设计单台设备才能放下 70B 甚至更大参数的量化模型。2. 为什么组 8 台 DGX Spark 集群先想清楚一个问题单台 DGX Spark 已经能跑 200B 模型了为什么还要组 8 台核心原因有三个。第一单台能跑和跑得好是两回事。一个 70B 模型在单台设备上可能勉强加载但推理速度很慢单并发输出可能只有每秒几个 token根本没法给业务用。第二实际业务往往需要同时服务多个请求单台的并发能力有限。第三本地部署的价值在于数据不出内网。很多团队有私有化部署需求模型和数据都不能离开公司环境这时候组 8 台集群就是在一台不够用、云上不合适之间找一个中间方案。2.1 适合谁这个方案适合下面几类人算法工程团队需要在本地反复测试大模型效果、评估模型质量又不希望每次调用都走云 API。私有化交付团队客户要求模型部署在内网不能把数据传出机房。教学和科研团队需要一个可控的推理集群环境方便做实验和教学。对数据安全要求高的企业内部工具团队比如做内部知识库、代码助手、文档解析服务。2.2 不适合什么不要把 8 台 DGX Spark 当成“小号训练集群”。DGX Spark 的定位是推理和个人开发不是大规模训练。真要训练一个 70B 模型应该去用云上的 GPU 集群而不是在这里堆 8 台桌面设备。另外它的存储和 CPU 规模也不是为视频渲染、游戏服务器这类场景设计的。如果你需要的是传统 CUDA 计算卡、需要大带宽显存做专业图形渲染DGX Spark 也不是最优选择。2.3 使用边界与合规提醒组集群跑大模型有三条边界必须记住模型授权你下载和部署的开源模型要遵守对应的开源许可证或厂商使用条款商用前必须确认授权范围。数据隐私内网部署不等于可以随意处理敏感数据尤其是涉及个人信息的内容需要遵守相关法律法规和内部数据规范。内容安全如果做的是生成类应用输出内容需要做安全审核和人工复核避免错误内容直接流出。3. 8 台 DGX Spark 集群硬件与网络拓扑组 8 台 DGX Spark不是把 8 台设备往桌上一放、插上网线就能跑。网络拓扑是关键尤其是如果你要用到跨节点张量并行。3.1 硬件清单先列一个最小硬件清单设备数量说明DGX Spark8 台核心算力节点万兆交换机1 台或以上集群内网互联网线/光模块按拓扑数量准备带宽越高越好机架/散热架按机房条件准备8 台桌面设备也需要理线UPS 电源按功率配置多机长时间运行建议保障供电这里说的“万兆交换机”是一个较稳妥的起点。跨节点跑张量并行时节点之间的通信数据量非常大千兆网络会成为严重瓶颈。如果你不确定交换机规格优先选支持更高带宽、低延迟的型号别在网络上省钱。3.2 网络拓扑设计8 台设备的组网最稳妥的是星型拓扑每台 DGX Spark 都接到中心交换机上。节点规模不大不需要复杂的 leaf-spine 架构但有一点要注意不要用两台设备直连的方式代替交换机。跨节点通信需要任意两台机器都能互通交换机能保证这一点。组网完成后的基本信息建议如下# 规划 IP 段示例按实际内网调整 192.168.10.101 dgx-spark-01 192.168.10.102 dgx-spark-02 192.168.10.103 dgx-spark-03 192.168.10.104 dgx-spark-04 192.168.10.105 dgx-spark-05 192.168.10.106 dgx-spark-06 192.168.10.107 dgx-spark-07 192.168.10.108 dgx-spark-08静态 IP 比 DHCP 更省心。配置好 IP 后在所有节点上更新/etc/hosts让每台机器都能通过主机名访问其他节点。这个步骤不做跨节点通信会频繁踩坑。3.3 初始化检查在部署软件之前先在每台设备上做一轮基础检查# 查看系统信息 hostnamectl # 查看 IP 地址 ip addr # 查看 GPU 设备 nvidia-smi # 测试节点间连通性 ping dgx-spark-02重点确认三件事系统版本是否一致、IP 是否互通、nvidia-smi能否正常显示设备。8 台设备如果系统版本不一致后续部署容器和驱动时会出现各种奇怪问题。建议把固件和系统更新到同一版本再开始。4. 软件环境与集群部署硬件就绪后进入软件环节。这里主要做三件事装容器环境、选推理框架、确定集群调度方式。4.1 基础软件环境DGX Spark 出厂自带 DGX OS底层是 Ubuntu 定制版已经预置了 NVIDIA 驱动和 CUDA 环境。你只需要补上容器工具# 检查 Docker docker --version # 安装 NVIDIA Container Toolkit如果未预装 sudo apt-get update sudo apt-get install -y nvidia-container-toolkit # 重启 Docker sudo systemctl restart docker注意如果你的 DGX Spark 出厂系统版本较老建议先通过系统更新工具把驱动和固件更新到最新版本再安装容器工具。驱动版本和容器工具版本不匹配会导致容器内看不到 GPU。4.2 推理框架选择本地集群跑大模型主流的选择有三个框架特点适用场景vLLMOpenAI 兼容接口成熟吞吐高社区活跃生产推理服务、高并发 APISGLang在长文本和复杂推理场景下性能突出复杂 prompt、多样本推理Ollama安装简单适合小模型快速试用本地开发、模型快速验证从搜索结果来看现在大家更关心 vLLM 和 SGLang 这类能真正提供 API 服务的框架而不是单纯的 Ollama 体验。下面以 vLLM 为例演示SGLang 的部署思路类似。4.3 使用 K8s 做集群调度8 台设备如果做生产服务推荐用 Kubernetes 统一调度。基本思路是8 台 DGX Spark 组成一个 K8s 集群用 NVIDIA Device Plugin 让 Pod 可以申请 GPU 资源再用 Deployment 部署推理服务。部署命令大概长这样具体版本按你的集群调整# 初始化集群在控制节点上执行 kubeadm init --pod-network-cidr10.244.0.0/16 # 加入集群在计算节点上执行 kubeadm join 控制节点IP:6443 --token token # 安装 NVIDIA Device Plugin kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yaml这里要提醒一个问题DGX Spark 的“GPU”是统一内存架构K8s 的 Device Plugin 能否正确识别和申请资源取决于你安装的插件版本和 DGX OS 版本。不要假设所有版本的 Device Plugin 都能直接工作先在小范围测试。如果不想上 K8s也可以退一步用 Docker Compose 在每台设备上启动服务配合 Nginx 做负载均衡。这个方案更轻但故障转移和扩缩容能力弱一些。5. 集群推理功能测试与效果验证部署完成后先别急着上大模型。建议按照“小模型验证集群 - 中等模型测性能 - 大模型测稳定”的顺序推进。5.1 第一步小模型验证集群先在一台节点上用一个小模型验证推理链路是否通# 以 vLLM 启动一个较小模型路径按实际模型位置调整 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.85 \ --host 0.0.0.0 \ --port 8000启动日志出现类似Uvicorn running on http://0.0.0.0:8000的信息就说明服务起来了。然后验证接口curl http://127.0.0.1:8000/v1/models如果返回了模型列表说明基础链路正常。这一步不要跳很多跨节点问题都是在小模型测试阶段提前暴露的。5.2 第二步70B 模型单机 vs 双机张量并行做完小模型验证后开始测试用户最关心的问题两台 DGX Spark 张量并行跑 70B 模型单并发输出到底能到多少 token/s。先说结论这个数字没有统一答案它取决于模型量化方式、上下文长度、并发数、网络带宽、推理框架版本等多个因素。网上任何直接给出的“XX token/s”都只能作为参考不能当作你的设备基准。正确的做法是跑一轮可控的测试。先说跨节点张量并行部署以 vLLM 为例核心是配置--tensor-parallel-size参数并保证两个节点都能访问到同一个模型权重目录# 节点一上执行示例具体参数以 vLLM 版本文档为准 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-70B-Instruct \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --host 0.0.0.0 \ --port 8000实际操作中跨节点张量并行还涉及 NCCL 通信配置、共享存储挂载、防火墙放行端口等步骤建议参考 vLLM 官方文档的分布式推理章节。然后写一个简单的单并发测速脚本import time import requests url http://服务IP:8000/v1/chat/completions payload { model: Qwen2.5-70B-Instruct, messages: [ {role: user, content: 用一句话介绍自己。} ], max_tokens: 128, temperature: 0.7 } start time.time() resp requests.post(url, jsonpayload, timeout300) elapsed time.time() - start if resp.status_code 200: data resp.json() content data[choices][0][message][content] completion_tokens data.get(usage, {}).get(completion_tokens, 0) output_speed completion_tokens / elapsed print(f输出内容: {content}) print(f耗时: {elapsed:.2f}s) print(f输出 token 数: {completion_tokens}) print(f单并发输出速度: {output_speed:.2f} token/s) else: print(f请求失败: {resp.status_code} {resp.text})测试参考维度测试项关注点模型加载耗时从启动到 ready 的时间首 token 延迟第一个字出现前等待多久单并发输出速度一个请求下的 token/s多并发表现4、8、16 并发时总吞吐和单请求延迟5.3 第三步200B 模型测试8 台集群的真实价值在 200B 级别模型。这个体量通常需要量化模型配合单台设备可能要利用统一内存才能放下速度不会太快8 台集群则可以通过张量并行把模型分布到更多节点上降低单节点内存压力。测试方法和 70B 一样先部署再跑单并发测速然后逐步增加并发。唯一需要注意的是200B 模型加载时间会很长启动时耐心等不要因为日志长时间没变化就杀掉进程。可以额外监控系统状态# 实时查看统一内存占用 watch -n 1 nvidia-smi # 查看系统内存 free -h128GB 统一内存被模型吃满后继续加并发会导致 OOM 或严重变慢。这是正常现象说明需要进一步调低gpu-memory-utilization或者换更小精度的量化模型。6. 接口 API 与批量任务部署 DGX Spark 集群最终目标一般是给上层业务提供 API 服务。vLLM 启动后默认暴露 OpenAI 兼容接口这意味着你之前写的 OpenAI SDK 代码可以几乎无缝切换过来。6.1 OpenAI 兼容接口调用from openai import OpenAI client OpenAI( base_urlhttp://服务IP:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelQwen2.5-70B-Instruct, messages[ {role: user, content: 写一段关于集群部署的技术总结。} ], max_tokens512, temperature0.7 ) print(response.choices[0].message.content)接口地址直接指向集群的负载均衡入口或任意一台节点 IP 即可。6.2 批量任务脚本批量推理是本地集群最常见的用法。比如要对一批文档生成摘要或对一批文本做分类。核心写法是循环调用接口并加上日志、重试和失败记录import json import time import requests API_URL http://服务IP:8000/v1/chat/completions MODEL_NAME Qwen2.5-70B-Instruct def call_model(text, max_retries3): payload { model: MODEL_NAME, messages: [ {role: user, content: f请对下面内容做摘要\n{text}} ], max_tokens: 256, temperature: 0.3 } for attempt in range(max_retries): try: resp requests.post(API_URL, jsonpayload, timeout120) if resp.status_code 200: return resp.json()[choices][0][message][content] else: print(fHTTP {resp.status_code}: {resp.text}) except Exception as e: print(f请求异常: {e}) time.sleep(2 ** attempt) return None with open(input.jsonl, r, encodingutf-8) as fin, \ open(output.jsonl, w, encodingutf-8) as fout: for line in fin: item json.loads(line) result call_model(item[content]) out { id: item[id], result: result } fout.write(json.dumps(out, ensure_asciiFalse) \n) fout.flush()批量任务有几个经验输入和输出用 JSONL 格式每行一条方便断点续跑。每处理一条就写一次文件不要等全部跑完再写防止中途崩溃丢数据。对失败请求做重试重试次数建议 3 次采用退避策略。批量任务要加并发控制不要让请求把集群打满。6.3 批量任务调度如果批量任务量大建议在脚本外面再套一层任务队列。可以用的方案有方案复杂度适用场景Python 脚本 线程池低百量级任务Celery Redis中千量级任务、定时任务Argo Workflows高K8s 环境下的复杂任务流从 8 台 DGX Spark 集群的定位来看多数场景用脚本 线程池就够了。只有任务量到几千上万条时才需要引入完整任务队列。7. 资源占用与性能观察本地集群部署完成后资源占用观察是日常运维的核心工作。这里说明几个关键观察点和常见优化方向。7.1 观察统一内存占用DGX Spark 使用统一内存传统nvidia-smi的显存数字含义和普通 GPU 服务器不完全一样。建议同时看两个指标# 查看 GPU 相关内存 nvidia-smi # 查看系统内存 free -h模型推理时统一内存占用会体现在这两个命令的输出里。如果free -h显示可用内存快速下降说明模型权重和 KV Cache 正在占用内存。7.2 关注网络吞吐跨节点张量并行时网络是最大的瓶颈。观察网络吞吐可以用# 实时查看网络流量 iftop -i 网卡名 # 查看网卡统计 ip -s link如果模型跑起来后某台节点网卡流量持续打满说明跨节点通信占了主要开销。这时候降低tensor-parallel-size、减少并发或者升级交换机带宽比盲目调其他参数更有效。7.3 降低内存占用的手段内存不够用了按优先级依次尝试手段效果代价降低gpu-memory-utilization减少 KV Cache 占用释放内存给模型加载并发能力下降吞吐降低使用量化模型减少模型权重占用生成质量可能下降缩小max-model-len减少 KV Cache 预留空间不能处理超长文本减少并发数直接降低峰值内存吞吐下降使用张量并行把模型分散到多节点增加网络通信开销7.4 进程管理和端口冲突8 台设备上跑服务最常见的混乱来源是端口冲突和僵尸进程。# 查看 8000 端口占用 lsof -i :8000 # 杀进程 kill -9 PID生产环境建议给每个服务固定端口并把 PID 写入日志文件方便追踪。启动脚本里加一行echo $! /var/run/vllm.pid可以省去很多排查时间。8. 常见问题与排查方法8 台 DGX Spark 组成集群踩坑概率不是单台的 8 倍而是 8 倍加网络问题。下面这张表是我认为最值得提前记住的排查清单问题现象可能原因排查方式解决方案启动后页面/接口打不开服务未启动或端口被占用检查日志、lsof -i :端口更换端口或重启服务模型加载 OOM模型太大或gpu-memory-utilization设置过高查看free -h和nvidia-smi换量化模型或降低内存利用率跨节点张量并行失败节点间网络不通、SSH 未配置、共享存储缺失先 ping 测试再检查共享目录挂载配置好/etc/hosts和免密登录推理速度很慢网络带宽不足或模型量化等级过高iftop查看网络流量升级交换机带宽或减少并行规模并发一提升就 OOMKV Cache 预留不足观察nvidia-smi的内存占用曲线降低并发数、调低gpu-memory-utilization批量任务中途卡住请求超时或模型输出长度超限查看脚本日志和 API 响应增加超时时间、设置max_tokens上限节点间模型版本不一致各节点模型文件同步不完整对比模型目录的哈希值使用共享存储或统一同步脚本容器内看不到 GPU容器工具版本与驱动不匹配nvidia-smi在宿主机执行容器内再试重装对应版本 NVIDIA Container Toolkit这里的核心排查思路是先确认单节点 OK再确认节点间通信 OK最后再看框架配置。不要一上来就调模型参数很多问题出在基础设施上。9. 最佳实践与使用建议8 台 DGX Spark 不是买回来插上电就能高枕无忧的。下面这些实践建议来自本地集群部署的通用经验能帮你少走弯路。9.1 先从最小配置验证第一次部署不要直接上 200B 模型。先用一台设备跑 7B 模型确认 API 能通再用两台设备跑 70B确认张量并行能工作最后才扩展到 8 台。每增加一台设备都做一次连通性检查。9.2 保持一套最小可运行配置把验证通过的模型文件、启动脚本、配置文件单独放一个目录并记录下用的 vLLM 版本、CUDA 版本、容器镜像版本。这样系统出问题后可以快速恢复到可用状态不用从头排查。9.3 目录规范建议目录结构如下/opt/ai-cluster/ ├── models/ # 模型权重文件 ├── config/ # 启动配置和脚本 ├── data/input/ # 批量任务输入 ├── data/output/ # 批量任务输出 ├── logs/ # 服务和任务日志 └── scripts/ # 部署和运维脚本模型、输入、输出、日志分开管理是批量任务不混乱的前提。9.4 批量任务要加失败重试上一节已经给了带重试的示例代码。生产环境建议再加一个“已处理 ID 清单”把成功处理的记录追加到一个文件里失败了可以断点续跑不需要重新处理全部数据。9.5 API 服务要限制访问集群暴露的 API 服务不要直接绑到公网。默认只绑定内网 IP配合防火墙规则限制来源 IP。如果必须对外提供服务前面加一层 API 网关做鉴权和限流。9.6 注意模型授权和数据合规这一条必须反复强调下载模型时看清楚开源许可证商用前确认没有授权风险。处理内部数据时遵守数据分级规范尤其是涉及个人信息的文本和文档。生成类应用上线前必须接入内容安全审核机制。10. 总结与下一步8 台 DGX Spark 组集群这件事最值得尝试的点不是“我有 8 台设备”而是你终于可以在本地内网跑起一个真正能用的推理服务。它把 70B 到 200B 级别的模型变成了团队内部的 API数据不用出网业务系统可以直接接入。如果你也准备组一套建议按这个顺序验证先用一台设备跑通小模型 API再用两台设备测试 70B 张量并行重点观察网络吞吐和内存变化接着用 8 台设备部署 200B 模型跑单并发测速然后逐步加并发。最容易踩的坑是网络带宽不足和跨节点共享存储没配好这两个问题会在你部署大模型时集中爆发。下一步可以尝试的方向有三个一是接入 K8s把 8 台设备变成标准化的推理服务平台二是用 Prometheus Grafana 做集群监控把内存、网络、请求延迟都可视化三是接入任务队列把批量推理流程工程化。先把一台设备跑熟再扩展到 8 台这个路线不会错。