语音模型这一年:从 ASR 到端到端语音

两年前你做语音功能,绕不开 Whisper。把音频丢进去,拿一段文字出来,干净利落。 今天你再去看,会发现一个有点反常识的事实:在不少新产品里,那一段文字根本不存在了。语音进去,语音出来,中间没有任何一步是"文本"。Whisper 这种纯 ASR 模型,正在从"语音 AI 的地基"退化成"一个还在用、但不再激动人心的工具"。 这不是 ASR 变差了——它一直在变好。是语音模型这条线,这一两年走完了一次三级跳。我想把这三级讲清楚:每一步解决了什么、赔进去了什么,以及 2026 年的此刻,你手里的场景到底该站在哪一级。 三级跳:一张时间线 timeline title 语音模型的三代演进 第一代 专用 ASR : Whisper 系 / 各家流式 ASR : 语音 → 文字,只做识别 第二代 多模态语音理解 : Qwen-Audio / Qwen3-Omni : 语音直接进 LLM,听懂语气与事件 第三代 端到端语音 : Moshi / Sesame CSM : GPT-Realtime / Gemini Live : 语音进语音出,中间不落文字 这三代不是互相取代的关系——更像三层楼,新楼盖起来了,旧楼还有人住,而且住得挺好。下面一层一层说。 第一代:专用 ASR,把语音"压扁"成文字 ASR 模型只干一件事:把声波转成最可能的那串字。Whisper large-v3 仍然是这条线上的标杆,多语言、抗噪、开源、便宜,2026 年依然是无数转写流水线的默认选项。 它解决的问题很实在:语音是连续的、模拟的、信息量巨大的信号,文字是离散的、规整的、好处理的符号。ASR 在两者之间架了一座桥。有了这座桥,语音才第一次能接进所有为文字设计的系统——搜索、数据库、传统 NLP、LLM。 代价也恰恰在这座桥上。ASR 是一次有损压缩,而且丢掉的东西,常常正是你最想要的。 同一句"你这是什么意思",可以是真诚发问,可以是压着火,可以是开玩笑。转成文字之后,这九个字一模一样,语气全没了。一段录音里有人在笑、有人在哭、背景有玻璃碎掉的声音——ASR 给你的还是那行字,这些"非文字信息"在转写的瞬间被抹平。 对"我要把会议录音变成文字稿"这种任务,这种丢失无所谓,甚至是好事。但对"我要做一个能察言观色的语音助手",这就是地基上的裂缝:你的下游模型再聪明,也只能在 ASR 留下的那点信息里打转。 ...

2026-05-14 · 2 min · Chico

流式 TTS:把首包延迟压到 150ms

合成一句 12 个字的话,模型跑完要 1.2 秒。但如果做对了,用户感受到的延迟是 150ms。 这不是魔法,是流式 TTS 的基本盘。差别在于:你是等整句音频生成完再播,还是第一个音频块一出来就往用户耳朵里塞。前者用户等 1.2 秒,后者等 150ms——同一个模型,同样的算力,体验差一个数量级。 我在《实时语音对话的延迟预算》里把整条语音 Agent 链路拆过一遍,TTS 那一段只给了一句话:“要流式,首包出来就播。“这篇把那一句话展开,只讲 TTS。 为什么是"首包”,不是"整句” 先说清楚一个被混淆得很厉害的指标。 很多 TTS 厂商的官网首页挂着"实时率 0.3"或者"合成速度比真人快 3 倍"——这说的是整句合成耗时:一句 5 秒的话,1.5 秒合成完。这个数字对离线场景(把一本书转成有声书)有意义,对实时对话几乎没意义。 实时对话里真正决定体验的是 TTFA(time-to-first-audio,首包音频延迟):从你把文字喂给 TTS,到第一段能播放的音频抵达用户、开始出声,中间隔了多久。 道理和流式 LLM 一样。LLM 看的是首 token 延迟(TTFT),不是整段生成完的时间;TTS 看的是首包,不是整句。因为一旦第一个音节开始播,后面的音频是边合成边播的——只要合成速度比播放速度快(实时率小于 1),用户就永远听不到"卡壳"。整句要 1.5 秒还是 3 秒,用户根本感知不到,他在听前半句的时候,后半句已经悄悄合成好排在缓冲区里了。 所以这篇标题里的"150ms",指的是 TTFA。这是 2026 年一个够格但不极致的数字:对话不会让人觉得"AI 在想",但还没到 Cartesia Sonic-3 那种 40ms 模型延迟的极限。 有个数字陷阱要先点破。厂商宣传的"75ms"或"100ms"通常是纯模型推理时间——在一块独占 GPU 上,喂一段短文本,模型吐出第一块音频要多久。它不含网络往返、不含 API 网关排队、不含音频编码、不含你播放器的缓冲。一个 benchmark 跑 100ms 的模型,部署在共享云上、赶上流量高峰,端到端能轻松飙到 800ms。所以看 TTFA 数字,永远要问一句:这是模型延迟,还是用户真实感知到出声的延迟?这篇说的 150ms,是后者。 首包延迟花在哪 把 TTFA 拆开,大致是这么几块: ...

