SpecEdge: Scalable Edge-Assisted Serving Framework for Interactive LLMs

Conference: NeurIPS'25 Spotlight

Github: https://github.com/kaist-ina/specedge

My Thought

个人感觉这篇工作是将ICLR25 PEARL: Parallel Speculative Decoding with Adaptive Draft Length中大小模型彼此互不等待的协同Speculative Decoding模式放在了云边协同场景下(一般来说Pearl中的大小模型协同需要放在不同的卡上，在单卡场景下没法实现，而云边协同的场景下刚好符合Pearl的研究场景)，用来掩盖和减小 draft 和 target model 的网络通信开销。

同时也对多edge draft models 的情况进行了优化，提出Server-Side Pipeline-Aware Scheduling来进一步提高target model的利用率。

这篇工作真正实现上还有许多细节，有时间可以看看开源代码中是否涉及到。

1. Motivation

Large language models (LLMs) power many modern applications, but serving them at scale remains costly and resource-intensive. Current server-centric systems overlook consumer-grade GPUs at the edge.

大型语言模型（LLMs）支撑了众多现代智能应用，但其部署和推理成本极高。目前的主流推理系统普遍采用“服务器中心化”架构，忽视了边缘侧日益强大的消费级 GPU 资源。

A compelling opportunity exists to dramatically reduce LLM serving costs by leveraging consumer-grade GPUs at the network edge. The GeForce RTX 4090 delivers up to 330.3 TFLOPS (FP16 tensor), even exceeding the 312 TFLOPS of data-center-class A100, while costing 14.43× less.

RTX 4090 等消费级 GPU 的 FP16 张量算力已超过 A100，但成本仅为其十四分之一。若能在网络边缘充分利用这些 GPU，将可能从根本上改变 LLM 部署的经济性。

然而，现有推理架构（如张量并行、流水线并行）依赖数据中心级高速互连（InfiniBand / NVLink），在广域网 (WAN) 条件下无法有效运行，成为利用边缘资源的主要障碍。

2. Challenge

（1）传统并行失效

当前主流并行技术（Shoeybi et al., 2019；Aminabadi et al., 2022）在数据中心内部表现良好，但依赖高带宽低延迟互联，难以跨公网运行。 WAN 环境下传输中间激活状态（如 KV Cache 或特征图）会带来巨量通信开销。

（2）Split Computing 局限

传统 split computing 通过“层切分”在边缘和服务器之间划分网络层，以减少服务器计算或原始输入传输。但对于自回归的 Transformer LLMs 而言，每生成一个 token 都需要一次前向传播与跨端通信，通信轮次与 token 数成正比，延迟巨大。

因此，需要一种通信次数少、传输数据量小的新式协同推理方式。

3. Contribution

We introduce SpecEdge, an edge-assisted inference framework that splits LLM workloads between edge and server GPUs using a speculative decoding scheme, exchanging only token outputs over the network.

提出 SpecEdge：一种利用 推测式解码（speculative decoding） 在边缘与服务器间分工的推理框架，仅传输 token 序列，不传输中间激活。

✅ Proactive edge drafting：边缘设备在服务器验证期间持续生成 token 候选，以隐藏网络延迟；
✅ Pipeline-aware scheduling：服务器端智能交错多用户请求的验证任务，提高 GPU 利用率。

实验表明： SpecEdge 在相同延迟下实现 2.22× server throughput、提升整体成本效率 1.91×，并降低 inter-token latency 约 11.24%。

4. Method

4.1 Disaggregated LLM Decoding

SpecEdge 将 LLM 推理解耦为两个角色：

Edge GPU (consumer-grade)：负责 drafting（生成候选 token 树）；
Server GPU (data-center)：负责 verification（验证候选并生成最终 token）。

这种 disaggregated speculative decoding 带来两大优势：

减少通信轮次与数据量：传统 layer-split 需要每 token 通信一次；SpecEdge 只在每 n 个 token 候选后交互一次；
提升算/I O 比：服务器端批量验证多个 token，可在一次前向中复用参数加载，提高算力利用率。

但此分离引出两大新挑战：

