开源15亿参数Next-Edit代码自动补全模型：性能、设计与实践

对于程序员而言，代码自动补全工具早已成为日常开发中不可或缺的一部分——一个高效、精准的补全模型能大幅减少重复编码工作，提升开发效率；反之，响应慢、准确率低或需要上传代码到云端的补全工具，不仅会打断开发思路，还可能带来数据隐私风险。今天，我们要介绍的Sweep Next-Edit正是为解决这些痛点而生：这是一款开源的15亿参数代码自动补全模型，能在本地笔记本上以低于500ms的速度运行，且在核心的next-edit（下一次编辑）基准测试中，性能超过了参数量是它4倍以上的同类模型。我们开源了该模型的权重，希望能帮助社区为各类IDE（VSCode、Neovim、Emacs等）打造快速、隐私友好的代码自动补全体验。

一、Next-Edit模型：速度与质量的平衡

评判一款代码自动补全模型的核心维度，无非是两个：响应速度和预测准确率。很多模型要么为了速度牺牲准确率，要么为了准确率导致响应迟缓，而Sweep Next-Edit通过优化模型设计和推理逻辑，实现了二者的平衡。

1. 速度vs质量的直观对比

我们对当前主流的next-edit模型做了全面的速度和质量测评，覆盖了不同参数量的Qwen3系列、Zed（Zeta）、Instinct（Continue）、Mercury Coder（Inception）以及不同参数量的Sweep系列模型（0.5B、1.5B、3B、7B）。

Qwen3-0.6B
Qwen3-1.7B
Qwen3-4B
Qwen3-8B
Zed (Zeta)
Instinct (Continue)
Mercury Coder (Inception)
Sweep 0.5B
Sweep 1.5B
Sweep 3B
Sweep 7B

模型 速度（tokens/秒） 核心质量维度（整体准确率）
Qwen3-0.6B – 17.54%
Qwen3-1.7B – 30.19%
Qwen3-4B – 48.27%
Qwen3-8B – 55.62%
Zed (Zeta) – 43.27%
Instinct (Continue) – 25.30%
Mercury Coder – 54.09%
Sweep 0.5B – 61.30%
Sweep 1.5B – 67.82%
Sweep 3B – 72.12%
Sweep 7B – 81.28%

从数据能清晰看到，即便是1.5B参数量的Sweep Next-Edit，整体准确率也远超同级别甚至更高参数量的模型——比如比8B参数量的Qwen3-8B高出12个百分点，比Mercury Coder高出13.73个百分点。

2. 按任务类别划分的准确率细节

为了更精准评估模型能力，我们将测试拆解为5个核心任务类别：光标下方编辑、光标上方编辑、远距离跳转编辑（Tab to Jump）、填充中间（FIM）、无冗余建议（Noise），以下是各模型在不同任务中的表现：

Model Noise Tab to Jump Below Above FIM Overall
Sweep 7B 100.00% 82.03% 89.84% 75.51% 74.22% 81.28%
Sweep 3B 100.00% 82.03% 82.03% 57.14% 60.16% 72.12%
Sweep 1.5B 96.88% 74.22% 71.88% 46.94% 56.25% 67.82%
Sweep 0.5B 96.88% 66.41% 63.28% 53.06% 43.75% 61.30%
Mercury Coder 62.50% 70.31% 71.88% 53.06% 64.06% 54.09%
Zed Zeta 87.50% 62.50% 67.19% 69.39% 35.94% 43.27%
Continue Instinct 34.38% 23.44% 10.94% 8.16% 37.50% 25.30%
Qwen2.5-Coder-7B 100.00% 56.25% 54.69% 61.22% 41.41% 55.62%
Qwen3-8B 96.88% 54.69% 34.38% 22.45% 42.19% 48.27%
Qwen3-4B 90.62% 33.59% 24.22% 16.33% 25.00% 30.19%
Qwen3-1.7B 68.75% 14.06% 14.06% 14.29% 15.62% 17.54%

