NVIDIA Jetson Thor上部署Qwen3.5 122B-A10B

2026-06-26

Hardware

引言

在《NVIDIA Jetson Thor》完成 Thor 的基础安装与配置后，本文记录在该平台上使用 vLLM 部署 Qwen3.5-122B-A10B 模型的完整过程。该模型总参数量 122B，每次推理激活约 10B 参数。除单 Thor 上的环境配置与服务启动外，本文还进一步探讨了基于 QSFP28 25GbE 高速链路与 Ray 框架构建双 Thor 跨卡分布式推理的实践方案。此外，部署过程中也测试了 Qwen3.5 其他参数量版本以及 Gemma-4 系列模型，资源占用与推理速度部分会一并列出，供对比参考。

Qwen 3.5有以下几个亮点：

统一视觉语言基础（Unified Vision-Language Foundation） Qwen3.5 采用早期融合训练（Early Fusion），将视觉 token 和文本 token 统一训练，不再是”文字模型 + 外挂视觉模块”的拼接方案。在推理、编程、Agent 任务和视觉理解等基准测试上，整体性能对齐甚至超越上一代专门的视觉模型 Qwen3-VL。
高效混合架构（Gated Delta Network + MoE） Qwen3.5 引入 Gated Delta Networks 与稀疏 Mixture-of-Experts（MoE）的组合架构。以 35B-A3B 为例，总参数量 350 亿，每次推理仅激活约 30 亿参数，实现了高吞吐、低延迟、低成本的三重平衡——这正是”用中等规模做出旗舰效果”的核心秘密。
百万 Agent 规模的强化学习训练过程中，RL 框架在数百万个 Agent 环境中并行运行，通过递进式任务分布持续提升模型的真实世界泛化能力，使模型在复杂多步 Agent 任务中的鲁棒性大幅提升。
201 种语言覆盖 Qwen3.5 将多语言支持扩展至 201 种语言与方言，包含对中文、粤语等多种方言的细粒度理解能力。

关于 Qwen3.5-122B-A10B

架构

根据 Hugging Face 官方模型卡，Qwen3.5-122B-A10B 的核心架构如下：

模型类型：带视觉编码器的因果语言模型（Causal Language Model with Vision Encoder）
训练阶段：预训练 + 后训练（Pre-training & Post-training）
语言模型
- 总参数量 / 激活参数量：122B / 10B（稀疏 MoE 架构）
- 隐藏层维度：3072
- 词表大小：248,320（Padded）
- 层数：48
- 隐藏层布局：12 × (3 × (Gated DeltaNet → MoE) → 1 × (Gated Attention → MoE))
- Gated DeltaNet
  - 线性注意力头数：V 为 64，QK 为 16
  - 头维度：128
- Gated Attention
  - 注意力头数：Q 为 32，KV 为 2
  - 头维度：256
  - RoPE 维度：64
- Mixture of Experts（MoE）
  - 专家总数：256
  - 每次激活专家数：8 个路由专家 + 1 个共享专家
  - 专家中间层维度：1024
- 输出层：248,320（Padded）
- MTP：支持多步预测（Multi-Token Prediction）
上下文长度：原生支持 262,144 tokens，可扩展至 1,010,000 tokens

本文实际部署使用的是 FP4 量化版本（Sehyo--Qwen3.5-122B-A10B-NVFP4），与官方 FP8 版本在架构上一致，量化精度不同。

官方并没有完整的Qwen3.5 架构图，分别从网站、Qwen3.7-Max、DeepSeek专家模式问到的架构如下：

deepseek

Qwen3.7

官方宣称特性

Qwen 团队在 Qwen3.5 Highlights 中，对 Qwen3.5 系列（含 122B-A10B）宣称了以下核心特性：

统一视觉-语言基座（Unified Vision-Language Foundation）：通过多模态 token 的早期融合训练，在推理、编程、Agent 和视觉理解等基准上达到与 Qwen3 同代水平，并超越 Qwen3-VL 系列。
高效混合架构（Efficient Hybrid Architecture）：Gated Delta Networks 与稀疏 MoE 相结合，在保持低延迟的同时实现高吞吐推理，成本开销较小。
可扩展强化学习泛化（Scalable RL Generalization）：在百万级 Agent 环境中扩展强化学习，通过逐步复杂的任务分布训练，提升真实场景适应能力。
全球语言覆盖（Global Linguistic Coverage）：支持 201 种语言与方言，面向全球化部署，具备更细粒度的文化与地域理解能力。
下一代训练基础设施（Next-Generation Training Infrastructure）：多模态训练效率接近纯文本训练（近 100%），并配备异步 RL 框架，支持大规模 Agent 脚手架与环境编排。

