实时语音对话的延迟预算:把「AI 慢半拍」拆到毫秒

你跟一个语音 AI 说完话,它停顿了一下,才开口回答。 那一下"停顿",就是它不像人的地方。 人类对话的轮次间隔(turn-taking gap)中位数只有约 200ms,熟悉的人之间还经常"抢话"——下一句在上一句结束前就接上了。一旦 AI 的回应超过 500ms,你会明显感觉到"它在想";超过 800ms,对话就开始别扭,你会忍不住重复自己,或者以为它没听见。 所以做语音 Agent,延迟不是"优化项",是及格线。这篇把从【用户说完最后一个字】到【AI 喇叭里出第一个音】之间发生的事,拆到毫秒。 这条流水线长什么样 flowchart LR A[用户说话] --> B[轮次判定VAD + 端点] B --> C[ASR语音转文字] C --> D[LLM首 token] D --> E[TTS首包音频] E --> F[AI 出声] style B fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色的两块——轮次判定和 LLM 首 token——是预算里最大的两笔开销,也是最值得花力气的地方。 一份现实的延迟预算 环节 它在做什么 典型耗时 轮次判定(VAD + 端点) 判断"用户真的说完了" 50–250 ms ASR(语音转文字) 把语音转成文字 ~0–150 ms* LLM 首 token(TTFT) 想出第一个字 250–500 ms TTS 首包 合成出第一段音频 75–200 ms 网络往返 客户端 ↔ 服务端 30–80 ms 合计(可感知) 约 500–900 ms * ASR 与用户说话并行进行,大部分转写在用户说完之前就做完了,所以它对预算的增量很小——前提是你用的是流式 ASR。 ...

2026-05-19 · 2 min · Chico

语音模型这一年:从 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

实时语音的打断:barge-in 怎么做对

约五分之一的语音通话里,用户会在 AI 还没说完时开口插话。 这个数字来自 PolyAI 对生产环境通话的统计,我自己看线上日志,感受也差不多。更值得注意的是后半句:会打断的用户,往往是意图最强的那批人。 他们听够了想直接说事,或者发现 AI 理解错了要赶紧纠正。换句话说,打断处理得烂的那一小撮通话,直接决定了你整个产品体验的天花板——因为最在乎、最着急的用户,恰好都撞在这里。 所以"能被打断"不是锦上添花的功能。它和延迟一样,是语音 Agent 的及格线。但和延迟不同,打断的难点不在毫秒,在于它是一个并发控制问题:一个事件要同时掐断好几条正在跑的流,还不能掐错。 为什么打断比想象中难 很多人第一次做打断,以为就是"检测到用户说话,调一下 audioPlayer.stop()"。上线一周就会发现到处是坑。 难在三个地方。 第一,打断是个分布式的取消操作。用户开口的那一刻,你的系统里可能同时有:扬声器在播第 3 句的音频、TTS 服务还在合成第 5 句、LLM 还在流式生成第 8 句的 token。这三样东西跑在不同进程甚至不同机器上。你要在几十毫秒内把它们一起叫停,任何一个漏网,AI 就会出现"我已经打断它了,它怎么还在自说自话"的灵异现象。 第二,判断"这算不算打断"本身就难。背景里有人说话、电视开着、用户自己"嗯"“对啊"地随口附和——这些都会让一个朴素的 VAD 兴奋地触发打断。误打断比"打断慢了"更伤体验:AI 说到一半被一声咳嗽打断,僵在那里,用户一脸问号。 第三,打断之后,对话状态是脏的。AI 那句话只说了一半就被掐了,LLM 的上下文里到底该记成"我说了整句"还是"我只说了半句”?记错了,下一轮 AI 要么重复已经说过的内容,要么基于"它以为自己说了但其实没说出口"的信息往下接。 这三件事,后面一件件拆。 怎么知道用户在打断 打断检测的第一关,是 VAD(语音活动检测)。它干一件很窄的事:判断这一小段音频里有没有人声。现代 VAD(比如 Silero)能在几十毫秒内给出"有声/无声"的概率,这一层基本算解决了。 但 VAD 只够回答"有没有声音",回答不了"这声音算不算一次真正的打断"。2026 年成熟的做法,是在 VAD 上面叠一层判断,通常叫语义化的轮次检测。 这里要分清两个相关但不同的问题: 端点检测(turn detection):用户这一轮说完了没?——决定 AI 什么时候开口。 打断检测(barge-in):AI 正在说话时,用户这声插话,要不要让 AI 闭嘴?——决定 AI 什么时候停下。 它们共用 VAD 这个底座,但上层逻辑不一样。打断检测要额外回答的问题是:这声音是"我要说话了你停下",还是"嗯哼,我在听"。 主流框架的处理方式,可以摆在一起看: 方案 核心信号 特点 朴素 VAD 音频能量 / 人声概率 最快,但把附和、噪音全当打断 转写流启发式 VAD + ASR 部分转写文本 看用户说出的字是不是"有内容" 模型化打断判定 专门小模型读音频+文本 区分真打断 / 附和 / 噪音,准但有计算开销 LiveKit 在 2026 年走的是模型路线:它的自适应打断(adaptive interruption)用真实对话音频训练了一个小模型,AI 说话期间检测到人声,不会无脑停,而是让模型先判断"这次该不该让出话权"。Pipecat 的 Smart Turn、Deepgram 的 Flux、VideoSDK 开源的 Namo,思路都类似——从"听到声音就停"升级到"听懂这是不是打断再停"。 ...