2026-05-13 · 2 min · Chico

语音克隆的滥用与检测

2025 年第一季度,美国境内利用深度伪造语音的电话诈骗(vishing)环比涨了 1600% 多。同一年 FBI 的互联网犯罪报告里,跟 AI 相关的诈骗投诉超过 2.2 万起,涉案金额 8.93 亿美元。 这些数字背后有一个让人不舒服的事实:克隆一个人的声音,现在只需要三秒公开音频。你公司高管参加过的每一场财报电话会、每一次大会演讲、每一段播客采访,都躺在公网上,对想用它的人来说就是现成的训练素材。 克隆技术本身已经不是新闻——这个博客之前写过《声音克隆:60秒复制你的声音,然后呢?》。这篇讲"然后"的另一面:声音一旦能被以假乱真地复制,我们靠什么分辨真假,以及这件事到底能做到多好。 滥用长什么样:三种,不是一种 把"AI 语音诈骗"当成一个笼统的词,会让你低估它。它至少是三类性质不同的攻击。 第一类是社工诈骗。 最经典的是"亲人求救":伪造你孩子的哭腔打电话说出事了急需用钱。但 2025 年真正造成大额损失的是企业版——伪造 CEO 或 CFO 的声音,指示财务转账。香港那起 2.56 亿港元的案子是个标志:财务员工参加了一场视频会议,会议里的 CFO 和同事全是 AI 生成的,人脸、口型、声音都对得上,他一开始怀疑是钓鱼,但一场"活的"视频会把他的怀疑全打消了,直到事后跟总部人工核对才发现。 第二类是声纹绕过。 不少银行和券商用"我的声音就是我的密码"做身份验证。克隆语音直接攻击这套系统。它比社工诈骗更隐蔽,因为受害的不是某个被吓住的人,而是一套自动化的认证流程——没有人在场可以"觉得不对劲"。2025 年 1 到 8 月,某金融机构的活体检测被 AI 伪造尝试绕过了 8000 多次。 第三类是假音频内容。 伪造公众人物的录音、伪造一段"泄露的会议录音"、给某段视频配上从没说过的话。它不针对个人钱包,针对的是舆论和信任。2024 年美国大选期间出现过伪造拜登声音的自动外呼电话,就是这一类。 三类攻击的防御手段完全不同。社工诈骗要靠流程和人的警觉,声纹绕过要靠活体检测,假内容要靠溯源和检测——别指望一招通吃。 检测合成语音:能做到,但有前提 检测分两条路:被动检测(拿到一段音频,判断它是不是 AI 合成的)和主动标记(生成时就打上记号)。先说被动。 被动检测模型在学术基准上的成绩相当好。这个领域有一套延续多年的评测体系——从早年的 ASVspoof 挑战赛,到 2026 年 ICME 的环境感知语音检测挑战赛(ESDD2)、ACM Multimedia 的全类型音频伪造检测挑战赛(AT-ADD)。检测模型也在进步:用 Whisper 这类大规模语音模型抽特征,比传统声学特征的等错误率(EER)低了约 21%,再针对反伪造任务微调 Whisper 编码器,还能再降近 15%。 听起来不错。但"在干净数据集上 EER 很低"和"在真实世界管用"之间,差了一整条鸿沟。 flowchart TD A[一段语音] --> B{被动检测模型} B -->|实验室条件| C[准确率很高] B -->|真实世界| D[麻烦开始了] D --> E[电话信道压缩] D --> F[录音回放/翻录] D --> G[训练时没见过的新 TTS] D --> H[环境噪声/混响] style C fill:#d8f0d8,stroke:#5aa05a style D fill:#fde7c2,stroke:#e8b23c 真实世界里有三个东西在持续打击检测准确率: ...

