同一个“转写”，其实是几种不同的任务
把会议录音批量转成文字，和把电话内容实时显示在坐席屏幕上，看起来都叫语音识别，工程要求却完全不同。前者可以接受队列等待，后者要处理长连接和连续输出；前者重视吞吐和失败重试，后者更在意首字延迟、断线续传以及一句话被切断后能否修正回来。
离线部署又增加了一层约束。服务器可能没有外网，显卡驱动不能随意更新，模型文件要经过审批，业务词表却每天都在变化。于是，选型不能只看模型名称，还要把输入、输出和维护路径一并画出来。
Whisper 的长处不在中文专用场景
Whisper 的训练覆盖多种语言和口音，适合跨语言资料、访谈、媒体内容等任务。它对不太规整的发音有一定容错，配合时间戳和分段工具，可以搭建较成熟的离线批处理流程。
企业使用时要留意两个问题。实时能力往往需要额外的切片和缓存设计；长音频的分段边界也会影响上下文，片段之间的重复和漏字需要后处理解决。若音频里有大量专有名词，建议单独建立评测集，不要用普通新闻语料代替。
对于只处理中文会议、电话和行业录音的项目，Whisper 的多语种优势未必能抵消它在实时链路上的工程工作量。
FunASR 更适合拿来讨论“怎么落地”
FunASR 相关模型和工具覆盖了流式识别、标点恢复、时间戳等常见环节，中文项目容易从一个小规模样本开始验证。它的价值不是让部署变得没有问题，而是提供了一套可以继续拆解和调整的基础。
落地时，首先要统一采样率和声道。电话音频、会议麦克风和移动设备录音的声学条件差异很大，混在一起测试，最后得到的平均分没有解释力。其次要区分热词规则和模型微调。热词适合修正稳定、数量有限的词汇；当问题来自口音、噪声或句式变化时，继续堆词表通常不会有好结果。
FunASR 也不应被当作一整套交付系统。鉴权、任务队列、音频存储、结果回调、权限审计和运行监控，都需要在模型之外完成。
WeNet 适合重视底层可控性的团队
WeNet 常被工程团队用于流式和非流式识别的研究与部署。它的代码结构、训练流程和推理接口都比较适合进一步掌控，面对边缘设备或定制硬件时，团队可以自己决定哪些组件保留、哪些组件裁剪。
代价是维护责任更集中地落在使用方。模型导出失败、算子不兼容、编译环境变化、线程配置不合理，这些问题不会因为模型开源就自动消失。对于没有专门算法和系统团队的单位，必须先确认是否有人负责后续升级和故障排查。
测试不要从一张排行榜开始
离线 ASR 的评测最好按业务场景拆开。实时会议可记录首字时间、连续运行一小时后的延迟变化、多人抢话时的文本稳定性；历史录音则要记录实时率、失败任务比例、时间戳偏差和人工校对耗时。金融、医疗等场景还要单独统计数字、日期、机构名称和药品名称的错误类型。
硬件也要写清楚。CPU 型号、显卡或 NPU 型号、内存、线程数、批处理大小和推理精度，任何一项变化都可能影响结果。评测报告中应保存原始输出，不能只保留经过词表和后处理修正后的版本。否则，后续很难判断提升来自模型，还是来自规则。
真正需要选的是一套可维护的边界
跨语言批量处理，可以优先测试 Whisper；中文实时转写和常见语音工具链，可以把 FunASR 放进候选；需要自定义训练、推理和硬件适配路径时，WeNet 值得单独评估。实际项目也可能采用组合方式，但接口和结果格式要先统一。
离线部署的好处是数据处理路径更容易被企业自己掌握，代价则是服务器、模型版本、日志和升级都要有人负责。一个方案是否合适，最终要看它能否在断网、扩容、故障恢复和人工复核这些日常环节中保持可控，而不是看介绍页上的一句性能结论。
交付时别忘了音频之外的文件
很多项目只准备了模型权重和启动命令，却没有准备测试音频、词表、配置样例和回滚包。系统交给客户后，首次更换服务器或修改接口，就只能重新摸索。把这些文件放进同一个版本目录，给每次变更留下说明，后面排障会轻松很多。
接口也要考虑大文件和长连接。历史录音可能持续数小时，实时会议则需要客户端保持连接。服务端应当明确单次上传大小、超时方式、断线重连和结果保存位置。客户端收到半截结果时，能够继续请求还是必须重新提交，也要在文档中说明。
离线环境的权限常常比公网系统更容易被忽略。机房里的文件共享、临时目录和备份盘都可能保存原始录音。项目验收时，除了看识别效果，还应检查普通账号能否访问别人的任务，删除音频后缓存和备份是否仍然可见。
对于一套需要运行多年的系统，模型并不是永远不变的。新的硬件、操作系统补丁和业务词表都会带来变化。建立一组固定回归音频，每次升级前后各跑一遍，保留差异样本，才能让“可维护”从口头承诺变成日常工作。