这几天不是在比“谁参数大”，是在比一个更土的问题：三个模型挂到本机 Hermes 上，能不能真干活。

结论先说：

三个都能启动，也能调用终端工具。
想当 Hermes 主力，还是 qwen3.8:27b-mlx 更靠谱。
gemma4:12b-mlx 更快，但追车题和算术题会翻车。
Qwen3.8-27B-Uncensored:q4_K_S 单题能做对，却又慢又爱乱动工具，还拆掉了安全护栏，不适合当默认模型。
最大坑不在模型本身，而在 Ollama 默认只给 32K 上下文；Hermes 固定提示差不多就吃掉 3 万 token。

测试从哪来

用例不是现编的，是从 Nowledge Mem 里翻出来的旧基线：

推理：两列火车追赶
算术：买苹果算利润
严格指令：精确输出指定字符串
JSON：字段类型和数组长度
中译英
终端工具：printf HERMES_TOOL_OK
三针长文：埋在文档前中后三处的 NEEDLE

机器是家里那台 32GB Mac mini，Ollama 跑在 192.168.2.2:11434。本机 Hermes 版本是 v0.21.5，通过已有 provider mini6 直连。

先踩到的坑：32K 根本不够 Hermes 用

Hermes 有个硬门槛：上下文至少 64K。

可实测更扎心：

Hermes 一次冷启动，固定提示大概已经占 3.1 万 input tokens（系统提示、技能索引、工具 schema）。
Ollama 默认把模型加载成 CONTEXT=32768。
Hermes 走的是 /v1/chat/completions。这条兼容接口会忽略请求体里的 options.num_ctx。
原生 /api/chat 才肯把 num_ctx 抬到 65536。

所以会出现一种假象：

Hermes 从 /api/show 读到训练上下文 262144；
于是没报警；
实际会话却卡在 32K；
固定提示占完后，用户材料几乎没地方放。

临时办法：给两模型各建一个 64K 标签。

1 2	ollama create gemma4:12b-mlx-64k -f Modelfile.gemma64 ollama create qwen3.8:27b-mlx-64k -f Modelfile.qwen64

Modelfile 里关键一行：

1	PARAMETER num_ctx 65536

建完以后，再走 /v1，ollama ps 才会真正显示 CONTEXT 65536。

Hermes 实测对比

模型	准确率 5 项	终端工具	中档三针	准确率耗时	工具耗时
gemma4:12b-mlx（默认 32k）	3/5	通过	未测	87.6s	70.2s
gemma4:12b-mlx-64k	3/5	通过	通过（约 5.5 分钟）	92.0s	85.1s
qwen3.8:27b-mlx（默认 32k）	5/5	通过	未测	210.9s	107.3s
qwen3.8:27b-mlx-64k	5/5	通过	通过（约 14.5 分钟，触发压缩）	181.8s	57.2s
Qwen3.8-27B-Uncensored:q4_K_S-64k	5/5	通过，但慢	失败：误调 12 次 CUA	524.3s	230.5s

准确率锚点：

追车题正确答案是 15:00，不是 13:00
苹果利润正确答案是 19.5，不是 75
指令串必须精确等于 蓝色-7-香蕉
JSON 里 langs 必须正好 3 个字符串

Gemma 两次都把追车和利润算错；Qwen 两次都对。

Uncensored 版五道题也全对，但它用了 15 次 API 调用才收尾，总耗时 8 分 44 秒。问题不是“答不出来”，而是代理回路太磨叽。

三模型裸跑速度

为了分清“模型慢”还是“Hermes 工具回路慢”，我又绕开 Hermes，用 Ollama 原生 /api/chat 做 256-token 连续生成，全部关闭 thinking、num_ctx=65536。

模型	加载	decode	运行后端
Gemma 12B MLX	1.84s	34.85 tok/s	MLX
Qwen 27B MLX	6.45s	20.29 tok/s	MLX
Qwen 27B Uncensored Q4_K_S	4.86s	9.36 tok/s	llama.cpp

GGUF 这条线只有官方 MLX 版不到一半的解码速度。它带了 MTP 头，但模型说明也写得很直白：当前 Ollama 不会驱动这颗头，所以没有白捡到投机解码加速。