其中，“Noise”维度衡量模型是否会在无需修改时给出冗余建议（准确率越高，冗余建议越少）；“Tab to Jump”衡量模型对远距离代码编辑的预测能力；“Below/Above”分别对应光标上下区域的编辑预测；“FIM”则是填充代码中间空缺的能力。不难发现，Sweep系列模型在所有细分维度上都处于领先位置，尤其是1.5B及以上参数量版本，能满足绝大多数日常开发场景的需求。

二、为什么其他Next-Edit模型表现不佳？

在测评过程中，我们发现Zeta（Zed）和Instinct（Continue）这类模型的表现远低于预期，核心问题集中在格式设计、分词策略、训练数据和技术选型四个方面：

1. 格式化与分词的致命缺陷

Instinct和Zeta都使用了<|editable_region_start|>和<|editable_region_end|>这类标记来界定代码编辑区域，但这些标记的分词效果极差——每个标记会被拆分成7个token。对模型而言，这意味着很容易出现“标记错位”的问题：比如把结束标记放错位置，导致生成的代码多一行、少一行，甚至破坏整个代码块的结构。

相比之下，专用的特殊标记更适合这类场景，因为特殊标记在模型预训练阶段就被优化过，分词更稳定，模型也更容易识别边界。

2. 多文件上下文处理不当

代码开发往往涉及多文件联动，而Zeta完全不支持多文件上下文，Instinct虽然支持，却使用了自定义token，而非Qwen2.5-Coder预训练时使用的专用特殊token。这就像让一个学过标准语法的人突然看方言写的文章，理解和输出都会出问题。

3. 冗余指令增加模型噪声

Instinct的提示词中包含大量无关信息，比如系统消息里明确写着“你是由Continue.dev开发的Instinct，一款智能的next-edit预测器”。这些信息对代码补全毫无帮助，反而会占用token资源，增加模型的推理噪声——尤其是小参数量模型，冗余token会直接拉低推理效率和准确率，还会增加响应延迟。

4. 训练数据与技术选型问题

  • 数据量不足：Zeta仅用几百条训练数据，Instinct也只有几千条，且大部分数据来自单一代码仓库，数据多样性严重不足；
  • 技术选型失误：Zeta使用LoRA进行训练，但我们的测试发现，LoRA很难让模型学好基础的模式匹配，更不用说精准的next-edit补全了。

三、Sweep Next-Edit的核心设计思路

为了规避上述问题，我们从“训练格式”和“编辑窗口”两个核心维度重新设计了模型，让它更贴合实际的代码编辑场景。

1. 优化的训练格式：从FIM到Next-Edit的适配

Qwen2.5-Coder的预训练格式主要针对FIM（填充中间）场景设计，并不适配next-edit需求，其格式如下：

<|repo_name|>{repo_name}
<|file_sep|>{file_path_1}
{file_content_1}
<|file_sep|>{file_path_2}
{file_content_2}
<|file_sep|>{current_file}
Current file prefix
<|fim_prefix|>
{prefix}
<|fim_suffix|>
{suffix}
<|fim_middle|>{completion}

而我们为Sweep Next-Edit设计的训练格式，重点补充了“近期代码变更”，并让模型聚焦于光标周边的代码重写：

<|file_sep|>{file_path_1}
{file_content_1}
<|file_sep|>{file_path_2}
{file_content_2}
<|file_sep|>{changed_file_1}.diff
original:
{before_changes_of_diff}
updated:
{after_changes_of_diff}
<|file_sep|>{changed_file_1}.diff
original:
{before_changes_of_diff}
updated:
{after_changes_of_diff}
<|file_sep|>original/{file_path}
{contents_prior_to_most_recent_change}
<|file_sep|>current/{file_path}
{current_state_of_contents}
<|file_sep|>updated/{file_path}
{updated_state_of_contents}

