← 返回 PaperDaily 大模型与智能体

RLM-Cascade：API省45.8%，p50还快1.83倍

这篇论文最有意思的地方，不是“又做了个路由器”，而是把推测式解码从 token 级搬到了响应级，还能跨模型、跨厂商、跨架构跑起来。更狠的是，在真实 agentic coding 负载里，成本、延迟、质量居然一起往上走，工程味很足。

龙哥读论文 阅读 4 查看原文
#大语言模型 #模型架构 #预测模型 #Agent #AI应用
RLM-Cascade：API省45.8%，p50还快1.83倍
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
这篇论文最有意思的地方，不是“又做了个路由器”，而是把推测式解码从 token 级搬到了响应级，还能跨模型、跨厂商、跨架构跑起来。更狠的是，在真实 agentic coding 负载里，成本、延迟、质量居然一起往上走，工程味很足。


原论文信息如下：
论文标题:
RLM-Cascade: Response-Level Speculative Decoding for Cost-Efficient LLM API Serving 发表日期:
2026年06月 发表单位:
PayPal 原文链接:
https://arxiv.org/pdf/2606.22840v1.pdf

响应级推测解码：如何用两毛钱换回一块的体验

这篇论文最有意思的地方，不是“又做了个路由器”，而是把推测式解码从token 级搬到了响应级。说人话就是：以前是“先猜下一个词，再让大模型逐词验算”；现在变成“先让便宜模型写完整答案，再让贵模型整段检查、必要时改写”。
这里的speculative decoding，中文通常译作“推测式解码”，原本是为了解决大模型解码慢的问题：小模型先“打草稿”，大模型负责“批改”。但原始版本要求两个模型共享词表、能看见彼此的概率分布，这在同一家模型内部还好办，跨厂商 API 场景就直接卡死。RLM-Cascade 的聪明之处在于，干脆不纠结 token 了，直接把整段回复当作一个单位来处理。
这就像审稿时不再逐字挑错，而是先看整篇文章有没有大方向问题。虽然精细度没 token 级那么“数学洁癖”，但换来的是只要会调 HTTP API 就能接入，不需要模型内部权限，不需要共享词表，也不需要把两家模型硬塞进同一套推理框架里。工程上，这叫“别跟底层较劲，先把钱省下来”。
图1：RLM-Cascade 端到端架构图
图1：RLM-Cascade 端到端架构图。简单请求走 SKIPPED 路径，只调用 DeepSeek；复杂请求走 Draft+Verify；工具调用类请求直接交给 Opus，保证 JSON schema 不翻车。异步埋点和监控在响应返回后再跑，不抢主链路时间。
这套思路的价值不在“学术上优雅”，而在“业务上能活”。在真实的 agentic coding 场景里，一个会话往往几十轮来回，里面既有写代码、解释代码，也有调用工具、读文件、查搜索。贵模型每轮都上场，账单会像开了加速器一样飞；便宜模型单独上场，质量又容易飘。RLM-Cascade 试图把这两个极端揉在一起：简单的让便宜模型直接上，复杂的再请贵模型兜底。

RLM-Cascade 架构揭秘：三个路径，一招制胜

