快不快，不能只看一次推理
语音识别项目常把“速度提升”写成一个醒目的数字，但单次推理时间只能说明很小一部分问题。真实服务要处理连续音频、多个连接和失败重试，还要把文字送回业务系统。一个模型在空载时很快，遇到十几个并发任务后排队很久，用户感受到的仍然是慢。
FunASR、Whisper 以及其他 ASR 工具的推理效率，都会受到音频长度、采样率、模型精度和后处理方式影响。测试时把这些条件写清楚，比给出一个脱离环境的倍率更有参考价值。
先处理音频，再谈算力
音频进入模型前通常要经过解码、重采样、声道转换和语音活动检测。任何一个环节堵住，模型设备都会出现空转。历史录音还可能存在多余静音、损坏文件和异常音量，应该在队列前做轻量检查，避免把明显不可用的任务送进推理节点。
实时流的切片长度需要反复试。切片短，首字出现得快，但上下文不足，容易出现断词和重复；切片长，结果更连贯，却会增加等待和缓存。实际配置应当根据会议、电话或现场录音分别验证，不能把一套参数复制到所有场景。
量化不是只换一个数字类型
INT8、FP16 等量化方式可以降低内存压力，也可能改善设备吞吐，但精度变化要按词和场景观察。普通句子没有变化，不代表设备型号、金额和药品名称也没有变化。
量化前后应使用同一批音频，保留原始转写和后处理结果。除了字错率，还要记录首字延迟、实时率、显存峰值和失败任务比例。如果换了推理后端或硬件，报告中必须单独标注，不能把几项改动的效果合并成一个结论。
有些算子在一种加速环境中可以正常运行，换到另一种设备后会退回 CPU。系统上线前应检查算子覆盖、驱动版本和内存拷贝次数。否则监控里看到的“GPU 利用率不高”，可能不是模型太轻，而是关键计算根本没有留在加速设备上。
队列是实时系统的隐形瓶颈
实时请求和离线归档请求最好分开排队。实时请求需要短等待窗口，批量任务可以接受更长的队列；如果它们共用一个先进先出队列，归档任务很容易占满资源。
动态批处理可以减少设备空闲，但批次越大，等待时间未必越短。调度器需要同时考虑队列长度、任务优先级和当前显存。长音频还要支持分片完成和断点恢复，不能因为一个片段出错就让整份文件重新计算。
服务接口也要有明确的超时和重试规则。客户端重连时，服务端需要知道哪些片段已经处理过；结果回调失败时，任务应当能够再次投递，但不能重复写入业务系统。很多所谓的“识别速度问题”，最后查出来其实是重复任务和无效重试。
CPU、GPU 和边缘设备各有脾气
CPU 部署便于维护，适合任务量有限、硬件环境比较统一的场景；GPU 更适合并发和批处理，但驱动、显存和散热会增加运维要求；边缘设备功耗低、数据路径短，却更容易受到内存和存储限制。
硬件评测不能只跑五分钟。至少要观察长时间运行后的温度、内存增长、日志大小和服务重启时间。对于没有公网的机房，还要验证镜像、模型和驱动怎样升级，出现问题后如何回退。
把“加速”写成可验收的事项
一份有用的加速报告应当列出基线版本、模型版本、硬件、音频条件、并发设置和统计方法。结果可以包括首字时间、实时率、批量吞吐、显存峰值、失败率和恢复时间。若做了量化或词表适配，还要分别报告识别结果变化。
推理加速最终服务于稳定的业务流程。模型本身可以替换，硬件也会升级，但音频入口、队列、版本记录和故障恢复这些环节不能靠临时排查维持。只有把它们一起测过，速度数字才有实际意义。
内存问题通常比算力问题更难找
长音频转写时，音频缓存、特征缓存、模型权重和结果队列可能同时增长。服务刚启动时内存很平稳，跑过几百个任务后才出现缓慢上涨。监控应当记录每个任务的音频长度、分片数量和内存变化，才能判断问题来自单个异常文件，还是队列没有释放。
批处理大小也不能照搬别人的配置。批次过小，设备频繁启动，空耗会增加；批次过大，某个长文件就可能让同批任务一起等待。可以先按音频时长分组，再用小步增加并发的方式寻找稳定区间，遇到错误时保留当时的队列和设备状态。
实时服务还需要背压机制。客户端发送速度超过推理速度时，服务端应当明确拒绝、排队或降级，不能让内存无限增长。队列达到阈值后，客户端应收到可理解的错误信息，后台则记录触发原因和恢复时间。
加速后的结果格式也要保持稳定。模型推理、标点恢复和说话人分离只要有一个版本变化，就可能改变时间戳或字段结构。业务系统不应直接依赖内部模型输出，最好通过固定的接口层做版本兼容和灰度验证。