在边缘端运行推理和智能体 AI，一直比它本该有的难度更高。直到不久前，具备多步推理能力的模型还太大，无法在边缘硬件上本地运行。构建智能体的开发者只能把推理请求路由到数据中心，既增加了网络依赖和成本，也可能暴露本应留在设备端的数据。
这一限制正在消除。整个夏天发布的几个模型系列，共同标志着边缘 AI 的转折点。这一代新的小型开源模型，已经能提供几个月前还需要大型数据中心系统才能实现的推理和智能体能力，而 NVIDIA Jetson 如今就能运行它们。
这可以为驾驶舱内助手、实时异常检测，以及在恶劣或偏远环境中作业的机器人提供支持。现场专家可以减少排障时间，在网络连接受限或中断时，关键系统也能继续运行。
本文以 Nemotron 3.5 Lightning 和 Qwen3.8-27B 为例，介绍在 Jetson 上部署这一代新开源模型需要了解的内容。你将了解比较模型架构时该关注什么，如何运用推理优化技术充分发挥硬件性能，以及如何针对自己的工作负载验证配置。
具体来说，本文回答以下开发者问题：
- 如何为 Jetson 选择推理模型？
- NVFP4 量化和推测解码（speculative decoding）如何提升推理性能？
- 如何用 vLLM 部署 Nemotron 3.5 Lightning 和 Qwen3.8-27B？
- 如何针对你的应用验证配置？
下方图 1 展示了这一转变。它按模型规模和发布日期绘制了 Artificial Analysis Intelligence Index。2026 年发布的开源模型，得分已接近 2025 年的领先模型，而参数量少得多。
如何为 Jetson 选择推理模型？
更好的训练方法和更高效的架构推动了这一变化。例如，蒸馏（distillation）把 Nemotron 3 Ultra 的部分能力迁移到了更小的 Nemotron 3.5 Lightning 模型中。不同的架构也会在能力、内存占用和生成速度之间形成不同的取舍。
Qwen3.8-27B 是稠密模型，每个 token 都会激活全部 270 亿个参数。Nemotron 3.5 Lightning 采用混合专家（MoE）架构，总参数量为 300 亿，但每个 token 只激活 30 亿。因此这两个模型适合不同类型的工作负载。
这些差异对长时间运行的智能体尤为重要。例如，智能体可以利用实时传感器数据和设备日志监控系统，执行经过批准的纠正操作，对照预定义测试验证结果，仅在需要时才上报给专家。这一切都在边缘端本地运行，无需联网，延迟也很低。
Nemotron 3.5 Lightning 很适合这类响应密集的工作流，更快的 token 生成可以缩短整个流程的耗时。Qwen3.8-27B 则更适合决策次数较少但难度更高的任务，这类任务允许智能体花更多时间生成每次响应。
在选定模型之前，请针对你的应用所需的决策、工具和响应模式，对两个模型分别做基准测试。
在 Jetson 上，这些智能体循环可以紧挨着它们所服务的传感器和系统运行。你可以通过 vLLM 和 llama.cpp 等主流框架在本地部署模型，让推理循环不必完全依赖数据中心。
Gemma 4 E4B 是 Jetson Orin Nano 的理想起点。对于 Jetson AGX Orin 和 Jetson AGX Thor，Nemotron 3.5 Lightning 和 Qwen3.8-27B 是不错的选择。这些模型系列都有高质量的量化检查点，并在主流推理引擎上提供了优化的部署方案。
如何在 Jetson 上优化推理模型的推理性能？
有两种互补的技术可以提升推理性能：NVFP4 量化减少模型运算所需的计算量和内存，而推测解码可以在每个验证步骤中生成多个被接受的 token。
模型架构决定了起点，但部署选择同样会影响性能。下方图 2 对比了两个模型在 BF16、NVFP4，以及 NVFP4 加上我们为每个模型测得的最快推测解码配置下的表现。
如上方图 2 所示，我们逐项加入两种优化。BF16 作为基线，NVFP4 加入量化，最终配置则把 NVFP4 与我们为每个模型测得的最快推测解码配置结合起来。
解码时，模型一次生成一个 token 来构成响应。每个 token 通常都需要再过一遍模型。这给了你两种提升性能的方式：减少每一遍的计算量，或让每一遍产出更多 token。
量化采用的是第一种思路。低精度数值减少了 GPU 在每一遍中需要搬运和处理的数据量。借助 NVFP4 这样的格式，你可以提升生成速度、降低内存占用，同时让质量保持接近 BF16。
推测解码采用的是第二种思路。较小的草稿模型提出若干 token，主模型再一并验证。最终决定仍由主模型做出。如果它接受了多个提议的 token，生成就能在一个验证步骤中前进多个 token。
下方视频 1 展示了使用与不使用推测解码时的响应生成过程，直观呈现了由此带来的加速。
▶ https://www.youtube.com/watch?v=N4r-2-Yp5Zw
视频 1. 在 NVIDIA Jetson 上对比 Qwen3.5 9B NVFP4 在使用与不使用推测解码时的推理
有多种方法可以生成这些草稿，包括 MTP、DFlash 和 DSpark。三者都能在 Jetson 上运行，但生成和评估提议的方式各不相同。我们测试了现有的方法和草稿检查点，而不是假定某一种配置对所有模型都最优。
这两种优化相辅相成。NVFP4 降低了每一遍的成本，推测解码则增加了每一遍产出的被接受 token 数。两者结合，性能提升超过任何单一优化。
两个模型的最快推测解码配置并不相同。Nemotron 3.5 Lightning 搭配 DSpark 表现最好，Qwen3.8-27B 则搭配 DFlash2 最好。请针对你计划部署的模型测试方法和草稿检查点，而不要假定某一种配置对所有模型都最优。
前提条件
运行以下命令之前，请确认你已具备：
- 一台 Jetson AGX Thor 或 Jetson AGX Orin
- 已配置 NVIDIA Container Runtime 和 Docker 的 JetPack 7.2。
- 足够存放模型和草稿检查点的存储空间
- 已接受 NVIDIA Nemotron 和 Qwen3.8 检查点的许可条款
对于 Nemotron 3.5 Lightning，你可以在 Jetson AGX Thor 或 Jetson AGX Orin 上运行我们测得的最快配置，即 NVFP4 与 DSpark 的组合。
首先，启动 vllm/vllm-openai:v0.28.0 容器：
docker run --pull=always --runtime nvidia --rm -it \
--network host \
--ipc=host \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--entrypoint bash \
vllm/vllm-openai:v0.28.0
然后，在容器内运行以下命令：
vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
--reasoning-parser nemotron_v3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--max-model-len 128000 \
--kv-cache-dtype fp8 \
--gpu-memory-utilization 0.7 \
--trust-remote-code \
--max-num-batched-tokens 16384 \
--enable-prefix-caching \
--speculative-config '{"method":"dspark","model":"nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark","num_speculative_tokens":5}' \
--mamba-backend flashinfer \
--mamba-ssm-cache-dtype float16 \
--enable-mamba-cache-stochastic-rounding \
--mamba-cache-philox-rounds 5 \
--mamba-cache-mode align
对于 Qwen3.8-27B，你可以使用上面命令启动的同一个容器，并通过以下命令在 Jetson AGX Thor 或 Jetson AGX Orin 上运行我们测得的最快配置，即 NVFP4 与 DFlash2 的组合：
VLLM_GDN_DECODE_KERNEL=triton vllm serve Inferact/Qwen3.8-27B-NVFP4 \
--served-model-name qwen38 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--max-model-len 50000 \
--max-num-seqs 8 \
--gpu-memory-utilization 0.85 \
--trust-remote-code \
--speculative-config '{"method":"dflash","model":"incoai/Qwen3.8-27B-DFlash2","num_speculative_tokens":7}'
每种方法创建和评估草稿 token 的方式各不相同，这会影响其提议的成本和准确率。
MTP 使用与主模型一起训练的预测头来提出若干未来 token。现在，你可以在许多主流模型系列上使用 MTP，包括 Qwen、Gemma 和 Nemotron。
DFlash 使用独立的基于扩散的草稿模型，并行提出一整块 token。目前它支持的兼容草稿检查点最为丰富。DSpark 在 DFlash 的基础上增加了草稿修正，并会提前终止质量较差的提议。有匹配的检查点时，DSpark 可能更快，但它支持的检查点较少。
用有代表性的工作负载验证性能
模型层面的基准测试可以帮你找出一个表现出色的推测解码配置。然而，不同应用生成的文本类型各异，性能也会随工作负载而变化。为了衡量这种影响，我们固定每个模型的最快配置，测试了 SpeedBench 的四个类别：写作、推理、摘要和检索增强生成（RAG）。
在我们测试的各个类别中，每个模型最快的方法保持不变，但吞吐量仍随工作负载而异。Nemotron 3.5 Lightning 搭配 DSpark 的输出速度在 123.01 到 138.02 tokens/s 之间，Qwen3.8-27B 搭配 DFlash2 则在 27.69 到 34.44 tokens/s 之间。
请用能代表目标应用的提示词来验证你的推测解码配置。有代表性的数据集有助于你选出最适合自己的模型和使用场景的方法与草稿检查点。
什么时候应该训练自定义检查点？
对大多数应用，建议从现有的量化检查点和草稿模型入手。这通常足以获得很好的准确率和可观的加速，而无需自己训练。在部署该配置之前，请用来自你应用的提示词进行测试。通用基准测试无法告诉你，某个检查点是否保留了对你的数据至关重要的行为。
如果量化降低了准确率，可以使用 NVIDIA Model Optimizer，通过量化感知训练（quantization-aware training）或蒸馏来微调量化模型。量化感知训练在训练过程中模拟较低的精度。量化感知蒸馏则还会借助更高精度的教师模型，帮助量化模型保留原模型的行为。
这种额外的调优对那些细微准确率变化也很关键的专门化工作负载最为有用。要了解如何用任一方法训练量化模型，请参阅NVIDIA Model Optimizer 的 QAT 和 QAD 教程。
推测解码也可以采用同样的思路。公开的草稿检查点可能与你的模型兼容，但带来的加速却不及预期。加速效果取决于主模型接受所提议 token 的频率。接受率较低时，生成和验证草稿的开销会抵消收益。如果出现这种情况，请参照 vLLM Speculators 训练指南，用有代表性的应用数据训练一个兼容的推测器（speculator）。Speculators 支持 MTP、EAGLE-3、DFlash 和 DSpark 等方法。训练完成后，请在你自己的提示词上同时测量草稿 token 的接受率和解码吞吐量。
大多数应用并不需要自定义训练。先从现有检查点入手，测量其准确率和性能，只有当结果显示存在明显差距时，才训练自己的检查点。
开始使用
Jetson 通过优化的运行时、量化检查点和推测解码，支持最新的开源模型。有了这一基础，你就可以从测试模型迈向构建和交付边缘应用。
要进一步了解这些模型、查看如何对它们做基准测试、获取推荐方案，并比较不同 Jetson 平台上的性能，请访问 Jetson AI Lab 模型页面。
如需更多动手指导，请参阅我们在主流框架上的教程：在 Jetson 上运行 LLM 和 VLM、生成式 AI 模型基准测试，以及推测解码入门。