2026-04-28 · 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

实时语音 API 横评:OpenAI、Gemini 与国内

先说一个反直觉的事实:2026 年了,真正跑在生产环境、扛着电话客服流量的语音 Agent,大多数还不是端到端语音 API 做的。 端到端听起来无可挑剔——语音直接进、语音直接出,中间不落文字,延迟低、情感保留好。OpenAI 的 gpt-realtime、Google 的 Gemini Live、豆包的端到端实时语音大模型,demo 都惊艳。但真把它塞进一个要上线的产品里,你会在第二周撞上几堵墙:它说错话你没法在中间拦一道、合规团队要审通话记录而你只有一段音频、客户要换个特定音色而 API 只给你 8 个预设。 所以选型这件事,不能只看 demo 的"哇"。这篇把实时语音 API 的关键维度摊开,再把 OpenAI、Gemini 和国内几家的真实定位讲清楚,最后按场景给建议。 先把"关键维度"对齐 挑实时语音 API,大家张口就是"延迟低不低"。延迟当然重要,但它只是八个维度里的一个。我把这八个维度列出来,你拿任何一个 API 去套都不会漏: 维度 它在问什么 容易被忽略的点 延迟 用户说完到 AI 出声多久 看的是首包,不是整句生成完 打断 能不能被插话、插得干不干净 误打断(噪音触发)比慢更恼人 音色 有多少声音、能不能定制/克隆 预设音色撑不起品牌化产品 语言 支持哪些语种、能否中途混说 方言、中英混说是国内刚需 价格 每分钟多少钱、缓存能省多少 端到端按音频 token 计费,贵 是否端到端 一个模型还是 ASR+LLM+TTS 决定了下面两项 可控性 能不能拦、能不能调试、能不能换 端到端是黑盒,这点最痛 合规 有没有文字记录可审计、数据落哪 金融/政务直接卡死非合规方案 后面三项——是否端到端、可控性、合规——是连在一起的一条逻辑链,也是真正决定选型的地方。延迟和音色反而是"达标就行"的项。 OpenAI Realtime:能力最强,也最贵 OpenAI 的 Realtime API 用的是 gpt-realtime 这个 speech-to-speech 模型,语音直接进出,一个模型一个接口搞定。它的强项是指令遵循和工具调用——你给它一段复杂的 system prompt、挂十个函数,它能稳稳地按规矩走、该调哪个调哪个。这一点上,目前没有对手。 ...

2026-04-19 · 2 min · Chico

TTS模型微调:用自己的声音训练语音模型

两个主流开源方案 模型 特点 数据需求 显存要求 XTTS v2 多语言,效果稳定 2-20分钟 12GB+ Fish Speech 中文效果好,速度快 3-10秒起 4GB+ 方案一:XTTS微调 准备工作 硬件要求: GPU:12GB显存以上(推荐16GB) 内存:16GB以上 数据要求: 至少2-3分钟清晰录音 推荐5-20分钟效果更好 WAV格式,16kHz以上 安装 1 2 3 git clone https://github.com/daswer123/xtts-finetune-webui cd xtts-finetune-webui pip install -r requirements.txt 数据格式 1 2 3 4 5 6 dataset/ ├── audio/ │ ├── 001.wav │ ├── 002.wav │ └── ... └── metadata.csv metadata.csv 格式: 1 2 3 audio_file|text|speaker_name audio/001.wav|今天天气真不错。|my_voice audio/002.wav|我们去公园散步吧。|my_voice 训练配置 1 2 3 4 # 关键参数 batch_size: 2 # 显存不够就调小 epochs: 10-50 # 数据少就多跑几轮 learning_rate: 5e-6 # 别调太大,容易过拟合 常见问题 问题1:训练后声音变奇怪 → 过拟合了,减少epochs或增加数据 ...

