语音AI其实是三件事：听清、会说、像谁 ​

魔当实验室 · 2026年10月

本文是"AI技术科普"系列第七篇。《本地 AI 工具的四层》那套分层方法在这里比语言模型还管用，《模型文件到底从哪来》讲的"软件不产生模型"也一样成立；《本地 AI 出图、出片》说过的"输出类型决定机器要承多大的活"，语音是第三种答案。文中的机器账来自我们自己维护的本地应用清单，模型信息口径均为 2026 年 10 月查询。不做在线服务比价、不排名次、不放下载和注册链接，也不讲音乐生成。

AI技术发展很快，文中提到的工具、模型和数据反映的都是当前阶段的情况，具体功能与授权条款以各项目官网与其代码仓库、模型仓库为准。

先把"装个 Whisper"这件事拆开 ​

语音是本地 AI 里最容易装错的门类，原因很简单：它比文字多一层。很多人说自己"装了 Whisper"，实际上他装的是三层东西叠在一起的一个组合。

这三层不是套娃，是三次独立的选择——和第 2 篇讲的四层是同一件事：同一层里比高低才有意义，跨层比出来的结论都是废话。"Whisper 和 FunASR 哪个强"这种问法其实问不清，因为前者是一批模型、后者是一整套带标点和说话人分离的工具箱，它们各自的加速方式还不一样。

我们把收进本地应用清单的语音软件按这三层对了一遍，34 个语音相关的应用里，做识别的 8 个（其中 1 个两边都做），做合成的 26 个。出声的选择比认字的多出三倍，这不是巧合：识别这件事已经被几个两三百兆参数的小模型做到基本够用，合成还在比音色、比情绪、比语种覆盖，所以供给一直在往上堆。

三个方向，比的是三样东西 ​

语音AI看着是一件事（跟电脑用说话打交道），拆开是三件：听（语音识别）、说（语音合成）、像谁（音色克隆）。它们的难点完全不同，装的时候踩的坑也不一样。

还有一样容易和这三件事混在一起的：给视频配环境音和音效。清单里 MOSS-SoundEffect、ThinkSound、Woosh、Stable Audio 3 都归在这一类，它们不念字，做的是"这段画面该有什么声音"。给一段无声素材铺上门声和雨声，和把一段文字念成中文，是两个任务，别拿同一个工具硬凑。

魔当实验室的建议是先记住一句结论："听"是本地最划算的一件事，"说"是本地最挑机器的一件事，"像谁"是本地最需要你先想清楚用途的一件事。原因分别在下面三段。

先算一笔看得见的账 ​

抽象地说"语音比文字吃机器"没什么用。我们把清单里每个语音应用的实际安装要求抄出来统计了一遍（这些数字是我们自己做安装包时逐条核对的口径，硬盘是装完之后的占用量级，显存是 Windows 侧标注的最低门槛，2026 年 10 月查询），分布是这样的：

三个结论都能直接用。

其一，本地转写真的便宜。 SenseVoice 的官方口径是 234M 参数，我们记录的包体只占 10GB 出头，内存建议 8GB 以上、CPU 就能起步；而做同一件事的 Whisper-WebUI 要 24GB。差别不在识别精度，而在包里塞了多少模型和多少运行环境——CosyVoice 的安装说明里就写着，装的时候会连着下载 0.5B 版本和历史版本的多个模型。所以"语音占硬盘"占的往往不是权重，是你顺手一起装进来的那些版本和依赖，这笔账和第 3 篇里"文件体积不等于参数量"是同一条。

其二，配音这一头把机器要求拉开到了四倍。 同是"把字念成声音"，清单里 CosyVoice 标的是 4GB 显存起，PilotTTS 和 VibeVoice 标 6GB，IndexTTS 2 / 2.5、dots.tts、FireRedTTS3、VoxCPM2 这批标 8GB，AuK 标 12GB，MOSS-TTS 1.5 标 16GB——最后一档在普通游戏显卡上直接跑不动。先按自己这张卡划掉一半选项，再谈挑哪个，这比看任何横评都省事。真想在没显卡的机器上出声，走的是另一档：MOSS-TTS-Nano 这类超轻量模型 CPU 就能跑，代价是音色和情绪都平淡一些。

