每个对本地大模型集群感兴趣的人看到“8台 DGX Spark”这种标题都会停下来。DGX Spark 是 NVIDIA 发布的桌面级 Grace Blackwell 开发者套件单台拥有 128GB 统一内存官方定位是“个人 AI 超算”。把 8 台组在一起第一反应自然是能不能本地部署 200B 级大模型能不能通过张量并行把 70B 模型的单并发输出打上去部署和调度是不是比想象中麻烦这篇文章围绕“DGX Spark 集群”这个场景展开。先看单机与多机的能力差异再给出一套可落地的集群部署思路包括网络拓扑、分布式推理、接口 API 和批量任务测试。文章不会堆概念重点回答三件事8 台 DGX Spark 到底能干什么、怎么启动、踩坑之后怎么排查。如果你正在评估 DGX Spark 是否该多买几台或者已经到手但不知道怎么组织成集群这篇可以直接收藏。1. 核心能力速览先看 DGX Spark 单机和 8 台集群的关键指标。以下数据来自 NVIDIA 公开资料与实际部署测试中的常见结论具体数值需以你手上的硬件版本和固件为准。能力项DGX Spark 单机8 台 DGX Spark 集群核心芯片GB10 Grace Blackwell 超级芯片8 x GB10统一内存128GB8 x 128GB合计约 1024GB 可供统一编址AI 算力官方指标FP4 精度下约 1 PFLOPS理论上 8 PFLOPS 级实际受网络与调度限制互联能力内置 ConnectX-7 高速网卡支持高速以太网或 InfiniBand 网络8 节点通过交换机组成高速网络跨节点通信走 RDMA/RoCE操作系统DGX OS基于 Ubuntu每个节点独立 DGX OS可统一纳管启动方式单机即开即用建议 Kubernetes/K3s 或 SLURM 调度也可用 vLLM 分布式推理典型模型规模70B 级量化模型、RAG、Agent 开发200B 级量化模型、多模型并发服务、数据处理流水线API 能力可部署 OpenAI 兼容接口统一入口负载均衡到多节点批量任务单机队列支持集群队列、分布式并行任务适合用户个人开发者、算法工程师企业 AI 团队、高校实验室、私有化部署团队从这张表可以看出DGX Spark 的亮点不在“一块显卡能跑多大”而在“统一内存架构让大模型本地部署的门槛大幅降低”。单台的 128GB 统一内存已经超过绝大多数消费级显卡的显存容量8 台组合后理论上可以承载更大参数规模模型的权重和 KV Cache。但要注意集群不是简单拼接跨节点通信、模型切分、调度策略都会直接影响实际吞吐。2. 适用场景与使用边界DGX Spark 集群最适合三类场景。第一类是本地大模型推理服务。企业数据不能出域但业务需要 70B 甚至 200B 级模型在线服务。DGX Spark 集群可以把模型权重全部放在本地通过 OpenAI 兼容 API 对外提供推理能力。相比租用云端 GPU 实例数据隐私和长期成本更可控。第二类是 AI 应用开发和 Agent 工程。8 台节点可以拆成多个独立环境一台跑代码模型一台跑向量模型一台跑对话模型再用统一网关对外提供服务。团队内部做 AI 应用原型验证时不需要等待云端配额。第三类是分布式训练和批量数据处理。虽然 DGX Spark 的强项是推理但多节点配合分布式数据并行也能做中小规模微调和批量数据标注。特别是文本、图像、语音混合的多模态数据处理可以按节点拆分任务大幅缩短批处理时间。使用边界也要说清楚。DGX Spark 不是万能的它不适合做超大集群的万卡训练也不适合与现有 x86 GPU 服务器混部后直接套用传统 CUDA 优化思路。因为它的 CPU 是 Arm 架构很多在 x86 上编译好的 Python 库和 CUDA 扩展需要重新编译。另外跨节点张量并行会引入通信开销如果网络配置不合理8 台机器的性能可能还不如单台跑小模型。在合规方面本地部署模型和数据处理必须遵守数据来源授权和模型开源协议。涉及人脸、声音、版权素材时必须确认训练数据和推理素材的授权范围。集群部署的访问控制也要做好不要把所有接口暴露在公网。3. DGX Spark 硬件基础与集群拓扑设计硬件决定了集群的上限。DGX Spark 最核心的优势是 GB10 超级芯片它将 Grace CPU 和 Blackwell GPU 集成在一起CPU 与 GPU 共享 128GB 统一内存。传统显卡需要把数据从显存搬到内存再搬回来DGX Spark 则可以直接在统一内存上操作这会让大模型加载和 KV Cache 管理变得更高效。在设计 8 台集群前先明确两个问题网络怎么连、存储怎么组织。3.1 网络拓扑方案8 台 DGX Spark 需要一台支持 RoCE 或 InfiniBand 的高速交换机。最简单的拓扑是星型结构每台 DGX Spark 的 ConnectX-7 网卡接入交换机节点之间通过 RDMA 通信。如果只有两台可以直连测试8 台必须走交换机。拓扑类型优点缺点适用场景星型拓扑布线简单扩展容易交换机是单点故障影响面大8 台以内的小规模集群双交换机冗余高可用单交换机故障可切换成本翻倍配置复杂生产环境、长期稳定服务全互联节点间延迟最低需要大量网线不适用于 8 台以上性能敏感的实验环境IP 地址规划建议单独划分一个管理网段和一个数据网段。管理网段走 SSH、Kubernetes API、监控数据网段走 RDMA、模型并行通信、数据集同步。不要把管理流量和数据流量混在一起否则分布式训练时 ping 值和高带宽传输会互相干扰。3.2 存储方案DGX Spark 自带 NVMe 存储但多节点集群需要一个共享数据目录。最简单的方式是搭建 NFS 服务把模型文件放在一台节点上其他节点通过 NFS 挂载。但 NFS 的并发性能和可靠性一般如果数据集较大建议使用 JuiceFS 或 MinIO 搭建分布式存储。以 JuiceFS 为例它可以把对象存储作为底层在各节点挂载为 POSIX 文件系统。模型文件一旦放在共享存储中所有节点看到的是同一个路径分布式推理框架加载权重时就不需要每台机器单独复制一份模型。# 在存储节点初始化 JuiceFS 文件系统示例 juicefs format --storage minio --bucket http://minio:9000/dgx-models \ --access-key admin --secret-key admin123 \ dgx-meta models-store# 各计算节点挂载 JuiceFS sudo juicefs mount -d --cache-dir /var/jfs/cache \ dgx-meta /mnt/dgx-models注意这里的 MinIO 和对象存储需要你自己准备JuiceFS 只是把模型元数据和数据块托管到对象存储。如果团队规模小直接 NFS 也够用。4. 环境准备与前置条件集群部署前先在每台 DGX Spark 上完成基础环境准备。4.1 系统与驱动DGX Spark 出厂预装 DGX OS基于 Ubuntu。首次开机后先确认系统更新、NVIDIA 驱动和 CUDA 环境。# 查看系统信息 uname -a cat /etc/os-release # 查看 GPU 和网卡 nvidia-smi ibstatus如果nvidia-smi正常输出说明驱动和 CUDA 环境就绪。接着安装 NVIDIA Container Toolkit让 Docker 容器能访问 GPU。# 安装 NVIDIA Container Toolkit以 Ubuntu 为例 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker4.2 Arm 架构的依赖兼容DGX Spark 的 CPU 是 Arm 架构这是最容易忽略的坑。很多在 x86 上预编译的 Python wheel 包在 DGX Spark 上装不了尤其是带有 C/C 扩展的库。建议所有节点使用 conda 或 uv 创建独立环境优先选择aarch64版本的包。# 创建 Python 环境 conda create -n dgx-cluster python3.11 -y conda activate dgx-cluster # 安装 PyTorch 和 vLLM选择 arm64 版本 pip install torch torchvision torchaudio pip install vllm如果安装过程中报Could not find a version that satisfies the requirement大概率是包没有提供 ARM 版本可以去源码仓库找通用的tar.gz包或者用pip install --no-cache-dir强制重新编译。4.3 网络与防火墙检查多节点集群必须保证节点之间网络互通。先检查网卡速率和网络延迟。# 查看网卡信息 ip a ethtool eth0 # 节点之间测试延迟替换 IP ping -c 5 192.168.100.11如果使用了 RDMA还需要确认 RoCE 或 InfiniBand 模式检查ibstat是否正常。集群内部防火墙不要阻止数据端口建议直接关闭或放行内部网段。# 放行内部网段示例按实际网段替换 sudo ufw allow from 192.168.100.0/244.4 SSH 免密登录8 台节点逐一登录非常低效先配置 SSH 免密。# 在管理节点生成密钥 ssh-keygen -t ed25519 -C dgx-cluster # 分发公钥到其他节点 ssh-copy-id user192.168.100.11 ssh-copy-id user192.168.100.12 # 后续节点同理配置完成后管理节点应该能直接 SSH 到任何计算节点这是后续统一部署和监控的基础。5. 集群部署与启动流程环境准备完成后开始部署集群。这里推荐两种方式一种是轻量级方案用 SLURM 做任务调度另一种是 Kubernetes 方案用 K3s 或 KubeSphere 管理容器化服务。GPU 推理服务优先推荐 Kubernetes 方案因为可以结合 GPU 调度、滚动更新和弹性扩容。5.1 部署 K3s 集群K3s 是轻量级 Kubernetes 发行版占用资源少适合边缘和桌面级设备。以一台节点作为 master其他 7 台作为 worker。# 在 master 节点执行 curl -sfL https://get.k3s.io | sh - # 获取加入 token sudo cat /var/lib/rancher/k3s/server/node-token # 在 worker 节点执行 curl -sfL https://get.k3s.io | K3S_URLhttps://192.168.100.10:6443 \ K3S_TOKENmaster-token sh -K3s 装好后在 master 节点确认节点状态。sudo k3s kubectl get nodes5.2 在 Kubernetes 上部署 GPU 推理服务K3s 默认支持 NVIDIA GPU 调度前提是节点上已经安装了 NVIDIA Container Toolkit。创建vllm-deployment.yaml部署 vLLM 服务。apiVersion: apps/v1 kind: Deployment metadata: name: vllm-server namespace: ai spec: replicas: 1 selector: matchLabels: app: vllm-server template: metadata: labels: app: vllm-server spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [vllm, serve, /models/Qwen2.5-70B-Instruct-GPTQ-Int4] args: [--tensor-parallel-size, 1, --max-model-len, 8192] resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: models mountPath: /models env: - name: HF_HOME value: /models volumes: - name: models hostPath: path: /mnt/dgx-models type: Directory --- apiVersion: v1 kind: Service metadata: name: vllm-server namespace: ai spec: selector: app: vllm-server ports: - port: 8000 targetPort: 8000用kubectl apply -f vllm-deployment.yaml创建服务。此时 vLLM 会在单台节点上加载 70B 量化模型。如果模型文件在共享存储中所有节点都能访问。5.3 单台与多台的启动差异单台 DGX Spark 启动 vLLM 比较简单直接指定--tensor-parallel-size 1。但 70B 模型按 BF16 权重约 140GB超过单台 128GB 统一内存所以要么用 4bit 量化要么让 2 台节点联合推理。# 单台节点加载 70B 量化模型 vllm serve /models/Qwen2.5-70B-Instruct-GPTQ-Int4 \ --tensor-parallel-size 1 \ --max-model-len 8192如果追求更高精度需要两台 DGX Spark 组成张量并行。# 两台节点张量并行加载 70B 模型组织示例 vllm serve /models/Qwen2.5-70B-Instruct-AWQ \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --max-model-len 8192注意张量并行对节点间通信带宽非常敏感。DGX Spark 的互联速度虽然比传统千兆网卡快很多但和单机 NVLink 相比仍有差距。70B 模型用 2 节点 TP2 时每层 Transformer 的权重都会切分到两台机器每次前向传播都需要跨节点同步通信延迟会成为吞吐瓶颈。实际能跑到多少 token取决于模型结构、量化方式、序列长度和网络延迟建议部署后先用固定 prompt 压测不要凭感觉判断。6. 功能测试与效果验证集群部署完成后先不要急着接业务按下面的顺序做功能测试。6.1 验证节点间分布式推理用一台管理机向集群中的 vLLM 服务发送请求观察响应。curl http://192.168.100.10:30080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-70b-int4, messages: [{role: user, content: 用一句话解释什么是张量并行}], max_tokens: 256, temperature: 0.7 }如果返回正常的 JSON 结果说明推理链路已通。接着用nvidia-smi或nvtop观察各节点的 GPU 利用率确认负载是否分散到多台机器。# 节点上实时查看 GPU 状态 watch -n 1 nvidia-smi如果所有 GPU 利用率都稳定在某个水平说明分布式推理生效。如果只有一台节点有负载其他节点 GPU 利用率接近 0说明张量并行没有真正跑起来需要检查--tensor-parallel-size参数和节点间的 RDMA 网络。6.2 70B 模型单并发输出测试很多人在意“两台 DGX Spark 张量并行跑 70B 模型单并发输出多少 token”。这个数字没有统一答案它由以下因素共同决定模型结构MHA、GQA、MoE 对 KV Cache 和通信量影响巨大。量化精度INT4、INT8、BF16 的权重体积不同显存和带宽占用不同。输入输出长度max model len 越大KV Cache 占用越多prefill 时间越长。网络延迟TP2 时每层都要跨节点通信网络延迟直接压低 token 吞吐。推理框架vLLM 的 continuous batching 是否生效也会显著影响单并发时延。稳妥的做法是部署完成后用脚本打一次基准。import time import requests url http://192.168.100.10:30080/v1/chat/completions payload { model: qwen-70b-int4, messages: [{role: user, content: 写一篇关于分布式系统的 500 字短文}], max_tokens: 512, temperature: 0.7, stream: False } start time.time() response requests.post(url, jsonpayload, timeout180) elapsed time.time() - start data response.json() tokens data[usage][completion_tokens] print(f输出 tokens: {tokens}) print(f总耗时: {elapsed:.2f} 秒) print(f平均速度: {tokens / elapsed:.2f} tokens/s)运行后记录结果。如果你的网络配置合理2 节点 TP2 跑 70B INT4 模型单并发通常能稳定在一个可用的速度如果速度非常慢优先排查网络是否走了 RoCE、是否开启了巨帧、是否有 CPU 干扰导致通信线程被抢占。6.3 200B 级模型部署测试8 台 DGX Spark 的目标是本地部署 200B 级大模型。以 200B 模型 INT4 量化为例权重约 100 到 120GB分布式切分到 8 台后每台内存压力可以接受。关键是切分策略。推荐使用流水线并行pipeline parallel加张量并行tensor parallel的组合。vLLM 支持--pipeline-parallel-size和--tensor-parallel-size参数。# 8 台节点加载 200B 模型组织示例 vllm serve /models/Qwen2.5-200B-Instruct-GPTQ-Int4 \ --tensor-parallel-size 4 \ --pipeline-parallel-size 2 \ --max-model-len 16384这个配置的含义是4 台节点做张量并行2 组这样的配置串联成流水线。相比单纯 TP8这种混合方式减少跨节点通信的同步次数更契合多机集群的网络特点。但具体 TP 和 PP 的配比需要实测调优建议小规模测试后再全量加载。测试时先输入短文本确认输出正常再逐步增大max_tokens和并发数。如果出现 OOM 或推理超时优先降低max-model-len其次降低并发数。6.4 批量任务测试批量任务考验的是服务稳定性和队列调度。可以用 Python 脚本模拟多用户并发请求。import concurrent.futures import requests import time url http://192.168.100.10:30080/v1/chat/completions def send_prompt(prompt): payload { model: qwen-70b-int4, messages: [{role: user, content: prompt}], max_tokens: 128, temperature: 0.3 } start time.time() response requests.post(url, jsonpayload, timeout60) return time.time() - start prompts [介绍一下人工智能 for _ in range(20)] with concurrent.futures.ThreadPoolExecutor(max_workers10) as executor: futures {executor.submit(send_prompt, p): p for p in prompts} latencies [] for future in concurrent.futures.as_completed(futures): latencies.append(future.result()) print(f平均响应时间: {sum(latencies) / len(latencies):.2f} 秒) print(f最大响应时间: {max(latencies):.2f} 秒)通过这种方式可以快速观察集群在高并发下的表现。如果响应时间随并发数线性恶化需要检查 vLLM 的调度队列适当调整--max-num-seqs或--max-num-batched-tokens。7. 集群调度、接口 API 与批量任务DGX Spark 集群的核心价值之一就是服务化。把 vLLM 接入 Kubernetes 后API 地址就变成一个稳定的服务入口。7.1 OpenAI 兼容 APIvLLM 原生提供 OpenAI 兼容接口路径为/v1/chat/completions。可以像调用 OpenAI 一样调用本地模型服务。from openai import OpenAI client OpenAI( base_urlhttp://192.168.100.10:30080/v1, api_keynot-needed ) response client.chat.completions.create( modelqwen-70b-int4, messages[ {role: system, content: 你是一个技术文档助手。}, {role: user, content: 写一段 FastAPI 的接口示例} ], max_tokens1024 ) print(response.choices[0].message.content)这里的api_key在本地环境通常不校验但如果集群暴露到内网其他部门建议在服务前面加一层 API Gateway 或认证代理不要直接裸奔。7.2 多模型路由8 台 DGX Spark 不一定只跑一个大模型。更常见的用法是一台跑 7B 对话模型做实时聊天两台跑 70B 模型做复杂推理两台跑 Embedding 模型做 RAG剩下一台跑语音识别或其他小模型。Kubernetes 场景下可以每个模型一个 Deployment再通过 Ingress 或网关按路径路由。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ai-models namespace: ai spec: rules: - host: ai.local http: paths: - path: /chat backend: service: name: vllm-server-7b port: number: 8000 - path: /reason backend: service: name: vllm-server-70b port: number: 8000这样外部系统只需要知道一个统一地址内部按业务选择不同模型。7.3 批量任务队列如果业务需要批量处理大量文本比如给一万篇文章生成摘要直接用 HTTP 请求循环调用容易超时。推荐使用任务队列把任务写入 Redis 或数据库由 worker 进程消费并调用 vLLM 接口。import redis import requests import json r redis.Redis(host192.168.100.20, port6379) queue summary_tasks while True: _, task_data r.blpop(queue, timeout0) task json.loads(task_data) response requests.post( http://192.168.100.10:30080/v1/chat/completions, json{ model: qwen-70b-int4, messages: [ {role: user, content: f请为以下文本生成摘要{task[text]}} ], max_tokens: 256 }, timeout120 ) if response.status_code 200: summary response.json()[choices][0][message][content] # 写回数据库或对象存储 print(f任务 {task[id]} 完成) else: # 失败重试写入重试队列 r.rpush(summary_tasks_retry, task_data)批量任务的核心是“失败可重试、进度可追踪”。建议每一条任务都带唯一 ID处理结果写回数据库方便中途断点续跑。8. 资源占用与性能观察方法资源占用是评估 DGX Spark 集群最重要的维度之一。8.1 显存与内存观测DGX Spark 没有独立显存而是统一内存。nvidia-smi中的显存数据对应的是统一内存中 GPU 可访问的部分实际模型推理时 CPU 和 GPU 共享这 128GB。# 实时查看 GPU 使用 watch -n 1 nvidia-smi # 查看内存 free -h当模型加载后如果内存占用接近 128GB说明模型权重加 KV Cache 已经吃满设备内存。此时继续调大并发数系统会开始换页推理速度会急剧下降。8.2 CPU 与 GPU 占用DGX Spark 的 Arm CPU 负责处理数据加载、Token 采样、调度逻辑。如果只盯着 GPU 利用率可能漏掉 CPU 瓶颈。建议同时监控 CPU 负载。htop如果 GPU 利用率不高但 CPU 接近满载优先检查 Token 采样和解码配置或换用更高效的推理框架版本。8.3 网络与存储监控跨节点张量并行和批量数据读取会占用网络带宽存储性能也会影响模型加载速度。# 查看网络流量 iftop -i eth0 # 查看磁盘 IO iostat -x 1如果模型加载非常慢先看存储是不是瓶颈如果推理时 token 速度波动明显再看网络是否有丢包或重传。8.4 如何降低资源占用在资源有限的情况下按以下顺序优化降低max-model-len减少 KV Cache 预留空间。使用 INT4 或 INT8 量化模型减少权重占用的内存。限制并发数避免多任务同时抢占内存和带宽。关闭不必要的后台服务和日志采集释放 CPU 和内存。如果单机推理速度可接受不要强行分布式推理。9. 常见问题与排查方法DGX Spark 集群部署中以下几个问题出现频率最高。问题现象可能原因排查方式解决方案容器启动报错无法访问 GPUNVIDIA Container Toolkit 未安装或驱动不兼容检查nvidia-ctk --version、nvidia-smi重新安装 toolkit确认驱动版本匹配节点间 ping 通但分布式推理不工作RDMA 网络未启用或网段隔离检查ibstatus、rdma link确认数据网段路由正确开启 RoCE/InfiniBand70B 模型无法加载到单台设备模型精度为 BF16内存不够查看free -h和日志中的 OOM 提示改用 INT4/INT8 量化模型或使用多节点 TP请求响应很慢GPU 利用率低CPU 成为瓶颈或网络通信开销大TOP 查看 CPU 占用iftop查看网络减少并发降低max-model-len调整 TP/PP 配比K3s 节点状态 NotReady节点资源不足或 containerd 异常journalctl -u k3s查看日志释放内存重启 worker 节点API 响应超时模型加载时间过长或推理队列堆积查看 vLLM 日志和批处理队列增加超时时间降低 qps或扩容节点分布式推理出现 NaN 或输出乱码模型切分方式不正确或权重文件损坏用单机小模型测试对比输出重新下载模型检查 TP/PP 参数Python 包安装失败包没有 ARM 版本查看 pip 错误信息选择 aarch64 版本或源码编译批量任务卡住任务队列消费异常或 API 请求阻塞查看 worker 进程栈和 Redis 队列长度增加重试机制给请求设置超时和重试模型加载后内存占用 100%量化后权重仍过大或 KV Cache 配置过高用nvidia-smi和free -h确认降低max-model-len或换更小模型排查时永远先看日志。vLLM 的日志、K3s 的kubectl describe pod、系统日志journalctl都会直接指出问题方向不要一上来就怀疑硬件。10. 最佳实践与合规建议把 8 台 DGX Spark 真正用好需要一套工程化实践。10.1 部署最佳实践第一先小后大。第一次不要直接加载 200B 模型先用 7B 模型确认集群通信正常再逐步增加模型规模。每次调整后记录显存占用、token 速度和响应时间形成自己的性能基线。第二模型和数据集统一放共享存储。不要每台节点各放一份否则 8 台机器各下载一次模型浪费带宽和磁盘空间。第三给接口服务加保护。即使是内网服务也要前置认证和速率限制。防止某个业务调用方把集群打满影响其他任务。第四保留一套最小可运行配置。把已经验证过的 Dockerfile、Kubernetes YAML、启动命令固化下来下次初始化新节点时直接复用。10.2 合规与安全建议DGX Spark 集群的本地部署能力很强但越强的能力越要控制边界。部署开源模型时确认模型许可证允许商用或允许在私有环境部署。使用内部数据做 RAG 或微调时确认数据来源合法不包含未授权的个人信息。涉及人脸、声音、肖像等敏感数据时必须获得明确授权并做好访问审计。不要让未认证用户直接访问模型 API尤其是具备代码生成、文档处理能力的模型。集群内 SSH 密钥和 API 密钥要纳入密钥管理不要写死在脚本里。合法授权是本地部署的基本前提尤其是企业环境合规问题比性能问题更容易造成长期风险。11. 总结与下一步8 台 DGX Spark 集群的价值不在于“8 PFLOPS”这个理论数字而在于把 200B 级模型、多模型服务、本地数据安全和批量任务统一到一套可管理的设备上。从实际部署角度看最值得先验证的功能是共享存储挂载、2 台节点张量并行跑 70B 量化模型、OpenAI 兼容 API 是否稳定。这三个点通了再往上扩展 200B 模型和多模型路由才有意义。最容易踩的坑有两个Arm 架构依赖兼容和跨节点通信配置。前者会让环境准备阶段消耗大量时间后者会让分布式推理性能远低于预期。建议先把这两块基础打牢再追求模型规模和并发数量。如果你已经有多台 DGX Spark下一步可以考虑接入完整的 Kubernetes 生态做 GPU 调度、监控告警和自动扩容。或者把 DGX Spark 集群与现有业务系统打通作为内部 AI 能力平台统一对外服务。本地部署这条路DGX Spark 提供了很新的硬件底座剩下的效率提升就看团队怎么组织模型、数据和调度策略了。