最近把手上的 Jetson 参数整理成了一张可以横向对比的表（在线地址，支持 CSV 导出），19 个型号，从 Orin Nano 4GB 一路排到 Thor T5000。表本身没什么好说的，真正有意思的是把它横过来之后冒出来的三个问题：Orin NX 8GB 和 Orin Nano 8GB 的 GPU 是同一块，那多花的钱到底买到了什么；为什么「275 TOPS」和表里的 137.5 正好差一倍；以及 Thor 的算力涨了 3.8 倍、带宽却只涨 1.33 倍，这笔账到底该怎么算。

后半程拿 llama.cpp 和 Jetson AI Lab 的实测数字回来对了一遍，三个问题的答案基本都对得上带宽这条线。

口径：表里的数字是稠密值

这是读这张表最容易踩的坑，先立规矩。

表里的所有算力都是稠密（dense）值，而 NVIDIA 官网大字报和绝大多数中文文章引用的是稀疏（sparse）值，两者默认开着 2:1 的结构化稀疏，差整整一倍。

拿四条数据验一下：

型号 表里（稠密） 官方宣传（稀疏） 倍数
Orin NX 16GB INT8 30 + DLA 20 = 50 100 TOPS 2
AGX Orin 64GB INT8 85 + DLA 52.5 = 137.5 275 TOPS 2
AGX Orin 32GB INT8 54 + DLA 46 = 100 200 TOPS 2
Thor T5000 FP4 1035 2070 TFLOPS 2

四档全部精确对上，说明这个口径是干净的。但含义要说清楚：稀疏带来的那 2 倍，需要模型权重满足 2:4 稀疏模式才能真正吃到。你拿一个普通的 INT8 PTQ 模型上去跑，AGX Orin 64GB 就是 137.5 TOPS，不是 275。

这也是为什么你会看到「Thor 是 Orin 的 7.5 倍」和「3.8 倍」两种说法。差别不在稀疏，在精度档位：7.5 倍是拿 Thor 的 FP4（2070 稀疏 / 1035 稠密）去比 Orin 的 INT8（275 / 137.5），分子分母的精度不一样，无论走稀疏还是稠密都算出 7.53；3.8 倍是在同一档 INT8 下比（517.5 vs 137.5 = 3.76），那才是同一把尺子。

Orin 的切法：一颗 Die 切四刀

Orin 这一代最有意思的地方在于，从 4GB 的 Nano 到 64GB 的 AGX 用的是同一颗 GA10B。差别只在切几刀：

型号 SM CUDA Tensor Core TPC DLA（稠密 INT8） 位宽 带宽
AGX Orin 64GB 16 2048 64 8 52.5 256 204.8
Orin NX 16GB 8 1024 32 4 20 128 102
Orin Nano 8GB 8 1024 32 4 — 128 68
Orin Nano 4GB 4 512 16 2 — 64 34

（位宽单位 bit，带宽单位 GB/s，DLA 单位 TOPS）

一张表看完，两个结论自己就浮出来了。

第一，Orin Nano 8GB 和 Orin NX 8GB 的 GPU 完全一样。 同样 8 个 SM、1024 个 CUDA、32 个 Tensor Core、4 个 TPC。差别只有两处：GPU 频率 625 vs 765 MHz，内存带宽 68 vs 102 GB/s。前者带来 22% 的 FP32（1.28 vs 1.57 TFLOPS），后者带来 50% 的带宽。所以「NX 比 Nano 快」这件事，真正起作用的不是算力，是带宽。

第二，Orin Nano 这一档根本没有 DLA。 想做多路相机的传统 CV 推理、或者把 CNN 从 GPU 卸载到 DLA 上跑，Nano 从硬件上就没这个能力，TensorRT 里 --useDLACore 那几条配置也就无从谈起。

顺带一提，Orin NX 8GB 升到 16GB 加的也不是 GPU：GPU 核心一个没多，多出来的是两个 CPU 核（6→8）、8GB 内存和更高的频率（765→918 MHz）。DLA 两档都是 20 TOPS，完全一样。

还有个容易被忽略的细节：Orin Nano 4GB 是 64-bit 位宽，8GB 才是 128-bit。同样是 Nano，4GB 那档的带宽只有 34 GB/s，是 8GB 的一半。买之前看清 SKU，别按「Nano」这个名字一刀切。

SUPER 改了什么

「SUPER」这个名字容易让人以为是换了一代，实际上它改的是频率、功耗墙和 DLA 数量，架构一点没动。