此外，官方 FP8 版本采用 block size 为 128 的细粒度 FP8 量化，宣称性能指标与原始模型几乎一致。模型默认处于思考模式（Thinking Mode），会在最终回复前先生成思考内容；也支持通过 API 参数关闭思考，直接输出回复。官方推荐使用 vLLM、SGLang 等推理框架部署，原生上下文长度为 262K，复杂长文本任务可借助 YaRN 等技术扩展至约 1M tokens。

部署过程

下载大模型

pip install modelscope
modelscope download --model Qwen/Qwen3-VL-8B-Instruct --local_dir ./dir

创建环境

conda create -n uv python=3.12
conda activate uv

安装 torch、torchvision、torchaudio

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

安装部分依赖

pip install xgrammar triton flashinfer-python --prerelease=allow

下载 vLLM 源代码

git clone --recursive https://github.com/vllm-project/vllm.git
cd vllm

编译 vLLM 前的环境安装、配置

python3 use_existing_torch.py
pip install -r requirements/build.txt

安装 vLLM

pip install --no-build-isolation -e .

查看 Jetson AGX Thor 架构

nvidia-smi --query-gpu=name,compute_cap --format=csv

配置架构

export TORCH_CUDA_ARCH_LIST=11.0a
export TRITON_PTXAS_PATH=/usr/local/cuda/bin/ptxas

下载用于 tokenizer 的文件并配置环境变量

mkdir tiktoken_encodings
wget -O tiktoken_encodings/o200k_base.tiktoken "https://openaipublic.blob.core.windows.net/encodings/o200k_base.tiktoken"
wget -O tiktoken_encodings/cl100k_base.tiktoken "https://openaipublic.blob.core.windows.net/encodings/cl100k_base.tiktoken"
export TIKTOKEN_ENCODINGS_BASE=${PWD}/tiktoken_encodings

启动 vLLM

以 Qwen3.5-9B 为例：

vllm serve \
/home/sunjing/projects/VLM/models/Qwen3.5-9B \
--async-scheduling \
--port 8000 \
--host 0.0.0.0 \
--trust-remote-code \
--swap-space 16 \
--max-model-len 32768 \
--tensor-parallel-size 1 \
--max-num-seqs 256 \
--gpu-memory-utilization 0.7 \
--enable-prefix-caching \
--allowed-local-media-path /home

可能出现的问题

ptxas-blackwell fatal: Value ‘sm_110a’ is not defined for option ‘gpu-name’

export TRITON_PTXAS_BLACKWELL_PATH=/usr/local/cuda/bin/ptxas

ValueError: Free memory on device cuda:0 (18.7/122.82 GiB) on startup is less than desired GPU memory utilization (0.2, 24.56 GiB).

降低 gpu-memory-utilization 的数值即可。

AssertionError: Error in memory profiling.

export VLLM_SKIP_MEMORY_PROFILER=1

测试可用

curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "/home/sunjing/projects/VLM/models/Qwen3-VL-8B-Instruct",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "描述图片中都有什么"},
        {"type": "image_url", "image_url": {"url": "https://inews.gtimg.com/om_bt/OuP9OfpazXjI8MOLob6kDLosfdDJbm1thq-J4wOhEGyxkAA/1000"}}
      ]
    }
  ],
  "max_tokens": 100
}'

启动新服务

每次运行需要重新配置的环境变量（可以选择写死在 bashrc 里）：

export TORCH_CUDA_ARCH_LIST=11.0a
export TRITON_PTXAS_PATH=/usr/local/cuda/bin/ptxas
export TIKTOKEN_ENCODINGS_BASE=${PWD}/tiktoken_encodings
export TRITON_PTXAS_BLACKWELL_PATH=/usr/local/cuda/bin/ptxas

显存释放

运行后退出，显存无法正常释放时，可执行：

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

启动 122B 大模型

