AI 实践：纪实
------OpenClaw + 本地 Ollama + Qwen3.5，在 Mac mini M6 24GB 上跑 4B / 9B
最近在 Mac mini M6、24GB 内存上做了一轮本地化 Agent 实测：
方案是 openclaw + 本地 Ollama + qwen3.5:4b-mlx / qwen3.5:9b-mlx 。
任务相同：让它搜索论文，然后整理一篇 5000～10000 字文章。
其中 -mlx 后缀表示模型为 Apple MLX 框架格式。MLX 是 Apple 为 Apple Silicon 设计的机器学习数组框架，利用统一内存架构，减少 CPU-GPU 之间的数据拷贝。换句话说，这类权重针对 Apple 芯片运行做了格式转换或量化优化，而不是原始 PyTorch 权重。
存在个人操作的原因，9b时间酌情减了20分钟。
1. 上下文配置说明
OpenClaw 侧配置如下：
json
{
"contextWindow": 262144,
"contextTokens": 131072,
"maxTokens": 16384
}需要明确的是，这三个是 OpenClaw 的配置项，不是 Ollama 原生参数：
contextWindow：OpenClaw 侧声明模型原生窗口大小，属于元数据，不直接决定实际内存占用。contextTokens：OpenClaw 侧实际输入预算，决定一次最多给模型塞多少上下文。对接 Ollama 时，它需要映射为 Ollama 的num_ctx才能生效。maxTokens：单次生成的最大输出 token 数，Ollama 侧通常对应num_predict或类似生成上限参数。
Ollama 本身控制上下文长度的核心参数是 num_ctx ，不是 contextWindow / contextTokens。如果 OpenClaw 没有把 contextTokens 正确映射到 num_ctx，就可能出现"配置看起来很大，实际没生效"的情况。两者最好保持一致，尤其是在硬件跑不动模型宣称的完整上下文时。
评论：这次
contextTokens设置到 131072，实际输入预算已经很大，对内存压力不小。Agent 场景里不只是模型本身，还有搜索、网页解析、工具调用、Node.js 进程等额外开销，实际占用会比单跑模型高不少。
2. qwen3.5:4b-mlx 实测
- 模型：qwen3.5:4b-mlx
- 任务：搜索论文，整理 5000～10000 字文章
- OpenClaw 侧配置：
contextWindow 262144、contextTokens 131072、maxTokens 16384 - 内存占用：Ollama 进程运行时约 5GB，峰值约 9.5GB；Node.js 进程约 1.3GB
- 用时：35 分钟
体感：24GB 内存下跑 4B 比较从容，流程能完整跑通。但输出更像"结构完整的草稿"，能搭架子，内容密度和可信度一般。
评论：4B 的优势是轻、能跑起来，适合验证 Agent 流程。但让它独立完成长篇论文综述，基本只能算草稿机。
3. qwen3.5:9b-mlx 实测
- 模型：qwen3.5:9b-mlx
- 任务：搜索论文，整理 5000～10000 字文章
- OpenClaw 侧配置：
contextWindow 262144、contextTokens 131072、maxTokens 16384 - 内存占用：Ollama 进程运行时约 10GB，峰值约 16GB；Node.js 进程约 1.3GB
- 用时：62 分钟
体感：9B 的表达和技术细节比 4B 好一些，但内存峰值已经到 16GB，用时也几乎翻倍。在 24GB 机器上，这个占用不算宽裕，系统、缓存、工具再一挤，就接近上限。
评论：9B 比 4B 有提升，但边际收益不算大。时间多花近一倍，内存峰值多 6.5GB，换来的更多是"更像样一点的草稿"，还谈不上质变。24GB 跑 9B 长上下文 Agent，已经接近舒适区边缘。
4. 耗时与内存对比
| 模型 | Ollama 进程运行时 | 峰值内存 | Node.js 占用 | 用时 |
|---|---|---|---|---|
| 4B | 约 5GB | 约 9.5GB | 约 1.3GB | 35 分钟 |
| 9B | 约 10GB | 约 16GB | 约 1.3GB | 62 分钟 |
评论：4B 和 9B 的 Node.js 占用差不多，差距主要在模型侧。这里说的 Ollama 内存，通常包括模型权重、KV Cache 和运行时开销；实际占用会随上下文长度、并发和缓存情况变化。9B 峰值 16GB 对 24GB 机器来说已经比较紧张。如果同时开浏览器、IDE、同步盘，体验会明显下降。
5. 最后总结
这两个模型写个草稿也许还算可以，一次到位基本不可能。
要真正可交付，还得用 API。
本地跑模型，估计得用 30B 以上的模型；要达到可实战应用，硬件投入太大。个人投入不合适，发烧友除外。
本地模型适合什么？
- 隐私敏感、离线场景：数据不出本机。
- 轻量任务：摘要、分类、抽取、改写、格式整理、初筛。
- Agent 入门：验证工具调用、RAG、自动化流程。
- 低成本批处理：不追求高准确率，可人工复核。
- 本地草稿：先生成框架，再由大模型或人工精修。
复杂任务还得上大模型
- 5000～10000 字深度综述
- 严谨引用与事实核验
- 数学推导、技术细节
- 复杂多步 Agent
- 最新知识、生产级交付
这些任务，现阶段还是 API 大模型更现实。更合理的方案是混合架构：
本地小模型做预处理、隐私处理和初筛，云端大模型做推理、写作、审校和引用核验。
关于硬件甜点区
24GB 统一内存跑 4B 比较舒服，跑 9B 长上下文 Agent 已经接近上限。
如果本地要上 30B+ 才谈得上可实战，通常需要 64GB / 128GB 统一内存或多卡，个人性价比很低。
也许我的硬件限制，确实无法达到本地部署的甜点区。
不是本地模型没价值，而是 "本地 + 长上下文 + Agent + 长文写作" 这个组合太吃资源。
6. 评分对比
| 维度 | 9b | 4b |
|---|---|---|
| 结构完整性 | 9 | 9 |
| 覆盖范围 | 9 | 9 |
| Agent 入门价值 | 8 | 7 |
| LLM Agent | 6 | 5 |
| 强化学习 | 5 | 4 |
| MARL | 5 | 4 |
| 数学准确性 | 4 | 3 |
| 技术准确性 | 5 | 3 |
| 引用可信度 | 2 | 2 |
| 工程实践价值 | 6 | 4 |
| 学术综述价值 | 3 | 2 |
| 综合 | 5.5～6 | 4～5 |
解读：结构和覆盖面都能到 9，说明小模型"搭框架"的能力不差；但引用可信度只有 2，数学准确性 3～4，技术准确性 3～5，说明它更像"会写综述腔的草稿机"，不是"可交付的学术作者"。9B 比 4B 有提升，但引用可信度没有拉开差距，说明检索和引用核验不能交给小模型自己完成。
一句话结论
本地 4B / 9B 适合做 Agent 入门、隐私预处理、摘要分类和草稿；
复杂长文、严谨引用、多步推理，还是得上 API 大模型。
我的 24GB Mac mini 能玩本地 Agent，但离"本地可实战"的甜点区，还有一段距离。