Whisper 实时语音识别部署与测试指南

本文说明如何准备本地或云端运行环境、安装并调用 Whisper，区分完整文件转写与分段输出，再按清晰口径检查识别结果、延迟与资源用量。

部署 Whisper 的第一步，是先确认你要做的是完整文件转写，还是“已有音频分段后尽快返回结果”：OpenAI 的 Whisper 模型卡明确写明，模型不能开箱即用于实时转写。你可以用 faster-whisper 的分段生成结果，再由 FastAPI 的 StreamingResponse 逐块返回，但这不等于原生麦克风流式识别。选择 GPU服务器租用环境时，应把“模型能处理什么”和“服务怎样交付结果”分开验证。

先划清“实时”的边界

OpenAI 的 Whisper README 说明，transcribe() 会读取整个文件，并以滑动的 30 秒窗口处理音频，因此它提供的是离线整文件转写基线，不是开箱即用的流式接口。

如果音频已经被切成多个分段，逐段返回结果可以缩短调用方拿到首段文本前的等待；但持续接收麦克风音频还需要解决采集、缓冲、分段、背压和取消。上述官方说明没有为这套组合规定完整端点或协议，因此不能仅凭响应逐块返回，就把系统标为“实时识别”。

自有机器或 GPU服务器租用：准备并安装 OpenAI Whisper

同一 Whisper README 说明，代码库预期适用于 Python 3.8-3.11 和近期 PyTorch，系统需要安装 ffmpeg；如果 tiktoken 没有当前平台的预编译 wheel，还可能需要 Rust。

模型共有六种尺寸。下表是 README 标注的约需 VRAM，可用于初步筛选，不能代替具体实例的容量核对：

模型	约需 VRAM
`tiny`	~1 GB
`base`	~1 GB
`small`	~2 GB
`medium`	~5 GB
`large`	~10 GB
`turbo`	~6 GB

在 Ubuntu 或 Debian 上，按文档安装系统依赖和 PyPI 包：

sudo apt update && sudo apt install ffmpeg
pip install -U openai-whisper

先用已有音频运行命令行入口：

whisper audio.flac audio.mp3 audio.wav --model turbo

也可以通过 Python 调用同一模型：

model = whisper.load_model("turbo")
result = model.transcribe("audio.mp3")
print(result["text"])

命令完成并输出转写文本，只能说明安装、模型加载和文件读取链路已经跑通，不能据此判断准确率或实时性。租用机器时，还应从供应商当前页面核对 GPU 型号、驱动与 CUDA 兼容性、计费单位、存储费用及停止规则；这些内容不能由 Whisper 文档确定。

用 faster-whisper 和 FastAPI 做分段输出

按 faster-whisper 的说明，它是基于 CTranslate2 的 Whisper 重新实现，要求 Python 3.9 及以上版本。与 openai-whisper 不同，它不需要单独安装系统 FFmpeg，因为 PyAV 已捆绑所需库。其 transcribe() 返回 segments 生成器，只有迭代这些分段后，转写才开始运行。

安装命令为：

pip install faster-whisper

GPU 模式可按文档创建模型：

model = WhisperModel(model_size, device="cuda", compute_type="float16")

这里的 model_size 应替换为你准备加载的模型标识；compute_type="float16" 会在 GPU 上使用 FP16。最新 CTranslate2 版本只支持 CUDA 12 和 cuDNN 9，官方 NVIDIA 镜像 nvidia/cuda:12.3.2-cudnn9-runtime-ubuntu22.04 已包含所需库。部署前应先让供应商确认实际驱动和 CUDA 环境。

FastAPI 的流式响应文档说明，在路径操作中声明 response_class=StreamingResponse 后，可以使用 yield 逐块发送数据，应用需要自行生成并编码响应字节。这个机制解决的是输出传输，不会自动完成麦克风采集、音频切片或流式推理。

如何检查结果、延迟和资源用量

先固定测试矩阵，每次只改变一个主要变量。记录模型、GPU、CUDA、cuDNN、compute_type、音频语言、时长、语速、分段规则和冷热状态；首次调用与后续调用不要混在同一个平均值中。

延迟测试至少统一两个时间点：音频分段何时就绪，以及首个或完整响应何时被调用方收到。可采用以下内部口径：

first_segment_latency_ms = first_segment_received_at_ms - audio_segment_ready_at_ms
end_to_end_latency_ms = complete_response_received_at_ms - audio_segment_ready_at_ms
realtime_factor = sum(audio_duration_seconds) / test_wall_clock_seconds

这些公式是本机测试定义，不是所有项目的统一指标。MLPerf Inference Rules 要求提交使用 LoadGen，并把延迟定义为 LoadGen 将查询交给被测系统到收到回复的时间；如果没有采用该规则和工具，结果应标为内部功能或压力测试。

资源采样可以围绕以下公式组织：

peak_vram = max(vram_samples)
mean_gpu_utilization = sum(gpu_utilization_samples) / sample_count

费用核对则读取供应商当前账单，把实际出现的 GPU 实例、存储、出站流量及其他项目相加，不预设固定金额：

total_charge = sum(actual_bill_line_items)

常见出错点

把 StreamingResponse 的逐块响应等同于实时音频输入；
没有分别记录首段延迟和完整响应延迟；
把 README 中的约需 VRAM 当成实例容量保证；
未核对 CUDA、cuDNN 与 CTranslate2 版本关系；
把不同冷热状态、语言或音频时长的数据合并比较。