最近一直在搭建本地 AI 工作流（数字员工 / MCP / Agent 自动化），从最初盲目追求大模型，到最终回归理性方案，中间踩了不少雷。本文把经验和教训整理出来，打算入手的读者可以留意避坑。
一、第一坑：以为有 32B，其实根本没有
刚开始选模型时，目标很明确：Qwen3.5-32B。因为印象里 Qwen3 系列确实有这个参数量级。
结果到官网一查，根本没有这个型号。后来才搞清楚：官方 3.5 系列的参数量分档如下：
9B / 27B / 35B（A3B）/ 122B / 397B所谓的“32B”，实际上是指：
Qwen3.5-35B-A3B ≈ 32B 能力原因在于：
- MoE 架构（稀疏激活）
- 实际参与计算的参数量约在 30B 以上
结论很直接：别再花时间找 32B 了，直接认准 35B-A3B 就行。
二、第二坑：下载一个模型要 5 天
第一次下载 35B 的时候：
- 文件大小 22GB
- 下载速度 48KB/s
- 预计完成时间 128 小时
当时直接怀疑人生。问题本质不在模型本身，而在于下载链路。
解决办法其实很简单：直接用 aria2c -x 16 -s 16 做多线程下载，或者换用 hf-mirror、LM Studio 内置下载 这类工具。
速度从 KB/s 直接跳到 MB/s，这才是正常体验。
三、第三坑：下载了“假 Qwen”
一开始下载的模型名字是：Qwen3.5-14B-A3B-Claude-Opus-Reasoning-Distilled。名字听起来很猛，实际上是一个社区魔改模型。
问题非常明显：
- 输出不稳定
- JSON 结构容易乱
- 风格偏向 Claude
- 指令跟随不靠谱
如果模型名里包含 distilled / opus / gpt / merge / uncensored 这类关键词，基本可以判断是二创模型，使用需谨慎。
正确的选择：认准官方 GGUF 版本。
四、第四坑：盲目追大模型（35B）
很多人一开始目标非常明确：必须上 35B。
实际跑起来的表现是：
| 指标 | 表现 |
|---|---|
| 内存 | 吃满 |
| 速度 | 很慢 |
| 体验 | 卡顿 |
本地模型部署，不是越大越好，而是要匹配整个系统的运行形态。
五、最终结论：换成 9B
后来换成了 Qwen3.5-9B Q4_K_M（6.5GB）。这个量级的模型，实际效果非常可观：
- Agent 执行
- JSON 输出
- 代码生成（中等复杂度）
- 流程编排
当然，9B 也有短板：
- 长链复杂推理
- 多表复杂分析
- 高精度工程代码
现在的认知已经变成：模型不是单点，而是系统架构的一部分。
推荐的分层搭配方案：
主模型（常驻）：Qwen3.5-9B
复杂任务：Qwen3.5-14B
高阶推理：Qwen3.5-35B-A3B（按需调用）简单总结就是：
9B = 跑系统
14B = 做任务
35B = 解难题如果你正在做 Agent / MCP / 自动化系统，本地部署环境是 Mac 或 32GB 内存，并且需要长期稳定运行，最优路径是：先用 9B 跑通整个系统，再引入 14B 做增强，最后按需接入 35B。稳步推进，远比一步到位更有效。
