MiniCPM5-2B与4B的竞争：为何代理框架能展现不同的故事
MiniCPM5-2B在单次测试得分上优于4B系列模型，但在基于代理的测试中则落后两到三倍。基准测试中的混淆率及Ollama的处理速度也是考量因素。
来源: The 2B Model That Beats 4B Rivals — Until You Test It as an Agent
一个拥有25亿个参数的模型，据说在高级编程测试中能超越40亿参数的竞争对手，听起来似乎非常划算。然而，若将同一模型接入真正的多轮智能系统，其性能则会下降多达三倍。单次测试的结果很难反映实际软件工程中的复杂情况。忽略综合评分，在本地测试处理效率，才能为判断何时该使用此模型提供明确的依据。
宣称的优势
OpenBMB于2026年9月7日发布了MiniCPM5-2B。这是一个参数量为25.16亿的密集型因果语言模型，采用Apache 2.0许可证，原生上下文长度为131,072个标记。根据发布信息，它是40亿参数以下最佳的开放模型，在34项基准测试中的平均得分达到53.9，优于包括Qwen3.5-4B在内的多款40亿参数级竞争模型，具体得分如下：MATH-500为94.6，AIME 2026为86.5，LiveCodeBench v6为69.1，SWE-bench Verified为46.4。
这里没有人拿经过挑选的排行榜截图来炫耀。这次发布是精心组织、严肃认真的：有八个模型文件同时发布。这些模型涵盖了基础阶段的检查点、训练中期及单独的SFT阶段的结果，还有通过RL和OPD调优后的最终模型、GGUF和MLX格式的转换版本、4位精度的GPTQ构建版本，以及一个名为MiniCPM5-2B-DSpark的推测解码原型模型。一个只是悄悄测试基准的实验室不会这样发布产品。这个项目似乎期待得到严格审查，因此为从llama.cpp和Ollama，到LM Studio、vLLM和SGLang，再到Transformers、MLX以及FlagOS多芯片架构等各种目标运行环境都准备了相应的文件。
At full strength, the claim is that a model about 44 percent smaller than Qwen3.5-4B beats it on math, code and software-engineering benchmarks. If that held without caveats, it would be a meaningful data point about scaling for reasoning-focused post-training. It does not hold without caveats, and the interesting part is exactly where it breaks down and why.
What is under the hood
了解实际运行的架构有助于理解其优缺点。MiniCPM5-2B是一种与LlamaForCausalLM类似设计的解码器：它拥有42层Transformer结构，采用分组查询注意力机制，16个查询头共享2个键/值头。对于这种规模的模型而言，8比1的比例相当大胆，这大大减少了每个标记对应的KV缓存大小，因此在需要保留较长的工具调用历史记录或多个智能体会话共享同一块GPU时尤为有用。尽管MiniCPM系列的其他版本如MiniCPM-SALA和MiniCPM4曾尝试过混合注意力机制，但该团队仍选择使用传统机制，并将精力投入其他方面。
其限制因素在于上下文长度与训练数据的筛选。在参数量低于30亿的情况下，模型能支持131,072个标记实属罕见，因为大多数该规模模型的上限通常在32K到64K之间，超过此范围后性能就会下降。在需要模型持续记录越来越长的调用记录、差异对比及命令行输出的任务中，这样的上下文容量比单纯的参数数量更为重要。
该模型仅支持英语和中文处理，不具备视觉和音频功能。这种设计上的限制是刻意为之，并非疏忽，因为用于多模态对齐的每个参数都会减少用于推理和工具使用的资源。OpenBMB还发布了训练后的数据：UltraData-SFT-Agent-2609，其中包含50万条智能体行为样本；以及UltraData-RL-2609，包含超过8万条强化学习样本。这体现了真正的透明度，因为模型中内置的智能体行为可以直接被查看，而无需通过基准测试的差异来推测。
在了解其架构之后，那些基准测试结果就不再是抽象的数字，而是关于特定解码器及相应训练方法的可验证假设。
首个突破：23对比15
该模型在发布后不到一天就出现了问题。OpenBMB的声明称该模型的人工智能分析智能指数得分为23，而Artificial Analysis的独立追踪系统显示的得分则为15。后来对该指数的修正后数值接近13。人们自然而然地会质疑OpenBMB是否夸大了自己的数据。
事实并非如此，这一情况值得仔细研究，因为对基准测试结果差异的本能愤怒既不是正确的反应，也是最普遍的反应。Artificial Analysis的方法说明解释了这一差异。简而言之，差异并非源于模型性能下降，而是评估标准发生了变化：与早期版本相比，私人测试集在总权重中的占比上升到了40%，此外4.2版本还增加了两项新评估内容，即AA-Briefcase智能体评估和长上下文测试。
OpenBMB公布的23分是依据智力指数v4.1.1版本测得的。等到人们开始比较这些数值时，公开追踪版本已升级到v4.2，其权重设置不同，而且多了两个在最初数据发布时并不存在的构成要素。将一个版本的23分与另一个版本的15分进行对比并不能说明存在谎言，因为这只是在比较两种不同的测量标准，之后对两者结果不一致表示惊讶而已。
真正的失误在于早期的报道将这两个数值并排刊登，却未说明它们来自不同的指数版本，这就导致了毫无数据依据的误导性结论。凡是引用综合指数得分的报道都应注明对应的版本信息。如果不这么做，23分和15分就无法相互比较，实际上只是使用了相同名称的两个不同问题罢了。
第一个问题是可以解决的，而第二个问题则几乎无法如此简单地解决。
真正的差距：智能体工具的运用
决定这一模型如何被看待的数值来自Terminal-Bench v2.1测试。在该测试中，MiniCPM5-2B的得分在8.6到9之间，而Qwen3.5-4B的得分则为25.8。两者之间存在大约三倍的差距，尽管MiniCPM5-2B在同类模型中排名智能指数首位，但在该基准测试中仍仅位列第八。SWE-bench Pro测试的结果也类似，MiniCPM5-2B的得分为14.4，Qwen3.5-4B的得分为28.2，差距约为两倍。
将这一结果与发布声明放在一起看。OpenBMB在SWE-bench测试中获得的46.4分，号称优于Qwen3.5-4B，正是“超越4B模型”这一宣传点的核心依据。但SWE-bench Pro并非只是换个名字的同一项测试——它使用的是更广泛、更具挑战性的真实代码库问题集，并通过真正的智能体框架来运行，其“Verified”模式更接近于单次补丁生成方式。而Terminal-Bench则与单次评估相去更远，它是一个实时终端环境，模型需要在多轮交互中自行规划、执行命令、读取输出，并从自身错误中恢复。
MindStudio的独立评估直截了当地指出：该模型在某些智能体基准测试中表现尚可，但在更难的智能体测试——即SWE-bench Pro和Terminal-Bench中，表现远落后于Qwen。
这一结果远比索引版本不匹配的问题更能调整人们的预期。对于那些需要编写正确补丁来完成精心设计的任务——即以工程方式实现的单次生成任务——验证系统会给予相应奖励。Terminal-Bench和SWE-bench Pro在多次工具使用过程中都能保持稳定表现，能够从失败的shell命令中恢复，并避免在计划执行到第三步时出现崩溃。显然，该模型在第一类任务上表现优异，而在第二类任务上则相对较弱。任何将其作为自主编码子代理、替代单次补丁编写工具的人，都将面临第二类任务的挑战。
这种差距是真实存在的且尚未得到解释，也没有任何方法论上的因素可以说明它，因此应当通过手动测试来验证，而非仅依赖任何一方的汇总数据。
在本地复现
似乎还没有人在真实硬件上针对不同量化级别发布过每秒token数的系统化测试数据。现有的资料大多只是重复发布时的基准测试表，或是某一个零散的速度数值。以下数据为单次运行结果，并非在不同种子值和批量大小下进行的系统性测试，因此仅可作为本地测量的参考，不能作为最终结论。
8K上下文下的内存占用情况：
Q4_K_M：约2.78 GBQ8_0：约3.7 GBBF16/FP16：约6.3 GB
根据独立来源的测试数据：在配备8 GB VRAM的RTX 3070 Ti显卡上，使用LM Studio的Q4量化设置且仅开启单流时，处理速度约为每秒144.23个token，这属于普通消费级显卡的性能水平。在高端硬件方面，Hacker News上有关该产品的讨论提到，在一台DGX Spark上可同时运行32个子代理，它们的总处理速度平均为每秒931个token，最高可达每秒1,364个token。后一个数值更符合该产品的设计目标——其并非旨在赢得单流延迟竞赛。GQA比率较低且占用资源少，正是为同时处理多个会话而设计的，32个代理共享一个节点正好契合这一需求。
最快复现相关功能的工具是Ollama：
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# Recommended flags for flash attention + quantized KV cache
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve &
# Run directly from Ollama's registry
ollama run openbmb/minicpm5-2b
将 Hugging Face 中的特定量化方案引入 llama.cpp 的方法：
huggingface-cli download openbmb/MiniCPM5-2B-GGUF \
MiniCPM5-2B-Q4_K_M.gguf \
--local-dir ./minicpm5-2b-gguf
为实现大规模的 OpenAI 兼容服务，vLLM：
pip install vllm
vllm serve openbmb/MiniCPM5-2B \
--max-model-len 131072 \
--dtype bfloat16 \
--port 8000
# Query it like any OpenAI chat completion endpoint
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model": "openbmb/MiniCPM5-2B", "messages": [{"role": "user", "content": "Write a quicksort in Rust"}]}'
不同任务的质量差异并非综合测试指标所能体现。MindStudio通过实际GGUF测试发现，Q8_0模型在独立编程以及可验证的数学和物理推理方面表现良好，但在针对特定数据结构的SQL调试任务和多语言翻译任务中表现极差，会给出看似有把握但实际上错误的答案。
这种看似有把握却错误的表现比任何准确率数值都更值得重视。明显的错误在审查时很容易被发现，但以“确定无疑”的方式出现的错误却会导致有缺陷的SQL迁移被投入实际使用。可复现性也存在另一个隐患：llama.cpp的表现会因其构建版本以及前端应用聊天模板的方式而大相径庭。当本地测试结果与他人不同之时，应在判定模型已发生变化之前先检查构建环境。
综合来看，本地测试结果与Terminal-Bench和SWE-bench Pro上的差异一致。对于有明确边界、可验证的任务，表现良好；而一旦需要对外部结构有精确了解或进行开放式多步骤判断，表现就会变得不稳定。多个独立来源都持续显示出这种规律，足以作为决策依据，从而决定了最终的抉择。
何时选择该模型
抛开基准测试的争议之后，仍然存在一个有用的决策框架，但它并非对模型优劣的最终判定。
非常适合的场景：
- 同时运行大量子智能体。GQA带来的内存效率，以及32个智能体在DGX Spark上每秒处理931个token的能力，才是关键指标，远比评分重要。
不适用于的情况：
- 自由形式或创意代码生成。在构建HTML页面或SVG图形等任务中，其测试结果不如专用编码模型，因为该模型的优势在于推理、数学运算、工具使用及函数调用能力。
- 特定模式的SQL调试及多语言翻译，这类任务中它常常会直接出错而无法妥善处理。
公平起见，先跳过那些片面的观点：认为对比所用的基准模型如Qwen2.5-2B或Gemma-2B已经过时，这类意见只属于次要评论，而非官方模型说明中的内容。官方说明中的对比是基于最新模型，包括Qwen3.5-2B、Gemma-4-E2B-it、granite-4.2-3B以及LFM2.5-2.6B。对此次发布的批评应针对其真正的弱点——智能体框架带来的性能差距，而非官方资料已经反驳的基准模型问题。
基准测试结果具有特定性
暂且不谈这个特定模型，更重要的教训才是值得保留的。Beats-4B的宣称虽属实，但范围有限。它的优势基于OpenBMB的数学模型以及单次编码测试套件AIME、LiveCodeBench和SWE-bench Verified，此外在版本修复后还得益于Artificial Analysis的汇总数据。但在Terminal-Bench和SWE-bench Pro测试中，Qwen3.5-4B的表现是其两到三倍，因此Beats-4B的优势便不复存在。以上所有说法同时都是正确的。
对于未来任何低于4B参数量的模型宣称，都应先让其通过至少一种类似实际工作的对抗性测试基准，如Terminal-Bench、SWE-bench Pro或类似测试，然后再用单次编码测试套件来预测该模型的表现。编写代码补丁与完成多轮任务是两种不同的技能，一个模型可能在前者上表现优异，而在后者上则表现平平。推特上发布的汇总数据从未说明具体是哪种能力得到了体现。
对于任何经过版本固定的聚合索引，无论来自人工分析还是其他来源，版本号都不是可选的元数据。它能够区分真正的差异与人为制造的差异。23对15的这一现象曾看似一场丑闻，持续了大约一天，直到方法说明显示这只是常规的版本升级而已。下一次基准测试引发的争议可能会以同样的方式得到解决，也未必如此，而唯一的办法就是亲自查看。
要点总结
就其规模而言，MiniCPM5-2B确实设计精良，拥有42层结构、8比1的GQA比率、131K的本地上下文数据、开放的训练数据，以及涵盖从DGX Spark到笔记本电脑等多种设备的八种配套测试工具。它在某些基准测试中表现良好而在其他测试中表现不佳的事实，并不能改变这些优点。基准测试只是有限的工具，每一种都只能衡量特定的方面，总分数永远无法反映全部情况。
在采用那些听起来好得令人难以置信的新一代小型模型之前，至少要复现一个对抗性智能体基准测试，并确认任何综合指数得分背后的具体版本。绝不能仅凭一个标题数字就决定采用某种架构。
相关阅读
- 在LangGraph中构建规划智能体：规划、执行、重新规划与报告 —— 一种用于金融研究的四节点LangGraph规划智能体：结构化规划、支持命名空间识别的工具注册表、重新规划限制以及可追踪的示例运行过程。