其三，"Intel 的 Mac 装不上配音模型"是引擎层的事，不是模型算不动。 26 个合成应用里 15 个在苹果机器上只支持 M 系列，而 8 个识别应用一个都没有这个限制。原因很实在：新放出的合成模型大多绑 CUDA 的训练与推理路径，苹果这边要么走 MLX、要么走 CoreML 重写一遍，没重写的就干脆不支持；识别这一层的工具早就有 CPU 与跨平台部署路线，所以 Intel Mac 也还剩得下。买机器之前把这条看清楚，比事后折腾省事得多。

听：真正要问的是"有没有显卡、要不要实时" ​

转写是最容易被本地方案拿下的方向，因为它对显存的要求远低于图像和视频，而且这一代小模型快得夸张。

公开实测里流传最广的一组对比是这样的（口径多为项目方与社区自测，2026 年 10 月查询，当量级参考）：SenseVoice-Small 在 CPU 上就能跑到十几倍实时，一段十秒的录音大约六百毫秒出结果；而 Whisper large-v3 有 1.5B 参数，即便在旗舰消费级显卡上也只有十几倍实时，一小时会议录音要等上几分钟。也就是说，一个专门为本地设计的小模型，在 CPU 上比一个通用大模型在显卡上更快。

真正拉开使用体验的是"除了字以外还给什么"。清单里这一档分得很清楚：FunASR 把标点、说话人分离、时间戳拼成一条能直接用的流水线，因为它要解决的是"整理一段采访"而不是"识别一句话"；MOSS-Transcribe-Diarize 的官方介绍写的正是 50 多种语言的长音频转写、说话人区分与精准时间戳，这是给会议记录和访谈稿准备的；Confucius4-R2T2 反过来，主打低延迟实时、输出稳定连续的文字，适合边说边出字的场景；Qwen3-ASR 覆盖几十种语言与方言，官方还专门提到歌词识别——做音乐字幕的人确实会冲这一条来。GLM-ASR 则把方言和低音量当作卖点。至于老牌的那条路线，Whisper-WebUI 到今天仍然常被提起，一部分原因就是它顺手把翻译也做了。

第二件事是语言覆盖。Whisper 的模型卡列了近百种语言，但社区公认的短板恰恰是中文方言和中英混读；主打中文的几家在这两处更稳。也有反例值得知道：NVIDIA 那批 Parakeet 系列在英文和欧洲语言上表现很好，公开文档列出的覆盖语言里根本没有中文——"最强的英文 ASR"和"能用的中文 ASR"在 2026 年仍然是两个答案。至于榜单，开放评测里 2026 年上半年确实出现了平均错误率低于 Whisper large-v3 的新模型，但榜单口径（测试集、语言配比）各不相同，拿来当参考就好，别当结论。

第三件事是"要不要实时"。把一小时的录音放着让它慢慢转，和边说边出字，是两套工程：后者要求模型能流式输出、要配合断句和静音检测。sherpa-onnx 这类跨平台部署框架就是冲这个来的——它覆盖流式与非流式识别、语音合成、静音检测、关键词唤醒，能跑在 x86、ARM 甚至部分 NPU 上。如果你要的是"手机上离线也能记字"，那挑的是引擎层，不是模型层。

所以本地转写的分流其实很简单：只有 CPU、要处理大批量中文素材，就从 SenseVoice、FunASR 这一档加统一工具箱起步；主要处理英文和欧洲语言、追求开箱即用，Whisper 这条老牌路线仍然是最稳的起点；要装进设备里做实时，先确认引擎支持流式，再回头挑模型。

说：三条路，各解决一类麻烦 ​

合成比识别难，因为"能念出字"和"听起来像人"之间差着一整个时代。2026 年的本地 TTS 大致分三派。

派系之外，有三件具体的事值得提前知道。

控制力已经卷到很细的地方了，而细的地方正好是坑。 我们在清单上给每个应用记的能力标签就是按这些维度分的：音色设计、情绪控制、长文本、跨语言。举几个具体的：IndexTTS 2.5 把拼音和音标级别的发音纠错当卖点，这解决的是中文配音最烦的多音字和人名读法；PilotTTS 声称能操控十几种情绪和笑声、换气这类语气词，还带一批地方方言；FireRedTTS3 的方言语种在清单里是标得最多的一档；VibeVoice 主打超长篇幅、多角色对话，也就是播客和有声书这一类一次要念几万字的活；Breeze TTS 2 和 CosyVoice 走的是流式，边生成边出声，适合要做能插话的助手那种场景。这些能力不是同一件事，别拿"最像人"这一个指标去选——给三分钟视频配音要的是情绪和长文本，做个实时助手要的是延迟。