启动 122B 等较大参数量的模型，在启动过程中容易被 kill。理论上，122B-FP4 的模型只需要占据 61GB + KV cache，但是在启动的时候需要更多（可能是权重文件分割太大）。

vllm serve ./Sehyo--Qwen3.5-122B-A10B-NVFP4 \
  --quantization compressed-tensors \
  --reasoning-parser qwen3 \
  --language-model-only \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.65 \
  --max-model-len 2048 \
  --max-num-seqs 1 \
  --enforce-eager \
  --mm-processor-cache-gb 0 \
  --trust-remote-code

双Thor分布式推理

在单台 Thor 节点部署超大参数模型（如 Qwen3.5 122B-A10B）时，显存往往吃紧。为了进一步释放全尺寸/高精度大模型的推理能力，使用两台 Thor 建立跨设备分布式推理是最直接有效的方案。

双 Thor 分布式推理的核心在于建立两台 Thor 设备之间的高速通信链路。Thor 开发套件配备 QSFP28 接口，单个接口提供 4×25 Gbps 通道带宽，理论聚合速率可达 100 Gbps，能够满足跨设备张量传输对高带宽与低延迟的严苛需求。

根据 NVIDIA 官方方案（Jetson AGX Thor 硬件布局），两台 Thor 设备可通过 QSFP 端口背靠背直连，采用 4×25 Gbps QSFP28 线缆实现点对点互联，无需借助外部交换机即可构建高效的数据通道。

需要注意的是：

QSFP 端口默认工作在 4×10GbE 模式；
要启用 25GbE 模式，需要修改 BSP 配置文件中的 ODMDATA 并重新刷机；
不能使用普通 RJ45 网线插入 QSFP 接口；
25GbE 模式需要匹配 QSFP28 DAC / AOC / 光模块和线缆。

官方提供了 25GbE 配置和两台 Thor 直连测试文档：Enable 25 Gigabit Ethernet on QSFP Port。

PS：实际发现，默认状态只有48G，而刷机后最多也就是只有420G，达不到宣称的100G

双 Thor 分布式推理的落地主要包含 硬件链路与刷机配置 以及 软件环境与 Ray 集群部署 两个主要阶段。

硬件直连与 25GbE 刷机配置

QSFP 线缆连接与刷机步骤完全参考 NVIDIA 官方教程：Enable 25 Gigabit Ethernet on QSFP Port。

线缆选择：要想达到 4×25 Gbps 带宽，必须使用 QSFP28 规格的线缆（推荐 MCP1600 QSFP28 Copper Cable DAC 直连铜缆），不能使用 QSFP+ 的 40G 线缆/模块。
硬件直连：通过 QSFP 线缆将两台 Jetson AGX Thor Developer Kit 的 QSFP 端口直连。
配置文件修改与 reflash：Thor 的 QSFP 端口默认运行在 4×10GbE 模式，要启用 25GbE，需借助一台 x86_64 Ubuntu 主控主机（Host PC），安装 NVIDIA SDK Manager。将 Thor 连至 Host 并进入 Recovery 模式，编辑对应设备的配置文件修改 ODMDATA：

标准 Jetson AGX Thor Dev Kit（4 个 MGBE 端口）：编辑 jetson-agx-thor-devkit.conf
```
ODMDATA="uphy1-config-8,mgbe0-speed-3,mgbe1-speed-3,mgbe2-speed-3,mgbe3-speed-3";
```
Jetson Thor T4000 模块（3 个 MGBE 端口）：编辑 jetson-agx-thor-t4000.conf
```
ODMDATA="uphy1-config-8,mgbe0-speed-3,mgbe1-speed-3,mgbe2-speed-3";
```

mgbeX-speed-3 代表将对应端口速率置为 25Gbps。两台 Thor 均需按各自型号完成配置文件修改并执行 reflash（如 sudo ./flash.sh ...）。

刷机完成并启动 Linux 后，需在两台设备上执行以下优化以发挥 100G 带宽潜能：

配置 4 个 MGBE 接口，启用 9K MTU（Jumbo Frame）：

sudo ifconfig mgbe0_0 down mtu 9000 up
sudo ifconfig mgbe1_0 down mtu 9000 up
sudo ifconfig mgbe2_0 down mtu 9000 up
sudo ifconfig mgbe3_0 down mtu 9000 up

