作者：Lei阅读 --

小模型的「小」在 2026 年裂成了两半：一台 24GB Mac 上的三笔账

把 2026 年的 SLM 趋势放到一台 24GB Mac 上验一遍：Qwen3.5-4B 默认配置下 20 件抽取活可用率 0/20，关掉思考后 20/20；35B-A3B 的 Q4 权重 20.50 GiB 装不进 17.76 GiB 的 GPU 工作集。参数量这个坐标失效了。

LLMAI Infrallama.cppLLM Serving工程实践

我给 2026 年 3 月发布的 Qwen3.5-4B 派了 20 件最简单的活：从一句中文里抠出 name / city / amount 三个字段，输出一个 JSON。默认配置下，20 条全部撞上 token 上限，14 条返回空内容，可用率 0/20。加一个参数关掉思考，同样 20 条：20/20 全对，墙钟从 161.7 秒降到 9.9 秒。

而 2024 年 9 月的 Qwen2.5-7B，三种配置下都是 20/20，开箱即用。

这两组数字是我今晚在自己这台 24GB M5 Pro 上跑出来的。它们指向同一件事：2026 年判断一个小模型能不能用，「多少 B 参数」这个坐标已经失效了。

趋势报告仍然按参数量排队——0.8B 能跑视频了、3B 追上了去年的 7B、30B-A3B 只激活 3B。这些说法本身没错，但它们全都不能预测上面那组 0/20。真正决定成败的三件事都不在参数量里：常驻多少字节、每 token 搬多少字节、默认是否思考。

这篇文章做三件事：把这三个坐标各用一笔亲手算/亲手跑的账立起来，把 2026 年主流小模型重新摆回这三个坐标上，最后说清这套框架什么时候不成立。

名词速查

术语一句话解释
SLM小语言模型。2026 年各家口径不一，微软划到约 14B 以下，一份 agent 研究用 10B 以下，本文按「能在单机/端侧全量常驻」理解
总参数 / 激活参数模型一共有多少权重 vs 生成一个 token 实际用到多少。MoE 让两者拉开差距，写作 35B-A3B（35B 总、3B 激活）
MoE（混合专家）把前馈层拆成许多「专家」，每个 token 只路由到少数几个。省的是计算和搬运，不省常驻
线性注意力 / Gated DeltaNet用固定大小的状态替代随长度增长的注意力矩阵，代价是精确回忆能力弱一些。Qwen3.5 按 3:1 混合线性层与全注意力层
Q4_K_Mllama.cpp 的一种 4bit 量化格式。我实测下来实际约 0.614 字节/参数（4.91 bit），不是理论上的 0.5
GGUFllama.cpp 的模型文件格式，把权重和 chat 模板等元数据打包在一起
工作集上限Metal 报给 llama.cpp 的 recommendedMaxWorkingSetSize，即 GPU 建议最多占用多少内存。这台机器上是 17.76 GiB，只有物理内存的 74%
思考模式模型先生成一段推理再给答案。2026 年的小模型基本都带这个开关，而开关的默认值不由你决定

这篇不重讲的三件事

动笔前我列了读者需要的前置知识，其中三项站内已有专文，这里只给一句话和链接，不再重复：

结论先行：三个有效坐标

坐标它决定什么缺了它会出现什么现象
常驻字节（总参数 × 位宽）能不能装进这台机器模型根本加载不起来，或者被挤到 CPU 上慢十倍——参数量小但装不下的模型，激活参数再少也没用
每 token 字节（激活参数 × 位宽）生成一个 token 有多快装得下但慢得没法交互，或者反过来：模型缩小了 9 倍，速度只快 4 倍，你以为的加速没兑现
默认是否思考这次调用是跑腿还是写作文一件三字段抽取花掉 512 个 token 然后返回空字符串，finish_reason 悄悄写着 length

三个坐标里，第三个最容易被漏掉，因为它不写在模型卡的参数表里，写在推理框架的默认值里。下面逐个立账。

第一笔账：常驻字节——20.50 GiB 装不进 17.76 GiB

