基础内存32GB的Mac Mini，跑得动27B参数大模型
ANEMLL Forge 0.2.1：Qwen3.8-27B 在 M6 神经引擎上现可运行高达 192K 上下文（M6 32GB）。
新增：INT8 K/V 缓存（FP16 的一半）以及一个共享目标输出头的小型草稿模型——减少 0.86 GB ANE 内存，速度不变。
解码速度取决于内容：JSON 35–62 tok/s，代码 18–32，散文 10–17。短上下文预填充 260 tok/s，192K 时为 62。128K–192K 使用较小的预填充批次（32 行 vs 64 行）以保持在内存预算内。
注意：完整 192K 首次编译在 M6 上约需 2 小时（一次性，缓存后）。--ctx 仅导出所需条目，因此编译更快：16K 从下载到运行服务器约 10 分钟。我认为 96K 是 32GB 上尺寸/速度的最佳平衡点：预填充 123 tok/s，解码约 27 tok/s，总内存约 21.4 GB。
发布说明：https://github.com/Anemll/anemll-forge/blob/main/docs/RELEASE_NOTES_v0.2.1.md
视频（俄罗斯方块生成约 150K 令牌，无压缩）：https://x.com/anemll/status/2111941341819408866
论文：Apple 神经引擎中的三位 MLP 向量量化 — https://github.com/Anemll/anemll-forge/blob/main/docs/papers/anemll-forge-v02.pdf
此致，
Anemll 🤖
高票评论（帖子共 17 条讨论）
[+9] u/Individual_Page9676：来自 Apple Silicon 产品线另一端的运行相同模型的数据点：
我的机器： 16 英寸 MacBook Pro — M5 Max，128GB 统一内存，8TB SSD。
我的设置： LM Studio 搭配 Splash 引擎，运行 incoai/Qwen3.8-27B-Splash 构建。
我的数字： 生成速度超过 200 tok/s。
作为参考，Inco 发布该构建在 48GB M5 Pro 上约 74 tok/s，因此跳至 Max 的内存带宽在像这样密集的 27B 模型上确实显著。
有趣的是我们的权衡完全相反：
* 你在 32GB Mini 上以可用速度运行，整个模型打包在不到 10GB 的权重中，运行在神经引擎上。我以暴力方式获得速度——GPU 加 128GB 快速统一内存。
* 在 128GB 下，我无需考虑 KV 缓存。即使在此模型完整 262K 上下文下，FP16 缓存约 17GB，仍有剩余空间。无需 INT8 缓存、无需编译步骤、无需预算计算。
* 你在 192K 下的预填充——在 Mini 上该深度 62 tok/s——确实令人印象深刻。这是你帖子中让我停止滚动的数字。
非常出色的工作。一年前没人会相信 27B 能在基础内存 Mini 上体面运行。
[+4] u/ieatrox：哟，是 anemll！
很高兴看到你回归。我有个朋友刚买了 M6 32，我们正在看能运行什么，我想他可能选择 3.6-35B-A3B，直到 Flint 支持成熟到足以验证其表现。
但 27B 以不错的速度……不错。
[+2] u/geo38：/u/underscorebot
[+2] u/DistanceSolar1449：这是 16.5GB，不够大以在注意力上有好的 bpw。
[+2] u/j_lyf：2 小时？搞什么鬼。.
[+1] u/Classic-Role-5548：我会围绕 96K 行规划 32GB Mini，而不是 192K 头条。192K 是约 2 小时首次编译加上预填充批次从 64 行减至 32，且散文解码在缓存满前已为 10-17 tok/s。96K 约 21.4 GB 仍为操作系统和浏览器留出空间，预填充 123 tok/s，解码约 27 tok/s。这是我不再压缩编码线程的长度。
关于 INT8 KV 注释的一个陷阱：当草稿模型共享目标输出头时，缓存字节减半并不自动意味着质量损失减半。一个糟糕的草稿令牌由与缓存打包的同一头评分。我会在 96K 下运行一次长 JSON 和一次长散文，相同提示，INT8 对比 FP16，并查看它们分歧点，而不仅仅是 tok/s。如果它们在 32K 后仍保持一致，我会发布 INT8。如果散文先漂移，我会为写作保留 FP16，为工具调用 JSON 使用 INT8，这已是表中更快的解码桶。
[+1] u/underscorebot：由于新 Reddit 中的错误，带有下划线或波浪号的 URL 被不一致地转义，破坏旧 Reddit 和第三方移动应用。请尝试以下 URL：
* https://github.com/Anemll/anemll-forge/blob/main/docs/RELEASE_NOTES_v0.2.1.md
---
^(这是一个机器人。调用方式：/u/underscorebot。问题？评论？/r/underscorebot 谢谢。版主： 这是一个选择加入的机器人。 请将其添加到您希望其扫描的子版块的 批准提交者 中。注意：此评论中可能出现的用户提供的链接不构成认可。)
关键事实
- ANEMLL Forge 0.2.1 版本支持在 M6 32GB 的 Mac Mini 上运行 Qwen3.8-27B 模型，最高支持 192K 上下文。
- 新版本引入了 INT8 KV 缓存（占用 FP16 的一半）和一个共享目标输出头的更小 drafter，节省了 0.86 GB 的 ANE 内存，速度不变。
- 解码速度取决于内容：JSON 35-62 tok/s，代码 18-32 tok/s，散文 10-17 tok/s。
- 预填充速度在短上下文时为 260 tok/s，在 192K 上下文时为 62 tok/s。
- 128K-192K 上下文使用较小的预填充批次（32 行 vs 64 行）以保持在内存预算内。
- 发布说明链接：https://github.com/Anemll/anemll-forge/blob/main/docs/RELEASE_NOTES_v0.2.1.md
- 有一篇论文：Three Bit MLP Vector Quantization in Apple Neural Engine。
- 一位用户报告在 16 英寸 MacBook Pro（M5 Max，128GB 统一内存）上使用 LM Studio 和 Splash 引擎运行同一模型，生成速度超过 200 tok/s。