问题：在不更换语音模型的情况下释放容量
归档音频转写服务需要在达到明确质量目标的同时处理更多音频。ProsGrow 从 MLPerf Inference v6.0 使用的公开 Whisper 实现出发，在一台配备八张 RTX PRO 6000 Blackwell GPU 的节点上复现了其支持的配置。完整时长的基线测试达到每秒 291.771 个音频样本。
我们分析了引擎的批处理行为，发现公开配置并非当前系统的最优选择。通过一项受支持的配置调整，两次完整时长运行达到每秒 299.444 个样本，即在相同八张 GPU 上将吞吐量提高 2.63%。所选配置也通过了基准测试的准确率门槛。
基线 → ProsGrow 调优后
| 本地配置 | 音频样本/秒 | 样本/秒/GPU | 相对本地基线的提升 |
|---|---|---|---|
| 公开配置 · 基线 | 291.771 | 36.471 | — |
| 所选配置 · 第 1 次运行 | 299.628 | 37.454 | 2.69% |
| 所选配置 · 第 2 次运行，观测下限 | 299.260 | 37.408 | 2.57% |
| 所选配置 · 两次运行均值 | 299.444 | 37.431 | 2.63% |
两次调优运行的差值仅为其均值的 0.123%。为保守规划容量，我们采用较低的观测结果，即 299.260 个样本/秒。基线有一次完整时长测量，调优配置有两次。
性能分析揭示的引擎批处理行为
在两次所选配置运行中，平均 GPU 利用率从 94.417% 提高到 97.373% 和 97.312%。结合吞吐量结果，这支持了通过改善批处理节奏释放容量的解释。这是基于遥测数据的推断，并非对未公开引擎内部机制的断言。
ProsGrow 评估了完整流水线，选择了一项受支持的引擎配置，并通过完整时长重复测试和独立准确率检查进行验证。公开源码、检查点、数据集、解码行为、LoadGen 种子和评估器均保持不变。继续使用相同的 FP16 源检查点和 NVFP4 解码器矩阵乘法插件；未启用任何源码性能补丁。
权衡：吞吐量提高，活跃功耗略有上升
第一次完整调优运行将 GPU 平均总功耗从 3,428 W 提高到 3,508 W，同时吞吐量提高 2.69%。每处理 1,000 小时源音频的 GPU 能耗从 0.4885 小幅下降到 0.4868 kWh。容量提升并未降低实测能效，但能耗差异很小。
质量始终是明确的验收门槛。调优配置的 AccuracyOnly 运行覆盖全部 1,633 个样本，使用 MLCommons 评估器得到词错误率 2.131770%，低于允许的 3.046429%。这证明了在所评估语料上的通过结果；本次对比未对本地基线单独进行准确率测试。
外部参考：更少 GPU 实现相近吞吐量
报告中的主要公开 Whisper 对比来自 HPE 八 GPU 的 294.821 个样本/秒结果。我们的均值为 299.444 个样本/秒，节点吞吐量高出 1.57%。两者均使用八张 RTX PRO 6000 GPU，但主机和软件细节不同。
经过核查的公开 MLPerf v6.0 快照还包含 HPE 十 GPU 的 297.661 个样本/秒结果。我们的本地八 GPU 均值高出 0.60%，加速器数量少 20%。除以 GPU 数量后，结果为每 GPU 每秒 37.431 对比 29.766 个样本，差幅为 25.75%。
这是有用的系统效率参考。在我们自有节点上隔离测得的工程增益是引擎配置选择带来的 2.63% 提升。外部对比还包含主机和软件栈差异，因此无法将全部单 GPU 优势归因于这一项调整。
这对转写服务意味着什么
在所评估语料上，两次运行均值对应每个实际小时处理约 7,202 小时源音频，基线则为 7,017 小时。根据基准样本的平均片段时长换算，这意味着每个活跃节点小时可额外处理约 185 小时源音频。存在持续归档积压的服务可以利用这一增益，在相同已安装 GPU 上缩短处理窗口。
ProsGrow 会从吞吐量、转写质量、排队时长和数据边界等方面验证归档转写服务。实时转写需要单独的服务约定，包括并发连接、部分结果行为、最终结果延迟和故障恢复。Offline 样本速率无法确定实时流容量。
付费需求为 10% 时的语音成本
9月15日的能力报告使用价值 $100,000 的节点、三年摊销、70% 的基准到服务效率和 10% 的付费需求，建模得到每售出一分钟音频 $0.0001321。该报告带日期的 API 价格输入为 OpenAI 托管 whisper-1 的 $0.006/分钟，以及 Deepgram Nova-3 单语言预录音 PAYG 的 $0.0043/分钟。建模的基础设施成本分别低 97.80% 和 96.93%。
计算将实测容量换算为每个日历小时约售出 30,247.5 分钟音频，再用约 $3.995 的每小时基础设施成本除以该容量。成本包括 $100,000 ÷（3 × 8,760 小时）的硬件摊销和按 $0.10/kWh 计价的电费；假定整节点空闲功耗为 1.5 kW、活跃功耗为 5.5 kW，按 10% 的需求进行加权。服务效率与付费需求是两个独立假设。
在每小时成本和其他假设保持不变时，实测2.63% 的吞吐量提升本身，可将单位成本降低约 2.56%。与 API 价格之间更大的差距来自私有批处理容量的经济模型，且高度依赖需求。
这是基础设施成本与价格之间的对比，并非已经证实的客户节省。它不包含维护、冷却/PUE、人力、网络、存储、支持、冗余和 SLA 储备。本地 Whisper Large v3、托管 whisper-1 和 Nova-3 的模型及服务功能不同，尚未建立等价服务质量。
Granite API 与实时语音
报告还测量了一项独立的 Granite 排队 API 服务。通过主机放置和请求批处理，吞吐量从 19,062.88 提升到 28,368.99 RTFx，相对其最初本地 API 基线提高 48.82%。RTFx 指每个实际秒处理的音频秒数。该批处理 API 评估了 62,880 条语音，退化输出为零，最差 WER 为 3.4942%。
Granite 另一个独立异步 Offline 结果为 68,932.91 RTFx。报告的实时 ASR 测试在三次各 24 秒的同主机回环测试中，维持了 5,568 条 WebSocket 连接。这些测试采用不同的模型、评分和计时边界。每项主要结果都来自独占节点的单独测试；外部流量、长时间实时运行和故障恢复仍需验证。
方法与局限
- 系统与软件栈：2026年8月20日至21日的测试使用八张 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU 和两颗 AMD EPYC 9575F CPU，以及 TensorRT 10.14.1.48、TensorRT-LLM 1.3.0rc0 和 CUDA 13.1。公开参考代码和模型/数据哈希均已固定并检查。
- 工作负载与单位：MLPerf Whisper 数据约定将 LibriSpeech 重新打包为 1,633 个单声道、16 kHz 音频样本。每个样本补齐为 30 秒进行 Whisper 计算；实际源音频时长平均为 24.0505 秒。音频样本/秒、生成 token/秒和源音频小时数是不同单位。
- 性能有效性：基线及两次主要调优运行均满足至少 10 分钟的要求，且 LoadGen 状态为 VALID。短时诊断运行用于选择候选配置，不与完整时长的主要结果混用。0.123% 的范围仅涵盖两次调优重复测试，并非置信区间。
- 准确率与合规：这些是基于 MLPerf 的本地测量，并非官方 MLPerf 提交或经过 MLCommons 审核的结果。TEST01 性能验证通过。直接输出比较发现不匹配；允许的回退验证对基线和审计输出得到相同的 2.168070% WER，因此补充通过了该检查。这是通过回退流程完成验证，而非逐字节准确率一致。完整 AccuracyOnly 测试的 WER 仍为 2.131770%。
- 生产范围：功耗数据仅涵盖 GPU，不含主机和冷却。音频小时数换算基于此语料，并假定存在持续队列。客户的口音、语言、噪声、重叠语音、词汇，以及存储、网络、重试、利用率和延迟均需要单独测量。
私有语音转文字与离线 Whisper 转录
对于私有音频转录，这项 Whisper 基准测试有助于估算在规定期限内处理存档所需的能力。语音转文字吞吐量和词错误率（WER）必须在有代表性的录音上一起评估。离线基准处理能力不能说明服务能支持多少路实时音频流，也不能说明部分转录结果会多快返回。