SpecEdge 阅读笔记：用边缘草稿分担大模型推理

大模型服务通常把推理集中在服务器上。SpecEdge 考虑另一种分工：边缘设备运行较小的草稿模型，服务器保留较大的目标模型，通过推测解码协作生成文本。它关注的核心问题是，如何让边缘算力真正减少服务器负担，而不让网络等待抵消收益。

本文根据个人阅读笔记整理，介绍论文设计思路；没有进行本地复现实验。原论文发表于 NeurIPS 2025，代码见官方仓库。

为什么通过 token 协作

跨公网拆分模型层，需要频繁传输中间张量，网络带宽和延迟都会影响推理效率。推测解码让小模型先提出一段候选 token，再由目标模型批量验证。边缘与服务器主要交换 token 和验证结果，使这种协作更适合公网条件。

参与者	主要任务	需要解决的问题
边缘草稿模型	生成候选 token	草稿速度和接受率
服务器目标模型	验证候选并给出后续结果	批量验证的效率
调度器	组织多个用户的验证请求	等待期间的服务器利用率

草稿的价值取决于有多少候选被接受。小模型生成得快，并不等于整套系统必然更快；接受率低时，大量草稿工作会被丢弃。

主动草稿：让等待期间继续工作

如果边缘端每次提交草稿后都停止生成，网络往返和服务器验证期间就会空等。SpecEdge 让边缘端在等待验证结果时继续生成候选，将这部分工作与服务器验证重叠。

提前生成的内容仍以尚未确认的前缀为条件，因此不能直接当成最终输出。验证结果到达后，需要判断前缀是否对齐；不匹配的后续草稿必须回退或丢弃。

流水线调度：利用多个用户的等待间隙

单个用户的边缘设备生成下一段草稿时，服务器可以处理其他用户的验证请求。调度策略将多个请求组织成批次，减少服务器等待边缘草稿的空闲时间。

草稿长度在这里也是调度参数：短草稿通信更频繁，长草稿等待更久，也可能浪费更多不被接受的候选。合适的长度需要兼顾边缘生成时间、网络往返和服务器验证时间。

阅读后的理解

这篇论文把推测解码扩展成了端与云之间的协作接口。评估这类系统时，我会同时检查草稿接受率、端侧开销、服务器吞吐量，以及用户感受到的首 token 和后续 token 延迟。只看某一侧 GPU 的利用率，很容易忽略整条链路的等待。

论文中的收益来自特定实验配置。换成更慢的边缘设备、更不稳定的网络或不同并发规模，需要重新测量，不能直接套用论文结论。