Recoleta Item Note

Balancing Latency and Accuracy of Code Completion via Local-Cloud Model Cascading

本文提出 MCCom，用本地小模型优先、必要时再切换云端大模型的级联方式，来改进代码补全中的延迟-准确率权衡。其核心在于结合用户行为做路由，并让小模型与大模型通过推测解码和迭代检索协同工作。

code-completionmodel-cascadingspeculative-decodingretrieval-augmented-generationlatency-accuracy-tradeoff

Summary

代码行级补全需要实时低延迟与高准确率同时成立，但现有方案通常二选一：大模型更准却更慢、更贵，小模型/静态分析更快却常常不够好。
在真实开发中，这个问题很重要：文中引用研究称 44% 的开发者期望语句级补全在 0.5 秒内返回，而 45% 的用户认为当前补全工具的主要问题是质量低。
要做模型级联，关键难点有两个：何时升级到大模型，以及如何让小模型和大模型有效协作，否则会损失速度或准确率。

提出 MCCom：默认先在本地运行一个 121M 小模型，仅在必要时才调用云端大模型，从而减少平均等待时间和云侧算力消耗。
路由策略分两步：先看小模型前 3 个 token 的平均概率来预判是否低置信；若先展示了小模型结果，再通过用户是否继续输入/是否接受补全来判断是否隐式拒绝，并在拒绝后升级到大模型。
为了加速两端推理，设计了两阶段推测解码：先用上下文精确匹配构造几乎零成本草稿给小模型；若小模型结果被拒绝，再把它作为大模型的 speculative draft，加速大模型解码。
为了提升大模型质量，设计了迭代检索：第一次用左右上下文做 BM25 检索；若小模型输出被拒绝，则把该输出作为新的语义线索再次检索，并按小模型置信度加权融合检索分数，给大模型提供更相关上下文。
由于缺少合适的小模型，作者还基于 41M 个 Python 训练样本自行训练了一个轻量代码补全模型，并在 41K 验证样本上进行分析与验证。

作者训练的 121M 小模型在基准上达到最先进 7B 模型平均性能的 73.8%；在 41K 真实仓库验证样本上，即使不使用 RAG，也能正确处理 37.8% 的案例。
速度方面，文中称该 121M 本地模型相比部署在云端 Nvidia A800 GPU 上的 7B 大模型，推理速度约快 2 倍。
在 RepoEval 和新提出的 StmtEval 上，MCCom 将推理延迟降低 5.8%–47.9%，平均降低 25.6%；摘要还给出平均可减少 46.3% 的大模型使用量。
准确率方面，MCCom 相比“始终调用大模型”的基线，Exact Match 提升 2.9%–13.5%，平均提升 8.9%。
文中还给出支持级联设计的实证观察：小模型输出有 14.4% 会直接出现在左侧上下文中；在随机 1000 个样本上，小模型与大模型输出的平均 ES 相似度为 78.4%，说明两阶段推测解码有现实基础。
论文声称该方法对多种大模型都表现出一致有效性，并额外提出了更贴近真实交互场景的新基准 StmtEval；但摘录中未提供更细的分模型分数据表格。

Built with Recoleta

Turn arXiv, Hacker News, OpenReview, Hugging Face Daily Papers, and RSS into local Markdown, Obsidian notes, Telegram digests, and a public site.