RLM-Cascade 的架构其实不复杂，核心就是三条路，像高速公路分流：SKIPPED、Draft+Verify、Direct。名字听着像炫技，实际是非常朴素的工程分层。
表1：复杂度路由规则（按顺序评估）
表1：复杂度路由规则（按顺序评估）。系统先看是否是工具调用，再看是否命中简单前缀、复杂关键词，最后再看输入长度。路由器不是“灵机一动”，而是先按硬规则把最容易判断的请求分出去。
第一条路是SKIPPED。简单请求直接绕过 Opus，只让 DeepSeek 出结果。这里的“跳过”不是偷懒，而是承认一个事实：大量日常请求根本不值得把最贵模型请出来。比如打招呼、简单解释、基础代码片段，这些任务如果都用顶配模型，属于“拿火箭送外卖”。
第二条路是Draft+Verify。DeepSeek 先写草稿，再交给 Opus 审核。Opus 不是简单复读，而是根据验证结果给出两种判定：USE_DRAFT 表示草稿可直接用，ENHANCE 表示需要改写。这里的 Opus 其实更像“总编”，不负责从零写每个字，而是盯住质量底线。
表2：判定结果、触发条件与相对成本
表2：判定结果、触发条件与相对成本。SKIPPED 的成本大约只有 Opus-only 的 2%，ACCEPTED 约 20%，ENHANCED 则可能略高于直接调用 Opus，因为它要多承担草稿输入和改写开销。
第三条路是Direct，专门给工具调用类请求。这个设计很关键，因为工具调用不是普通文本生成，而是 schema 约束很强的 JSON 输出，稍微写歪一点，客户端执行循环就可能断掉。换句话说，工具调用这类请求不适合“先草稿再说”，它更像“必须一次写对”的硬任务。
这三条路背后有一个很实用的判断：不是所有请求都该走同一条链路。大模型服务里最常见的误区，就是把“模型能力”当成唯一变量，忽略了请求类型、输出格式、成本约束、延迟敏感度这些现实问题。RLM-Cascade 的价值就在于，它没有试图让一个模型包打一切，而是让系统学会分工。
表3：不同 SKIPPED 比例下的预测节省
表3：不同 SKIPPED 比例下的预测节省。只要简单请求占比越高，整体节省就越明显；而且论文给出的临界点很低，SKIPPED 比例只要超过约 13.3%，系统就开始赚钱了。

规则路由器居然比模型更懂请求，7 成请求直接跳过 Opus

这篇论文最“反直觉”的地方之一，是路由器不是训练出来的，而是规则写死的。很多人一看就想：这也能发论文？但工程里真不一定非要上复杂模型。只要场景足够明确，规则路由器反而更稳、更便宜、更容易解释。
它的判断逻辑很朴素：先看是不是工具调用；如果不是，再看是否命中简单前缀，比如“what is”“summarize”；再看复杂关键词，比如 class、security、sql；最后看输入长度是否超过 1500 字符。整个过程是 O(1) 级别，不需要再调用模型，连额外推理成本都省了。
这里有个很重要的工程判断：路由错一点点，通常只是省少一点钱；但路由对了，能省很多钱。论文也承认，false positive——把简单请求误送进 Draft+Verify——主要是多花一点钱；而 false negative——把复杂请求误判成简单请求——才会带来质量风险。所以路由器的目标不是“花里胡哨”，而是优先避免漏掉复杂任务。
表4：不同评测集上的判定分布
表4：不同评测集上的判定分布。无论是线上真实请求还是扩展任务集，SKIPPED 都稳定落在 64% 到 70% 左右，说明这套路由不是靠偶然样本“刷出来”的。
更妙的是，论文还专门把工具调用单独拎出来。因为 agentic coding 场景里，工具调用并不是边角料，而是主菜。Claude Code 这种工作负载里，70% 到 80% 的轮次都是工具选择轮次，文本生成轮次反而只占少数。也就是说，若没有这个“Direct”旁路，推测式解码会被大量不适合它的请求拖累。
这也是论文里很务实的一点：它没有把所有请求都当成“值得优化的文本生成”，而是承认现实系统里有大量结构化输出、协议约束和工具链依赖。很多方案死在“只优化模型，不优化请求形态”；这篇工作至少知道，真正掏钱的是系统，不是论文标题。

反向直觉：成本、延迟和质量竟然能同时提升