2026 年小模型最显眼的架构变化，是 MoE 下沉到了「小模型」这一档。两个已核实的例子：

  • NVIDIA Nemotron 3 Nano 30B-A3B（arXiv:2512.20848，v1 提交于 2025-12-23）：混合 Mamba-Transformer 的 MoE，25 万亿 token 预训练，支持最长 1M 上下文，摘要称相比同尺寸开源模型（GPT-OSS-20B、Qwen3-30B-A3B-Thinking-2507）推理吞吐最高提升 3.3 倍。我只核到了摘要；「128 专家激活 6 个 + 2 个共享」这类细节来自技术报告与二手评述，未逐项核到原文。
  • Qwen3.5-35B-A3B（模型卡，引用块标注 2026 年 2 月）：35B 总参数、3B 激活，256 个专家中每 token 激活 8 个路由专家 + 1 个共享专家，40 层按 10 × (3 × GatedDeltaNet→MoE + 1 × GatedAttention→MoE) 排布，原生 262144 上下文，YaRN 外推到约 101 万。

「只激活 3B」听起来就是能塞进笔记本的意思。我去 Hugging Face API 查了它 GGUF 的真实文件体积：

Qwen3.5-35B-A3B-Q4_K_M.gguf      20.50 GiB
Qwen3.5-35B-A3B-Q8_0.gguf        34.37 GiB

而我这台机器上 llama.cpp 启动时报的工作集上限是 recommendedMaxWorkingSetSize = 19069.67 MB。这里有个单位坑：ggml 源码里打印这个值时除的是 1e6（见 ggml-metal-device.m:1337），所以它是 19.07 × 10⁹ 字节 = 17.76 GiB，占 24 GiB 物理内存的 74%。

于是这笔账很干脆：20.50 − 17.76 = 缺 2.74 GiB，而且这还没算 KV cache。 一个「只激活 3B」的模型，在一台 24GB 的机器上装不进 GPU。

再往下算一层，就能看清 MoE 到底买了什么、没买什么。按我实测的 0.614 字节/参数估算（均匀位宽的粗估，embedding 通常精度更高，所以这是下限）：

常驻字节每 token 搬运
把工作集塞满的 dense 模型（约 31B @Q4）17.76 GiB19.07 GB
35B-A3B20.50 GiB≈ 1.84 GB
Qwen3.5-0.8B @Q40.49 GiB0.52 GB

MoE 把每 token 搬运量压到了同等常驻内存 dense 模型的 1/10.3，却把常驻量顶高了。 它优化的是「算得少」，端侧的墙是「装得下」——这两件事在 2026 年被 MoE 彻底掰成了两个互不相干的维度。注意第三行：35B-A3B 每 token 搬的字节数，是 0.8B 的 3.5 倍，但它需要 42 倍的常驻内存。

于是那句根本约束可以写下来了：

2026 年的小模型之所以长成「总参数大、激活参数小」的样子，是因为服务端的稀缺资源是算力与带宽，而端侧的稀缺资源是常驻内存；MoE 只解决了前者。

这句话是可反驳的——如果常驻内存不要钱，那么 MoE 化就是纯赚，各家没有任何理由继续发布 0.8B / 3B 的 dense 模型，也没有理由为端侧单独设计架构。而现实恰恰相反。

崩点在哪： 把 MoE 换成「最朴素的做法」——直接上一个把工作集塞满的 dense 模型。它装得下（17.76 GiB），但每 token 要搬 19.07 GB，按这台机器实测的上限带宽 243.8 GB/s 算，decode 天花板约 12.8 tok/s。低于人的阅读速度，交互体验直接崩掉。反过来，把常驻压到 0.8B 那一档，你就得接受一个能力弱得多的模型。MoE 是在这两个崩点之间开的第三条路，但它只在你付得起 RAM 的地方成立。

