从CPU-only到GPU/NPU，聊清楚并发、内存、说话人和后处理到底怎么影响配置

企业第一次做语音识别私有化部署，最常问的一句话通常是：10路、30路、50路并发到底需要什么服务器？

这个问题看起来应该有一个很标准的答案，但真正做项目以后会发现，同样是30路实时识别，如果只是普通话ASR，和同时开启说话人、标点、热词、文本修正，甚至再叠加会议纪要，服务器压力完全不是一个量级。

所以这篇不打算给一个“万能配置表”，而是把中小规模实时ASR的配置逻辑拆开。下面的配置范围可以用于前期预算和方案设计，但正式采购前仍然建议在目标服务器上做阶梯压测。

一、先把“10路、30路、50路”说清楚：到底指什么路数？

企业项目里最容易混淆的，是“在线连接数”和“同时活跃语音路数”。

例如有50个WebSocket连接在线，并不代表50个人从头到尾一直在讲话。会议和客服场景里通常存在大量静音，VAD会过滤一部分无效音频。真正决定模型计算压力的，是同时有多少路音频处于活跃状态。

所以做容量规划前，至少要确认三个数字：

• 最大在线连接数：最多有多少客户端保持连接；

• 峰值活跃路数：同一时刻真正持续讲话的音频有多少路；

• 目标冗余：生产环境通常不能按100%资源跑满，需要留出故障、峰值和扩展余量。

如果客户说“50路并发”，最好继续问一句：是50个连接，还是要求50路持续音频同时实时转写？

二、真正决定服务器配置的，不只是ASR主模型

一套能上线的实时语音识别服务，往往不只有一个ASR模型。

因此，下面谈10路、30路、50路服务器时，默认指的是“实时ASR + VAD + 基础标点/热词”这一类常规链路。如果同时启用重型说话人模型或大模型后处理，配置要单独往上加。

三、10路实时ASR：通常没必要一开始就上GPU

10路属于比较典型的小规模实时识别场景。内部会议、客服试点、小型业务系统、单部门语音接入，经常落在这个区间。

一个比较稳妥的CPU-only起步配置可以参考：

如果目标只是10路标准普通话实时识别，CPU-only通常更简单：部署成本低、驱动少、维护也容易。对于内网、国产CPU或信创环境，10路也比较适合作为第一阶段POC规模。

但如果10路里还要实时说话人分离、实时文本纠错甚至同步跑LLM，就不能再把它当成“只有10路ASR”的配置。

四、30路实时ASR：开始进入“必须认真做容量测试”的区间

30路并发通常已经不是简单Demo了。企业客服、多个会议室、小型指挥调度、行业平台都可能出现这个规模。

CPU-only方案可以参考：

30路最容易出现的问题，不是“完全跑不动”，而是刚开始看起来正常，满载以后P95延迟慢慢上升。所以这个规模开始，不能只看平均CPU利用率，还要看持续满载时的实时率和尾延迟。

如果出现下面几种情况，可以考虑直接转GPU/NPU路线：

• 目标CPU性能一般，CPU-only需要占用大量核心；

• 未来很快会从30路扩到50路甚至更高；

• 每路都要启用说话人或其他声学模型；

• 客户对延迟和峰值冗余要求较高；

• 同一服务器还需要处理大量离线录音。

五、50路实时ASR：CPU仍然能做，但要开始算“总拥有成本”

50路是一个比较有意思的分界点。技术上，经过优化的ASR完全可以继续走CPU-only；但如果为了50路堆到很高规格的CPU，整机价格、功耗和未来扩容成本可能开始接近一张AI加速卡方案。

CPU-only路线可参考：

如果业务已经明确会继续增长，50路时就应该考虑架构能不能横向扩展，而不是只想办法把所有路数硬塞进一台机器。

更合理的思路可能是：ASR服务做成独立节点，业务层按会话调度。以后从50路扩到100路时，可以增加节点，而不是整体推翻重做。

六、10/30/50路服务器配置，放在一起怎么理解？

这张表只能作为方案前期的“预算级参考”，不能直接作为验收承诺。同样的30路，在不同CPU、模型量化、采样率、说话人模块和音频活跃率下，实际资源占用可能有明显差异。

七、为什么有些项目30路就要GPU，有些50路还能CPU-only？

因为路数只是表面指标。真正决定算力的是每一路到底跑了什么。

以下因素都会把单路成本往上拉：

• 模型更大，或者没有做量化和CPU优化；

• 电话8k、会议16k之外还要跑复杂前处理；

• 每路实时启用说话人分离；

• 句尾再跑一遍更重的Final模型；

• 对P95延迟要求非常低，需要保留更大算力余量；