一般人听到“多加一层验证”，第一反应是：这不就更慢、更贵了吗？ 结果这篇论文偏偏把这个直觉打脸了：在真实负载里，它不仅更省钱，还更快，质量还没掉，甚至略有提升。
表6：不同评测集上的 API 成本节省
表6：不同评测集上的 API 成本节省。线上服务集全量累计节省 45.8%，建筑化评测集达到 47.4%。这不是“实验室里抠出来的 0.3 个点”，而是能直接写进账单的节省。
为什么会这样？核心原因是 SKIPPED 路径占比太高，而且它确实快。论文在 125 个真实生产请求上观察到，draft 使用率达到 88.8%，其中大量请求直接走 DeepSeek-only，绕开 Opus。由于 Opus 的输出单价远高于 DeepSeek，哪怕只有一部分请求被拦截到便宜路径，整体成本就能明显下降。
表7：三端点延迟与吞吐对比
表7：三端点延迟与吞吐对比。Remote Speculate 的 p50 端到端延迟是 2026 ms，而 Native Opus 是 3698 ms，速度提升 1.83×。更有意思的是，TTFT 反而更慢，因为它要先等草稿写完再验证，这就是典型的“前面慢一点，后面快很多”。
这个结果看起来反直觉，其实很合理。大多数请求根本不需要经过 Opus，所以整体 latency 的中位数被 DeepSeek-only 路径拉下来了。也就是说，这套系统不是“让 Opus 更快”，而是“让大部分请求别再排队等 Opus”。这和现实中的排队系统很像：少数慢车不影响大多数快车先走。
质量方面也没有掉链子。20 题的 Code/Math/Instruct 综合测试里，Remote Speculate 达到 100%，Native Opus 是 95%。这说明验证阶段不只是“省钱过滤器”，还可能起到一种意外的纠错作用：草稿把问题框住后，Opus 更像在做定向修正，而不是从零自由发挥。
表8：质量基准通过率
表8：质量基准通过率。Remote Speculate 在代码、数学、指令跟随上都是 100%，Native Opus 在指令跟随上只有 80%。这说明“先草稿、再纠错”的提示方式，有时比开放式生成更容易把约束卡稳。
这部分最值得记住的一句话是：它不是在“加计算”，而是在“换计算位置”。把大量简单请求从贵模型挪走，把少量复杂请求交给贵模型精修，于是成本、延迟、质量三项指标同时受益。能做到这点，靠的不是玄学，而是对工作负载分布的准确判断。

翻车现场：这种场景下 Opus 反而更贵了

表9：ENHANCED 任务结果
表9：ENHANCED 任务结果。大多数复杂任务即便走了 Draft+Verify 也仍然省钱，但也有少数任务会出现“成本倒挂”，也就是比直接调用 Opus 还贵。
最典型的例子是 mteb-retrieve。这个任务里，DeepSeek 先生成了一个短但错误的草稿，Opus 接手后不仅要纠错，还把答案扩写得更长，最后总 token 成本反而高于直接从 Opus 出发。这个案例很有教育意义：验证模型如果把短错答案改成长对答案，省钱逻辑就可能被反杀。
这也说明，RLM-Cascade 真正的系统瓶颈不只是“草稿质量”，更是“路由精度”。如果复杂任务被错误送进 SKIPPED，质量风险最大；如果简单任务被过度送进 Draft+Verify，成本会被悄悄吃掉。论文把这件事讲得很明白：路由器才是总开关，模型只是执行器。
换句话说，这套系统并不是“任何任务都稳赚不赔”的万能券。它更像一个精细分账器：简单任务越多，收益越稳；复杂任务越多，Draft+Verify 的价值越依赖草稿是否靠谱、验证是否克制。工程落地时，最该盯的不是单次 demo，而是任务分布是否和论文里的生产负载接近。

论文精髓：系统设计、直觉分析与开源展望

如果把这篇论文压缩成一句话，那就是：把“推测式解码”从模型内部搬到 API 外围，让不同厂商、不同架构、不同成本层级的模型能协同工作。它不是在追求最漂亮的理论证明，而是在追求一个能进生产的系统方案。
它的两个关键直觉特别值得记住。第一，简单请求不该浪费在贵模型上；第二，验证不一定要逐 token 做，整段判断同样能带来可接受的质量与更好的部署弹性。前者解决成本，后者解决接入门槛。两者叠加，才有了“跨厂商、跨架构、跨系统”的现实意义。
不过，这篇工作也不是没有边界。它的 TTFT 会变慢，说明对强交互、强流式体验的场景还不够友好；它依赖规则路由，说明泛化到完全未知请求时仍要额外验证；它还受制于上游 API 的价格、限流和模型版本漂移。换句话说，论文展示的是一条很实用的路，但不是终点。
它开源并提供实时 dashboard 和 Prometheus 监控，这点很加分。因为很多“省钱方案”只会在 PPT 上省钱，一落地就没人知道到底省了多少。RLM-Cascade 至少把可观测性补齐了，这才像一个真正面向企业 AI 基础设施的方案。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决什么问题？解决的是 LLM API 服务里“贵模型太贵、便宜模型太弱、直接路由又怕翻车”的老大难问题。RLM-Cascade 用便宜模型先出草稿，再由贵模型决定是否直接放行或改写，从而把成本压下来，同时尽量守住质量。