谁真的绕过了这个约束： 苹果。第三代 Apple Foundation Models（官方研究页，2026-06-08 发布，9 月 9 日有更新）里的 AFM 3 Core Advanced 是端侧 20B 稀疏模型，每次请求只激活 1–4B。关键不在稀疏，在于官方明确写了：完整模型放在闪存（NAND）里而不是常驻 DRAM，路由按 prompt 决策而不是按 token 决策，常开的共享专家加上按需载入 DRAM 的路由专家。

这就是在直接拆解「常驻字节」这一项。而它的共同祖先很老——这是需求分页（demand paging）和工作集理论：把全量数据放慢速大容量介质，按访问局部性把工作集调进快速小容量介质。之所以能按 prompt 而不是按 token 路由，正是因为按 token 路由的局部性太差，页面换入换出的开销会吃掉全部收益。同一个约束、同一套解法，四十年前发生在磁盘与内存之间，今天发生在闪存与 DRAM 之间。

第二笔账：每 token 字节——缩小 9 倍，只快 4.4 倍

我用 llama-bench 在同一台机器、同样 -ngl 99 -p 512 -n 128 -r 3 的条件下量了三个模型（2024 年的 7B 对照 2026 年的 4B、0.8B，量化格式统一 Q4_K_M）：

模型权重体积参数量prefill (tok/s)decode (tok/s)每 token 搬运折算有效带宽
Qwen2.5-7B（2024-09）4.36 GiB7.62B1495.65 ± 7.0952.07 ± 0.454.68 GB243.8 GB/s
Qwen3.5-4B（2026-03）2.54 GiB4.21B1922.77 ± 31.9363.10 ± 0.502.73 GB172.1 GB/s
Qwen3.5-0.8B（2026-03）497.39 MiB752.39M8627.00 ± 63.85228.89 ± 0.620.52 GB119.4 GB/s

最后一列是我拿 decode × 权重体积 折算的。如果 decode 严格受内存带宽约束，这一列应该是个常数——它不是，从 243.8 一路掉到 119.4 GB/s。

这意味着：模型越小，带宽 roofline 越不成立。 0.8B 的权重只有 7B 的 1/9.0，decode 却只快 4.4 倍。缩小模型换速度这件事，在小尺寸端有明显的收益递减——每 token 的固定开销（kernel 启动、采样、框架调度）开始压倒权重搬运。

这条对选型很实际：如果你的目标是延迟，从 4B 降到 0.8B 大概率不值得。 我这台机器上 4B → 0.8B 的权重缩了 5.2 倍，decode 只快 3.6 倍，而能力差距是断崖式的。真正划算的那一跳是别的：0.8B 跑完全部 20 件抽取活只用 3.5 秒，7B 用了 14.0 秒——快 4.0 倍、小 9.0 倍、准确率同为 20/20。 这才是 2026 年密度进步兑现的地方，它兑现在「窄任务上用更小的模型」，不兑现在「同一个模型变快」。

第三笔账：默认是否思考——我在这里翻了车

这是今晚最出乎我意料的一段，过程也不光彩，照实写。

我原本打算用 llama-cli 批量跑探针，加了 -no-cnv 想要单轮模式。结果进程挂在交互提示符 > 上一动不动，180 秒超时被我杀掉。查了 --help 确认 -no-cnv 这个 flag 确实存在，但配合 -sys 时并没有生效。我没继续纠这个问题，改用 llama-server 走 HTTP 批量——这个绕路反而是撞见真问题的原因，因为 HTTP 响应把 content 和 reasoning_content 分开返回了，而命令行把两者混在一起打印，我根本不会注意到。

第一个探针跑完，0.8B 的结果是：裸 JSON 合规 0/20，但把 markdown 围栏抠掉之后字段正确率 18/20。我当时的判断是「小模型不听格式指令」，准备去加 grammar 约束。直到我把单次响应完整打印出来：

{
  "finish_reason": "length",
  "message": {
    "content": "",
    "reasoning_content": "好的，我需要处理用户的请求，他们希望只输出一个 JSON 对象，键固定为 name/city/amount……"
  },
  "usage": { "completion_tokens": 300 }
}

