闲置 16GB M1 Pro MBP 跑大模型

[ahdw]

Gemma4 E4B IT 4bit MLX 能跑出几十 tokens/s ，但是有什么用呢？试着在同一局域网里面的 Mac Mini ，把 OpenCode 的 Quick 类指定成它，但是 12K 上下文都能报错，tensors cannot be broadcast 。这玩意儿到底有什么用？

也试了一下 Jackrong 的 Qwopus 3.5 9B 6bit MLX ，还是只能当单次聊天回复机器人用，接入 OpenCode 就报错。

实在是想不出来本地 LLM 有什么用。

加钱换 64G 的新机器？那钱买 Coding Plan 都够用多长时间了，不比本地模型强多了。

用 TurboQuant+ 部署了 Qwen3.5 9B Q8_0 GGUF 版本，竟然通过了洗车测试和长杆进门测试，有 16 ～ 17 tokens/s ，开 16K 上下文 RAM 峰值占用不到 11GB ，可以修改 wired RAM 的上限，给 13GB ，应该能尝试一下 32K 上下文了。

缺点就是思考的时间长了一点。

但是这样当 headless server ，或者没网的时候玩，好像也可以？

最后的发现

关于量化：

1. TurboQuant 的编解码都要消耗 M1 Pro 相对孱弱的 APU 性能
2. 模型权重量化，比如 Q4_K_M 带来的总数据量减少，会被相应的编解码损耗抵消
3. 最终的效果就是，在 KV Cache 的量化方式相同时，高精度权重，比如 Q8_0，速度会稍慢于 Q4_K_M； 3.1 对同一个权重文件来说，-ctk 用 q8_0，-ctv 用 turbo4 会比两个都用 turbo4 更快 3.2 M5 之前的机型不要轻易尝试 TQ4_1S 这样的量化，虽然 RAM 压力会小，但是编解码的计算开销没有 Tensor API 的加速，对这些老机型来说会导致 tokens/s 的惨烈降低

关于模型：

1. Qwen3.5-9B-Q4_K_M.gguf 确实很强，质量很高，但是在这台机器上很慢，只有 15-18 tokens/s，而且思考模式关不掉，太啰嗦了，洗车问题和长杆进门问题能思考5分钟以上，甚至10分钟，消耗完 4K-8K 的上下文窗口，都到不了正式回答。但是质量很高，能通过洗车测试，概率通过长杆进门测试
2. Qwopus3.5-9B-Q4_K_M.gguf 确实改善了原生 Qwen3.5 的一些问题，比如不那么啰嗦了，思考也简短了。但是感觉智力变低了，我无法接受。速度没有变化。
3. Gemma-4-E4B-IT-Q4_K_M.gguf 很平衡，速度能达到 22-28 tokens/s，思考模式可以关闭，但无法通过洗车测试和长棍进门测试
4. Gemopus-4-E4B-IT-PREVIEW-Q4_K_M.gguf 速度没有提高，默认没有打开思考模式，但是感觉整体降智严重

关于上下文窗口：

感谢 TurboQuant+，在模型权重量化的基础上，让 KV Cache 也显著缩小了体积。最终在 16 GB RAM M1 Pro MBP 上使用上面的模型，都能有 48K 的上下文，还有余裕。

64K 能启动 llama-server，但使用时会报错。

96K 无法启动 llama-server。

log snippet

太长了放不下，回复在内容里面了。

[940i3s34v4F1HW41]

本地模型很弱智，不建议将这点加入到任何和现实生活相关的考量中，当它不存在

[yougo]

之前看到说 50 张 H200 也无法支撑起一个 GPT 5.2 Pro 的稳定的算力需求 所以即便那些遥遥领先的闭源模型哪天开源了 也跟大多数人没有关系 光是电费就远超当前订阅的费用 所以以后只要需求持续存在 模型就会持续涨价直到和个人部署成本达成平衡

[nc]

64G 统一内存都不够用。不如用买机器的钱去买 token ，本地模型智商还是低，上下文也有限。

[aklllw]

想起一个冷笑话：
“我的 xx 设备能够连续跑一天的任务花费超多 token 不用一分钱”
“有没有可能是因为智力太低了所以才需要跑一整天”

[wsbqdyhm]

单卡 4090 跑过 qwen3.5:35b 、gemma4:27b ，没什么实际意义。

