流式 ASR 与 TTS：把语音转文字、把文字变语音

唤醒词把板子叫醒了，它开始录你这句话——可大模型读不懂音频，它只认文字。同样，模型吐出来的回答是一串文字，但你想听到的是声音。中间这两道"翻译"，就是这一节的主角：把语音变成文字的 ASR，和把文字变成语音的 TTS。

想象你对桌上的板子说"明天杭州热不热"。这句话先被录成一段音频，得有人把它读成"明天杭州热不热"这六个字，模型才能接着想；模型回了"明天最高 31 度，比今天凉快点"，又得有人把这串字念出声，你才听得到。这两个"有人"，就是 ASR 和 TTS。理解了它们，L4 大模型那一节里"唤醒 → ASR → LLM → TTS"的四步链路，你就补齐了中间最关键的两环。

读这篇前，你得先弄懂板子是怎么被叫醒、怎么开始录音的——还没看的，先补唤醒词检测。

---

ASR 是什么：把声音读成文字

ASR（Automatic Speech Recognition，自动语音识别） 干的事一句话就能说清：输入一段音频，输出一串文字。你对它说"打开客厅的灯"，它还你 打开客厅的灯 这五个字。

它要解决的难点，恰恰是人类觉得理所当然的事：

• 同音不同字：「是」和「事」、「在」和「再」，光靠发音分不开，得靠上下文猜。
• 连读和口音：真人说话不会一个字一个字蹦，会连读、会吞音、会带口音，音频波形和"标准发音"差得远。
• 噪声：背景有电视声、有人插话，模型得把你的声音从一锅杂音里捞出来。

所以 ASR 不是简单的"声音查表"，它本身就是一个不小的模型。这也是为什么它通常不放在 ESP32 上跑——一颗几十块的单片机扛不动。

TTS 是什么：把文字念成声音

TTS（Text-To-Speech，语音合成） 是 ASR 的反向操作：输入一串文字，输出一段能播放的音频。模型回你"明天有小雨"，TTS 把这五个字合成成一段人声波形，喇叭一放，你就听到了。

早年的 TTS 一听就是"机器人念字"，生硬、断句怪。现在的神经网络 TTS 已经能做到语气自然、有停顿、甚至能模仿特定音色。但它和 ASR 一样，是个吃算力的模型，正经的高质量合成同样多放在算力更足的地方跑。

---

为什么非得"流式"

最直观的做法是"录完再处理"：等你把整句话说完，把完整音频打包发出去，等 ASR 全部识别完拿到文字，再发给模型……这条路能走通，但慢得让人难受。每一步都在"干等上一步全部做完"，延迟一节节累加，端到端拖到好几秒。

流式（streaming） 换了个思路：别等全部做完，做一点就往下传一点。

• 流式 ASR：你还在说，它已经边录边识别，话音刚落、文字基本也就出来了，而不是话说完了才开始算。
• 流式 TTS：模型一边吐字，TTS 一边合成、喇叭一边播。你听到开头那几个字时，模型可能还在生成后半句。

差别有多大？非流式像是"你说完 → 等 → 它再说完"，每个环节首尾相接地排队；流式像是把整条链路改成了流水线，多个环节同时在动。对人来说，等待感从"明显卡顿"降到"接近自然对话的停顿"。做语音交互，流式几乎是必选项——它不让链路更快完成全部计算，但让你更早听到第一个字，体感天差地别。

---

在硬件链路里，它们站在哪

把 L4 大模型 那条四步链路摊开，ASR 和 TTS 各占一头，中间夹着模型：

你说话
  │
  ▼
本地录音（ESP32 经 I2S 麦克风采集）
  │  流式上传
  ▼
云端 ASR ──→ 文字
            │
            ▼
          云端 LLM ──→ 回复文字
                       │
                       ▼
                     云端 TTS ──→ 音频流
                                  │  流式下发
                                  ▼
                          板子驱动喇叭播放 → 你听到回答

看清楚两件事：

• ASR 在最前、TTS 在最后，模型夹在正中间。ASR 负责把"人的声音"翻成模型能读的文字，TTS 负责把"模型的文字"翻回你能听的声音。少了任意一头，这就不是个"能用嘴聊"的设备。
• 板子两头都在做流式传输：录音那头边录边往上传，播放那头边收边播。中间录音怎么采、喇叭怎么驱动，是 I2S 音频 那一节的事，这里只关心"声音和文字怎么互相转"。

---

端侧做还是云端做

最关键的工程取舍：ASR 和 TTS 这两个模型，放 ESP32 本地跑，还是甩给云端？

答案在绝大多数情况下偏向云端，原因很实在：

• 算力：像样的 ASR/TTS 都是神经网络模型，ESP32 这种几百 KB RAM 的芯片根本装不下、也跑不动。强行塞一个能跑的，质量会差到没法用。
• 效果：云端能用的是大模型、新模型，识别准、合成自然；端侧只能跑极度裁剪过的小模型，差距肉眼可见。

