MultimodalFlow
EN
← 返回博客

2×Jetson Thor 跑 DeepSeek-V4-Flash-NVFP4：QSFP28 互联前置测试与真实阻塞点

DeepSeek-V4-FlashNVFP4Jetson ThorQSFP28SGLangvLLM多节点推理边缘推理

上一篇测完 DeepSeek-R1-Distill-Qwen-32B 后，我继续评估更激进的目标：用两台 Jetson Thor 通过 QSFP28 互联，跑 NVIDIA 发布的 nvidia/DeepSeek-V4-Flash-NVFP4。

这次没有直接下载 100GB+ 权重硬冲，而是先做前置验证。结论先放前面：

项目结果
模型nvidia/DeepSeek-V4-Flash-NVFP4
模型规模DeepSeek-V4-Flash：284B total / 13B active；NVIDIA NVFP4 页面标注 167B params
官方验证形态vLLM：GB300，TP=4；SGLang 示例：TP=8
目标硬件2× Jetson Thor
当前状态未进入 V4-Flash 权重下载和启动
阻塞点QSFP28 IP 未在两端配通、thor-jd 空盘不足、Jetson aarch64 上 NVFP4/V4 多节点栈未验证

一句话：2×Thor 跑 V4-Flash-NVFP4 不是完全没希望，但当前环境还没到可以下载权重开跑的阶段。先把 QSFP28 + SGLang 多节点小模型跑通，才值得碰 V4-Flash。

为什么不是直接下载权重

DeepSeek-V4-Flash-NVFP4 不是 30B/70B 级模型。它是 V4-Flash 的 NVIDIA NVFP4 量化版本，面向 Blackwell GPU 做过适配。官方页面强调：

  • NVFP4 量化
  • FP4 indexer cache
  • 支持 SGLang / vLLM
  • validated on Blackwell GPU
  • vLLM 示例使用 GB300 + TP=4
  • SGLang 示例使用多卡 TP=8

这和 Jetson Thor 的部署形态差别很大。Thor 是低功耗边缘 SoC，优势是统一内存、边缘部署和长期在线；V4-Flash-NVFP4 的目标更像多卡数据中心节点。

更现实的问题是：当前两台机器的磁盘和内存余量并不适合贸然下载。

机器空盘可用内存备注
thor约 161GB约 44GB有 SGLang / vLLM NGC 镜像
thor-jd约 73GB约 61GB已下载 deepseek-r1:32b，空盘更紧

thor-jd 的 73GB 空盘基本不适合放一份完整 V4-Flash-NVFP4 checkpoint。即使采用共享目录，也要先确认跨节点加载不会被网络和文件系统拖垮。

两台机器的软件环境

两台 Thor 都有 NVIDIA NGC 镜像：

机器SGLangvLLM
thornvcr.io/nvidia/sglang:26.04-py3，SGLang 0.5.10+516d57acnvcr.io/nvidia/vllm:26.04-py3
thor-jdnvcr.io/nvidia/sglang:26.04-py3nvcr.io/nvidia/vllm:26.04-py3，vLLM 0.19.0+...nv26.04

SGLang 26.04 的 help 里能看到相关参数：

--tensor-parallel-size
--nnodes
--node-rank
--dist-init-addr
--moe-runner-backend
--moe-a2a-backend
--modelopt-quant nvfp4
--quantization modelopt_fp4 / modelopt_mixed / petit_nvfp4 / mxfp4

这说明“入口参数”存在。但入口存在不等于能在 Jetson 上跑通。真正风险在：

  • aarch64 容器内的 FP4 / NVFP4 kernel 是否覆盖 Thor
  • DeepSeek V4 loader 是否支持该 checkpoint
  • TP=2 是否足够，官方验证是 TP=4/TP=8
  • 跨节点 NCCL 是否能走 QSFP28，而不是默认走 Wi-Fi / Tailscale / Docker bridge
  • MoE all-to-all 是否能接受 10GbE 级链路

QSFP28 链路检查

两台机器的 mgbe0_0 到 mgbe3_0 都显示 10GbE link up。

thor：

mgbe0_0  Speed: 10000Mb/s  Link detected: yes
mgbe1_0  Speed: 10000Mb/s  Link detected: yes
mgbe2_0  Speed: 10000Mb/s  Link detected: yes
mgbe3_0  Speed: 10000Mb/s  Link detected: yes

thor-jd：

mgbe0_0  192.168.100.2/24  Speed: 10000Mb/s
mgbe1_0  192.168.101.2/24  Speed: 10000Mb/s
mgbe2_0  192.168.102.2/24  Speed: 10000Mb/s
mgbe3_0  192.168.103.2/24  Speed: 10000Mb/s

但 thor 的这些接口没有 IP：

mgbe0_0  UP, LOWER_UP, no IPv4
mgbe1_0  UP, LOWER_UP, no IPv4
mgbe2_0  UP, LOWER_UP, no IPv4
mgbe3_0  UP, LOWER_UP, no IPv4

我尝试临时给 thor 配：

sudo ip addr add 192.168.100.1/24 dev mgbe0_0
sudo ip addr add 192.168.101.1/24 dev mgbe1_0
sudo ip addr add 192.168.102.1/24 dev mgbe2_0
sudo ip addr add 192.168.103.1/24 dev mgbe3_0

但当前 SSH 用户没有免密 sudo：

sudo: a password is required

所以本轮不能完成 iperf3 带宽测试，也不能验证 NCCL 是否能走 QSFP28。