300 个 token 全部花在思考上，content 是空字符串。 一件三字段抽取，它在心里反复确认了「amount 应该对应金额」然后预算耗尽。这个失败形态我在《一次 finish_reason=length 翻车》里写过——静默失败，HTTP 200，字段齐全，内容为空。这次是同一个坑的另一张脸。

于是我把探针重写成三种条件对照：默认（不传任何 thinking 参数）、显式关思考、关思考再叠加 json_schema 约束。同样 20 件活、temperature 0、n_predict 512。全表：

模型条件裸 JSON 合规字段全对空内容撞上限token/条20 条墙钟
Qwen3.5-0.8B默认0/2019/2011257.624.6 s
Qwen3.5-0.8B关思考20/2020/200030.03.5 s
Qwen3.5-0.8B关思考+schema20/2020/200030.03.5 s
Qwen3.5-4B默认0/200/201420512.0161.7 s
Qwen3.5-4B关思考20/2020/200022.09.9 s
Qwen3.5-4B关思考+schema20/2020/200022.09.9 s
Qwen2.5-7B（2024）三种条件均同20/2020/200027.114.0 s

三条读得出来的结论：

一，思考在跑腿活上是纯税。 0.8B 开思考多花 8.6 倍 token、7.0 倍墙钟，准确率反而从 20/20 掉到 19/20。4B 更极端：23.3 倍 token、16.3 倍墙钟，换来可用率 0/20。

二，模型越大，这个税越重，方向和直觉相反。 4B 比 0.8B 思考得更长（512 vs 257.6 token/条，全部撞上限），于是在这件事上表现更差。我原以为 4B 会稳一些。

三，一个 flag 就能修好，而且修好之后 grammar 约束不再必要。 关思考后两个 2026 模型都是 20/20 裸 JSON，json_schema 一个字节都没改变（token 数完全相同）。格式不合规不是能力问题，是被思考轨迹撑破了输出信封。

那么这个「默认」是谁定的？我顺着查了一层，答案不在模型侧：

  • Qwen 官方模型卡明确写着 Qwen3.5-0.8B「operates in non-thinking mode by default」，需要显式传 enable_thinking: True 才开。卡里还专门警告这个 0.8B「更容易进入思考循环」。
  • GGUF 里的 chat 模板也是默认关的。 我直接解析了本地那个 GGUF 的 tokenizer.chat_template（7816 字符），分支写得很清楚：{%- if enable_thinking is defined and enable_thinking is true %}{{- '<think>\n' }}{%- else %}{{- '<think>\n\n</think>\n\n' }} ——未定义就走空思考块。
  • 是 llama-server 把它打开的。 -rea, --reasoning 默认值是 auto，帮助文本写的是「detect from template」；--reasoning-budget 默认 -1（不限）。而 llama.cpp 里那个探测函数 common/chat.cpp:358 的 common_chat_templates_support_enable_thinking() 是拿 inputs.enable_thinking = true 去套模板看它支不支持；随后 tools/server/server-common.cpp:1299 把这个值灌进请求，:1314 起才用请求里的 kwarg 去覆盖它。

也就是说，auto 的语义不是「跟随模板的默认值」，而是「模板支持就打开」。文档那句 detect from template 读起来像前者，实际是后者。我用 -rea off 复验了一次：同一个 prompt，34 个 token、finish_reason: stop、思考字段为空。

顺带一个坑：我探针里用的 chat_template_kwargs: {enable_thinking: false} 是已废弃的写法，common/arg.cpp:3526 会打 deprecation 警告（我跑的时候 stderr 重定向到了 /dev/null，所以没看见）。要关思考，正确的开关是 -rea off 或 --reasoning-budget 0。

把 2026 年的模型摆回这三个坐标

这是本文「全面」的那部分。我把今年被讨论最多的小模型按三个坐标列一遍，每行标注我核到哪一档——没有亲手跑过的行我不会写成实测。