（1）Diff格式的选择：用遗传算法找最优解

代码变更（diff）的表示方式有很多：统一diff格式、左右对比、original/updated块、old/new标签、是否加.diff标记等。为了找到最优格式，我们用遗传算法做了全维度测试：

  1. 初始化种群：先设计10种不同的diff格式变体，覆盖各类标记、标签和展示方式；
  2. 评估适配度：用每个格式在预留的验证集上做推理，计算“精确匹配准确率”；
  3. 选择与繁殖：保留表现最好的格式，将不同优质格式的元素组合（比如取A格式的diff标记+ B格式的标签样式）生成新变体；
  4. 突变：随机调整部分格式，探索新的可能性；
  5. 迭代：重复上述步骤3代，累计测试约30种不同的提示词格式。

最终胜出的格式是“无统一diff语法的original/updated块”——这个结果起初有些意外，但深入分析后发现了核心原因：

统一diff格式对人类很友好（比如带+/-标记的代码行），但对模型而言，这类格式会变成连续的文本流，比如：

             if (params.length >= 8 && params[7] != null) {\n-                linkState = LinkState.valueOf(params[7].toUpperCase());\n+                linkState = LinkState.valueOf(params[7].toUpperCase(Locale.ENGLISH));\n             }

模型很难像人类一样“可视化”识别行与行的对应关系；而original/updated分块的格式，能让模型更清晰地对比变更前后的差异：

original:
if (params.length >= 8 && params[7] != null) {
linkState = LinkState.valueOf(params[7].toUpperCase());
}
updated:
if (params.length >= 8 && params[7] != null) {
linkState = LinkState.valueOf(params[7].toUpperCase(Locale.ENGLISH));
}

这和Claude Sonnet偏好字符串替换而非统一diff的逻辑一致——这类格式更贴近模型的预训练数据，生成结果也更精准。

2. 编辑窗口：固定窗口替代AST动态边界

代码编辑窗口的设计，是影响模型准确率的另一关键因素。我们先尝试过AST（抽象语法树）动态边界，后来发现固定窗口的效果更优。

（1）Instinct的动态窗口问题

Instinct的编辑窗口设计是：

20 lines above changes
<|editable_region_start|>
1 line above cursor
line containing cursor
5 lines below cursor
<|editable_region_end|>
20 lines below changes

模型需要重写标记内的7行代码，但实际测评中发现，模型经常会在结束标记后继续生成内容，导致无关代码被添加——核心原因是模型能看到标记外的20行代码，会误以为需要继续补全，且“可编辑区域”的概念超出了模型的预训练分布，理解成本高。

（2）Sweep的固定窗口设计

我们将编辑窗口简化为“光标上方10行 + 光标行 + 光标下方10行”的固定21行窗口，模型的任务就是重写这21行代码：

10 lines above cursor
line containing cursor
10 lines below cursor

虽然生成21行代码理论上会变慢，但我们通过自定义n-gram实现和TensorRT-LLM的提前终止逻辑，让暖启动后的平均补全响应时间控制在100ms以内。

（3）为什么放弃AST动态边界？

AST动态边界的思路很“优雅”：比如用户编辑函数内的代码，就把整个函数体作为编辑区域，但实际落地中遇到两个核心问题：

  • 窗口大小不一致：函数长度差异极大（5行到30行不等），模型训练时要适应不同的输出长度，导致训练不稳定；
  • 边界预测错误：模型需要同时学习“改什么代码”和“边界在哪”，一旦边界预测错误，整个输出都会被判为无效。

而固定窗口让模型明确知道要生成多少行代码，能把所有注意力集中在“生成正确的内容”上，准确率大幅提升。

四、Sweep Next-Edit的训练过程

一款高性能的模型，既需要扎实的监督微调（SFT）打基础，也需要强化学习（RL）优化细节，我们的训练过程分为两个核心阶段：