中英混读和数字是所有模型的公共坑。 社区实测里反复出现的结论是：纯中文或纯英文表现好的模型，一旦句子里混进另一种语言就会崩；有的模型音质很高但会把阿拉伯数字读错甚至吞掉。所以别用一个模型跑所有素材，先按你的实际内容类型试一小段——这比看任何横评都可靠。

这一层的"能不能商用"要看四样东西，不是两样。外壳软件、推理引擎、模型权重，加上你拿来当参考的那段声音本身。前两层常有明确的 MIT、Apache 2.0；权重层不少仓库写的是识别不出格式的声明（不等于可以商用，也不等于禁止，只能回到仓库自己的条款里去看）。我们这边有个更直观的例子：一个把几十种音频模型收进同一个界面的聚合工具，它的授权栏里同时写着五种不同的条款——因为那不是一个软件，那是几十个东西叠在一起。至于最后一样，用自己的声音没什么争议，用别人的声音就是另一回事了，这条线不在本文范围里。

像谁：一条是"抄"，一条是"养" ​

克隆这件事被短视频带火，但技术上是两条完全不同的路。

第一条是零样本，业内也叫"抄"：你给几秒到几十秒的参考音频，模型当场把音色挪过来念新内容。清单里这一族最密：F5-TTS、VoxCPM、Spark-TTS、dots.tts、CosyVoice、GLM-TTS、Qwen3-TTS、LongCat-AudioDiT，连 GPT-SoVITS 也常被人拿几秒素材当零样本用。它的长处是省事，短处是相似度封顶在参考素材的质量上——背景有噪音、有混响、说话人换了距离，出来的就不像。第二条是微调，也就是"养"：拿几十分钟到几小时你自己的干净录音认真训练一个专属版本，慢、要占资源，但稳定性和相似度都高一档，GPT-SoVITS 那套"炼丹"流程在这一档流传最广，星标数在代码平台上是这一类里最高的一档（2026 年 10 月查询）。

现在的克隆也不只是搬音色了。Confucius4-TTS 的官方说明写的是一段音频同时克隆音色与情绪，Chatterbox 把跨语言克隆和精细情感控制放在一起，Step-Audio-EditX 主打生成之后再改情绪和语气——"像"这件事的评价维度已经从"像不像那个人"变成"像不像那个人在那句话里的那个状态"。

判断标准只有一条：你需要的是一次性的像，还是长期每天都像。偶尔做一条视频，零样本足够；要长期用自己的声音批量出内容，值得为它做一次微调。还有一句实话值得写在前面——本地跑语音这件事，很多人最后卡住的地方根本不是模型，是素材。参考音频里混进了键盘声、空调声，或者说话时离麦克风忽远忽近，再强的模型也救不回来。

大多数人不装语音模型，却在天天用语音 ​

清单里有一类应用值得单独拎出来，因为它说明了一件事：语音最常见的用法，是藏在一条流程里，用户根本不知道自己调了哪个模型。

pyVideoTrans 一条链把视频翻译、字幕生成和配音做完；MoneyPrinterTurbo 从文案到素材、配音、字幕、配乐全自动出片；LatentSync 让一张静态人像跟着音频张嘴说话，我们记录的显存门槛是 6.5GB；SoulX-Podcast 是把文稿直接铺成多说话人播客。这几个的共同点很实在：它们的输入是文件，输出也是文件，中间识别和合成各是哪家的模型，用户在软件里换个下拉框就行。而第 6 篇讲的 ComfyUI 在这份清单里的定位也顺手带上了语音和音乐——同一个节点图里，出图和出声是两类节点，不是两个软件。

所以如果你本来就在做字幕、配音、切片视频，那你的选型问题其实已经被人替你答过一半了：先看你已经在用的那款流程工具支持挂哪些语音引擎，再决定要不要单独装一个。

第四个方向在换掉一层 ​

三个方向之外，2026 年多了一个不太好归类的新东西：端到端语音对话。