开启 Linux 内核 threaded NAPI 模式：

sudo sh -c "echo 1 > /sys/devices/platform/bus@0/a808a10000.ethernet/net/mgbe0_0/threaded"

锁定 CPU 时钟频率：
```
sudo jetson_clocks
```

为各 MGBE 接口启用 deferred DMA unmap（IOMMU 设为 DMA-FQ）：

# 以 mgbe0_0 为例（其他 mgbe1_0, mgbe2_0, mgbe3_0 替换接口名）
GROUP=$(basename $(readlink /sys/class/net/mgbe0_0/device/iommu_group))
echo DMA-FQ | sudo tee /sys/kernel/iommu_groups/$GROUP/type

配置完成后，使用 iperf3 工具测试两台 Thor（分别设为 Thor-A 主节点与 Thor-B 从节点）之间点对点的实际传输带宽。

Thor-B（从节点）启动 iperf3 服务端：
```
iperf3 -s
```
提示：若报错 Address already in use，可执行 sudo kill -9 $(sudo lsof -ti :5201) 2>/dev/null 清理已有进程。
Thor-A（主节点）运行带宽测试：
```
iperf3 -c 192.168.1.21 -t 10
```

测试结果显示点对点吞吐率可稳定达到 67.9 ~ 80 Gbits/sec，满足分布式推理的跨卡通信要求。

分布式软件环境与 Ray 集群搭建

Docker 与 NVIDIA Container Toolkit 配置

刷机后系统默认没有 Docker 环境，需手动安装并配置：

sudo apt-get update
sudo apt-get install -y docker.io
sudo systemctl enable --now docker
sudo usermod -aG docker $USER
newgrp docker

安装并注册 NVIDIA Container Toolkit：

# 检测安装
nvidia-ctk --version

# 安装命令
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

# 注册 runtime 并重启 docker
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

保证两台 Thor 设备导入相同的 Docker 镜像及模型权重文件：

zcat vllm-openai-nightly.tar.gz | docker load

Docker 容器启动与 Ray 集群搭建

分别在 Thor-A 与 Thor-B 上启动容器，注意配置跨设备通信的网卡名称（NCCL_SOCKET_IFNAME）。

Thor-A（主节点）容器启动：

docker run -it --rm \
  --runtime=nvidia \
  -e NVIDIA_VISIBLE_DEVICES=all \
  -e NCCL_SOCKET_IFNAME="=mgbe1_0" \
  -e NCCL_SOCKET_FAMILY=AF_INET \
  -e NCCL_IB_DISABLE=1 \
  -e NCCL_DEBUG=INFO \
  --network host \
  --ipc=host \
  -v /home/grg/xwy:/app/models \
  --name vllm-thor-a \
  --entrypoint /bin/bash \
  vllm/vllm-openai:nightly

Thor-B（从节点）容器启动：

docker run -it --rm \
  --runtime=nvidia \
  -e NVIDIA_VISIBLE_DEVICES=all \
  -e NCCL_SOCKET_IFNAME="=mgbe0_0" \
  -e NCCL_SOCKET_FAMILY=AF_INET \
  -e NCCL_IB_DISABLE=1 \
  -e NCCL_DEBUG=INFO \
  --network host \
  --ipc=host \
  -v /home/grg/xwy:/app/models \
  --name vllm-thor-b \
  --entrypoint /bin/bash \
  vllm/vllm-openai:nightly

在容器内安装 Ray 并建立分布式集群：

pip install ray

Thor-A 启动 Ray Head 节点：

ray stop --force
ray start --head --node-ip-address=192.168.1.100 --port=6379 --num-gpus=1

Thor-B 加入 Ray 集群：

ray stop --force
ray start --address=192.168.1.100:6379 --node-ip-address=192.168.1.11 --num-gpus=1

验证集群状态：在 Thor-A 上运行 ray status，确认检测到 Total Usage: 0.0/2.0 GPU，代表两卡分布式节点构建成功。
模型服务启动与并行策略比对

流水线并行（Pipeline Parallelism，推荐）使用流水线并行（将模型不同层分配到不同卡上串行计算）启动服务。该方式跨节点通信开销较小，性能稳定：

