写于 2026 年 5 月 | 数据主要截至 2026 年 2 月
过去一年，小模型这条路线变得越来越值得认真看。不是 8B、4B、2B 突然能替代大模型，而是很多真实场景根本不需要”尽可能强”的模型——它们要的是本地能不能跑、长上下文会不会爆、响应够不够快、部署链路可不可控、许可证能不能放进产品。
MiniCPM 吸引我的地方就在这里。它不是单纯把参数量做小，而是围绕端侧部署和长上下文效率做了一套相对完整的工程路线：MiniCPM4 用可训练稀疏注意力降低长文本成本，MiniCPM4.1 加入推理 / 非推理双模式，MiniCPM-SALA 尝试稀疏 + 线性注意力混合，BitCPM4 把量化压到 1.58 bit。
这篇不是发布新闻，也不是 benchmark 摘抄。我更关心一个工程问题：MiniCPM 这条路线解决了什么，又把哪些复杂性转移给了使用者。
MiniCPM 是什么
MiniCPM 是 OpenBMB 组织下的高效小参数量大语言模型系列，主要由清华大学自然语言处理实验室和面壁智能推动。它的核心方向很明确：在 10B 以下规模里，尽可能提升模型能力和推理效率，尤其面向端侧、边缘设备和本地部署。
截至这次调研，比较关键的几个节点是：
| 时间 | 版本 | 重点 |
|---|---|---|
| 2024.02 | MiniCPM-2B / 1B | 轻量模型起点 |
| 2024.09 | MiniCPM3-4B | 4B 规模能力提升 |
| 2025.06 | MiniCPM4-8B / 0.5B | 引入 InfLLM-V2，可训练稀疏注意力 |
| 2025.09 | MiniCPM4.1-8B | 支持 thinking / non-thinking 双模式 |
| 2026.02 | MiniCPM-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 放进同一个模型。不是每个请求都需要深度推理——复杂问题展开思维链，普通问答、摘要、工具调用走短路径，这才符合真实的成本和延迟需求。
用法很直接：
tokenizer.apply_chat_template(messages, enable_thinking=True)
tokenizer.apply_chat_template(messages, enable_thinking=False)本质上是在把”模型能力”拆成可调策略：同一个模型根据任务选择更高质量或更低延迟。对本地应用、桌面助手、端侧智能体来说，这比刷一个最高分更实用。
SALA：稀疏 + 线性的混合架构实验
MiniCPM-SALA 是这条路线里最有研究味的一步。它没有继续沿纯 Transformer dense attention 往前推，而是混合了两种注意力：25% 的层使用 InfLLM-V2 稀疏注意力（保留长距离依赖的保真度），75% 使用 Lightning Attention 线性注意力（长序列上计算和内存复杂度更优）。纯线性模型可能损失表达能力，纯稀疏模型仍有成本压力，混合是折中点。
为了让这种混合架构不需要从零训练，SALA 引入了 HALO——通过蒸馏把已有 Transformer 权重转换到混合架构。位置编码方面，用 HyPE 分别适配稀疏层和线性层对位置信息的不同需求。
SALA 的意义不在于它已经是成熟方案，而在于它说清了一个趋势：长上下文模型不会只靠扩大窗口解决问题，架构本身必须变。
BitCPM4：1.58 bit 量化的实际意义
BitCPM4 把参数量化到 1.58 bit（三值量化）。很多本地设备的限制不是算力，而是内存和带宽，这个方向对端侧部署很关键。
它用的不是 post-training quantization，而是量化感知训练：先在小模型上用 Wind Tunnel 搜索量化超参，再迁移到目标规模。
我的判断：
- 端侧和边缘设备，极低 bit 量化确实能显著降低部署门槛。
- 质量敏感任务，需要按自己的数据重新评估。
- 桌面 GPU 或云端推理，BF16 / GPTQ / AWQ 可能已经够用。
BitCPM4 值得跟踪，但要不要采用取决于你的硬件约束是否真的足够强。
部署生态：能力不等于处处可用
MiniCPM 的部署覆盖面不窄——HuggingFace、CPM.cu、vLLM、SGLang、llama.cpp、Ollama、MLX 都有支持。但能力不是在每个框架里完全等价：
| 路线 | 优点 | 代价 |
|---|---|---|
| CPM.cu / HuggingFace | 最接近官方能力，能用稀疏注意力 | 生产化和生态成熟度需评估 |
| vLLM / SGLang | 服务端部署成熟，吞吐生态好 | 稀疏注意力能力可能无法完整利用 |
| llama.cpp / Ollama / MLX | 本地体验友好 | 适合轻量尝试，不一定覆盖高级能力 |
MiniCPM 最值得注意的取舍就在这里：它不是”随便接入就能拿满收益”的模型系列。你要先决定自己要的是模型能力、推理效率、部署便利，还是生态稳定。
和 Qwen、Llama、Phi 怎么选
“哪个最强”不是正确的问题。不同系列优化目标不同，关键看你的约束：
- 中文生态 + 通用能力 + 工具链成熟度 → Qwen 仍然是默认选项，且 Qwen2.5 小模型在端侧也很有竞争力
- 国际生态 + 长期兼容性 → Llama 系列，社区支持和下游适配最广
- 轻量本地实验 → Phi、Gemma、Qwen 小模型都值得试
- 端侧长上下文效率 + 稀疏注意力 + 低 bit 量化 → MiniCPM 值得单独评估
MiniCPM 的差异化不在于”所有场景都赢”，而在于它把端侧效率做得更系统。如果你不需要稀疏注意力或极端量化，Qwen / Llama 的部署体验更省心。
我会怎么用它
如果现在要做本地 AI 工具，我会优先在这些场景测试 MiniCPM：
- 本地长文档分析——代码库摘要、论文阅读、日志分析
- 端侧 Agent——需要工具调用但预算有限
- 边缘设备推理——Jetson、AIPC、低显存工作站
- 私有化部署——权重可控、许可证友好
我不会在生产链路里默认选它。不是模型不够好，是工程路线还需要和具体部署环境匹配。团队如果已经深度依赖 vLLM / SGLang / Kubernetes 推理服务，稀疏注意力的收益能否覆盖额外维护成本，必须实测。
总结
MiniCPM 代表了一条和”堆更大模型”不同的路线：小参数量、长上下文、端侧部署之间做系统优化。
它的优势是组合能力：InfLLM-V2 处理长上下文推理成本，MiniCPM4.1 用双模式推理适配不同任务，SALA 探索 sparse + linear 架构，BitCPM4 把量化推到极低 bit，CPM.cu 把这些能力落到实际设备。
代价同样清晰：越依赖结构创新，越依赖配套推理框架；越想拿到极致效率，越要接受更复杂的部署栈。
MiniCPM 不一定是最省心的小模型，但它是研究端侧 LLM 效率路线时绕不开的项目。个人开发者适合深入试验；团队适合放进候选池，带着真实 workload 做验证。
参考资料
- OpenBMB/MiniCPM GitHub 仓库：https://github.com/OpenBMB/MiniCPM
- MiniCPM4 技术报告：https://arxiv.org/abs/2506.07900
- MiniCPM-SALA 技术报告：https://arxiv.org/abs/2602.11761
- InfLLM-V2 论文：https://arxiv.org/abs/2509.24663
- HuggingFace OpenBMB 模型库：https://huggingface.co/openbmb
- CPM.cu 推理框架：https://github.com/OpenBMB/CPM.cu