问题都问不明白，为什么要教你？

因为 gemma4 12B 有 48 层，qwen3.5 9B 只有 32 层。层深度决定了逻辑的缜密性。

@zzutmebwd 根本性的解决方案是 pp 过程，怎么保持 O(n)的算法。要是能找到个方案，那真的是非常嗨皮了。

要是能买到，amd 的 mi 系列，可能会更好点。

还得和 context 长度挂钩，越长越线性下降。

@zzutmebwd 只要模型能力足够强，pp 慢了点，但是能搞定，我也能接受的，任务布置下去，让它哼哧哼哧的搞。

内存不够的情况下，最新的 qat 量化版本，确实有得搞。Q4 的体积，Q8 的效果。

@TGOcc m5 max 的统一内存带宽才 614GB/s ，真正对推理影响最大的还是内存带宽，apple metal gpu 核心，讲真，最终在 263k 的 context ，完全没有影响了。我的 m1 ultra ，qwen27B Q8 在 150k context 之后，tg 就下滑到了 5 左右。但是大部分情况下，最终还是能完成任务的，这还是因为 qwen 27B 的 Q8 确实强。

另外，oMLX 最大的问题是 让 context 无法往 263k 去，因为一旦 内存过了告警阈值，就直接 panic 了。

所以，我推荐 llama.cpp ，不要信那些说什么不用 oMLX 就浪费 apple metal gpu 的，他们压根儿就没实践过。我用 llama.cpp 直接把 gpu 利用率搞到了 100%。

llama.cpp 能把 context 搞到 263k ，并且 Q4 量化，能把内存逼近到极限，但是不会 panic 。

mac 系列真正能打的是，ultra ，128G 内存就是甜点位。因为 800GB 的内存带宽，模型超过 60G ，在 long context 的情况下，pp 过程慢的让人怀疑人生。96G 内存是最舒服了，263k context 可以跑 Q8.

@followadc 我换了 moe 模型，并且用 llama.cpp 把 context 搞到了 263k 。总体来说，还是可以的。

即便是 ultra ，dense 模型，在 263k 的 context 下，pp 依然会降到 100 一下，比较闹心。

这个 12B 昨天刚出，我就测了，16G 太尴尬了，context 完全跑不起来。起码要 32G ，多出来的 20G 跑 context 。

mac mini 的内存带宽，会慢的让你怀疑人生。

是 max pro 还是 ultra ？不一样的。

夕阳西下的黄昏阶段，没什么搞头了。

mac studio m4 max 的 内存带宽才 410GB/s ，跑 30B 左右的 dense ，虽然可以用 mtp 加速，但是依然鸡肋。

mac studio 只能买 ultra ，m3 ultra 的内存带宽 819GB/s ，nvidia tesla v100 的 hbm2 900GB/s ，可以接近，但是容量超过 128G 就是鸡肋。

mac studio 最大的优势是 功耗低，最大持续功耗 480 瓦，也就 2 张 N 卡的功耗。

1 ，开源 70B 以下参数的 moe 逻辑能力比 dense 差太多了。

层宽和层深之间有个甜点位，不同参数量的甜点位又不同。总体来看，那几个大的 moe ，active 的 expert 层数应该都要搞到 40 ～ 60 ，在宽度上做取舍。

gemma4 E4B 有 42 层，比 qwen3.5 9B 的 32 层 更深，按理来说，逻辑能力应该更好，但是受限于总参数量导致的宽度窄，表征能力不行，所以更容易在逻辑推理的起始位就跑偏，导致整个推理完全无法收敛。这点，通过中等数学的奥赛题可以验证。就算是 gemma4 E4B 横向增加 experts + router ，把总参数也堆起来，依然也无法解决问题。

2 ，dense 只需要在原始架构上达到了甜点位，横向+experts + router ，依然很能打。如果这种架构做层 plug-in 模式，更有搞头。总体来看，在 linear attention 这条路线上来看 qwen3.6 27B 已经是甜点位了。在纯 transformer 路线上来看 gemma4 31B 似乎也到了甜点位。如果可以搞一个 plug-in 架构，类似 TTT 模式，那真的就是开源福音。

先在 window 7 指定的版本里 搞定 docker ，然后在外面把所有依赖都封装进 docker 。