Program-as-Weights:0.6B 小模型如何匹配 32B 大模型
编译时推理参数高效本地部署2026-07-06 · cs.LG / cs.CL
为什么重要。PAW 把 LLM 从"每次调用都要推理的求解器"重新定义为"按需编译 LoRA 适配器的工具制造机"——一旦某类任务被自然语言规范"编译"成几十 MB 的适配器,本地 0.6B 模型就能复现 32B 模型效果,内存缩减约 50×、MacBook M3 跑 30 tok/s。这意味着大量对延迟/成本/隐私敏感的"模糊函数"场景(日志告警、JSON 修复、意图排序)第一次有了"编译产物"形态的离线方案,开发者不再需要为每个小工具调一次云端 API。
核心论文解读
作者:Yuntian Deng(领衔,含完整的 PAW 团队)· 分类:cs.LG / cs.CL · 代码:随论文同步开源 FuzzyBench(10M 示例)
关键技术点
- 范式重定义:模糊函数(fuzzy function)指难以用确定性规则实现、又不必动用通用 LLM 的任务。PAW 把这类任务"编译"成"参数高效适配器 + 冻结的小解释器"。
- 三件套架构:4B 编译器(把自然语言规格书变成 LoRA 适配器)+ 0.6B Qwen3 冻结解释器 + FuzzyBench 训练集(10M 合成样本,覆盖日志告警/JSON 修复/排序等任务族)。
- 调用经济性:编译器每条函数调用一次,解释器每次应用调用——大部分推理走本地 0.6B,只有"编译"那一跳需要 4B 模型。
- 性能对标:0.6B Qwen3 + PAW 适配器 ≈ 直接 prompt Qwen3-32B;内存约 1/50;MacBook M3 端到端 30 tokens/s。
局限性
- 编译开销未量化:论文给出 inference 侧的 50×,但 4B 编译器一次编译的端到端耗时/成本没单独报告。对一次性任务未必比直接调 32B API 划算。
- 任务边界模糊:FuzzyBench 覆盖"模糊函数"但缺乏清晰判据——什么任务值得编译、什么任务仍应走通用 LLM,工程化指南缺失。
- 泛化到非 Qwen 系列未验证:解释器选择冻结的 Qwen3-0.6B;换成 Llama / Gemma / 国产 0.6B 是否同样适配,无对照实验。
- 10M 数据合成方法:合成管线本身的细节(覆盖度、去污染、避免 shortcut)交代较薄。
PAW 的真正信号不是"0.6B 干翻 32B",而是把模型调用从 I/O 接口 升级为 构建产物——一次编译、反复调用、纯本地。这与之前 LoRA 微调完全不同:LoRA 是再训练,PAW 是再生成,生成物是一个可分发、可版本化、可缓存的 LoRA 文件。
相关工作
方向:神经符号混合 · 作者:Timo Bert 等
SE-RRM(symbol-equivariant recurrent reasoning model)作为神经求解器给 SAT/Sudoku 求解器提供分支引导,在 9×9 Sudoku 上把 backtracking 加速 33.3×,Glucose 4.1 加速 1.70×。与 PAW 同属"小模型 + 外部引擎"路线,但 PAW 用小模型执行模糊函数,G-RRM 用小模型引导精确求解器。两者都验证了"用合适的工程组合替代堆参数"。
方向:LRM + 多模态工具 · 作者:Zhilin Wang / Lingxi Xie 等 · 接收:ICML 2026
DramaSR-LRM 让大推理模型自主聚合声纹/语言/视觉线索,完成 532K 对白行、900+ 角色的归属任务。代表"重推理 + 工具调用"路径——和 PAW 的"轻推理 + 编译产物"形成对比。两者一起读可以看到当前 LLM 应用的两极分化趋势。
方向:参数级 unlearning · 作者:Matteo Boglioni 等 · 基准:OLMo-1B / OLMo-7B
在 OLMo 系列上注入合成 PII 到预定义参数,用 gradient ascent 等方法 unlearning,发现现有 SOTA 在参数级精度严重不足、易被 resurfacing 攻击重新挖出。LACUNA 进一步揭示:只要 localization 做对,简单的梯度方法就能做到强擦除。这与 PAW 的"参数即程序"思路互为印证——既然参数可以被精准定位/编辑,把它当作可编译产物就是自然延伸。
技术坐标
| 方案 | 模型规模 | 运行时位置 | 适用任务 | 关键约束 |
| 直接 Prompt 32B | 32B | 云端 API | 通用开放任务 | 延迟、成本、隐私 |
| DramaSR-LRM | LRM(未明示) | 云端 + 工具调用 | 多模态归属/推理 | 需要强推理链 |
| G-RRM | SE-RRM(小) | 本地 + SAT solver | 约束满足/逻辑题 | 需要 symbolic 后端 |
| PAW | 0.6B + LoRA 适配器 | 纯本地 | 模糊函数(日志/JSON/排序) | 任务需可被"规范"化 |
我的判断
PAW 不会替代通用 LLM,但会切走一大块"准 LLM 任务"。当一个任务能写成"输入 X,输出 Y,允许近似正确",且每天会被调用上千次,云端 32B 的成本/隐私/延迟就会反噬——这正是 PAW 的甜蜜区。判断落地节奏取决于三件事:① 编译器本身的开源质量和工具链成熟度;② FuzzyBench 覆盖的任务族多广;③ 是否有大厂(尤其端侧芯片厂)把它原生集成进端 SDK。
需要冷静看的三点。①"0.6B ≈ 32B"是在 FuzzyBench 这类特定任务上的等效,不是通用能力等价——别误读为"小模型全面碾压"。② 编译器 4B 的成本没透明披露,如果每次"编译"实际跑出 30 秒+,落地体验未必优于直接调 API。③ LoRA 适配器作为分发产物的版权/供应链治理是空白——分发方是否能看到原始规格书、是否能复现,工业场景会有合规风险。
对 JC 的可操作启示:
- picturebook-kg 的数据清洗里有大量"近似正确即可"的子任务(JSON 修复、字段归一、关键词分类)——理论上可用 PAW 风格编译成端侧 LoRA,跑在 M-series Mac 上替代云端 LLM 调用,降本可观。
- 如果 PAW 仓库按论文承诺开源,值得花一个 spike 跑通"FuzzyBench → LoRA → 0.6B 推理"全链路,验证在自家数据上的真实匹配度。
- G-RRM 的"神经引导 + 符号求解"思路对绘本知识图谱的 schema 校验/冲突检测可能有借鉴——符号侧规则明确,神经侧引导排序,正好契合。
参考资料