为什么你的边缘端 LLM 推理速度总在 20 tokens/s 徘徊

很多在 Jetson Orin Nano 或类似单板计算机上部署大模型的开发者都会陷入一个误区：认为推理慢是因为 GPU 算力（TFLOPS）不够，于是拼命优化算子或寻找更高算力的芯片。但实际上，在 Batch Size = 1 的实时推理场景下，决定速度的根本矛盾不是算力，而是内存带宽。

简单来说，LLM 的自回归生成本质上是一次极其低效的“数据搬运”。每生成一个 token，模型都需要将整个权重矩阵从内存中读取一遍，与当前的激活向量做一次点乘，然后迅速丢弃。在这种模式下，处理器的计算单元大部分时间都在空转，等待数据从 LPDDR5 总线传输过来。从 Roofline 模型分析，这属于典型的 Memory-bound（内存受限）场景，而非 Compute-bound（计算受限）。

我们可以用一组具体的数字来量化这个瓶颈。以 Jetson Orin Nano 8GB 版本为例，其 LPDDR5 总线的理论带宽上限约为 68 GB/s。如果你运行一个经过 4bit 量化的 7B 参数模型，模型权重文件大小约为 4GB。这意味着，即便没有任何计算开销，单次读取这 4GB 权重所需的物理时间就高达 59 毫秒（4GB / 68GB/s ≈ 0.0588s）。换算下来，理论上的速度天花板被死死卡在了 17-20 tokens/s。在这种情况下，无论你把 GPU 算力提升多少倍，只要带宽不增加，速度就绝不会有质的飞跃。

为了打破这个带宽枷锁，目前最有效的方案之一是 Speculative Decoding（投机采样）。它的核心逻辑是通过“批量验证”来提高单次内存读取的利用率。

具体执行流程分为四步：首先，引入一个极小的 Draft Model（草稿模型），由它快速预测接下来的 N 个 token（例如 8 个）；其次，将这 N 个 token 连同输入一次性交给大尺寸的 Target Model 进行一次 Forward Pass（前向传播）；接着，对比两者的输出，保留一致的前缀；最后，在出现分歧的地方，由 Target Model 给出正确的采样结果并补齐，然后进入下一个循环。

这里的关键在于：Target Model 的权重在一次内存读取过程中，被用来验证了多个 token。如果 Draft Model 猜得准，一次读取就能产出多个 token，从而在不增加带宽的情况下，实质性地提升了吞吐量。而且，这种方案在数学上保证了结果的精确性。很多人误以为投机采样是牺牲精度换速度，但实际上它的接受规则经过严格设计，最终输出的概率分布与直接使用 Target Model 完全一致，文本内容没有任何损失。

总结来看，在边缘端部署 LLM 时，不要盲目追求算力峰值，而应优先关注内存带宽及其利用率。如果你的硬件被限制在 68 GB/s 这种量级，那么通过投机采样这种算法层面的优化，比更换更高算力的计算模块要高效得多。