Frontier Reasoning Reaches the Edge: 如何在 NVIDIA Jetson 上部署和优化模型

在边缘端运行推理和智能体 AI 一直比实际需要更难。直到最近，能够进行多步推理的模型仍然太大，无法在边缘硬件上本地运行。开发智能体的开发者必须将推理请求路由到数据中心，这带来了网络依赖、增加了成本，并可能导致本应留在设备上的数据暴露。

这一限制正在被打破。今年夏季发布的多个模型家族共同构成了边缘 AI 的转折点。这一代紧凑的开放模型现在能够交付此前只有大型数据中心系统才能提供的推理和智能体能力，而 NVIDIA Jetson 今天即可运行它们。

这些模型能够驱动驾驶室内助手、实时异常检测以及能在恶劣或偏远环境中作业的机器人。现场专家可以减少排查故障的时间，关键系统在网络连接受限或完全中断时也能继续运行。

本文将以 Nemotron 3.5 Lightning 和 Qwen3.8-27B 为例，介绍如何在 Jetson 上部署这一代开放模型。你将了解比较模型架构时需要关注什么，如何应用推理优化技术以充分发挥硬件性能，以及如何为特定负载验证配置。

具体而言，本文旨在解答以下开发者关心的问题：

• 如何选择适用于 Jetson 的推理模型？
• NVFP4 量化和投机解码如何提升推理性能？
• 如何使用 vLLM 服务 Nemotron 3.5 Lightning 和 Qwen3.8-27B？
• 如何为应用验证配置？

下图展示了这一转变。该图按模型尺寸和发布日期绘制了 Artificial Analysis Intelligence Index。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 是很好的选择。这些模型家族都提供了高质量的量化 checkpoint，并在主流推理引擎上有优化好的部署方案。

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

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

模型架构决定了性能起点，但服务部署方式同样影响表现。下面的图 2 对比了两个模型在 BF16、NVFP4，以及 NVFP4 加上各自测试中最快的投机解码配置下的表现。

如图 2 所示，我们每次叠加一项优化：BF16 作为基准，NVFP4 加入了量化，最终配置则在 NVFP4 的基础上为每个模型搭配我们测试中最快的投机解码方案。

在解码阶段，模型一次生成一个 token，而每个 token 通常都需要完整跑一遍模型。因此提升性能有两条路：要么降低每次前向计算的工作量，要么让每次前向计算产出更多 token。

量化走的是第一条路。更低的数值精度意味着 GPU 每次前向计算需要搬运和处理的数据量更少。使用 NVFP4 这类格式，可以在生成速度更快、内存占用更低的同时，把质量保持在接近 BF16 的水平。

Speculative decoding 采用第二种思路。较小的草稿模型会先提出若干个 token，再由主模型统一验证。最终决策权仍在主模型手中：若主模型接受多个提议 token，则一次验证步骤即可推进多个 token 的生成。 下面的 Video 1 对比了开启和关闭 speculative decoding 时的响应生成过程，直观展示了由此带来的速度提升。

生成草稿的方法有多种，包括 MTP、DFlash 和 DSpark。三者均可在 Jetson 上运行，但在生成和评估提议的方式上各不相同。我们测试了现有方法及草稿 checkpoint，而非直接假设某种配置对所有模型都是最优的。

这两种优化手段相辅相成：NVFP4 降低了每次前向传播的成本，而 speculative decoding 则提升了每次传播中能被接受的 token 数量。两者结合带来的性能提升优于单独使用其中任意一种。

两个模型的最快 speculative decoding 配置并不相同：Nemotron 3.5 Lightning 在 DSpark 下表现最佳，而 Qwen3.8-27B 在 DFlash2 下效果最好。建议针对你要部署的模型实际测试不同方法与草稿 checkpoint，不要想当然地认为某一种配置适用于所有模型。

前置条件

运行以下命令之前，请确认你已具备：

• Jetson AGX Thor 或 Jetson AGX Orin
• 配置好 NVIDIA Container Runtime 与 Docker 的 JetPack 7.2
• 足以容纳模型和草稿 checkpoint 的存储空间
• 已接受 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，当前支持的兼容草稿 checkpoint 最为广泛。DSpark 在 DFlash 基础上增加了对草稿的修正，并能提前终止低质量的提议。当存在匹配的 checkpoint 时，DSpark 速度更快，但它支持的 checkpoint 种类较少。

用典型负载验证性能

模型级基准测试有助于你确定一个优秀的推测解码配置。然而，不同应用生成的文本类型各异，性能也会随负载变化。为了衡量这种影响，我们固定每个模型的最快配置，并对 SpeedBench 的四个类别进行测试：写作、推理、摘要和检索增强生成。

在测试的各个类别中，每个模型使用相同的方法都是最快的，但吞吐量仍因工作负载而不同。Nemotron 3.5 Lightning 配合 DSpark 的输出速度在 123.01 到 138.02 tokens/s 之间，Qwen3.8-27B 配合 DFlash2 则在 27.69 到 34.44 output tokens/s 之间。

请使用能代表目标应用的提示词来验证你的投机解码配置。一份有代表性的数据集能帮你选出最适合自己模型和场景的方法与草稿模型检查点。

什么时候需要训练自定义检查点？

对大多数应用来说，直接使用现成的量化检查点和草稿模型即可，通常无需自己训练任何东西，就能获得不错的精度和有效的加速。在部署之前，请先用来自你应用的提示词进行测试——通用基准无法告诉你一个检查点是否保留了对你数据至关重要的行为。

如果量化导致精度下降，可以用 NVIDIA Model Optimizer 通过量化感知训练或蒸馏对量化后的模型进行微调。量化感知训练（QAT）在训练过程中模拟低精度运算；量化感知蒸馏（QAD）则额外借助一个更高精度的教师模型，帮助量化模型保留原模型的行为。

这类额外的调优最适合那些对精度细微变化敏感的专用工作负载。想了解如何用这两种方法训练量化模型，请参阅 NVIDIA Model Optimizer QAT 与 QAD 教程。

投机解码也可采用同样的思路。公开的草稿模型权重虽然可能与你的主模型兼容，但加速效果未必达到预期。实际加速幅度取决于主模型对草稿 token 的接受频率；若接受率偏低，生成和验证草稿的成本反而可能抵消收益。遇到这种情况，可参考 vLLM Speculators 训练指南，用具有代表性的应用数据训练一个与你模型兼容的专用草稿模型。Speculators 支持 MTP、EAGLE-3、DFlash 和 DSpark 等方法。训练完成后，请在自有提示上同时测量草稿 token 接受率与解码吞吐。

大多数应用场景无需自定义训练。建议先从现有权重出发，评估其准确性和性能，只有当结果明显不足时再进行自有训练。

开始上手

Jetson 已支持最新的开源模型，并配备了优化运行时、量化权重和投机解码能力。基于这些基础，你可以从模型测试转向构建和部署边缘应用。

想了解更多模型信息、基准测试方法、推荐配方，以及跨 Jetson 平台的性能对比，请访问 Jetson AI Lab 模型页面。

如需更实用的指导，可参考以下教程：在 Jetson 上运行 LLM 和 VLM、生成式 AI 模型基准测试，以及在主流框架上入门投机解码。