端侧推理从跑通到可用：TensorRT Edge-LLM 与投机解码的边界

同一个推理框架，仍有不同的硬件条件

NVIDIA 在 10 月 30 日发布的教程使用 DGX Spark 64GB 和 TensorRT Edge-LLM 运行文本模型 Nemotron-3.5 Lightning。原文将 Spark 定位为开发平台，并说明该推理框架也面向 Jetson Thor、DRIVE AGX Thor 和 IGX Thor 等嵌入式平台。

这里的“端侧”包含专用 GPU 设备，不能据此推断手机也能运行同一配置。本站建议先确定部署硬件、可用内存和功耗预算，再核对目标平台的模型支持清单；开发机跑通不能替代最终设备验收。

冷启动包括下载和引擎构建

原文示例固定 TensorRT Edge-LLM 0.11.1 与 TensorRT 10.16.1.11，并要求 CUDA 13、Python 3.10 至 3.12。首次启动包含约 21GB 的模型下载和 TensorRT 引擎构建，后续启动可复用匹配配置的缓存；这些步骤都发生在终端能够聊天之前。

本站建议把下载、引擎构建、服务就绪和首次回答分别计时。缓存目录需要同时容纳模型与引擎，模型版本或运行配置变化后也应重新检查缓存是否可复用。接口已经监听，并不等于服务已完成加载；应用应等待就绪检查成功再发送请求。

投机解码加快生成，不代表首字更快

DSpark 让草稿模型先提出多个 token，再交给主模型验证。来源使用三个草稿 token，在 HumanEval 提示集上报告平均生成速度从 73.4 提升至 126.9 tokens/s；同一组实验的首 token 延迟中位数则从 98.1ms 变为 98.7ms。这里的生成速度明确不包含首 token 等待时间。

原文还报告 SpeedBench 1K 的生成速度为 73.3 与 108.5 tokens/s，说明收益随工作负载变化。本站判断：先看用户是在等待第一句话，还是等待长答案完成，再决定优化指标；不能把某组生成速度的提升直接当成整体响应时间按相同比例缩短。

复现性能需要保留完整口径

来源性能表采用 DGX OS 7.6.0、NVFP4、开启 thinking、batch size 1、单个并发流式请求和 128-token 输出上限；DSpark 推理时的系统峰值内存为 27.9GB，包含操作系统。这是供应方在指定设备上的报告，本站没有运行模型或复现跑分。

本站建议用自己的提示、输入长度、并发量和输出上限做开关对照，同时记录首 token 延迟、完整答案耗时与系统峰值内存。若应用还运行语音、视觉或其他后台任务，应把这些真实负载加入验收，再决定是否启用投机解码。

实践检查表

• 固定硬件、软件版本、模型精度与缓存配置，分别记录冷启动和热启动。
• 区分首 token 延迟与不含首字等待的生成速度，注明单位及统计方式。
• 先在同一组提示上比较 DSpark 开关，再测目标并发和完整答案时间。
• 把操作系统、模型、引擎和应用其他任务纳入内存预算，不把来源跑分当作本站实测。