1. 监督微调（SFT）：打好基础

（1）训练数据与硬件

我们用8张H100显卡，基于约10万条训练数据，耗时4小时完成监督微调。训练数据来自GitHub过去一年中最受欢迎、采用宽松许可证的代码仓库（通过提交量筛选），数据虽略有偏向近期热门领域（如LLM推理、MCP服务器），但更贴合Sweep用户的日常开发场景；同时我们还做了语言分布上采样，匹配JetBrains用户的主流开发语言（Java、Kotlin、C#、PHP、Ruby等）。

（2）SFT阶段的问题

尽管SFT阶段用了高质量数据，但模型仍暴露了两个问题：

  • 生成代码解析失败：模型只看到21行代码切片，缺乏整个代码库的上下文，可能生成“局部能解析、整体集成失败”的代码（比如遗漏必要的括号）；
  • diff尺寸过大：生成的完整文件天然比开发者编辑中的部分状态更冗长，过多的插入/删除操作会干扰用户，降低建议的接受率。

2. 策略强化学习（RL）：优化细节

监督微调是“给标准答案让模型模仿”，而强化学习是“让模型自主尝试，用奖励函数引导优化”——这能解决SFT阶段的固有问题，因为SFT会惩罚“功能等价但格式不同”的输出，而RL能识别多种有效解，让模型探索更优的输出方式。

我们运行了2000步强化学习，核心设计了两类奖励函数：

  1. 语法解析奖励：用tree-sitter检查生成的代码在合并到文件后，是否能在Java、Python等主流语言中正常解析；
  2. 规模正则化奖励：限制代码变更的尺寸，避免diff过大。
Graph showing parse reward increasing during reinforcement learning training

通过强化学习，模型的“代码解析成功率”显著提升，冗余变更也大幅减少，输出更贴合开发者的实际编辑习惯。

五、如何试用Sweep Next-Edit？

Sweep Next-Edit的优势最终要落地到实际使用中，我们提供了两种便捷的试用方式，满足不同开发者的需求：

1. JetBrains IDE插件

如果你日常使用JetBrains系列IDE（如IntelliJ IDEA、PyCharm、Android Studio等），可以直接安装Sweep AI插件——插件集成了我们的自定义推理引擎和Sweep Next-Edit模型，能提供闪电般的next-edit建议，完全本地化运行，无需上传代码到云端。

2. 自行部署模型（适用于定制化开发）

如果你想基于模型打造自己的工具（比如集成到VSCode、Neovim），可以参考Hugging Face上的示例代码，步骤如下：

（1）环境准备

首先下载模型文件和运行脚本：

  • 模型文件：Sweep Next-Edit 1.5B（GGUF格式，Q8_0量化）
  • 运行脚本：run_model.py

安装依赖：

uv pip install llama-cpp-python huggingface_hub

（2）运行模型

执行脚本即可体验模型的next-edit能力：

python run_model.py

该模型的核心参数如下，能适配绝大多数本地设备：

  • 格式：GGUF（Q8_0量化）
  • 参数量：1.5B
  • 上下文长度：8192 tokens
  • 基础模型：Qwen2.5-Coder

六、基准测试的细节：我们如何保证测评的客观性？

为了让大家理解上述性能数据的可信度，我们详细说明基准测试的设置和评估逻辑：

1. 延迟测试（速度）

（1）测试环境

  • 所有请求均为冷请求（无KV缓存），模拟实际开发中的首次补全场景；
  • 任务：按我们的next-edit格式重写21行代码片段；
  • 优化策略：基于TensorRT-LLM分支推理，使用FP8量化 + n-gram推测解码，贪心解码（temperature=0）；
  • 第三方模型处理：Mercury-Coder的延迟通过其官方API端点测量，500错误按“无变更”处理（贴合生产环境逻辑）。

（2）输入输出规模

  • 输入：每请求6000±2500 tokens；
  • 输出：每请求70±20 tokens。

