说实话，写这篇文章之前我犹豫了很久。因为这一年的经历实在太曲折了，从一开始信心满满地觉得"不就是个语音转文字嘛"，到中间被各种坑折磨得怀疑人生，再到最后终于跑通上线——这个过程，我觉得值得记录下来，也许能帮到正在踩同样坑的兄弟。

先说背景。我在一家给政府单位做信息化项目的公司，去年接了个活儿：给某省级单位的内部会议系统加上实时语音转写功能。听起来不复杂对吧？但甲方有三条铁律：

• 网断死。不是"尽量别联网"，是物理拔网线那种断。
• 必须跑在国产芯片上。服务器是华为鲲鹏+昇腾的，操作系统是麒麟，没得商量。
• 要能分清谁在说话。领导们开会，得知道哪句话是谁说的，最后生成的会议纪要要按人分段。

就这三条，直接把市面上 90% 的方案干掉了。

第一阶段：我以为开源能救我

我最先想到的当然是开源。GitHub 上 Whisper、FunASR 这些项目 star 数都好几万，社区也活跃，文档看起来也挺全的。我心想，下载下来改改不就完了？

现实给了我三记耳光。

第一巴掌：断网环境装不上。

FunASR 依赖一堆 Python 包，正常开发机上 pip install 一把梭没问题。但甲方那个环境是纯内网，连 PyPI 都访问不了。我只能在外面一个个把依赖包下下来，拷到 U 盘里带进去装。光是解决依赖冲突就搞了三天，最后发现有个底层库的版本和麒麟系统不兼容，彻底卡死。

第二巴掌：昇腾卡跑不起来。

开源模型默认都是 NVIDIA CUDA 的。昇腾的计算框架是 CANN，底层算子完全不一样。我试着用华为的迁移工具转，转是转过去了，但推理速度慢得离谱——一段 10 分钟的音频要跑 8 分钟才出结果，这还叫什么"实时"？后来我研究了一下，发现是好几个关键算子没有做昇腾的原生适配，走的是 CPU 回退，性能直接塌了。

第三巴掌：多人说话分不清。

好不容易把 ASR 凑合跑起来了，甲方又问：能分清谁说的吗？我去找开源的说话人分离方案，跑了一下，三个人的会议它给我分出了五个人，而且同一个人前半段是"说话人1"后半段变成了"说话人3"——这就是所谓的"聚类漂移"，在有回声的会议室里特别严重。

折腾了将近两个月，我不得不承认：开源模型是个好东西，但它只是个毛坯房。要住人，还得精装修，而且这个装修的工程量比买毛坯房贵得多。

第二阶段：大厂方案，报价劝退

开源走不通，那就看看商业方案呗。我前后联系了三家大厂，情况大概是这样的：

A 厂报价最高，光是私有化部署的授权费就六位数起步，而且按年收费。我们那个项目预算本来就紧，这个价格直接超标。

B 厂倒是便宜一些，但他们的私有化方案只支持 NVIDIA 的卡，问能不能跑在昇腾上，对方很坦诚地说"目前还不支持，在规划中"。规划中——这三个字我太熟了，通常意味着遥遥无期。

C 厂技术上倒是可以，但部署周期要两三个月，而且需要他们的工程师驻场调试。甲方那个涉密环境，外部人员进出审批流程你懂的，光走手续又是一个月。

所以你看，大厂的问题不是技术不行，是要么太贵，要么不适配信创，要么交付周期太长。对于我们这种"预算有限、信创刚需、交期紧"的政企项目来说，真的很尴尬。

第三阶段：一个意外的发现

说来也巧。有天晚上我在技术群里吐槽昇腾适配的问题，一个做智慧法院项目的哥们私聊我，说他们用了一家叫"灵声智库"的方案，在昇腾 310B 上跑得还挺稳的。

我当时的第一反应是：没听说过啊，靠谱吗？小厂的东西能行？

但死马当活马医吧，我要了他们的测试包试了一下。

不试不知道，确实让我有点意外。

首先是部署。

人家给的是一个完整的离线安装包，不是那种"先联网下载依赖"的假离线。Docker 镜像、模型文件、配置脚本全打包好了，我在甲方的麒麟+昇腾环境上大概花了半天就跑起来了。对比我之前折腾开源方案的三天地狱，这个体验好太多了。

然后是性能。

我拿同一段 30 分钟的会议录音做测试。这个方案在昇腾 310B 上的转写速度大概是 30 多倍速——也就是说 30 分钟的音频不到 1 分钟就出结果了。关键是，它是流式的，音频一边进一边出文字，延迟很低，体验就像你看直播字幕一样。

