GPU 还是 NPU？AI 推理选型的第三个答案
最近有不少朋友在搭大模型推理服务时都会卡在同一个问题上：推理硬件到底选 GPU 还是 NPU？问了一圈，发现多数人的答案都是"无脑上 GPU"，理由无非是生态成熟、性能强；另一拨做端侧和嵌入式的则坚持 NPU，理由是能效比高、单位成本低。两边吵得不可开交，但我在实际项目中却越来越觉得，这个二选一本身就把问题问偏了——在很多生产级场景里，真正被忽略、却性价比极高的方案是 CPU 推理。这篇文章不打算站队，而是把我这几年在 AI 推理选型上踩过的坑、实测过的数据、以及一套可以落地的决策思路完整梳理一遍，希望能帮正在纠结的你省掉几周试错时间。
先说清楚适用范围。如果你是在做 7B/13B 级别的开源大模型推理，服务形态是内部工具、自动化流水线、批量任务或者对延迟不敏感的 SaaS 功能，那这篇文章里的内容基本可以直接抄作业。如果你做的是高并发低延迟的对外商业化 API，GPU 依然是更稳妥的主路线，但 CPU 也值得作为容量缓冲和冷启动方案留着。至于 NPU，它并非不好，只是大多数人对它的期望值被营销话术抬得太高了，实际落地落差很大。
1. 先看 GPU 和 NPU 的“舒适区”：被营销话术掩盖的选型陷阱
1.1 GPU 的算力优势是有前提的，不是无脑碾压
GPU 在推理任务上的强，主要体现在大矩阵乘法上。Transformer 架构里的 Attention 计算、MLP 层的全连接，本质上都是大规模 GEMM 运算，GPU 的 Tensor Core 就是为这种计算量身定做的。所以当你把一张完整的推理请求切成固定 batch、固定序列长度、喂给 GPU 时，单位时间能处理的 token 数确实远超 CPU。这也是几乎所有性能测试报告里 GPU 一骑绝尘的原因。
但很少有人提另一个事实：推理负载并不全是 GEMM。解码阶段涉及大量的访存操作、KV cache 读写、Softmax 归一化、采样等小算子。这些小算子对算力密度要求不高，但对内存带宽和内存延迟极其敏感。很多人在压测时发现 GPU 利用率只有 20%~30%，不是 GPU 不行，而是整个推理链路中大量时间花在了访存和调度上，Tensor Core 在干等着数据搬运。这个问题在所有硬件上都存在，只是 GPU 因为算力堆得太高，访存瓶颈显得更扎眼。
我在某个内部项目中做过一次对照实验：同一个 7B 开源模型，用某主流 GPU 推理框架在 A 型数据中心 GPU 上跑，FP16 精度，单条请求流式输出，稳定吞吐约每秒 90~110 个 token；而一台普通的双路 X86 服务器，用内存带宽优化过的 CPU 推理路径，同样 FP16、不量化，稳定吞吐约每秒 30~40 个 token。看起来差 3 倍，但如果把成本算进去：那台 GPU 的采购价是这台 CPU 服务器的 8~10 倍，功耗是 5 倍以上，而且为了塞进数据中心还得考虑供电、散热、机架空间。结论就变成了：在低并发、单路请求、对延迟不敏感的场景里，GPU 的性价比其实非常难看。
1.2 NPU “省电”标签背后的实际落差
NPU 在绝大多数宣传材料里都会强调 TOPS 数值，某款号称 30 TOPS 的端侧 NPU，听起来算力直逼独立显卡。但稍微懂行的人都知道，这个 TOPS 通常是稀疏计算的峰值，而且是 FP16/INT8 混合精度下的理论值。真正跑起一个标准 Transformer 模型，算子覆盖率、激活函数支持度、数据精度适配，每一个环节都可能让实际性能打三到五折。更麻烦的是，NPU 的算子库和编译工具链往往是私有 SDK，不同厂商的 NPU 之间没有任何通用接口，你在 A 家 NPU 上优化好的模型，搬到 B 家就得重写一半。
我并不是否定 NPU 在端侧的价值。在手机、边缘盒子、智能摄像头这类功耗和成本预算极紧的场景里，NPU 跑轻量级的视觉模型或语音唤醒模型，确实比 CPU 和 GPU 都合适。但如果你试图用服务器端 NPU 卡来跑 13B 甚至更大的大模型推理，就会遇到几个非常现实的坑：显存/内存带宽不足导致 batch 上不去，量化工具不成熟导致精度下降明显，推理框架适配晚一步导致你只能等厂商更新。这些坑我身边不止一个人踩过，最后都是默默换回 GPU 收场。
1.3 为什么这么多人只能在 GPU 和 NPU 之间选
说到底，GPU 和 NPU 的二分法是被厂商生态和惯性思维推出来的。打开任何一份 AI 硬件招标需求书，几乎是必选 GPU；打开任何一篇端侧 AI 报道，又必然强调 NPU。甲方不会主动提 CPU，因为写了 CPU 显得"不够 AI"；乙方也不敢推 CPU，因为客户会觉得你在糊弄。于是 CPU 顺理成章被排除在讨论范围之外。但这个思维惯性在真实项目里是要付出真金白银的——很多内部系统只是需要一个能跑模型的管道，根本不需要一秒处理几十条请求的极端吞吐，却被硬塞了高价加速卡。
我见过一个最典型的案例：某公司要做一个文档摘要工具，预计日调用量几千次，并发峰值不超过 10，团队采购了 4 张高端 GPU 卡，部署完发现 GPU 使用率常年低于 5%，运维成本倒是实实在在翻了几倍。后来换成一台配置不错的双路服务器做 CPU 推理，日调用量轻松扛住，整体成本下降了 70%。这个例子不是说 GPU 不好，而是说选型的第一件事应该是算清楚自己的真实负载，而不是先入为主地在两个广告词之间做选择。
2. 第三个答案：CPU 在推理链路中的真实定位与底层逻辑
2.1 CPU 的“平庸”参数为什么能干活
很多人一听 CPU 推理，第一反应是"那不是几十年前的老古董方案吗"。其实大模型推理的瓶颈和一个常识有关：解码阶段是访存密集型，不是算力密集型。生成每个 token 都需要把完整的模型权重从内存里读一遍（至少在 batch 较小、无法复用权重缓存时是这样），这时候内存带宽直接决定了你能跑多快。GPU 的 HBM 带宽确实惊人，但 CPU 服务器的内存带宽并没有想象中那么不堪。现代 X86 服务器配合多通道 DDR5，实际可用带宽普遍能到 200GB/s 以上，某些旗舰平台甚至接近 400GB/s。一个 7B 模型 FP16 权重约 14GB，按 250GB/s 算，每秒至少能完整扫过 15~20 次权重，换算成 token 就是每秒几十个，跟实际表现吻合。
关键还不只是内存带宽。CPU 近年来在指令集上不断加码，AVX-512、AMX 这类矩阵加速指令，允许你用单条指令完成大量乘加运算。配合量化（INT8/INT4），CPU 推理的有效算力被进一步放大。我在实测中发现，INT8 量化后的 7B 模型在 CPU 上吞吐能翻 1.5~2 倍，精度损失在大部分任务上都在可接受范围内。很多探索了 CPU 推理的人都会有一个相似的体验：它的上限不如 GPU，但在单路低并发场景下，差距没有想象中大。这不是一个"能不能跑"的问题，而是"够不够用"和"划算不划算"的问题。
2.2 实测场景：单机 CPU 跑 7B/13B 开源模型的真实成绩
为了把话说得更具体，我把自己在几个项目里采集到的实测数据整理了下表。测试环境是双路 X86 服务器（总计 64 核），全量模型加载到内存，使用某开源推理框架的 CPU 后端，输入提示约 200 token，输出 128 token，单条请求流式返回。数据是多次跑出来的稳定值，不是峰值冲刺值。
| 模型规模 | 精度 | 首 token 延迟 | 平均生成速度 | 总功耗（整机） |
|---|---|---|---|---|
| 7B | FP16 | 1.2s | 28~35 token/s | 约 180W |
| 7B | INT8 | 0.6s | 45~55 token/s | 约 190W |
| 13B | FP16 | 2.1s | 15~20 token/s | 约 200W |
| 13B | INT8 | 1.0s | 25~32 token/s | 约 210W |
这个成绩放到 GPU 面前确实不够看，但请结合两个背景来看。第一，这是纯 CPU 推理，没有调用任何加速卡；第二，整机功耗只有两百瓦出头，相比数据中心 GPU 动辄四五百瓦起步，优势非常直观。实际做内部工具时，25~50 token/s 的生成速度在大部分业务场景里已经够用——用户阅读本来就是 5~10 token/s，慢一点并不会影响体验；甚至在并行度够高时，还能同时服务 5~10 个用户，整体体验并不差。
2.3 CPU 选型里最常见的三个误判
CPU 推理的坑不比 GPU 少，最常见的是买了超高性能 CPU 却用不上。第一个误判是只看核数，以为核越多推理越快。实测发现 64 核比 32 核的提升常常只有 20%~30%，因为解码阶段大量时间在等待内存数据，CPU 核心再多也闲着。对 CPU 推理而言，内存通道数和频率的重要性不亚于核心数，优先保证至少 8 通道内存，比盲目堆核更有效。第二个误判是忽略单线程性能。推理框架在调度、字符处理、算子执行上依然依赖少量高主频核心，基频低的老型号 CPU 往往载不动大模型。第三个误判是内存容量配得太紧张。模型权重只是底数，KV cache 会随并发和序列长度快速增长，并发 8 路、长上下文场景下 KV cache 很容易吃掉十几个 GB，内存配到模型占用两倍以上才算合格。以上这三点我全都踩过，第一版 CPU 推理方案就因此翻过车，后来重新调整配置才跑顺。
3. 选型决策框架：别用“感觉”决定基础架构
3.1 三个决定性变量：并发、延迟、成本
与其纠结"谁性能强"，不如先把三个决定性变量摆到台面上：并发度、延迟要求和成本预算。不同业务在这三个维度上的取值差异，会直接给出完全不同的选型答案。并发低、延迟要求宽、成本敏感，CPU 是首选；并发高、延迟要求严、客户愿意为性能买单，GPU 是当然之选；端侧功能固定、功耗要求极苛刻、长期大规模铺开，NPU 才有入场的资格。这不是非此即彼，而是把变量拆开看，很多纠结都会自动消失。
我在实际评审方案时会用一个简单的打分表：
| 需求变量 | 低并发场景（<20 并发） | 中并发场景（20~100） | 高并发场景（>100） |
|---|---|---|---|
| 单 token 延迟容忍度 | 可接受 1~3s 首 token | 可接受 0.5~1s | 必须低于 0.3s |
| 推荐首选 | CPU（性价比最优） | GPU + CPU 混合 | GPU |
| 需要准备的成本系数 | 1x | 2~3x | 5~10x |
这张表不是真理，但能让人快速进入"按需求选型"的正轨，而不是被两个阵营的跑分带偏方向。
3.2 量化计算：每秒多少 token 才真正够用
更进一步的判断可以把业务指标换算成硬性的 token 吞吐指标。大模型推理的性能标准一般看首 token 延迟（TTFT）和生成阶段每秒 token 数。假设业务要求用户从发出请求到看到第一个字不超过 2 秒，模型单请求生成阶段按 40 token/s 计算，那么单台 CPU 服务器在同时服务 2~3 个用户时，首 token 延迟仍在可控范围内。但如果业务是允许 50 个人同时提问的客服机器人，每人半秒内必须有响应，这就考验硬件的峰值并发能力了，CPU 扛不住，GPU 批量推理的优势才真正发挥出来。
我习惯的做法是先估算峰值 QPS，再乘上一个典型交互的生成 token 数，算出每秒需要的总 token 吞吐，然后反推需要的硬件规模。曾有内部项目估算峰值每秒只需要 200 个生成 token，一台双路 CPU 服务器跑 INT8 7B 模型实时吞吐约为 50 token/s，因此预留 4 台做负载均衡就够了，总投资比起一台 GPU 便宜得多。这个结论完全是算出来的，不是拍脑袋。
3.3 训练与推理必须分开看待
还有一个常见的决策错误是把训练和推理混为一谈。训练阶段，反向传播对算力的需求是推理的好几倍，迭代时间长、数据吞吐大，这个阶段 GPU 几乎没有替代方案，认了就行。但训练完成后把模型部署为服务时，需求性质完全变了——推理请求是短时、并发、碎片化的，很多时候根本填不满一块 GPU 的算力池。我在多个项目里采用的策略是：训练/实验环境保留少量 GPU，生产推理先用 CPU 跑起来，等并发真的上来了再逐步扩容 GPU。这样做的好处是前期的资金压力小，架构上也保留了未来平滑升级的空间。
4. 混合部署的实操经验：不止“选哪个”而是“怎么搭配”
4.1 分层推理架构：让每一类硬件干自己最擅长的事
聊完选型，再聊聊我更推荐的一种做法：分层推理架构。不是把全部流量都压到同一个硬件上，而是根据请求的复杂度、重要性、频率做分级处理。
具体来说，我常用三层设计：第一层用规则引擎或小模型做意图识别和粗筛，跑在 CPU 上，成本几乎为零；第二层用 7B 级别开源模型处理大多数常规问题，可以在 CPU 或一个中等规模的 GPU 实例上跑；只有第三层，也就是真正需要强推理能力的长尾复杂问题，才交给高端 GPU 或者 NPU 集群。这种设计在实际业务中效果非常明显，曾经有一个客服摘要项目，80% 的请求在第二层就完成了响应，只有 20% 会走到第三层，GPU 的数量可以从最初的 8 卡缩到 2 卡，成本下降一半以上。
4.2 用 CPU 当“缓冲垫”解决 GPU 排队问题
第二个实战技巧是把 CPU 推理实例作为 GPU 服务的弹性缓冲。当突发流量涌来时，GPU 的并发能力再强也扛不住瞬间请求暴增，队列一旦加深，用户的首 token 延迟就会飙升。这时候如果后端有自动扩缩容机制，新拉起的容器是 CPU 推理实例，它虽然单个实例吞吐低一些，但胜在扩容快速、成本低，可以在几秒内补上容量缺口，承担相当一部分次要请求，给 GPU 释放出处理核心请求的余力。这个"CPU 垫底、GPU 冲峰"的组合拳，在好几次促销活动中都帮我稳住了服务的尾延迟表现。
4.3 实测中的意外问题与排查：超线程、NUMA 和内存分配
混合部署也不是都顺风顺水，有一些坑值得单独拿出来说一下。第一是超线程。CPU 推理框架在多线程跑算子时，超线程不仅不提速，反而可能因为共享缓存的争用导致性能倒挂。我的一台 32 核服务器，关掉超线程后推理吞吐竟然提升了约 15%。第二是 NUMA 拓扑。多路服务器上，如果推理线程和内存分配跨越了 NUMA 节点，跨节点的访存延迟翻倍，性能下降非常明显。建议把 CPU 亲和性和内存分配固定在同一节点，用工具确认内存实际落在哪个节点上，比盲目关超线程效果更直接。第三是虚拟化环境。很多云主机的 vCPU 是超卖资源，跑纯计算还行，跑内存密集型的 CPU 推理就原形毕露，实测同一配置的物理机比某云虚机快了一倍多。现在我再做性能评估时，一律先在物理机上跑一次基准，再考虑虚拟化偏移量。
5. 未来两三年，推理硬件选型会怎么变（基于个人观察）
5.1 芯片厂商正在悄悄“重新发明 CPU”
一个值得注意的趋势是，传统 CPU 厂商开始在新一代芯片里集成针对 AI 推理的加速指令和更宽的向量单元。这不是 NPU 那种独立的硬件模块，而是把加速能力直接放进 CPU 的处理管线中。带来的直接好处是程序员可以不改代码，只靠升级硬件就获得显著的推理速度提升。我推测未来两三年，CPU 推理在主流模型上的性能还会继续上涨，这会让它在中小负载场景里的性价比优势更加明显。
5.2 软件栈成熟度正在成为新的选型标准
过去人们选 GPU 很大程度上是冲着生态去的——框架、算子库、部署工具都是现成的。但当 CPU 推理的框架成熟度提升后，情况会变化。现在已经有相当不错的开源推理框架支持 AVX-512/AMX 等指令优化，支持 INT8/INT4 量化，甚至可以在纯 CPU 环境下直接跑常见的开源模型格式。相对而言，NPU 的软件栈依然是最大软肋，各家 SDK 封闭、算子覆盖参差不齐，同一个模型在不同 NPU 上表现差异极大。可以预见，软件栈的成熟度和开放程度，会比峰值 TOPS 数值更能决定一款推理硬件的真实竞争力。
5.3 给小型团队的建议：先用 CPU 验证，再按需升级
如果你所在团队资源有限、技术栈还在早期，我会建议你不要一开始就采购昂贵加速卡。第一步，把手头的普通服务器或高性能台式机当作推理测试床，跑通完整的推理链路：模型加载、请求处理、流式返回、并发控制、监控告警。第二步，记录下真实的吞吐和延迟数据，评估在当前业务量下 CPU 是否已经可以覆盖需求。第三步，只有当你发现延迟已经影响到用户体验或并发上不去了，才考虑引入 GPU 或 NPU，并且优先选择可以直接对接现有推理框架的硬件，避免被私有生态绑架。这套路线的核心逻辑是先验证业务需求，再为验证后的真实缺口买单，而不是反过来先买硬件再找理由。
我在多个项目里用这套方法完成推理服务落地，最直观的感受是：很多所谓"硬件不够用"的判断，其实是需求没定义清楚、优化没做充分，甚至只需要改一下并发策略和量化精度就能解决。CPU 推理给了团队一个低成本试错的窗口期，这个机会窗口在 AI 项目快速迭代的早期显得尤为珍贵。至于 GPU 和 NPU 的经典二选一，我现在的回答更倾向于：真正成熟的团队不会被某个硬件标签锁死，他们会把手头的每一种算力都放进工具箱，让整个系统在成本、性能、稳定性之间找到自己最舒服的平衡点。
