Jetson AGX Thor 官方 LLM 跑分可信吗？我在真实部署环境复测了一次
NVIDIA 官方 Jetson benchmark 页面已经给出了一组很漂亮的 Jetson AGX Thor LLM / VLM 数据：Llama、Qwen、DeepSeek、Qwen2.5-VL 等模型都用 tokens/sec 的方式列了出来。
这些数字有没有价值？有。
能不能直接当成你项目上线后的速度？不能。
本文不把官方数据简单说成"虚标"，也不把真实部署里的低速结果说成"设备不行"。更准确的说法是：官方 benchmark 是在清晰、受控、优化过的条件下测出来的上限参考；真实工程环境需要重新定义 workload。
为了避免只停留在讨论，我也连接到一台正在跑真实服务的 Jetson AGX Thor 测试机（下文记为 thor-test），在不停止后台服务、不清空桌面环境、不重新拉模型的情况下，用现有 SGLang 服务做了一组轻量复测。
官方数据到底测了什么
根据 NVIDIA Jetson Benchmarks 页面，Jetson AGX Thor 的生成式 AI benchmark 条件大致如下：
| 项目 | 官方条件 |
|---|---|
| 设备 | NVIDIA Jetson AGX Thor Developer Kit |
| 系统 | JetPack 7.0 |
| CUDA | 13.0 |
| TensorRT | 10.13 |
| 推理框架 | vLLM |
| 输入 / 输出长度 | ISL 2048 / OSL 128 |
| 并发 | C=1 与 C=8 |
官方公布的部分 LLM / VLM 结果：
| 类型 | 模型 | C=1 tokens/s | C=8 tokens/s |
|---|---|---|---|
| LLM | Llama 3.1 8B | 41.3 | 150.8 |
| LLM | Llama 3.3 70B | 4.7 | 12.6 |
| LLM | Qwen 3 30B-A3B | 61.0 | 226.4 |
| LLM | Qwen 3 32B | 13.19 | 79.1 |
| LLM | DeepSeek R1 7B | 41.32 | 304.8 |
| LLM | DeepSeek R1 32B | 13.31 | 82.6 |
| VLM | Qwen2.5-VL 3B | 71.7 | 356.86 |
| VLM | Qwen2.5-VL 7B | 45.0 | 252.0 |
| VLM | Llama 3.2 11B Vision | 26.31 | 69.63 |
来源：NVIDIA Jetson Benchmarks 页面，数据抓取时间为 2026-07-27。
这里最重要的不是某个单点数字，而是测试条件：vLLM、固定 ISL/OSL、明确并发、官方软件栈。
如果你的项目用的是 llama.cpp、SGLang、Ollama、不同量化格式、不同上下文长度，或者设备上还跑着摄像头、ROS、Web 服务和 Python 任务，那结果自然不该一模一样。
为什么真实部署经常跑不到官方数字
1. tokens/s 不是一个单一指标
LLM 推理至少要分两段看：
| 阶段 | 主要受什么影响 | 用户体感 |
|---|---|---|
| Prefill | 输入长度、KV cache、batch、注意力实现 | 首 token 延迟 |
| Decode | 模型大小、量化、内存带宽、并发调度 | 后续输出速度 |
官方表格使用 ISL 2048 / OSL 128，这是一个明确 workload。但真实聊天、Agent、RAG、视觉问答并不总是 2048 输入、128 输出。
一个 RAG 请求可能塞进 8K token 上下文；一个机器人状态摘要可能只有 200 token 输入；一个代码 Agent 可能连续调用工具并反复追加历史。它们的性能瓶颈完全不同。
2. 并发吞吐和单用户延迟不是一回事
官方 C=8 数字通常明显高于 C=1，因为并发请求可以提高 GPU 利用率。比如 Qwen 3 30B-A3B 在官方表中 C=1 是 61 tokens/s，C=8 是 226.4 tokens/s。
这并不表示单个用户会看到 226 tokens/s。它表示在 8 路并发下，系统总吞吐量更高。
如果你做的是现场工程师手持平板问答，单请求延迟更重要。
如果你做的是工厂多路摄像头事件摘要，总吞吐更重要。
3. 推理框架差异非常大
同一个模型在不同引擎上可能完全不是一个速度：
| 引擎 | 优势 | 常见代价 |
|---|---|---|
| vLLM | 高吞吐、PagedAttention、并发调度成熟 | 容器和依赖较重，边缘端调参更多 |
| SGLang | 适合结构化生成、Agent 和服务化 | 不同模型支持差异明显 |
| llama.cpp | GGUF 生态成熟，部署简单 | 极限吞吐通常不如专门优化的服务端栈 |
| Ollama | 使用门槛低，适合快速验证 | benchmark 可控性较弱 |
| TensorRT-LLM / Edge-LLM | NVIDIA 栈优化潜力最大 | 构建、导出和调试成本最高 |
官方 benchmark 使用 vLLM，不等于你的 llama.cpp GGUF 结果应该接近它。
4. 边缘设备不是空跑模型
真实 Jetson 设备经常同时运行：
- 摄像头采集与编码
- ROS / Isaac ROS 节点
- 目标检测或 VLM 管线
- Web API 服务
- 日志、监控、远程访问
- Python 自动化脚本
这些任务会吃掉 CPU、内存带宽、GPU kernel 调度空间和热设计余量。实验室跑分看的是模型，工程部署看的是系统。
真实部署环境：thor-test 当前状态
这次复测不是干净实验室环境，而是一台已经连续运行服务两周的 Thor：
| 项目 | 状态 |
|---|---|
| 主机 | thor-test |
| 系统 | Ubuntu 24.04.3 LTS |
| L4T | R38.2.2 |
| Kernel | 6.8.12-tegra |
| 功耗模式 | MAXN |
| 内存 | 122 GiB 总量，测试前约 61 GiB 已用 |
| 空闲温度 | GPU 约 58-60C，CPU / Tj 约 60C |
测试时机器上已经运行：
| 服务 | 说明 |
|---|---|
| SGLang 模型服务 | Qwen2.5-7B-Instruct |
| 向量检索服务 | 用于本地 RAG / 文档检索 |
| 文本搜索服务 | 用于关键词检索 |
| 本地模型管理服务 | 用于快速验证其他模型 |
| 桌面与远程管理进程 | 模拟真实维护环境 |
这类状态更接近真实边缘 AI 机器：模型服务不是唯一负载，设备上还要承担检索、管理、远程访问和其他应用进程。
复测结果：SGLang + Qwen2.5-7B-Instruct
当前常驻模型：
Runtime: SGLang
Container image: nvcr.io/nvidia/sglang:26.04-py3
Model: Qwen2.5-7B-Instruct
Context length: 4096
mem-fraction-static: 0.3
API: OpenAI-compatible /v1/chat/completions
单请求测试
每个请求 max_tokens=160，非流式返回：
| Case | Prompt tokens | Completion tokens | Time | Completion tokens/s |
|---|---|---|---|---|
| 中文边缘 AI 问答 | 46 | 136 | 8.180s | 16.63 |
| 英文摘要 | 44 | 65 | 3.958s | 16.42 |
| JSON 输出 | 50 | 32 | 1.993s | 16.06 |
这个结果很稳定：在有后台服务、桌面、检索组件和远程管理进程的情况下，Qwen2.5-7B-Instruct 的单请求 decode 大约是 16 tokens/s。
4 并发测试
然后我发起 4 个并发请求，每个请求最多输出 128 token：
| 指标 | 结果 |
|---|---|
| 并发数 | 4 |
| 总 wall time | 8.959s |
| 总 completion tokens | 505 |
| 聚合 completion tokens/s | 56.37 |
| 单请求耗时 | 8.534-8.957s |
这组数据正好说明了官方 C=1 / C=8 表格为什么要分开看：并发可以显著提高总吞吐，但单个用户看到的延迟不会按同样比例下降。
和官方 benchmark 怎么比较
这次复测不能直接对标 NVIDIA 官方的 Qwen 3 30B-A3B 或 Qwen 3 32B 结果，因为条件不同：
| 维度 | 官方 benchmark | thor-test 复测 |
|---|---|---|
| 系统 | JetPack 7.0 | L4T R38.2.2 / Ubuntu 24.04.3 |
| 框架 | vLLM | SGLang |
| 模型 | Qwen 3 系列等 | Qwen2.5-7B-Instruct |
| ISL / OSL | 2048 / 128 | 短 prompt / 最多 160 输出 |
| 设备状态 | benchmark 环境 | 真实服务运行中 |
| 后台负载 | 未知但受控 | 模型服务、检索服务、本地模型管理、桌面与远程管理进程 |
所以正确结论不是"官方快、实测慢"，而是：
在真实服务环境里，Thor 仍然可以稳定提供 7B 级模型的本地 API；单请求约 16 tokens/s，4 并发总吞吐约 56 tokens/s。
如果目标是复现官方表格，需要再做一次更严格的测试：同一 JetPack / CUDA / TensorRT / vLLM / 模型 / ISL / OSL / 并发设置。
之前的大模型测试作为参照
之前我在 Jetson AGX Thor 上跑过 Qwen3.6-35B-A3B-FP8，使用 SGLang 服务方式，测试时设备并不是干净环境。
观测结果约为：
| 模型 | 框架 | 条件 | 结果 |
|---|---|---|---|
| Qwen3.6-35B-A3B-FP8 | SGLang | 已有后台负载，160 token 响应 | 约 14 tokens/s |
这个数字不能直接和官方 Qwen 3 30B-A3B 的 vLLM 结果对打，因为模型、框架、prompt 长度、负载状态都不同。但它说明了一个更重要的事实：
Thor 的硬件空间足够跑中大型本地模型；真正决定体验的是运行栈、并发策略和你的实际 workload。
如果把测试机清空、升级到官方 JetPack 7.0 软件栈、使用同一模型与 vLLM，再固定 ISL 2048 / OSL 128，才有资格做更严谨的 apples-to-apples 对比。
我会如何复测官方 benchmark
如果目标是判断自己的 Thor 是否接近官方状态，我会这样测。
第一步：固定系统快照
cat /etc/nv_tegra_release
uname -a
nvidia-smi || true
python3 -V
free -h
df -h
Jetson 上不同 JetPack、CUDA、容器版本差异很大。不要只记录"Thor"，要记录完整软件栈。
第二步：固定功耗与温度条件
sudo nvpmodel -q
sudo jetson_clocks --show
tegrastats
跑分前让设备进入稳定状态，记录空闲温度和功耗。边缘设备的热状态会直接影响长时间吞吐。
第三步：用官方 workload 先复测
先不要急着测自己的业务 prompt。先按官方设定建立基线：
| 参数 | 建议 |
|---|---|
| ISL | 2048 |
| OSL | 128 |
| 并发 | 1、8 |
| 框架 | vLLM |
| 指标 | prefill tokens/s、decode tokens/s、端到端延迟、峰值内存 |
只有这一步跑完，才知道自己的设备、系统和容器有没有明显问题。
第四步：再测业务 workload
真实部署至少补三组：
| 场景 | 输入 | 输出 | 重点 |
|---|---|---|---|
| 交互问答 | 512-2K | 128-512 | 首 token 延迟 |
| RAG 问答 | 4K-16K | 256-1K | 长上下文吞吐 |
| Agent / JSON | 1K-8K | 多轮短输出 | 格式稳定性与工具调用 |
VLM 还要单独记录图像分辨率、图像数量、视觉 encoder 时间和总延迟。
怎么解读 Thor 的官方数字
我的建议是把官方 benchmark 当成三类信号。
信号一：模型能不能放进边缘设备
Llama 3.3 70B、Qwen 3 32B、DeepSeek R1 32B、Qwen2.5-VL 7B 都出现在 Thor 官方表里，这本身就很重要。
它说明 Thor 的 128GB 级统一内存让边缘设备第一次真正进入了"几十 B 参数模型可本地服务"的区间。
信号二：MoE 模型在边缘端非常值得关注
Qwen 3 30B-A3B 的官方 C=1 是 61 tokens/s，C=8 是 226.4 tokens/s。这个数字的核心不是"30B 比 8B 还快"，而是 MoE 的激活参数只有一部分。
对边缘部署来说，MoE 的吸引力很直接：模型容量大，但每次前向激活较少。代价是路由、框架支持和量化格式要更仔细。
信号三：VLM 才是 Thor 最有差异化的方向
Qwen2.5-VL 3B / 7B、Llama 3.2 11B Vision 这类结果比纯文本 LLM 更值得边缘 AI 团队关注。
因为 Thor 的真实场景很少只是聊天。它更可能是：
- 看摄像头画面
- 读仪表盘
- 解释异常截图
- 结合语音和图像做现场助手
- 给机器人或工业设备生成行动建议
这也是 MultimodalFlow 后续更值得持续测试的方向。
选型建议
| 目标 | 优先测试 |
|---|---|
| 单用户本地助手 | C=1、首 token、decode tokens/s |
| 多路 API 服务 | C=4 / C=8 总吞吐、P95 延迟 |
| RAG 知识库 | 8K / 16K 输入下的 prefill 时间 |
| 工业视觉问答 | VLM 图像编码时间 + 总响应时间 |
| 机器人 Agent | 多轮稳定性、JSON / tool call 成功率 |
| 离线现场部署 | 热稳定、掉电恢复、日志与监控 |
如果你只看一个 tokens/s 数字，很容易选错模型。
如果你把 workload 拆开，Thor 的价值会清楚很多。
结论
Jetson AGX Thor 官方 benchmark 不是没意义的营销数字。它提供了一个很有价值的上限参考：在 JetPack 7.0、CUDA 13.0、TensorRT 10.13、vLLM 和固定 ISL/OSL 条件下，Thor 能把几十 B 级 LLM / VLM 跑到什么范围。
但真实部署时，你要重新测四件事：
- 你的模型
- 你的推理框架
- 你的上下文长度和并发
- 你的设备后台负载和热状态
我更关心的不是"能不能复刻官方最高值"，而是：在摄像头、RAG、Agent、现场服务同时存在的边缘系统里，Thor 能不能持续给出可用延迟。
这才是边缘 AI 部署真正需要的 benchmark。