• 同机还运行离线转写、会议纪要或LLM纠错。

反过来，如果模型轻、VAD有效、音频存在大量静音，而且业务只要求实时转写，CPU的性价比就会非常不错。

八、GPU和国产NPU什么时候真正有价值？

GPU/NPU的价值不只是“更快”，更重要的是在高并发下提供更高的算力密度。

如果同一台服务器未来要承载50路以上实时ASR，同时还要跑离线任务、说话人或者其他AI模块，AI加速卡通常比继续无限增加CPU核心更容易做容量扩展。

但有两个前提：

• 目标ASR模型已经适配对应GPU/NPU运行时；

• 并发数字必须在目标硬件上实测，不能把另一张卡或另一套模型的结果直接照搬。

特别是国产NPU项目，模型转换、算子、驱动和推理框架都会影响最终吞吐。采购时应该看完整服务压测，而不是只看芯片理论算力。

九、如果还要会议纪要或上下文纠错，最好把LLM和ASR分开算

现在很多项目已经不满足于“实时转成文字”，还希望继续做文本纠错、摘要、会议纪要、质检和问答。

这里最容易出现的错误，是把LLM算力也塞进原来的ASR服务器预算里。

ASR是持续、低延迟的流式任务；LLM则更像阶段性的大算力任务。两者如果抢同一套资源，满载时非常容易互相影响。

更稳妥的设计是：

实时ASR优先保证稳定和低延迟；句子或会议结束以后，把最终文本交给独立的文本后处理/LLM服务。

这样10路、30路、50路的ASR服务器配置才不会因为“大模型功能”被完全打乱。

十、中小规模ASR私有化，真正值得花时间的是POC，不是争论参数

对于10路到50路项目，其实没必要一开始就采购很重的服务器。最省钱的方法通常是先用目标环境跑一轮真实POC。

经过这一轮以后，服务器该买32核还是48核、要不要上GPU，往往就很清楚了。

十一、灵声智库在中小规模私有化项目里更强调“按真实业务配机器”

灵声智库目前更倾向于把服务器选型放在POC之后，而不是先给客户一个看起来很精确、实际上缺少条件的固定路数表。

对于10路、30路、50路这类中小规模实时ASR，可以根据目标CPU、内存、是否有GPU/NPU、音频格式、是否启用说话人、是否还有离线任务等条件，先给出参考方案，再通过目标服务器压测确定最终容量。

这种方式看起来没有“某台服务器固定支持多少路”那么简单，但更接近真实企业项目。因为客户最后要的不是一个漂亮数字，而是长期稳定运行。

十二、几个采购方经常问的问题

Q：10路实时语音识别一定要GPU吗？

通常不一定。如果使用已经优化的ASR模型，10路实时识别完全可以优先评估CPU-only。是否需要GPU，要看模型、说话人、延迟和其他AI任务。

Q：30路实时ASR用多少核CPU比较合适？

可以先从32-48核级别做预算和POC，但最终取决于目标CPU单核性能、模型和完整服务链路。建议做阶梯压测，而不是只按核心数线性推算。

Q：50路实时ASR还能用CPU吗？

可以，但应比较高规格CPU与GPU/NPU方案的总成本、功耗和后续扩容。若未来很快上百路，提前设计加速卡或多节点架构通常更合适。

Q：为什么同样是50路，不同厂商给的服务器差很多？

因为模型大小、量化方式、VAD、说话人、标点、Final处理、实时延迟指标和并发口径都不同。必须先统一测试条件再比较。

Q：CPU-only是不是一定比GPU便宜？

小规模通常更简单、更省部署成本；规模上升后，需要比较高核心CPU整机与GPU/NPU的总拥有成本，而不是只比较一块硬件价格。

Q：灵声智库能做10路、30路、50路私有化ASR吗？

可以按项目环境提供实时/离线ASR、WebSocket/REST API、热词、说话人等能力，并根据目标服务器做容量测试。最终并发与延迟以实际POC为准。

结语：中小规模ASR最重要的不是“配得越高越好”，而是配得刚刚合适

10路、30路、50路实时语音识别并不属于必须堆重型AI服务器的场景。很多项目用CPU就能完成，真正需要GPU/NPU的时候，再根据规模、延迟和附加能力升级。

服务器选型最怕两个极端：一是为了省钱把配置压到刚好跑满，生产环境没有任何余量；二是还没做POC就上很高规格硬件，最后大部分资源长期闲置。

更实用的做法始终是：先把业务链路说清楚，再用真实音频做阶梯压测，最后按目标并发加上合理冗余确定机器。

对中小规模私有化ASR来说，能稳定跑、容易维护、后面还能扩，往往比一开始追求最高配置更重要。