2026-01-16 · 2 min · Chico

TTS数据准备:从录音到训练的完整流程

数据决定上限 TTS模型效果好不好,80%取决于数据质量。 常见问题: 录音有底噪 → 合成出来有杂音 音量不稳定 → 合成忽大忽小 断句不自然 → 合成节奏奇怪 录音要求 硬件 设备 推荐 预算 麦克风 电容麦(如AT2020) ¥500-1500 声卡 独立声卡或USB麦 ¥300-800 环境 安静房间+吸音棉 ¥100-300 录音参数 1 2 3 采样率: 48kHz(至少16kHz) 位深: 24-bit 格式: WAV(无损) 录音技巧 距离:麦克风离嘴15-20cm 音量:保持-12dB到-6dB之间 状态:正常语速,自然呼吸 时长:至少2小时(5-10小时效果更好) 数据清洗流程 graph LR A[原始音频] --> B[降噪] B --> C[音量标准化] C --> D[切分句子] D --> E[对齐文本] E --> F[质量检查] F --> G[训练数据] 1. 降噪 工具:Audacity(免费)、Adobe Podcast(在线) 1 2 # 使用ffmpeg + rnnoise降噪 ffmpeg -i input.wav -af "arnndn=m=rnnoise-models/bd.rnnn" output.wav ⚠️ 注意:过度降噪会导致声音失真,宁可保留少量底噪 ...

2026-01-15 · 1 min · Chico

Voice Agent架构:从语音输入到智能响应

Voice Agent 是什么 一句话:能听会说的AI助手。 graph LR A[用户说话] --> B[ASR语音识别] B --> C[LLM理解+生成] C --> D[TTS语音合成] D --> E[播放给用户] 看起来简单,但要做好有三个核心挑战: 延迟 - 用户说完到AI回复,要控制在1-2秒内 打断 - 用户随时可以打断AI说话 自然度 - 不能像机器人一样僵硬 核心架构 方案一:串行流水线 1 用户说话 → [等说完] → ASR → LLM → TTS → 播放 优点:实现简单 缺点:延迟高(3-5秒) 适合:对延迟不敏感的场景(如语音留言) 方案二:流式处理 1 用户说话 → [边说边识别] → [边生成边合成] → [边合成边播放] 优点:延迟低(1-2秒) 缺点:实现复杂,需要处理中间状态 适合:实时对话场景 关键组件 1. ASR(语音识别) 方案 延迟 准确率 成本 Whisper API 1-2s 95%+ 按时长计费 Deepgram 200ms 90%+ 按时长计费 本地Whisper 500ms-2s 95%+ 需要GPU 实时识别关键: ...

2026-01-14 · 2 min · Chico

声音克隆:60秒复制你的声音,然后呢?

先说个真事 朋友公司有人收到"老板"的语音消息,让转账50万。声音、语气都对,差点就转了。后来发现是AI克隆的——骗子从老板的抖音视频里扒了几十秒素材。 这就是现在声音克隆的水平:以假乱真。 60秒能干什么 用ElevenLabs举例: 1 2 3 4 5 6 7 8 9 10 11 12 13 from elevenlabs import clone, generate # 上传60秒录音 voice = clone( name="我的声音", files=["sample.mp3"] ) # 让它说任何话 audio = generate( text="这话我从没说过", voice=voice ) 就这么简单。效果好到专业人士都分辨不出。 能用来干什么 正经用途: 有声书制作(成本从10万降到1千) 虚拟主播(24小时不下播) 游戏NPC配音(1000个NPC,1000种声音) 帮失声的人"说话" 不正经用途: 诈骗(前面说的那种) 伪造录音 未经授权用别人的声音 怎么防骗 涉及转账,打电话确认。语音消息不算数。 设暗号。家人之间约定一个只有你们知道的词。 听细节。AI声音太"完美"——没有呼吸声、没有口水音、没有犹豫。 怎么玩 免费方案: Coqui TTS(开源),需要自己部署 付费方案: ElevenLabs,$11/月起,效果最好 录音技巧: 安静环境 正常语速 至少60秒,内容越丰富越好 配音演员会失业吗 低端活会被抢:有声书旁白、广告配音、游戏NPC。 ...

2026-01-10 · 1 min · Chico