26M小模型碾压微调LLM：手机端语法纠错4ms，准确率0.799

手机键盘里的语法纠错，究竟该用微调过的小型语言模型，还是从零训练一个编辑标注器？Mindscend 团队用一组详细的对比实验给出了答案：一个仅有 26.2M 参数的 GECToR 风格标注器，在准确率和误改率上全面击败了 Gemma 3 270M 和 SmolLM2 360M 的 LoRA 微调版本，且单句推理仅需约 4ms。

为什么不用 LLM 做纠错？

在手机键盘扩展中做语法纠错，约束条件远比想象中苛刻。iOS 键盘扩展的内存上限在 60-80MB 左右，超出就会被系统杀掉；键盘不需要 GPU 加速保证，但必须始终保持跟手响应。更关键的是，整个推理过程完全离线——iOS 端从不请求 Full Access，Android 端干脆没有 INTERNET 权限。

在这些约束下，团队还面临一个核心指标取舍：纠错的精确率比召回率重要得多。 改错一个正确的句子，对用户信任的伤害远大于漏掉一个错误。因此他们用 F0.5 作为主指标，同时单独追踪两个关键数据：误改率（把正确句子改错的比例）和丢失保护片段率（姓名、数字、邮箱、URL 被改动的比例）。

F0.5 分数是 F 分数的变体，通过给精确率（Precision）赋予比召回率（Recall）更高的权重（β=0.5）来计算。Fβ 的通用公式为 (1+β²)·P·R/(β²·P+R)，当 β=0.5 时精确率的权重是召回率的四倍。在语法纠错这类场景中，误改一个正确的句子对用户体验的伤害远大于漏掉一个错误，因此团队选择 F0.5 而非标准的 F1，以在评估中放大精确率的重要性，确保模型不会为了多抓错误而牺牲准确性。

2600万参数标注器的技术方案

团队的核心思路来自 GECToR（Omelianchuk 等人，2020）——不让模型生成文本，而是为每个词预测一个编辑标签。比如 He don't know 会被标注为 KEEP / REPLACE_doesn't / KEEP，标签执行后再让模型处理自己的输出，最多迭代 3 轮，从而支持依赖链式的修正。

模型的架构选择相当克制：8 层 encoder-only Transformer，d_model 384，6 个注意力头，FFN 维度 1536，最大 160 token，总共 26.2M 参数。自研 16k 字节级 BPE 分词器，15,000 个编辑标签。训练分两阶段：先在 FineWeb-Edu 约 2000 万句子上做掩码语言模型预训练，再用 1202 万对（噪声, 干净）数据做纠错微调——其中 30% 是恒等对，让模型学会把 $KEEP 当作真正的答案。整个训练在一台 RTX 3080 Ti 笔记本 GPU 上完成，总计约 9 小时。

字节级 BPE（Byte Pair Encoding） 是一种介于字符级和词级之间的子词分词方法。它从单个字节开始，反复合并语料中出现频率最高的相邻字节对，直到达到预设的词表大小。字节级 BPE 的关键优势在于：它天然支持任何 Unicode 字符，不会出现未登录词（OOV）问题，且词表可以做得非常紧凑。与常规的基于字符的 BPE 不同，字节级 BPE 直接操作原始字节序列，这使得模型能够处理任意语言和符号，对于手机键盘这种需要覆盖多种输入场景的应用尤为重要。

实测数据：小标注器 vs 小 LLM

结果对比非常直接。SmolLM2 360M 加 LoRA 微调后 F0.5 为 0.663，误改率 20.1%；而 26M 标注器 v1.5 的 F0.5 达到 0.799，误改率仅 2.4%，保护片段丢失率为 0.0%。零样本的 Gemma 3 270M 更是几乎不可用——F0.5 仅 0.122，99.6% 的正确句子都被改动了。

误改率的差距根源在于生成式纠错的机制：模型重新生成每一个 token，每个 token 都是一次改错的机会。微调能大幅降低这种倾向，但无法根除。

v1.5 相比 v1.2 的真正提升体现在特定错误类型上：真实拼写错误（”recieve”）的 F0.5 从 0.882 提升到 0.963，漏词（”I going home”）从 0.078 跃升至 0.698。但时态错误（”Yesterday I go”）仍然是短板，F0.5 只有 0.119，团队表示这是下一步攻克方向。

推理时防护：几行代码胜过一次训练

