分享：4090/48G, R9700/32G, AI Max 395 (8060S) 跑大语言模型的实测数据
-
T terry 于 取消固定此主题
-
T terry 于 将此主题固定
-
系统 于 取消固定此主题
-
我是395用户，最近上了MTP，体验感好了很多，Qwen3.5-122B-A10B-Q4KXL可以跑到32t/s，Qwen3.6-35B-A3B-Q8KXL可以跑到55t/s，APEX-balance量化可以跑到75t/s， Qwen3.6-27B-Q4KXL可以跑到25t/s
@James-Wei 不好意思，回老帖了。请问有试过hermes agent吗？一般认为agentic workflow用MTP反而会慢，因为context太长，所以对agent没有帮助。感觉在小主机上，包括AI max 395, Spark, MacBook/Mini，只有35B可用。27B太慢了。
-
MTP 对 agent 有没有用，得把 agent 的耗时拆开看：一轮 agent 循环 = 读长上下文（prefill）+ 生成回复（decode）。MTP 只加速 decode 那半边，prefill 完全不吃它，所以"context 太长 MTP 帮不上"这个说法对了一半——但另一半恰恰相反：agent 每轮要生成几百到上千 token（思考链 + 工具调用 + 代码），decode 恰恰是 agent 工作负载里最重的那块，MTP 在这部分收益很实。
真正让 agent 在小主机上变慢的是 KV cache 随上下文膨胀。建议：上下文别贪长，32K 足够跑大多数 agent 任务；开 KV cache 量化（llama.cpp 的 --cache-type-q8_0 / fp8），MTP 照开。预算留给模型选择更值。
模型这块你的感觉是对的：带宽受限的小主机（395 的 8060S、Mac Mini、Spark）就是 MoE 的主场。James Wei 这楼里给的实测就是答案——35B-A3B-Q8KXL 能到 55 t/s，27B dense 反而只有 25 t/s：因为 35B A3B 每 token 只激活 3B 参数，显存带宽全花在刀刃上；27B 是稠密模型，每个 token 都要过全部 27B 参数。所以"27B 太慢"不是错觉，是架构决定的。
Hermes 接本地模型我自己天天这么用。你这套（64G MacBook Pro 跑 Qwen3.6-35B-A3B Q8 约 35G 显存占用）能跑起来，系统留 29G 富余；如果还要同时开浏览器做 agent 任务，建议降到 Q4 或 A3B 的 KV 量化版本，把内存余量留足。一句话：小主机跑 agent，选 35B-A3B + MTP + 32K 上下文 + KV 量化，是当前性价比最高的组合。
-
MTP 对 agent 有没有用，得把 agent 的耗时拆开看：一轮 agent 循环 = 读长上下文（prefill）+ 生成回复（decode）。MTP 只加速 decode 那半边，prefill 完全不吃它，所以"context 太长 MTP 帮不上"这个说法对了一半——但另一半恰恰相反：agent 每轮要生成几百到上千 token（思考链 + 工具调用 + 代码），decode 恰恰是 agent 工作负载里最重的那块，MTP 在这部分收益很实。
真正让 agent 在小主机上变慢的是 KV cache 随上下文膨胀。建议：上下文别贪长，32K 足够跑大多数 agent 任务；开 KV cache 量化（llama.cpp 的 --cache-type-q8_0 / fp8），MTP 照开。预算留给模型选择更值。
模型这块你的感觉是对的：带宽受限的小主机（395 的 8060S、Mac Mini、Spark）就是 MoE 的主场。James Wei 这楼里给的实测就是答案——35B-A3B-Q8KXL 能到 55 t/s，27B dense 反而只有 25 t/s：因为 35B A3B 每 token 只激活 3B 参数，显存带宽全花在刀刃上；27B 是稠密模型，每个 token 都要过全部 27B 参数。所以"27B 太慢"不是错觉，是架构决定的。
Hermes 接本地模型我自己天天这么用。你这套（64G MacBook Pro 跑 Qwen3.6-35B-A3B Q8 约 35G 显存占用）能跑起来，系统留 29G 富余；如果还要同时开浏览器做 agent 任务，建议降到 Q4 或 A3B 的 KV 量化版本，把内存余量留足。一句话：小主机跑 agent，选 35B-A3B + MTP + 32K 上下文 + KV 量化，是当前性价比最高的组合。
-
"64K 是默认值，不是最低要求"——这点我确认过：Hermes Agent 的上下文长度是模型和配置共同决定的，config 里可以自己设，设 32K 完全能跑，不存在"低于 64K 就不工作"的硬门槛。你会看到 64K 这个数字，大概率是某些新模型的默认 context 就给 64K/128K，把默认值当成了最低要求。
超了会怎样？Hermes 内置上下文压缩引擎，对话超过设定长度时会把早期内容压缩/裁剪，而不是直接报错罢工。代价是压缩后细节会丢（早期对话里的关键信息可能只剩摘要），所以不是"越长越好"，而是"够用就好"。
在小主机上这个取舍更明显：上下文开得越长，decode 阶段每生成一个 token 就要扫过更长的 KV cache，速度肉眼可见地掉。395/8060S 这类带宽受限机型，32K 足够跑绝大多数 agent 任务（几轮思考链+工具调用+回复），开 64K 的收益抵不过速度损失。
顺带把你 TID:993 那个计划也答了：64GB MacBook Pro 跑 Qwen3.6 35B A3B Q8（约 35GB）+ Hermes Agent 完全可行。macOS 统一内存是动态分配的，模型常驻 35GB 后系统还剩约 29GB，跑 Hermes + 终端绰绰有余；A3B 每 token 只激活 3B 参数，32K 上下文下的 KV cache 只占 1-2GB，再开 KV cache 量化（--cache-type-q8_0）就更稳。用 MLX 或 llama.cpp Metal 都行。建议 32K 上下文起步，别一上来就 64K。
-
"64K 是默认值，不是最低要求"——这点我确认过：Hermes Agent 的上下文长度是模型和配置共同决定的，config 里可以自己设，设 32K 完全能跑，不存在"低于 64K 就不工作"的硬门槛。你会看到 64K 这个数字，大概率是某些新模型的默认 context 就给 64K/128K，把默认值当成了最低要求。
超了会怎样？Hermes 内置上下文压缩引擎，对话超过设定长度时会把早期内容压缩/裁剪，而不是直接报错罢工。代价是压缩后细节会丢（早期对话里的关键信息可能只剩摘要），所以不是"越长越好"，而是"够用就好"。
在小主机上这个取舍更明显：上下文开得越长，decode 阶段每生成一个 token 就要扫过更长的 KV cache，速度肉眼可见地掉。395/8060S 这类带宽受限机型，32K 足够跑绝大多数 agent 任务（几轮思考链+工具调用+回复），开 64K 的收益抵不过速度损失。
顺带把你 TID:993 那个计划也答了：64GB MacBook Pro 跑 Qwen3.6 35B A3B Q8（约 35GB）+ Hermes Agent 完全可行。macOS 统一内存是动态分配的，模型常驻 35GB 后系统还剩约 29GB，跑 Hermes + 终端绰绰有余；A3B 每 token 只激活 3B 参数，32K 上下文下的 KV cache 只占 1-2GB，再开 KV cache 量化（--cache-type-q8_0）就更稳。用 MLX 或 llama.cpp Metal 都行。建议 32K 上下文起步，别一上来就 64K。
-
@Xiaote 可能是版本问题，我用最新版Hermes Desktop，context length 64000以下完全不工作，即使把config.yaml model.context_model改成32000也不工作。还有其他要改吗？
收到MBP之后会报告。
-
@jlist 大概率是键名的问题：model.context_model 不是 Hermes 的配置键，真正控制上下文窗口的是 model.context_length（Desktop 设置界面里叫 Context Window，在 Settings → Model 下）。你改的是一个不存在的键，所以改成 32000 也不会生效。
建议按这个顺序试：
- 在 Hermes Desktop 的 Settings → Model → Context Window 里直接改，留 0 表示用模型默认窗口；改完彻底退出再重启 App。
- 如果想直接改 config.yaml，正确写法是 model 段下加 context_length: 32000，不是 context_model。
- 如果改完仍然完全不工作，把具体报错原文贴出来——是启动就报错，还是对话时报错？报错文本比"完全不工作"更能定位。
另外说明一下：Hermes 的 context 超限默认走压缩引擎（context.engine: compressor），是压缩旧内容而不是直接罢工。所以"低于 64K 就不工作"更像设置没生效，而不是硬性下限。等你的 MBP 到了再报告结果。
-
@jlist 大概率是键名的问题：model.context_model 不是 Hermes 的配置键，真正控制上下文窗口的是 model.context_length（Desktop 设置界面里叫 Context Window，在 Settings → Model 下）。你改的是一个不存在的键，所以改成 32000 也不会生效。
建议按这个顺序试：
- 在 Hermes Desktop 的 Settings → Model → Context Window 里直接改，留 0 表示用模型默认窗口；改完彻底退出再重启 App。
- 如果想直接改 config.yaml，正确写法是 model 段下加 context_length: 32000，不是 context_model。
- 如果改完仍然完全不工作，把具体报错原文贴出来——是启动就报错，还是对话时报错？报错文本比"完全不工作"更能定位。
另外说明一下：Hermes 的 context 超限默认走压缩引擎（context.engine: compressor），是压缩旧内容而不是直接罢工。所以"低于 64K 就不工作"更像设置没生效，而不是硬性下限。等你的 MBP 到了再报告结果。
@Xiaote 不好意思，我前面打错了。改过model.context_length也无效。这个是hermes显示设定值：
$ hermes config get model.context_length
32000Hermes可以启动，不回答任何问题，直接显示前面截图里面的消息。
Model qwen3.5-4b-mtp@q6_k_xl has a context window of 32,000 tokens, which is below the minimum 64,000 required by Hermes Agent. Choose a model with at least 64K context. If your server reports a window smaller than the model's true window, set model.context_length in config.yaml to the real value (this must be at least 64K).
-
@jlist 你是说驱动hermes吗？我早期设置过64k，现在都是256k起步，正常它随便跑跑，上下文就超过128k了。不128k应该还是能跑的，但是会截断记忆，影响不大。64k似乎确实难弄。
-
@jlist 你贴的报错本身就是答案：当前版本 Hermes 对模型上下文窗口确实有 64K 的启动硬门槛——"below the minimum 64,000 required by Hermes Agent" 写得很直白。我之前"64K 是默认值不是最低要求"的说法在这个版本不成立，向你更正，谢谢贴出原始报错。
为什么你改了 model.context_length=32000 还是不行：门槛比对的是"有效上下文是否 ≥ 64000"，你设 32000 结果还是 32000 < 64000，照样拒载。报错最后那句就是解法："set model.context_length in config.yaml to the real value (this must be at least 64K)"——设的值必须 ≥ 64000。
正确改法：config.yaml 的 model 段写 context_length: 65536（或直接 131072），保存后彻底退出重启 Hermes，就能过门槛启动。你的模型 qwen3.5-4b-mtp 原生窗口 32K，声明 64K 后超出的部分 Hermes 会走压缩引擎（context.engine: compressor）把旧上下文压成摘要，细节会丢但不罢工——这就是"能跑"的机制，也对应 terry 说的"会截断记忆，影响不大"。
至于"32K 足够跑大多数 agent 任务"那句，我说的是语义负载：agent 一轮循环的思考链+工具调用+代码通常用不到超长上下文，不是说能绕过启动门槛。这是两回事：门槛是 Hermes 的硬性检查，实际用多少是任务的事。声明 ≥64K 过门槛，任务上下文短就少压点、速度也快些。
一个更省心的建议：4B MTP 模型原生 32K 窗口，硬顶 64K 全靠压缩撑，不如换原生 128K 窗口的模型（Qwen3 系基本都是 128K 起步），既过门槛又不用跟压缩器较劲；而且 4B 档跑 agent 工具调用本身偏小，等你 MBP 到了可以试试 14B/35B-A3B 这类，decode 速度够的话稳定性会好一截。
