ASR 用 GPU 还是 CPU：模型规模与并发的账

2026-08-24

语音识别（ASR）该跑在 GPU 还是 CPU 上，没有统一答案。它取决于你的并发量、延迟要求、模型规模，以及请求是均匀到达还是尖峰到达。

多数团队的默认假设是”GPU 一定更好”。这个假设在训练环节大致成立，但推理环节完全是另一回事——推理面对的是真实的请求流，而请求流有闲有忙。一块卡忙的时候确实猛，闲的时候一样在计费。判断标准不是峰值算力，而是这台机器有多少比例的时间在真的干活。

一句话结论

请求稀疏的内部工具（一天跑几十次）：用 CPU。GPU 大部分时间在空转，买的是闲置。
高并发在线服务 + 模型不小：用 GPU。这是 GPU 的主场。
大批量离线转写：用 GPU，而且要把攒批开到位——离线场景没有延迟约束，吞吐就是一切。
端侧 / 嵌入式：用 CPU（或设备自带的 NPU）。这个场景根本没有 GPU 这个选项。
拿不准的时候：先用 CPU 跑通全链路，等看到真实负载曲线再决定。

这篇文章不会给你的东西

先说清边界：本文不写任何显存需求、GPU 型号、每张卡能跑多少路、成本金额、性能倍数。

原因很简单——这些数字下个月就可能变。硬件在换代，推理框架在优化，模型在迭代，任何一个具体数字写下来都会很快过期，而读者拿着过期数字做决策，比没有数字更危险。

这篇给的是框架和该算哪几笔账。数字请你拿自己的模型、自己的机器、自己的流量去实测。

枢纽概念：攒批换的是什么

整篇选型的核心，是一个取舍：

攒批（batching）会增加单个请求的延迟，但能提高整体吞吐。

GPU 的算力优势来自并行。一次只处理一条请求，大量计算单元是闲着的；把多条请求凑成一批一起算，单位时间处理的总量能明显上去。代价是先到的那条请求必须等后面的凑齐——它多出的等待时间，就是买来的吞吐。

这个取舍决定了场景分野：

实时对话：用户说完等着回应，多等一点就是体感变卡。这里攒批窗口必须压得很短，甚至不攒。于是 GPU 的并行优势被限制住了，投入产出比大打折扣。
离线转写：一批录音今晚跑完明早看结果，单条延迟多几秒毫无影响。这里可以放开攒，GPU 的优势能吃满。

所以更准确的说法不是”GPU 更快”，而是：GPU 的优势要靠攒批兑现，而攒批需要场景允许你等。你的场景不允许等，这份优势就兑现不了多少。

该算的几笔账

选型前把下面这几项写下来，答案往往就自己浮出来了。

第一笔：峰值并发是多少。 不是日均，是峰值。系统必须按峰值配容量，日均只决定你有多少时间在浪费。

第二笔：请求怎么到达。 均匀到达还是尖峰到达，是完全不同的两种账。均匀到达的服务，机器利用率可以做得很高；尖峰到达的服务（比如只在上班时段有量），峰值时段之外的资源全在空转。GPU 空转的代价比 CPU 空转高得多，这一条最容易被忽略。

第三笔：延迟要求。 分清是”用户在等”还是”机器在等”。前者的延迟预算以毫秒计，后者可以按小时算。这一笔直接决定你能不能攒批。流式场景还要额外看首字延迟，详见RTF 和实时率怎么读。

第四笔：模型规模。 小模型在 CPU 上跑得动，大模型在 CPU 上会难受。但注意——“大小”是相对于你的延迟预算而言的，同一个模型在离线场景绰绰有余，在实时场景可能就吃力。

第五笔：能不能攒批。 见上一节。这是唯一一笔能把 GPU 的账彻底算翻的项。

