跑 LLM 吗？跑的话 M1 Max ，因为 64GB 统一内存是真爽，而且 Max 芯片的带宽比 Pro 芯片的带宽大多了。
M1 Max 是 400GB/s ，M3 Pro 只有 150GB/s 。

做视频剪辑吗？ M1 Max 有两个多媒体引擎，M3 Pro 只有一个。

除了 CPU 性能有提升，GPU 硬件支持了 bf16 格式以外，我看不出选 M3 Pro 的任何理由。

吓得我赶紧去把 ARM VM reshape 成了 2 核 12G

@SteveRogers 太贵了太贵了，我 7000 块钱搞了个 16 寸无头骑士 64GB 的 M1 Max ，够我玩一阵子了

再往上升级目前看就 M5 Max 性能提升明显，但是对比 7K 的价格，太不划算了……

@zhongzh 我试了一圈下来，Qwen3.6-35b-a3b-oQ8 不开思考模式是最稳的，我 hot cache 设置成 2GB ，memory guard 设置成 aggressive ，用 Pi Coding Agent ，在一个 session 里面反复探索、深入，体验和用 DSv4 Flash 这样的模型很接近了。当然，智力是明显差一些的。但是真的已经是能用的程度了。

27B 和 31B 两个，在我的 M1 Max 上最大的问题是 PP 太慢。这两个 Dense Model 对量化的容忍程度比 MoE 高，为了速度，我选了 4bit 量化，但是还是慢。差不多 10 tokens/s 的生成速度我能忍，但是真实场景里面到了中途以后，动辄 10 分钟起步的 PP 令我难以忍受。

M1 Max 也是 2 小核，我的实际感受并不是 2 个小核会导致突然卡一下，而是相对比较费电。M4 （不带后缀）的 6 小核 4 大核设计才更适合日常使用。

@zhongzh 你跑多大的 context ？

oMLX - LLM inference, optimized for your Mac
https://github.com/jundot/omlx
Benchmark Model: Qwen3.6-27B-MLX-VL-oQ8-fp16 (DFlash)
================================================================================

Single Request Results
--------------------------------------------------------------------------------
Test TTFT(ms) TPOT(ms) pp TPS tg TPS E2E(s) Throughput Peak Mem
pp1024/tg128 9841.9 24.30 104.0 tok/s 41.5 tok/s 12.927 89.1 tok/s 31.94 GB
pp4096/tg128 38659.6 23.87 106.0 tok/s 42.2 tok/s 41.691 101.3 tok/s 34.03 GB
pp8192/tg128 77367.7 24.89 105.9 tok/s 40.5 tok/s 80.529 103.3 tok/s 35.27 GB
pp16384/tg128 160222.9 25.85 102.3 tok/s 39.0 tok/s 163.506 101.0 tok/s 37.61 GB
pp32768/tg128 349855.4 49.53 93.7 tok/s 20.3 tok/s 356.146 92.4 tok/s 42.01 GB
pp65536/tg128 801931.3 51.50 81.7 tok/s 19.6 tok/s 808.472 81.2 tok/s 47.38 GB

https://omlx.ai/benchmarks?chip=&chip_full=M4%7CMax%7C32&model=gemma+4+31b&quantization=&context=&pp_min=&tg_min=

你看看真实 benchmark 你能接受吗。

Qwen 27b 和 gemma 31b 这种 dense 模型还是得显卡

用 oMLX ，然后 32GB RAM 可以很舒服地跑 gemma-4-26b-a4b-fp16 了，你选一下 oQ8 量化配短一点的上下文，或者 oQ4 量化，跑 32K 以上的上下文。

M1 和 M2 系列的 GPU 没有 bf16 格式的硬件加速，所以关键不在量化，在 fp16 上，能显著提升 PP 和 TG 的速度。

另外，Dflash 和 MTP 对 M1 系列来说，基本上净收益为负，不用浪费时间了。

Qwen3.6-35b-a3b 比那个 9B 模型强，你都有 32GB RAM 了，没必要用它了。

建议看看 oMLX 的社区评测，不要用 llama.cpp ，浪费苹果硬件