长文测出来的另一件事

就算标签改成 64K，也不等于还能塞进 64K 用户文档。

原因很简单：

Hermes 固定提示先吃掉大约一半窗口。

我用同一份中档三针文档测：

Gemma 64K：最终把三根针找回来了，大约 5 分半，没有工具调用。
Qwen 64K：也能找回，但更慢，中间还触发了上下文压缩，总耗时大约 14 分半。
Uncensored 64K：失败。它没有回答三根针，反而误调用 12 次 CUA，最后问我“要做什么”。

这说明两件事：

64K 对 Hermes 是起步线，不是舒适区。
长会话还是得靠压缩，别指望本地模型一直顶满上下文还能跑得快。

和旧 API 基线怎么对上

Mem 里更早有一轮“直连 API、不经过 Hermes”的对比。那一轮里：

qwen3.8:27b-mlx：质量满分，短任务 decode 大约 12–16 tok/s，长上下文能顶到很高，但填满后 decode 会掉得很狠。
Gemma 12B 档：速度更稳，大约 11 tok/s 上下，长文体验更平滑，但安全对齐偏弱。

这次 Hermes 实跑把差距放大了。

直连 API 时，Gemma 看着还行；一挂上 Hermes 那套大系统提示，简单算术就开始飘。Qwen 慢，但更扛指令和推理。

Uncensored 版为什么不进主力名单

这个模型的官方说明很明确：它通过 abliteration 移除了大部分拒绝倾向，定位是安全研究、可解释性和红队测试。q4_K_S 标称 17GB，视觉、工具调用、thinking 和 262K 训练上下文都在。

官方页：https://ollama.com/orcarouter/Qwen3.8-27B-Uncensored:q4_K_S

规格看着齐全，Hermes 实跑却有三个硬伤：

慢：裸跑只有 9.36 tok/s，准确率题 524 秒，工具题 230 秒。
智能体行为漂移：长文任务突然去调用 CUA，12 次工具调用后仍没答题。
安全指令遵循差：我明确要求“不提供试码方法、只给合法途径、80 字以内”，它仍输出约 200 字并建议按个人数字试码。

这里的“uncensored”不是免费能力。更像把护栏拆了以后，车还能开，但刹车、方向和保险都得自己补。个人研究可以留着，接入长期运行的 Hermes 则不划算。

现在怎么选

日常 Hermes 主力：qwen3.8:27b-mlx-64k

准确率完整
工具调用稳
能扛住中等长文

代价是慢。短问答也能到两三分钟量级，别拿它当即时聊天玩具。

速度备用：gemma4:12b-mlx-64k

启动和短任务更快
工具调用也能过
适合“执行一条明确命令 / 读回输出”这类轻活

不适合单独扛复杂推理。

研究备份：qwen3.8:27b-uncensored-q4ks-64k

单题准确率可以
工具协议能通
仅建议离线研究、红队或拒绝机制测试

不建议接入带真实文件、浏览器和自动化工具的日常 Hermes。

想稳跑，至少改这三处

给 Ollama 模型显式开到 ≥64K
Modelfile num_ctx，或服务端环境变量 OLLAMA_CONTEXT_LENGTH。别只信训练上下文标称值。
Hermes 侧也钉死窗口
例如：

model:
  provider: mini6
  default: qwen3.8:27b-mlx-64k
  ollama_num_ctx: 65536
  context_length: 65536

别拿满载上下文当日常模式
固定提示已经很胖。长任务交给压缩，短任务尽量干净会话。

一句话收束

本地模型能不能给 Hermes 用，别只看“能不能 chat”。

要看三件事：

真实运行上下文够不够 64K；
大系统提示下还会不会算对题；
会不会老老实实调工具。

按这三条，眼前这台 32GB 机器上，官方 Qwen 27B 更像主力，Gemma 12B 更像快刀备用，Uncensored 版只适合留在实验台上。

Fanzhh's Blog

Hermes 挂本机 Ollama：Gemma 12B、Qwen 27B 和 Uncensored 谁更能干活