# [Qwen3.6][Jetson Thor] 无法复现文档中的 42.8 tok/s baseline

[HuLixiaNick531]

[Qwen3.6][Jetson Thor] 无法复现文档中的 42.8 tok/s baseline

问题

在 Jetson AGX Thor 上运行 Qwen3.6-27B NVFP4 + MTP，文档中 ctx=128 的
decode 性能为 42.8 tok/s，当前环境稳态实测约为 25.76 tok/s。

环境

• Jetson AGX Thor 128 GB，SM110
• JetPack 7.2 / L4T 38.4
• MAXN，jetson_clocks ON，GPU 1575 MHz
• 容器：nvcr.io/nvidia/pytorch:25.12-py3
• PyTorch：2.10.0a0+b4e4ee81d3.nv25.12
• Container CUDA：13.1
• FlashRT：d0db114
• FP8 KV cache，K=6，ctx=128，max_new_tokens=64

最新结果

一次 warmup 后连续测量三次：

Rep	Prefill	Decode time	Decode
1	332.582 ms	2484.409 ms	25.761 tok/s
2	332.605 ms	2486.273 ms	25.741 tok/s
3	333.086 ms	2482.827 ms	25.777 tok/s

平均 prefill 为 332.76 ms，decode 为 25.76 tok/s。三次输出 SHA 完全
一致，CUDA Graph 和 FP8 XQA 均正常启用。

排查结果

1. 使用文档 baseline commit 7cf622f 的 frontend 和重新编译的 kernel，稳态仍
   只有 24.26 tok/s，不像是后续 frontend 代码回归。
2. CUDA 13.0 与 CUDA 13.1 编译的 kernel 实测仅相差约 1.6%。
3. 2K–16K prefill 与文档误差约 0.5–1.2%，问题主要集中在 decode。
4. ctx=128 的主要耗时为：MTP chain K=6 约 65–67 ms，verify K+1=7 约 110 ms。
5. MTP lm_head 的 widen tactic 在 SM110 上明显较慢：

Tactic	单次 lm_head
widen	7.83 ms
default	4.46 ms
pingpong	4.40 ms

将 vocab-sized lm_head 改用 default 后，decode 提升到 28.27 tok/s，
但仍达不到 42.8 tok/s。

希望确认

1. 能否提供 Thor baseline 使用的完整 benchmark 脚本和 prompt？
2. AL=3.86 是否包含每个 speculative cycle 的 target token？
3. 参考设备上的 MTP K=6 chain 和 K=7 verify 分别应为多少毫秒？
4. SM110 的 lm_head 是否应使用 default/pingpong 而不是 widen？

如果有进一步定位问题的建议、推荐的 profiling 方法或需要补充的测试数据，也请告知。非常感谢维护者的帮助！

[LiangSu8899]

感谢反馈，也谢谢你把 lm_head 不同 tile 的耗时单独测出来，这个结果很有价值。

我在 Thor 上按照文档中的配置重新跑了一遍。ctx=128、K=6、max_new_tokens=64，可以稳定达到 42–44 tok/s：

 ctx   K   TTFT_ms   dec_ms   tok/s     AL
 128   6      266.6   1436.4   43.86   3.86

K=1 和 K=6 的 greedy 输出逐 token 一致，parity 检查为 PASS。

测量口径和环境

为了方便对齐，我这边的统计方式是：

decode tok/s = (n_new_tokens - 1) / (full_gen_time - TTFT)
AL = spec_accepts / spec_attempts

Prefill 和 decode 使用两个独立的 CUDA event 窗口计时，因此 decode 时间不包含 prefill。

你贴出的结果也是分别统计了：

Prefill: 332.76 ms
Decode:  2484.4 ms

所以双方口径是一致的，性能差距应该不来自计时方式。

我这边的软件栈与你相同：

Container: nvcr.io/nvidia/pytorch:25.12-py3
PyTorch:   2.10.0a0+b4e4ee81d3.nv25.12
CUDA:      13.1

