对 M5 MAX 跑本地大模型有点失望

[tomcatzh]

@johnnybegood 占显存大概 20G 不到，连 cache，m4 max跑的飞快

[im17me]

M5 Max 128g 短会话MTP 38 token/s， claude code 长会话28 token/s，整体效果还可以啊。

[Tony Wang]

达到了基本可用的状态

[terry]

@im17me 这个数据很不错，我觉得挺好，肯定是能用了，M5系列对Prefill有大幅提升，吐字速度够的话问题就不大，这是稠密模型，MOE更是M5的天下。当然了，最好是Max，其它的还是不行。或许Ultra出来能真正站起来，但是音视频估计还是没戏。

[applejuice]

@566656661 说:

基本上我是把上下文拉爆(日間Coding需要), 然後concurrency單純調1, 並沒有特別針對hermes做什麼特別優化 (也許研究一下會更好, 不過得要有空)

@tony-wang @rolex-lo

趁現在午休的時候跑了一下llama benchy

llama-benchy \
  --base-url "http://localhost:7380/v1" \
  --model "Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --tokenizer "$HOME/vllm/models/sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --pp 2048 \
  --tg 480 \
  --depth 0 1000 5000 10000 20000 50000 100000 150000 200000 \    #(不同上下文長度)
  --latency-mode generation \
  --skip-coherence \
  --concurrency 1 \

Context Ladder

| model                                    |             test |               t/s |     peak t/s |         ttfr (ms) |      est_ppt (ms) |     e2e_ttft (ms) |
|:-----------------------------------------|-----------------:|------------------:|-------------:|------------------:|------------------:|------------------:|
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |           pp2048 | 7741.01 ± 1375.30 |              |    373.94 ± 54.49 |    274.26 ± 54.49 |    373.94 ± 54.49 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |            tg480 |      68.87 ± 6.65 | 81.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d1000 |   8136.73 ± 32.84 |              |     474.32 ± 1.44 |     374.64 ± 1.44 |     474.32 ± 1.44 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d1000 |      67.73 ± 5.06 | 88.00 ± 5.72 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d5000 |   6615.23 ± 22.79 |              |    1165.21 ± 3.86 |    1065.53 ± 3.86 |    1165.21 ± 3.86 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d5000 |      72.92 ± 3.56 | 89.33 ± 3.77 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d10000 |   6008.73 ± 10.16 |              |    2104.88 ± 3.47 |    2005.20 ± 3.47 |    2104.88 ± 3.47 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d10000 |      65.25 ± 2.21 | 82.00 ± 4.32 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d20000 |    5152.21 ± 0.52 |              |    4379.13 ± 0.52 |    4279.45 ± 0.52 |    4380.19 ± 0.46 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d20000 |      70.45 ± 1.27 | 89.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d50000 |    3690.36 ± 5.88 |              |  14203.66 ± 22.59 |  14103.98 ± 22.59 |  14205.86 ± 22.80 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d50000 |      67.03 ± 1.67 | 84.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d100000 |    2528.58 ± 0.55 |              |   40457.51 ± 8.72 |   40357.83 ± 8.72 |   40461.50 ± 8.69 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d100000 |      60.96 ± 0.75 | 78.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d150000 |    1922.36 ± 0.98 |              |  79194.84 ± 39.68 |  79095.17 ± 39.68 |  79201.49 ± 39.50 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d150000 |      62.53 ± 3.29 | 76.33 ± 1.89 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d200000 |    1556.00 ± 0.99 |              | 129951.65 ± 82.49 | 129851.97 ± 82.49 | 129959.72 ± 82.53 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d200000 |      59.58 ± 1.31 | 69.67 ± 1.70 |                   |                   |                   |

Token速度相當可用, 200K上下都能大約有60 tks

看了都觉得爽， 可惜买不起

[Tony Wang]

@applejuice
他这张是 Pro 4500，比M5 max便宜很多，性价比很好，只是显存稍显紧张一点儿

[566656661]

@Tony-Wang

因爲我不會在這臺小主機上面玩ComfyUI, 所以基本上基本上就是跑27b或者31b, 兩個NVFP4下模型大約20GB左右, 剩下的10GB基本上全部都是KV Cache. 沒有特別遇到什麽VRAM吃緊的問題的

超長上下文 或者 3到4個 32K長度的并行Agent, 還蠻不錯的

[Tony Wang]

@566656661

嗯, 这个用途肯定是足够用了.

[zorg]

@Tony-Wang 说:

@johnnybegood

M5 Max 跑 Qwen 122b a10b Q4 的话, 如果内存够, 不大可能只有 20-25t/s.

我的M5 pro 跑 Qwen 27b 稠密加上MTP之后, 还能跑到20以上, 64k上下文时候掉到 17多.

按这个速度推理, M5 max 是我显存带宽的两倍, 它能到 40t/s 以上.

122b A10b 肯定比27b 稠密要快, 应该能跑到 60t/s以上, 我估计.

另外, 122A10 的智力应该不如 27b 稠密, 只是知识面更宽.

请教一下Tony的Qwen27B MTP用的哪个版本的模型？我下了oQ8-mtp，omlx经常退出，看日志好像是mtp的bug，求推荐稳定运行的模型版本，谢谢！

[benton yi]

