企业官网建设流程全解析

最近 NVIDIA DGX Spark 的热度一直很高，很多人把它看作“桌面上跑大模型”的终极设备。不过单机归单机，真正让我觉得有意思的，是 Alex Ziskind 那个 8 台 DGX Spark 组集群的实验。8 台机器通过高速网络互联，变成一个可以承载超大模型的本地推理集群，这件事从纸面上看很有吸引力，但实际搭起来到底要做什么、会遇到哪些坑，大部分资料都没有讲透。

本文就从“组 8 台 DGX Spark 集群”这个场景出发，拆解集群的硬件基础、架构设计、软件选型、完整部署流程，以及大家最关心的几个问题：8 台机器到底能跑多大的模型？多机并行后性能是否能线性扩展？如果有一天你想在自己的机房或者实验室复现类似方案，应该重点关注哪些环节？

1. 背景：当桌面级 AI 超算开始组队

1.1 为什么 DGX Spark 能成为讨论焦点

DGX Spark 是 NVIDIA 面向 AI 开发者推出的紧凑型 AI 超级计算机，它解决的痛点是“本地跑大模型，不想完全依赖云端 API”。

它的硬件基础是 Grace Blackwell 架构的超级芯片，CPU 和 GPU 通过片内高速互联集成在一起，并配备了 128GB 级别的统一内存。对大模型开发来说，统一内存的吸引力非常大，因为显存和内存之间不需要频繁拷贝数据，大模型参数可以直接放进这个统一内存池里。相比传统 CPU+独立 GPU 的架构，它在跑大模型的场景下更省心，也更省功耗。

很多开发者在拿到机器第一天的感受是：单台 DGX Spark 已经能比较流畅地跑 70B 级别的量化模型，也能做一定程度的微调和 RAG 实验。这已经颠覆了以往“大模型必须上服务器”的认知。

1.2 单机虽有惊喜，但物理边界也很明显

单机能够跑到什么程度，取决于内存容量和芯片算力。虽然 128GB 统一内存在桌面级设备里已经算很大，但模型参数一旦超过 100B，单机就会变得吃力；如果还要开长上下文、大批量并发推理，内存带宽又会成为瓶颈。

更关键的是，单机无法解决多用户共享问题。团队里如果有多个人同时要跑模型，一台机器很快就排队；如果要做集群容错，单机更是无从谈起。于是很自然的思路是：把多台 DGX Spark 连起来，组成一个小型 AI 集群。

1.3 组集群的意义是什么

组 8 台 DGX Spark 集群，核心目标有三点：

• 扩大模型容量：单机放不下的模型，通过多节点张量并行切分到不同机器上。
• 提升吞吐：多节点并行可以为多个请求同时提供服务，适合团队集中使用。
• 资源调度：通过 Kubernetes 等调度平台统一管理 GPU、内存、存储，实现按需分配。

Alex Ziskind 那个实验，本质上就是把 8 台单机能力合并成一个逻辑上的“大 GPU”，再在这块大 GPU 上运行更大规模的模型。这也是为什么这个话题能让集群工程师和 AI 工程师同时感兴趣的原因。

2. 从单机到 8 机：集群的核心能力评估

2.1 单机规格与定位

在讲集群之前，先明确单机的定位。根据 DGX Spark 公开的硬件规格，它的核心配置大致如下：

• 芯片：Grace Blackwell 超级芯片，CPU 与 GPU 通过 NVLink-C2C 互联。
• 统一内存：128GB 级别，可被 CPU 和 GPU 共同访问。
• 算力：FP4 精度下达到 1000 TFLOPS 级别。
• 网络：板载高速网络接口，支持 RDMA 能力，适合多机互联。

这样的配置决定了它适合作为“小规模模型推理节点”或者“集群中的一个计算单元”。需要注意的是，DGX Spark 并不是一台传统意义上的 GPU 服务器，它更强调低功耗、低噪音和易部署，所以多台机器之间需要通过高速以太网或 InfiniBand 类网络互联来提高通信效率。

2.2 单机承载模型的上限判断

判断一台机器能跑多大模型，最简单的方法是看参数占用的内存：

模型内存占用 ≈ 参数量 × 每个参数的字节数

• 70B 模型，FP16 精度下大约需要 140GB，单机 128GB 放不下。
• 70B 模型，INT4/FP4 量化后大约需要 35GB 到 40GB，单机可以放下。
• 200B 模型，INT4 量化后大约需要 100GB 到 110GB，单机很紧张，需要集群。

这个估算方式同样适用于集群场景。多台机器组成集群后，模型参数可以按层切分或者按张量维度切分到多台机器上，这样单机内存压力就会大幅降低。

