过去一年，"端侧小模型"成了 AI 圈最热闹的赛道。
手机厂商在发布会里喊 Mac mini 级算力进芯片，开发者拿它跑本地 Agent，硬件玩家在 Jetson Orin 上挑战 70B 量化模型。朋友圈里每隔一周就能看到一篇新文章——"某某模型又刷榜了""某某芯片本地推理破 X tok/s"。
这些数字看看就算。真要落到离线部署，你面临的不是"平均分更高"的问题，而是另一组更土的约束：
手机没电还得跑吗？工控板只有 2GB 显存怎么办？Agent 要连续跑 30 轮会话，KV Cache 会不会撑爆内存？首 token 延迟能不能压到 500ms 以内？
今天我们不谈跑分榜，谈一个更实在的问题：端侧小模型现在有三派在同时推进——MoE、稠密、扩散 LM——它们各自把哪个维度做到了极致，又在哪个维度妥协了。只有把这三件事看清，才能给你的硬件和任务做出靠谱的选型。
先说清楚分类依据。今天要讲的三派，划分标准只有一条：推理时实际被激活的参数从哪里来。
这个维度比"模型架构"或"参数规模"都重要——因为端侧算力紧张，能不能把总参数里的一小部分"挑出来"工作，直接决定了显存占用和推理速度的天花板。
总参数很大，但每次只激活一小撮"专家"。路由层决定走哪条专家路径，路由器本身也是一个小模型。理论上可以用极小的激活参数覆盖极大的总参数规模。代表：Liquid AI LFM2.5 系列、xAI Grok 的部分后端。
每次推理都走完整个模型，没有路由。参数规模就是激活参数规模，用各种量化（GGUF、AWQ、FP8）把它压进显存。代表：MiniCPM-V 系列、llama.cpp 社区的各种量化版本、Qwen 系列的端侧切片。
不走传统 token-by-token 自回归，而是把生成过程当成反向去噪。每次推理都是对一组噪声向量反复迭代，激活参数既不固定也不来自"专家路由"。代表：Liquid AI d1-3B 系列、MIT Diffusion Transformer 路线上的若干分支。
三派的命名都不神秘，但各有各的生态系统。现在混进来一个新变量：端侧硬件对这三派的友好度完全不一样——GPU 喜欢稠密矩阵，CPU 喜欢简单算子，NPU 更偏向固定形状的数据流。这就是为什么同一张榜单上，第一名在 iPhone 上可能跑不动，最后一名反而最顺手。
Liquid AI 今年发布的 LFM2.5-24B-A2B 是端侧 MoE 目前最有代表性的旗舰：总参数 24B，激活参数只有 2B。他们给了一个漂亮的数字——在 Apple M5 Max 上跑出 184 tok/s，比同量级稠密模型快了一截。
但这个故事没说完。
Liquid 官方自己也承认：路由器在每次推理开始前要先跑一遍，首 token 延迟（TTFT）比同激活参数的稠密模型多了几十毫秒。具体多多少，他们没给。路由器本身也是个小模型，在 NPU 上可能被加速器友好地执行，但在老款 CPU 上可能成瓶颈。
再看精度。LiveClaw 这个面向智能体工具调用的评测集上，LFM2.5-24B-A2B 拿了 48.09 分。对比基准是 Qwen3.6-35B-A3B 的 38.19——MoE 在这个任务上高出了约 26%。但 LiveClaw 只是一个基准。在更常见的 MMLU、ARC、GSM8K 这些通用集上，MoE 并不总能保持这种领先。
还有一个问题：MoE 的 KV Cache 没跟着激活参数一起缩小。路由器虽然只挑少数专家工作，但被挑中的专家各自产生的 KV 都要存下来。Agent 连续跑 30 轮的时候，KV 会稳定增长到一个稠密模型差不多的体量。端侧部署如果只盯着"激活参数小"而忽略 KV，很容易中途 OOM。
2026 年最让业界惊讶的一件事，是端侧小模型的稠密路线没有像大家预测的那样被 MoE 吞掉，反而活得挺好。MiniCPM-V 4.7 系列就是例子：它从 35B 一路切到 1B，覆盖四个参数档位，全部走稠密路线，每一档都配套 GGUF、GPTQ、AWQ、int4、FP8 五种量化格式。
为什么稠密路线扛住了？三个原因。
第一，硬件天然适配。现代手机 NPU、Mac Apple Silicon、NVIDIA Jetson、甚至 Intel 最新的 U 系列 CPU，对连续稠密矩阵乘法做了深度优化。MoE 需要路由、分块、稀疏算子调度，这些反而常常落在 NPU 的盲区。实际跑起来，同样的激活参数规模，稠密模型在硬件上"踩点"更准，很多时候 tok/s 反而更稳。
第二，量化生态成熟。llama.cpp 社区两年的耕耘，让稠密模型的量化技术几乎变成了一个"有手就会"的标准流程。你拿一个 7B 稠密模型，用 llama.cpp 的 quantize 命令一键就能压成 Q4_K_M 格式，显存占用砍到原来的 1/4，准确率损失在大部分任务里不到 3%。而 MoE 的量化，目前还处在"能用但不稳"的阶段——专家之间的稀疏结构让量化误差被放大。
第三，多模态任务稠密路线更稳。MiniCPM-V 系列主打多模态。图像到文本、音频到文本的任务里，MoE 的"专家路由"反而成了累赘——多模态融合本身就需要所有模态的编码结果被统一处理，挑专家的逻辑在这里帮不上忙。这也是为什么 HF Trending 里 Qwen-Image-2.1-Turbo 一直维持着 300+ 的日下载量，却没有人给它套 MoE 壳。
第三派是扩散路线。Liquid AI d1-3B 在 LiveClaw 上拿了 48.09 分，跟同系列的 MoE 旗舰打平，比同参数规模的稠密模型高了一大截。但很少有人在讨论扩散 LM 部署到 iPhone 或 Jetson 上。
为什么？先讲扩散 LM 怎么工作的。传统自回归 LM 是一个 token 一个 token 地往外吐，像打字机。扩散 LM 是从一组随机噪声出发，用几十步迭代把它"洗"成正确输出，像洗照片。
这个机制带来两个优势。一是生成质量在长文本上更稳，因为它是"整体优化"而不是"边走边猜"。二是理论上可以在迭代中途停下来做工具调用或重写，比自回归的"一路跑到黑"更灵活。
但端侧部署目前还卡在两个没解决的问题上。
首 token 延迟。扩散 LM 在输出任何东西之前要先跑完几轮去噪迭代。Liquid AI 没公开过 TTFT 数字，但 MIT Diffusion Transformer 的早期工作里，10 步去噪的 TTFT 大约是同参数稠密模型的 2 到 3 倍。对移动端用户来说，这等于等了 2 秒才看到第一个字。
迭代步数与输出长度耦合。传统 LM 生成 100 个 token 就跑 100 次前向，扩散 LM 生成 100 个 token 也跑 N 次前向（N 是去噪步数，典型值 8 到 16），但这 N 次前向每次都要处理整个序列。序列越长，扩散的成本是平方级增长的。对长 Agent 会话来说，这比 MoE 的 KV 问题还要命。
好了，三派各自的优缺点已经摊开了。现在给一张统一口径的横评表，帮你拍板。列维度选了最影响端侧决策的六件事：激活参数、总参数、首 token 延迟、峰值显存、工具调用能力、多模态支持。
| 维度 | MoE 派（以 LFM2.5-24B-A2B 为代表） | 稠密派（以 MiniCPM-V 4.7 / Qwen3.6-35B-A3B 为代表） | 扩散 LM 派（以 d1-3B 为代表） |
|---|---|---|---|
| 激活参数 | 2B（总 24B） | 1B ~ 35B（等于总参数） | 每次迭代全激活 |
| 总参数 | 24B | 1B ~ 35B（多档位） | 3B（目前小尺寸） |
| 首 token 延迟 | 基准 + 路由器开销（未公开，估计 +50ms） | 基准（最快） | 基准 × 2~3（去噪步数） |
| 峰值显存 | KV 随会话线性增长（与稠密相当） | 等于模型权重 + KV | 随序列长度平方增长 |
| 工具调用能力 | LiveClaw 48.09（高） | LiveClaw 38.19（中高） | LiveClaw 48.09（高，与 MoE 持平） |
| 多模态支持 | 路由器可能不友好（生态早期） | 成熟（MiniCPM-V 主打多模态） | 未充分验证 |
再给你一份按硬件和任务分类的快速推荐：
iPhone / 骁龙 Gen 3 以上：优先 MoE。激活参数小，在 NPU 上能跑出最快的交互式体验。如果需要多模态，退回稠密。
Mac mini M1 / M2：优先稠密。Apple Silicon 对稠密矩阵优化最充分，llama.cpp 开箱即用。M5 Max 这种高端机两种都能跑。
NVIDIA Jetson Orin / Xavier：稠密首选。TensorRT-LLM 对 7B ~ 13B 量化稠密模型的支持最稳，FPS/延迟都可控。
Intel CPU / 工控板（≤ 4GB 显存）：只能走稠密路线。MoE 路由和扩散迭代在这种硬件上都会拖垮延迟。选 1B ~ 3B 档位、GGUF Q4 量化。
单次问答 / 快速命令（≤ 5 轮会话）：MoE。小激活参数 + 高 tok/s 最搭。
长会话 Agent（≥ 20 轮工具调用）：稠密。KV 占用可预测，量化生态成熟，部署风险最低。
多模态任务（图文理解、语音交互）：稠密。路由器逻辑在多模态融合里没用。
实验性场景（研究、演示）：扩散 LM 可以试试。但不要带到生产环境。
MoE、稠密、扩散——三派现在都在同一个池子里试水，谁也没有彻底赢。
去年这个时候大家还在说 MoE 会吞掉整个端侧市场，结果稠密路线因为硬件优化和量化生态守住了半壁江山，扩散派又从一个意想不到的角度插了进来。
真正要选的时候，别去看谁的 tok/s 数字最大。先把你的硬件列表、显存上限、最大会话长度、和最常用的任务类型列出来，再拿这张表对照一遍。
如果对照完还是不知道选什么，选稠密。不会错。