2026-04-27 · 2 min · Chico

语音合成的情绪与韵律:怎么让 AI 不像念稿

把同一句话放给两套 TTS 念:“你说得对,这个我之前还真没想到。” 两套都咬字清楚、没有杂音、采样率拉满。但其中一套你一听就知道是机器——不是因为它念错了,恰恰是因为它念得太"齐"了。每个字的时长几乎一样,每个停顿都卡在标点上,整句话像被一把尺子量过。 人不是这么说话的。人说"还真没想到"的时候,“真"会拖长一点,“没"会轻一点,“想到"前面会有个几乎听不见的迟疑。这些东西加起来,就是韵律(prosody)。发音准是 2020 年就解决的问题;韵律和情绪,才是 2026 年还在啃的硬骨头。 这篇讲清楚:念稿感到底差在哪儿,以及现在有哪几条路去补。 念稿感不是发音问题,是韵律问题 先把概念拆开。一段语音里,“说了什么"是文本内容,“怎么说的"是韵律。韵律不是一个东西,是四样东西叠在一起: 节奏(timing)——每个音、每个词占多长时间,语速是匀的还是有快有慢。 停顿(pause)——停在哪里,停多久。停顿不只在逗号句号,也在一个意群说完、或者你要强调下一个词之前。 重音(stress)——哪个词被加重了。”我没说过"和"我没说过”,意思完全不同。 语调(intonation)——句子的音高曲线。陈述句往下走,疑问句往上挑,反问句又是另一条线。 念稿感的根源,是早期 TTS 把这四样都做成了"默认值”:语速恒定、停顿只认标点、不分轻重、语调按句型套模板。结果就是每句话都念得四平八稳,像新闻联播里的提示音。 更麻烦的是,韵律和情绪是强耦合的。同样一句"你来啦”,高兴时音高整体偏高、句尾上扬;敷衍时又平又短;惊讶时第一个字猛地拔高再回落。情绪不是在准确的发音上再"刷一层颜色”,情绪本身就是通过韵律表达出来的。所以"TTS 加情感"这件事,本质上是"让 TTS 学会控制韵律"。 学术界很早就指出了拦路的三个问题:标签依赖(模型只会照训练时见过的"高兴/悲伤"几个标签走)、风格纠缠(想让它变开心,音色也跟着变了)、控制粒度太粗(只能整句一个情绪,改不了某个词)。这三条到现在也没完全解决,只是被绕过的方式越来越多。 控制韵律的四条路 2026 年要给语音"调情绪",大致有四种手段,从"最可控"到"最自然"排开,正好是个谱系。 flowchart LR A[SSML / 标记精确·机械] --> B[参考音频自然·难复用] B --> C[指令式控制灵活·偏意会] C --> D[上下文感知省心·难调试] style A fill:#fde7c2,stroke:#e8b23c style D fill:#cde9d6,stroke:#3c9e6a 第一条:SSML 和标记。 这是最老、也最确定的办法。你用标记语言显式地告诉引擎:这里停 300 毫秒、这个词音高升 10%、这段语速放慢。SSML 至今仍是工业界控制语音合成的事实标准,因为它可复现——同样的标记,出来的语音每次都一样。它的代价也明显:你得手动标,标多了维护成本极高,而且本质上是在用规则逼近一个连续的东西,生硬的接缝藏不住。新一代模型在 SSML 之外加了实验性的情绪标签,比如在句首写 [surprised],让整句带上惊讶的底色——比纯 SSML 省事,但仍然是离散的、一句一个。 第二条:参考音频。 不告诉模型"要开心",而是直接丢给它一段开心的录音,让它"照着这个感觉说"。Qwen3-TTS 这类模型 3 秒参考音频就能克隆音色和说话风格,Fish Audio S2 用 10 秒参考做跨语种迁移。这条路的好处是自然——韵律是从真人录音里"抄"来的,不是算出来的。坏处是难复用:你想要一个"略带歉意但又不卑微"的语气,得真去找到或录一段这样的音频,而且参考音频里的情绪和音色经常分不干净。 第三条:指令式控制。 用自然语言描述你要的效果:“用安慰的语气,慢一点,句尾别上扬。“这是 LLM 时代才成立的玩法。它灵活到几乎没有边界,你能描述出任何细微的语气。但它也最"意会”——同一句指令,不同模型、甚至同一模型不同时候,理解都可能有偏差。它适合创作和探索,不适合需要每次结果一致的生产链路。 ...