模型常驻（Q4 量级）每 token（激活）默认思考证据档位
Qwen3.5-0.8B0.49 GiB（实测文件）0.52 GB（实测）卡说关，llama-server 打开我实测
Qwen3.5-4B2.54 GiB（实测文件）2.73 GB（实测）同上我实测
Qwen3.5-35B-A3B20.50 GiB（HF API 文件体积）≈1.84 GB（我按均匀位宽估）未测文件体积核实，吞吐未测
Nemotron 3 Nano 30B-A3B未测3B 激活支持 ON/OFF 与思考预算摘要核实，细节二手
Apple AFM 3 Core3B dense，端侧3B未公开官方页核实
Apple AFM 3 Core Advanced20B 总，放闪存不常驻 DRAM1–4B，按 prompt 路由未公开官方页核实
Gemma 3n E2B / E4B官方称约 2GB / 3GB 内存5B / 8B 原始参数，靠 MatFormer + 逐层嵌入压缩不带思考开关官方博客转述，我未复现
Phi-4-mini-reasoning 3.8B未测3.8B dense就是个推理模型arXiv:2504.21233 已核（2025-04-30）

摆完之后有几件事变清楚了：

「多模态下沉到 1B 以下」是真的，而且是结构性的。 Qwen3.5-0.8B 的模型卡写的是 causal LM 加视觉编码器，24 层、hidden 1024、原生 262144 上下文。一个 0.49 GiB 的文件里同时装着视觉编码器和 26 万 token 的上下文能力——这在 2024 年是不可想象的。

长上下文的标称值要按常驻字节重新读。 35B-A3B 标称原生 262144、外推 101 万，可它的权重就已经把这台机器的工作集撑爆了；1M 上下文的 KV cache 要另外找地方放。上下文窗口是一张需要内存兑付的支票，而兑付它的额度和权重共用同一个池子。

「思考模式」在 2026 年从功能变成了默认。 这一年发布的小模型几乎都是混合推理模型，而 agent 里绝大多数调用是跑腿活。NVIDIA 那篇立场论文（arXiv:2506.02153，v1 2025-06-02，v2 2025-09-15，我核到摘要）的核心论点正是：agent 系统里模型在反复做少数几件窄任务，所以小模型「够用、更合适、更经济」，且能被训成严格输出 JSON 这类格式。论文摘录里那个「便宜 10–30 倍」的数字我只见于二手转述，没核到正文，这里不当结论用。但我今晚的测量给它补了一条论文没讲的边界：小模型确实能严格输出 JSON——前提是你先把它的思考关掉。 这一条站内之前梳理《Agent 推理循环里被小模型接管的八个岗位》时还没有实测支撑，现在有了。

密度定律该怎么读：我算出来是 5.4 个月，不是 3 个月

趋势文章最爱引的是清华的密度定律。原始论文（arXiv:2412.04315，v2 修订于 2024-12-06）的说法我核过原文：把「达到同等性能所需的参数量」定义为有效参数量，能力密度即有效参数量与实际参数量之比，而开源模型的最大能力密度「约每三个月翻一倍」。期刊版发在 Nature Machine Intelligence（2025），有付费墙我没读到正文；二手报道说期刊版把周期调到了约 3.3–3.5 个月，我未核实。

拿我今晚的数据做一次窄任务校验：Qwen2.5-7B（2024-09，7.62B）和 Qwen3.5-0.8B（2026-03，752M）在这 20 件抽取活上同为 20/20，参数量差 10.1 倍，间隔 18 个月。折算下来是翻倍周期 5.4 个月。

而按论文的 3 个月周期外推同样 18 个月，应该是 64 倍——也就是说今天该有一个 500M 的模型全面打平 2024 年底的 32B。这显然不成立。

我的判断（这是观点，不是事实）：密度定律是一条对历史数据的漂亮拟合，不是可以线性外推的预言。它成立的那个窗口里有一次性红利——把大模型的 CoT 蒸馏进小模型、把后训练配方（distill → SFT → DPO → RLVR，见 Phi-4-Mini-Reasoning 那篇的四阶段）跑熟。这些红利是有限的：一旦小模型的能力主要来自蒸馏教师，它的上限就被教师锁住了，这正是站内《训练小模型的三条路》那条主线——每个能打的小模型背后都站着一个大模型。