[unusualcat]

没有。唯一的用处就是即时翻译……

[villivateur]

我想到本地模型有一个用处，就是帮盲人了解周围的情况，盲人用手机拍照后，用本地模型解析为语音

[fredweili]

有用，用法是跑本地小模型测试自己写的 agent/rag 代码，节约一点 token ，还方便看 log
要是接入 claw 跑生产环境，用错了地方，老老实实的买订阅

[workbest]

搞搞翻译，summary 这些没问题；

coding ，作图，视频肯定不行

[bcllemon]

本地模型用来做路由可行吗？根据业务自动切换至不同的 ai

[clemente]

@yougo 假的
512b 的模型上 nvfp4 只需要 500gb 的显存服务器就够了 按照 H200 也就是一台服务器 8 张卡

[mengdu]

现阶段没啥用。

[Whittaker]

彦祖们，如果用本地模型搭建一个 QA Agent 有搞头嘛？

[yjhatfdu2]

这个问题我在 omlx 上遇到过，似乎是你设置的上下文大小，不是比较整数的值，比如你填个 32768 或者 65536 试试

[beginor]

不要那么悲观，本地跑一个 Zeta 或者 Qwen coder 配合 llama-code 插件做代码提示还是挺好的 🙂

[MacsedProtoss]

本地模型感觉就翻译了 或者劣质小说生成器
我是 5090 32g gemma 4 31b 上下文也就能拉到几万而已 用途也十分有限

[iango]

16G 顶多只能 8K 上下文……

[ahdw]

@iango no no no, 强烈推荐 TurboQuant+，8K 上下文 context 占用仅 152 MB

llama_memory_breakdown_print: | memory breakdown [MiB] | total free self model context compute unaccounted |
llama_memory_breakdown_print: | - MTL0 (Apple M1 Pro) | 13000 = 2666 + (10332 = 9075 + 152 + 1104) + 0 |
llama_memory_breakdown_print: | - Host | 1062 = 1030 + 0 + 32 |
ggml_metal_free: deallocating

链接：
https://github.com/TheTom/turboquant_plus/blob/main/README.md

Qwen3.5-9B-Q8_0.GGUF, 8K context RAM 还有剩！

现在当 headless server ，用 SSH 连进去用，GUI cost 降低了，Context Window 还能再调高一点

[ahdw]

```
main: loading model
srv load_model: loading model '/path/to/TurboQuant/models/gemma-4-E4B-it-Q4_K_M.gguf'
common_init_result: fitting params to device memory, for bugs during this step try to reproduce them with -fit off, or provide --verbose logs if the bug only occurs with -fit on
llama_params_fit_impl: projected to use 11441 MiB of device memory vs. 14199 MiB of free device memory
llama_params_fit_impl: will leave 2757 >= 1024 MiB of free device memory, no changes needed
llama_params_fit: successfully fit params to free device memory
llama_params_fit: fitting params to free memory took 0.39 seconds
llama_model_load_from_file_impl: using device MTL0 (Apple M1 Pro) (unknown id) - 14199 MiB free

print_info: file format = GGUF V3 (latest)
print_info: file type = Q4_K - Medium
print_info: file size = 4.62 GiB (5.28 BPW)

load_tensors: CPU_Mapped model buffer size = 360.00 MiB
load_tensors: MTL0_Mapped model buffer size = 4731.51 MiB

llama_context: n_ctx_seq (49152) < n_ctx_train (131072) -- the full capacity of the model will not be utilized
ggml_metal_init: allocating
ggml_metal_init: found device: Apple M1 Pro
ggml_metal_init: picking default device: Apple M1 Pro
ggml_metal_init: use fusion = true
ggml_metal_init: use concurrency = true
ggml_metal_init: use graph optimize = true
llama_context: CPU output buffer size = 1.00 MiB
llama_kv_cache_iswa: creating non-SWA KV cache, size = 49152 cells
llama_kv_cache: MTL0 KV buffer size = 306.00 MiB
llama_kv_cache: size = 306.00 MiB ( 49152 cells, 4 layers, 1/1 seqs), K (q8_0): 204.00 MiB, V (turbo4): 102.00 MiB
llama_kv_cache: upstream attention rotation disabled (TurboQuant uses kernel-level WHT)
```