kokoro-onnx这个文字转语音工具好不好我的判断是如果你希望在自己的电脑上生成语音它值得试一试。本地运行、模型较小是它值得关注的原因。至于声音是否足够好还要看你使用的语言、文本和具体音色。微软的语音合成也值得比较不过“微软 TTS”可能指不同的产品。对 Python 开发者来说先分清下面三种方案选型会容易很多Kokoro kokoro-onnx下载模型在本地生成语音。edge-tts通过社区维护的 Python 客户端调用 Edge 的在线语音服务。Azure AI Speech通过微软官方 SDK 或 API接入云端语音服务。如果做离线工具我会先试 Kokoro如果写个人小脚本我会先试 Edge TTS如果应用需要官方 API我会优先评估 Azure Speech。这些建议来自它们公开的功能和部署方式。本文没有进行实际试听或性能测试也不据此评选音质冠军。kokoro-onnx到底是什么Kokoro 是语音合成模型。模型说明介绍的是一个拥有8200 万参数的开放权重模型。“开放权重”意味着可以下载训练好的模型文件。kokoro-onnx则是另一个 Python 项目它通过 ONNX Runtime 运行 Kokoro。ONNX Runtime 是执行模型推理的软件。Python 包、模型文件和音色数据配合起来才能把文字转换成音频。分清这几层才能正确理解音质差异。Kokoro 模型和音色数据会直接影响声音文字如何转换成发音也很重要。项目针对 1.0 模型推荐使用 Misaki G2PG2P 负责把文字转换成发音表示。运行时主要影响模型执行和硬件支持不能仅凭使用 ONNX就认定声音更自然。准备好模型、音色数据和相关语言依赖后推理可以在本地完成。应用不需要把每段文字发送给远程语音服务。项目也支持 CPU因此尝试它并不以独立显卡为前提。许可证也要分开看kokoro-onnx使用 MIT模型权重使用 Apache 2.0。把它们打包进应用时要分别保留相应许可证要求的声明。注意下图上半部分的绿色边界Kokoro 的语音生成留在设备内部。下半部分的蓝色路径则跨过了网络边界。这会影响离线能力、数据流向以及网络故障时的处理方式。图中比较的是常见的本地 Kokoro、Edge 在线服务以及 Azure 托管 API。微软还有专门的嵌入式和容器方案需要另行比较不能从这张图推导出“微软 TTS 都无法离线”。你记得的微软 TTS可能是哪一种Edge TTS适合先写个 Python 小脚本如果你记得有一个 Python 包不需要 Azure 密钥就能生成微软语音那很可能是edge-tts。它连接的是 Microsoft Edge 的在线文字转语音服务不要求电脑安装 Edge 浏览器。这个包由社区维护。安装它并不等于把微软的语音模型装到了本地。它支持选择音色、调整语速、音高和音量也能输出字幕。不过项目文档明确说明不支持任意自定义 SSML。SSML 是控制语音输出的 XML 标记语言因此不能把 Azure 的 SSML 示例直接搬过来就假定功能相同。用它试听音色、制作个人听力材料起步比较方便。如果放进自动化流程我会保留替代方案通过社区客户端接入与使用 Azure 官方 API并不是同一种服务支持关系。Azure AI Speech适合需要官方 API 的应用Azure Speech 提供微软官方 SDK 和 REST API。创建 Azure 订阅与 Speech 资源后应用就可以调用服务。从文档列出的范围来看Azure 的语言和音色选择明显比 Kokoro 更广也提供停顿、发音和说话风格等控制能力。不过具体支持哪些功能要看所选音色和模型系列。名字带有“HD”并不意味着支持所有 SSML 功能。对产品开发来说它提供了一套有官方文档的服务接口。应用仍然需要处理认证、请求限制、网络故障和计费。音质究竟谁更好不限定语言、音色和文本直接比较“谁更好听”很难得到可用的结论。一个温和的英文音色可能适合有声书却读不好技术名称。一个中文音色可能把普通句子读得很清楚却处理不好英文缩写。十秒钟的演示悦耳也不能证明二十分钟的课程听起来同样舒服。Kokoro 自己的音色文档就提醒不同语言、不同音色的质量有差异。文档还提到过短的语句可能表现不佳过长的语句可能出现语速偏急。因此短句是否合并、长段落如何切分都应该放进应用测试。如果主要生成英文我会把af_heart放入第一轮试听。项目文档给它的内部评级较好但这些评级估计的是训练数据的质量和数量不是直接的试听分数也不是与微软比较后的独立评测结果。如果主要生成中文我会尽早加入微软音色做对照。Kokoro 虽然列出了普通话音色但文档也说明部分非英语语言的训练数据和发音处理支持有限。中文需要单独验证不能沿用英文的评价这也不意味着每个微软音色都一定胜过每个 Kokoro 音色。中英混读更值得单独测试例如请检查 API 的 timeout再运行 Kubernetes 的 health check。这里要听的不只是声音是否自然还包括语言切换、缩写和停顿。支持两种语言不等于能把一句话里的两种语言都处理好。另外不要把旧榜单当成今天的结论。Kokoro 的评测页面包含 2025 年 2 月保存的榜单截图不能据此判断它与今天所有微软音色的优劣。成本和速度也要放到同样的条件下比较本地运行 Kokoro不需要为每个生成字符向语音服务商付费但硬件、电费、部署和维护仍有成本。如果服务器大部分时间都在空闲摊到每个音频文件上的费用未必低。Edge TTS 通常不需要 Azure 密钥就能接入但这不能推出“无限容量”也不能把它视为与付费开发者 API 具有相同服务条款。个人实验看重起步方便产品选型还需要比较官方 Azure 服务。Azure TTS 通常按处理的字符计费。截至本文资料核查时官方价格页列出的 F0 免费层额度为神经网络 TTS 每月 50 万字符。预算前仍要确认适用条件、音色类别和配额限制。付费单价则应查看当前地区的报价不宜直接沿用旧文章里的美元价格。速度也有不同含义。语音助手关心多久开始出声有声书生成更关心整段音频何时完成。云端方案包含网络延迟本地方案则受到电脑性能影响。实际比较时至少分别记录“等待首段音频的时间”和“全部生成完成的时间”。本地模型要把首次加载与后续请求分开在线服务要计入网络时间。输入文本应相当比较的音频交付阶段也应一致。选型前做一轮小范围对照我会从实际要处理的内容里准备一组简短测试材料主要语言的普通段落。日期、价格、小数和计量单位。人名与技术术语例如 PostgreSQL、Kubernetes。“再试一次”这样的短指令。一段较长文本以及应用需要的中英混读句子。每个工具挑选两三个符合目标口音和用途的音色朗读同一组文本。播放时统一音量、使用同一副耳机并隐藏文件名减少对品牌和工具名称的先入判断。记录读音错误、漏词、重复、停顿不自然以及长时间收听是否疲劳。还要记录每份结果需要多少人工修正。稍微好听一点却经常要返工的音色未必适合每天自动生成内容。如果用于语言学习我会特别重视发音清晰、停顿合理、表现稳定。表现力更强不一定就更适合跟读和听力练习。我的选择顺序如果离线是硬要求沿下图左侧绿色的“是”分支先评估 Kokoro。如果允许联网再看是否需要官方 API。这个分支帮助确定从哪里开始最终选择仍要经过试听。本地阅读器、离线助手或者希望文本留在自己设备上的批量任务先试 Kokoro。在目标电脑上确认语言效果和生成速度再围绕它继续开发。允许联网的个人脚本、听力练习先试 Edge TTS。检查实际可用音色并让流程便于更换语音来源。需要微软官方 API、更广音色选择或者受支持的语音控制功能优先评估 Azure Speech。测试时使用未来真正打算上线的音色和功能。如果做英语学习音频我会同时试听 Kokoro 和微软如果做中文配音我会把微软放进第一轮对照如果必须离线我会从 Kokoro 开始再用实际录音判断音质是否达标。