vllm serve /app/models/models--Intel--Qwen3.5-122B-A10B-int4-AutoRound/snapshots/3045d02bb737effc4581da91bddbad3be02934e4 \
  --host 0.0.0.0 --port 8004 \
  --tensor-parallel-size 1 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray \
  --gpu-memory-utilization 0.38 \
  --max-model-len 32768

注意：流水线并行暂不支持搭配 MTP 投机解码（Draft model 未实现 SupportsPP 接口，启动初始化会报错）。

张量并行（Tensor Parallelism）若尝试使用张量并行（每层矩阵切分到多卡）并启用 MTP 投机解码：
```
vllm serve /app/models/models--Intel--Qwen3.5-122B-A10B-int4-AutoRound/snapshots/3045d02bb737effc4581da91bddbad3be02934e4 \
  --host 0.0.0.0 --port 8004 \
  --tensor-parallel-size 2 \
  --pipeline-parallel-size 1 \
  --distributed-executor-backend ray \
  --gpu-memory-utilization 0.40 \
  --max-model-len 32768 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":2}'
```
实测坑点：张量并行由于每一层都需要频繁进行全同步（all-reduce）通信，在缺乏 NVLink 的跨节点以太网场景下容易引发 Worker 进程挂起或超时错误（No available shared memory broadcast block found in 60 seconds），因此在双 Thor 环境下优先推荐流水线并行。

推理服务验证

模型服务成功启动后，使用 curl 发送请求验证推理输出：

curl http://localhost:8004/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/app/models/models--Intel--Qwen3.5-122B-A10B-int4-AutoRound/snapshots/3045d02bb737effc4581da91bddbad3be02934e4",
    "messages": [{"role": "user", "content": "请给出辣椒炒蛋的步骤"}],
    "max_tokens": 512,
    "temperature": 0.7,
    "chat_template_kwargs": {"enable_thinking": false}
  }'

跨设备分布式并行计算原理

在完成了两台 Thor 设备的物理链路直连与网络打通后，系统是如何跨设备协同完成大模型并行计算的？其底层机制主要由 Ray（分布式调度层）、vLLM（分布式推理引擎） 与 NCCL（NVIDIA 集合通信库） 协同驱动。

架构分工与通信机制

分布式集群运行时的整体通信架构如下图所示：

                    ┌──────────────────────────────────────────────┐
                    │               用户 HTTP 请求                  │
                    └──────────────────────┬───────────────────────┘
                                           │
                                  ┌────────▼────────┐
                                  │  vLLM API Server │
                                  └────────┬────────┘
                                           │ (Ray RPC)
                       ┌───────────────────┴───────────────────┐
                       │                                       │
            ┌──────────▼──────────┐                 ┌──────────▼──────────┐
            │  Thor-A (Head 节点) │                 │  Thor-B (Worker 节点)│
            │ ┌─────────────────┐ │                 │ ┌─────────────────┐ │
            │ │ vLLM Worker 0   │ │ ◄── NCCL (Socket)──►│ vLLM Worker 1   │ │
            │ └────────┬────────┘ │   (25GbE 链路)  │ └────────┬────────┘ │
            │ ┌────────▼────────┐ │                 │ ┌────────▼────────┐ │
            │ │ GPU 0 (Layer 1~24)│                 │ │GPU 1 (Layer 25~48)│
            │ └─────────────────┘ │                 │ └─────────────────┘ │
            └─────────────────────┘                 └─────────────────────┘

各组件的具体职责如下：

Ray（控制面）：Ray Head 节点（Thor-A）通过 6379 端口与 Worker 节点（Thor-B）建立 TCP/RPC 控制信道，统一调度两台设备的 GPU 资源，并在各自容器内拉起 vLLM Worker 进程。
NCCL Over Socket（数据面）：由于两台独立的 Jetson AGX Thor 开发板之间没有 NVLink 物理总线，因此在容器启动时指定了 -e NCCL_SOCKET_IFNAME="=mgbe1_0" 与 -e NCCL_IB_DISABLE=1。NCCL 会自动回退到基于网卡的 TCP/IP Socket 传输机制，通过 25GbE 接口在两台 Thor 之间高速传输张量（Tensor）数据。

vLLM 原生分布式推理工作机制

vLLM 本身原生内置了完整的分布式推理支持，开发者无需手动修改模型结构源码，仅需在启动时配置 --distributed-executor-backend 等参数即可。其底层实现机制主要包含以下关键环节：

