1.1 开源语音识别的定义、技术链路与典型应用场景
我自己第一次接触开源语音识别是在一个会议转写项目里。当时团队想把手头几个小时的录音自动变成文字，预算有限，数据又不能出内网。找了一圈商业API，报价单看得我头皮发麻。后来有人扔给我一个GitHub仓库，说“你试试这个”。那是我第一次意识到，开源语音识别不是简单的“免费软件”，它更像一套可以拆开、改造、搬进自己机房的工具箱。它的核心是一组公开源代码的模型和工具，让你能在自己的硬件上完成语音到文字的转换过程，不用把音频传到别人的服务器上。这些项目通常包含预训练模型、推理代码、音频预处理脚本，有些还带微调工具和社区维护的文档。我后来在多个项目里反复验证一件事：开源语音识别的价值不在于零成本，而在于你拿到了控制权。
从技术链路来看，我习惯把它拆成几段来看。音频进来先做预处理，采样率统一、降噪、去除静音片段，这些步骤看着不起眼，实际对后面识别效果影响不小。我踩过的坑是直接拿手机录音丢给模型，背景风扇声让识别结果惨不忍睹。预处理之后是特征提取，把波形变成模型能吃的声学特征，常见的有Fbank、MFCC。接下去是声学模型和语言模型配合解码，声学模型负责听清发音，语言模型负责把词串成合理的句子。解码器再结合发音词典和语言模型打分，输出候选文本。后处理阶段做标点恢复、数字规范化、大小写处理。整条链路里每个环节都有开源实现，也能单独替换。我自己比较喜欢这种模块化设计，调哪个环节心里有数。
应用场景这块我观察下来，开源语音识别最常出现在几个地方。会议和访谈转写是典型需求，企业内网部署一套，录音不出门，转写结果直接进知识库。字幕生成也很常见，短视频团队用开源模型批量出字幕，成本比按分钟计费的云服务低很多。客服质检场景里，开源方案可以针对行业术语做微调，把“退保”“免赔额”这类词识别准。车载和智能家居对实时性要求高，模型要小、要快，通常跑在边缘设备上。医疗和司法领域对隐私和合规特别敏感，本地部署几乎是硬门槛。我接触过一个律所项目，庭审录音涉及当事人隐私，他们宁可多花硬件钱也要把模型放在自己机柜里。这些场景的共同点是：数据不能随便出门，需求又足够明确，开源语音识别正好卡在这个位置上。
1.2 开源与闭源方案对比：成本、隐私、可控性与合规边界
成本这件事我吃过亏。早年做一个客服语音分析项目，图省事接了某云厂商的语音识别API，前三个月账单还算温和。业务量翻倍之后，每月费用直接超过一个中级工程师的工资。后来换成开源模型加两台带GPU的服务器，硬件一次性投入，后面主要是电费和运维人力。我并不是说开源一定更便宜，小规模试点阶段，闭源API的按量付费反而更灵活。量大了之后，开源方案的单位成本优势才明显。我自己算账的习惯是把三年总拥有成本拉出来看：硬件折旧、运维人力、模型调优时间、故障排查成本，这些都要算进去。闭源方案的钱花在明面上，开源方案的钱花在暗处，选哪个取决于团队有没有相应的工程能力。
隐私和可控性是我最看重的两个点。闭源API意味着音频要离开你的网络，哪怕厂商承诺不存储，数据出域这件事本身就够让安全团队紧张。开源语音识别把模型放在你自己的服务器上，音频从采集到转写全程在内网闭环。我在金融客户那里做过对比，安全审计的时候，本地部署方案的材料薄薄一叠，云API方案要填的数据流向说明厚得像本书。可控性还体现在模型行为上。闭源API更新版本不会通知你，识别风格变了、某些词不准了，你只能被动接受。开源模型你可以锁定版本，可以针对自己的数据微调，可以改解码参数。我有个做方言识别的小团队，他们用开源模型加上自己标注的几千条语音，把地方口音识别率提了十几个点。这种深度定制在闭源方案里基本做不到。
合规边界需要单独拎出来说。开源许可证不是免死金牌，Apache 2.0、MIT、GPL各有各的义务。商用之前我会让法务过一遍许可证，确认能不能闭源分发、要不要保留版权声明、修改后的代码要不要开源。模型权重和代码的许可证可能不一样，Whisper的代码是MIT，模型权重也是MIT，用起来比较省心。有些模型研究用途和商用授权分开，得仔细看。数据合规方面，本地部署减少了跨境传输的风险，但录音采集本身要符合个人信息保护法的要求，告知同意、最小必要这些原则跑不掉。我通常建议客户在部署开源语音识别之前，先把数据分类分级做清楚，哪些音频能进模型、哪些要脱敏、日志保留多久，这些制度层面的东西比选模型更花时间。
1.3 开源语音识别生态全景：模型、推理框架、工具链与社区
模型这块我常跟人比喻成菜市场，摊位多、口味杂。Whisper是OpenAI放出来的多语种模型，开箱即用，英语和主流语言表现稳，社区里微调版本满天飞。FunASR是阿里达摩院开源的一套工具，中文场景打磨得比较细，流式和非流式都有现成方案。Vosk主打轻量离线，树莓派上都能跑，精度肯定不能跟大模型比，胜在省资源。Kaldi是老牌选手，灵活得像乐高，什么都能拼，学习曲线也陡。ESPnet偏研究向，论文复现方便。SpeechBrain把语音任务封装得比较友好，适合快速搭原型。我自己的习惯是：先看场景，中文实时字幕优先试FunASR，多语种离线转写先跑Whisper，嵌入式设备翻Vosk的文档。没有一个模型通吃所有场景，这点我深信不疑。
推理框架和工具链决定了模型能不能顺利跑起来。ONNX Runtime我用得最多，跨平台、CPU和GPU都能推，模型转换一次到处跑。TensorRT在NVIDIA显卡上速度快，转换过程麻烦一点，适合推理服务上线之后做优化。PyTorch原生推理写起来最直接，调试方便，生产环境里性能要看具体版本。工具链方面，ffmpeg做音频格式转换和重采样，sox做降噪和音量归一化，这些都是老面孔。VAD工具包用来切分长音频，我试过几个开源VAD，WebRTC的VAD轻量够用，Silero VAD对噪声环境更稳一些。标点恢复模型、逆文本归一化工具、说话人分离工具，这些周边组件拼在一起才叫完整的语音识别流水线。我经常跟团队说，别只盯着声学模型，周边工具选不好，整体体验照样拉胯。
社区活跃度是我评估开源项目的重要指标。GitHub上的issue响应速度、最近一次commit时间、文档更新频率，这些比star数更能说明问题。Hugging Face上模型卡写得清不清楚、有没有示例代码、评论区有没有人答疑，这些细节影响落地效率。我待过几个开源语音识别的用户群，有人问部署问题，社区里真有热心人贴日志、给命令。这种氛围对新手特别友好。反过来，有些项目代码质量不错，但维护者半年不露面，issue堆了几百条没人管，用起来心里没底。我现在的习惯是，选型之前先翻最近三个月的commit记录和issue回复，再看看有没有企业用户在背后持续投入。社区活跃不等于项目一定适合你，至少说明你遇到问题的时候不至于孤立无援。
1.4 模型选型与本地部署的总体评估框架（精度、时延、资源、许可证、可维护性）
精度是选型的第一道门槛，但我不会只看论文里的WER数字。公开测试集和你的真实场景往往差很远。我做过一个保险客服的语音项目，模型在AISHELL上WER很低，到了真实录音里，客户带口音、语速快、背景有键盘声，识别率直接掉一截。后来我们自己标了五百条业务音频做测试集，拿几个候选模型跑一遍，结果排名跟公开榜单完全不一样。CER对中文更直观，字错率比词错率更贴近实际阅读体验。长音频场景还要看模型对上下文连贯性的保持能力，有些模型切段之后前后文丢标点、丢术语，读起来很难受。我的建议是：精度评估一定要用自己的数据，测试集不用大，几百条覆盖主要场景就够，关键是真实。
时延和资源要放在一起看。RTF是实时率，小于1才能做实时转写，大于1只能做离线批处理。我见过团队拿大模型硬做实时字幕，GPU跑满还是延迟两三秒，用户体验很差。资源占用包括显存、内存、CPU核数、磁盘空间。Whisper large模型显存占用不低，小团队一张消费级显卡跑起来吃力。量化能降资源，INT8量化之后精度损失多少要实测，有些模型量化后WER涨两个点，业务能接受，有些模型直接崩掉。批处理能提高GPU利用率，离线转写场景把音频攒一攒再推，吞吐量能翻倍。CPU推理适合低并发场景，我试过在十六核CPU上跑Vosk做实时字幕，单路没问题，并发一上来就顶不住。资源评估要留余量，别按峰值算，按日常峰值的一点五倍到两倍留比较稳妥。
许可证和可维护性经常被低估。Apache 2.0商用友好，MIT更宽松，GPL要求衍生作品开源，AGPL对网络服务有额外要求。我碰过一个小团队想拿GPL模型做SaaS，法务看了直摇头。模型权重的许可证要单独确认，有些项目代码开源但权重限制商用。可维护性方面，我看三件事：文档是否覆盖部署和调优、版本发布是否有规律、社区是否有长期维护迹象。一个模型精度再高，部署文档只有半页README，团队里没人能把它跑起来，价值等于零。我倾向选那种有企业背书或者基金会支持的项目，出问题的时候有地方找答案。本地部署的总体评估框架可以简单画个表：精度用自有测试集打分，时延看RTF和端到端延迟，资源看显存和CPU占用，许可证让法务确认，可维护性看最近半年的社区活跃度。五个维度都过线再进入下一轮，别在单个指标上钻牛角尖。
2.1 主流开源模型谱系与代表方案概览
我电脑里有个文件夹叫“模型动物园”，里面按场景分门别类放着各种开源语音识别的权重和配置文件。每次有人问我该用哪个模型，我都先把这个文件夹打开，一边翻一边说：你看，这是Whisper全家桶，tiny到large塞了一排；这是FunASR的流式和非流式版本；Vosk那几个小包躺在角落里，树莓派项目专用的；Kaldi和ESPnet的recipe文档混在子目录里，像两本需要慢慢啃的旧手册。这个文件夹是我这几年攒下来的家底，每个模型进过一次真实项目才放进去。
Whisper是绕不开的一个起点。OpenAI把代码和权重都放出来之后，社区里用它做离线转写的团队特别多。我自己在英语会议转写上跑过Whisper large-v2，识别质量确实稳，标点符号也会自动带上，省了不少后处理功夫。中文场景下它也能用，但遇到行业术语或者口音重的录音，错误率会往上飘。有个做播客的朋友拿Whisper转自己的节目，聊天类内容识别得很顺，一到嘉宾讲技术名词就开始蹦错字。Whisper的强项在于多语种均衡，英语、西班牙语、法语这些大语种表现很平均，不用为每种语言单独找模型。
FunASR是后来才认真用起来的。有个客户要在客服系统里做实时字幕，我拿FunASR的流式模型试了一轮，中文识别响应很快，延迟控制得不错。它分了好几种模型规格，paraformer-large精度高一些，paraformer-online适合低延迟场景。我在一个方言夹杂普通话的访谈录音上对比过FunASR和Whisper，FunASR对西南官话的适应性明显好一截，Whisper那边有些词识别得莫名其妙。阿里团队对中文场景打磨得细，标点、数字归一化这些细节都有现成处理。
Vosk和Kaldi是另一种路数。Vosk我之前在树莓派上折腾过，模型包很小，内存占用低，跑起来风扇都不怎么转，识别精度不能跟大模型比，离线命令词和简单问答够用了。Kaldi像一套古老的积木，什么都能拼，但你要花时间读文档、调脚本。我认识一个做语音标注工具的小团队，他们拿Kaldi做强制对齐，图的就是灵活可控。ESPnet和SpeechBrain更像研究工具，论文复现和实验对比用起来顺手，生产环境部署得自己再包一层。
2.2 核心能力对比：识别精度、多语种与方言支持、实时性、鲁棒性与长音频处理
识别精度这件事我从来不信单一榜单。去年做一个医疗问诊的转写项目，公开测试集上Whisper large的WER比我试的另一个中文模型低一个多点。我就拿二十条真实问诊录音跑了一遍，结果反过来了。医生说话快、有专业术语、患者声音小，Whisper识别“房颤”这种词经常写成“房颤”以外的奇怪组合。那个中文模型针对医疗语料微调过，反而更准。精度对比一定要用你自己的数据，标个一两百条，覆盖主要场景和说话人类型，跑出来的排名才作数。我现在的习惯是每个候选模型跑三组数据：安静环境标准普通话、嘈杂环境带口音、专业领域术语密集，三组看下来基本能判断适不适合。
多语种和方言支持得分开说。Whisper天生多语种，切语言不用换模型，做国际会议转写省事。FunASR中文强，方言要看具体版本，有些方言模型单独发布，得去翻文档。我做过一个闽南语访谈的活，试了两个模型，效果都不太理想，最后找了一个专门做闽南语微调的社区模型才勉强能用。方言这条路没有银弹，得接受一个现实：通用模型在方言上表现参差不齐，真要做方言场景，找对应方言的微调版本或者自己标数据训练。
实时性和鲁棒性经常打架。Whisper large在GPU上跑实时转写，RTF能压到零点几，但遇到背景噪声大的录音，解码器会反复修正，延迟忽高忽低。FunASR流式模型在噪声环境下稳定性好一些，我在地铁车厢录音上试过，识别结果虽然也有错，延迟波动不大。长音频处理方面，Whisper默认切三十秒窗口，切多了会丢上下文，读起来前后不连贯。FunASR有长音频模式，内部做VAD切分再拼接，连贯性好一些。我自己处理长录音的习惯是先跑一遍VAD切句，按语义段落切，再逐段识别，比直接丢整段音频给模型效果好。
2.3 工程化对比：资源占用、推理速度、部署难度、许可证与社区活跃度
资源占用这块我踩过实实在在的坑。有次在客户的测试服务器上部署Whisper large，机器只有一张24G显存的卡，模型加载完剩不了多少余量，并发三路音频就开始排队。后来换medium版本，精度掉了一点，并发跑到八路才稳定。FunASR的paraformer-large显存需求低一些，同张卡上能跑更多并发。Vosk的模型包按兆算，十六核CPU上跑四路实时识别没问题，再多就顶不住。我一般会先问清楚部署环境的硬件条件，再反过来筛模型，而不是先看精度排行榜。硬件是硬约束，模型是软选择，顺序不能反。
部署难度差异很大。Whisper有现成的Python包，pip install之后几行代码能跑起来，调试也方便。FunASR的部署文档写得比较细，Docker镜像、服务化示例都有，跟着走基本能跑通。Kaldi的部署对新手不太友好，编译依赖多、脚本参数复杂，没有Linux经验的话会卡很久。Vosk有预编译的库，跨平台支持不错，Windows上也能用。许可证方面，Whisper是MIT，商用限制少。FunASR的模型和代码许可证要看具体发布页面，有些模型对商用有额外说明，我一般会让法务确认。Kaldi是Apache 2.0，商用友好。社区活跃度我习惯看最近三个月的commit和issue回复情况，Whisper和FunASR的社区响应都比较快，Vosk更新频率低一些但文档稳定，Kaldi的社区偏邮件列表风格，提问要等。
2.4 场景化选型建议：离线转写、实时字幕、嵌入式与边缘设备、企业私有化与行业定制
离线转写场景我首选Whisper large或者FunASR的paraformer-large。有个做播客后期的小团队找我搭转写流水线，他们一周出三期节目，每期一个小时左右。我用Whisper large加VAD切分，在单张消费级显卡上跑批量转写，一夜能处理十几期，第二天人工校对一遍就出稿。他们后来试过FunASR，识别结果差不太多，中文标点处理稍微好一点。离线场景对实时性没要求，精度优先，选大模型准没错。批处理记得把音频攒一攒，GPU利用率能翻倍。
实时字幕是另一套逻辑。我做过一个线上讲座的实时字幕项目，用FunASR流式模型，延迟控制在两秒以内，观众体验还不错。Whisper做流式得自己切窗口、自己处理上下文衔接，麻烦一些。实时场景里模型大小很关键，large模型延迟忽高忽低，medium或者small更稳。嵌入式设备就更有意思了，我拿Vosk在树莓派上做过离线语音控制，识别“开灯”“关窗帘”这些短指令很利索，模型包才几十兆。你让Whisper在树莓派上跑实时识别，基本不现实，内存和算力都扛不住。
企业私有化和行业定制是开源语音识别最能打的地方。我接触过一个保险公司的客服质检项目，他们需要识别“退保”“免赔额”“犹豫期”这些词，通用模型老出错。后来用FunASR做基础模型，拿几千条标注过的客服录音微调，术语识别率提了一大截。整个模型跑在内网服务器上，录音不出机房，安全部门很满意。行业定制这条路需要数据准备和微调经验，不是所有团队都有这个能力。我一般建议客户先拿通用模型跑基线，看错在什么地方，再决定要不要走微调这条路。有些场景通用模型够用，微调反而是过度工程。
2.5 模型评估方法与测试集设计：WER与CER、RTF、冷启动、并发与稳定性
评估这件事我习惯从测试集设计开始。公开测试集像标准试卷，能测出基本水平，测不出真实场景的坑。我一般会跟客户要一批真实音频，覆盖不同说话人、不同设备录音、不同背景噪声类型。标注的时候我让团队把术语、数字、人名单独标出来，后面看错误分布的时候能定位到具体类型。测试集不用大，三五百条就够，关键是要有代表性。我见过团队拿一千条安静环境录音测出来分数很漂亮，一上线遇到嘈杂录音就翻车。测试集设计要故意刁难模型，把最难的情况放进去。
WER和CER要看场景。英文场景WER直观，中文场景CER更准。有个做教育录播的朋友发现模型WER很低，但识别结果里数字全写成阿拉伯数字，标点时有时无，学生看着别扭。后来他们单独统计了标点准确率和数字格式正确率，问题才定位清楚。RTF测试要模拟真实负载，单路跑和八路并发跑出来的数字完全不一样。我习惯用实际的音频流跑满三十分钟，看RTF波动范围和内存增长情况，短时间跑出来的数字参考价值有限。
冷启动和并发稳定性经常被忽略。服务刚启动第一路请求延迟特别高，模型加载、显存分配都在这时候发生，生产环境要预热。我一般会在服务上线前跑一轮预热请求，把模型完全加载好再接入流量。并发测试要逐步加压，看什么并发数开始出现延迟抖动和识别超时。有个项目我们测到十六路并发时内存开始缓慢增长，查了一周发现是解码器缓存没清理干净。这类问题不上并发测试根本暴露不出来。稳定性方面我还会跑长时间浸泡测试，八小时连续识别，看是否有内存泄漏和精度漂移。开源模型不是跑通就完事，这些工程细节决定能不能上生产。
3.1 本地部署前置准备：硬件选型、操作系统、依赖环境与模型获取
每次有人在群里问我“语音识别模型怎么本地跑起来”，我第一句话都是先问硬件。这事儿跟买鞋一个道理，得先量脚。GPU型号、显存大小、磁盘读写速度、内存带宽，这些数字摆出来，能选的模型范围就少了一大半。我自己有台旧工作站，一张RTX 3090二十四G显存，跑Whisper large勉强够用，并发一多就喘。后来加了一张A10，把流式识别和大模型离线转写拆开跑，才算是把硬件利用率拉顺了。CPU方案不是不能玩，Vosk在十六核的机器上跑四路实时没问题，但你要拿纯CPU跑Whisper large，等结果的时间够泡两杯茶。
操作系统这块我得啰嗦两句。Ubuntu 20.04和22.04是我用得最顺的两个版本，NVIDIA驱动、CUDA、cuDNN这条链子的文档最全，踩坑了搜到的答案也最多。CentOS系在企业内网里常见，客户机房十台有八台是CentOS 7，但它对新版GPU驱动的支持得手动折腾，装的时候要格外小心内核版本和驱动匹配。Windows能跑，Python环境配好了也行，但生产环境我基本不推荐，长期跑服务的稳定性还是Linux省心。macOS做开发调试挺好，M1/M2芯片跑推理也有社区方案，就是部署到生产服务器的时候得做跨平台适配。
依赖环境这件事我吃过亏。有回在客户机器上装FunASR，Python版本是3.6，torch装最新版直接报错，退回旧版本又跟另一个库打架。后来我养成了一个习惯：每个项目单独建conda环境，Python版本锁定在3.8到3.10之间，pip安装之前先看requirements里的版本约束。模型获取的渠道也得留意，Hugging Face下载有时候慢，国内可以用镜像站，但镜像同步有延迟，新发布的模型不一定有。许可证文件建议跟着模型一起归档，尤其是商用项目，后面法务审的时候不至于抓瞎。
3.2 典型部署路径：命令行推理、Python服务、Docker容器与API服务化
刚开始玩的时候我都是从命令行推理入手的。Whisper装完，whisper audio.mp3 --model large敲下去，进度条走起来那一刻特别有成就感。这种方式适合验证模型能不能跑、效果大概怎样，快速试错用。麻烦在于参数多了记不住，每次要翻文档，批量处理还得自己写循环脚本。我一般会在项目早期用命令行跑几轮，确认模型和音频匹配度没问题再往下走。
Python服务是稍微正式一点的玩法。拿FastAPI或者Flask包一层，把模型加载放在服务启动的时候，请求进来直接推理返回结果。这种结构调试方便，加日志、加监控、加业务逻辑都顺手。我做过一个会议转写服务，接口收音频文件，内部做VAD切分、逐段识别、拼接输出，整个流程用Python串起来，客户那边通过HTTP调用就行。要注意的是模型加载很吃内存，服务启动时间可能几十秒，别在请求处理里反复加载模型，那是新手常犯的错。
Docker容器化是往生产环境走的必经之路。镜像里把CUDA、Python、模型权重全部打好，换台机器docker run就能起来，环境一致性有保障。我一般会做两层镜像：基础镜像装驱动和依赖，应用镜像叠加代码和模型文件，更新的时候只重建应用层。API服务化再往上走一步，用Kubernetes或者docker-compose管多个副本，前面挂Nginx做负载均衡，健康检查、自动重启这些机制加上去，才算是能扛住线上流量的结构。这条路我走过好几遍，每次都有新坑，但走通之后确实省心。
3.3 性能与成本优化：量化与剪枝、批处理、GPU与CPU异构推理、缓存与并发调优
性能优化这件事，我一般是先看瓶颈在哪再动手。有次客户抱怨推理太慢，我上去一看，GPU利用率只有百分之十几，大部分时间花在音频解码和VAD切分上，模型本身跑得飞快。后来把预处理改成并行流水线，整体吞吐翻了将近三倍。量化是另一个常用手段，Whisper的int8量化版本显存占用能降差不多一半，精度损失在半到一个点WER之间，看场景能不能接受。剪枝我用得少一些，语音模型的结构化剪枝需要重新训练调优，投入产出比得算清楚。
批处理是个立竿见影的招。GPU天生适合并行，把多条音频攒成一个batch送进去推理，吞吐量提升明显。离线转写场景我一般把batch size设到八或者十六，再大显存扛不住。实时场景batch不能太大，延迟会上去，得在吞吐和延迟之间找平衡点。GPU和CPU异构推理也值得说，VAD切分、音频重采样这些轻量操作放CPU上跑，重模型推理放GPU，两边并行不打架。我有个项目就是这么搭的，CPU核数多分一点给预处理，GPU专心跑识别，整体资源利用率比全塞GPU上高不少。
缓存和并发调优是生产环境的日常功课。模型加载后的预热请求一定要做，第一路请求延迟高得吓人，不预热直接接流量会出事故。解码器缓存、特征缓存这些细节要看具体框架，有的框架内部做了缓存复用，有的需要手动配置。并发数不是越高越好，我一般从低往高压，观察延迟曲线和内存增长，找到拐点就停在拐点前面一点。有个项目我们压到十二路并发时P99延迟突然跳起来，查下来是显存碎片问题，加了定期清理策略才稳住。
3.4 数据安全与运维：离线隐私保护、权限审计、日志监控、版本管理与模型更新
做企业项目的时候，数据安全是绕不过去的门槛。我接触过一家做法律咨询的公司，客户录音涉及案件细节，绝对不允许出内网。整个系统部署在他们自己的机房，模型推理、文件存储、结果输出全在内网完成，外网只开一个管理端口做运维。离线隐私保护不只是网络隔离，音频文件的生命周期管理也要设计好，临时文件什么时候删、识别结果存多久、访问记录怎么留，这些细节得提前定规矩。
权限审计和日志监控是运维的基本盘。API服务化之后，谁调用了什么接口、传了多长的音频、返回了什么结果，这些都要有日志。我习惯在网关层做访问控制，API key按项目分发，不同项目之间数据隔离。日志里音频内容本身不记录，只记元数据，避免日志系统变成隐私泄露的新渠道。监控方面我一般盯几个指标：请求量、延迟分布、错误率、GPU显存占用、服务进程内存。有次半夜收到告警，显存下午还在百分之六十，凌晨爬到百分之九十五，查下来是某路音频触发了异常长解码，加了超时限制才解决。
版本管理和模型更新容易被忽略。模型文件、配置文件、推理代码三者的版本要对得上，我一般用Git LFS管模型权重，代码仓库里放版本清单和校验值。模型更新不能直接覆盖线上版本，得走灰度流程，新模型先接一小部分流量，对比识别结果和延迟指标，没问题再全量切换。回滚方案要提前准备好，旧模型文件别急着删。我见过团队升级模型后精度反而下降，想回滚发现旧权重已经删了，那叫一个被动。
3.5 常见问题与落地清单：环境冲突、模型兼容、音频预处理、延迟瓶颈与验收指标
环境冲突是我被问得最多的问题。Python包版本打架、CUDA版本和驱动不匹配、同一个机器上两个项目依赖不同版本的torch，这些事儿几乎每个项目都会遇到。我的解法是容器化加虚拟环境双保险，开发阶段用conda隔离，部署阶段用Docker固化。模型兼容性问题通常出在推理框架版本上，FunASR的模型用旧版runtime加载可能报错，Whisper的模型转成其他格式之后精度偶尔会掉，这些都要在测试环境先跑一轮再上生产。
音频预处理这块的坑比想象中多。采样率不统一是最常见的，模型要十六k，客户给的是四十四点一k，不重采样直接喂进去识别结果全是乱的。声道数也得注意，双声道音频要混成单声道还是取一路，不同处理方式结果不一样。音量太小的录音识别率会掉，我一般加一个响度归一化步骤。格式兼容方面，mp3、wav、m4a主流格式都支持，但有些编码格式解码会出问题，建议统一转成wav再处理。
延迟瓶颈的排查得从链路两头看。客户端上传音频的时间、服务端排队时间、预处理时间、模型推理时间、结果返回时间，每一段都要打点。我见过一个项目客户抱怨延迟高，打点一看推理只占百分之二十，大头在文件上传和格式转换上。验收指标要提前跟客户对齐，识别准确率用WER还是CER、实时率RTF目标是多少、P95延迟上限、并发路数、连续运行稳定性要求，这些数字写进验收清单，交付的时候一条条对。落地清单我一般会列这么几项：环境依赖版本锁定、模型文件校验、预热脚本、健康检查接口、日志采集配置、回滚方案、压测报告。清单看着琐碎，每一项都是踩过坑之后加上的。
