把一个 3.67 GB 的模型文件塞进本地电脑，不加一个参数，也不重新训练，只靠让中间层原地多转几圈，就能在写代码时打赢两倍体量的 9B 模型。2026 年 11 月 7 日，MarkTechPost 放出了一篇用 llama.cpp 本地运行 NVIDIA Nemotron Labs 推理小模型 Dory 1.0 4B 的实测指南。这不仅是一份跑分教程，它真正揭开的是端侧小模型算力账本的改写，以及循环架构落地时撞上的底层工程暗礁。
一个 3.67 GB 文件里的四档变速箱
Dory 1.0 4B 发布于 2026 年 10 月 16 日，总参数量 3.98B，支持最高 256K 上下文，官方提供了 BF16（约 7.95 GB）、NVFP4、MXFP8 以及 Q5_K_M GGUF（精确大小为 3,673,288,864 字节）等格式。它的物理结构很特殊，由 8 个输入层、1 个共享的 20 层循环块和 8 个输出层组成（在 GGUF 中对应 16、40、16 共 72 个交替的注意力与 MLP 条目，每 3 个滑动窗口注意力层配 1 个全注意力层），其中共享循环块占了 1.84B 参数。
每个 token 经过中间这 20 层时，可以执行 1、2、3 或 4 次循环。官方推荐把 2 次循环作为默认起点，但 GGUF 文件头里内置的默认循环次数却是 4，启动服务时如果不手动覆盖参数，就会在不知不觉中跑满最贵的档位。4 次循环施加的每 token 参数量是 1 次循环的 2.51 倍，权重读取字节数是 2.28 倍。
为了控制显存，Dory 提供了两种循环 KV 缓存模式：per_loop 为每次循环分配独立缓存，在 4096 上下文下从 1 次循环的 306 MiB 涨到 4 次循环的 816 MiB（若拉满 256K 上下文，2 次和 4 次循环分别要吃掉约 19 GiB 和 32 GiB）；last_loop 则只保留最后一次循环的缓存，不管转几圈都死死锁在 306 MiB。
越慢反而越省：被内部循环砍掉一半的废话
直觉上，每个 token 多算几遍，生成速度肯定大跌。社区基于 MLX 在 MacBook Pro M5 Max（128 GB）上的 8-bit 实测也印证了这一点：短提示词下，1、2、4 次循环的解码速度分别为 101、69、39 tokens/s；32K 提示词后解码速度降为 82、54、31 tokens/s，32K 预填充耗时则分别为 10 秒、17 秒和 31 秒。
我更在意的是另一本账：单 token 变慢了，为什么跑完一个复杂任务的总算力成本反而没怎么涨？
传统模型做测试时计算（Test-time compute），靠的是不断吐出更长的思维链 token，废话多、试错多，上下文越滚越长。Dory 把思考塞进了隐空间循环里——单步想得更深，直接减少了外部的错误尝试和交互轮次。在 GDPval-AA v2 基准上，1、2、4 次循环的平均每次尝试总输出 token 从 212K 暴降至 140K 再降至 85K；Terminal-Bench 2.1 从 109K 降至 78K 和 54K；SWE-bench Verified 从 33.6K 降至 26.4K 和 24.8K。
隐空间里多转两圈，抵得上显式输出里的十万句废话。
折算下来，在 4 项 Agent 任务中，2 次循环的总生成算力成本仅相当于 1 次循环的 1.03 至 1.25 倍，4 次循环也只有 1.07 至 2.04 倍。用最高两成五的算力代价，就能换来核心能力的大幅跃升。
越级打怪的边界与推理引擎的暗礁
循环机制在编程和指令遵循上确实能越级打怪，但它救不了底层知识密度的先天不足。对标阿里的 Qwen3.5 系列，Dory 的长板和短板同样分明：
| 评测基准 | Dory 1.0 4B (1 / 2 / 4 Loops) | Qwen3.5-4B | Qwen3.5-9B | 核心判断 |
|---|---|---|---|---|
| SWE-bench Verified | 50.3 / 59.5 / 61.8 | 54.7 | 61.0 | 2 次循环超 4B，4 次反超 9B |
| IFBench / SciCode | 4 Loops 达 79.00 / 35.11 | - | 59.00 / 28.21 | 指令遵循与科学编程大幅领先 |
| AA-LCR / GDPval Elo | 4 Loops 达 73 / 967 | - | 68.4 / 546 | 长程 Agent 任务优势明显 |
| GPQA Diamond (无工具) | 69.19 / 72.41 / 72.16 | 77.71 | 80.93 | 4 次循环分数倒退，不敌 4B |
| HLE (纯文本无工具) | 2 Loops 最高 10.89 | 11.31 | 15.43 | 硬核知识受限于 4B 物理容量 |
韩非子讲“巧妇难为无米之炊”。脑子转得再快，肚子里没存够货也是白搭。这也是为什么 MarkTechPost 教程拿 GSM8K 小学数学题来测 Dory 其实选错了靶子——NVIDIA 官方模型卡里压根没收录 GSM8K，这台发动机的真正主场是 SWE-bench 这类需要长程规划的 Coding Agent。目前无论是官方还是社区，都还缺少相同硬件、相同运行时下 Dory 与 Qwen3.5 完成端到端任务的真实挂钟耗时（wall-clock time）对比。
- 结论.Dory 极适合作为本地编程 Agent 底座，靠 2 至 4 次循环减少无效交互；但在依赖硬核知识储备的任务上，同尺寸传统模型依然更稳。
更深一层的麻烦在推理引擎里。截至 2026 年 11 月 7 日，llama.cpp 官方支持 Dory 的 PR #30306 仍处于草稿阶段，教程只能去拉取指定分支（brianchmielNV/llama.cpp，commit 98a74c97ea09ac72f6ceda1559808fc0a2f447ce）自行编译，甚至连教程里照抄模型卡命令的文件名 dory-q5_k_m.gguf 都会报错，必须改成仓库真实的 NVIDIA-Nemotron-Labs-Dory1.0-4B-Q5_K_M.gguf 并校验 SHA-256。
十九世纪铁路刚铺开时，不同公司的宽轨与窄轨无法互通，车头再先进也跑不快。今天的开源推理框架就建立在“1 个物理层 = 1 个执行步 = 1 份 KV 缓存”的旧轨距上，Dory 这种 36 个物理层展开成最高 96 个虚拟层的架构一进来，到处都在撞车。
在 PR #30306 的适配过程中，物理层与虚拟层的计数撕裂一度直接搞坏了部分卸载（partial offload）与自动显存适配，直到 commit 3834b4a 才修好；期间还曾因为 BF16 缩放张量放错了设备位置，引发严重的 CPU/GPU 传输瓶颈，在 RTX 5070 Ti 上修复后（commit 9e2f3be）解码吞吐量才从 25.67 飙升到 79.94 tokens/s，足足差出 3.11 倍。
更要命的是数值确定性。虽然 PR #30306 已完成 CPU 与 CUDA 各 96/96 项数值比对和 36/36 项服务冒烟测试，但 Metal 后端与完整长上下文验证还没走完——教程直接在 Mac 上开启 Metal 编译其实踩在了未验证区。同时，官方虽称 last_loop 精度接近 per_loop，但实测证实 last_loop 不仅会改变预测结果，还会让预填充的分块大小（prefill chunk size）直接左右模型的最终输出；甚至在 per_loop 模式下，11 月 2 日也有社区报告指出存在因循环数值放大导致的分块依赖性（chunk-dependent logits，尚待复现与审查）。
- 风险.在生产环境或本地评测中开启
last_loop省显存，或随意改动--ubatch-size分块参数，都会破坏循环模型输出的一致性。
把“拉长思维链”变成“加深隐空间循环”，确实帮端侧 4B 小模型找到了四两拨千斤的支点。但当一个 3.67 GB 的文件开始在内部折叠时间，先被逼着重写底层逻辑的，恰恰是 llama.cpp 这些习惯了线性世界的推理引擎。接下来最值得盯紧的，就是 PR #30306 何时能修平数值抖动并正式合入主线。