一位开发者用一台售价不到 300 美元、搭载 2013 年双路 Xeon E5-2690 v2（即单机双 CPU 插槽）、完全没有 GPU 的翻新存储服务器，跑通了 Google DeepMind 2026 年发布的 Gemma 4 26B A4B 模型，实际生成速度约每秒 5.2 个 token；这条帖子在 Hacker News 获得 274 点赞和 179 条评论，核心争议点不是"能不能跑"，而是"跑通过程中遇到的一个隐蔽 bug"——非 AVX2 芯片上的 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 只支持 AVX1 指令集，不支持后续大多数推理框架默认依赖的 AVX2/FMA3。

他选用的模型是 Google DeepMind 发布的 Gemma 4 26B A4B（Mixture-of-Experts 架构，Q8_0 量化），推理框架是 ik_llama.cpp（llama.cpp 的一个专注 CPU 优化的分支）。实测结果：

过程并不顺利。作者最初拿到的输出是"看起来流畅、实际语义混乱"的多语言文本——没有报错、没有 NaN，肉眼很难第一时间判断是 bug 还是模型本身效果差。深入排查后发现：MOE_FUSED_UP_GATE 等融合算子在非 AVX2 编译路径下缺少对应的调度分支，导致每个专家层的前馈网络输出实际是未初始化的内存——这类问题的诊断线索是 logits 均值出现异常偏高（约 +16），指向隐藏状态包含垃圾数据。修复方式是将融合算子拆分为两次独立调用（ggml_mul_mat_id + ggml_fused_mul_unary），仅在非 AVX2 构建下生效，补丁已作为 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 版本，规格如下：

"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：什么时候该选哪个

本地部署老硬件更多是一种极限实验和成本探索，并不意味着它能替代日常的云端调用。两者的适用边界可以用下面的对比理清：

2026 年以来，多家云端大模型 API 陆续上调价格，有实测文章统计并援引称，部分厂商的调用价格涨幅从数十到数百个百分点不等[数据待核实：建议核实具体厂商官方定价公告]，这也是"值不值得自建本地推理"重新被讨论的现实背景之一。对于确实需要稳定调用多种模型、又不想负担硬件运维成本的团队，也可以选择在国内可直接访问的多模型平台上按需切换——例如七牛云 AI 大模型广场汇聚了多款主流大模型，支持按任务需求切换调用，属于云端路线的一种补充选项。

没有 GPU 的机器，能跑动多大的模型？

除了这次的 Xeon 实验，近期还能看到几类类似的"硬件极限"探索，可以帮助判断自己手头设备的大致上限：

● 双路老 Xeon + 大内存：有开发者在双路 Xeon 配 256GB DDR4（同样无 GPU）的机器上，完整测试了多个不同规模的开源模型，验证了"内存足够大，CPU 也能撑起中等规模模型"的思路。

● 消费级迷你主机 + 集成显卡：有实测记录显示，26B 规模的 Gemma 4 MoE 版本可以在仅依赖核显、显存占用不到 8GB 的迷你主机上运行[数据待核实：具体机型与测试环境细节建议以官方评测为准]，说明 MoE 架构对消费级设备也具备一定友好度。

● 超大参数量下的纯 CPU 极限：也有报道提到有开发者用不依赖 GPU、代码量极小的推理实现跑通了参数量远超主流商用模型的开源模型[数据待核实：该案例的具体参数规模与运行环境需以原始出处进一步核实]，更多是技术极限验证，距离日常可用还有距离。

综合来看，能否在无 GPU 设备上跑动某个模型，核心取决于三点：模型是否采用 MoE 等稀疏激活架构、量化精度选择（如 Q8_0）、以及内存容量与带宽——这三者共同决定了"跑不跑得动"和"跑得多快"。

本地部署要留意的几个坑

如果打算在闲置的老硬件上做类似实验，以下几点是这次案例中暴露出的实际经验：

1. 确认 CPU 指令集支持范围：老旧 CPU 可能只支持 AVX1，而多数推理框架的性能优化路径默认针对 AVX2/FMA3 编写，指令集不匹配是编译失败或运行异常的常见根源。

2. 选择针对 CPU 优化的推理框架：案例中使用的 ik_llama.cpp 是 llama.cpp 面向 CPU 场景的优化分支，相比通用框架在老硬件上表现更稳定。

3. 警惕"看起来正常"的错误输出：非主流硬件路径上出现的 bug 未必会报错或产生 NaN，输出可能是"流畅但语义混乱"的文本，需要额外检查中间层数值分布来判断问题。

4. 量化精度需要权衡：案例采用 Q8_0 量化，在精度损失和推理速度之间取得平衡，量化精度越低通常速度越快但输出质量风险越高。

5. 关闭不兼容的编译选项：案例中特别提到需要去掉 --run-time-repack 参数，因为它会将权重重排为 AVX2 专用内存布局，在不支持 AVX2 的机器上会直接导致错误。

常见问题

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 模型能力与云端定价均处于快速变化中，建议读者结合最新官方信息判断。

延伸阅读：七牛云 AI 大模型广场——多模型统一接入与对比测试平台。

企业Token Plan：https://www.qiniu.com/ai/plan