根本原因是音频缓冲区过大、采样率不匹配及Whisper非流式设计；应调小pyaudio的frames_per_buffer、绕过重采样、禁用padding、手动管理KV cache，并改写generate终止逻辑实现低延迟流式转写。
为什么 pyaudio 录音 + whisper 转写延迟总在 2s 以上
根本原因不是模型慢，而是默认音频缓冲区太大、采样率不匹配、以及 Whisper 的 streaming=False 强制等整段输入。真实对话场景下，pyaudio 默认 frames_per_buffer=1024 在 16kHz 下就引入约 64ms 固定延迟，叠加 Whisper 预处理（如重采样、pad）和 batch 推理，很容易突破 1.5s。
实操建议：
- 把
pyaudio的frames_per_buffer降到256或128（需配合设备支持，否则报IOError: [Errno -9981] Input overflowed） - 录音前用
pyaudio主动查设备真实支持的最小latency：stream.get_input_latency()，别硬设 - 绕过 Whisper 默认的
feature_extractor，直接喂 raw waveform（shape[1, N]），避免重采样开销；若模型是tiny.en，它原生吃 16kHz，别转 48kHz 再降采样 - 禁用
tokenizer的padding=True和return_tensors="pt"的自动 batch 行为——单句流式必须padding=False+return_tensors="pt"手动 squeeze
torch.compile 对 whisper 模型加速有没有用
基本没用，甚至可能变慢。Whisper 的 forward 包含大量动态控制流（如 if len(input_ids) > 0:）、可变长 attention mask、以及 generate 中的 while 循环，torch.compile 当前（2.3+）对这类模型支持极弱，常 fallback 到 eager 模式，还多了一层图构建开销。
更靠谱的路径：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 用
transformers的WhisperForConditionalGeneration.prepare_inputs_for_generation提前缓存 KV cache，避免每次 decode 都重算 encoder 输出 - 换
llama.cpp或whisper.cpp的量化推理后端：它们把 encoder+decoder 全编译进 C，内存连续、无 Python GIL，端到端延迟可压到 300ms 内（tiny.en+Q5_K_M） - 如果坚持用 PyTorch，至少关掉
torch.backends.cuda.matmul.allow_tf32 = False，TF32 在小 tensor 上反而拖慢
怎么让 whisper 真正“边录边转”而不是等 3 秒静音才出结果
关键不是调 prompt，而是重写 generate 的 stopping 逻辑。原版 Whisper 的 generate 默认等 EOS token 或 max_length，但语音流里没有明确 EOS，它只能靠静音检测（speech_to_text 库里那种）或超时强制截断，这就导致“卡住”。
实操改法：
- 用
model.generate(..., return_dict_in_generate=True, output_scores=True)拿到每步 logits，自己做 top-k 解码 + beam search 终止判断 - 加一个滑动窗口：只保留最近 5 秒音频的 logits 做增量解码，丢弃旧帧对应的历史 KV，防止 context 过长拖慢
- 静音判定不用等完整 VAD，直接监控输入 waveform 的 RMS：连续 300ms
RMS 就触发 partial flush，哪怕只解出两个词也先吐出去 - 别依赖
whisper.tokenizer.decode(tokens, skip_special_tokens=True)的默认行为——它会等完整句子，改成逐 token decode + 正则过滤标点（如re.sub(r'[.!?]+$', '', text)）再输出
WebSocket 传输音频流时，bytes 分块大小怎么设才不卡顿
不是越小越好。WebSocket 帧头固定 2–14 字节，如果每包只传 128 字节音频，网络开销占比超过 10%，TCP 还容易触发 Nagle 算法合并小包，反而增加抖动。
经验值：
- 16kHz / 16-bit 单声道 → 每 20ms 是
640字节，按此粒度分帧最稳（对应人耳语音感知窗口） - 服务端用
asyncio.Queue(maxsize=4)缓存待处理帧，满则丢最老一帧（宁可丢帧也不能积压） - 客户端发包前加时间戳（
int(time.time() * 1000)），服务端用它校准音频时序，避免因网络抖动误判语速快慢 - 千万别用
json.dumps({'audio': list(bytes_data)})—— base64 或 list(int) 会放大 3–4 倍体积，直接用 binary frame 传bytes
最难调的其实是音频硬件链路：USB 声卡驱动、ALSA buffer 配置、甚至麦克风增益过高引入的 clipping，都会让 Whisper 的 VAD 失效，进而让整个流式逻辑卡在“等静音”上。这些比代码参数重要得多。