三个轻量级推理时技巧贡献了大量收益。KEEP 偏置——在 $KEEP 的 logit 上加一个常数，偏置值 1/2/3 直接对应用户可见的严格度设置（”多抓一些”/”平衡”/”只改确定的”）。保护片段——检测到姓名、数字、邮箱或 URL 后，只允许 $KEEP，结果是全测试集保护片段丢失率为 0.0%。合理性守卫——$REPLACE 只有在属于已知修正类型或编辑距离足够小时才被接受，上下文规则还会在下个 token 首字母大写、含数字或是 $ £ € # @ 等符号时保留介词。

合理性守卫中的“已知修正类型”指的是模型在训练数据中学习到的常见编辑操作类别，例如拼写纠正（recieve → receive）、主谓一致（He don't → He doesn't）等。只有当 $REPLACE 标签所对应的修改属于这些预定义的合法类型，或者编辑距离（即原词与替换词之间的字符差异数）小于某个阈值时，该替换才会被接受。这样可以防止模型在不确定的情况下做出过于激进的修改，从而进一步降低误改率。

一个反直觉的训练 Bug：训得越久越差

这是整篇分享中最有警示意义的部分。v1.3 和 v1.4 版本在正确文本上的误改率分别飙升到 7.4% 和 9.1%，而 v1.2 只有 3.1%。

根因是训练长度不对等。 团队的微调脚本把时间预算按 step 300 时测到的速度换算成步数。v1.2 恰好因为 VRAM 溢出（WSL 共享内存回退）导致速度测量偏慢，意外获得了较短的训练计划。溢出修复后，v1.3 和 v1.4 全速运行，实际训练步数达到 v1.2 的 2-3 倍（2.6-2.9 epoch vs 1.4）。对比本身就不公平，而长训练的那几个版本恰好是差的。

额外 epoch 主要放大了模型先验——多出来的误改集中在姓名旁边的介词替换上（如”booked table 27 at Kyiv”改成”in Kyiv”）。合成噪声和真实 GEC 数据中都包含介词修正样本，训练越久模型越容易过度触发。更隐蔽的是，checkpoint 选择用的是合成验证集上的编辑 F0.5，这个指标一直在涨（0.9655 → 0.9739），但真实正确文本上的误改率也在同步上涨。

团队最终的修复方案是受控重跑：固定 step 数、每次只改一个变量、训练 2-3 个种子衡量方差。结果显示新数据本身没有问题——回归纯粹来自多余的 epoch。v1.5 在 30,000 步配置下达到 F0.5 0.799、真实消息误改率 1.9% 的最佳平衡。

端侧部署：26MB Core ML，4ms 一句话

iOS 端导出为 Core ML 8-bit 权重，模型体积 26MB，与 fp32 的标签一致率 99.96%。为了适配 Neural Engine，团队使用了加法浮点注意力掩码、显式注意力和 cumsum 位置编码，输入按 16/32/64/96/160 token 分桶填充。键盘中实际使用 CPU 计算单元，就地读取 fp16 输出缓冲区并尊重 strides，release 构建下约 4ms 一句。团队特别提到早期”模型很慢”的报告其实是 Debug 构建加上 24ms 的 MLShapedArray 转换开销。Android 端使用 ONNX opset 17 加 int8 动态量化，27MB，与 fp32 一致率 99.1%，CPU 上同样约 4ms 一句。Swift 和 Python 的等价性测试跑在共享 fixtures 上，确保手机端和训练代码产生完全相同的标签。

Core ML 是苹果公司推出的机器学习框架，允许开发者将训练好的模型部署到 iOS、macOS 等设备上，并利用 CPU、GPU 和 Neural Engine（神经引擎）进行硬件加速。8-bit 权重是指将模型参数从 32 位浮点数量化到 8 位整数，可以大幅减小模型体积和内存占用，同时保持较高的推理精度。Neural Engine 是苹果芯片中专为神经网络计算设计的加速器，但需要模型满足特定的算子约束，因此团队使用了加法浮点注意力掩码等技巧来适配。

行业启示

这项工作对端侧 AI 部署有几点通用价值。对于**纠错（而非改写）**类任务，小型序列标注器在精确率、体积和速度上都优于小型生成式 LLM。误改率必须单独测量，F 分数会掩盖用户最敏感的失败模式。训练时务必固定步数而非时间预算，否则不同运行之间悄然失去可比性。最后，几行推理时防护代码的价值可能超过再来一轮训练。

模型权重已在 Hugging Face 上以 Apache-2.0 协议开源，包含 tokenizer、标签、Core ML 和 ONNX 导出及完整指标。