潜在延迟增加：draft → verify 若顺序执行，会产生额外网络 RTT；
服务器空闲风险：若等待边缘端草稿完成再验证，会造成服务器闲置。

为解决上述问题，SpecEdge 提出两项核心技术：

Proactive edge drafting (§ 4.2) —— 利用“主动生成”掩盖网络延迟；
Pipeline-aware scheduling (§ 4.3) —— 通过交错批验证保持服务器高利用率。

4.2 Proactive Draft Generation at the Edge

核心思想

当 edge GPU 生成 n 个候选并发送至 server 验证后，无需等待返回结果，而是立即继续向前生成新的候选 token。若服务器验证通过且其“bonus token”与边缘提前生成的首个 token 一致（称为 complete draft alignment），则这些预生成的 token 可直接接入生成流，无需重新计算，从而实现计算-通信重叠、隐藏延迟。

当服务器验证了边缘端发送的候选 token 并生成下一个 token（bonus token）后，如果这个 bonus token 恰好与边缘端在等待期间主动预测出的第一个 token 一致，那么说明两边的生成路径完全吻合（即 complete draft alignment）。这意味着边缘端之前预生成的那一段 token 就是服务器最终认可的结果，可以直接沿用、无需重新计算，从而让边缘端在等待验证时做的工作不被浪费，实现“边算边传”的计算–通信重叠，显著减少整体生成延迟。

KV Cache 更新策略

对于 aligned path：Edge 可复用已有 KV Cache，仅增量更新；
若验证失败或路径分叉，则丢弃 proactive 分支，从服务器返回的 token 序列重新构建 KV Cache。

此机制保证一致性同时降低冗余计算。

性能收益模型

SpecEdge 形式化地分析 proactive drafting 的期望收益：

$$ E(\text{Gain}) = P_{\text{align}} \cdot P_{\text{match}\mid\text{align}} \cdot \Big(\frac{T_{\text{draft}}}{H_{\text{expan}}} - 1\Big) $$

$P_{\text{align}}$：前 n 个 token 验证通过且与 proactive 路径对齐的概率；
$P_{\text{match}\mid\text{align}}$：在对齐条件下 server bonus token 与 proactive 首 token 匹配的条件概率；
$T_{\text{draft}}$：边缘草稿生成时间；
$H_{\text{expan}}$：proactive 扩展深度。

若收益为正，则说明重叠计算可有效隐藏通信延迟。

通信-计算重叠分析

设网络往返延迟为 $T_{\text{net}}$，服务器验证耗时 $T_{\text{verify}}$，边缘 drafting 耗时 $T_{\text{draft}}$。 SpecEdge 通过调节 $n$ 与 draft 深度 $k$ ，使得：

$$ T_{\text{verify}} \approx T_{\text{draft}} + T_{\text{net}} $$

从而在时间轴上实现几乎完全重叠，无空闲阶段。

成功与失败场景

Complete alignment：server bonus token 与 proactive 首 token 匹配，直接复用并继续向前。
Partial alignment 或 divergence：server 路径与 proactive 树分叉，丢弃 proactive 分支，回退到验证末端。
统计结果：论文实测 alignment 成功率随 draft 深度增长递减，通常 2–4 token 深度可在延迟与命中率间取得平衡。

4.3 Server-Side Pipeline-Aware Scheduling

SpecEdge 将服务器职责限定为 verification only。此设计释放了大量计算资源，但也带来调度挑战：当某个 edge 正在生成新草稿时，服务器可能暂时无任务可处理，出现空闲气泡（bubbles）。

Pipeline 调度机制

SpecEdge 通过交错不同用户请求的验证任务，构建跨请求流水线：

服务器持续从多个 edge 设备接收已完成的 draft batches；
对批内所有候选序列并行验证；
验证完成后立即将结果发回对应 edge；
服务器转而处理下一批来自其他 edge 的草稿。

这种交错确保服务器 GPU 几乎持续满载，实现近似“双倍吞吐”。

动态深度校准

为最大化流水线效率，SpecEdge 实时测量 $T_{\text{verify}}$ 与 $T_{\text{draft}}$，并动态调整 draft 深度 $d$：

