Edge AI：捣鼓一下 MiniCPM5-2B

———在 8G M2 MacBook Air 上实测 MiniCPM5-2B：从本地 Chat 到 Coding Agent

最近 MiniCPM5-2B 发布了，号称“目前最强的小参数模型之一”。在 AA 榜单中达到 25B 参数以下模型 SOTA，整体能力可以和 4B，甚至 9B 模型竞争，重点覆盖代码、数学、长文本、工具调用和 Agent 任务。可参考 Artificial Analysis 的介绍。

我之前也试过一些本地模型（Qwen3.5-4B、Gemma 4 E4B）。能运行是一回事，真正拿来做事又是另一回事：有的回答质量不稳定，有的速度可以但复杂指令容易跑偏，有的虽然支持工具调用，接到实际 Agent 应用里却不太顺手。所以这次我决定不只看 benchmark，而是直接在自己的设备上部署 MiniCPM5-2B，看看它能不能承担一点真实工作。

我的设备是一台 M2 MacBook Air，8GB 内存。在这个内存条件下，我依然选择了适合 Apple Silicon 的 MLX 4bit 版本，目标很明确：先把本地 Chat 跑起来，再进一步测试工具调用和 Agent 工作流。

部署测试代码见 MiniCPM-Deploy-Locally。

一、先把 MiniCPM5-2B 部署起来

仓库提供了多种模型格式。对 Mac 用户来说，MLX / 4bit 是比较自然的选择：它针对 Apple Silicon 优化，显存和内存压力相对小，也不需要为了跑一个 2B 模型切换到更重的推理栈。

我使用的是 MiniCPM5-2B-MLX 权重。核心启动命令大致如下：

mlx_lm.server \
  --model /path/to/MiniCPM \
  --host 127.0.0.1 \
  --port 8080 \
  --temp 1.0 \
  --top-p 0.95

整体感受比我之前试过的一些本地模型在速度和质量上更均衡：

首 token 和后续生成速度都比较舒服，日常对话不会有明显的“卡住感”；
普通知识问答、改写、解释代码这类任务，回答结构比较完整；
中文交互自然度不错，至少不像一些小模型那样经常出现句子没说完或上下文断掉的情况。

二、服务化和工具解析

接下来我想测试 Agent 能力，需要把工具调用接进来。MiniCPM5-2B 的工具调用输出不是原生 OpenAI JSON，而是 XML 风格，例如：

<function name="get_weather">
  <param name="city">北京</param>
</function>

官方推荐使用 SGLang，并通过 minicpm5 parser 把 XML 转换成 OpenAI 兼容的 tool_calls。

如果不想引入 SGLang，也可以在模型输出服务后面插一个很小的 XML parser 服务，完成同样的协议转换。实现参考 openai_tool_server.py。

服务分成两层：

服务	地址	作用
MLX backend	`127.0.0.1:8080`	加载本地 4bit 模型并生成文本
OpenAI proxy	`127.0.0.1:8000`	提供 OpenAI 兼容接口，并处理 MiniCPM 的 XML 工具调用

启动服务：

./start-openai-tool-server.sh

启动后可以先检查：

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/v1/models

这样，外部 Agent 不需要知道 MiniCPM 内部输出的是 XML，仍然可以按标准 OpenAI 接口读取 message.tool_calls。

三、Agent Harness 适配

有了 Chat 和 Tool Calling 之后，下一步就是找一个 Agent harness，把模型接进真实的文件和终端工作流。

我原本以为常用的 Desktop 工具都支持本地模型直接接入，并提供一些基础工具配合，但试了几个之后发现并不都能顺滑支持 tools / function calling：发送模型请求时不会声明支持的 tools。这个问题也可以通过接入 MCP 来探索解决方案。

Unsloth 有 Gemma 工具调用的 showcase，可以直接接入工具；但我直接加载 MiniCPM 模型调用工具时，模型会直接输出 tool name，推测是 Unsloth 自带的解析方式和 MiniCPM 的 XML 格式不匹配。

最后我选择了 pi-agent。它原生自带基础工具 read、edit、bash，也足够简洁，正好覆盖一个 Coding Agent 的最小闭环。这样看来，pi-agent 也比较适合作为测试系统的基础设施。

pi-agent 侧使用 OpenAI 兼容 provider，关键配置如下：

{
  "providers": {
    "minicpm-local": {
      "baseUrl": "http://127.0.0.1:8000/v1",
      "api": "openai-completions",
      "apiKey": "local",
      "models": [
        {
          "id": "minicpm5-2b-mlx",
          "name": "MiniCPM 5 2B MLX",
          "reasoning": false,
          "input": ["text"],
          "contextWindow": 131072,
          "maxTokens": 2048
        }
      ]
    }
  }
}

启动本地 API 后，再启动 pi-agent，选择 minicpm5-2b-mlx，就可以开始测试工具调用。

四、实测任务

我给 Agent 的任务是：

写出 Attention 注意力机制的数学公式和计算步骤，保存成 Markdown；再根据步骤写出 Python 代码，初始化变量并运行脚本。

这是一个很适合做基础 Agent 验证的 case，因为它同时包含了写文件、读文件、执行命令和根据结果继续调整几个环节。

这次完整会话中，Agent 一共完成了 15 次工具调用，涉及 bash、write、read 和 edit。中间脚本曾经出现过矩阵维度错误，Agent 根据 traceback 继续调整，最后重新运行成功，没有停在第一次报错的位置。

我更关注的是整个闭环是否成立，而不是让模型一次性生成一段看起来正确的代码。实际结果是：

Markdown 文件成功写入；
Python 脚本成功创建并执行；
遇到运行错误后，Agent 能继续调用工具进行修正；
最终能够返回执行结果和输出形状。

完整的 pi-agent 会话记录也一并提供，方便复现这次测试过程。

五、总结

实测下来，MiniCPM5-2B 在我有限的内存下完成了这次测试，在速度、能力和 Agent 表现之间达到了比较好的平衡，并且此次也开源了数据和训练信息，可以参考做更多探索。

现阶段端侧 AI 确实适合承担一些本地化任务：

本地日常问答和文字处理，至少比现在手机厂商的 AI 助手更好用；
简单、边界明确的代码修改，这里其实可以配合 Minis 继续探索；
对于一些垂直端侧场景，还可以自己尝试 fine-tune。

端侧模型的优势（隐私、延迟、个性化），再结合云端大模型的能力来互相补足，已经有很多落地尝试。相信随着端侧 AI 的不断发展，端侧或端云协同方案能更好地分担现有云端大模型服务的一部分任务，并带来更大的优势。