硬件和运行状态：

Jetson AGX Thor Developer Kit
MAXN
jetson_clocks enabled
GPC: 1.575 GHz
GPU temperature during decode: ~45°C

因此目前看不像是 CUDA、PyTorch 或容器版本差异。

当前比较明显的差异

相同 shape 下，两边的大致耗时是：

Part	Your result	My result
MTP chain, K=6	~65 ms	~28 ms
Verify, K+1=7	~110 ms	~74 ms
64-token decode window	~2484 ms	~1436 ms

不仅是 lm_head，MTP chain 和 verify 也都明显偏慢。

这段 decode 的主要工作是 NVFP4 W4A16 GEMM，每轮需要从 LPDDR5X 中读取大约 13.5 GB 的权重。所有 kernel 又都运行在 CUDA graph 下，因此这里主要受有效内存带宽影响，而不是 kernel launch overhead。

两个不同部分同时慢约 1.5–2.3 倍，我会优先怀疑 EMC 频率或实际内存带宽，而不是某一个单独的 kernel。

建议先确认 EMC 时钟

MAXN 主要设置功耗和频率上限，并不等于所有时钟都一定锁定在最高值。

对于 decode 这种 SM occupancy 较低、主要受内存带宽限制的负载，DVFS 仍可能降低 EMC，也就是内存控制器和 LPDDR5X 的频率。

建议执行：

sudo nvpmodel -m 0
sudo jetson_clocks
sudo jetson_clocks --show

请重点确认 GPC 和 EMC 是否都处于最高频率。

如果此前只启用了 MAXN，但没有实际运行 jetson_clocks，这一点可能解释相当一部分性能差距。

还可以跑一个 device-to-device cudaMemcpy 带宽测试做独立验证。Thor 的峰值带宽约为 273 GB/s；如果实际结果明显低于约 250 GB/s，通常说明 EMC 或内存带宽状态没有达到预期。

另外也建议在 benchmark 运行时观察 tegrastats，确认没有热降频，并检查 EMC 频率在整个 decode 阶段是否稳定。

关于 lm_head 的 widen tile

你这里的结论是对的。

对于 SM110 上这些 M=1 shape，widen 的表现确实不如 default 或 pingpong。我这边的 tile benchmark 结果也是：

lm_head, M=1:
default / pingpong: ~96.4% bandwidth utilization
widen:              ~90.3%
fused gate/up, M=1:

default:            ~70%

widen:              ~37%

输出是 token-exact 的，cosine similarity 为 1.0，所以切换 tile 不会带来精度变化。

我会把 SM110 上 M=1 的 decode/chain GEMM 默认切换为 default，并做一次端到端验证。

这项修改和 EMC 问题并不冲突。内存带宽不足时，效率较低的 tile 会受到更明显的惩罚，这与你测到的 7.83 ms 对 4.40 ms 是吻合的。

回答你列出的几个问题

1. 能否提供完整 benchmark 脚本和 prompt？

可以，完整脚本：

bench_qwen36_thor_decode.py

Prompt 是脚本中 SEED 定义的重复英文文本，并确定性地 tokenize 到正好 ctx 个 token。

这样可以保证 warmup 和正式计时运行使用相同的 cur_pos 序列，也会命中同一组 CUDA graph。

2. AL=3.86 是否包含每个 cycle 的 target token？

不包含。

这里的定义是：

AL = spec_accepts / spec_attempts

它统计的是每个 verify cycle 中被接受的 draft token 数。

每个 cycle 在接受这些 draft token 之外，还会额外产生一个 verify 自己的 argmax token，也就是通常所说的 bonus token。这个 +1 不计入 AL。

因此：

AL ≈ 3.86

实际每个 cycle 产生的 token ≈ AL + 1 ≈ 4.86

例如我这里 ctx=128、K=6 时：

spec_attempts = 14

spec_accepts  = 54

AL = 54 / 14 = 3.86