2.3 集群扩展的收益与挑战

理想情况下，8 台 DGX Spark 集群能够提供的总内存接近 8 × 128GB，也就是 1TB 级别。这意味着从容量上看，跑 200B 甚至更大规模的量化模型是有可能的。

但集群不是简单的“内存相加”，还有两个关键挑战：

• 通信带宽：多节点并行推理时，每层计算都可能需要跨节点同步中间结果，网络带宽和延迟直接决定扩展效率。
• 调度与容错：节点多了，任何一台机器出现故障都会影响整体服务，必须引入调度平台做健康检查和自动重启。

所以在组集群之前，先要把网络和调度这两件事想清楚。

3. 8 台 DGX Spark 集群的整体架构

3.1 网络拓扑设计

集群组网是所有环节里最优先的一件事。8 台 DGX Spark 建议采用两层架构：

• 计算网络：用于 GPU 之间 NCCL 通信，要求高带宽、低延迟，建议使用支持 RDMA 的高速交换机。
• 管理网络：用于 Kubernetes API、SSH、监控数据，可以使用普通千兆或万兆交换机。

计算网络和管理网络必须分离。如果让 NCCL 通信和管理流量跑在同一张网卡上，模型并行训练或推理时很容易出现网络拥塞，表现为 NCCL 超时、训练速度骤降。

具体拓扑可以用下面这个简化图来理解：

[ DGX Spark 01 ] \ [ DGX Spark 02 ] \ [ DGX Spark 03 ] |--- 高速交换机（RDMA） --- 计算网络 [ DGX Spark 04 ] / [ DGX Spark 05 ] / [ DGX Spark 06 ] / [ DGX Spark 07 ] \ [ DGX Spark 08 ] \--- 管理交换机 --- 跳板机/管理节点

如果你的交换机不支持 RDMA 或 RoCE，NCCL 会退化为 TCP 通信，性能会明显下降。所以在采购设备时，一定要确认交换机和网卡是否支持 RoCE v2 或 InfiniBand。

3.2 共享存储设计

大模型集群通常需要一个共享存储，用来存放模型权重、数据集和日志。最简单的方案是 NFS，把一台机器作为存储服务端，其他机器作为客户端挂载。

NFS 的优点是实现简单、兼容性好，缺点是性能一般。如果只是存放模型文件和代码，NFS 完全够用。如果训练时要频繁读取数据集，建议把数据放在本地 NVMe 盘上，或者使用并行文件系统（如 Lustre、BeeGFS、GPFS）。对于 8 台 DGX Spark 这个规模，我的建议是先上 NFS，遇到 I/O 瓶颈再考虑替换。

3.3 软件栈选型

集群软件栈是整个方案中最复杂也最容易踩坑的部分。参考目前主流的 AI 集群方案，推荐如下组合：

• 操作系统：每台 DGX Spark 已经预装 DGX OS（基于 Ubuntu 定制），这一层基本不用折腾。
• 容器运行时： containerd 或 Docker。
• 调度平台： Kubernetes。
• GPU 资源接入： NVIDIA Device Plugin，让 Kubernetes 能够感知 GPU 资源。
• 监控： DCGM Exporter + Prometheus + Grafana。
• 存储： NFS，通过 Kubernetes NFS Subdir External Provisioner 动态创建 PVC。
• 推理框架： vLLM 或 TensorRT-LLM。

其中 Kubernetes 负责最上层的资源调度，这一层选得是否合理，直接影响后续使用体验。对于没有现成 K8s 运维经验的同学，也可以先用 Docker Compose 做小规模集群，但一旦涉及 8 台机器和多个用户，还是建议一步到位使用 Kubernetes。

4. 集群搭建实战：从拆箱到调度

4.1 环境准备

在开始动手前，先确认以下信息：

• 8 台 DGX Spark 已经完成系统启动，网络端口正常。
• 每台机器的主机名、IP 地址规划清楚。
• 已配置 SSH 免密登录，至少从管理节点可以免密登录到所有计算节点。
• 确保 8 台机器的时间同步一致。

下面的示例以 8 台机器为例，假设主机名为node01到node08，其中node01同时作为管理节点和存储服务端。

4.2 基础网络配置

DGX OS 使用 Netplan 管理网络。以node01为例，假设管理网络 IP 为192.168.10.11，计算网络 IP 为10.10.1.11，配置文件内容如下：

# 文件路径：/etc/netplan/01-netcfg.yaml network: version: 2 ethernets: eth0: dhcp4: no addresses: - 192.168.10.11/24 routes: - to: default via: 192.168.10.1 nameservers: addresses: - 192.168.10.1 eth1: dhcp4: no addresses: - 10.10.1.11/24

