长程编码 Agent 有个尴尬的成本结构:一个任务动辄几十上百步,业内惯常做法是把每一步都丢给云端前沿大模型。NVIDIA 的研究团队最近在 arXiv 上挂出论文 EdgeWise,开头就戳破这层窗户纸——不是每一步都需要大模型的能力,但每一步都在按大模型的价格付费。

云端大模型的价值,集中在少数关键步骤

论文先做了一个观察实验:分析 2.4k 条编码 Agent 轨迹,把每一步归入六类操作(写、读、搜、命令、思考、其它),然后随机抽 40% 的步骤路由到云端 GPT-5.5 或 Claude Opus 4.8。结果既出人意料又在情理之中:即便云端覆盖比例固定到 40%,性能却和「每步都用云端」相差无几,有时甚至更好。配合皮尔逊相关分析,发现真正与最终结果强相关的只有写、复杂读这两类——「在哪个步骤请求云端」比「总共请求多少次」更关键。

这个观察直接把 EdgeWise 的设计锚定下来:本地跑一个小模型扛下绝大多数动作,云端只在写代码和复杂阅读这种关键节点被点醒,剩下的步骤按本地便宜算力结算。

步级 RL 让 9B 模型学会「喊人」

EdgeWise 提供两套委托策略。第一套叫二元委托:每一步跑完都过一道外部裁判模型,根据这一步的难度和重要程度决定本地要不要喊云端。裁判是事后调度,稳健但每一轨都要算两次账。

第二套是论文重点——自委托。Qwen3.5-9B 先用监督微调学一遍,再用步级强化学习把「什么时候该喊云端」压进模型权重。奖励来自最终任务结果,经过细粒度的信用分配回传到每一次委派决策。换句话说,模型在训练时就知道「这一招喊晚了吃亏,喊早了浪费」。推理时不需要再带裁判,本地 9B 模型自己就能拍板要不要把这一步丢给云端。

论文同时给出第三种范式:上下文管理。云端被叫来时,本地应该把整段轨迹都喂给它还是只喂当下状态?EdgeWise 给出统一答案——完整的交互历史通常表现最好,代价是 token 贵一点;如果你想再抠一点成本,可以筛掉无关步骤。

数字:53% / 63% / 50%,三组关键节流

主表里的对照选 Qwen3.5-9B 当本地主力,云端分别接 GPT-5.5 和 Opus 4.8,任务最长 80 步。在 SWE-ReBench 上,自委托把云端成本砍掉 53%(配 GPT-5.5)和 63%(配 Opus 4.8);在 Terminal-Bench 2.1 上分别砍 35% 和 33%。Pass@3 与全程云端基本持平,平均差距写出来就是 0.0%。

跨 4 个 harness(自训练用 Terminus2,评估再跨 OpenHands、π、mini-swe-agent)做迁移,自委托在没见过的 harness 上依然把成本压下来 25% 以上——说明「何时喊云端」这个能力是 harness 无关的元技能,不绑定具体框架。

最后落到真机:EdgeWise 跑在 DGX Spark 本地工作站上,把成本再降约 50%,Pass@3 与云端 A100 设置相当。这一段是真金白银的实战:不是机房里跑出来的纸面数字,而是终端开发者能用上的边云协同。

所以呢

EdgeWise 给了一个被反复讨论但一直没有干净答案的问题的可执行答案:小模型能不能当主力?答案是能,但前提是它得知道自己哪一步不行。步级 RL 把「不行」内化进 9B 模型本身,本地模型会喊人且喊在刀刃上——成本结构可以重新画。

参考来源:EdgeWise 论文(arXiv:2610.17560,https://arxiv.org/abs/2610.17560 );NVIDIA 项目页(https://research.nvidia.com/labs/lpr/edge-wise/)。