$$ T_{\text{verify}} \approx T_{\text{draft}} + T_{\text{net}} $$

若服务器验证过快（$T_{\text{verify}} < T_{\text{draft}} + T_{\text{net}}$），则减少 draft 深度；若服务器验证较慢（$T_{\text{verify}} > T_{\text{draft}} + T_{\text{net}}$），则增加 draft 深度，以维持两者时长近似匹配，从而实现最佳计算–通信重叠。

异质请求处理（Heterogeneous Requests）

多用户处于不同生成阶段，序列长度差异大。为并行处理：

Custom Attention Masking：为每个序列生成独立注意力掩码，保证仅对有效 token 计算自注意；
KV Cache Padding：将所有序列填充至当前批次最长长度，避免频繁调整张量形状。

这样，服务器可一次性在大 batch 内验证多个不同长度的请求，充分利用 GPU 并行能力而无交叉干扰。

5. Evaluation

实验设置

模型：LLaMA-2-13B 与 7B （作为 draft / verify 模型）。
边缘 GPU：RTX 4090（24 GB VRAM）；
服务器 GPU：A100 40 GB；
网络条件：WAN 仿真 10 Gbps 带宽、20–40 ms RTT。
比较基线：
1. Server-only inference（传统单端推理）；
2. Split computing baseline（层切分方案）；
3. Local speculative decoding（单机推测式解码，无分布式）。

主要指标

指标	含义
Throughput	单位时间内服务器验证的 token 数
Latency per token	端到端平均 token 延迟
Cost Efficiency	吞吐 ÷ 成本（以美元计）
Server Utilization	GPU 占用率
Alignment Success Rate	完全对齐概率

结果分析

Throughput ↑ 2.22×：由于服务器专注批验证且持续满载，吞吐翻倍；
Latency ↓ 11.24 %： Proactive drafting 成功率约 73 %，能有效隐藏 RTT；
Cost Efficiency ↑ 1.91×：边缘端硬件成本低，整体推理成本大幅下降；
Server Utilization 接近 98 %： Pipeline aware 调度避免了空闲；
Scalability：随 edge 数量增加，性能线性提升直至网络饱和。

消融实验（Ablation）

模块	Throughput 变化	Latency 变化
– Proactive Drafting	↓ 35 %	↑ 18 %
– Pipeline Scheduling	↓ 42 %	↑ 10 %
– Both	↓ 63 %	↑ 28 %

两个模块缺一不可：主动草稿负责降低延迟，流水线调度保证吞吐。

Sensitivity Study

Draft Depth d：过浅 → alignment 低；过深 → 无效草稿浪费 GPU；最佳 d≈4；
Network RTT：延迟越大，SpecEdge 相对优势越明显；
Edge/Server 比：1:4 至 1:6 可实现吞吐最优平衡。

6. Conclusion

We have presented SpecEdge, an edge-assisted LLM inference framework leveraging user-side consumer GPUs for drafting candidate tokens, while the server focuses on final verification.

SpecEdge 通过仅传输最终 token 输出，在典型 WAN 环境下实现高效的分布式 LLM 推理。边缘端的 Proactive Drafting 最大化利用本地算力并隐藏网络延迟；服务器端的 Pipeline-aware Scheduling 保证 GPU 持续饱和并显著提升吞吐。

实验结果表明：SpecEdge 在保证交互延迟可接受的前提下，可使服务器吞吐提高 2.22×，运营成本降低 1.91×。

My Thought#

1. Motivation#

2. Challenge#

（1）传统并行失效#

（2）Split Computing 局限#

3. Contribution#

4. Method#

4.1 Disaggregated LLM Decoding#

4.2 Proactive Draft Generation at the Edge#

核心思想#

KV Cache 更新策略#

性能收益模型#

通信-计算重叠分析#

成功与失败场景#

4.3 Server-Side Pipeline-Aware Scheduling#

Pipeline 调度机制#

动态深度校准#

异质请求处理（Heterogeneous Requests）#

5. Evaluation#

实验设置#

主要指标#

结果分析#

消融实验（Ablation）#

Sensitivity Study#

6. Conclusion#