@diudiuu 没懂你在说什么，ultra 的机型下，我用 llama.cpp 都能把 模型全部层加载进 apple metal gpu ，cpu 都没有加载任何层。

我彻底没用 omlx ，它限制了 context 长度，我用 llama.cpp 跑 263k context 能一直跑。只是 llama.cpp 对于 混合 attention 的支持目前有问题。不过大概率要几个月才能 fix 这个问题，或者根本无解，跑的满点罢了。

mac 系列，现在只考虑 ultra 。

很有诚意。我要是年轻 10 岁，就去北京闯一闯了。

@sjmcefc2

推理第一要素，gmem/umem 的带宽，越大越好。
第二要素才是算力本身，prefill 阶段，context 太长，Nvidia 的 cuda 擅长的地方。

mac 系列只有 ultra 的带宽>= 800GB/s ，这是第一个要素。 至于 apple metal gpu 的 core 数量，讲真，再多一倍也无济于事。算力对于 mac 系列来说，聊胜于无。

mac 系列只有 ultra 能用，别的都不用试了。

确实还没恢复，我前天 build 的最新版，现在依然遇到这个 force full prompt ，难怪我每次长 context 到最后，都越来越慢，😭

有一讲一，一个办公工具，你不折腾可能还行，哪有那么多 感动自己就以为能感动别人的项目。

他可能一直没明白 微信强大的地方在于做减法，不折腾。

@kennylam777 还是 你有钱啊。

@commoccoom 如果你的经济阔绰，我推荐 NVIDIA RTX PRO 6000 Blackwell (96GB)，虽然带宽只有 1.1TB/s ，但是由于 Nvidia cuda 的极致优化，prefill 依然很能打，最主要的是 kvcache ，模型本身大概 36G ，你可以有 60G 左右跑 context ，Q8 的情况下，263k 跑满，还能开 2 parallel 。

如果你经济有限，我推荐 mac ultra ，可以是 64G ，但是 96G 或者 128G 更好。把 context 搞成 Q4 ，跑 263k 也是 ok 的。只是越往后越慢，但是依靠模型本身的能力，慢点也能完成任务。

Diffusion 这条路，依然没有解决当前 LLM prefill 里 超长 context 说带来的 attention O(n²) 消耗。只是在 token generator 上做了加速的文章。但是当前 agent 模式的瓶颈，已经不在 token generator 。

解决 prefill 的 attention O(n²) ，依然任重道远。 主要是信息论里，对 过去 context 的压缩 是否能保证完全无损，这是当前很长时间内的根本矛盾。

@BingoXuan Gemma4 31B 擅长的是 stem 的理论逻辑。coding 确实不如 qwen3.6 27B 。

@BingoXuan
@kennylam777

qwen3.6 27B 是真正的能打，我现在日常主力了。能感觉到，这个模型之后，这个板块沉寂了很长一段时间，恐怕大家都是偷着乐的。


27B 真正能打，是因为它在 27B 这样的参数下，能搞到惊人的 64 层 dense ，模型的宽和深，有个奇妙的组合甜点位。只顾宽不顾深，就只有广博知识面，但是缺乏逻辑深度和缜密，只知道夸夸其谈，经不起推敲。只有深度，没有宽度就是个诡辩的杠精。但是 27B 兼顾了知识面的广度和逻辑的深度，但是如果再增参数和深度，本地部署又失去了可能。巨大的参数所产生的 kvcache ，以及 agent 模式下 context 的反复进出，单卡带宽完全跟不上，就算是 gmem/umem 的容量够，attention 的 O(n²) 也是无解的。

可能是绝唱，也可能是当下开源的极限。

qwen 这次估计要落后 Gemma 团队了，Gemma 总能整出一些新活儿。😂

这个方向的东西都是一抓一大把了，你这个和同类竞品有什么优势？你只提到了解决你遇到的问题，还是感动自己了一位就能感动别人的典中典。

因为大部分使用 vibe coding 的 application ，对于这个世界来说，没有什么意义。无所谓的，都是乐色。还是他们自己 LLM 产生的，有什么所谓的隐私？

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

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

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