认识 MiniCPM5-2B:20 亿参数跑出 Agent 能力,端侧模型第一次敢说自己"能干活"了
说个让我挺不舒服的对比。
我手机里装着一个 AI 助手,问它"帮我查一下这周末去杭州的高铁,再看看西湖边上评分 4.5 以上的酒店,最后给我排个行程"——它卡了三秒,然后回我一句"我暂时无法访问实时信息"。
这三秒里发生了什么?我的请求飞到了几千公里外的机房,一个几百 B 参数的模型替我想了想,然后告诉我它干不了。
花了钱、等了延迟、交了数据,最后得到一句"我干不了"。 这事挺荒诞的。
而就在 2026 年 9 月 8 日,面壁智能联合 OpenBMB 开源社区把 MiniCPM5-2B 扔了出来。它的核心主张很简单粗暴:上面那件事,20 亿参数的模型在你自己手机上也能干,而且不用联网。
一组让我反复看了两遍的数据:在 Artificial Analysis 的 Agentic Index(专门测 Agent 能力的指标)上,MiniCPM5-2B 拿了 20 分;而同级别的 2B-4B 模型,普遍只有 2 分左右。
十倍。不是 10%,是 10 倍。
更扎心的是横向对比:这个 2B 模型在综合智能上拿了 23 分,超过了 Qwen3.5 9B(22 分)和参数是它 6 倍的 Gemma 4 12B(22 分)。 以 1000 分为人类基线的真实任务评测里,它拿 891 分,而 Qwen3.5 9B 是 645、Gemma 4 12B 是 647。 翻译一下:你多出来的那 40 亿参数,可能只是在交电费。
什么是 MiniCPM5-2B
MiniCPM5-2B 是面壁智能联合开源社区 OpenBMB 于 2026 年 9 月 8 日开源的高密度端侧语言基座模型,2B 参数级别,Apache 2.0 协议,原生支持 131,072 tokens(128K)上下文,主打在手机、PC、车机、机器人等算力受限设备上本地运行通用 Agent 能力。
代码在 github.com/OpenBMB/MiniCPM,权重在 Hugging Face 和魔搭 ModelScope 都有。
先把几个容易搞混的点讲清楚:
第一,它是"密度模型",不是"小模型"。 名字里的 2B 是尺寸级别,实际参数量约 25.17 亿(非 Embedding 参数约 19.82 亿)。面壁从 2023 年就一直在推一个叫**「密度定律」**的东西——模型能力的提升速度,快过参数量的增长和成本的下降速度。翻译成人话:每一份参数里塞进多少智能,才是端侧的真瓶颈。 因为手机上的显存和算力是死的,参数总量有天花板,那唯一的出路就是把每个参数的潜力榨干。
第二,它是标准架构,不是魔改。 官方模型卡白纸黑字写着 LlamaForCausalLM,42 层,GQA 分组查询注意力(16 个 Q 头、2 个 KV 头)。这意味着你不需要任何自定义算子、不需要 fork 模型代码,Transformers / vLLM / SGLang / llama.cpp / Ollama 开箱即用。这一点在工程上极其重要——多少"惊艳"的开源模型死在了"需要打补丁才能跑"上。
第三,它主打的不是"聊天",是"干活"。 官方给的能力清单是:工具调用、深度搜索、代码生成、Office 文档处理、数据库交互。也就是说它的设计目标从一开始就不是陪你唠嗑,而是当 Agent 的大脑。
第四,这次开源的不是只有权重。 这点我认为比模型本身更重要:训练 Recipe(配方)、强化学习框架 Meshy、RL 策略 JustRL II、以及四个数据集(UltraData-Code、UltraData-SFT-Agent-2609、UltraData-RL-2609、UltraX)全部开放。截至 2026 年 9 月,UltraData 系列数据集累计下载量已超 266 万次。
它有什么特点
- 4B 以下综合第一,34 项基准平均 53.9 分。 官方模型卡列出的 34 项基准覆盖代码推理、数学推理、指令遵循、综合知识、长文本、工具调用、智能体任务,MiniCPM5-2B 平均 53.9 分排名第一——不仅领先同级 2B 的第二名(33.2 分),也超过 4B 里表现最好的 Qwen3.5-4B(51.1 分)。
- Agentic Index 20 分,断层式领先。 同级的 LFM2.5-2.6B、Granite 4.2 3B、Mistral 3 3B 都在这个指标上非常吃力。这是"端侧通用 Agent"第一次有了像样的数字支撑。
- Token 效率高得离谱。 完成同样的 Intelligence Index 任务,MiniCPM5-2B 平均只消耗 21k 输出 token(14k 思考 + 7k 回答),处于全场最低一档。得分相近的 Qwen3.5 9B 需要 34k,Granite 4.2 8B 需要 26k。用差不多一半的"口水",换来了更高的分数。 对端侧来说这不只是省钱——token 少意味着延迟低、发热少、电池耐用。
- 原生 128K 上下文。 131,072 tokens。手机上能塞进一整份长文档来做分析,不用切片、不用外挂向量库,这件事的体验差别很大。
- Think / No-think 双模式。 官方推荐采样参数:思考模式
temperature=1.0, top_p=0.95。聊天闲扯和深度推理可以走不同的路子,不用为了省 token 牺牲复杂任务的表现。 - 量化与端侧格式齐全。 官方提供 BF16 标准版(Transformers / vLLM / SGLang)、GGUF 版(llama.cpp / Ollama / LM Studio / Jan)、MLX 4bit 版(Apple Silicon)、GPTQ 4bit 版,以及 LiteRT-LM 版。Mac 用户直接有 4bit 现成包,不用自己量化。
- 芯片 Day0 适配,不是"以后会支持"。 英特尔(酷睿 Ultra 系列 CPU+GPU+NPU 全异构 + OpenVINO 全链路优化)、瑞芯微(RK3588 + RK1828 双芯 + RKNN3,靠高带宽压低首 token 时延)、Arm(Armv9 SME2 技术,实测 prefill 约 1.7 倍、decode 约 1.2 倍提速)三家首日原生适配。另外 FlagOS 一口气覆盖了英伟达、海光、沐曦、天数智芯、昆仑芯、昇腾、ARM-v9 等 9 种芯片。
我一直觉得"端侧模型"这个词被用坏了。很多所谓的端侧模型,本质上是个被砍到只剩聊天能力的云端模型,跑在本地只是因为"能跑起来"。 MiniCPM5-2B 不一样的地方在于:它把 Agent 能力当一级公民来训练,而不是当成云端模型掉线后的降级方案。 这是两条完全不同的技术路线。
用在哪儿
手机上的本地 Agent。 这是最直接的场景。MiniCPM 系列已经进入三星旗舰机,截至 2026 年 8 月全系列全球下载量突破 5000 万次,其中语言基座下载超 1300 万次。你的日程整理、消息摘要、本地文件检索,全程不出设备。
智能座舱。 长安、吉利等车企的座舱已经在用。这个场景的需求非常刚性——车机经常没信号,而且你不可能接受" tunnel 里语音助手罢工"。本地推理带来的低时延(首 token 延迟是语音交互体验的生死线)和无网可用性,是云端方案补不上的。
具身机器人。 机器人不可能背一根网线上街,也不能每次抓取前先问云端。2B 模型的功耗和体积让"本地决策闭环"变得现实。
PC / AI PC 上的个人助理。 英特尔平台上已经跑通了深思考推理、工具调用、深度搜索、代码生成全套端侧 Agent 能力,且显著压低了运行内存占用和长上下文推理时延。开发者在 AI PC 上可以做到开箱即用。
成本敏感的高频调用。 这条其实最容易被忽略:如果你的业务每天要跑几百万次"格式化工单""抽取字段""分类工单"这类活,用 2B 模型本地跑,和调用云端 API 的成本差可能是两个数量级,而且数据不用出内网——这对金融、医疗、政务是硬需求。
初体验
三种玩法,从省事到折腾排个序。
最省事:Ollama / LM Studio(GGUF)
# 从魔搭拉 GGUF 版
pip install -U modelscope
modelscope download --model OpenBMB/MiniCPM5-2B-gguf
# Apple Silicon 用 MLX 4bit 版
modelscope download --model OpenBMB/MiniCPM5-2B-MLX拿 llama.cpp 或 Ollama 起服务之后,就是标准 OpenAI 兼容接口,不用改一行业务代码。
算力够:vLLM 起服务
pip install "vllm>=0.21"
vllm serve openbmb/MiniCPM5-2B --port 8000调一下试试:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "openbmb/MiniCPM5-2B",
"messages": [{"role": "user", "content": "帮我看看这份报表里环比下降最多的三个指标"}],
"max_tokens": 512,
"temperature": 1.0
}'要玩工具调用:SGLang(官方推荐)
pip install "sglang[srt]>=0.5.16"
python -m sglang.launch_server \
--model-path openbmb/MiniCPM5-2B \
--port 30000 \
--tool-call-parser minicpm5注意那个 --tool-call-parser minicpm5(或者写 auto)。这行是 MiniCPM5-2B 的灵魂开关——模型输出的是 XML 风格的工具调用,靠这个 parser 转成 OpenAI 的 function calling 格式。想真的让它"干活",别漏。
想再压一层延迟,可以开 DSpark 投机解码:
python -m sglang.launch_server \
--model-path openbmb/MiniCPM5-2B \
--trust-remote-code \
--speculative-algorithm DSPARK \
--speculative-draft-model-path openbmb/MiniCPM5-2B-DSpark \
--speculative-dspark-block-size 7 \
--port 30000本地 Python 推理:
pip install -U "transformers>=5.6" accelerate torchfrom transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "openbmb/MiniCPM5-2B"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id, torch_dtype="auto", device_map="auto",
)
messages = [{"role": "user", "content": "请简要介绍一下你自己。"}]
inputs = tokenizer.apply_chat_template(
messages, tokenize=True, add_generation_prompt=True,
enable_thinking=True, return_dict=True, return_tensors="pt",
).to(model.device)
outputs = model.generate(**inputs, max_new_tokens=128)
print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:], skip_special_tokens=True))要微调的话,LlamaFactory、ms-swift、TRL、Unsloth、XTuner 都已经支持。
两个避坑提醒:一是显存别按"2B"估,实际参数约 25 亿,消费级 8GB 卡跑 BF16 要留足余量,紧张就上 GGUF 或 GPTQ 4bit;二是工具调用一定走 SGLang 并带上 parser 参数,用 vLLM 默认配置跑会以为模型不会调工具,白白浪费它最强的那部分能力。
进阶
我想把话说得直白一点:这次开源最值钱的不是那 25 亿个权重,是那套"怎么把 Agent 能力训进小模型"的方法论。
权重会过时,榜单会被刷新。但 Meshy 框架(干掉了 RL 训练的中央控制器和 Ray 依赖,把训练、推理、奖励计算全建模成对等服务,用 TransferQueue 的数据就绪状态驱动控制流,同步/异步/全异步三种模式自由切换)和 JustRL II(给 GRPO 装上 Critic 做 token 级信用分配,专门治长思维链训练时"分数越训越低"的老毛病),是可以直接拿去用的生产力工具。
数据侧也一样。UltraData-Code 从约 1.92 亿个公开 GitHub 仓库采集、清洗、去重、结构化合成,产出 400B 词元的 L2 算法精筛数据和 150B 词元的 L3 任务导向合成数据——这种体量的高质量代码数据,自己从头做一遍基本不现实。
我的个人判断:2026 年下半年真正的分水岭,不是谁家模型分数高,而是 Agent 到底跑在云上还是跑在你手里。 云端 Agent 的成本、延迟和数据合规三座大山,靠堆参数翻不过去;端侧这条路一旦被验证可行,整个 AI 应用的成本结构会被重写。MiniCPM5-2B 的 20 分 Agentic Index,是这条路的第一块路标。
当然要泼点冷水:891 分相对 1000 分的人类基线,意味着它离"可靠"还有距离;Terminal-Bench v2.1 只有 8.6 分、SWE-bench Pro 14.4 分,说明复杂长程编码任务仍是端侧模型的禁区;而且它现在也只是"能力雏形",离真正量产落地还隔着工程优化的坑。别拿它去替代云端干重活,它的战场是那些高频、轻量、要隐私的场景。
一个务实的起步建议:挑一个你业务里最高频、最不重要的那类任务(比如工单分类、字段抽取、日志摘要),先用 vLLM 起个服务压 1000 条真实数据,看准确率和延迟能不能接受。跑通了这个再谈替换云端,比盯着榜单纠结值不值当有用得多。
更多开源技术干货和学习资料,关注公众号「遇码」,领取专属福利。