型号 CUDA 频率 DLA 带宽 TDP
Orin Nano 4GB 512 625 → 1020 MHz 无 34 → 51 GB/s 7/10 → 7-25 W
Orin Nano 8GB 1024 625 → 1020 MHz 无 68 → 102 GB/s 7/15 → 15-25 W
Orin NX 8GB 1024 765 → 1173 MHz 10 → 20 TOPS 102 GB/s 不变 10-20 → 10-40 W
Orin NX 16GB 1024 918 → 1173 MHz 20 → 40 TOPS 102 GB/s 不变 10-25 → 10-40 W

有三件事值得记下来。

NX 的 DLA 翻倍了。 只有提频的话，10 → 20 TOPS 需要频率涨一倍，而 GPU 只涨了 53%，所以这大概率是加了第二个 DLA 实例。这让 NX 16GB SUPER 的稠密总量到了 78 TOPS（INT8 38 + DLA 40），对应官方 157 TOPS 的稀疏口径。

SUPER 之后两颗 NX 的 GPU 变成同一颗了。 8GB 和 16GB 的 SUPER 都是 1024 CUDA @ 1173 MHz，完全一致。两档的差别只剩内存容量、CPU 核数（6 vs 8）和 DLA 档位（20 vs 40 TOPS）。

另外，Orin Nano 的 SUPER 不只是提频：8GB 那档的带宽从 68 涨到 102 GB/s（内存速率从 4266 提到 6400 MT/s，位宽仍然是 128-bit）。对 LLM 来说这一项比频率更值钱，后面实测会看到。

Thor：算力和带宽脱钩了

从 AGX Orin 64GB 到 Thor T5000，几个关键数字并排：

项目 AGX Orin 64GB Thor T5000 倍数
稠密 INT8 137.5 TOPS 517.5 TOPS 3.76×
FP4 无 1035 TFLOPS —
内存带宽 204.8 GB/s 273 GB/s 1.33×
内存容量 64 GB 128 GB 2×
CPU 12× A78AE @ 2.2 GHz 14× Neoverse-V3AE @ 2.6 GHz —
TDP 15-60 W 40-130 W 2.2×

算力 3.76 倍，带宽 1.33 倍，TDP 2.2 倍。这三个数字的相对关系，基本决定了 Thor 适合什么、不适合什么。

CPU 那一栏的换代比核数更重要。A78AE 是从手机核 A78 派生的车规版，在 Orin 上做前处理、解码、数据搬运时很容易把 12 个核打满；Neoverse-V3AE 是服务器级的核，缓存和内存子系统的底子完全不是一个量级。同时 130 W 的功耗墙也意味着 T5000 必须配主动散热，不再是一块能塞进巴掌大外壳的板子。

GPU 那一栏还第一次出现了 MIG 的字样（T4000 是「6 TPC MIG」，T5000 是「10 TPC MIG」）。如果按字面理解，Thor 支持按 TPC 把 GPU 切分给不同的安全域或租户——这在 Jetson 上是新东西，对做多路隔离的车载方案意义不小。当然目前能看到的信息还只有一个词，具体怎么切、切完性能怎么分，得等文档。

T2000 和 T3000 还没有出货

表里还有两个 Blackwell 型号：T3000 和 T2000。它们是 NVIDIA 在 2026 年 7 月发布的，但要等到 2027 Q1 才上市，目前只能靠 AGX Thor 开发套件的仿真模式来评估。

按官方口径，T3000 是 865 FP4 TFLOPS（稀疏，对应表里的 432.5 稠密）、32GB LPDDR5X、273 GB/s 带宽、8 核 Neoverse、25 GbE，体积和功耗都大约是 T5000 的一半；T2000 是 400 FP4 TFLOPS（稠密 200）、16GB 内存、137 GB/s。

这里有个细节值得留意：NVIDIA 说 T3000 在多模态负载上的推理性能「接近 T5000」。可 T3000 的峰值算力只有 T5000 的 42%（432.5 vs 1035 FP4），两者唯一持平的是 273 GB/s 的带宽。这句话能成立，本身就是「带宽比峰值算力更能解释实际吞吐」的旁证——也正是后面几节要展开的那条线。

所以这两个型号我只在表里保留参数，不参与下面的横向比较：没有公开的 FP32/FP16 数字，也没有第三方实测，比了没意义。等真机出来再补。

