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 都够用多长时间了，不比本地模型强多了。
也试了一下 Jackrong 的 Qwopus 3.5 9B 6bit MLX ，还是只能当单次聊天回复机器人用，接入 OpenCode 就报错。
实在是想不出来本地 LLM 有什么用。
加钱换 64G 的新机器？那钱买 Coding Plan 都够用多长时间了，不比本地模型强多了。
第 1 条附言 · 10 天前
用 TurboQuant+ 部署了 Qwen3.5 9B Q8_0 GGUF 版本，竟然通过了洗车测试和长杆进门测试，有 16 ～ 17 tokens/s ，开 16K 上下文 RAM 峰值占用不到 11GB ，可以修改 wired RAM 的上限，给 13GB ，应该能尝试一下 32K 上下文了。
缺点就是思考的时间长了一点。
但是这样当 headless server ，或者没网的时候玩，好像也可以？
缺点就是思考的时间长了一点。
但是这样当 headless server ，或者没网的时候玩，好像也可以？
第 2 条附言 · 9 天前
最后的发现
关于量化：
- TurboQuant 的编解码都要消耗 M1 Pro 相对孱弱的 APU 性能
- 模型权重量化，比如 Q4_K_M 带来的总数据量减少，会被相应的编解码损耗抵消
- 最终的效果就是，在 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 的惨烈降低
关于模型：
- Qwen3.5-9B-Q4_K_M.gguf 确实很强，质量很高，但是在这台机器上很慢，只有 15-18 tokens/s，而且思考模式关不掉，太啰嗦了，洗车问题和长杆进门问题能思考5分钟以上，甚至10分钟，消耗完 4K-8K 的上下文窗口，都到不了正式回答。但是质量很高，能通过洗车测试，概率通过长杆进门测试
- Qwopus3.5-9B-Q4_K_M.gguf 确实改善了原生 Qwen3.5 的一些问题，比如不那么啰嗦了，思考也简短了。但是感觉智力变低了，我无法接受。速度没有变化。
- Gemma-4-E4B-IT-Q4_K_M.gguf 很平衡，速度能达到 22-28 tokens/s，思考模式可以关闭，但无法通过洗车测试和长棍进门测试
- 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
太长了放不下，回复在内容里面了。
 |
1
sddyzm PRO 本地模型很弱智，不建议将这点加入到任何和现实生活相关的考量中，当它不存在
|
 |
2
yougo 15 天前
之前看到说 50 张 H200 也无法支撑起一个 GPT 5.2 Pro 的稳定的算力需求 所以即便那些遥遥领先的闭源模型哪天开源了 也跟大多数人没有关系 光是电费就远超当前订阅的费用 所以以后只要需求持续存在 模型就会持续涨价直到和个人部署成本达成平衡
|
 |
3
nc 15 天前
64G 统一内存都不够用。不如用买机器的钱去买 token ，本地模型智商还是低，上下文也有限。
|
 |
4
aklllw 14 天前
想起一个冷笑话：
“我的 xx 设备能够连续跑一天的任务花费超多 token 不用一分钱” “有没有可能是因为智力太低了所以才需要跑一整天” |
 |
5
wsbqdyhm 14 天前 via iPhone  1
单卡 4090 跑过 qwen3.5:35b 、gemma4:27b ，没什么实际意义。
|
 |
6
unusualcat 14 天前 via Android
没有。唯一的用处就是即时翻译……
|
 |
7
villivateur 14 天前
我想到本地模型有一个用处，就是帮盲人了解周围的情况，盲人用手机拍照后，用本地模型解析为语音
|
 |
8
fredweili 14 天前
有用，用法是跑本地小模型测试自己写的 agent/rag 代码，节约一点 token ，还方便看 log
要是接入 claw 跑生产环境，用错了地方，老老实实的买订阅 |
 |
9
workbest 14 天前
搞搞翻译，summary 这些没问题；
coding ，作图，视频肯定不行 |
 |
10
bcllemon 14 天前
本地模型用来做路由可行吗？根据业务自动切换至不同的 ai
|
 |
12
mengdu 14 天前
现阶段没啥用。
|
 |
13
Whittaker 14 天前
彦祖们，如果用本地模型搭建一个 QA Agent 有搞头嘛？
|
 |
14
yjhatfdu2 14 天前
这个问题我在 omlx 上遇到过，似乎是你设置的上下文大小，不是比较整数的值，比如你填个 32768 或者 65536 试试
|
 |
15
beginor 14 天前
不要那么悲观，本地跑一个 Zeta 或者 Qwen coder 配合 llama-code 插件做代码提示还是挺好的 🙂
|
 |
16
MacsedProtoss 14 天前 via iPhone
本地模型感觉就翻译了 或者劣质小说生成器
我是 5090 32g gemma 4 31b 上下文也就能拉到几万而已 用途也十分有限 |
 |
17
iango 13 天前
16G 顶多只能 8K 上下文……
|
 |
18
ahdw OP @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 还能再调高一点 |
|
19
ahdw OP ```
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) ``` |
Select Language