2026-04-26 · 2 min · Chico

ASR 工程:语音识别落地的那些坑

你试用一个 ASR 模型,拿手机对着它念一段稿子,转写结果几乎一字不差,你心里想:这事成了。 然后你把它接进真实业务。客户在马路边打来电话,背景是车流声;他说到你公司的产品名,转写出来是三个完全不相干的字;他报了一串订单号"一三幺零",屏幕上是"一三妖灵"。Demo 里的惊艳,到这里一点都不剩。 问题不在模型菜。开源的 Whisper、各家的流式 ASR,安静环境下的中文字错率早就压到了 3% 以下,这已经接近人工转写的水平。坑全在"安静环境、念稿子"这八个字之外——真实的语音是脏的,而工程的活,就是处理这些脏东西。这篇把落地之后才会碰到的坑,一个一个拆开。 第一个岔路口:流式还是非流式 这是接 ASR 之前必须想清楚的第一件事,选错了后面全是返工。 非流式(批量):把一整段音频丢进去,等它整段识别完,返回结果。流式:音频一边录一边送,模型一边听一边吐字,你能拿到不断更新的"中间结果"。 差别不只是"快一点慢一点"。它们是两类不同的产品形态: 维度 流式 ASR 非流式 ASR 典型延迟 首字 200–300ms,说完即出 等说完后再算,3 秒话约多等 0.5–2 秒 准确率 略低(只能看到左边的上下文) 略高(能看到整句,甚至整段) 成本 贵(常见 $0.016/分钟级别) 便宜(常见 $0.008/分钟级别) 适用 语音 Agent、实时字幕、点单 会议录音转写、客服质检、播客字幕 记住一个核心事实:流式之所以准确率低,是因为它在"说完之前"就得交答案。它做"我想订一张去——“的转写时,根本不知道后面是"北京"还是"报告”。非流式没这个包袱,它能等整句听完再回头修正,所以同样的模型,非流式版本的字错率往往低一两个百分点。 这里有个 2026 年很常见、但容易踩反的折中:用 VAD 把长音频切成"准句子",每段当成一个 mini-batch 走非流式模型。这套做法在"实时字幕"这种场景里很香——它不需要逐字滚动,用户能接受"一句一句往外蹦",于是你既拿到了非流式的准确率,延迟又只是一句话的长度。但如果你做的是语音 Agent,用户在等 AI 回话,那这套就不行——你必须真流式,让 ASR 和用户说话并行跑,说完文字基本也就好了。 别被"我两个都要"骗了。 一个产品里通常只有一条主链路。先确定用户是不是在"等",再选。 专有名词、中英混读、数字:错得最离谱的三类 通用 ASR 在通用语料上训练,所以它对"通用的话"很强,对"你的话"很弱。落地后用户投诉最集中的,永远是这三类。 专有名词。 你公司叫"声析",模型从没见过这两个字的组合,它会按发音找一个最像的常见词——“声息"“生气"“省吃”。这不是模型蠢,是它在做概率上最合理的猜测。人名、产品名、内部黑话、行业术语,全是重灾区。 中英混读。 中文工程师说话天然混英文:“这个 bug 我提了个 PR"“把 latency 压下来”。问题是很多 ASR 在"语种判定"上是僵的——它先猜你这句是中文还是英文,再用对应的解码路径。猜错了,“PR"变成"批 R”,“latency"变成一串看不懂的拼音。2026 年好一些的方案(比如 Gladia、Deepgram Nova-3)做了句内 code-switching,语种切换不需要整句重判;但便宜的、老的模型,中英混读仍然是硬伤。 ...

2026-04-25 · 2 min · Chico