配置完成后执行：

sudo netplan apply

将其他节点按同样的方式配置，计算网络 IP 依次为10.10.1.12到10.10.1.18。配置完成后，从node01测试所有节点连通性：

for i in {12..18}; do ping -c 1 10.10.1.$i > /dev/null && echo "node0$((i-10)) OK"; done

4.3 部署 NFS 共享存储

在node01上安装 NFS 服务端：

sudo apt update sudo apt install -y nfs-kernel-server sudo mkdir -p /data/nfs/models /data/nfs/datasets /data/nfs/logs

编辑/etc/exports：

# 文件路径：/etc/exports /data/nfs 10.10.1.0/24(rw,sync,no_root_squash,no_subtree_check)

重启服务并验证：

sudo exportfs -ra sudo systemctl restart nfs-kernel-server

在node02到node08上安装 NFS 客户端并挂载：

sudo apt install -y nfs-common sudo mkdir -p /data/nfs sudo mount -t nfs 10.10.1.11:/data/nfs /data/nfs

为了重启后自动挂载，把下面这行写入/etc/fstab：

10.10.1.11:/data/nfs /data/nfs nfs defaults,_netdev,nofail 0 0

4.4 部署 Kubernetes 集群

这里选择 kubeadm 方式搭建。首先在所有节点上执行初始化操作，安装常用依赖并关闭交换分区。这里给出核心命令序列，版本以你实际安装时的最新稳定版为准。

# 在所有节点执行 cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter sudo swapoff -a sudo sed -i '/ swap / s/^/#/' /etc/fstab sudo apt install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl

在管理节点初始化集群：

sudo kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=192.168.10.11

初始化成功后，按照命令行提示配置kubectl：

mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

而后将其他节点加入集群，加入命令在初始化成功后命令行会直接给出，形如：

sudo kubeadm join 192.168.10.11:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

之后安装 CNI 网络插件，这里以 Flannel 为例：

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

4.5 接入 NVIDIA GPU

Kubernetes 默认不能感知 DGX Spark 上的加速器，需要安装 NVIDIA Device Plugin。

先确认每台节点都安装了 NVIDIA Container Toolkit，然后创建 Device Plugin DaemonSet。以下是一个精简版配置：

# 文件路径：nvidia-device-plugin.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: tolerations: - operator: Exists effect: NoSchedule priorityClassName: system-node-critical containers: - name: nvidia-device-plugin-ctr image: nvcr.io/nvidia/k8s-device-plugin:v0.16.1 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins - name: gpu mountPath: /dev/gpu volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: gpu hostPath: path: /dev/gpu

部署完成后查看节点状态：

kubectl get nodes kubectl describe node node01 | grep -A5 "Capacity"

正常情况下，Capacity中会列出nvidia.com/gpu资源，数量为 1，代表该节点有 1 个可调度的加速器单元。

4.6 验证集群调度能力

创建一个测试 Pod，确认 GPU 资源可以被调度：

# 文件路径：gpu-test-pod.yaml apiVersion: v1 kind: Pod metadata: name: gpu-test spec: containers: - name: cuda-container image: nvcr.io/nvidia/cuda:12.4.1-base-ubuntu22.04 command: ["nvidia-smi"] resources: limits: nvidia.com/gpu: 1

运行命令：

kubectl apply -f gpu-test-pod.yaml kubectl logs gpu-test

如果日志能正常输出 NVIDIA 显卡信息，说明 Kubernetes 已经能正确调度 GPU 资源。

5. 在集群上部署大模型推理服务

5.1 推理框架选型

集群搭建完成后，下一步就是跑大模型。目前主流的自托管推理框架有 vLLM 和 TensorRT-LLM，两者都支持多节点并行推理。

• vLLM：部署简单，OpenAI 兼容 API 容易对接，四舍五入可以无缝替换 OpenAI 接口。
• TensorRT-LLM：NVIDIA 官方推理框架，针对硬件优化更深入，但配置更复杂，更适合生产环境深度调优。

我的建议是：先上 vLLM 跑通全流程，再根据性能瓶颈决定是否切换到 TensorRT-LLM。

5.2 多节点推理的关键参数

vLLM 多节点推理依赖张量并行（tensor parallel）和流水线并行（pipeline parallel）两个概念。

• 张量并行：把 Transformer 层中的权重切分到多张 GPU 或多台机器上，适合节点间通信带宽较高的场景。
• 流水线并行：把不同层分配到不同 GPU 上，通信压力较小，但存在流水线气泡，利用率偏低。

