coefu

即便是 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 。

以前都说 LLM 是推理下一个字符，所以有可能算错 10+11 这种最基本的计算题。

你说是就是？这个因果是你自己想当然定义的？先定义了一个错的 A ，反推出一个正确的 B 。