在边缘端运行推理和智能体 AI 一直比它本应有的难度更大。直到最近，具备多步推理能力的模型仍然太大，无法在边缘硬件上本地运行。构建智能体的开发者不得不将推理请求经由数据中心处理，这增加了网络依赖、提高了成本，并暴露了可能需要留在设备上的数据。
这一限制正在解除。整个夏季发布的多个模型系列共同标志着边缘 AI 的转折点。这一新一代紧凑型开放模型如今能够提供仅在几个月前还需要大型数据中心系统才能实现的推理和智能体能力，而 NVIDIA Jetson 今天就能运行它们。
这可以为驾驶室内的助手、实时异常检测以及在恶劣或偏远环境中工作的机器人提供支持。现场专家可以减少排查故障的时间，关键系统也能在连接受限或不可用时继续运行。
本文介绍了在 Jetson 上部署这一新一代开放模型所需了解的内容，并以 Nemotron 3.5 Lightning 和 Qwen3.8-27B 为例。你将了解在比较模型架构时应关注哪些方面、如何应用推理优化技术以充分发挥硬件性能，以及如何针对你的工作负载验证配置。
具体来说，本文回答了以下开发者问题：
- 如何为 Jetson 选择推理模型？
- NVFP4 量化和投机解码如何提升推理性能？
- 如何使用 vLLM 部署 Nemotron 3.5 Lightning 和 Qwen3.8-27B？
- 如何为你的应用验证配置？
下面的图 1 展示了这一转变。它按模型规模和发布日期绘制了 Artificial Analysis Intelligence Index。2026 年发布的开放模型如今达到了与 2025 年领先模型相似的分数，同时使用的参数少得多。
图 1. 具备边缘能力的 2026 年模型（绿色）以远少于前沿模型的参数量达到了与 2025 年前沿模型相当的情报分数
如何为 Jetson 选择推理模型？
更好的训练方法和更高效的架构正在推动这一变化。例如，蒸馏将 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. NVFP4 量化和推测解码在 Jetson 上共同实现高达 6.28 倍于 BF16 的解码吞吐量加速
如上图 2 所示，我们一次添加一项优化。BF16 提供基线。NVFP4 添加量化。最终配置将 NVFP4 与我们为每个模型测试的最快推测解码配置相结合。
在解码过程中，模型一次生成一个 token 的响应。每个 token 通常需要再次通过模型。这为你提供了两种提升性能的方法：减少每次通过的工作量，或从每次通过中产生更多 token。
量化采用第一种方法。较低精度的值减少了 GPU 在每次通过中必须移动和处理的数据量。使用 NVFP4 等格式，你可以在保持质量接近 BF16 的同时提高生成速度并减少内存使用。
推测解码采用第二种方法。较小的草稿模型提出多个 token，主模型一起验证它们。主模型仍然做出最终决定。如果它接受多个提议的 token，生成会在一个验证步骤中前进多个 token。
下面的视频 1 展示了使用和不使用推测解码的响应生成，说明了由此带来的加速。
视频 1. 在 NVIDIA Jetson 上比较 Qwen3.5 9B NVFP4 推理使用和不使用推测解码
有几种方法可以生成这些草稿，包括 MTP、DFlash 和 DSpark。这三种方法都能在 Jetson 上运行，但它们生成和评估候选 token 的方式不同。我们测试了可用的方法和草稿检查点，而不是假设某一种配置对每个模型都是最优的。
这两种优化相辅相成。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 类别：写作、推理、摘要和检索增强生成。
图 3。推测解码加速因工作负载而异，两个模型在 RAG 和写作上受益最大
在我们测试的各个类别中，同一方法对每个模型仍然是最快的，但吞吐量仍因工作负载而异。使用 DSpark 的 Nemotron 3.5 Lightning 的输出吞吐量范围为 123.01 到 138.02 token/s，而使用 DFlash2 的 Qwen3.8-27B 的范围为 27.69 到 34.44 token/s。
使用代表目标应用程序的提示来验证你的推测解码配置。具有代表性的数据集将帮助你选择最适合你的模型和用例的方法和草稿检查点。
何时应该训练自定义检查点？
对于大多数应用程序，从现有的量化检查点和草稿模型开始。这通常足以获得强大的准确性和有用的加速，而无需自己训练任何东西。在部署配置之前，使用来自你的应用程序的提示进行测试。通用基准测试无法告诉你检查点是否保留了对你数据重要的行为。
如果量化降低了准确性，请使用 NVIDIA Model Optimizer 通过量化感知训练或蒸馏来微调量化模型。量化感知训练在训练期间模拟较低精度。量化感知蒸馏还使用更高精度的教师模型来帮助量化模型保留原始模型的行为。
这种额外的调优对于准确性微小变化很重要的专业工作负载最为有用。要了解如何使用任一方法训练量化模型，请遵循 NVIDIA Model Optimizer QAT 和 QAD 教程。
对推测解码（speculative decoding）采用同样的方法。一个公开的草稿检查点（draft checkpoint）可能与你的模型兼容，但提供的加速仍可能低于预期。加速效果取决于主模型接受所提议 token 的频率。当接受率较低时，生成和验证草稿的成本可能会降低收益。如果出现这种情况，请遵循 vLLM Speculators 训练指南 ，使用具有代表性的应用数据训练一个兼容的推测器（speculator）。Speculators 支持的方法包括 MTP、EAGLE-3、DFlash 和 DSpark。训练完成后，在你自己的提示词上同时测量草稿 token 接受率和解码吞吐量。
大多数应用不需要自定义训练。从可用的检查点开始，测量它们的准确性和性能，只有当这些结果显示出明显差距时，才训练你自己的模型。
开始使用
Jetson 通过优化的运行时、量化检查点和推测解码支持最新的开放模型。有了这一基础，你就可以从测试模型转向构建和交付边缘应用。
要了解有关这些模型的更多信息、查看如何对它们进行基准测试、查找推荐的配方（recipe），以及比较各 Jetson 平台上的性能，请访问 Jetson AI Lab 模型页面。
如需更多实践指导，请参阅我们的教程：在 Jetson 上运行 LLM 和 VLM、对生成式 AI 模型进行基准测试，以及在主流框架上开始使用推测解码。