无法复现。
「然而并没有」节点预备。

@Hermitist Qwen3.5-9B 是我玩过智力最强的小模型了，你还觉得蠢？具体是什么场景？ 9B 及以下的模型，我就没见过比它聪明的……

OpenCode Go 量好少，1 天之内用光 2 次 5 小时额度的话，就相当于用完了 1 周的额度，和半个月的额度。
这样站起来蹬的话，一个月的额度也就能用 3 天，中间还隔一个星期。
但是好处是 Go 套餐里面用各家的模型收费基本一致，它没怎么加价。GLM 5.1 当个低配 Opus4.6 用还是可以的。

Go 套餐 + 充值（美元）可以用 GLM 5.1
现在 DeepSeek V4 Pro 性价比也很高，充钱用 API 当 Sisyphus Agent 主力用，搞不定切到 Go 里面的 GLM ，还是很强的。

你试试 Qwen3.5-9B ，很惊喜。

我在闲置的 16GB RAM M1 Pro MBP 上面，用 oMLX （已经支持 TurboQuant 给 KV Cache 量化了，我用的 4bit ）跑混合量化的 Qwen3.5-9B-MLX-OptiQ-4Bit 版本，能坚持到 45K context 才 OOM ，使用的时候确保 context 不超 32K ，留出 10K 给它 thinking 和 reply ，还能有 2-3K 的 buffer 。

速度的话，我也跑了 benchmark：
1k -> PP 136.6 · TG 28.4 tok/s
4k -> PP 140.1 · TG 27.4 tok/s
8k -> PP 139.3 · TG 26.2 tok/s
16k -> PP 136.7 · TG 23.9 tok/s
32k -> PP 131.1 · TG 20.1 tok/s

你的设备应该不会比我这台机器更古早了，性能应该更好。

智力的话，我也做了一些测试：
1. 农夫过桥问题不需要思考模式就能秒答对
2. 洗车问题需要思考大约 200-300s ，但是每次都能答对
3. 猎人打鸟问题短暂思考就能答对
4. 给飞机跑道装跑步机问飞机能不能起飞，思考后能答对
5. 9.11 和 9.9 哪个大，短暂思考后答对

还有很多此类问题，没有翻车的。就是思考时间比较长。

我也 benchmark 了单一量化版的，Qwen3.5-9B-MLX-4Bit, 速度能稍微快一点：
1k -> PP 136.3 · TG 30.3 tok/s
4k -> PP 140.0 · TG 29.1 tok/s
8k -> PP 139.3 · TG 27.9 tok/s
16k -> PP 136.7 · TG 25.3 tok/s
32k -> PP 131.1 · TG 21.2 tok/s

想了一下，觉得混合精度可能在长上下文的时候，某些 edge case 表现更稳，这一点速度损失可以承受。

我也尝试了用 llama.cpp ，打开 metal 优化编译，再配合 TurboQuant+，结果完全不如 oMLX ，跑不赢一点。Context Window 可以大一些，但是速度太慢了，16K 以上就掉到 10 tok/s 以下了。

都 4 月中了，泡温泉不嫌热吗？

@oldlamp 加钱即可满足速度和质量双全，直接上 512GB 统一内存的 Mac Studio ，哈哈

唉，世上安得三全法？

```
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)
```

@oldlamp

Qwen3.5 非常啰嗦，思考就要占大量 context ，我看这篇文章里面才设置了 4K 上下文，一个洗车问题，或者棍子过门问题就能烧光这点预算，根本等不到吐出回答的时候。
14 tokens/s 其实有点儿慢。你能接受一个问题连想带回答要 5 分钟起步吗？

我也在调这个，用的机器也不求行，是一台闲置的 16GB M1 Pro MBP ，权重用的 Q4_K_M ，KV Cache 也用了 TurboQuant+，能开到 48K 上下文，15-18 tokens/s 。喜欢它的质量，但不太能接受这个速度。

要速度就要换成 Gemma-4-E4B ，同样的量化版本，能跑到 22-25 tokens/s ，速度可以接受了，但是质量差一点