微型语言模型赋能瞬时响应 Micro Language Models Enable Instant Responses
用 8M–30M 参数设备端模型生成前 4–8 词掩盖云端延迟
前置知识
推测解码 (Speculative Decoding)
用一个小模型先草拟多个 token，再让大模型一次性验证这些 token 是否一致。如果一致则接受，否则丢弃重生成。目的是减少大模型自回归解码的串行步数，但首个 token 仍要等大模型确认后才显示。
本文反复对比这种 draft-and-verify 范式，强调 µLM 不验证、立刻提交显示，这是与本文核心思路最相关的对照范式。
因果语言模型 / Decoder-only Transformer
只使用 Transformer 解码器堆叠的自回归语言模型。每一层用 RMSNorm 归一化、RoPE 旋转位置编码、SwiGLU FFN 与分组查询注意力 (GQA)。输入嵌入与输出语言模型头共享权重以节省参数。
µLM 全系列都是这种架构，理解它的组件 (GQA、权重共享) 才能理解为何 8M–30M 模型仍能跑得动。
首 token 时间 (TTFT) 与流式生成
TTFT 是用户发出请求到屏幕出现第一个 token 的延迟。流式生成让用户边读边等，首个 token 出现即代表「系统在工作」，显著降低主观等待感。
本文主旨就是把 TTFT 压到极致：本地 45 ms 出现第一个 token，而云端同等任务要 0.2–5 秒以上。
LM-as-a-judge 评估范式
用一个强 LLM (如 GPT-4o) 按预设 rubric 给生成文本打分。本文中各项得分都与人类评分有较高 Pearson 相关性 (0.719–0.803)，可作为自动评估代理。
µLM 只输出 4–8 词而非完整回答，传统 NLG 评估会因答案截断而严重失真，论文因此引入专门 rubric 与 LLM 评判。
BPE 分词器 (Byte-Pair Encoding)
通过迭代合并语料中最频繁的相邻字符对，把文本切成子词单元。词表大小直接决定嵌入矩阵体积：词表越大，词嵌入张量占用内存越多。
µLM 训练了一个 12,288 词表的 BPE，正是为了把嵌入参数控制在几 MB 级，适配嵌入式设备。
研究动机
智能手表、智能眼镜、入门级智能手机等边缘设备的单应用内存只有几十 MB，散热包络也无法支持持续推理——这意味着即便是当前最小的 100M–1B 参数模型 (Llama-3.2-1B、SmolLM2-135M) 也无法在这种设备上「始终在线」运行。但把这些任务卸载到云端又会引入多秒级延迟：网络往返 50–500 ms、服务器排队 100–4000 ms、prefill 又要 50–500 ms，远超人类对话的「亚秒级响应」门槛 (Veluri et al., 2024)。结果是「设备上的 AI 助手」要么不存在，要么慢得让用户失去耐心，而恰恰在穿戴设备上，这种随时可用的贴身助手最有价值。已有思路 (Speculative Decoding、Model Routing) 都没解决第一个 token 不依赖网络的问题：前者要等大模型验证才显示，后者路由到云端后同样受限于网络延迟。
本文的目标是本文要构造一个 8M–30M 参数级别的「微型语言模型」(µLM)，把它直接跑在嵌入式硬件上；本地模型生成前 4–8 个语义上有意义、与上下文对齐的词并立刻显示，云端模型同时收到这段前缀作为上下文并续写完整回复，从而把首次可读输出时间压到接近零，让用户感觉不到云端往返。本文同时想让 µLM 在 LM-as-a-judge 评估中与 70M–256M 参数基线 (LaMini-GPT-124M、SmolLM2-135M-Instruct 等) 表现相当，并在嵌入式平台 (Orange Pi 5) 上达到 45 ms 的首 token 时间。
与已有工作不同的是，过去的小模型工作要么是孤立研究 100M+ 模型本身的对话能力，要么把模型 cascading/routing 当作「问题路由」而非「延迟掩盖」。MiniMind 这样的项目虽然参数规模相近，但只评估中文任务且定位为教学工具，不解决「在端侧协作成型响应」这一具体工程问题。本文的关键切角是把 micro-scale 模型重新定位为「协作者」而非「端点」：它不需要完整生成回复，而只需要为一个更强模型打头阵——这一思路抓住了「第一段文字就能恢复用户主观等待感」(Kim et al., 2025a) 这条人因学结论，把延迟问题从「让云端更快」转成「用本地掩盖云端」，从而跳出了传统的端云取舍框架。
核心方法
整体思路可以类比为「两个人对话，你脑子慢但嘴快」：本地的 µLM 像「嘴快」的模块，它可能只有一点点智能，但能立刻先把对话的前 4–8 个词说出口；同时云端的大模型并行听到这段话，再接着写完整回复。技术上分为两条线：(1) 训练五个 8.79M–29.50M 参数的 Decoder-only Transformer 变体 (隐藏维 256/384/512、层数 8/16)，用 1.485B token 的聊天语料先做预训练，再用 323.4M token 做 SFT，训练时保持总 FLOPs 在各变体间近似一致以便公平比较；(2) 设计 commit-and-continue 协作生成框架：用提示词把云端模型强行改造成「续写者」，先完成本地句子，再补内容；并预设三种错误恢复机制 (显式纠正、自然纠错、幽默纠错) 给云端使用。整个系统最终在 Orange Pi 5 嵌入式硬件上实测，得到 45 ms 的 TTFT 和 4.3× 的端到端吞吐提升。
核心创新是和「推测解码」彻底分道扬镳：推测解码等大模型验证后才提交 token，首 token 时间仍然受网络限制；本文反而把「不可撤回、立刻显示」当成设计目标——µLM 的前几个 token 一旦上屏就锁死，云端必须接续它们。这样做反而带来三个新研究问题：(a) 这么小的模型还做不做得成「语境对齐的开头」？(b) 云端能否在不引用、不否定、不重启的前提下接着写？(c) 错了怎么救？本文依次给出可量化的回答：14–29M µLM 在五个 lm-eval-harness 基准 (HellaSwag/PIQA/BoolQ/ARC-Ch./OBQA) 上能与 70M–256M 基线打成均势；7 个本地+云端组合中 4 个词前缀恢复率仅 3.7%；4–8 词构成最优前缀长度；用户对 µLM+LLM 与独立云端 LLM 的并列偏好率为 77.3%，显著超过 50% 基线 (p<0.001)。
方法步骤详情
流水线四段。(1) 架构: Decoder-only Transformer + pre-norm + RoPE ($\theta=10^6$) + RMSNorm + SwiGLU + GQA, 嵌入与 head 共享; 隐藏维 256/384/512、层数 8/16 五组合, 中间维度按 $3d$ 取整到 64。(2) 训练: UltraChat、MOSS、Instruction_merge_set 三个对话集清洗去重后 1.485B token, BPE 词表 12,288 重训; SFT 用 Magpie 指令集 323.4M token, FLOPs 对齐通过 optimizer 步数与参数量成反比。(3) 协作: 本地 4–8 词立即 commit; 云端通过 §M.1 改造为「续写者」, 不重复不否定, 先补完整句再答实质; 错误时按 §M.2 选三种纠错模式。(4) 评估: lm-eval-harness 定量, LM-as-a-judge 在 5 个 rubric + 4 个 handoff 维度打分, TTFT 与吞吐在 Orange Pi 5 实测。
技术新颖性
技术新颖性体现在三个层面：(1) 视角新颖——以「端云协同响应」而非「单端生成」为优化目标，重新定义了小模型评测维度 (Local Helpfulness、Sem. Coherence、Style Consistency)，并明确告诉 LLM 评判不要因为短而扣分；(2) 交互范式新颖——推出「commit-and-continue」与 speculative decoding 的对照，并通过三种可切换的错误恢复模式把「错误处理」从被动现象变成可设计对象；(3) 工程新颖性——在 FLOPs 对齐的训练设置下系统扫描 8M–30M 区间的深度-宽度权衡，发现 28.85M (512×8) 比更深的 29.50M (384×16) 略好，符合小模型 shape 研究的近期观察 (Sharma, 2025)。
实验结果
结果分四块。基准 (Table 4): µLM-512-8 (28.85M) 五基准综合 0.390, 与 pythia-160m 0.389、LaMini-GPT-124M 0.393 持平, SmolLM2-135M 0.429 领先。变体内部: 8.79M 仅 0.345, 28.85M 0.390, 8M–30M 区间未崩塌。协作 (Table 1): µLM-28M + Qwen2.5-72B 用 4 词达 4.67 最高分, 强于独立 Qwen3-0.6B (4.59) 与独立 µLM-28M (3.72)。Table 5: 4/8/16 词纠错触发率 3.7%/8.4%/16.4%。用户研究 (Fig. 5): 49.3% 持平、28.0% 偏好协作, 合计 77.3% (p<0.001)。错误恢复 (Fig. 6): 自然 44.0%、幽默 36.7%、显式 19.3%。硬件: 28M µLM TTFT 45 ms、出 4 词 55 ms; 端到端吞吐 142 vs 34 tokens/s (4.3×), 能耗 31 vs 141 mJ/token (4.5× 下降)。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| lm-eval-harness 综合 (HellaSwag/PIQA/BoolQ/ARC-Ch./OBQA) | 五个 acc_norm (BoolQ 用 acc) 的平均分 | 0.390 (µLM-512-8, 28.85M) | LaMini-GPT-124M 0.393 / LaMini-Neo-125M 0.406 / SmolLM2-135M-Instruct 0.429 | 以 1/4–1/9 参数量匹配 70M–256M 对照基线，差距仅 0.003–0.039 |
| 协作生成 (µLM-28M + Qwen2.5-72B, 4 词前缀) | Fluency/Sem. Coh./Redundancy/Style Cons. 平均 (1–5 LLM 评判) | 4.67 | 独立 Qwen3-0.6B 4.59；独立 µLM-28M 3.72 | 比独立 Qwen3-0.6B +0.08，比独立 µLM-28M +0.95 |
| Handoff Correction Rate (Qwen3-235B-A22B 续写 8 词前缀) | 云端必须显式纠错的占比 | 8.4% | 4 词 3.7%；16 词 16.4% | 8 词比 16 词少触发 8.0 个百分点纠错 |
| 用户对协作 vs. 独立 LLM 的并列偏好率 | (持平 + 偏好协作) 比例 | 77.3% (49.3% tie + 28.0% prefer collaborative) | 50% 随机基线 (精确二项检验 p<0.001) | +27.3 个百分点，显著优于随机 |
| Orange Pi 5 端到端吞吐 | tokens/s 端到端 (含 prefill+decode) | 142 tokens/s (µLM-28M) | 34 tokens/s (SmolLM2-135M-Instruct) | 4.3× 提升 |
| Orange Pi 5 单位 token 能耗 | mJ/token | 31 | 141 (SmolLM2-135M-Instruct) | 能耗下降 4.5× |
局限与改进
作者列出: (1) 长 prompt 鲁棒性未充分验证——§G 把样本按 token 分四箱, 平均分 4.58/4.52/4.69/4.64, 无显著下降; (2) 训练语料以日常对话为主, 缺数学/编程等垂直领域, 长技术问题可能暴露错误, 建议超阈值 fallback; (3) 当前只做单轮响应开启, 长上下文多轮管理交给云端; (4) 设备验证只用 Orange Pi 5, 未在量产穿戴 SoC 上验证; (5) UI 需按 ~4 词/秒节奏显示才能掩盖延迟。独立观察: 用户研究仅 15 人、机构内招募, 可能带 tech-savvy 偏差; LM-as-a-judge 中 Informativeness 这条对小模型天然不利, 真实差距可能更小; 安全实验中 31/80 由 µLM 独立拒答、剩余 49 个云端挽救 33 个, 但未给最终安全比例细节; Table 1 中 Qwen3-235B-A22B 在多组合里反不如 Qwen2.5-72B, 续写能力不只看规模, 但论文 §G 仅一句话提及。
独立分析的弱点
独立分析三个弱点。弱点一: rubric 偏置可能掩盖真实差距——论文明确要求 LLM 评判「不要因为短而扣分」, 等于为小模型换了一套标尺, µLM 只输出 4 词而云端是整段回复, 严格来说语义不可比。改进方向是把所有回复截断到相同长度, 或把 µLM 的 4 词与同样长度的云端 token 同等比较。弱点二: 用户研究只对比了 µLM+LLM 与独立 LLM, 缺少「µLM-only」对照组, 无法拆解「本地有响应」这一安慰剂效应贡献了多少偏好。改进方向是补一组「本地 µLM 答 8 个词后沉默等待」, 用事后问卷区分「响应可见性」与「内容质量」两个独立维度。弱点三: 三种错误恢复模式各自适合不同场景, 但论文没给自动选择策略。改进方向是训练 5M 左右的轻量分类器, 给 µLM 输出打分并预测哪种纠错模式最契合当前对话 (query 领域、紧急度、用户偏好), 把自恢复策略路由化。
未来方向
论文已经给出了几条未来方向：在更长 prompt 与多轮上下文管理上做端到端验证；用 Whisper-tiny 这类 ~39M 模型把框架延伸到语音接口；面向真实穿戴 SoC 而非开发板做实测。基于成果可延伸的方向还包括：(1) 把 µLM 训练成「情境模式探针」——通过它对 query 的开头判断任务类型 (闲聊/工具调用/敏感话题)，让云端在收到 prefix 时就能预先分流到合适的 system prompt；(2) 用蒸馏或迁移学习把 µLM 蒸馏成 1M–5M 极端小尺寸，专门面向手表级别 SoC；(3) 多模态扩展——把 µLM 拓展为「音频-视觉前缀器」，在 AR 眼镜场景下用前置摄像头和 mic 增量生成会话前缀，进一步压缩用户感知延迟；(4) 错误恢复模式与上下文敏感度结合，让幽默纠错只能在用户情绪未低落时启用，避免在悲伤消息下用幽默引起反感。
复现评估
复现友好度中等偏上。论文承诺开源 checkpoint 与 demo (GitHub Sensente/micro_language_model_swen_project)。§A 列出完整架构 (RMSNorm、RoPE $\theta=10^6$、GQA、SwiGLU、embedding-output tied) 与超参 (AdamW $\beta_1=0.9$, $\beta_2=0.95$, 权重衰减 0.1, 梯度 clip 1.0, peak LR $5\times10^{-4}$, batch 64, 最大序列长 1024, bf16); 数据预处理全过程在 §A-B。算力: 预训练 1.485B token, FLOPs 对齐以 28.85M×3 epoch 为参考; 按 Kaplan 估算需几十到上百 GPU·天 (未列具体数字), 单卡 A100 跑一轮约一周, SFT 更轻。LM-as-a-judge 用 GPT-4o, 成本显著, 可用开源 judge 替代。Orange Pi 5 整机几百元即能搭建。
论文图表
概念图，展示用户通过智能设备发问 (例如「How can I stay focused while studying?」)，本地 µLM 立即输出「Start by minimizing distractions and create a study schedule...」并显示在屏幕上；同一时间云端 LLM 已经收到这段前缀作为上下文，正在生成完整回答，整个等待过程被本地响应掩盖。
这是论文的「灵魂图」，直接把 commit-and-continue 的工程范式画给读者——没有这张图，读者很难想象 4–8 词前缀是怎样掩盖云端延迟的，也很难体会与推测解码的根本差异。
(a) 一个 3×5 表格列出 8.79M / 14.43M / 17.11M / 28.85M / 29.50M 五个 µLM 变体的隐藏维和层数；(b) 柱状图对比 µLM 与 Pythia-70M/160M、LaMini-GPT-124M、Neo-125M、Cerebras-256M、SmolLM2-135M-Instruct 的 lm-eval-harness 总分；(c) 在 WikiHow/Vicuna/AdvisorQA 三个对话集上，µLM 的定性总分随参数量近似单调上升。
论文声称「微型模型在 8M–30M 区间仍能用」的核心证据。这张图把变体构造、定量缩放、定性缩放一次性全部展示出来，决定了「值得做这件事」的判断。
堆叠条形图：自然纠错 rank1=44.0% / rank2=34.7% / rank3=21.3%；幽默纠错 rank1=36.7% / rank2=40.7% / rank3=22.7%；显式纠错 rank1=19.3% / rank2=24.7% / rank3=56.0%。揭示用户明显倾向「自然恢复」而反对「显式打断」。
为「错误恢复应被当作显式设计维度」这一论点提供用户层证据，决定了部署时应该默认选哪种模式。