3. 参考设备上 K=6 chain 和 K+1=7 verify 分别是多少？

我这边 CUDA graph 下的稳态结果大约是：

MTP chain, K=6: ~28 ms

Verify, M=7:    ~74 ms

你那边大约是：

MTP chain, K=6: ~65 ms

Verify, M=7:    ~110 ms

两个阶段都偏慢，因此我更倾向于系统性的带宽或内存时钟差异，而不是单个 kernel 的问题。

4. SM110 的 lm_head 应该用哪个 tile？

建议使用 default 或 pingpong，不要使用 widen。

对于当前 M=1 shape，我这边 default 和 pingpong 的结果接近，都会明显优于 widen。后续我会将 SM110 的默认选择改为 default。

5. 进一步定位建议

建议按下面的顺序排查。

首先锁定时钟并重新运行 benchmark：

sudo nvpmodel -m 0

sudo jetson_clocks

sudo jetson_clocks --show

python bench_qwen36_thor_decode.py ...

然后确认 D2D 内存带宽：

Expected: close to the device's practical maximum

Suspicious: substantially below ~250 GB/s

如果还存在差距，可以使用 Nsight Systems：

nsys profile -o qwen36_decode 

python bench_qwen36_thor_decode.py ...

重点查看：

cuda_gpu_kern_sum

NVFP4 W4A16 GEMM 理论上应该占 decode 时间的绝大部分。我这里大约是 88%。可以进一步根据权重读取量和 kernel 时间估算每个 GEMM 的实际有效带宽。

最后检查 CUDA graph 是否在正式计时期间继续捕获。可以在 timed generation 前后打印 graph cache 大小，正常情况下不应该增长。

为了继续定位，麻烦贴一下：

1. benchmark 脚本输出

2. jetson_clocks --show 的完整输出，尤其是 GPC 和 EMC

3. D2D cudaMemcpy 带宽

4. 可选：nsys 的 cuda_gpu_kern_sum

有这些数据后，基本可以判断差距来自 EMC／实际内存带宽、热降频，还是仍有其他配置没有对齐。

再次感谢你提供这么完整的测试结果。

[HuLixiaNick531]

感谢你提供完整的 benchmark 脚本、参考数据和排查建议。

重新检查后，我发现之前误用了纯 BF16 的 MTP checkpoint。现在已经改为正确的 FP8 MTP：

Main: /models/flashRT/Qwen3.6-27B-NVFP4
MTP:  /models/flashRT/Qwen3.6-27B-FP8-MTP

其中 MTP projection 是 FP8 E4M3 block-scaled。与此同时，我临时将 SM110 上所有 M <= 8 的 W4A16 widen 调度切换为 default。K=1/K=6 greedy parity 仍然为 PASS。

测试环境

Device:    Jetson AGX Thor Developer Kit, SM110
FlashRT:   d0db114
Container: nvcr.io/nvidia/pytorch:25.12-py3
PyTorch:   2.10.0a0+b4e4ee81d3.nv25.12
CUDA:      13.1
Main ckpt: /models/flashRT/Qwen3.6-27B-NVFP4
MTP ckpt:  /models/flashRT/Qwen3.6-27B-FP8-MTP

1. Benchmark 输出

# device=NVIDIA Thor cc=11.0
# torch=2.10.0a0+b4e4ee81d3.nv25.12 cuda=13.1
# max_seq=16512

   ctx   K   TTFT_ms    dec_ms    tok/s     AL   att   acc
   128   6      325.2    1929.9    32.64   3.86    14    54

K=1/K=6 greedy parity: PASS

参考结果：

TTFT:   266.6 ms
Decode: 1436.4 ms
Speed:  43.86 tok/s
AL:     3.86

相比最初错误的 BF16 MTP + widen 配置，吞吐已经提升到 32.6 tok/s，但距离参考结果 43.86 tok/s 仍有明显差距。

2. jetson_clocks --show