云端的代价你也得认：依赖网络（断网就哑了）、有延迟（网络往返跑不掉）、涉及隐私（你的语音离开了设备）。

那端侧一点都不做吗？也不是。现实里的分工通常是：

• 唤醒词放本地——必须常驻、必须省电、必须秒级响应，这活儿天然属于端侧。
• ASR / TTS / LLM放云端——重活交给算力足的服务器。

这条"轻的留本地、重的上云"的分界，和 L4 大模型那节讲的"云端 vs 边缘"是同一个道理。真要追求离线、不依赖网，市面上确实有能在算力更强的边缘设备（不是 ESP32，而是带 NPU 的开发板）上跑的方案，但那是另一个量级的工程，先别在入门阶段为难自己。

---

常见方案概览

ASR/TTS 这条赛道，国内外的选择都不少，大体分两类。具体哪家好用、价格多少、接口怎么调，以各服务官方文档为准，这里只给你一张地图，不背参数。

• 云端 API：各大云厂商基本都提供语音识别和语音合成的在线接口，按调用量或时长计费。好处是接入快、不用自己养模型、效果有保证；代价是要联网、要鉴权、要算成本。
• 本地/自建引擎：如果你想把模型握在自己手里，开源社区有真实可用的项目。ASR 方向，FunASR（阿里达摩院开源）是常被提到的中文识别项目；TTS 方向，Fish Speech 是社区里活跃的开源语音合成项目。这两个都是真实存在的开源工程，但具体能力、部署门槛、效果，请去各自仓库和文档里核实，别听我一面之词。

---

示意：把一段音频发给 ASR 拿文字

不贴具体某家接口的代码（那只会误导你去对错文档），只讲思路。把一段录好的音频转成文字，逻辑上就这几步：

1. 准备音频：按服务要求的格式录/转
   （常见要求：16kHz 采样率、单声道、PCM 或某种编码——以文档为准）
2. 发请求：把音频数据（或音频流）POST 给 ASR 接口，带上鉴权
3. 拿结果：接口返回一段 JSON，里面有识别出的文字
4. 取文字：从 JSON 里解析出那串识别结果，交给下一步（LLM）

流式版本的差别在第 2、3 步：不是"打包整段再发"，而是建立一条持续连接，边录边把音频片段往上送，服务器边识别边把中间结果回吐。等你话说完，最终文字也基本到手了。TTS 反过来同理——把文字送进去，服务器边合成边把音频片段流式回传，板子收一段播一段。

具体到 ESP32 上怎么发请求、怎么管鉴权、怎么扛住返回体不爆内存，和 L4 大模型 那节讲的 HTTPS 调用是同一套功夫，回去看那节的示例和内存提醒。

---

避坑：四个最常见的翻车点

• 延迟：用了非流式接口，或网络绕了远路，对话就一卡一卡。优先选支持流式的方案，并就近选接入点。
• 识别不准：录音质量是地基。麦克风离嘴太远、采样率不对、背景太吵，ASR 再强也救不回来——先把 I2S 录音 那头做扎实。
• 方言与口音：多数 ASR 对标准普通话最稳，重口音、方言识别率会掉。如果你的用户群口音重，选服务时专门看它对方言的支持。
• 网络抖动：流式上传最怕断断续续。Wi-Fi 信号弱、丢包，会让识别结果残缺或卡死。链路里要有重连和超时处理，别假设网络一直完美。

---

动手挑战

这一节偏原理，动手部分以"想清楚"为主：

1. 画出你的链路：拿张纸，把"你说话 → ASR → LLM → TTS → 你听到"五个框画出来，标清楚每一框放本地还是云端、为什么。能画清楚，你就真的理解了。
2. 挑一家、读文档：选一个你能访问的 ASR 服务，只读它的接口文档，找出三个关键信息——它要什么音频格式、支不支持流式、怎么鉴权。先把文档读懂，比急着写代码重要得多。

卡住了？把你画的链路图和读到的文档片段发给 AI，让它帮你确认理解对不对、字段有没有看漏。

---

小结 · 你现在掌握了什么

• 你能分清 ASR（语音→文字）和 TTS（文字→语音）各自在干嘛，以及它们和唤醒词不是一回事。
• 你理解了"流式"的价值：它不让计算更快，但让你更早听到第一个字，把等待感压到接近自然对话。
• 你看清了 ASR/TTS 在对话链路里的位置——一头一尾夹着模型，板子两端都在做流式传输。
• 你想清了端侧 vs 云端的取舍：算力和效果决定了 ASR/TTS 多放云端，唤醒词留本地。

把这两环接上，"唤醒 → ASR → LLM → TTS"的完整链路在你脑子里就闭环了。

下一步：与其让板子直连一堆云服务、把 Key 和编码细节全堆在设备上，不如自己搭一个后端中转，把 ASR、LLM、TTS 都收到服务端统一调度——往 自建后端 这节走。想直接看一整套语音助手怎么把这些环节工业级地落地，去实战项目里逐行拆小智旗舰。