两台 DGX Spark、一根高速线缆，再加一个量化模型，看起来就能搭出一台本地 DeepSeek 服务器。真正动手时，麻烦通常集中在三个地方：权重能否装下、推理框架能否执行、两台机器能否高效通信。
这三个条件缺一不可。网络连通，不代表分布式推理已经成立；模型文件小于总内存，也不代表加载后不会 OOM。
原始素材中的部署思路值得参考，但有几处需要先纠正：双机内存不会自动合并，284B 模型的 FP16 权重也不止 284GB。另外，素材没有给出可核验的 DeepSeek V4 Flash 模型仓库、量化版本和镜像标签，因此本文不把这些版本信息及性能数字当作已经验证的事实。硬件初始化和网络配置可以按步骤推进，模型部署则必须以实际仓库和框架支持情况为准。
一、先算清模型能不能装下
DGX Spark 的吸引力很明确：GB10 平台提供 128GB 统一内存，适合在桌面设备上尝试较大的量化模型。
不过，统一内存有两层含义需要区分。
单台设备上，CPU 和 GPU 共享物理内存，减少了独立显存容量带来的限制。两台设备连接后，各自仍然拥有自己的内存和地址空间。模型需要由推理框架切分，通过网络交换中间结果。
两台 128GB 设备提供的是两份可用于分布式部署的内存资源，不是一块透明的 256GB 显存。
假设目标模型确实有 284B 参数，仅按参数数量估算权重存储：
| 权重精度 | 理论权重体积 | 未计入的部分 |
|---|---|---|
| FP16/BF16 | 约 568GB | 缓存、运行时、临时张量 |
| 8-bit | 约 284GB | 量化元数据及未量化层 |
| 4-bit | 约 142GB | 缩放因子、混合精度层等 |
| 2-bit | 约 71GB | 编码开销、混合精度层等 |
这里使用十进制 GB。实际文件大小取决于量化格式，不能用理论值直接替代下载页面上的体积。
MoE 模型还容易带来另一个误解：激活参数少，是否意味着只需要存储这些参数？
通常不成立。每个 token 只调用部分专家，能够减少计算量；但后续 token 可能路由到其他专家，因此常见部署仍需保存全部专家权重。专家卸载可以改变内存占用，却会引入额外的数据搬运和延迟。
我的建议是：先确认权重格式和运行时开销，再讨论双机性能。 如果这一步算不清，后面的网络调优很容易变成无效劳动。
二、硬件准备要分清两张网络
双机部署最好把管理网络和计算网络分开。
管理网络用于 SSH、下载模型和访问 API。高速直连网络用于节点间通信。两者可以同时存在，但承担的任务不同。
建议准备：
| 项目 | 数量 | 用途 |
|---|---|---|
| DGX Spark | 2 台 | 分布式推理节点 |
| 兼容的高速直连线缆 | 按官方方案 | 连接高速网卡端口 |
| 普通网线 | 2 根 | 接入管理局域网 |
| 显示器、键鼠 | 1 套 | 按设备指南完成本地初始化 |
| 原装电源 | 2 套 | 供电 |
| 可用存储空间 | 两台分别检查 | 权重、镜像、缓存和日志 |
线缆不要只按 QSFP 外形购买。需要核对设备支持的接口类型、线缆型号、链路模式和固件要求。
原素材中"QSFP28 只有 50Gbps"的说法不准确。QSFP28 常见于 100GbE，实际链路速度取决于端口和双方支持的模式；线缆上的标称速率，也不保证设备会以同样速率建立连接。是否随双机套装附带线缆，应以具体销售配置为准。
还有一个不太显眼的约束：模型通常需要在两台节点上都能被正确读取。 除非部署方案明确使用共享存储，否则不能只在主节点下载权重，就默认工作节点也能访问。
三、单机初始化先把基础状态查清
两台设备分别完成首次设置，包括用户账号、主机名、管理网络和系统更新。具体开机与远程初始化方式，以对应设备版本的官方指南为准。
建议主机名使用 spark-1 和 spark-2，避免日志里两个节点看起来完全一样。
初始化后，在两台机器上分别执行：
# 检查系统架构，Spark平台应为ARM64/aarch64
uname -m
# 检查GPU及驱动状态
nvidia-smi
# 检查内存和磁盘余量
free -h
df -h
# 查看网卡名称和地址
ip -br link
ip -br addr
# 若已安装RDMA相关工具，检查RDMA设备与网卡的对应关系
ibdev2netdev
ibdev2netdev 中的 Up 状态说明对应链路已起来，但不能据此判断 RoCE、NCCL 和模型通信都正常。
记录两台机器的驱动、系统版本和后续容器镜像。分布式环境最怕一台更新了，另一台没更新，最后把版本问题误判成网络问题。
统一内存也意味着系统进程、CPU 工作负载和 GPU 推理共享资源。部署前应关闭不必要的应用，不要把 128GB 全部当成模型预算。
四、双机互联从固定地址开始
连接兼容线缆后，先确认实际处于 Up 状态的高速接口。两台设备上的接口名不一定相同，不能照抄截图里的名称。
下面给出固定地址的配置示例。它适用于两台设备直连、目标接口未被其他配置管理的情况。执行前先检查 /etc/netplan/ 中已有配置；如果系统工具已经配置了这条链路，不要再叠加一份。
在 Spark 1 上执行：
# 必须替换为本机实际连接线缆的接口名
IFACE="enp1s0f1np1"
# 确认接口存在
ip link show "$IFACE"
# 创建仅用于直连链路的配置，不设置默认网关
sudo tee /etc/netplan/90-spark-direct.yaml >/dev/null <<EOF
network:
version: 2
ethernets:
${IFACE}:
dhcp4: false
dhcp6: false
addresses:
- 192.168.100.10/24
EOF
sudo chmod 600 /etc/netplan/90-spark-direct.yaml
sudo netplan generate
# 使用可回滚方式试用配置，确认正常后再接受
sudo netplan try
Spark 2 使用本机接口名，并把地址改成：
addresses:
- 192.168.100.11/24
这个网段必须与现有局域网、VPN 和容器网络错开。直连接口不设置默认网关，避免模型下载和管理流量被错误导向另一台机器。
在 Spark 1 上验证：
# 检查访问对端时是否经过直连接口
ip route get 192.168.100.11
# 检查基本连通性
ping -c 4 192.168.100.11
# 检查接口实际协商速率，替换为本机接口名
sudo ethtool enp1s0f1np1
SSH免密只解决进程启动
如果部署方案需要主节点远程启动工作进程，可以配置 SSH 公钥认证。
在 Spark 1 上执行：
# 若已有合适密钥，可跳过生成步骤；不要覆盖已有密钥
ssh-keygen -t ed25519 -f ~/.ssh/spark_cluster
# 将sparkuser替换为Spark 2上的真实用户名
ssh-copy-id -i ~/.ssh/spark_cluster.pub \
sparkuser@192.168.100.11
# 验证公钥认证，禁止回退到密码交互
ssh -i ~/.ssh/spark_cluster \
-o BatchMode=yes \
sparkuser@192.168.100.11 hostname
首次连接时应核对主机指纹。是否需要反向免密登录，取决于启动器，不必默认把两台机器配置成完全互信。
如果使用 NVIDIA 提供的集群配置工具，应检查当前版本文档的适用范围。自动配置网络可以减少手工错误，但不会自动解决模型格式、推理框架和量化内核的兼容性。
五、ping通之后还要验证通信路径
网络测试需要分层，不能一步跳到"集群已就绪"。
| 验证层级 | 要确认的内容 | 常用工具 |
|---|---|---|
| 物理链路 | 端口是否连通、协商速率是否正确 | ethtool |
| IP网络 | 地址、路由和基础通信是否正确 | ip、ping |
| TCP吞吐 | 普通网络传输是否存在明显瓶颈 | iperf3 |
| RDMA通信 | RoCE路径是否可用 | RDMA测试工具 |
| GPU集合通信 | NCCL是否使用预期网络路径 | nccl-tests |
原素材把 200Gbps 换算成约 25GB/s，这个单位换算没问题。但不能要求 NCCL all-reduce 的结果必须达到 25GB/s。
链路标称速率、有效传输吞吐、NCCL 输出的 algbw 和 busbw，衡量的内容不同。消息大小、集合通信算法、协议开销和 GPU 数据路径都会影响结果。
带宽偏低时，应检查：
- NCCL 是否退回 TCP Socket，而未使用预期的 RDMA 路径；
- 是否选中了管理网卡；
- 容器是否能够访问所需的 GPU、RDMA 设备和库；
- 两端 MTU、驱动及相关软件版本是否一致；
- 测试消息是否太小，导致延迟主导结果。
只有几 GB/s 并不能直接证明 Netplan 接口名写错。直接反复修改地址，可能把原本正常的管理连接也改坏。
六、模型部署先过兼容性检查
到这里，两台机器具备了协同运行的基础条件。接下来才是模型部署。
对于素材中提到的 DeepSeek V4 Flash，需要补齐以下信息，才能写出可信的完整启动命令：
| 必须确认的信息 | 为什么需要 |
|---|---|
| 官方模型仓库和版本 | 确认架构、参数规模、配置及许可证 |
| 量化仓库和具体格式 | 确认实际权重体积和加载方式 |
| 推理框架版本 | 确认支持该模型架构 |
| 容器标签或镜像摘要 | 确保环境可复现 |
| GB10量化内核支持 | ARM64镜像可运行，不等于GPU算子可执行 |
| 双机启动方案 | 确认使用Ray、其他启动器或框架原生多节点机制 |
| 分片方式 | 确认权重和专家如何分布到两个节点 |
尤其需要注意：2-bit 专家量化、NVFP4 和泛称的 FP4，不是可以随意互换的格式。 某个模型能被一个后端加载，不代表 vLLM 也能直接读取。
容器兼容性同样有两层：
- CPU 侧需要匹配 ARM64；
- GPU 侧需要匹配 GB10、驱动、CUDA 和对应算子实现。
原素材没有给出完整镜像名称及版本，因此不能据此确认所谓"专用镜像"具备哪些优化。
部署顺序建议收敛为三步：
- 使用目标容器运行一个明确支持的小模型，验证 GPU 执行路径。
- 运行双节点通信或小模型分布式测试，验证启动器和通信后端。
- 加载目标量化模型，以短上下文、低并发启动，再逐步增加负载。
--tensor-parallel-size 2 只是并行度设置的一部分。它不会自动发现另一台机器，也不会自动完成工作进程启动和权重分发。
对于 MoE，还可能涉及专家并行。是否使用、如何组合，要看模型与推理框架的具体实现，不能只凭参数规模决定。
七、双机的收益要用实际请求验证
双机确实增加了可用资源，但也增加了通信。
张量并行会拆分部分矩阵计算，并在层间交换数据。如果单台已经能装下模型，且主要服务单用户、低并发请求，跨节点通信开销可能抵消第二台设备带来的收益。
| 部署方式 | 更适合的目标 | 主要代价 |
|---|---|---|
| 单机量化推理 | 个人使用、低并发、简化维护 | 容量与精度受限 |
| 双机张量并行 | 模型需要分片，或测试确认有收益 | 通信开销和运维复杂度 |
| 双机各跑一份模型 | 模型单机可容纳，希望提高总吞吐 | 无法扩大单实例模型容量 |
我的选型倾向是：能单机稳定承载的低并发场景，先用单机；确实需要更大模型或更高吞吐，再验证双机方案。
服务启动后，可以通过 OpenAI 兼容接口进行最小验证。以下示例要求模型已被服务命名为 local-deepseek，且 API 监听在本机 8000 端口：
# 检查服务实际暴露的模型名称
curl -fsS http://127.0.0.1:8000/v1/models
# 发送一次短请求；model需与服务返回的模型名称一致
curl -fsS http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "local-deepseek",
"messages": [
{
"role": "user",
"content": "用三句话解释统一内存的作用。"
}
],
"max_tokens": 128,
"temperature": 0.2
}'
正常 JSON 只证明这次请求成功。还应确认输出合理、两台节点实际参与计算，并测试连续请求与长上下文。
性能记录至少包含四项：
- 首 token 延迟；
- 单请求生成速度；
- 多请求总吞吐；
- 峰值内存与失败率。
不要只截取一个 token/s 数字。模型版本、量化格式、输入长度、输出长度和并发数不同，结果很难直接比较。
八、调优从内存预算开始
DGX Spark 的内存带宽会影响推理性能，但不同阶段的瓶颈不一样。长输入的预填充更依赖计算和算子效率，低批量逐 token 解码更容易受权重读取带宽影响；双机还要考虑通信等待。
因此，不宜直接套用"换一种量化就提升多少倍"的结论。
出现 OOM 时，也要先看发生在哪个阶段：
| OOM阶段 | 优先检查 |
|---|---|
| 加载权重 | 权重体积、分片是否生效、加载时的临时副本 |
| 初始化缓存 | 最大上下文、并发数、缓存预算 |
| 运行请求 | 实际上下文增长、批处理规模、其他进程占用 |
降低 --gpu-memory-utilization 可能缩小 KV Cache 预算，缓解部分情况；如果权重本身装不下，它解决不了容量问题。
前缀缓存适合重复系统提示词、固定模板等场景，需要请求确实共享可复用的前缀。它也会消耗缓存空间，不能保证所有多轮对话都从分钟级缩短到秒级。
投机解码则需要草稿模型或模型特定机制，以及后端支持。接受率低时，额外计算甚至可能拖慢请求。素材中的 DSpark 支持情况和速度数字，没有对应版本与测试条件，不宜作为部署承诺。
下载模型时，优先使用可信来源并记录 revision。若使用第三方镜像，应核对文件完整性，避免把访问令牌发送到不可信站点。涉及 trust_remote_code 的模型，还需要审查仓库代码。
API 和集群控制端口也不要直接暴露到公网。管理网络中的访问控制、认证和防火墙配置，应与模型服务一起完成。
两台 DGX Spark 部署本地 DeepSeek，合理的验收顺序是：硬件状态正常、直连网络正常、GPU 通信正常、目标模型可加载、实际请求满足需求。每一步都有自己的证据，不能用前一步成功代替后一步验证。
可以从 NVIDIA 的 DGX Spark Playbooks 查找对应硬件和软件版本的实践，再与目标模型仓库、推理框架文档交叉核对。真正值得保留的部署记录，应包括模型 revision、镜像摘要、网络配置、完整启动命令和测试条件。
桌面设备跑大模型的价值很实在：数据留在本地，开发环境可控，也便于实验。但两台机器是否值得，最终要看它们有没有在你的上下文长度、并发规模和延迟要求下，带来可测量的收益。