为什么 QSFP28 配通前不能测 V4-Flash

两台机器虽然可以通过 Tailscale 地址互相访问：

机器Tailscale
thor100.98.202.31
thor-jd100.98.98.105

但 V4-Flash 这种 MoE 模型不能用 Tailscale 或 Wi-Fi 作为 serious benchmark 网络。Tensor parallel 和 MoE expert routing 会产生大量跨 rank 通信。

即便 QSFP28 实际是 4×10GbE，总带宽也只是 40GbE 级别，和 NVLink / NVSwitch / 数据中心 IB 仍然不是一个量级。能不能启动是一回事，能不能有可交互速度是另一回事。

权重需要两台都下载吗？

如果用 SGLang / vLLM 的常规多节点 TP，每个 rank 通常都需要能访问完整 checkpoint 目录。有两种方式：

方式评价
两台各放一份完整权重最稳，但占盘最大
NFS / 共享 NVMe 挂到两台同一路径省盘，但启动慢，随机读可能拖垮
手工拆 rank0/rank1 权重不建议，容易和 safetensors index / loader 逻辑冲突

当前 thor-jd 只有 73GB 空盘，不适合各放一份完整 V4-Flash-NVFP4。因此即使后续继续，也应优先考虑：

  1. 清理 thor-jd 磁盘，至少准备 200GB 空间；
  2. 或者给两台挂同一个共享模型目录；
  3. 确认 SGLang/vLLM 多节点小模型先能从该目录启动。

已验证的小模型基线

本轮之前，我已经在 thor-jd 上用 Ollama 跑通了：

模型量化context速度
DeepSeek-R1-Distill-Qwen-32BQ4_K_M，18.48GiB4096约 10.4 tok/s

这个测试说明 Thor 本身跑 32B dense reasoning model 没问题。但 V4-Flash-NVFP4 是 284B/13B active MoE，完全是另一类部署。

下一步应该怎么做

在碰 V4-Flash 权重前，我建议先完成这 4 步。

1. 配通 QSFP28 IP

在 thor 上配置：

sudo ip addr add 192.168.100.1/24 dev mgbe0_0
sudo ip addr add 192.168.101.1/24 dev mgbe1_0
sudo ip addr add 192.168.102.1/24 dev mgbe2_0
sudo ip addr add 192.168.103.1/24 dev mgbe3_0
sudo ip link set mgbe0_0 mtu 8966
sudo ip link set mgbe1_0 mtu 8966
sudo ip link set mgbe2_0 mtu 8966
sudo ip link set mgbe3_0 mtu 8966

然后互 ping：

ping 192.168.100.2
ping 192.168.101.2
ping 192.168.102.2
ping 192.168.103.2

2. 跑 iperf3

在 thor-jd：

iperf3 -s -B 192.168.100.2

在 thor：

iperf3 -c 192.168.100.2 -B 192.168.100.1 -P 4 -t 30

四条链路都测一遍，再考虑 bonding 或多 rail NCCL。

3. 用小模型测 SGLang 多节点

先不要用 V4-Flash。用 Qwen2.5-7B 或其他小模型验证：

# rank 0 on thor
sglang serve \
  --model-path /models/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tp 2 \
  --nnodes 2 \
  --node-rank 0 \
  --dist-init-addr 192.168.100.1:20000 \
  --trust-remote-code

# rank 1 on thor-jd
sglang serve \
  --model-path /models/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tp 2 \
  --nnodes 2 \
  --node-rank 1 \
  --dist-init-addr 192.168.100.1:20000 \
  --trust-remote-code

如果小模型 TP=2 都不通，V4-Flash 没必要试。

4. 再做 V4-Flash 加载实验

前面都通过后，再考虑：

sglang serve \
  --model-path /models/DeepSeek-V4-Flash-NVFP4 \
  --tp 2 \
  --nnodes 2 \
  --node-rank 0 \
  --dist-init-addr 192.168.100.1:20000 \
  --quantization modelopt_fp4 \
  --modelopt-quant nvfp4 \
  --context-length 4096 \
  --trust-remote-code \
  --disable-cuda-graph \
  --disable-piecewise-cuda-graph

但这一步我现在只把它列为待验证命令，不把它写成已成功方案。

结论

这次测试没有证明“2×Thor 可以跑 DeepSeek-V4-Flash-NVFP4”。相反，它证明了更重要的一点：当前环境还没满足开始 V4-Flash 实测的前置条件。

已确认：

  1. 两台 Thor 都有 SGLang/vLLM NVIDIA 容器；
  2. SGLang 26.04 暴露多节点、TP、NVFP4/FP4 相关参数；
  3. 四个 mgbe 口 link up 到 10GbE；
  4. thor-jd 已配置四个 QSFP28 网段；
  5. thor 的 QSFP28 口还没有 IP，当前用户无 sudo，无法临时配置；
  6. 当前磁盘空间不足以安全下载 V4-Flash-NVFP4，尤其是 thor-jd。

我的工程判断是：

先把 2×Thor 的 QSFP28 + SGLang 小模型 TP=2 打通，再下载 V4-Flash-NVFP4。否则大概率只是花很久下载权重，然后卡在网络、NCCL、loader 或 FP4 kernel 上。

测试时间：2026 年 8 月 13 日。本文记录的是前置测试和阻塞点，不声称完成 DeepSeek-V4-Flash-NVFP4 在 2×Thor 上的成功推理。