Whisper 实时流式转录：低延迟语音转文本指南

OpenAI Whisper 是一个开源语音识别模型，具备高准确率和多语言支持。虽然 Whisper 最初并不是为流式场景设计的，但只要搭建合适的处理流水线，你就可以构建 低延迟的实时语音转文本系统——非常适合直播字幕、会议转录、直播流、以及语音助手等场景。

本文将介绍如何让 Whisper 在实时场景下稳定工作，包括整体架构、关键技术、取舍权衡，以及参考代码。

为什么流式这么难

传统 Whisper 是基于完整音频片段运行的，而不是针对持续不断的音频流。主要挑战包括：

增量解码 —— 处理持续到来的片段音频
低延迟 —— 尽快给出识别结果
切片边界伪影（chunk 边界处的错误或丢词）
GPU 利用率 vs 响应速度

为了解决这些问题，通常会使用 滑动窗口 + 重叠（overlap） 以及增量缓冲（buffering）。

架构总览

使用 Whisper 做实时流式识别时，典型架构包含以下组件：

Audio Source → Audio Buffer → Segmenter → Whisper Inference → Post-processing → Consumer

Audio Source —— 麦克风 / 浏览器 / 电话语音
Segmenter —— 生成带重叠的音频切片
Whisper Inference —— GPU / CPU 上运行的模型
Post-processing —— 合并文本和时间戳

为低延迟进行切片

客户端会持续发送音频数据。为了避免一次性输入过长的音频，一般会：

窗口长度（Window length）： 1–5 秒
重叠时长（Overlap）： 0.5–1 秒
缓冲区大小（Buffer size）： 取决于你的延迟需求

窗口越小，延迟越低，但计算与调度开销越大。

为流式选择合适的模型

Model	VRAM	Latency	Accuracy
tiny	1–2 GB	⭐⭐⭐⭐	❌
base	2–4 GB	⭐⭐⭐	⭐⭐
small	4–8 GB	⭐⭐	⭐⭐⭐
medium	8–12 GB+	⭐	⭐⭐⭐⭐

流式场景中最常见的折衷选择： base 或 small

基本流式处理流程（伪代码）

import whisper
import sounddevice as sd
import numpy as np

model = whisper.load_model("small").to("cuda")

BUFFER = []
WINDOW = 3  # seconds
OVERLAP = 1  # seconds
RATE = 16000

def callback(indata, frames, time, status):
    global BUFFER
    BUFFER.extend(indata.flatten().tolist())
    # When buffer length > window, process
    if len(BUFFER) >= RATE * WINDOW:
        segment = BUFFER[:RATE * WINDOW]
        BUFFER = BUFFER[int(RATE * (WINDOW - OVERLAP)):]
        audio = np.array(segment)
        result = model.transcribe(audio, fp16=True)
        print("--- partial →", result["text"])

这段代码会持续输出带重叠的 部分转录结果（partial transcript）。

处理重叠与拼接

重叠有助于减少切片边界处的丢词问题。

举例：

切片序列：

0–3s
2–5s
4–7s

然后你需要：

移除重叠区域的重复文本
调整时间戳
输出一条连续的文本流

在浏览器中实现实时转录

你可以通过 WebRTC 或 Web Audio API 在浏览器中采集音频并推流到服务器：

const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
const processor = audioContext.createScriptProcessor(4096, 1, 1);
source.connect(processor);
processor.connect(audioContext.destination);

processor.onaudioprocess = (e) => {
  const chunk = e.inputBuffer.getChannelData(0);
  sendToServer(chunk); // WebSocket/Socket.io
};

部署模式

☁️ 无服务器（云端）

客户端通过 WebSocket 发送音频
使用 AWS Lambda 处理短音频 / 或使用长驻 GPU 服务器
在 GPU 实例上运行 Whisper
通过自动扩缩容实现弹性伸缩

🖥️ 专用 GPU 服务器

一台或多台长期运行的 GPU 机器
更低的端到端延迟
适合 24/7 在线服务

🌀 混合架构

边缘设备负责采集音频，并可以跑一个小模型进行预筛选
将音频或特征转发到中心 GPU 做完整转录

如何进一步降低延迟

🟡 1. 使用更小的窗口

更少的批量时长 → 更快的部分结果输出

🔵 2. 使用重叠缓冲

可以减少丢词和断句问题

🟢 3. 使用 FP16 / BF16

更快的推理速度

🔴 4. 对多路用户进行批处理

当服务器同时处理多路音频流时，适度批处理可以显著提升吞吐量

监控与指标

建议重点监控：

每个切片的端到端延迟
词错误率（WER）
GPU 利用率
部分转录 vs 最终转录的准确率

可以使用 Prometheus / Grafana 搭建可视化看板。

关键取舍

目标	取舍
低延迟	上下文更短 → 准确率下降
高准确率	窗口更大 → 延迟更高
小模型	推理更快，但准确率较低
大模型	推理更慢，但准确率更高

典型应用场景

直播流的实时字幕
会议或课堂的实时转录
交互式语音应用
线上会议、网络研讨会服务

总结

基于 Whisper 构建实时流式转录系统完全可行——关键在于合理平衡：

窗口大小
重叠时长
模型规模
硬件性能

只要设计得当，你就可以在生产环境中实现 低延迟且高准确率 的实时语音转文本服务。

Whisper 实时流式转录：低延迟语音转文本完整指南（2026）