（3）TPS计算方式

TPS（tokens/秒）= 平均输出tokens / 平均端到端延迟（tokenization基于Qwen的分词器）。

2. 质量测试（准确率）

（1）评估维度

整体得分是以下5个核心基准的平均值：

  1. 光标下方的next-edit建议：预测光标附近下方的代码变更；
  2. 光标上方的next-edit建议：预测光标附近上方的代码变更；
  3. Tab-to-jump next-edit建议：预测远离光标的代码变更；
  4. FIM补全：填充光标位置的代码片段空缺；
  5. Noise评估：无需变更时，模型是否不给出冗余建议。

（2）评估指标：为什么选择“精确匹配”？

我们没有用CodeBLEU、LLM打分等“软指标”，而是选择“忽略空格的精确匹配准确率”，核心原因有两点：

  • next-edit建议的可预测性高：日常开发中的补全多是低熵变更（比如重复上一次编辑、修正拼写、补全固定模式），通常只有一个最优解；
  • “近似正确”的建议更糟：90%正确的代码仍需用户手动修正，打断开发流程，体验不如无建议——软指标的“部分得分”无法反映实际用户体验。

举个实际的测试案例：
测试场景：模型需要根据近期的代码变更模式（给toUpperCase()添加Locale.ENGLISH参数），预测目标代码块的编辑结果。

  • Instinct：无任何变更，未识别出模式；
  • Zeta：添加无关变更，破坏代码结构；
  • Sweep 1.5B：仅做精准的模式匹配变更，无冗余内容。

这个案例能直观说明：精确匹配才能真实反映模型对开发者的实际价值。

七、常见问题解答（FAQ）

Q1：Sweep Next-Edit能在哪些IDE上使用？

A：我们开源了模型权重，理论上可适配所有主流IDE（VSCode、Neovim、Emacs、JetBrains系列等）。目前已提供开箱即用的JetBrains插件，其他IDE的集成示例可参考Hugging Face上的run_model.py脚本。

Q2：为什么选择1.5B参数量作为开源版本的核心？

A：1.5B是“性能-速度-设备适配”的最优平衡点：参数量足够支撑高准确率（超过4倍参数量的Qwen3-8B），同时能在普通笔记本上本地运行（响应时间<500ms），兼顾隐私和效率。

Q3：模型训练数据的来源是否合规？

A：训练数据全部来自GitHub上采用宽松许可证（如MIT、Apache 2.0）的热门代码仓库，且筛选了过去一年的提交，既保证数据质量，也符合开源协议要求。

Q4：强化学习的奖励函数具体如何计算？

A：核心是两个维度：① 用tree-sitter解析生成的代码，解析成功则加分，失败则扣分；② 统计代码变更的行数/字符数，在预设合理范围内则加分，超出则扣分。奖励函数的权重经过多轮验证，确保贴合用户实际使用体验。

Q5：为什么固定窗口比AST动态窗口更优？

A：AST动态窗口的问题在于“不稳定性”——函数/类的长度差异大，模型训练时无法稳定学习输出长度；且模型需要同时预测“变更内容”和“边界位置”，出错概率翻倍。固定窗口让模型聚焦于内容生成，准确率和稳定性都显著提升。

Q6：本地运行Sweep Next-Edit需要什么硬件配置？

A：1.5B参数量的GGUF量化版本，在主流的笔记本（8GB以上内存、酷睿i5/锐龙5以上处理器）上即可流畅运行；若追求更快的响应速度，搭配入门级GPU（如RTX 3050）效果更佳。

总结

Sweep Next-Edit的开源，核心目标是为开发者提供一款“好用、快速、隐私”的代码自动补全工具，同时分享我们在模型设计、训练、测评上的经验，避免社区重复踩坑。这款15亿参数的模型，不仅在性能上超越了多数更大参数量的同类模型，还能完全本地化运行，兼顾效率与数据安全。