一、背景：为什么要折腾本地部署

Hermes Agent 是我日常编程的主力工具——代码重构、仿真调试、博客写作都靠它。免费的云端模型时好时坏，一个自然的问题浮现：能不能把模型跑在自己电脑上，彻底告别 API 限流和网络波动？

这个想法很诱人。数据不出本地、零延迟、零费用——听起来完美。于是我在一台 WSL2 环境下启动了本地部署实验。

机器配置：Z790 + i9-13900KF + RTX 4090 24GB，内存 单条 16GB DDR5-4800（单通道未升级）。WSL2 分配 8GB。

选取的路线是当前最成熟的本地推理方案：Ollama + DeepSeek-R1。

二、第一次尝试：Ollama + DeepSeek-R1 本地运行

Ollama 的安装非常顺畅：

1
2
3
curl -fsSL https://ollama.com/install.sh | sh
ollama pull deepseek-r1:8b
ollama serve

模型拉下来大约 4.9GB，8B 参数版本在 RTX 4090 上加载毫无压力。ollama run deepseek-r1:8b 启动后，对话响应速度很快，中文质量也不错。一切看起来都很顺利。

问题出现在接入 Hermes Agent 的时候。

三、致命问题：Function Calling 不支持

Hermes Agent 的核心能力是工具调用（Tool Calling / Function Calling）——执行终端命令、浏览器抓取、文件读写、代码执行。Agent 需要根据用户意图自主决定调用哪个工具，这依赖模型的 Function Calling 能力。

DeepSeek-R1 是推理型模型（reasoning model），它擅长长链思维推理，但不输出标准化的 function call JSON。本质上，R1 是一个纯文本生成模型，没有经过工具调用格式的训练或对齐。

这就导致：

  • Hermes 能连接 Ollama 服务，能收到模型回复
  • 但模型从不触发工具调用，Agent 无法做任何实际操作
  • 问”帮我写个 Hello World”→ 能写出代码文本，但不会调 write_file
  • 问”帮我搜一下最新论文”→ 能讨论论文，但不会调 web_search

没有 Function Calling 的 Hermes，等于没有手和脚的人。

四、硬件瓶颈：16GB 内存的现实

换了思路：不用 R1，换一个支持 Function Calling 的模型行不行？

Ollama 生态里支持 function calling 的选择不少：Qwen2.5、Llama 3、Mistral 系列等。但这里遇到第二个问题：内存容量。

  • 16GB 单通道 DDR5，WSL2 分走 8GB，系统和其他应用占一截
  • 7B 模型（Qwen2.5 7B）尚可勉强运行，但 14B 级别直接 OOM
  • 支持 function calling 且效果好的模型（Qwen2.5 14B、Llama 3 8B instruct）不是跑不动就是效果打折

更深层的问题是 function calling + reasoning 的模型组合。想要中文好、推理强、又能调用工具的本地模型，在 2026 年 5 月这个时间点，16GB 内存实在捉襟见肘。

升级到 32GB 双通道的计划有，但还没执行。于是本地方案暂时告一段落。

五、转向云端：DeepSeek V4 Pro

本地跑不通，就回头看云端方案。DeepSeek 在 2026 年推出了 V4 Pro 型号，对比之前用过的版本有几个关键改进：

特性 DeepSeek-R1（本地） DeepSeek V4 Pro（云端）
Function Calling ❌ 不支持 ✅ 完整支持
上下文窗口 128K 128K
推理速度 本地 RTX 4090 云端 API
硬件要求 GPU 24GB + 内存 ≥32GB 无要求
成本 电费 ~0.0002/次查询∣0.0002/次查询 |
接入方式： 
1
2
3
# Hermes config 切换为 deepseek provider
hermes config set provider deepseek
hermes config set model deepseek-v4-pro

无需本地 GPU 资源，不需要管理模型文件，不需要折腾量化。一个配置切换，全部搞定。

六、云端实测：性能与成本

接入 DeepSeek V4 Pro 后做了几轮实测：

响应速度：

任务类型 响应时间
简单对话（”帮我看下 git status”） < 1s
中等任务（代码阅读 + 分析） 1-3s
复杂任务（多工具调用链） 3-8s

思考阶段（thinking）通常 1.6s 以内，工具调用链执行取决于任务复杂度，而非模型速度。对中国大陆网络来说，API 延迟在可接受范围内。

成本：

单次对话约 **0.0002∗∗（≈¥0.0015），一天200次查询约¥0.3。即便是重度使用，月成本在¥10−30量级——远低于升级硬件的电费和维护成本。0.0002**（≈ ¥0.0015），一天 200 次查询约 ¥0.3。即便是重度使用，月成本在 ¥10-30 量级——远低于升级硬件的电费和维护成本。
Function Calling 实测：

这是关键指标。V4 Pro 的 tool calling 非常稳定：

  • 多工具并行调用：✅ 正常（如同时 search + read_file）
  • 工具返回值理解：✅ 准确
  • 链式调用：✅ 正常（先读文件→发现需要修改→调 patch）
  • 异常处理：✅ 会主动重试（连接超时等场景）

七、两种方案对比

维度 本地 Ollama + R1 云端 DeepSeek V4 Pro
Function Calling ❌ 不支持 ✅ 完整
硬件要求 GPU 24GB + 内存 ≥32GB 无要求
部署难度 中等 极低（改一行配置）
网络依赖 无 需要
数据隐私 完全本地 云端传输
维护成本 更新模型、管理磁盘 零维护
月成本 电费 + 硬件折旧 ~¥10-30
模型升级 手动 pull API 自动最新

八、总结

本地部署 AI 编程助手，真正的瓶颈不是显卡，而是 Function Calling 能力 + 内存容量。

几点心得：

  1. Function Calling 是硬门槛。 推理型模型（R1）虽然逻辑强，但如果不输出标准化的工具调用，Agent 框架用不了。选本地模型时要先确认是否支持 tool calling 格式。

  2. 16GB 内存是死穴。 能跑 function calling 的 7B 模型效果一般，14B 又爆内存。32GB 双通道是本地 Agent 方案的底线配置。

  3. 云端方案在 2026 年已经很成熟。 DeepSeek V4 Pro 的价格低到可以忽略（¥0.0015/次），function calling 稳定，延迟可接受。在硬件没升级之前，这是最务实的路线。

  4. 不要为了”本地运行”而运行。 如果模型跑得了但工具链不通，等于白费力气。先确认端到端可用性，再决定要不要本地化。

未来等内存升级到 32GB 双通道后，可能会再次评估本地方案——比如 Qwen2.5 14B 或 Llama 4 的小体量版本，前提是它们确实支持 function calling 且 Hermes 能稳定对接。

在那之前，DeepSeek V4 Pro 云端方案，足矣。