在边缘运行推理和代理式 AI 比以往更加困难。直到最近，能够进行多步骤推理的模型还过于庞大，无法在边缘硬件上本地运行。构建智能体的开发者不得不通过数据中心进行推理，这增加了网络依赖性，增加了成本，并暴露了可能需要保留在设备上的数据。
这种限制正在解除。今年夏天发布的多个模型系列共同标志着边缘 AI 的转折点。现在，新一代紧凑型开放模型可提供仅在几个月前就需要大型数据中心系统的推理和代理式功能，而 NVIDIA Jetson 现在就可以运行这些功能了。
这可以为驾驶室内助手、实时异常检测以及在恶劣或远程环境中工作的机器人提供支持。现场专家可以减少故障排除所需的时间，而关键系统可以在连接受限或不可用时保持运行。
本文将以 Nemotron 3.5 Lightning 和 Qwen3.8-27B 为例，介绍在 Jetson 上部署新一代开放模型所需的知识。您将了解在比较模型架构时需要注意哪些方面，如何应用推理优化技术以充分利用硬件，以及如何验证工作负载的配置。
具体而言，本文将回答以下开发者问题：
- 如何为 Jetson 选择推理模型？
- NVFP4 量化和推理解码如何提高推理性能？
- 如何使用 vLLM 为 Nemotron 3.5 Lightning 和 Qwen3.8-27B 提供服务？
- 如何验证应用的配置？
下面的图 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 所示，我们添加了两次优化，一次一个。BF16 提供了基准。NVFP4 增加了量化。最终配置将 NVFP4 与我们针对每个模型测试的最快预测解码配置相结合。
在解码期间，模型每次生成一个 token。每个 token 通常都需要对模型进行另一次遍历。这为您提供了两种提高性能的方法：减少每次通道中的工作量或从每次通道中生成更多 token。
量化是第一种方法。较低精度值会减少 GPU 在每次传递期间必须移动和处理的数据量。借助 NVFP4 等格式，您可以提高生成速度并减少显存占用，同时保持接近 BF16 的质量。
预测解码采用第二种方法。一个较小的草稿模型会提出多个 token，然后主模型会一起验证这些 token。主模型仍会做出最终决策。如果它接受多个提议的 token，则在一个验证步骤中通过多个 token 推进生成。
下面的视频 1 展示了在启用和不启用预测解码的情况下生成的响应，并说明了由此产生的加速效果。
有多种方法可以生成这些草稿，包括 MTP、DFlash 和 DSpark。这三者都在 Jetson 上运行，但它们生成和评估提案的方式不同。我们测试了可用的方法并起草了检查点，而不是假设一种配置最适合每个模型。
这两种优化是相辅相成的。NVFP4 降低了每次通道的成本，而预测性解码会增加每次通道生成的可接受 token 数量。它们共同提高了性能，而不仅仅是优化。
两种模型的最快预测解码配置各不相同。Nemotron 3.5 Lightning 在使用 DSpark 时表现最佳，而 Qwen3.8-27B 在使用 DFlash2 时表现最佳。使用您计划部署的模型测试方法和检查点草稿，而不是假设一种配置最适合每个模型。
预备知识
在运行以下命令之前，请确认您已：
- Jetson AGX Thor 或 Jetson AGX Orin
- 配置 NVIDIA 容器运行时和 Docker 的 JetPack 7.2。
- 为模型和草稿检查点提供足够的存储空间
- 接受 NVIDIA Nemotron 和 Qwen3.8 Checkpoint 的许可条款
对于 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 的四个类别：写作、推理、总结和检索增强生成。
在我们测试的类别中，相同的方法对于每个模型来说仍然是最快的，但吞吐量仍然因工作负载而异。采用 DSpark 的 Nemotron 3.5 Lightning 的输出 token/s 介于 123.01 到 138.02 之间，而采用 DFlash2 的 Qwen3.8-27B 的输出 token/s 介于 27.69 到 34.44 之间。
使用表示预期应用程序的提示来验证您的预测解码配置。代表性数据集将帮助您选择最适合您的模型和用例的方法和检查点草稿。
何时应训练自定义检查点？
对于大多数应用程序，从现有的量化检查点和草稿模型开始。这通常足以获得较高的准确性和有用的加速，而无需自己进行任何训练。在部署配置之前，请根据应用程序的提示对其进行测试。常规基准无法判断检查点是否保留对您的数据至关重要的行为。
如果量化降低了准确性，请使用 NVIDIA Model Optimizer 通过量化感知训练或蒸馏对量化模型进行微调。量化感知训练会在训练期间模拟较低的精度。量化感知型蒸馏还使用更高精度的教师模型来帮助量化模型保留原始模型的行为。
这种额外调优对于小型精度变化至关重要的专用工作负载非常有用。要了解如何使用这两种方法训练量化模型，请遵循NVIDIA Model Optimizer QAT 和 QAD 教程。
对预测解码应用相同的方法。公开草稿检查点可以与您的模型兼容，但所提供的加速度仍低于预期。加速取决于主模型接受所提议的 token 的频率。当接受率低时，草稿的制作和验证成本会降低收益。如果发生这种情况，请按照 vLLM Speculator 训练指南，使用具有代表性的应用数据训练兼容的预测器。预测器支持 MTP、EAGLE-3、DFlash 和 DSpark 等方法。训练后，根据您自己的提示测量草图标记接受率和解码吞吐量。
大多数应用程序不需要自定义训练。从可用的检查点开始，衡量其准确性和性能，并仅在结果显示明显差距时训练您自己的检查点。
开始使用
Jetson 支持最新的开放模型，具有优化的运行时、量化检查点和预测解码功能。在此基础上，您可以从测试模型转向构建和交付边缘应用。
如需详细了解这些模型、了解如何对其进行基准测试、查找推荐方法以及比较 Jetson 平台的性能，请访问 Jetson AI 实验室模型页面。
如需更多实战指导，请参阅我们的教程，了解如何在 Jetson 上运行大语言模型 (LLM) 和大语言模型 (VLM) 、对生成式 AI 模型进行基准测试，以及如何在热门框架上开始预测解码。