顺带说，这也是我不愿意把自己算出的 5.4 个月叫成什么「定律」的原因：单一模型族、单一窄任务、n=20，它只是一个数据点。

一句话收口

  • 根本约束：服务端缺算力与带宽，端侧缺常驻内存。MoE 只解决前者，所以 2026 年的小模型全都长成「总参数大、激活参数小」，而这个形状对端侧毫无帮助——真正拆解常驻这一项的是苹果把权重放进闪存、按 prompt 路由。
  • 崩点：换成朴素的等常驻内存 dense 模型，每 token 要搬 19.07 GB，decode 天花板约 12.8 tok/s，交互性直接崩。
  • 可带走的动作：选型时不要问「几 B」，问三个数——权重文件多大、激活参数多少、推理框架默认开不开思考。第三个数最便宜也最容易要命：它值 16 倍墙钟和 0/20 的可用率。

这三个坐标什么时候不成立

灰度写在这里，不写成免责声明：

用云 API 时前两个坐标基本无效。 常驻和搬运是服务商的成本，不是你的约束；你面对的是价格和限流。这套框架只在你自己持有权重时有用。

批量吞吐场景下第二笔账要重算。 我量的是单请求 decode，此时瓶颈是带宽。并发上去后瓶颈会换成算力，MoE 的激活参数优势会放大，「缩小模型收益递减」这条结论会松动。这台机器上换闸的位置我在《本地部署到底看哪些本机参数》里量过。

第三笔账只覆盖了跑腿活。 我测的是三字段抽取——一件明确不需要推理的活。对真正需要多步推理的任务，思考不是税而是全部价值所在，关掉它会让准确率崩掉。判据很简单：这次调用的正确答案，是不是一眼可判？ 是，就关掉思考；不是，就留着并给足预算。

可靠性这一维我没测。 2026 年有两篇相关工作值得单独读：《A Geometric Analysis of Small-sized Language Model Hallucinations》（2026-02-16）指出 agent 场景下小模型的幻觉会顺着多步链路放大，并质疑「幻觉只是知识缺失」这个主流归因；PhantomBench（2026-06-09）报告了一个反直觉结果——推理模型的幻觉率比非推理模型更高。两篇我都只核到了标题与提交日期，结论来自摘录，没读正文。但它们和我今晚的观察咬得上：在跑腿岗位上，思考不只是贵，可能还更不可靠。 这是我接下来想亲手验的一件事——同一批任务，开思考与关思考的错误内容分布有什么不同。如果做出来，我会更新到这篇。

至于市面上流传的那些采纳率预测（比如「到 2027 年 40% 企业 AI 负载从云端大模型迁到小模型」），我在聚合站上见过多次但没核到 Gartner 原报告，因此不作为判断依据引用。这篇文章里唯一我敢打包票的数字，是那台机器给我的：17.76 GiB、20.50 GiB、161.7 秒、0/20。

参考来源

我的实测环境与命令

  • 机器：Apple M5 Pro / 24 GiB 统一内存 / macOS 26.6.2；llama.cpp build 8ed274ef4 (9630)，ggml 0.15.1
  • 基准：llama-bench -m <model>.gguf -p 512 -n 128 -ngl 99 -r 3
  • 探针：llama-server -m <model>.gguf -ngl 99 -c 4096 --jinja，经 /v1/chat/completions 发 20 条抽取任务，temperature 0、n_predict 512，三种条件对照；关思考的正确写法是 -rea off
  • 模型：Qwen2.5-7B-Instruct-Q4_K_M（2024-09 发布）、Qwen3.5-0.8B-Q4_K_M、Qwen3.5-4B-Q4_K_M（均取自 unsloth 的 GGUF 仓库）
  • 探针脚本与全部原始记录留在本机，未入库；文中所有比例（8.6×/16.3×/10.3×/5.4 个月等）都用一次性脚本验算过

源码定位

论文

官方资料

站内回链