评测最怕“看起来很公平”
云端 ASR 和本地 ASR 经常被放在一张表里比较：准确率、响应速度、并发数、成本，各占一列。表格很直观，却很容易把不同条件下的结果硬凑到一起。
云端服务的音频要经过网络传输，可能由服务方完成降噪、切片、标点和热词处理；本地系统则可能直接使用原始 PCM，也可能叠加了额外的词表和后处理。两边如果没有统一输入、统一输出和统一统计方式，最后比较的不是两个方案，而是两套不同的工作流。
一份可信的测试报告，开头就应该写清楚音频来源、采样率、声道、说话人数、噪声条件和专业词比例。
先固定数据集，再讨论结果
测试数据最好分成几组：安静普通话、电话带宽音频、会议室远场、多人交谈、行业术语和带背景噪声的现场录音。每组都要保留原始文件和人工校对稿，文件名、时间戳和版本不能中途变化。
如果只用播音员朗读的干净语音，模型差异通常会被放大或缩小，无法说明真实业务效果。相反，真实录音里常见的停顿、重复、口头语和抢话，才是系统上线后每天要处理的内容。
字错率或词错率可以作为参考，但不能单独代表结果。金融场景可能更关心金额和账户名，医疗场景更关心药品和剂量，庭审场景则需要保留时间戳和说话人信息。评测指标要跟业务风险对应。
延迟要拆成四段
实时转写常用“首字延迟”描述体验，但这个词本身不够精确。至少可以拆成音频上传、任务排队、模型推理和前端展示四段。云端方案的网络往返会受到线路和服务区域影响，本地方案则可能把时间花在音频转码、队列等待或显卡调度上。
测试时要同时记录首个文字、稳定文字和最终修订结果的时间。首个文字很快，但后续不断回改，用户仍然会觉得系统不稳定；文字很晚才出现，但一旦出现就几乎不变，也可能更适合某些归档任务。
长时间运行也要测。服务启动后十分钟的延迟没有太大意义，连续运行数小时、同时处理实时和批量任务时，内存增长、队列积压和连接断开才会暴露出来。
并发数不能脱离任务类型
“支持多少路并发”必须说明音频类型和输出要求。实时流式识别、短文件批处理和长录音归档，对显存和调度的压力不同。系统如果把所有请求放进同一个队列，批量任务可能挤占实时请求；如果把每个请求都单独占用一份模型，又会造成资源浪费。
合理的测试应当逐步增加负载，记录成功率、排队时间、实时率、显存峰值和失败重试次数。出现异常时还要确认任务是否能从断点恢复，不能只看服务有没有返回一个 HTTP 状态码。
成本计算要把人也算进去
云端方案通常按时长、请求量或套餐计费，本地方案则涉及服务器、机房、备份、升级和运维人员。对于转写量不稳定的项目，云端按量使用可能比较灵活；对于长期处理大量敏感音频的项目，本地系统的价值可能体现在数据路径和资源可控，而不是单纯节省费用。
人工复核也应纳入成本。一个识别率看起来不错的系统，如果每天需要大量人员修正数字、姓名和术语，实际效率未必理想。测试报告可以记录每小时音频对应的校对时间，这个数字对业务负责人往往比一项抽象的平均准确率更有参考价值。
让比较回到项目本身
云端和本地不是简单的优劣关系。需要快速试用、音频敏感度较低且调用量波动明显的项目，可以优先考察云端服务；对网络边界、数据留存和内网运行有明确要求的项目，则应把本地链路单独测试。
最终提交的报告应保留测试版本、原始输出、后处理规则和异常记录。只有条件可复现，下一次模型升级或硬件更换后，团队才知道结果到底变好了，还是测试方法变了。
一次评测应该能回答哪些追问
测试人员经常只提交平均字错率，客户却会继续追问：电话录音是否单独测过，数字错在哪里，长连接断开后怎么办，音频是否会离开机房。评测报告可以把这些问题提前写进去，避免采购阶段和上线阶段重复争论。
数据集还要注明来源和校对人。真实录音涉及隐私时，可以先脱敏，再保留足够的声学特征用于测试。校对稿不能只由一个人快速听写，关键术语最好经过第二人复核。这样得到的结果虽然不一定漂亮，却更接近实际业务。
网络条件也要分开测。云端服务可以记录不同线路和时段的延迟，本地服务则应模拟客户端集中上传、交换机拥塞和服务重启。两边都要测失败重试，否则稳定性结论只覆盖了理想状态。
如果最终决定采用本地方案，评测范围应延伸到管理和运维：任务能否查询，权限能否回收，文件能否按策略清理，模型升级后能否回滚。ASR 不是孤立的接口，交付结果也不应只是一张性能表。