第六笔：运维复杂度。 这一笔经常被漏掉。GPU 环境的驱动、运行时与框架依赖，版本之间还相互牵制，维护成本明显高于纯 CPU 环境；镜像更大、启动更慢、排障链条更长、能接手的人更少。如果团队里没人熟悉这套，这笔账可能比算力账还贵。

场景对照表

你的场景	倾向选	为什么
低并发内部工具（一天几十次）	CPU	请求稀疏，GPU 绝大部分时间空转；省下的运维复杂度也是实打实的收益
高并发在线服务	GPU	并发够高才撑得起卡的利用率；此时 CPU 方案要堆很多台机器才追得上
大批量离线转写	GPU	无延迟约束，可以放开攒批，吞吐吃满
端侧 / 嵌入式	CPU / NPU	没有 GPU 这个选项，路线是小模型 + 量化 + 端侧推理引擎
请求稀疏的长尾服务	CPU 优先	与内部工具同理；若确实需要大模型，考虑按需拉起而非常驻

表里没有”看情况”这一行，但真实世界有。混合负载（白天实时、夜里批量）就是常见的例外：可以用同一批 GPU 资源分时复用，但必须让实时流式请求优先于离线批量任务，否则一批长音频会把实时通道堵死。这属于并发与批处理的调度问题。

流式的特殊性：按路数算，不是按 QPS 算

有一个坑必须单独拎出来。

流式请求是长连接。 一路连接在整通对话期间都占着资源，从接通到挂断可能是几分钟。而非流式的整段转写是一次性的请求-响应，处理完就释放。

这意味着流式服务的容量模型要按并发路数算，不能按每秒请求数（QPS）算。用 QPS 那套思路估容量，会严重低估资源占用——每秒只有两个新会话接入，听起来很轻松，但如果每通对话平均持续五分钟，同时在线的路数是另一个量级。

选型时如果搞错了这个口径，无论选 GPU 还是 CPU，容量都会算错。流式与整段两种模式的完整差异见流式识别和整段识别的区别。

一个务实的建议：先用 CPU 跑通

如果你还在从零搭，我的建议是：先用 CPU 把全链路跑通，再谈优化。

理由有三条：

一，很多场景 CPU 就够了。 尤其是内部工具、低频服务、小模型场景。跑通之后你会发现根本没有性能问题，那这一步就是终点。

二，过早上 GPU 会提前引入架构复杂度。 一旦上卡，批处理策略、显存管理、驱动版本、资源调度全都要跟着上，而这些复杂度在你还没搞清楚真实负载长什么样的时候，是纯负担。

三，跑通之后你才有基准。 有了能跑的 CPU 版本，你才知道瓶颈到底在哪一环——可能压根不在模型推理，而在音频前处理或后处理那几步。没有基准就上 GPU，很可能优化了一个不是瓶颈的地方。

先跑通，再压测，再看曲线，最后才决定要不要上卡。这个顺序反过来做，通常要走弯路。

常见问题

问：能不能先按 GPU 设计，反正以后量上来了不用改？

可以，但要清楚代价：你提前付了架构复杂度和运维成本，换的是一个不确定会不会到来的未来。更稳的做法是把推理层抽象出来，让上层不关心底下跑在什么设备上，这样将来切换的成本就低了。抽象成本远低于提前上卡的成本。

问：CPU 上跑不动大模型，是不是只能换 GPU？

不一定。先看能不能换更小的模型——很多场景对精度的要求没有想象中高，小模型加上针对性的后处理，效果可能够用。量化也是一条路，端侧方案基本都走这条路线，见端侧离线识别为什么跑得动。确认这些都不行，再考虑上卡。

问：怎么知道我的 GPU 利用率够不够？

看两件事：一是忙闲比，机器有多少比例的时间真的在算；二是批大小的实际分布，如果绝大多数批次里只有一两条请求，说明你的流量密度撑不起攒批，GPU 的并行优势没有兑现。这两个数只能实测，任何人给你的经验值都不适用于你的流量。