在 8 台 DGX Spark 组成的集群中，如果模型参数超过 100B，优先使用张量并行。以 vLLM 为例，启动时需要传入--tensor-parallel-size参数，表示把模型切分到多少个推理引擎上。

5.3 用 vLLM 部署一个多节点推理服务

假设我们准备在 8 台节点上运行一个 200B 量级的 INT4 模型。vLLM 多节点部署有两种常见方式：一种是通过同一份启动命令在所有节点上拉起 worker，另一种是借助 Ray 集群。这里给出一种基于 Ray 的部署思路。

先准备一个 workdir 目录，存放模型文件。

sudo mkdir -p /data/nfs/models/mixtral-200b-int4 cd /data/nfs/models/mixtral-200b-int4 # 将模型权重下载到该目录，或通过对象存储同步到该目录

然后创建 Kubernetes Deployment 文件：

# 文件路径：vllm-serve.yaml apiVersion: apps/v1 kind: Deployment metadata: name: vllm-serve namespace: ai spec: replicas: 1 selector: matchLabels: app: vllm-serve template: metadata: labels: app: vllm-serve spec: volumes: - name: models hostPath: path: /data/nfs/models type: Directory nodeSelector: kubernetes.io/hostname: node01 containers: - name: vllm image: vllm/vllm-openai:latest command: ["python3", "-m", "vllm.entrypoints.openai.api_server"] args: - --model=/data/nfs/models/mixtral-200b-int4 - --tensor-parallel-size=1 - --max-model-len=4096 - --gpu-memory-utilization=0.9 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: models mountPath: /data/nfs/models

这个配置里使用了nodeSelector把服务固定到node01上，tensor-parallel-size=1表示先不启用多节点并行。多节点并行时，需要额外配置 Ray head 和 worker，并把--tensor-parallel-size设置为节点数量，同时通过环境变量告诉 vLLM 各节点的 IP 地址。不同版本的 vLLM 配置方式略有差异，部署前务必查看对应版本的官方文档。

5.4 部署完成后如何验证

服务启动后，通过kubectl get svc获取服务地址，然后用 curl 做一次推理测试：

curl http://<node01-ip>:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "mixtral-200b-int4", "messages": [{"role": "user", "content": "用一句话解释什么是集群"}], "max_tokens": 128 }'

如果返回正常的 JSON 响应，说明整个链路已经打通：Kubernetes 调度 -> GPU 容器 -> NFS 模型加载 -> vLLM 推理。

6. 8 台集群的算力分析与模型容量测算

6.1 从内存角度估算可承载模型

以 8 台 DGX Spark 为例，总统一内存约 1TB。但实际可用内存并不会百分之百用于模型参数，操作系统、推理框架、KV Cache 和输入输出缓冲区都要占用内存。保守估计，可用模型内存约为总内存的 70% 到 80%，也就是 700GB 到 800GB。

按 INT4 量化每个参数约 0.5 字节计算：

可承载参数量 ≈ 750GB / 0.5B ≈ 1.5T 参数

也就是说，单从内存容量角度看，8 台集群甚至可以尝试加载超过 1TB 的量化模型。但这里有一个重要前提：多节点并行时，跨节点通信带宽会成为瓶颈，实际吞吐可能会远低于参数规模增加的比例。

6.2 从算力角度估算推理吞吐

很多读者关心“两台 DGX Spark 做张量并行跑 70B 模型，单并发输出多少 token”。严格来说，这个数字受多种因素影响：

• 是否量化、量化精度。
• 输入序列长度和输出长度。
• 张量并行效率，取决于网络带宽和 NVLink 支持情况。
• 推理框架的调度方式，是否开启了 continuous batching。

没有在真实硬件上测试之前，任何具体的 token 数字都是估算。比较稳妥的做法是：先用小模型跑一遍基准测试，记录不同并发下的延迟和吞吐，再推算出目标模型的性能区间。你也可以通过 vLLM 自带的/metrics接口直接监控吞吐数据：

curl http://<node01-ip>:8000/metrics

重点关注vllm:generation_tokens_total和vllm:request_success_total这两个指标的变化趋势。

6.3 8 台机器最合适的定位

从工程角度看，8 台 DGX Spark 组成集群后，更适合做“多模型统一推理平台”，而不是“把一个大模型切到 8 台机器上跑”。原因在于，切分越大，通信成本越高。更合理的做法是：

• 用 1 到 2 台机器跑 70B 级别的量化模型。
• 用 2 到 4 台机器跑 200B 级别的量化模型。
• 剩下的机器可以承担微调任务、开发调试环境、数据处理任务。