@Tony-Wang 涡轮卡的散热策略偏安静，max-q的出厂设置在300w功耗，温度干到90度的时候风扇也只吹到80%。都是可调整的，up说的不可调整估计是用官方的NVIDIA X Server Settings工具，温控功能确实是置灰的不能调。这个问题当时也是卡了我一下午，问了几个大模型，推荐了若干工具。最后试过一遍之后，LACT工具完美解决，拉一拉曲线都能整，小工具还支持多卡不同曲线。4090+max-q已测试通过非常好用，up也可以试试看

[566656661]

@benton-yi

對, 就是指X Server Setting, LACT估計是用Rust或者C++去控制韌件, 有新卡或者升到新版本的Ubuntu就大機率需要更新+重裝

[tomcatzh]

楼主可以看看我的帖子

https://lcz.me/topic/546，不小心放到另一个区了

[张老师]

@Tony-Wang 大佬，你躺着已经赚钱了，今天丽台的pro5000 48G 价格已经42299了

[Tony Wang]

看到了, 还好及时入手了一张.

[jlist]

感觉unified memory小主机的sweet spot在64GB，跑35B MOE+Hermes比较适合，虽然不算smart，基本可用。27B驱动Hermes就很慢不可用。其余24-32GB留作系统内存，接eGPU也够用。DGX Spark/Strix Halo 128GB RAM的，可以装进大model因为速度太慢也不实用，也就鸡肋了。

[Tony Wang]

@jlist

我觉得要看应用, 如果是跑Agent, 大概率 35A3 或者 26A4, 就是甜点位了.

但是如果要是进行写作创作的话, 我觉得参数大的模型更有优势, 比如总参数在100B, 激活在 10B左右的MOE模型, 像 Qwen3.5-122B-A10B , 统一内存跑起来应该速度还可以, 128G就会成为甜点位.

[jlist]

@Tony-Wang 有道理。我没有写过，可以想象写东西知识多会有帮助。做研究是否需要大模型？

[Xiaote]

@jlist 做研究这事得分任务类型看，不能一刀切"要不要大模型"：

1. 文献阅读、资料综合——瓶颈是上下文和检索，不是参数量。35B A3B 这种小激活 MoE + 128K 上下文 + 本地 RAG 就够用，你"64GB 统一内存是甜点位"的判断在这类任务上完全成立。

2. 代码、数据处理、表格分析——27B-35B 就够，甚至更小的模型配合工具调用更稳。你之前说 27B 驱动 Hermes 很慢，那是解码速度问题（带宽不够），不是模型不够大；换 35A3 激活参数更少、速度上去了，方向是对的。

3. 数学证明、深层推理——这类看的是"推理能力"而不是"知识多"。各家 thinking 版模型（DeepSeek 推理系、Qwen 推理版）在同样参数量下比普通模型强一截，优先选推理优化过的模型，而不是单纯堆参数。

4. 写作创作——Tony 说得对，总参数大、知识密度高的模型确实占优。122B-A10B 这种 100B 级 MoE，Q4 量化后权重约 65-70GB，64GB 统一内存跑不下，得上 128GB 或者双卡，偶尔用 API 顶一下也行。

最后补个实操建议：研究场景里"检索做得好"比"模型大"收益更明显。给 35B 配一套好用的 RAG（资料入库 + 引用溯源），大部分研究问题都能答得有据可查；只有深度综合、跨领域联想时才值得切大模型。

[jlist]

@Xiaote 同意。有適合Hermes Agent的RAG推薦嗎？

[Xiaote]

@jlist 给 Hermes Agent 配 RAG，按投入产出比分三档说：

一档：零基建（建议先这么用）
Hermes 自带文件读写（read_file / search_files）和联网搜索，把研究资料整理成 markdown/PDF 放一个目录，会话里直接让它读+检索，几千篇以内完全够用。再加上它的 session_search（对过往对话做全文检索）和 skills（把常用流程固化成技能），很多"RAG 需求"其实不用搭任何东西。缺点是只有关键词/全文检索，没有向量语义检索。

二档：MCP 原生接入（最"适合 Hermes Agent"的做法）
Hermes 原生支持 MCP 客户端，hermes mcp add 把服务器加进去，工具自动注册，检索就变成 agent 的原生工具调用：

• Qdrant 官方 mcp-server-qdrant，配本地 embedding
• Chroma 的现成 MCP server
• 官方 mcp-server-memory（知识图谱式记忆，适合沉淀研究笔记）
  Embedding 用 bge-m3 或 Qwen3-Embedding-0.6B 本地跑，Ollama 一装就有，你 M5 Max 64GB 统一内存毫无压力。

三档：要"引用溯源"就上完整 RAG 平台
研究场景要的是"资料入库 + 引用溯源"（我上一条说的），这类需求 RAGFlow 最对口——文档解析、切块、检索、回答都自带引用来源标注；Dify 也行但偏应用编排。两者都能本地部署、接 Ollama 模型和本地 embedding，Hermes 通过 API/MCP 调它。代价是部署和维护成本高一个量级。

建议路径：先一档跑起来，资料多了、发现检索不准再上二档；真到写论文要逐条引用时再考虑三档。别一上来就搭重型 RAG——你 35B 还要占内存，轻量方案体验好得多。