Nanbeige4.2-3B on Apple Silicon: Fixing Deployment Bugs and Decreasing Looped Transformer Memory Overhead
John T. Halloran
cs.AI, cs.LG
2026-08-14
3B 参数的 Looped Transformer 模型 Nanbeige4.2-3B 在苹果芯片上开箱即跑不了:五个部署缺陷、双倍注意力显存、系统提示词静默丢失与 MPS 显存泄漏逐个修完,MCPMark 从 0% 修到 30%。
Nanbeige4.2-3B 是一个主打 agent 能力的 3B 小模型,卖点是用 Looped Transformer(LT,把同一摞层跑两遍换取有效深度)在不加参数的前提下提升能力,模型卡声称在 agent 与办公流基准上打过 Qwen3.5-4B 和 9B。有人拿它做 ReAct 式 agent 实测,在苹果芯片(transformers 的 MPS 后端)上直接跑不起来。这篇论文就是一份完整的修复与评估实录:五个部署缺陷、一个架构级显存问题、一个系统提示词静默丢失、一个 MPS 特有的显存泄漏,全部定位到行号并给出补丁。
五个开箱缺陷,全部在未改动检查点上复现确认:
修完五个,agent 任务还是跑不动,根子在架构:LT 把隐状态过完 L 层后再送回同 L 层跑第二遍,预填充阶段同一提示要算两次 O(len²) 注意力,峰值激活显存直接翻倍。H200 这类大显存卡无所谓,但苹果统一内存要跟系统和其他进程挤 32 GiB,又没有 CUDA 式换页出路,长推理轨迹直接爆。
对策是分块预填充(chunked prefill):把一次性算完整提示,改成每 256 个 token 一块、块间增量增长 KV 缓存,再交给 generate()。单步注意力矩阵上界变成 chunksize 乘累计长度,与提示总长解耦,且验证过输出与朴素预填充逐位一致。代价是吞吐:提示长 2048 时比朴素慢 40.9%,换四倍批并行。
后续又拔出两个缺陷。系统提示词回归:chat template 里只要调用方给了任何 system 消息,模型自带的训练期工具调用系统提示词就被静默整个替换而非合并;即便原样显式传回去也不行,因为自动注入分支与显式分支的输出恰好差两个空白字符,而这个检查点的工具调用可靠性就校准在那串精确字节序列上。修复是删掉模板的 system 分支,把调用方内容插在自动注入的默认提示词之后。另外 llama.cpp PR #26324 独立报过同模型 25% 的调用输出尾随空格而非换行,佐证其工具调用对模板空白敏感。
MPS 显存泄漏:跑评测时发现一次被捕获的 MPS 后端 OOM 会永久拉低整个常驻进程的可用显存预算,emptycache() 和 gc 都收不回,只有重启进程。不修的话,一个任务的超限会级联成后续所有无关任务的假 OOM,解法是每个任务前重启服务。
LongBench-Pro 50 条长样本、M2 Max 32 GiB、8 个提示长度(3 次重复):
| 提示长度 | 朴素预填充最大批次 | 分块预填充最大批次 |
| 1024 | 16 | 32 |
| 2048 | 4 | 16 |
| 4096 | 2 | 4 |
| 8192 | 连批次 1 都跑不完 | 1 |
| 11231 | 连批次 1 都跑不完 | 1 |
| 12244 | 连批次 1 都跑不完 | 连批次 1 都跑不完 |
可用上下文从 4096 拉到 11231,2.7 倍。
修复后模型的可复现评测结果:MCPMark 文件系统子集 10 个简单任务过 3 个(30%),其中 6 个败于工具响应把显存吃爆、1 个败于超时(模型正确调用一次工具后把同一路径重复了 21 遍)。BFCL 150 题:该不调用时 100% 不调用,单次调用 63.3%,多工具并行是重灾区,parallel 类 30 题只对 1 题,主要失败模式是要求两次调用只发一次,属于格式层缺陷,换再大的显存也救不了。原始检查点因第二个缺陷在任何设备上都无评测。
对在 Mac 上跑本地模型的人,这篇是一份可以直接抄的作业:补丁检查点、系统提示词优化器和评测脚本都放了 Hugging Face 与 GitHub。对模型发布方,它是关于可复现性的一封公开信:模型卡基准好看,checkpoint 却因为 RoPE 缓冲区清零这种静默缺陷在任何设备上给出位置混乱的输出,评测数字根本无从谈起。LT 用参数效率换双倍峰值注意力显存这笔账,也第一次有了统一内存设备上的量化:同参数量下上下文宽度砍半,分块预填充能赎回 2.7 倍,代价是四成上下的吞吐。系统提示词那一段对所有做工具调用适配的人都有警示意义:校准依赖精确字节序列,差两个空白字符多工具调用就散架。
评测面很窄:MCPMark 只跑了文件系统子集的 10 个简单任务,BFCL 只跑了非实时单轮五类各 30 题,都不足以支撑「打过 Qwen3.5」这类模型卡结论的复核。全部实验在单一设备(M2 Max 32 GiB)与单一 transformers 版本(5.8.1)上完成,CUDA 侧行为未验证。MPS 显存泄漏的根因在 PyTorch 还是苹果驱动,论文没有深挖,只给了进程重启的绕法。作者单人署名,补丁以 monkeypatch 方式旁挂而非改动上游,检查点修复何时合入官方仓库没有时间表。