在边缘设备上运行推理与智能体AI一直比预期更难。直到最近，具备多步推理能力的模型体积过大，无法在边缘硬件上本地运行。开发智能体的团队不得不将推理请求路由至数据中心，这带来了网络依赖、成本增加，以及本应保留在设备端的数据被暴露的风险。

这一限制正在被打破。整个夏季陆续发布的多个模型系列共同标志着边缘AI的一个转折点。这一代新型紧凑开源模型，如今能够提供几个月前还需要大型数据中心系统才能实现的推理与智能体能力，而NVIDIA Jetson现在就能运行它们。

这可以为车载助手、实时异常检测以及在恶劣或偏远环境中工作的机器人提供动力。现场专家可以减少故障排查的时间，关键系统也能在连接受限或不可用时继续运行。

本文将以Nemotron 3.5 Lightning和Qwen3.8-27B为例，介绍在Jetson上部署这一代新型开源模型所需了解的内容。你将学习在比较模型架构时需要关注哪些要点、如何应用推理优化技术来充分发挥硬件性能，以及如何针对你的工作负载验证配置。

具体而言，本文将回答以下开发者关心的问题：

如何为Jetson选择推理模型？

NVFP4量化和推测解码如何提升推理性能？

如何使用vLLM部署Nemotron 3.5 Lightning和Qwen3.8-27B？

如何为你的应用验证配置？

下图展示了这一转变。图中按模型规模和发布日期绘制了Artificial Analysis智能指数。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）在本地部署模型，使推理循环不完全依赖数据中心。

对于Jetson Orin Nano来说，Gemma 4 E4B是一个不错的起点。对于Jetson AGX Orin和Jetson AGX Thor，Nemotron 3.5 Lightning和Qwen3.8-27B是很好的选择。这些模型系列拥有高质量的量化检查点，并在主流推理引擎上提供了优化的部署选项。

如何优化Jetson上的推理模型性能

两种互补的技术可以提升推理性能：NVFP4量化可以减少模型运算所需的工作量和内存，而推测解码则可以在每次验证步骤中生成多个被接受的Token。

模型架构决定了起点，但服务端的配置选择同样会影响性能。下图比较了两个模型在BF16、NVFP4以及NVFP4结合我们为每个模型测试出的最快推测解码配置下的表现。

如上图所示，我们逐一叠加了两项优化。BF16作为基准。NVFP4增加了量化。最终配置将NVFP4与我们为每个模型测试出的最快推测解码配置相结合。

在解码过程中，模型逐个Token生成响应。每个Token通常需要一次完整的模型前向传播。这为提升性能提供了两种途径：减少每次传播的工作量，或从每次传播中产生更多Token。

量化采用的是第一种方法。低精度数值减少了GPU在每次传播过程中需要移动和处理的数据量。使用NVFP4等格式，可以在保持接近BF16质量的同时提升生成速度并降低内存占用。

推测解码采用的是第二种方法。一个较小的草稿模型会提出若干候选Token，主模型再对这些候选一并进行验证。最终决定仍由主模型做出。如果主模型接受了多个提议的Token，生成过程就能在一次验证步骤中推进多个Token。

视频演示了有无推测解码时的响应生成过程，展示了由此带来的加速效果。

有多种方法可以生成这些草稿，包括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场景：写作、推理、摘要和检索增强生成。

在我们测试的各个类别中，每个模型的最快方法保持不变，但吞吐量仍会因工作负载而异。Nemotron 3.5 Lightning搭配DSpark的输出Token速率介于每秒123.01到138.02个之间，而Qwen3.8-27B搭配DFlash2的输出Token速率介于每秒27.69到34.44个之间。

请使用能够代表目标应用的提示词来验证你的推测解码配置。一个具有代表性的数据集将有助于你为自己的模型和使用场景选择最合适的方法和草稿检查点。

何时应该训练自定义检查点

对于大多数应用而言，从现有的量化检查点和草稿模型入手就足够了。这通常无需自行训练便能获得不错的准确性和实用的加速效果。在部署配置之前，请使用你的应用场景中的提示词进行测试。通用基准测试无法告诉你某个检查点是否保留了对你的数据而言至关重要的行为特征。

如果量化降低了准确性，可以使用NVIDIA Model Optimizer，通过量化感知训练或蒸馏对量化模型进行微调。量化感知训练在训练过程中模拟低精度运算。量化感知蒸馏还会使用更高精度的教师模型，帮助量化模型保留原始模型的行为特征。

这种额外的调优对于那些微小准确性变化就很关键的专用工作负载最为有用。要了解如何用这两种方法训练量化模型，请参阅NVIDIA Model Optimizer的QAT和QAD教程。

推测解码同样适用这一思路。一个公开的草稿检查点可能与你的模型兼容，但提供的加速效果可能低于预期。加速效果取决于主模型接受所提议Token的频率。当接受率较低时，生成和验证草稿的成本可能会抵消其带来的收益。如果出现这种情况，请参考vLLM Speculators训练指南，使用具有代表性的应用数据训练一个兼容的推测器。Speculators支持包括MTP、EAGLE-3、DFlash和DSpark在内的多种方法。训练完成后，请在你自己的提示词上同时测量草稿Token接受率和解码吞吐量。

大多数应用并不需要自定义训练。先从现有检查点入手，测量其准确性和性能表现，只有在结果显示出明显差距时，才考虑训练自己的检查点。

开始使用

Jetson支持最新的开源模型，并提供优化的运行时环境、量化检查点和推测解码能力。有了这一基础，你就可以从测试模型转向构建并交付边缘应用。

要了解更多关于这些模型的信息，包括如何对它们进行基准测试、查找推荐方案，以及比较不同Jetson平台间的性能表现，请访问Jetson AI Lab模型页面。

如需更多实践指导，请参阅我们关于在Jetson上运行大语言模型和视觉语言模型、对生成式AI模型进行基准测试，以及在主流框架上开始使用推测解码的相关教程。

Q&A

Q1：Jetson上如何选择合适的推理模型？

A：需要根据应用所需的决策、工具和响应模式来选择。Nemotron 3.5 Lightning适合响应密集型工作流，因为更快的Token生成速度能缩短整体流程；Qwen3.8-27B更适合需要较少但更困难决策的任务，允许智能体在生成每个响应上花费更多时间。建议在正式部署前用实际场景对两个模型进行基准测试。

Q2：NVFP4量化和推测解码分别能带来什么好处？

A：NVFP4量化通过降低数值精度减少每次模型运算所需的数据处理量，从而提升生成速度并降低内存占用。推测解码则通过草稿模型提前提出多个候选Token，让主模型一次性验证，从而在每次验证步骤中生成更多被接受的Token。二者结合使用效果优于单独使用任何一项。

Q3：什么情况下需要训练自定义检查点？

A：大多数应用无需自定义训练，使用现有量化检查点和草稿模型即可获得不错效果。只有当量化明显降低了准确性，或公开的草稿检查点接受率过低、加速效果不理想时，才需要通过NVIDIA Model Optimizer或vLLM Speculators训练指南进行自定义训练。