MiniCPM ：端侧 LLM 的效率路线

May 14, 2026

aillmopen-source

写于 2026 年 5 月 | 数据主要截至 2026 年 2 月

过去一年，小模型这条路线变得越来越值得认真看。

不是因为 8B、4B、2B 模型突然能全面替代大模型，而是因为很多真实场景根本不需要“尽可能强”的模型。它们需要的是另一组指标：本地能不能跑、长上下文会不会爆、响应是不是够快、部署链路是不是可控、许可证能不能放进产品里。

MiniCPM 吸引我的地方就在这里。它不是单纯把参数量做小，而是围绕端侧部署和长上下文效率做了一套相对完整的工程路线：MiniCPM4 用可训练稀疏注意力降低长文本成本，MiniCPM4.1 加入推理 / 非推理双模式，MiniCPM-SALA 进一步尝试稀疏注意力和线性注意力混合，BitCPM4 则把量化压到 1.58 bit。

这篇不是模型发布新闻，也不是 benchmark 摘抄。我更关心一个问题：如果从工程使用角度看，MiniCPM 这条路线到底解决了什么，又会把哪些复杂性转移给使用者。

先给结论

MiniCPM 系列最值得关注的不是“同规模榜单分数”，而是它对端侧 LLM 的三个判断：

  1. 长上下文的瓶颈不只在模型能力，也在推理成本。
  2. 小模型要真正可用，必须同时解决架构、推理框架、量化和部署。
  3. 主流推理生态还没有完全消化稀疏注意力这类结构创新，性能收益往往伴随工程约束。

所以我会把 MiniCPM 看成一个偏工程导向的模型系列：它很适合研究端侧智能体、本地长文本处理、低成本私有化部署；但如果目标是最快接入生产 API，或者依赖 vLLM / SGLang 这类成熟服务框架，使用它的稀疏能力时要提前评估部署成本。

MiniCPM 是什么

MiniCPM 是 OpenBMB 组织下的高效小参数量大语言模型系列，主要由清华大学自然语言处理实验室和面壁智能推动。它的核心方向很明确：在 10B 以下规模里，尽可能提升模型能力和推理效率，尤其面向端侧、边缘设备和本地部署。

截至这次调研，比较关键的几个节点是：

时间版本重点
2024.02MiniCPM-2B / 1B轻量模型起点
2024.09MiniCPM3-4B4B 规模能力提升
2025.06MiniCPM4-8B / 0.5B引入 InfLLM-V2，可训练稀疏注意力
2025.09MiniCPM4.1-8B支持 thinking / non-thinking 双模式
2026.02MiniCPM-SALA稀疏注意力 + 线性注意力混合架构

这个演进路线里，参数规模不是唯一主线。更重要的主线是：怎样让模型在更长上下文、更小设备、更低显存预算下仍然可用。

MiniCPM4：把长上下文成本当成一等问题

MiniCPM4 的核心技术是 InfLLM-V2。它的思路不是在推理后临时剪枝，而是在训练阶段就引入稀疏注意力，让模型学会只关注更相关的 KV 块。

官方材料里反复强调的收益，是长上下文场景下的推理加速。典型配置里，每个 token 不需要和全部 128K token 做 dense attention，而是通过 semantic kernel 选择更相关的块。换句话说，它试图把长上下文的计算从“全量看一遍”变成“结构化地只看关键部分”。

这点很重要。很多长上下文模型的宣传重点是“支持多少 token”，但工程上更关键的问题是：支持之后能不能用得起。128K 上下文如果只是理论上能跑，但首 token 延迟、显存占用和吞吐都不可接受，对产品没有太大意义。

InfLLM-V2 的价值就在于它直接处理这个问题。

不过这也带来一个现实约束：稀疏注意力的收益依赖推理框架支持。官方推荐的 CPM.cu 和 HuggingFace 路线能利用这套机制，但 vLLM、SGLang 这类服务端常用框架在相关文档中仍以 dense 路线为主。对个人研究来说这不是大问题；对生产部署来说，这会影响运维复杂度和技术选型。

MiniCPM4.1：双模式推理更接近真实使用

MiniCPM4.1 一个值得注意的变化，是把 thinking 和 non-thinking 放进同一个模型里。

这比单纯提高 benchmark 更实用。真实应用里，并不是每个请求都需要深度推理。让模型在复杂问题上展开推理，在普通问答、摘要、改写、工具调用场景里走更短路径，才更符合成本和延迟需求。