SKIPPED、ACCEPTED、ENHANCED 分别是什么意思？SKIPPED 是简单请求直接走便宜模型，不再调用 Opus；ACCEPTED 是 Opus 认为草稿没问题，直接放行；ENHANCED 是 Opus 认为草稿不够好，需要重写或补强。三种结果对应三种成本路径。

为什么这套方法能同时省钱、提速、还不掉质量？因为大多数真实请求其实很简单，直接走 DeepSeek-only 就能完成；只有少数复杂请求才需要 Opus 介入。这样一来，整体中位延迟被大量“快路径”拉低，成本也被贵模型调用次数压下，而质量则由 Opus 的验证机制兜底。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆。把推测式解码从 token 级搬到响应级，思路不算玄，但落地方式很聪明，尤其适合 API-only 场景。

实验合理度：★★★★☆。有真实生产流量、有多种 benchmark、有延迟和质量的联合评估，比较像一篇真做系统的论文。

学术研究价值：★★★★☆。它把“模型内部技巧”转成“系统层可部署技巧”，对 LLM serving 和 agentic AI 都有启发。

稳定性：★★★☆☆。线上可用，但依赖路由规则和上游 API 稳定性，遇到请求分布变化时还要重新校准。

适应性以及泛化能力：★★★☆☆。对 agentic coding 这类结构化工作负载很合适，但对强流式聊天或高度开放式创作场景未必同样漂亮。

硬件需求及成本：★★★★☆。主打的是 API 成本优化，不是堆本地算力；对企业来说，省下的是账单，不是显卡。

复现难度：★★★☆☆。思路清楚，但真实效果依赖具体模型、价格、请求分布和线上流量，完全照搬不一定一模一样。

产品化成熟度：★★★★☆。已经在生产环境里跑了，且有监控、指标和开源接口，属于“能上桌吃饭”的方案。

可能的问题：路由规则偏手工，TTFT 有回退，且在低质量草稿被长篇纠错时可能出现成本倒挂，后续若能做成可学习路由会更强。


主要参考文献

[1] Y. Leviathan, M. Kalman, and Y. Matias, “Fast inference from transformers via speculative decoding,” ICML, 2023.
[2] C. Chen et al., “Accelerating large language model decoding with speculative sampling,” arXiv:2302.01318, 2023.
[3] L. Chen, M. Zaharia, and J. Zou, “FrugalGPT,” arXiv:2305.05176, 2023.
[4] X. Yue et al., “Large language model cascades with mixture of thoughts representations for cost-efficient reasoning,” arXiv:2310.03094, 2023.
[5] X. Wang et al., “Self-consistency improves chain of thought reasoning in language models,” ICLR, 2023.
[6] W. Kwon et al., “Efficient memory management for large language model serving with PagedAttention,” SOSP, 2023.
[7] G. Yu et al., “Orca: A distributed serving system for Transformer-based generative models,” OSDI, 2022.
[8] T. Cai et al., “Medusa: Simple LLM inference acceleration framework with multiple decoding heads,” ICML, 2024.
[9] Y. Li et al., “EAGLE: Speculative sampling requires rethinking feature uncertainty,” arXiv:2401.15077, 2024.
[10] D. Xu et al., “Big-little transformer decoder for optimal inference-time cost,” arXiv:2302.07030, 2023.
[11] L. Zheng et al., “Judging LLM-as-a-judge with MT-Bench and Chatbot Arena,” NeurIPS, 2023.
[12] A. Agrawal et al., “Taming throughput-latency tradeoff in LLM inference with Sarathi-Serve,” OSDI, 2024.

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helperdianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。