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 G2P；G2P 负责把文字转换成发音表示。运行时主要影响模型执行和硬件支持，不能仅凭使用 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 开始，再用实际录音判断音质是否达标。