这也是 Kubernetes 这类调度平台的价值所在：不同规格的模型服务可以申请不同数量的节点资源，互不干扰。

7. 常见问题与排查思路

7.1 集群部署与推理阶段高频问题

7.2 推荐排查顺序

遇到问题不要一个个试，建议按照下面顺序排查：

1. 先看网络：从每个节点ping其他节点的计算网络 IP，确认延迟和丢包。
2. 再看调度：kubectl describe pod <pod-name>查看事件，关注FailedScheduling的具体原因。
3. 再看日志：kubectl logs <pod-name>查看应用日志，重点是 NCCL 初始化和模型加载阶段。
4. 最后看监控：通过 DCGM Exporter 查看加速卡的温度、功耗和使用率，排除硬件层面的性能问题。

7.3 如何避免类似问题再次出现

在集群上线前，把所有基础环境做成自动化脚本，不要手工逐台配置。尤其是网络配置、NFS 挂载、内核参数、防火墙规则，这些内容一旦不一致，后续排查成本会非常高。

建议在每台机器的/etc/hosts中写入所有节点的主机名映射，并统一使用主机名而不是 IP 地址来访问节点，这样既能提高可读性，也能避免 IP 变化导致的配置混乱。

8. 集群落地的最佳实践与生产建议

8.1 网络：不要省交换机

8 台 DGX Spark 组集群，最值得投入的硬件是高速交换机。如果预算有限，宁可减少一部分存储设备或冗余电源，也要保证计算网络的带宽和稳定性。跨节点推理对网络抖动非常敏感，千兆网络跑小模型还能忍，跑 200B 级别模型基本不可用。

有条件的话，为计算网络单独配置一个网段，并为 NCCL 通信预留隔离的 VLAN 或子网，避免其他业务流量干扰。

8.2 存储：模型目录和日志目录分离

NFS 根目录下分别创建models、datasets、logs三个子目录，并设置不同权限。模型目录一般只读给推理服务，数据集目录只有训练任务可写，日志目录可以允许所有服务写入。这样的好处是方便做权限控制和备份。

对 DGX Spark 这类带有本地高速盘的设备，KV Cache 或临时文件不要存在 NFS 上，一定要指向本地磁盘，否则大批量请求时 NFS 会成为新的瓶颈。

8.3 安全：默认最小权限

DGX Spark 集群如果放在办公室或实验室，要特别注意网络安全。Kubernetes 的 API Server 默认端口是 6443，长时间暴露在办公网中会有被恶意访问的风险。建议通过防火墙限制只有跳板机可以访问管理端口。

涉及微调数据集时，要确认数据来源合法，不要使用未经授权的材料；涉及模型权重下载时，遵循模型许可证要求，不要将受限模型私自对外提供服务。

在集群上执行任何删除操作之前，都要确认对象存储和数据库没有误删风险。对于 NFS 上的模型文件，建议保留一份只读快照或者定期同步到对象存储。

8.4 运维：从第一天就建立监控体系

8 台 DGX Spark 虽然不算大集群，但已经远超手工管理的范围。建议从第一天就部署：

• Prometheus + Grafana：监控节点 CPU、内存、网络、磁盘。
• DCGM Exporter：监控加速卡利用率、显存占用、功耗、温度。
• Kubernetes Dashboard 或 Lens：方便查看工作负载状态。

监控的价值在故障时体现得最明显。没有监控，一台机器过热导致推理变慢，你可能要到用户反馈时才意识到问题。

9. 总结与下一步

8 台 DGX Spark 组成集群，这件事从硬件层面已经具备可行性，剩下更考验人的是网络规划、调度平台选型和推理框架调优。文章里提到的所有方案都围绕一个核心目标：让多台单机变成一个可调度、可扩展、可维护的统一资源池。

如果你打算实际搭建，建议先不要一次性上 8 台。可以先用两台机器，重点解决网络通信和多节点并行推理的问题，确认网络带宽和推理框架的配置思路都清晰之后，再逐步扩容。这样能把踩坑成本控制在最小范围内。

下一步值得关注的技术方向有两个：一是 Kubernetes 与 NVIDIA NIM 的深度集成，二是推理框架本身的分布式优化能力。无论哪种方案，最终都要回归到业务需求上——你的场景是同时跑多个小模型，还是集中资源跑一个大模型？两者的架构取舍完全不同。

动手之前，先把网络和存储方案定下来，再考虑软件层。基础设施稳定了，后面的大模型部署才会顺利。如果这篇文章对你有帮助，可以收藏备用，后续有新的实测结果我也会继续补充。