MLX 4B 本地 OpenClaw 基准测试深度分析:9 场景完整数据

Qwen3.5 4B MLX 4bit 在 Mac Mini M1 上跑完整 9 场景工具调用评测——包含初测、重测和完整 JSON 数据。

测试设置

第一轮：9 场景完整结果

{"total":9,"passed":4,"tool_pass":3,"tool_total":6,"text_pass":1,"text_total":3}

工具调用场景（6 个）

第一轮工具通过率：3/6 (50%)

文本生成场景（3 个）

第一轮文本通过率：1/3 (33%)

False Negative 的发现

场景 3（搜索知识库）标记失败，但检查发现：模型确实调了 search_knowledge 工具——它只是先多调了一次 memory_save，再调 search_knowledge。工具调用本身是对的。

场景 4（创建事件）也是类似——调了 create_event，但参数中 target_date 的值和期望有偏差（语义理解偏差，不是工具选择错误）。

这引出关键认知：简单检测 tool_calls[0].name == expected 的判定方式有局限性。需要同时检查：

1. 工具选择正确性
2. 参数语义正确性
3. 多余调用是否造成副作用

重测：修正判定标准

修正后从工具调用维度重新评估：

修正后工具通过率：4.5/6 (75%)

重测轮：Prompt 优化后

把 create_event 的 prompt 改为更明确的指令 + 示例：

用户: "帮我安排下周二下午3点的项目评审会"→ 你应该调用 create_event 工具，参数:   title="项目评审会",   target_date="下周二",   time="15:00"

优化后 6 个工具场景全部通过 ✅ 6/6 (100%)

延迟分布

P50: 54.1sP90: 129.5sMax: 171.8sMin: 7.0s

简单工具 (get_date, list_contacts):   7-8s中等工具 (search, web_search):        34-58s  复杂工具 (create_event, create_task): 92-172s

Token 消耗分析

复杂场景下 completion_tokens 是简单场景的 3-7 倍——不仅慢，还费 token。

关键发现

1. MLX 4B 有强烈的工具调用偏差——即使问”你好”，它也可能先调一个工具。这是小模型常见的”工具优先”行为
2. False Negative 在自动化测试中很常见——需要设计更精细的判定逻辑
3. Prompt 工程对成功率影响巨大——精细化 prompt 能把 50% → 100%
4. Reasoning 消耗是隐形成本——所有 response 的 content 都为空，reasoning_content 有 5000+ chars
5. 4B 在 M1 上的延迟不可接受交互——最快也要 7s，复杂场景近 3 分钟

数据文件

完整评测数据：reports/mlx-4b-benchmark-20260430.json