把 ASR 从公有云搬到企业内网，换一套国产硬件之后，最先暴露出来的通常不是识别准确率，而是环境问题：驱动版本对不上，推理框架找不到对应算子，容器里能启动，换到生产机却加载失败。信创部署的工作量，很大一部分都在这些看起来不属于算法的问题上。
先做一张可执行的环境清单
项目开始时，应当把操作系统、处理器、加速卡、驱动、运行时、容器引擎和编译器版本写清楚。只写“支持某国产平台”没有太大帮助，因为同一品牌的芯片和驱动版本也可能对应不同的算子实现。模型导出格式、动态库位置和设备可见性，也要放进清单里。
验证节点和生产节点最好保持一致。若必须存在差异，就在部署包中记录差异，并为关键组件准备校验值。这样出现加载失败时，可以先判断是文件不完整、权限不对，还是运行时版本不匹配，不至于从头猜起。
算子适配不是把模型文件换个格式
许多 ASR 模型在开发环境里依赖 CUDA 或特定版本的 PyTorch，迁移到其他加速平台后，部分算子可能没有直接对应实现。常见处理方式包括使用平台提供的算子库、替换等价算子、调整张量布局，或者把不支持的部分留在 CPU 上执行。
这类调整需要用固定音频做对照。每替换一个算子，就比较转写文本、时间戳、内存峰值和处理耗时。结果变化太大时，应先定位到具体算子和输入条件，不能只看最终的整段文字。尤其是流式识别，前后文切分和缓存处理稍有变化，就可能出现句首丢字或重复输出。
量化也要放在实际数据上验证。INT8 或其他低精度方式可能降低资源占用，但对数字、专名、短词和远场音频的影响不一定相同。验收集里要包含安静室内、多人交替、背景噪声和长音频等不同条件，并把可接受的误差范围提前写下来。没有基线的“提速几倍”并不能说明系统能否用于生产。
高并发的关键是队列和退让机制
离线转写常有两种任务：实时流和文件批处理。两者混用同一推理进程时，短时间内涌入多路音频，容易造成显存峰值上涨，甚至让实时任务被长文件拖住。服务层应区分任务类型，分别设置队列和超时规则。
动态 batching 可以提升资源利用率，但批次不能无限等待。实时音频应该有明确的组包窗口，超过窗口就立即送入推理；批处理任务则可以按照音频长度分组，减少填充带来的浪费。遇到设备繁忙时，系统要能返回排队状态，而不是让调用方一直等待一个没有结果的连接。
音频解码、特征提取、推理和结果写入也不宜全部塞进一个线程。把环节拆开后，某个文件损坏或下游存储变慢时，可以单独重试，避免整个服务跟着阻塞。监控至少应包含队列长度、单路耗时、设备内存、失败原因和待处理文件数，这些指标比一个笼统的“运行正常”更容易定位故障。
验收要看可维护性
信创 ASR 项目交付时，除了识别结果，还应交付离线安装介质、版本清单、日志位置、升级步骤和回滚方案。现场人员未必能修改推理代码，但应能判断服务是否启动、任务卡在哪个环节、磁盘是否已满，以及如何安全地切换到上一版本。
本地部署的价值不只是让数据留在内网，也包括在受限网络里保持系统可控。把硬件适配、模型版本、任务队列和运维流程一起设计，后续换服务器或增加并发时才有明确的调整路径。