拿 llama.cpp 的实测对一遍

前面几节反复在说 decode 受带宽限制。这句话其实是个可以验算的算术命题：每生成一个 token 都要把权重完整读一遍，所以速度上界就是带宽 ÷ 权重文件大小。上界按真实 GGUF 体积算，不做任何理想化折算，然后拿真机数据来对。

先看 Orin Nano 8GB（SUPER 档，25W，JetPack 7.2.1，llama.cpp CUDA 后端，Q4_K_M，4k 上下文，全量 offload）和 AGX Orin 64GB（JetPack 6.1，llama.cpp CUDA 后端，Q4_K_M，全量 offload）的 decode 速度：

板子 带宽 模型权重 上界 实测生成 达成率
Orin Nano 8GB SUPER 102 Qwen3 8B 5.03 GB 20.3 12.64 62%
Orin Nano 8GB SUPER 102 Qwen3 4B 2.50 GB 40.8 19.53 48%
Orin Nano 8GB SUPER 102 Llama 3.2 3B 2.02 GB 50.5 25.24 50%
Orin Nano 8GB SUPER 102 Qwen3 1.7B 1.11 GB 91.9 39.42 43%
AGX Orin 64GB 204.8 Llama 3.1 8B 5.26 GB 38.9 28 72%
AGX Orin 64GB 204.8 Qwen2.5 7B 5.05 GB 40.6 31 76%
AGX Orin 64GB 204.8 Phi-3 Mini 3.8B 2.58 GB 79.4 47 59%

（Orin Nano 数据取自 Turing Pi 的 llama-bench tg128 五轮均值；AGX Orin 数据取自 MultimodalFlow 的实测。两者都是第三方测试，量化文件和参数不完全可比，看量级。）

结论比预想的整齐：7～8B 这一档，实测落在带宽上界 62% 到 76% 之间，而且带宽翻倍之后达成率还更高（AGX Orin 72%～76% vs Nano 62%）。说明 AGX Orin 那块板子本来就有余量，Nano 更像是被带宽和固定开销一起卡住。

但模型越小，离上界越远：3.8B 掉到 59%，3B 是 50%，1.7B 只剩 43%。原因是每个 token 都有不随权重变化的固定开销——采样、kernel launch、Python/HTTP 层的调度。Qwen3 1.7B 的上界是 91.9 tok/s，实测 39.4，剩下的 50 多 token/s 全是这些开销吃掉的。所以「小模型就一定快」在端侧并不成立，换小模型能省的是内存，不是延迟。

后端的影响和换块板子差不多

Jetson AI Lab 的 benchmarks 页上有一份 MLC 后端的 Orin Nano Super 数据（INT4 量化），和上面的 llama.cpp 数据摆在一起很有信息量：

模型 Orin Nano（原版） Orin Nano Super 提升
Llama 3.1 8B 14 19.14 1.37×
Qwen2.5 7B 14.2 21.75 1.53×
Llama 3.2 3B 27.7 43.07 1.55×
Gemma 2 9B 7.2 9.21 1.28×
Phi 3.5 3B 24.7 38.1 1.54×
SmolLM2 41 64.5 1.57×

同样一块 Orin Nano 8GB（SUPER，102 GB/s），MLC 跑 Llama 3.1 8B 是 19.14 tok/s，而上面 llama.cpp 跑 Qwen3 8B 是 12.64，差 1.51 倍。这个差值里混了三个变量：后端（MLC vs llama.cpp）、量化方案（INT4 vs Q4_K_M）、以及词表大小（Qwen3 的 15 万词表让它的 embedding 层明显更大，GGUF 也因此到 5.03 GB）。公开数据拆不开这三者，但能确定一件事：同样的带宽，不同的软件栈能差出 1.5 倍。 带宽是天花板，天花板下面还有很大的地板。

原版到 SUPER 的这组提升（1.28～1.57 倍）也值得看一眼。Llama 3.1 8B 从 14 涨到 19.14，是 1.37 倍；而这台机器的带宽从 68 涨到 102 GB/s（1.5 倍），GPU 频率是 1.63 倍。实测提升低于这两个单因素中的任何一个，说明 decode 不是被单一指标线性决定的——带宽是上限，但上限之下还有调度、算子效率、KV cache 布局这些变量。反过来看，这也解释了为什么单纯「提频」的收益总是不如参数表上的数字好看。

Thor 上的 70B