SOC family:tegra264  Machine:NVIDIA Jetson AGX Thor Developer Kit
Online CPUs: 0-13, Offline CPUs:
cpu0:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu1:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu2:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu3:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu4:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu5:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu6:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu7:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu8:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu9:  Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu10: Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu11: Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu12: Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
cpu13: Governor=performance MinFreq=2601000 MaxFreq=2601000 CurrentFreq=2601000 IdleStates: WFI=0 cc7=0
gpu-gpc-0 MinFreq=1575000000 MaxFreq=1575000000 CurrentFreq=1575000000
gpu-nvd-0 MinFreq=1692000000 MaxFreq=1692000000 CurrentFreq=1692000000
EMC MinFreq=4266000000 MaxFreq=4266000000 CurrentFreq=4266000000
PVA0_VPS0: Online=0 MinFreq=0 MaxFreq=1215000000 CurrentFreq=1215000000
PVA0_AXI:  Online=0 MinFreq=0 MaxFreq=909000000 CurrentFreq=909000000
FAN Dynamic Speed Control=nvfancontrol hwmon2_pwm1=28
FAN Dynamic Speed Control=nvfancontrol hwmon2_pwm1_enable=1
NV Power Mode: MAXN

CPU、GPC 和 EMC 均锁定在最高频率，MAXN 已启用，因此目前看可以基本排除 DVFS 或 EMC 未锁频导致的性能差距。

3. D2D cudaMemcpy 带宽

测试使用连续 CUDA tensor 做 D2D copy，预热 10 次，每轮连续复制 20 次，测试 5 轮取中位数。

Size	Payload	Read + Write aggregate
256 MiB	118.23 GB/s	236.47 GB/s
512 MiB	119.48 GB/s	238.97 GB/s
1 GiB	118.36 GB/s	236.73 GB/s

读写合计约为 237-239 GB/s，因此整机内存带宽看起来不足以单独解释 32.6 与 43.9 tok/s 的差距？

4. Nsight Systems

使用 NVTX 分别标记 full generation 和 TTFT，然后将两段 kernel 时间相减，得到纯 decode 的统计结果：

Decode CUDA-event time: 1998.8 ms
GPU kernel time:        1970.0 ms

CUTLASS NVFP4 W4A16:    1644.0 ms   83.45%
BF16 matvec:             124.6 ms    6.32%
GDN recurrent:           104.4 ms    5.30%
Other:                    97.0 ms    4.93%

5. 主要阶段分解

MTP chain K=6:
  当前 38.72 ms
  参考约 28 ms
  慢 10.72 ms / 38.3%

Verify M=7:
  当前约 99.13 ms
  参考约 74.6 ms
  慢 24.53 ms / 32.9%

Verify 当前值根据下面的公式推算：

1929.9 / 14 - 38.72 = 99.13 ms

按 14 个 speculative cycle 计算：

Chain:  10.72 x 14 = 150.1 ms，占总差距约 30%
Verify: 24.53 x 14 = 343.4 ms，占总差距约 70%

6. Tile 对比

以下数据使用正确的 FP8 MTP，在 CUDA Graph 下重复 replay 30 次：

Shape	default	widen	pingpong
lm_head M=1	3.701 ms	6.969 ms	3.733 ms
gate+up M=1	0.539 ms	0.998 ms	0.555 ms
lm_head M=7	3.837 ms	7.028 ms	3.801 ms
gate+up M=7	0.553 ms	1.019 ms	0.555 ms

对应的 weight-only 有效带宽：

lm_head M=1:
  default   193.2 GB/s
  widen     102.6 GB/s
  pingpong  191.6 GB/s

gate+up M=1:
  default   186.0 GB/s
  widen     100.5 GB/s
  pingpong  180.6 GB/s

在当前环境中，widen 比 default / pingpong 慢约 1.8-1.9 倍。M=1 下 default 略快；M=7 下 default 和 pingpong 基本相同。

当前猜测