Distributed Executor 抽象层 vLLM 设计了统一的分布式执行器接口。当启动参数包含 --distributed-executor-backend ray 时，vLLM 会实例化 RayDistributedExecutor，通过 Ray Actor 将推理任务分发到各个节点上的 Worker（单机多卡则使用基于 Python 多进程的 MPDistributedExecutor）。
Worker 实例化与 PyTorch 进程组初始化 vLLM 在 Thor-A 与 Thor-B 的 Docker 容器中各自实例化 vLLM Worker 类。启动时，主控节点广播环境变量并调用 PyTorch 底层的 torch.distributed.init_process_group(backend="nccl")，利用打通的网卡建立跨设备的通信组。
模型切分与权重分片加载 vLLM 模型基类（如 Qwen2ForCausalLM）继承了并行模型层实现（集成自 Megatron-LM 或自定义 PP/TP 切分模块）。模型加载时，每个 Worker 根据其 rank 和 world_size，仅加载其所属切片对应的权重文件（如流水线并行下 Thor-A 仅加载前 24 层权重），大幅降低单卡显存占用。
PagedAttention 与 KV Cache 分片管理 分布式场景下，vLLM 标志性的 PagedAttention 显存管理机制会在每个 Worker 上独立申请对应层/头的 KV Cache 物理块（Block Table），并在连续批处理（Continuous Batching）推理过程中按需分配与释放。
引擎调度与连续批处理（LLMEngine） 主节点上的 LLMEngine 负责全局的 Request Queue（请求队列）、Continuous Batching 调度与 Token 采样逻辑。每次推理迭代时，LLMEngine 将包含 Prompt / Token 信息的指令广播给所有 Worker，各 Worker 并行执行 Forward 计算并在层间通过 NCCL 传递 Hidden State，最终将结果汇聚给主节点返回。

两种并行策略的计算过程与性能差异

流水线并行（Pipeline Parallelism, PP）—— 实测推荐方案

切分方式：将模型的 48 层 Transformer Block 按“层”切分，例如 Thor-A（GPU 0）加载 Layer 1~24，Thor-B（GPU 1）加载 Layer 25~48。
计算与传输：
1. Thor-A 接收输入后，GPU 0 计算前 24 层；
2. 算完第 24 层后，GPU 0 调用 NCCL 的 P2P Send 接口，将得到的隐藏层激活张量（Hidden States，尺寸为 [batch_size, seq_len, hidden_size]，仅数 KB）通过 25GbE 网线发给 Thor-B；
3. Thor-B 的 GPU 1 调用 P2P Recv 接收张量后，继续计算第 25~48 层，最终采样输出 Token。
优势：每生成一个 Token，卡间仅在边界层发生 1~2 次 P2P 点对点传输，传输数据量极小且不频繁，因此受以太网网络延迟的影响很小，运行非常稳定。

张量并行（Tensor Parallelism, TP）—— 跨网以太网踩坑分析

切分方式：将每一层 Transformer 内部的注意力矩阵（QKV）和 MLP 矩阵切分到两台 Thor 上，两卡同时计算同一层的一部分。
计算与传输：模型每计算一层，两台 Thor 必须通过 NCCL 执行 All-Reduce 操作合并局部结果。对于 48 层的模型，生成一个 Token 需要进行 $48 \times 2 = 96$ 次跨网络阻塞式同步。
局限：All-Reduce 极度依赖 NVLink 的微秒级超低延迟。在跨节点以太网（Socket）下，96 次 TCP 网络延迟被累加放大，容易导致进程在等待同步时抛出 No available shared memory broadcast block found in 60 seconds 60 秒超时错误。

下表直观总结了两种并行策略在双 Thor 跨卡环境下的差异：

特性	流水线并行 (Pipeline Parallelism)	张量并行 (Tensor Parallelism)
模型切分	按层切分（前24层 / 后24层）	按矩阵切分（每层矩阵切半）
NCCL 通信 API	`P2P Send / Recv`（点对点传输）	`All-Reduce / All-Gather`（全局同步）
单 Token 通信次数	1 ~ 2 次	96 次（48层模型）
网络硬件要求	普通千兆/万兆/25G 以太网即可	极度依赖 NVLink / NVSwitch
双 Thor 实测效果	稳定运行，显存平摊至 53G/57G	容易超时卡死（60s Timeout）

