分享：4090/48G, R9700/32G, AI Max 395 (8060S) 跑大语言模型的实测数据
-
T terry 于 将此主题固定
-
我的装备看这个帖子：
https://lcz.me/topic/117/小小秀一下我的ai-rig/12这个帖子主要是分享一下用这套装备能怎么跑大模型（LLM），有哪些组合，能大概跑出来什么样的效果等等。
GPU
- RTX 4090 48G （独立显卡）
- AMD Radeon AI PRO R9700 32G （独立显卡）
- AMD Radeon 8060S Graphics 128G（AI MAX 395的集成显卡）
各自的特点：
- AI Max 395：价格14000RMB左右，集成显卡代号8060S，共享内存128G，内存最大，能通吃许多大模型， 但算力最低，内存带宽260G左右，也是最低，所以跑大模型的速度最慢；
- 4090 48G：价格30000RMB左右，最贵，最快，显存带宽1TB左右，生态最好，vLLM可以跑得飞起，但48G显存吃不下超大模型，但跑27B模型或者30B模型，可以把上下文放256K，非常爽；
- R9700 32G：价格11000RMB左右，32G显存，速度尚可，性价比高，但算力和显存带宽（660G左右），都不如4090，因此速度介于8060S集成显卡和4090之间，能跑27B模型，选择Q4量化模型，上下文也能到256K。
玩法
分3类：
- 小模型单卡玩法，这就不说了，就是用一个卡跑一个模型；
- 中等模型分2卡玩法，例如Qwen3.5-122B模型，本来可以直接跑在AI MAX 395的集成显卡上，但我嫌他性能太差，然而4090和R9700两个卡，任何一个的显存又不够单跑这个模型，但2个卡加起来80G的VRAM就够了，因此可以将它用llama.cpp的
-ts参数，分层到2块卡上跑，效果惊人地快； - 超大模型分卡分3卡玩法，例如MiniMax M2.7这种，下载下来哪怕是Q4的量化版本，都有120多GB，连AI MAX 395的128GB都放不下（需要留内存给系统和kv cache），这种情况，可以把同一个模型分成3部分，让4090承担大头，AI MAX395承担中头，R9700承担小头。这样的性能会被AI MAX 395的集成显卡拖后腿，但是能跑，而且如果不用长上下文的Agent，仅用来聊天（利用超大知识库），性能也可以接受（吐字不慢）。
后面我就把这几种方法跑出来的效果给大家汇报一下。
测试工具
llama-benchy： 我用这个工具，它是通过openai的兼容api端点做压测，可以对任何推理引擎做压测（我是vLLM和llama.cpp），它能反映最终用户（例如Hermes Agent）能真正感受到的速度。
GitHub - eugr/llama-benchy: llama-benchy - llama-bench style benchmarking tool for all backends压测结果
模型 参数量 量化方式 权重大小 推理框架 GPU PROMPT PREFILL (pp8192) TOKEN GENERATION (tg512) MiniMax2.7 230B-A10B UD-IQ4_XS 102GB llama.cpp (-ts) 4090+R9700+8060S 781.68 27.74 Qwen3.5-122B-A10B 122B-A10B UD-Q4_K_XL 73GB llama.cpp 8060S 352.36 20.96 Qwen3.5-122B-A10B 122B-A10B UD-Q4_K_XL 73GB llama.cpp (-ts) 4090+R9700 2234.51 53.63 Qwen3.6-35B-A3B 35B-A3B Q5_K_XL 25G llama.cpp 4090 7978.24 162.10 Qwen3.6-35B-A3B 35B-A3B Q5_K_XL 25G llama.cpp R9700 2880.76 79.05 Qwen3.6-35B-A3B 35B-A3B Q5_K_XL 25G llama.cpp 8060S 946.44 50.77 Qwen3.6-27B 27B AWQ-6Bit 26GB vLLM 4090 2557.59 115.47 (with MTP) Qwen3.6-27B 27B UD-Q6_K_XL 25GB llama.cpp 4090 2402.65 33.88 Qwen3.6-27B 27B UD-Q4_K_XL 17GB llama.cpp R9700 914.31 26.56 Qwen3.6-27B 27B UD-Q4_K_XL 17GB llama.cpp 8060S 281.44 11.83 结论
这个结果其实就和特哥常常讲的一样，有多少钱卖多少钱的设备：买贵的吃不了亏，买便宜的占不了太多便宜。
以Qwen3.6-27B为例：- 跑在AI MAX 395的8086S上，PP才281个，吐字才11个，这个机器14000RMB，你买到了128G的大显存，还得到了一台不错的windows/linux主机，但是速度没法和独立显卡相比；
- 跑在R9700上，PP一下子914个，吐字有26个每秒，这才是可用的速度，但代价是11000RMB；
- 跑在4090上，这生态上的优势马上就出来了，用vLLM打开成熟的MTP支持，多请求PP一下子2557个，吐字115个（不要去折腾A卡的vLLM了，我尝试过，Qwen3.6支持度不行，上下文有限， 单请求速度不如llama.cpp），即使跑在llama.cpp上，PP速度也能到2402，只是吐字速度稍慢，才33个（受限与1TB显存带宽以及没有成熟的MTP）。这个卡30000RMB左右，比R9700贵了2倍左右，但你得到的效果也是2倍。
所以最后还是看自己，显卡这个市场现在基本上是一分钱一分货（除非被骗），不要纠结。自己想干啥，就买啥。
备注！AI MAX 395现在要重新评价它了，现在涨价到21000左右了，性价比已经比14000的时候低很多了！
-
@Fred 我草，这绝对精华帖子，我要做一个单独视频，给老弟署名。你给弄几张 截图啊，最好是黑乎乎的背景，显得逼格高点。卡和设备给我再拍几张图片发进来。我做完视频加入这个链接，让大家来膜拜下你。
@Fred 我草，这绝对精华帖子，我要做一个单独视频，给老弟署名。你给弄几张 截图啊，最好是黑乎乎的背景，显得逼格高点。卡和设备给我再拍几张图片发进来。我做完视频加入这个链接，让大家来膜拜下你。
哈哈不用单做视频特哥。我经常看你油管，学到很多东西，想着回报一下你。我的资料你随便用在视频里面。我是属于那种闲散玩法，比较佛系，有时间就来吹吹牛逼，分享点内容。不过我这个配置是有误导性的：不推荐显卡坞，有条件一定是尽量PCIE直连。我这是属于放养式玩法，不是生产力的标配，可靠性，性能都比PCIE直连差点意思。
-
作业牛逼，可以置顶！
-
-
我是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
-
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 到了再报告结果。
