1. 本地AI跑中文语音这件事到底在解决什么问题把开源模型塞进自己的机器里跑中文语音这个念头最早来自一个很朴素的痛点云端语音服务用着用着就开始卡脖子。要么是免费额度用完要么是网络抖动导致延迟忽高忽低要么是某些场景下根本不允许把音频传到别人的服务器上。我最早接触这块是在做一个离线会议记录工具的时候当时试了好几个在线接口转写一段四十分钟的录音等待时间从几十秒到几分钟不等完全看服务端心情。后来索性把目光转向本地部署才发现这条路比想象中宽得多。所谓本地AI跑中文语音核心就是把语音识别、语音合成这两大类模型下载到自己的电脑上用本地的算力完成推理音频数据从头到尾不出本机。能做的事情包括但不限于把会议录音转成文字稿、给视频自动生成字幕、把文字稿读成语音、做实时语音输入法、搭建离线语音助手。适合谁来参考我觉得三类人最合适一是对数据隐私有硬性要求的开发者二是想省钱又不想被API限流卡住的内容创作者三是纯粹想折腾、想搞明白语音模型到底怎么跑起来的技术爱好者。哪怕你只有一台带独立显卡的游戏本或者一台内存够大的轻薄本都能找到适合自己硬件档位的方案。这篇文章我会从整体设计思路讲起把模型选型、环境搭建、参数调优、实操流程、踩坑排查这几个环节全部拆开尽量让每个步骤都能直接抄作业。文中涉及的具体模型名称我会用通用叫法重点放在方法和逻辑上你换成任何一个同类型的开源模型思路都是通的。2. 整体方案设计与模型选型思路2.1 先搞清楚语音任务的两条主线中文语音的本地化本质上分两条线一条是语音转文字也就是ASR另一条是文字转语音也就是TTS。这两条线的技术栈、模型体积、硬件需求差别很大很多人一上来就想找一个“全能模型”把两件事都干了结果发现哪个都不好用。我的建议是分开处理各选各的专精模型通过一个简单的调度层把它们串起来。ASR这条线目前开源社区里中文效果比较能打的主要是几类架构一类是基于Transformer的端到端模型一类是Conformer结构还有一类是Whisper系的多语言模型。Whisper系的好处是中文识别准确率高、对噪声和口音的鲁棒性好缺点是模型偏大实时性一般。Conformer系的中文专用模型体积小、速度快适合做实时字幕但对方言和嘈杂环境的适应力弱一些。TTS这条线主流是VITS、FastSpeech2加声码器、以及一些基于扩散模型的方案。VITS系列音质自然、训练数据需求相对小是我个人比较推荐的入门选择。2.2 硬件档位决定模型尺寸选模型之前先摸清自己的硬件底细这一步很多人跳过结果下载了一个十几个G的模型发现跑不动。我一般按显存和内存把机器分成三档硬件档位典型配置推荐ASR模型规模推荐TTS模型规模预期效果入门档8G内存无独显tiny/base级别轻量VITS能跑速度慢适合尝鲜主流档16G内存6-8G显存medium级别标准VITS流畅接近可用进阶档32G内存12G以上显存large级别高质量VITS或扩散模型接近商用体验这里有个容易被忽略的点ASR模型对显存的需求和音频长度强相关。一段十秒的音频和一段十分钟的音频显存占用能差好几倍。所以哪怕你显存不大也可以通过切分音频的方式跑大模型只是要多写几行切片逻辑。2.3 为什么优先选ONNX或GGUF格式模型下载下来往往是PyTorch的pt或bin格式直接跑需要完整的训练框架依赖环境又大又容易冲突。我现在的习惯是优先找ONNX或GGUF格式的版本。ONNX的好处是跨平台、推理引擎轻量用onnxruntime就能跑CPU和GPU都支持。GGUF是llama.cpp生态推的格式量化做得好内存占用低特别适合没有独显的机器。量化这件事值得多说一句把模型从FP32量化到INT8甚至INT4体积能缩小到四分之一甚至更少速度提升明显代价是精度略有下降。对于语音任务INT8量化通常听不出明显差别INT4就要看具体模型了有的会开始出现吞字、音色发闷的问题。提示量化不是越小越好。我的经验是ASR模型量化到INT8基本无损TTS模型尽量别低于INT8否则合成出来的声音会有明显的机械感。3. 环境搭建与依赖安装的实操细节3.1 Python环境隔离是第一步不管你是Windows还是Linux第一件事都是建一个独立的虚拟环境。我见过太多人直接在系统Python里pip install结果把系统依赖搞崩最后重装系统。用conda或者venv都行我个人偏好conda因为可以顺便管理CUDA版本。conda create -n local_voice python3.10 conda activate local_voicePython版本选3.10是我踩过坑之后的结论。3.8有些新库不支持3.11、3.12又经常遇到某些推理库还没适配3.10是目前兼容性最好的甜点版本。3.2 推理引擎和音频处理库核心依赖其实不多主要是推理引擎加音频读写库pip install onnxruntime-gpu # 有N卡就装gpu版没有就装onnxruntime pip install soundfile librosa pip install numpy scipy这里有个细节onnxruntime-gpu和onnxruntime不能同时装装错了会导致GPU用不上。判断方法很简单跑一行代码看providers里有没有CUDAExecutionProviderimport onnxruntime as ort print(ort.get_available_providers())如果输出里只有CPUExecutionProvider说明GPU版没装对或者CUDA、cuDNN版本不匹配。CUDA版本和onnxruntime版本有对应关系装之前去官方文档查一下对应表别凭感觉装。3.3 音频格式的统一处理语音模型对输入音频的格式很挑剔常见要求是16kHz采样率、单声道、16bit PCM的wav文件。你手头的音频可能是mp3、m4a也可能是48kHz立体声直接喂给模型要么报错要么识别质量暴跌。我一般用ffmpeg做预处理ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a pcm_s16le output.wav这条命令把任意格式转成16kHz单声道16bit的wav。参数解释一下-ar 16000是采样率-ac 1是单声道-c:a pcm_s16le是编码格式。这三项是语音模型最通用的输入规格记住就行。注意不要用采样率转换库随便转有些库的重采样算法质量差会引入高频噪声影响识别率。ffmpeg的soxr重采样质量很稳值得信赖。4. 语音识别模型的本地部署与调优4.1 模型加载与首次推理假设你已经下载好了一个ONNX格式的中文ASR模型加载和推理的代码大概长这样import onnxruntime as ort import numpy as np import soundfile as sf # 加载模型 session ort.InferenceSession(asr_model.onnx, providers[CUDAExecutionProvider]) # 读取音频 audio, sr sf.read(output.wav, dtypefloat32) assert sr 16000 # 推理 inputs {session.get_inputs()[0].name: audio[np.newaxis, :]} outputs session.run(None, inputs)第一次跑的时候建议先用一段五秒左右的短音频测试确认能出结果再上长音频。我见过有人直接拿一小时的录音去跑结果内存爆掉排查半天以为是模型问题其实是没做分片。4.2 长音频分片与拼接策略长音频处理是本地ASR最核心的工程问题。模型通常有最大输入长度限制超了要么报错要么精度下降。我的做法是按静音点切分而不是机械地按固定时长切。因为按固定时长切很容易把一句话从中间切断导致前后两段都识别错。具体做法是用音频能量检测找到静音段在静音段中间下刀。这样切出来的每一片都是完整的语义单元识别准确率明显更高。切分阈值我一般设成-40dB持续200毫秒以上的静音才认为是切点。这个参数可以根据你的音频质量微调噪声大的录音把阈值调高一点避免把噪声误判成静音。拼接的时候要注意每段识别结果之间要加一个空格或者标点否则会出现“今天天气不错明天可能下雨”这种连在一起的情况。如果模型输出自带标点拼接就简单很多如果不带标点可以再接一个轻量的标点恢复模型。4.3 识别结果的常见问题与修正本地ASR跑出来的结果常见问题有三类一是同音字错误比如“在”和“再”、“做”和“作”二是专有名词识别不准人名地名特别容易错三是数字和单位混读比如“2024年”可能识别成“二零二四年”也可能识别成“两千零二十四年”。针对同音字我一般用一个简单的规则表做后处理把高频错误对替换掉。专有名词可以维护一个热词表在解码阶段给这些词加权。数字和单位则建议统一转成阿拉伯数字方便后续处理。这些后处理逻辑不复杂但能显著提升最终文本的可用性。实操心得热词表不要塞太多词超过两百个之后加权效果会互相干扰。我的经验是只放最关键的几十个词效果最好。5. 语音合成模型的本地部署与音色调校5.1 TTS模型的基本推理流程TTS比ASR多了一个环节文本前端处理。中文TTS的文本前端要做分词、多音字消歧、数字转读法、韵律预测这几件事。很多开源TTS模型把前端做得很简单导致“银行”读成“银xing”、“重庆”读成“重qing”这种问题。如果你的模型前端能力弱就需要自己补一个前端处理模块。推理流程大致是文本经过前端处理变成音素序列音素序列经过声学模型变成声学特征声学特征经过声码器变成波形。VITS这类端到端模型把这几步合在一起了用起来简单但可控性差一些。FastSpeech2加HiFiGAN这种分离式方案每一步都能调适合对音质有更高要求的场景。5.2 音色克隆与情感控制的取舍现在很多TTS模型支持音色克隆给几秒参考音频就能模仿那个音色。这个功能很诱人但实际用起来有几个坑。第一是参考音频的质量要求高有背景噪声或者混响克隆出来的音色就会发闷。第二是克隆音色的稳定性问题同一段文本跑两次音色可能有细微差别听起来不自然。第三是情感控制大部分开源模型的情感控制能力有限想要抑扬顿挫的效果往往需要额外训练或者用支持情感标签的模型。我的建议是如果只是做有声书或者通知播报用模型自带的预训练音色就够了稳定省心。如果确实需要特定音色参考音频一定要在安静环境录制时长控制在五到十秒太长反而效果不好。5.3 合成速度与音质的平衡TTS的推理速度主要受声码器影响。HiFiGAN这类声码器音质好但速度慢MelGAN速度快但音质差一些。在本地部署时如果追求实时性可以考虑用轻量声码器加缓存策略。所谓缓存策略就是把常用文本的合成结果缓存起来下次遇到相同文本直接读缓存省去推理时间。这个技巧在做语音助手的时候特别有用像“好的”“收到”这种高频短句缓存命中率很高。6. 完整实操流程从一段录音到一份文字稿6.1 环境准备与模型下载先把前面说的虚拟环境和依赖装好然后下载模型。模型文件建议放在一个固定的目录比如~/models/asr和~/models/tts方便管理。下载的时候注意校验文件完整性有些模型分片下载少一个分片就跑不起来。我一般会核对一下文件大小和官方说明是否一致。6.2 音频预处理与分片拿到录音之后先转格式再分片。分片脚本的核心逻辑是读入音频、计算能量、找静音点、切片、保存。这一步的输出是一堆wav小文件命名按顺序编号方便后续拼接。import librosa import numpy as np import soundfile as sf audio, sr librosa.load(output.wav, sr16000) energy librosa.feature.rms(yaudio, frame_length400, hop_length160)[0] threshold 10 ** (-40 / 20) silent_frames np.where(energy threshold)[0] # 后续根据silent_frames找切点这里省略具体切分逻辑6.3 批量识别与结果拼接分片之后就是批量跑识别把每片的识别结果收集起来按顺序拼接。拼接时注意加标点和空格。如果对准确率要求高可以在拼接后再过一遍语言模型做纠错但这一步会增加不少计算量看需求取舍。6.4 人工校对与后处理机器识别出来的文字稿直接用的比例大概在九成左右剩下一成需要人工过一遍。我的习惯是先把专有名词和数字统一替换再通读一遍改同音字。如果文字稿要发布这一步不能省因为语音识别的错误往往集中在关键信息上比如人名、金额、日期。7. 常见问题排查与避坑经验7.1 模型加载失败的几种原因模型加载失败最常见的原因是文件损坏或格式不匹配。ONNX模型要用onnxruntime加载PyTorch模型要用torch加载搞混了就会报错。另外如果模型是用新版本框架导出的旧版本推理引擎可能不兼容这时候要么升级引擎要么找旧版本模型。7.2 识别结果乱码或空白识别结果全是乱码或者空白通常是音频格式不对。检查采样率是不是16kHz声道是不是单声道位深是不是16bit。还有一个容易被忽略的点有些wav文件头信息不规范soundfile读出来是空的这时候用ffmpeg重新转一遍就好了。7.3 推理速度慢的优化方向推理慢先从硬件利用率查起。用任务管理器或者nvidia-smi看GPU有没有跑满如果GPU利用率很低说明瓶颈在数据预处理或者IO上。优化方向包括把音频预处理改成并行、用更小的模型、开量化、把模型常驻内存避免反复加载。我实测下来模型常驻内存这一项就能省掉每次几秒的加载时间批量处理时效果明显。问题现象可能原因排查方法解决方向加载报错格式不匹配看报错信息里的框架名换对应推理引擎结果乱码音频格式错检查采样率和声道ffmpeg重转速度慢GPU没用上nvidia-smi看利用率装GPU版推理引擎内存爆音频太长看内存占用曲线分片处理音色发闷参考音频差听参考音频质量重录参考音频7.4 中文标点和数字的处理技巧中文语音识别出来的文本标点往往缺失或者错乱。我的做法是接一个轻量的标点恢复模型或者用规则加词典的方式补标点。数字处理方面建议统一转成阿拉伯数字但要注意“一”在有些语境下不是数字比如“一样”“一直”这种要靠上下文判断规则很难覆盖全必要时人工校对。8. 本地语音方案的扩展玩法8.1 实时语音输入法的搭建思路把ASR模型和麦克风采集串起来就能做一个离线语音输入法。核心是流式识别也就是一边说话一边出字。流式识别的难点在于要处理不完整的语音片段模型需要支持增量解码。如果模型不支持流式可以用滑动窗口的方式模拟每隔几百毫秒把当前缓冲区送进去识别一次用后一次的结果覆盖前一次。这个方案实现简单但会有一定的延迟和重复计算。8.2 离线语音助手的组合方案ASR加TTS加一个本地对话模型就是一个完整的离线语音助手。对话模型可以用量化后的小参数模型跑在CPU上也能接受。整个链路的延迟主要来自对话模型的生成速度语音识别和合成相对快。如果追求响应速度可以把对话模型也做量化或者用更小的模型。8.3 批量处理与自动化脚本如果你要处理大量录音写一个自动化脚本会省很多事。脚本的逻辑是扫描指定目录下的音频文件逐个做预处理、识别、后处理最后输出文字稿到对应目录。加上日志记录和断点续传处理几百个文件也不怕中途出错。我一般会用多进程并行处理CPU核多的话速度提升很明显。提示批量处理时注意控制并发数并发太高会导致显存或内存不足反而拖慢整体速度。我的经验是并发数设成GPU数量的两到三倍比较合适。9. 我在这条路上踩过的几个坑第一个坑是盲目追求大模型。刚开始觉得模型越大效果越好下载了一个超大模型结果推理一次要等半分钟完全没法用。后来换成中等模型速度快了十倍准确率只降了一点点实际体验反而更好。模型选型一定要结合自己的硬件和使用场景不是越大越好。第二个坑是忽略音频预处理。有段时间识别结果总是莫名其妙地差排查了很久才发现是音频采样率不对。模型文档里写了要16kHz我没注意直接喂了48kHz的音频模型虽然不报错但识别质量暴跌。这件事之后我养成了习惯任何音频进模型之前先确认格式。第三个坑是没做分片直接跑长音频。一次处理一小时的会议录音内存直接爆掉程序崩溃。后来加了分片逻辑问题解决。分片这件事看起来简单但切点选得好不好对识别准确率影响很大值得花时间调优。第四个坑是TTS音色克隆的参考音频没选好。用了一段带背景音乐的音频做参考合成出来的声音一直有杂音换了干净的参考音频之后立刻正常。音色克隆对参考音频的纯净度要求比想象中高得多。10. 给不同基础读者的上手建议如果你是完全的新手建议从现成的整合包或者一键脚本开始先跑通一个最简单的例子建立信心。不要一上来就自己搭环境、下模型、写代码那样很容易在环境问题上卡住然后放弃。跑通之后再逐步深入理解每个环节在做什么。如果你有一定编程基础建议直接看模型的官方文档和示例代码自己动手搭一遍。遇到问题先看报错信息再去搜相关的issue大部分问题别人都遇到过。自己排查问题的过程比直接抄答案学到的东西多得多。如果你已经在用云端语音服务想迁移到本地建议先做一个对比测试拿同一段音频分别用云端和本地跑一遍对比准确率、速度、成本。心里有数之后再决定迁移哪些场景。本地方案不是万能的有些场景云端确实更方便混合使用才是理性的选择。最后分享一个小技巧本地语音模型的更新迭代很快建议定期关注开源社区的动态新模型出来之后花点时间试试往往会有惊喜。我现在保持的习惯是每个月抽半天时间把新出的中文语音模型跑一遍对比一下效果积累下来对模型能力的判断会越来越准。