你能想象吗？一台不到300美元、13年前的老服务器，居然跑通了Google DeepMind 2026年发布的Gemma 4 26B A4B模型，而且完全没有GPU。实际生成速度大约是每秒5.2个token。这条帖子在Hacker News上炸了锅，获得了274个点赞和179条评论。但有意思的是，大家争议的焦点根本不是“能不能跑”，而是“跑通过程中遇到的一个隐蔽bug”——一个在非A VX2芯片上的MoE融合算子缺少调度分支，导致专家层输出变成了看似流畅、实际是乱码的多语言文本。
这件事把“本地CPU推理”重新拉回了大众视野。Gemma 4采用混合专家（MoE）架构，26B总参数中只激活3.8B，这正是老旧硬件也能跑动大模型的关键。与此同时，2026年多家云端大模型API出现涨价，也让“要不要自建本地推理”成为更多开发者和企业绕不开的决策题。
一次本地部署复盘：从“乱码”到5 tokens/s
这次讨论的起点，是开发者neomindryan在个人博客发表的一篇实测记录，随后被转载到Hacker News首页。他使用的硬件是一台翻新的HP StoreVirtual存储服务器，成本低于300美元，搭载双路Intel Xeon E5-2690 v2（Ivy Bridge架构，2013年上市）、DDR3内存，完全没有GPU。这颗CPU只支持A VX1指令集，不支持后续大多数推理框架默认依赖的A VX2/FMA3。
他选用的模型是Google DeepMind发布的Gemma 4 26B A4B（Mixture-of-Experts架构，Q8_0量化），推理框架是ik_llama.cpp（llama.cpp的一个专注CPU优化的分支）。实测结果如下：
| 指标 | 数值 |
|---|---|
| 生成速度（decode） | 约5.2 tokens/秒 |
| 提示词处理速度（prompt eval） | 约16 tokens/秒 |
| 硬件成本 | 低于300美元 |
| CPU型号 | 双路Xeon E5-2690 v2（2013年，无GPU） |
过程并不顺利。作者最初拿到的输出是“看起来流畅、实际语义混乱”的多语言文本——没有报错、没有NaN，肉眼很难第一时间判断是bug还是模型本身效果差。深入排查后发现：MOE_FUSED_UP_GATE等融合算子在非A VX2编译路径下缺少对应的调度分支，导致每个专家层的前馈网络输出实际是未初始化的内存。这类问题的诊断线索是logits均值出现异常偏高（约+16），指向隐藏状态包含垃圾数据。修复方式是将融合算子拆分为两次独立调用（ggml_mul_mat_id + ggml_fused_mul_unary），仅在非A VX2构建下生效，补丁已作为PR #2138提交至ik_llama.cpp项目待审核。
这条案例给本地部署尝试者的直接提示是：输出“看起来正常”不等于“计算是对的”，尤其是在非主流硬件路径上，需要额外核对logits分布等中间指标。Hacker News评论区也有其他开发者给出类似量级的对照数据——有用户反馈在同代CPU上跑到8-12 tokens/秒，另有用户在双路Xeon + 256GB DDR4（同样无GPU）上完成了多个模型的实测记录，说明结果会随内存带宽、量化方式、具体机型而波动。
Gemma 4为什么能在CPU上跑起来：MoE架构与“激活参数”
要理解这次实验为何可行，关键在于Gemma 4的模型设计。据Google DeepMind发布的技术报告（arXiv:2607.02770），Gemma 4系列共有5个规格：E2B、E4B、12B Unified、26B A4B、31B Dense，覆盖从手机到服务器的部署场景，上下文窗口最高支持256K token，多语言支持覆盖140余种语言。
其中26B A4B是本次实验使用的MoE版本，规格如下：
| 属性 | 数值 |
|---|---|
| 总参数 | 25.2B |
| 激活参数 | 3.8B |
| 网络层数 | 30层 |
| 专家总数 | 128个（每token激活8个 + 1个共享专家） |
| 上下文长度 | 256K token |
“A4B”中的“A”指Active（激活参数），意味着模型总量是25.2B，但每次推理实际参与计算的只有约3.8B——这就是为什么它的推理速度接近一个4B级小模型，却能在MMLU Pro、LiveCodeBench等基准测试上取得接近31B稠密模型的分数（Gemma 4技术报告显示，26B A4B在LiveCodeBench v6上得分77.1%，仅比31B版本的80.0%低3个百分点）。对于内存带宽有限、算力薄弱的老旧CPU而言，“计算量小、内存占用大”正好比“计算量大、内存占用小”的稠密模型更容易接受。
本地CPU推理 vs 云端API：什么时候该选哪个
本地部署老硬件更多是一种极限实验和成本探索，并不意味着它能替代日常的云端调用。两者的适用边界可以用下面的对比理清：
| 维度 | 本地CPU推理 | 云端API调用 |
|---|---|---|
| 硬件门槛 | 需要老旧服务器或闲置硬件（本案例硬件成本低于300美元） | 无需自建硬件 |
| 推理速度 | 个位数 tokens/秒量级（受量化和CPU代际影响大） | 通常数十到数百 tokens/秒 |
| 适合任务 | 批量离线任务、无网络环境、故障后备 | 实时对话、高并发生产场景 |
| 运维复杂度 | 需要自行排查编译器指令集兼容性等底层问题 | 由服务商负责底层维护 |
| 成本结构 | 一次性硬件投入，边际成本接近零 | 按调用量计费，随价格调整波动 |
2026年以来，多家云端大模型API陆续上调价格，这也是“值不值得自建本地推理”重新被讨论的现实背景之一。对于确实需要稳定调用多种模型、又不想负担硬件运维成本的团队，也可以选择在多模型平台上按需切换——这属于云端路线的一种补充选项。
没有GPU的机器，能跑动多大的模型？
除了这次的Xeon实验，近期还能看到几类类似的“硬件极限”探索，可以帮助判断自己手头设备的大致上限：
- 双路老Xeon + 大内存：有开发者在双路Xeon配256GB DDR4（同样无GPU）的机器上，完整测试了多个不同规模的开源模型，验证了“内存足够大，CPU也能撑起中等规模模型”的思路。
- 消费级迷你主机 + 集成显卡：有实测记录显示，26B规模的Gemma 4 MoE版本可以在仅依赖核显、显存占用不到8GB的迷你主机上运行，说明MoE架构对消费级设备也具备一定友好度。
- 超大参数量下的纯CPU极限：也有报道提到有开发者用不依赖GPU、代码量极小的推理实现跑通了参数量远超主流商用模型的开源模型，更多是技术极限验证，距离日常可用还有距离。
综合来看，能否在无GPU设备上跑动某个模型，核心取决于三点：模型是否采用MoE等稀疏激活架构、量化精度选择（如Q8_0）、以及内存容量与带宽——这三者共同决定了“跑不跑得动”和“跑得多快”。
本地部署要留意的几个坑
如果打算在闲置的老硬件上做类似实验，以下几点是这次案例中暴露出的实际经验：
- 确认CPU指令集支持范围：老旧CPU可能只支持A VX1，而多数推理框架的性能优化路径默认针对A VX2/FMA3编写，指令集不匹配是编译失败或运行异常的常见根源。
- 选择针对CPU优化的推理框架：案例中使用的
ik_llama.cpp是llama.cpp面向CPU场景的优化分支，相比通用框架在老硬件上表现更稳定。 - 警惕“看起来正常”的错误输出：非主流硬件路径上出现的bug未必会报错或产生NaN，输出可能是“流畅但语义混乱”的文本，需要额外检查中间层数值分布来判断问题。
- 量化精度需要权衡：案例采用Q8_0量化，在精度损失和推理速度之间取得平衡，量化精度越低通常速度越快但输出质量风险越高。
- 关闭不兼容的编译选项：案例中特别提到需要去掉
--run-time-repack参数，因为它会将权重重排为A VX2专用内存布局，在不支持A VX2的机器上会直接导致错误。
常见问题
Q：Gemma 4 26B A4B和Gemma 4 31B有什么区别？
26B A4B是MoE（混合专家）架构，总参数25.2B但每次推理只激活约3.8B；31B是稠密（Dense）架构，参数全部参与计算。两者在多数基准测试上分数接近，但26B A4B推理速度更接近小模型量级，更适合算力有限的场景。
Q：普通家用电脑没有独立显卡，能跑动大模型吗？
取决于模型架构和量化方式。采用MoE架构且做过低精度量化（如Q8_0或更低）的模型，理论上可以在纯CPU环境跑动，但速度通常在个位数到十几 tokens/秒之间，更适合非实时任务。
Q：本地跑大模型输出乱码，是硬件问题还是模型问题？
两者都有可能，需要分步排查。先确认是否为编译或指令集兼容性问题（如CPU不支持某些优化路径导致的未初始化内存问题），再确认量化精度是否过低导致模型本身效果下降。
Q：企业内部有没有必要为省成本自建本地推理服务器？
如果业务是低频、可离线批处理的任务（如批量文档摘要、离线打标签），本地部署的边际成本优势明显；如果业务需要实时响应和高并发，云端API通常仍是更稳定的选择。
Q：MoE架构为什么能加速CPU推理？
MoE架构在每次推理时只激活总参数中的一小部分“专家”网络，而不是让全部参数参与计算，这大幅降低了单次推理所需的实际计算量，因而在算力有限的硬件上也能获得可用的速度。
老旧硬件跑通现代大模型，本质上验证的是MoE等稀疏激活架构在算力受限场景下的可行性边界，而不是对云端服务的替代方案。据Hacker News相关讨论及Google DeepMind官方技术报告显示，这类实验的价值更多在于给故障后备、离线批处理等非实时场景提供了一条几乎零边际成本的路径。本文内容基于2026年7月的公开讨论和官方资料整理，AI模型能力与云端定价均处于快速变化中，建议读者结合最新官方信息判断。