资源占用及速度

本节除 122B-A10B 外，还记录了 Qwen3.5 其他参数量版本及 Gemma-4 系列模型的测试数据，便于横向对比。

Token 计算说明
输入 Token 数：由图片输入 + 提示词（prompt）输入组成。
- Qwen3.5 图片输入：1 个 token 对应输入分辨率 32×32 的图片，例如分辨率为 1280×720 的图片输入约占 1280×720/32/32 = 900 tokens。
- Gemma-4 图片输入：1 个 token 对应输入分辨率 60×60 的图片，例如分辨率为 1280×720 的图片输入约占 1280×720/60/60 = 256 tokens。
- 1 个字约等于 0.5~1 token（反过来，1 Token 约等于 1~1.8 汉字）。
生成回复/输出 token：每个颜色块代表 1 个 token，以下截图约为 100 tokens。

对比：

参数量	精度	显存占用	输入处理速度（首次）	输入处理速度（后续）	首 token 耗时（首次）	首 token 耗时（后续）	生成速度	100 tokens 总耗时
Qwen3.5 122B-A10B	FP4	86G	233 tokens/s	765 tokens/s	3s	1.2s	12 tokens/s	8.3s
Qwen3.5 122B-A10B	INT4	86G	245 tokens/s	838 tokens/s	3.9s	1.1s	26 tokens/s	3.7s
Qwen3.5 122B-A10B	INT4 +MTP2	96G	—	790 tokens/s	—	1.2s	31 tokens/s	9.69s
Qwen3.5 122B-A10B	INT4/两台Thor级联	57/53GB	—	420.18 tokens/s	—	2.2s	31.38 tokens/s	3.18s
Qwen3.5 122B-A10B	FP4/两台Thor级联	67/62GB	—	1041 tokens/s	—	0.9s	19.8 tokens/s	5.05s
Qwen3.5 122B-A10B	FP8/两台Thor级联	102/98GB	—	934.98 tokens/s	—	1.026s	22.84 tokens/s	4.35s
Qwen3.5 9B	FP16	24G	56.67 tokens/s	1726.80 tokens/s	16s	0.55s	10 tokens/s	10.64s
Qwen3.5 4B	FP16	13G	57.74 tokens/s	2775 tokens/s	16.6s	0.34s	15 tokens/s	6.8s
Qwen3.5 2B	FP16	10G	58.19 tokens/s	3369.59 tokens/s	16.5s	0.28s	42.12 tokens/s	2.55s
Qwen3.5 0.8B	FP16	7G	58.49 tokens/s	3500.61 tokens/s	16.4s	0.27s	85 tokens/s	1.39s
Gemma-4-E2B	FP16	10.083G	—	3108.33 tokens/s	—	0.226s	16.22 tokens/s	6.325s
Gemma-4-E4B	FP16	15.427G	—	3032.52 tokens/s	—	0.273s	10.58 tokens/s	9.452s
Qwen3 30B-A3B	FP4	30G	1079 tokens/s	3536 tokens/s	0.8 s	0.2 s	52 tokens/s	1.9 s
Qwen3.6 35B-A3B	FP8	50G	366 tokens/s	1094 tokens/s	2.6s	0.87 s	41 tokens/s	2.4 s
Qwen3.6 27B	FP16	60G	257 tokens/s	1524 tokens/s	3.7 s	0.6 s	4 tokens/s	23 s
Qwen3.6 27B	FP8	43 G	618 tokens/s	2169 tokens/s	1.5 s	0.4 s	8 tokens/s	12 s
Qwen3.6 27B	FP4	36 G	598 tokens/s	2356 tokens/s	1.6 s	0.4 s	9 tokens/s	—

测试条件：采用多模态推理（图片 + 文字 prompt），1280×720 图片输入 + 约 100 token 的 prompt，约 100 tokens 的回复。

参考资料

Thor 安装与配置博客：《NVIDIA Jetson Thor》
Huggingface Qwen : Huggingface Qwen3.5-122B-A10B-FP8
Qwen3.5：迈向原生多模态智能体

致谢

本博客特别致谢 @haijing1995 提供的技术支持。