Thor 这边，NVIDIA 自己在技术博客里给了 Llama 3.3 70B（W4A16，vLLM）的数据：35 GB 权重，273 GB/s 带宽，单流上界 7.8 tok/s。

配置 结果 说明
vLLM，并发 1 6.27 tok/s 单流上界 7.8 的 80%
vLLM，并发 8 41.5 tok/s 总吞吐（每流 5.19） batch 摊薄了权重读取，总吞吐自然能超过单流上界
vLLM + EAGLE-3 投机解码，并发 1 16.19 tok/s 单流上界的 2.1 倍

第一行是 80%，和 Orin 上的 62%～76% 属于同一量级——跨了两代硬件和两套软件栈，这条规律依然成立。

后两行是这套模型的边界。并发 8 的总吞吐超过单流上界 5 倍多，不矛盾——batch 之后权重只读一遍就能给 8 个序列用，所以「带宽上界」约束的是单流，不是总吞吐。而第三行更彻底：投机解码直接绕过了这个前提。EAGLE-3 一次前向验证多个候选 token，不再需要「每生成一个 token 就读一遍全量权重」，于是 16.19 远高于 7.8。

所以本文的带宽模型只在「朴素自回归、batch=1」时成立。这是端侧最常见的默认形态，但不是唯一形态，也不是未来的形态。

这里有个容易误读的地方：Thor 的 FP4 计算单元不是给 decode 准备的。 decode 的上界由「权重的字节数」决定，和用什么指令去算几乎无关；而把权重压到 4-bit 这件事，Ampere 上照样能做——llama.cpp 的 Q4_K_M、TensorRT-LLM 的 INT4 AWQ、NVIDIA 自己在 Thor 上推荐的 W4A16，都是 weight-only 量化，不依赖 FP4 单元。上面 c=1 的 6.27 tok/s 已经贴着 273 GB/s 的物理上限走了，说明这一档没有留给「更快的计算单元」的余量。FP4 真正兑现收益的是 prefill 和 batch>1：那里激活值也要走矩阵乘，是算力密集型，才轮得到第五代 Tensor Core 发挥。

Prefill：算力开始说话的地方

Orin Nano 8GB SUPER 上实测的 prefill 吞吐（pp512，同样是 llama-bench 五轮均值）：

模型 prefill 速度 换算成 1024 token 的 prompt
Qwen3 8B 355.5 tok/s 约 2.9 s
Llama 3.2 3B 813.7 tok/s 约 1.3 s
Qwen3 1.7B 1408.3 tok/s 约 0.7 s

这个数字很能说明问题：1024 token 的 prompt 在 Orin Nano 上要将近 3 秒才吐第一个字，而 decode 阶段的上界是 20 tok/s。也就是说，长 prompt 场景里，用户感受到的延迟几乎全在 prefill 上，而这部分恰好是算力而不是带宽决定的。

按稠密 INT8 量级看，Orin Nano SUPER 是 33 TOPS，AGX Orin 64GB 是 137.5，Thor T5000 是 517.5——15.7 倍的算力跨度，而带宽只有 2.7 倍（102 到 273）。所以从 Orin Nano 换到 Thor T5000，prefill 的收益会远大于 decode 的收益。

需要提醒的是，pp512 是合成测试，真实 chat template 的 prompt 长度、系统提示词、工具调用描述都会让 TTFT 难看不少。上表的「约 2.9 秒」只是一个下限。

最后

参数表这种东西，价值不在背数字，在回答一个具体问题：这块板子跑不动，到底是算力不够还是带宽不够。

Orin 时代的答案多半是带宽——Nano 8GB 和 NX 8GB 的 GPU 配置一模一样，差的是 50% 的带宽和一个 DLA；而带宽那一半，在 LLM 上直接就是 50% 的出字速度，llama.cpp 的实测也把 7～8B 这一档钉在了带宽上界的 62%～76%。

Thor 时代 NVIDIA 把算力拉开了 3.8 倍，带宽只给了 1.33 倍，于是问题反过来：算力溢出、带宽不足，decode 被钉在 273 GB/s 上不动。真正拉开差距的是 prefill——那里吃的是算力，而算力这一代涨得比带宽凶。

这个不对称才是 2026 年之后端侧 LLM 的真实形状。等哪一代 Jetson 把带宽也翻上 3 倍，或者把投机解码做到默认可用，端侧大模型的产品形态才会跟着变一次。

本文所有数字都来自这张表，随官方文档持续更新：Jetson 系列参数对比。