为什么我们要本地部署 35B 模型

2026 年 4 月，SFD 实验室做了一个决定：把核心推理任务从云端迁回本地。不是不信任 API，而是算一笔账——每天 9 篇日更 + 15 个 Agent 协作，月调用量 50 万 +，云端成本 vs 两台 Mac Studio 的电费，本地部署 18 个月回本。

更重要的是：数据不出域。用户对话、技能配置、记忆碎片，这些敏感数据没必要送给第三方。

硬件选型：为什么是 Mac Studio

我们最终选了两台 Mac Studio M3 Ultra：

• MS01：96GB 统一内存，主推理节点
• MS02：96GB 统一内存，备用 + 编码专用

为什么不买 H100？简单：显存太贵。80GB H100 单卡 25 万，96GB Mac Studio 整机 3 万。Ollama 在 Apple Silicon 上的优化已经非常成熟，Qwen3.5 35B Q8 量化后只需 38GB 内存，MS01 完全吃得下。

Ollama 部署全流程

Step 1：安装 Ollama

brew install ollama
# macOS 需要手动启动服务
ollama serve

注意：macOS 上 Ollama 不会自动启动，需要手动运行 ollama serve 或者用 launchctl 配置开机自启。

Step 2：拉取模型

# MS01 拉 Qwen3.5 35B Q8 量化版
ollama pull qwen3.5:35b-q8_0

MS02 拉 Qwen3-Coder-Next（代码专用）
ollama pull qwen3-coder-next:latest

这里有个坑：Ollama 官方的 qwen3-coder-next 只有 latest（Q4_K_M）和 q8_0 两个 tag，没有 Q6。我们实测 Q4_K_M 在代码任务上表现足够好，内存只需 54GB，果断选 Q4。

量化版本选择指南

Qwen3.5 35B 官方提供多种量化：

量化	体积	内存	精度损失
Q8_0	38GB	~42GB	几乎无
Q6_K	30GB	~34GB	轻微
Q4_K_M	23GB	~27GB	可接受

我们的选择逻辑：推理节点（MS01）用 Q8_0 保精度，编码节点（MS02）用 Q4_K_M 省内存。实测 Q8 vs Q4 在中文写作任务上差异小于 3%，但在代码生成上 Q4 偶尔会漏掉类型注解。

踩坑记录

坑 1：模型拉取中断

38GB 模型拉取需要 20-30 分钟，网络波动容易中断。Ollama 支持断点续传，但需要确保 ~/.ollama/models 目录权限正确：

sudo chown -R $(whoami) ~/.ollama/models

坑 2：内存不足 OOM

第一次在 MS01 上跑 Q8 版本，系统直接卡死。排查发现 macOS 的内存压缩机制和 Ollama 冲突。解决方案：限制 Ollama 最大内存：

launchctl setenv OLLAMA_MAX_VRAM 40000000000

坑 3：并发请求排队

单模型实例同一时间只能处理一个请求。15 个 Agent 同时调用会排队。我们的解决方案：MS01 跑两个实例，不同端口：

# 实例 1：端口 11434，主推理
OLLAMA_MODELS=/opt/ollama/models1 ollama serve

实例 2：端口 11435，编码专用
OLLAMA_MODELS=/opt/ollama/models2 ollama serve --port 11435

性能实测

部署完成后做了基准测试（prompt 长度 1000 tokens，输出 500 tokens）：

• Q8_0 (MS01)：首 token 1.2s，生成速度 28 tokens/s
• Q4_K_M (MS02)：首 token 0.8s，生成速度 35 tokens/s

结论：量化版本反而更快（内存带宽压力小），但精度略降。对于日更写作任务，Q4 完全够用；对于技能审计、代码审查等高精度场景，Q8 更稳。

SFD 编者注

这套双机集群已经跑了 2 周，稳定性超出预期。每天处理 50+ 次推理请求，故障 0 次。唯一的问题是电费——两台 Mac Studio 满载约 600W，24 小时运行月电费约 300 元新币，但相比云端 API 每月 2000+ 新币的成本，还是香太多了。

下一步计划：研究 Ollama 的分布式推理，看看能不能把 72B 模型拆到两台机器上跑。有经验的欢迎在评论区交流 🔥