在一台 13 年前的无 GPU Xeon 上以 5 token/秒运行 Gemma 4 26B
在 10–13 年前的 Xeon CPU 上以大约每秒 5 个 token 运行一个 260 亿参数的 Gemma 4 模型，证明了只要有足够的 RAM 和谨慎的量化，现代大型 LLM 也能在老旧硬件上本地运行。评论者讨论了这在实践中到底有多可行：一边是缓慢的 token 速度和高功耗，另一边是隐私、无限使用以及“如果你已经拥有硬件，那就等于免费”的吸引力，并将成本与云端推理服务进行比较。该讨论串还涉及更大规模的稀疏/MoE 模型在消费级机器上的发展趋势，并引发了对 AI 生成技术博客文章以及社区关于披露规范的担忧。
AI 生成内容与 HN 规范
- 一些评论者认为这篇博客文章和部分评论“看起来像”AI 输出，并指出 AI 写的帖子/评论违反 HN 规范。
- 也有人不同意，或表示当人们大量使用 LLM 起草文本时，很难区分。
- 作者表示代码补丁是 AI 辅助完成的，但文章说明了哪些部分是人类完成、哪些部分是 AI 完成。
Bug 与技术细节
- 原始 fork 假定存在 AVX2；较老的 Ivy Bridge Xeon 不支持这一指令集，导致构建失败，并且更隐蔽地缺少两个 MoE 操作的调度路径。
- 在非 AVX2 构建中，MoE 专家输出来自未初始化内存，导致生成出流畅但毫无意义的文本。
- 该修复已通过 pull request 提交到上游。
性能、量化与内存
- 多个回复提到在老 Xeon、双路服务器和 Mac 硬件上运行 Gemma 4 及其他模型。
- token 速率差异很大：2013 年左右的 Xeon 上运行 Gemma 4 26B 约为 5 t/s；在 GPU 和更小/量化更强的模型上则更高。
- 讨论了 Q4 与 Q8：Q4 将带宽需求减半，并且在带宽受限系统上几乎可以将速度翻倍，但如果 RAM 充足，由于质量原因更偏好 Q8/Q6。
- 大内存（26B 模型常用 80–100+ GB）很常见；有人尝试极低内存配置和自定义加载器。
慢速本地模型的可用性
- 分歧很大：有些人觉得 5–10 t/s 用于后台或批处理工作可以接受；另一些人则认为这对交互式编码或长推理链根本不可用。
- 关于“心流状态”的争论：高速模型（每秒几百 token）让用户能快速迭代；慢速模型则会把人推向“排队然后离开”的使用方式。
成本、电力与效率
- 若干粗略估算认为，本地 CPU 推理的电费可能高于云端 token 成本，尤其是在 300–500W 服务器和较高电价下。
- 反方观点：更便宜的电、太阳能，或利用废热供暖，都可能改变这笔账。
- GPU 限功耗运行可以在速度损失不大的情况下显著降低能耗。
- 也有人指出，云服务商当前可能把 token 卖得低于真实成本，因此价格未来可能上涨。
隐私、控制与本地使用动机
- 许多人强调隐私、独立性以及不受供应商限制，是本地推理的主要原因，而非成本。
- 另一些人认为本地硬件很适合实验，但在质量或速度上暂时还无法与顶级云模型竞争。
本地 LLM 的未来
- 乐观预测：到 2027–2028 年，消费者硬件上可能运行超过 2000 亿参数的 MoE，甚至接近 1 万亿参数等效模型，这得益于三值/1-bit 训练、稀疏 MoE、新 GPU 和专用加速器。
- 怀疑者则强调 RAM 带宽、功耗限制、晶圆厂产能，以及优先服务数据中心的经济激励。
- 有人认为 transformer 在结构上并不适合高效本地推理；也有人认为持续的架构与硬件工作前景乐观。
工具与配置问题
- 实用技巧包括：在 Ollama 中调整超时、探索 LM Studio 的 TTL/逐出设置，以及使用批处理/agent 框架更好地利用缓慢的本地模型。