使用方式也比较直接：

tokenizer.apply_chat_template(messages, enable_thinking=True)
tokenizer.apply_chat_template(messages, enable_thinking=False)

从产品角度看，这其实是在把“模型能力”拆成可调策略：同一个模型可以根据任务选择更高质量或更低延迟。对本地应用、桌面助手、端侧智能体来说，这种能力比单一最高分更有价值。

SALA：稀疏注意力和线性注意力的混合实验

MiniCPM-SALA 是这条路线里最有研究味的一步。

它没有继续沿着纯 Transformer dense attention 往前推，而是采用混合架构：一部分层使用 InfLLM-V2 稀疏注意力，另一部分层使用 Lightning Attention 线性注意力。官方论文中的比例是 25% sparse attention 加 75% linear attention。

这个设计背后的判断很直接：

SALA 还引入了 HALO，用蒸馏方式从已有 Transformer 权重转换到混合架构，降低从零训练的成本；位置编码上则用 HyPE 区分稀疏层和线性层的需求。

我认为 SALA 的意义不在于它已经是所有人都应该使用的成熟方案，而在于它把一个趋势说清楚了：长上下文模型不会只靠扩大窗口解决问题，架构本身必须变。

BitCPM4：极端量化不是噱头，但也不是万能答案

BitCPM4 把参数量化到 1.58 bit，也就是三值量化。这个方向对端侧部署很关键，因为很多本地设备的限制不是算力，而是内存和带宽。

它的训练方式不是简单 post-training quantization，而是量化感知训练。官方材料中提到的思路是：先在小模型上用 Wind Tunnel 搜索量化训练超参，再迁移到目标规模模型。

这里我会比较谨慎地看它的价值：

也就是说，BitCPM4 很值得跟踪，但是否采用取决于硬件约束是否真的足够强。

部署生态：亮点和代价都在这里

MiniCPM 的部署覆盖面不窄：HuggingFace、CPM.cu、vLLM、SGLang、llama.cpp、Ollama、MLX 都有不同程度的支持。但它的能力不是在每个框架里完全等价。

我会把它分成三类：

路线优点代价
CPM.cu / HuggingFace更接近官方能力，能使用稀疏注意力生产化和生态成熟度要评估
vLLM / SGLang服务端部署成熟，吞吐生态好稀疏注意力能力可能无法完整利用
llama.cpp / Ollama / MLX本地体验友好更适合轻量尝试，不一定覆盖全部高级能力

这也是 MiniCPM 最值得注意的取舍：它不是一个“随便接入就能拿满所有收益”的模型系列。你要先决定自己要的是模型能力、推理效率、部署便利，还是生态稳定。

和 Qwen、Llama、Phi 这类模型怎么比较

如果只问“哪个模型最强”，这个问题不太成立。不同模型系列优化目标不一样。

我的粗略判断是：

MiniCPM 的差异化不在于“所有场景都赢”，而在于它把端侧效率这件事做得更系统。

我会怎么用它

如果我现在要做一个本地 AI 工具，我会优先在这些场景里测试 MiniCPM：

  1. 本地长文档分析，例如代码库摘要、论文阅读、日志分析。
  2. 端侧 Agent，尤其是需要工具调用但预算有限的场景。
  3. 边缘设备上的轻量推理，例如 Jetson、AIPC、低显存工作站。
  4. 对模型权重可控、许可证友好、可私有化部署有要求的项目。

我不会一开始就在所有生产链路里默认选它。原因不是模型不够好，而是工程路线还需要和具体部署环境匹配。尤其是当团队已经深度依赖 vLLM / SGLang / Kubernetes 推理服务时，稀疏注意力带来的收益能否覆盖额外维护成本，需要实测。

最后判断

MiniCPM 系列值得关注，因为它代表了一条和“继续堆更大模型”不同的路线：在小参数量、长上下文、端侧部署之间做系统优化。

它的优势不是单点能力，而是组合能力：

但这条路线也有代价：越依赖结构创新，越依赖配套推理框架；越想拿到极致效率，越要接受更复杂的部署栈。

所以我的结论是：MiniCPM 不一定是最省心的小模型，但它是研究端侧 LLM 效率路线时绕不开的项目。对个人开发者来说，它适合深入试验；对团队来说，它适合进入候选池，但要带着真实 workload 做验证，而不是只看榜单。

参考资料

← Back to blog