传统做法是三段流水线：先把你说的话转成文字，交给语言模型推理，再把结果念出来。每一步都吃延迟，而且转文字那一步会丢掉语气、迟疑、笑声这些东西。端到端路线把这些合并进一个模型直接处理音频：Moshi 是这条路上被讨论最多的开源参考实现，它的做法是同时开三路——一路听你说、一路生成它自己的声音、一路在内部维护一份文字独白，因此能做到你随时插话它随时接得住（全双工），公开资料里给的往返延迟量级在两百毫秒左右。今年这个方向明显在加速：上半年有厂商放出基于这套架构改进的全双工模型并采用宽松许可，10 月又有一家公司公开演示了一个不经文字环节、会笑会叹气的语音对话模型（媒体报道口径，尚未有可自证的权重公开）。

对个人用户来说，现在下结论还太早。这类模型体量普遍在 7B 上下，实时全双工还要把音频编解码一路压进同一台机器——这正是前面那笔账的延伸：能不能跑和跑起来等多久，是两件事。所以今天本地更划算的做法仍然是"级联"：识别用轻量小模型、推理用你已经在跑的语言模型、合成用 CPU 也能出声的轻小 TTS——三段各自挑合适的档位，加起来反而更快、更省显存。这类模型真正值得留意的是它在换掉哪一层：它把"外壳层"的编排逻辑收进了模型内部。等它降到手机端能跑的体量，前面那张三层表里第二层和第三层会被重新画一遍——就像毕业模型那篇里说的，能替人干活的从来不是单点能力，是链路。

外壳这一层，才是大多数人该先选的 ​

语音这一层有个别的门类没有的现象：普通人用的多半不是模型仓库，是整合包。

图形界面这边有 Buzz、Whisper-WebUI、MacWhisper 这类"拖进去就出文字"的转写软件；苹果芯片的机器上另有 MLX 路线的实现，把语音模型和文字模型一起收进同一个命令行工具。跨平台部署有 sherpa-onnx 这种把识别、合成、静音检测打包在一起的工具箱。再往上就是聚合工作台：清单里 audio.cpp WebUI 是这一档最典型的形状——同一个界面里支持几十种音频模型，语音生成、识别、转换和音乐创作都在一处，包体 13GB，内存 8GB 就能起，Intel 和苹果 M 系列都支持。它的授权栏里同时写着五种条款，这一点前面提过：外壳替你省的是切换成本，替你增加的却是需要看清的授权层数。

这一层的另一个价值是"帮你绕过命令行"。做配音、做字幕的人大多不是从代码仓库开始上手的，而是从整合包开始：下载、解压、双击启动，模型和依赖已经配好。这和第 4 篇说的那句是一致的——多数人被劝退不是因为选错了软件，而是第一次尝试就撞上了和环境有关的麻烦。市面上已经能看到一些把语音模型、依赖和常见音色文件打包在一起、做类似"一键安装、开箱即用"的方案，就是冲着这个位置来的。

几个问题帮你定位 ​

1. 我是听还是说？只是想把录音变成文字，那么 10GB 出头、CPU 起步的这一档就能开工；想让它替你念出声音，才需要开始算显存——清单里从 4GB 到 16GB 的门槛都摆着。
2. 我这台机器装得上下那一档吗？没有独立显卡、或者手里是 Intel 芯片的 Mac，就先在识别和轻小合成里起步，别去碰那些只支持 M 系列和 CUDA 路径的合成模型。
3. 我的内容里有没有中英混读、数字、方言、多音字？这四个是最容易翻车的地方，先拿一小段真实素材试，比看任何对比都准。
4. 我要"一次性像"还是"长期像"？前者几秒钟素材的零样本方案就够；后者值得做一次微调，并且要为素材质量花时间。

语音的产出是文件，不是答案 ​

文字类任务跑完给你的是一段回答，语音跑完给你的是可以直接放进成片的音频文件——这也是它和图像视频一样，属于"生产资料"而不是"聊天玩具"的那一类。

魔当实验室的看法是：这一层的工具会比语言模型那层换得更快，因为模型、引擎、外壳三层同时在动，任何一层的更新都会让上一层的教程失效。所以别把选型押在某个具体模型的名字上，押在三样你自己攒下来的东西：你的参考音频素材、你调好的那条流水线、以及你整理好的字稿与配音文件。这三样能跨软件带走，也能在你换掉第三个"最强模型"之后继续用。至于要不要现在就上端到端语音对话，答案是先别急——把它当成一次架构变化看着，把"听"这一头先跑通，本地语音真正的收益就在这件事上。

下一篇讲跑在这几层之上的那一层：为什么"它不知道我的东西"不是靠更长上下文解决的，见《什么是 RAG》。