最让我惊喜的是说话人分离。

它用的好像是一个叫 CAM++ 的声纹模型，我指定了会议有 3 个人之后，区分得相当准确，基本没出现之前开源方案那种"一个人被拆成两个人"的问题。而且它支持提前录入声纹，录入之后输出的结果直接就是"张主任：……""李处长：……"，不用再手动对应。

我当时就跟同事说，这东西不像是随便套了个开源模型的壳子。后来跟他们技术的人聊了一下，了解到底层模型确实是基于学术界的主流架构，但在工程层面做了大量自己的东西——比如高并发调度的网关设计、昇腾算子的原生适配、声纹聚类的增量优化这些。用他们的话说，"模型只是地基，上面的楼是我们自己盖的"。这话虽然有点王婆卖瓜，但从实际测试效果来看，确实站得住脚。

第四阶段：上线和一些实测数据

最后这个方案通过了甲方的安全审查和功能验收，在今年年初正式上线了。跑了大半年，我分享一些实际运行中的数据，供各位参考：

硬件配置：一台标准机架式服务器，鲲鹏 920 CPU + 一张昇腾 310B 推理卡，装的是麒麟 V10 操作系统。整台服务器的采购成本，大概也就几万块钱的事。

并发能力：日常同时开 5～8 个会议室做实时转写，完全没有压力。我后来压测过，单卡能稳定撑到 100 路并发都不掉链子，这个数字其实远超我们的实际需求。

准确率：普通话场景下，干净环境识别率体感在 95% 以上。会议室有点回声的情况下会稍微降一些，但加上热词之后，那些专有名词——各种政策文件名称、领导姓名、项目代号——识别率提升非常明显。

一个小细节让甲方很满意：会议结束后，系统会自动用内置的大模型生成一份结构化的会议纪要，包括议题摘要、各方观点、待办事项。以前这个活儿是办公室的小姑娘手工整理的，一场两小时的会要整理大半天。现在基本上会一结束，初稿就出来了。

踩过的坑，和一些选型建议

写到这里，我想把这一年的经验总结成几条实在的建议，给同样在做政企语音识别选型的朋友：

1. 别低估"断网部署"这四个字的含金量。

很多方案号称"支持私有化"，但你真拿到离线环境里一试，各种依赖缺失、各种服务启动失败。真正能做到"U 盘拷进去就能跑"的方案，才是真的私有化。这一条，建议在选型阶段就让厂商提供离线安装包做实测，别光听 PPT。

2. 信创适配一定要看"原生适配"还是"兼容适配"。

有些方案说支持昇腾，其实是通过 CPU 回退来"兼容"的，性能差十倍都不止。一定要问清楚：关键算子是不是在 CANN 上做了原生实现？有没有昇腾环境下的实际压测数据？最好让对方提供 npu-smi info 的运行截图，看 NPU 利用率是不是真的在干活。

3. 说话人分离是刚需，但大部分方案做不好。

尤其是在有回声、有背景噪音的真实会议室里。建议拿你们自己录的、最嘈杂的那段会议录音去测，别用厂商提供的"demo音频"——那些都是录音棚级别的音质，测了也白测。

4. 别只看识别率，要看全链路。

从音频采集、实时转写、说话人区分、热词优化、到最终的会议纪要生成——这是一条完整的链路。有的方案 ASR 本身还行，但没有说话人分离；有的有分离但没有大模型做后处理。找一个全链路打通的方案，能省掉你大量的集成工作。

5. 成本核算要看总账，不能只看授权费。

大厂方案授权费高，但部署快、有保障。小厂方案便宜，但万一跑不起来呢？开源方案免费，但你自己的人力成本呢？我自己的经验是：最终落地成本 = 授权费 + 硬件成本 + 适配改造人天 + 后续运维。把这四项加起来比较，才有意义。

最后说两句

一年前接这个项目的时候，我觉得语音识别是个成熟技术，应该很好搞。实际做下来才发现，技术成熟和工程成熟完全是两回事。尤其是在信创+断网+多人会议这种复合约束条件下，能真正跑起来的方案，比我想象的少得多。

我不是要给谁打广告，每个项目的情况不一样，适合我的不一定适合你。但我的建议是：别光看参数表，一定要拿到测试包在自己的环境里跑一遍。真金不怕火炼，跑得起来的就是好方案。

希望这篇流水账能帮到正在选型的你。有问题欢迎评论区交流，看到会回。