AssemblyAI 详细介绍了发布前的语音代理负载测试

AssemblyAI发布了一份技术指南，讲述如何在发布前对语音代理进行加载测试，认为单次静室通话的演示性能并不能反映生产环境。在 2026-10-20年发布的文章中，公司表示团队应在预计峰值并发时通过整个流水线回放最难的真实通话，并测量实体准确性、 P95 延迟、拒绝连接和每完成任务的成本。

指南说的测试方法

文章指出，负载测试应涵盖完整的语音协议栈——语音转文本、大型语言模型、文本转语音、工具调用和电话——并区分并发、吞吐量和会话时长，因为每个测试的失败方式不同。AssemblyAI表示，一个在短时间内开启数百次通话的回调活动，可能达到与长期并发负载不同的极限，大多数团队只测试第一个情况。指南还推荐四种配置文件：稳态、线性递增、尖峰和浸润。

AssemblyAI的例子主要关注制作类输入，而非干净的音频。帖子指出，团队应从最差的通话中构建语料库，包括 8 kHz电话压缩、实体密集的内容（如账户号码和确认码）、真实口音、背景噪音、中断和假启动。它还警告人工转录标签可能包含遗漏或清理，导致词误指标失真，并建议在评分语音工作流程时应优先于词语准确性。

容量、计费和失效模式

文章说测试应证明会话关闭干净，且提升速度控制在提供商的限制内。在AssemblyAI的流媒体和语音代理API上，会话按连接时间计费，指南中说容量按账户管理。关于流媒体，帖子说限制是每分钟新增会话数，且可自动在付费账户上扩展;而语音代理API则规定限制在并发会话数。

AssemblyAI还说负载测试应考虑计费行为。帖子说空闲时间是可计费的，未明确关闭的流会话可以在三小时后自动关闭并计费整段时间，关闭语音代理套接字但不发送session.end则会留下一个30秒的恢复窗口，且该窗口同样可计费。公司表示，按完成任务的成本比按小时成本更适合衡量，因为成本较低但效率较低的代理在实际操作中仍可能更贵。

参考指标与基准数据

指南建议报告百分位数而非平均值，并给出多个指标的目标阈值，包括最终定稿延迟P95低于500毫秒，端到端转动延迟P95 1.5秒P95以下，工具调用往返延迟低于500毫秒，计划高峰时零拒绝，且丢弃会话0.5%次以下。指南还建议团队应将斜坡相位和持续相位测量分开，因为斜坡过程中延迟可能加剧。

为了说明准确性比较，AssemblyAI引用了其英文语音代理基准测试， 12,460 脚本化场景。基于该基准测试，公司表示 Universal-3.6 Pro Realtime记录了 5.19% 字错误率和 14.4% 实体错误率，与Deepgram Flux EN在 13.50% 和 30.1%、ElevenLabs Scribe v2 在 7.78% 和 18.5%，以及Deepgram Nova-3 在 8.64% 和 26.1%之间进行了比较。帖子还提到电话号码子集为 2.4% ，而Deepgram Flux EN则为 11.5% 。报告还引用了Pipecat的独立开放STT基准，该基准发现语义词错误率 0.80% 合并，最终转录延迟中位数为 307 毫秒，同时指出Pipecat认为顶级服务之间的小间隔可能并不重要。

安全带引导与限速操作

AssemblyAI 包含其流媒体 API 和语音代理 API 的示例代码，强调实时控制音频节奏、等待会话确认后发送音频，以及只有在服务器确认会话已在线后才计算峰值并发时间。帖子中提到会话可以在连接时被拒绝，拒绝的会话应被计数，而非在负载测试中重试。文章还警告音频块必须保持在 API 允许的大小范围内，并且应明确终止流，以免测试泄露可计费会话。

在规划方面，公司建议团队应固定语音模型，而非依赖最新的默认，在同一语料库上进行基准测试备用模型，并在发布前设定回滚阈值。文章以一周的部署计划和生产准备度检查表结束，涵盖负载与并发、监控、团队自身数据的基准测试，以及合同问题如速率限制、计费单元、数据处理区域和支持响应目标。