再次感谢你的帮助。目前看，剩余问题不像是 EMC/D2D 总带宽不足，而更可能是特定 W4A16 shape 的有效带宽、实际访存流量或 verify dispatch 与参考环境不同？

[HuLixiaNick531]

附上完整测试结果

[LiangSu8899]

我这边对比数据觉得你那个判断是对的，可能是特定 W4A16 shape 的有效带宽和参考环境不同。我在我这边用同一个 tile bench 测了一遍，能精确定位到是哪个 shape。

我这边的 tile 数据（同一 bench，CUDA graph replay）

shape (M=1)	tile	我的耗时	有效带宽
gate+up N=34816	default	0.541 ms	67.9%
gate+up	widen	1.008 ms	36.4%
lm_head N=248320	default	2.712 ms	96.6%
lm_head	widen	2.880 ms	91.0%

对比你的：

shape	tile	你	我
gate+up default		0.539 ms	0.541 ms
gate+up widen		0.998 ms	1.008 ms
lm_head default		3.701 ms	2.712 ms
lm_head widen		6.969 ms	2.880 ms

差异很干净

gate+up 两边几乎一模一样（0.539 vs 0.541，widen 也是 0.998 vs 1.008），只有 lm_head 不同。说明：

• 不是时钟/整机带宽——否则 gate+up 也会慢。这跟你测的 EMC 锁死 4266、D2D 237 GB/s 正常是一致的。
• 不是 kernel 版本——fp4_w4a16_gemm_sm120 这个 kernel，从公共 base 到你的 d0db114（Add sm_120 INT4 (E0M3) W4A4 GEMV kernel and OMMA unlock tool #146 只加了 INT4 W4A4 和 OMMA patch，没动这个 GEMM，OMMA patch 也只针对 int4_ 函数）都没改过，两边是同一份。

唯一的区别在 shape：gate+up 只有 89 MB、0.5 ms 的短读，两边都卡在 launch overhead（~185 GB/s），看不出差别；lm_head 是 635 MB、连续 ~3 ms 顶着满带宽读**，我这边能冲到 264 GB/s（96%），你那边到 193（71%）。也就是说，只有大到能吃满带宽的持续读，才把两边板子的差别暴露出来。

我的猜测

最像的是板级对"持续大块读"的降速：短读（gate+up、你 memcpy 的 20 次小拷贝）看不出来，只有 lm_head 这种连续 3 ms 满带宽读的会掉到 71%。可能是持续访存下的内存功耗/热限，或者内存训练（memory training）这次不太理想。verify 里其他大 GEMM 应该也同样受影响，合起来就是你 verify 99 / chain 39 对我 74 / 28 的来源。

下一步建议

1. 重启一次再跑 tile bench——排除这次内存训练 marginal 的情况，先看 lm_head 是不是能回到 ~2.7 ms。
2. 持续读微测：拿 lm_head 那块 635 MB 权重在紧循环里连续读 ~100 ms，看 GB/s 会不会从初始 burst 掉到 ~193；如果掉，就实锤是持续大读被限速了。
3. OMMA patch 跟这条路径无关，不用管它。

widen 那个照旧——我会把 SM110 的 M=1 默认换成 default/pingpong，你带宽被压的时候它惩罚更明显，这个是叠加的。

麻烦你重启后把 tile bench 和持续读的数看一下，应该就能区分是偶发的内存训练还是板子固有的持续读上限了。

---

另外，这是 273 GB/s LPDDR5X 平台已知的 achieved-带宽方差 / 持续负载掉档情况，GB10 上也有人遇到，参考链接：
https://forums.developer.nvidia.com/t/the-ddr-bandwidth-is-significantly-lower-than-the-claimed-273gb-s/363238

重启/持续读微测还是可以试试试看(万一是内存训练能捞回一点)，但基本很可能是这个平台特性，我在其他测试中，以及不同的thor设备上，也会有这种状况，有些设备重启能直接改善，有些设备在负载一段时间后能恢复正常，目前我的测试经历来看，这个现象在不同硬件之间也存在一些差异