先问个问题你手里那张8G显存的显卡是不是自从装完Ollama和ChatGPT套壳聊天界面之后就一直在吃灰我身边大多数人都是这样跑得动ChatGLM或者Qwen的7B模型聊几句就觉得到头了。但AI的玩法远不止对话框。真正让我觉得值回门票的是把它变成能听、能说的本地数字人——你喊它一声它回头问你“怎么了”你说话它回答面前还有一个卡通形象在动嘴。全程数据不出本机显存占用我实测控制在6.5GB以内8G显卡完全扛得住。这个实践方案我这边叫Voice Companion本质上是一套把语音识别、大模型对话、语音合成、虚拟形象串联起来的参考实现。这篇文章会把我从零搭到调优的全过程写出来包括每个模块怎么选型、显存怎么算账、延迟怎么压缩以及那些不踩一遍根本发现不了的坑。1. 先想清楚本地数字人到底是个什么东西1.1 把“能听能说”拆成四件事很多人一听“数字人”就想到剪映那种卡通人物念稿视频、或者是动辄几十万成本的虚拟主播。但咱们在本地搭的不是那种离线渲染的高成本东西。实时数字人拆到底就是一条数据流管道一共四件事听麦克风采集音频识别成文字这一步叫ASR语音识别。想把文字送给大模型得到回答文本这一步是LLM推理。说把回答文本合成为语音播放出来这一步叫TTS语音合成。演在屏幕上渲染一个虚拟形象并让它的嘴型、表情跟着音频走。四条链路对应四个独立模块。8G显卡的本地数字人难点不在任何一个单一模块而在怎么把四个模块高效串在一起并且让它们不抢显存。Voice Companion这个项目的核心价值恰恰就是干这个胶水活——它管理会话上下文、控制音频流、调度唤醒词、串联各模块。你不需要自己从零写一个语音交互框架只需要把各个引擎接进去。1.2 8G显存的真实边界不是所有模型都能住进来这是最关键的一张账。先说结论8G显存最适合的策略是“大模型占GPU小模型和音频占CPU”。以目前性价比最高的方案为例模块推荐方案显存占用运行设备语音识别faster-whisper small0~2GB可全程CPUGPU或CPU大模型Qwen2.5 7B Q4_K_M量化4.5~6.5GBGPU语音合成piper中文模型0CPU虚拟形象Live2D/VRM前端渲染0.3~0.5GB浏览器侧CPU/GPU看出来没有真正吃显存的大头只有一个——大模型本身。只要语音识别选择small或base级别、语音合成选择CPU渲染的引擎8G显存是可以从容运行的。相反如果脑子一热全都放GPUwhisper large跑GPU占2GB多还塞一个CosyVoice的TTS模型再占2GB剩下的空间给7B模型就很紧张了随时会在某个节点触发CUDA out of memory。数字人最忌讳的就是“说着说着崩了”。1.3 Voice Companion在架构里的位置Voice Companion做的事情可以类比成一条流水线的传送带。每个模块都有自己擅长的工作faster-whisper只管把语音转文字大模型只管生成文本piper只管把文本读出来。问题是它们彼此不认识。faster-whisper输出的是纯文本大模型吃的是带system prompt的prompt结构piper需要的是特定语速和音色的音频参数。Voice Companion做的就是中间那层——把状态管理、事件循环、缓冲队列统一起来。它监听麦克风音频流唤醒之后开始录音录音结束切给ASRASR结果拼上人设prompt发给LLMLLM流式输出累积成文本后交给TTSTTS生成音频的同时把“正在说话”状态推给前端虚拟形象。这种架构的好处是每一块都能单独换。今天你想换更大的模型只动一个适配器就行不会牵一发动全身。2. 核心模块选型每一步都是权衡2.1 语音识别为什么不用原版whisper第一版我用的是OpenAI原版whisper结果直接被延迟和CPU占用劝退。在8G显卡、中端CPU的机器上原版whisper small转一段3秒的语音需要1~2秒的处理时间CPU占用还能冲到90%以上。这体验完全没法用。后来换成faster-whisper同一个模型推理速度快了不止一倍。因为它用CTranslate2重写了底层推理引擎支持int8量化在CPU上就能用很小的性能损失跑起来。我的推荐组合是模型档位small在中文识别准确率和速度之间比较平衡。base更快但长句、口音容易错medium准确但体积翻倍、延迟明显。运行设备CPU优先。small在CPU上推理一轮只要几百毫秒不值得让它占GPU显存。开启VAD语音活动检测faster-whisper自带vad_filterTrue能自动剪掉前后静音和空白识别速度和准确率都会有明显改善。关键参数languagezh强制中文beam_size5平衡速度与准确率compute_typeint8在CPU上跑就选这个。这里有个容易被忽略的细节麦克风采样的采样率。大多数麦克风默认是44100Hz或48000Hz而whisper用的是16kHz。我没有在代码里做重采样导致第一版识别出来的中文全是胡言乱语。解决办法很简单用PyAudio打开音频流时直接指定rate16000系统会自动处理。2.2 对话大脑7B量化模型的选择和显存账本地数字人的“智商”完全取决于大模型这一层。在8G显存条件下我试过几代小模型后长期主力是Qwen2.5 7B Instruct的Q4_K_M量化版。选择原因很直接中文能力强。数字人的使用场景是中文对话通用英文模型经常出现“翻译腔”和奇怪的用词。量化后体积可控。Q4_K_M版本的模型文件大概4.7GB跑起来加上KV cache和上下文缓存实际显存占用在5.5~6.5GB之间8G卡余量足够。指令跟随稳定。它对system prompt的执行比较可靠能保持住数字人的人设。显存账要算细一点。同样一个7B模型量化位数不同显存占用差很多量化格式模型文件大小8G显存评估Q8_0约7.6GB勉强能加载但上下文一长就爆Q5_K_M约5.2GB能跑上下文需限制在4096以内Q4_K_M约4.7GB推荐能留出上下文余量Q3_K_M约3.9GB省显存但明显变笨结合8G卡的实际可用约7.5~7.8GB我建议用Q4_K_M并把最大上下文限制在8192 tokens以内。别开满4096以上的超长上下文本地数字人的单轮对话根本用不了那么多反而白白占显存。模型加载走的是Ollama服务好处是它自动处理KV cache、批处理这些细节还能在保持进程不退出时反复调用。在Voice Companion里我把Ollama当成一个本地服务来用对话请求走HTTP接口不需要自己在Python里加载大模型省了一个大坑。2.3 语音合成本地TTS的三条路线声音这关我折腾得最久。看起来谁都会合成但实际体验天差地别。第一条路edge-tts。微软的在线接口音色非常自然免费支持中文多人声。但它本质是联网服务和“本地部署”的初衷冲突而且每次请求都要访问外网接口断网就哑巴。我只把它放在“快速测试音色”的场景用。第二条路piper。完全离线、CPU推理中文模型大概60MB延迟极低在我的机器上合成一句5秒的话耗时在300~500毫秒。缺点是音色机械感强一些不如云端那种自然但作为本地数字人的默认选择它在延迟和离线两个核心指标上完胜。第三条路CosyVoice。阿里开源的TTS自然度非常高甚至能模仿音色模型里有300M和500M两个规格。但它有两个门槛一是需要约2GB显存或较长的CPU推理时间二是环境依赖复杂。如果你执意要最自然的声音建议换12G以上显存的显卡或者接受CPU推理的慢速。我的最终选择是piper做默认、edge-tts做可选音色包。Voice Companion里我留了TTS引擎的抽象层改一个配置就能切换体验上不折腾。2.4 数字人形象从“剪映视频”到“实时形象”很多人受“剪映卡通人物数字人”这类内容影响以为数字人就是一段做好的卡通视频。但其实那是离线内容生成——你录一段话软件生成一个卡通人在说话的视频。而咱们本地数字人是实时交互它必须在你说完后1~2秒内开口回应还要同步嘴型这个节奏下不可能现渲染视频。正解是用Live2D或VRM模型。Live2D是2D的立绘式形象VRM是3D的。它们都是“表情参数骨骼动画”驱动能实时响应输入。在Voice Companion里我用的是浏览器端渲染方案前端是一个HTML页面用live2d-widget加载一个卡通模型。后端通过WebSocket把“开始说话/停止说话”状态推给前端。前端在播放TTS音频的同时播放一个“张嘴闭嘴”的循环动画。这个方案的好处是模型渲染完全不吃显卡显存8G全部留给LLM。而且Live2D模型资源非常多看到喜欢的卡通人物就能直接换。3. 实操落地搭一个会说话的卡通数字人3.1 环境准备依赖、模型和目录结构我用的是Windows 11机器显卡是RTX 4060 8G驱动和CUDA 12.1。如果换Linux流程基本一致Python依赖装法略有区别。先装基础依赖建议用虚拟环境管理pip install faster-whisper pyaudio openwakeword ollama websockets pydub numpyOllama单独装装好后拉取模型ollama pull qwen2.5:7b-instruct-q4_k_mpiper需要单独下载Windows二进制和中文语音模型解压后放在项目目录的models/piper_zh/下。目录结构我给一个参考voice-companion/ ├── main.py ├── engines/ │ ├── asr.py │ ├── llm.py │ ├── tts.py │ └── avatar.py ├── models/ │ ├── piper_zh/ │ ├── wakeword/ │ └── live2d/ └── config.yaml配置文件我放在config.yaml里所有模块参数集中管理。后续想换TTS引擎或把whisper从CPU切到GPU改这一个文件就行。3.2 主循环实现唤醒、识别、生成、播放最核心的代码逻辑是一个状态机大致流程如下import pyaudio import numpy as np import queue from faster_whisper import WhisperModel from openwakeword import Model as WakeWordModel # 初始化 asr WhisperModel(small, devicecpu, compute_typeint8) wake WakeWordModel(wakeword_models[hey_jarvis.onnx]) # 音频参数16kHz单声道80ms分片 FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 CHUNK 1280 # 80ms 16000Hz audio_queue queue.Queue() def audio_callback(in_data, frame_count, time_info, status): audio_queue.put(np.frombuffer(in_data, dtypenp.int16)) return (in_data, pyaudio.paContinue) pa pyaudio.PyAudio() stream pa.open( formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK, stream_callbackaudio_callback ) # 循环体 frames_buffer [] is_listening False while True: audio_chunk audio_queue.get() if not is_listening: # 唤醒检测只喂最后1秒的音频 frames_buffer.append(audio_chunk) frames_buffer frames_buffer[-13:] audio_1s np.concatenate(frames_buffer) pred wake.predict(audio_1s) # 唤醒词得分超过0.5就进入对话模式 if pred[hey_jarvis] 0.5: is_listening True frames_buffer [] print(已唤醒请说话...) else: # 静音超时则结束录音进入处理流程 frames_buffer.append(audio_chunk) # 连续1.2秒RMS低于阈值判定说话结束 rms np.sqrt(np.mean((audio_chunk.astype(np.float32) / 32768.0) ** 2)) if rms 0.01 and len(frames_buffer) 15: user_audio np.concatenate(frames_buffer) # 转文字 segments, _ asr.transcribe(user_audio, languagezh, vad_filterTrue) user_text .join(s.text for s in segments) print(f识别结果: {user_text}) # 交给LLM生成回答 answer generate_ollama(user_text) # TTS合成并播放 tts_play(answer) # 通知前端开始说 avatar.set_talking(True) frames_buffer [] is_listening False这段代码省略了LLM和TTS的具体实现但主循环的骨架就是这样。几个要点唤醒检测只喂“最近1秒”的音频避免录音越长越卡。用静音超时判断说话结束比按键触发自然得多。阈值要调麦克风底噪太大的房间阈值太低会永远不触发。唤醒词模型放CPU用的是openwakeword的预置hey_jarvis你也可以换中文唤醒词比如“你好小智”需要录制几段音频去训练项目README里会有说明。3.3 嘴型同步低成本但自然的效果说完一句话TTS开始播放音频的同时数字人的嘴要动起来。我见过不少人在这块搞得特别复杂用音频特征驱动嘴型参数算RMS、算频带能量其实没必要。Live2D模型大多有内置的mouth_open参数。最简单的方案是播放音频时直接把mouth_open设成一个稳定的张口状态配合呼吸动画效果就非常自然了。我用的方案是因为TTS音频是一段一段的前端播放时知道了总时长就把口型动画的时间线对齐。播放期间嘴巴参数在0.3~0.6之间平滑跳动像说话时的自然摆动停顿时嘴巴回到0.0。这个方案不需要分析音频频谱连前端几行代码都够了const mouthParam { open: () model.setParam(mouthOpen, 0.4), close: () model.setParam(mouthOpen, 0.0) }; // WebSocket收到开始说话 ws.onmessage (e) { const data JSON.parse(e.data); if (data.type talking) mouthParam.open(); else mouthParam.close(); };真正细节是说的内容和表情要有呼应。Voice Companion里我在LLM返回后先做一次简单的关键词判断高兴、无奈、思考把表情状态也打包发给前端数字人会在说话前先做一个对应的表情切换。这个很小的改动能让数字人从“没感情的工具”变成“有反应的人”提升非常明显。3.4 人设注入数字人的性格写在system prompt里数字人要不要懂礼貌、要不要高冷、会不会开你玩笑全看prompt怎么设计。这一步不用复杂提示词工程但有几个关键点角色定位明确身份比如“你是桌面上的一位数字伙伴名字叫小光”。说话风格要求口语化、短句、自然敢用语气词。能力边界告诉模型遇到回答不了的问题就直说不要编造。长度控制明确“回答控制在50字以内”本地数字人场景下15秒以上的长篇大论很影响体验。system: 你是小光一位住在用户电脑里的数字伙伴。 你的风格口语化、简洁、偶尔幽默。 回答中文长度不超过50字。 如果用户问你不懂的技术问题直接说不会不要编造。在Voice Companion里这段system文本会随每次对话请求发给Ollama。我实测下来Qwen2.5 7B对这个prompt的跟随性很稳长时间对话后不太容易“人格漂移”。4. 延迟优化和常见问题排查实录4.1 延迟算一笔账到底慢在哪一个完整的发问到回应延迟由三部分组成ASR识别用户说完后到识别出文字faster-whisper small在CPU上约300~500ms。LLM推理7B Q4_K_M在4060上生成50字回答约600~900ms。TTS合成piper合成5秒中文音频约300~500ms。加起来总延迟在1.2~1.9秒之间实际体验是人说完话后约1秒出头数字人开始开口。这个延迟完全可以接受关键是别让三个模块串行叠加地等。Voice Companion里我做了流水线优化用户说话的同时不用等完整录音结束才开始录音音量的检测ASR的结果到达后先发一个“思考中”的表情给前端让用户知道它听到了。真正的并行优化是TTS合成时LLM已经开始处理下一句上下文了——当然这个在单轮场景下用得不多。如果想进一步压延迟把ASR从CPU切换到GPU是立竿见影的识别时间能从400ms降到150ms左右代价是显存多占1.5~2GB。8G显卡用户可以自行取舍。4.2 踩坑实录几类高频问题的排查方法第一类CUDA out of memory。这是我遇到最多的报错。原因通常是whisper或者TTS占了一部分GPU把7B模型挤爆了。排查思路打开nvidia-smi看进程占用给Ollama设置环境变量限制能看到GPU的显存上限让它提前换KVCache策略最省事的办法是把ASR切成CPU。数字人是交互应用稳定性优先于单次识别速度。第二类唤醒词不灵敏或误触发。openwakeword在安静房间里表现还好一开风扇或放音乐就开始乱喊。调整方向有三个提高唤醒阈值从0.5改到0.6或0.7在唤醒之前加一个能量门控只有总音量足够大才进行判定检查麦克风是不是采集了48kHz但代码里误写成16kHz导致音频变形。第三类数字人声音卡顿、爆音。piper合成的WAV数据飘一次就爆音。原因是TTS返回的采样率与播放设备不一致。我处理的办法是先用pydub统一转成16bit单声道16kHz的WAV再交给播放器。这里不要用系统默认的媒体播放器去播WAV那类播放器初始化延迟太高建议直接用sounddevice或PyAudio播放原始PCM数据。4.3 常见问题速查表现象主要原因快速解法识别结果乱码采样率不匹配统一强制16kHz唤醒后立刻退出打开麦克风失败检查其他程序是否独占麦克风数字人回应慢LLM或ASR串行耗时先切CPU/GPU分工再看流水线TTS声音很机械piper天然机械感换edge-tts测试或换CosyVoice显存溢出其它模块占GPUOllama设GPU显存上限ASR换CPU前端形象不动WebSocket连接失败检查端口和CORS配置长时间运行后变卡音频队列堆积队列设置最大长度丢弃旧数据这些坑我基本都是在第一周逐个踩完的。最惨的一次是调了一整天最后发现只是麦克风的采样率写错了气到想把USB声卡扔了。最后想聊两句我把这套Voice Companion跑通之后桌面上那个Live2D卡通角色就再也没被关掉过。它更像一个“数字室友”你问它天气、让它算个乘法、跟它聊一会天都比打开一个冷冰冰的网页对话框有感觉得多。我个人的建议是第一版不要追求配置完美先按默认参数跑通闭环然后再一个个模块去替换和优化。先能用再谈好用本地AI折腾这个路子比一开始就想着上完美方案要实在得多。如果你想往下一步扩展可以试试把唤醒词换成中文的、把形象从Live2D换成VRM 3D模型、或者让它在回答时自动唤起本地的一些自动化脚本。8G显卡的上限其实挺高的看你怎么用。
先问个问题你手里那张8G显存的显卡是不是自从装完Ollama和ChatGPT套壳聊天界面之后就一直在吃灰我身边大多数人都是这样跑得动ChatGLM或者Qwen的7B模型聊几句就觉得到头了。但AI的玩法远不止对话框。真正让我觉得值回门票的是把它变成能听、能说的本地数字人——你喊它一声它回头问你“怎么了”你说话它回答面前还有一个卡通形象在动嘴。全程数据不出本机显存占用我实测控制在6.5GB以内8G显卡完全扛得住。这个实践方案我这边叫Voice Companion本质上是一套把语音识别、大模型对话、语音合成、虚拟形象串联起来的参考实现。这篇文章会把我从零搭到调优的全过程写出来包括每个模块怎么选型、显存怎么算账、延迟怎么压缩以及那些不踩一遍根本发现不了的坑。1. 先想清楚本地数字人到底是个什么东西1.1 把“能听能说”拆成四件事很多人一听“数字人”就想到剪映那种卡通人物念稿视频、或者是动辄几十万成本的虚拟主播。但咱们在本地搭的不是那种离线渲染的高成本东西。实时数字人拆到底就是一条数据流管道一共四件事听麦克风采集音频识别成文字这一步叫ASR语音识别。想把文字送给大模型得到回答文本这一步是LLM推理。说把回答文本合成为语音播放出来这一步叫TTS语音合成。演在屏幕上渲染一个虚拟形象并让它的嘴型、表情跟着音频走。四条链路对应四个独立模块。8G显卡的本地数字人难点不在任何一个单一模块而在怎么把四个模块高效串在一起并且让它们不抢显存。Voice Companion这个项目的核心价值恰恰就是干这个胶水活——它管理会话上下文、控制音频流、调度唤醒词、串联各模块。你不需要自己从零写一个语音交互框架只需要把各个引擎接进去。1.2 8G显存的真实边界不是所有模型都能住进来这是最关键的一张账。先说结论8G显存最适合的策略是“大模型占GPU小模型和音频占CPU”。以目前性价比最高的方案为例模块推荐方案显存占用运行设备语音识别faster-whisper small0~2GB可全程CPUGPU或CPU大模型Qwen2.5 7B Q4_K_M量化4.5~6.5GBGPU语音合成piper中文模型0CPU虚拟形象Live2D/VRM前端渲染0.3~0.5GB浏览器侧CPU/GPU看出来没有真正吃显存的大头只有一个——大模型本身。只要语音识别选择small或base级别、语音合成选择CPU渲染的引擎8G显存是可以从容运行的。相反如果脑子一热全都放GPUwhisper large跑GPU占2GB多还塞一个CosyVoice的TTS模型再占2GB剩下的空间给7B模型就很紧张了随时会在某个节点触发CUDA out of memory。数字人最忌讳的就是“说着说着崩了”。1.3 Voice Companion在架构里的位置Voice Companion做的事情可以类比成一条流水线的传送带。每个模块都有自己擅长的工作faster-whisper只管把语音转文字大模型只管生成文本piper只管把文本读出来。问题是它们彼此不认识。faster-whisper输出的是纯文本大模型吃的是带system prompt的prompt结构piper需要的是特定语速和音色的音频参数。Voice Companion做的就是中间那层——把状态管理、事件循环、缓冲队列统一起来。它监听麦克风音频流唤醒之后开始录音录音结束切给ASRASR结果拼上人设prompt发给LLMLLM流式输出累积成文本后交给TTSTTS生成音频的同时把“正在说话”状态推给前端虚拟形象。这种架构的好处是每一块都能单独换。今天你想换更大的模型只动一个适配器就行不会牵一发动全身。2. 核心模块选型每一步都是权衡2.1 语音识别为什么不用原版whisper第一版我用的是OpenAI原版whisper结果直接被延迟和CPU占用劝退。在8G显卡、中端CPU的机器上原版whisper small转一段3秒的语音需要1~2秒的处理时间CPU占用还能冲到90%以上。这体验完全没法用。后来换成faster-whisper同一个模型推理速度快了不止一倍。因为它用CTranslate2重写了底层推理引擎支持int8量化在CPU上就能用很小的性能损失跑起来。我的推荐组合是模型档位small在中文识别准确率和速度之间比较平衡。base更快但长句、口音容易错medium准确但体积翻倍、延迟明显。运行设备CPU优先。small在CPU上推理一轮只要几百毫秒不值得让它占GPU显存。开启VAD语音活动检测faster-whisper自带vad_filterTrue能自动剪掉前后静音和空白识别速度和准确率都会有明显改善。关键参数languagezh强制中文beam_size5平衡速度与准确率compute_typeint8在CPU上跑就选这个。这里有个容易被忽略的细节麦克风采样的采样率。大多数麦克风默认是44100Hz或48000Hz而whisper用的是16kHz。我没有在代码里做重采样导致第一版识别出来的中文全是胡言乱语。解决办法很简单用PyAudio打开音频流时直接指定rate16000系统会自动处理。2.2 对话大脑7B量化模型的选择和显存账本地数字人的“智商”完全取决于大模型这一层。在8G显存条件下我试过几代小模型后长期主力是Qwen2.5 7B Instruct的Q4_K_M量化版。选择原因很直接中文能力强。数字人的使用场景是中文对话通用英文模型经常出现“翻译腔”和奇怪的用词。量化后体积可控。Q4_K_M版本的模型文件大概4.7GB跑起来加上KV cache和上下文缓存实际显存占用在5.5~6.5GB之间8G卡余量足够。指令跟随稳定。它对system prompt的执行比较可靠能保持住数字人的人设。显存账要算细一点。同样一个7B模型量化位数不同显存占用差很多量化格式模型文件大小8G显存评估Q8_0约7.6GB勉强能加载但上下文一长就爆Q5_K_M约5.2GB能跑上下文需限制在4096以内Q4_K_M约4.7GB推荐能留出上下文余量Q3_K_M约3.9GB省显存但明显变笨结合8G卡的实际可用约7.5~7.8GB我建议用Q4_K_M并把最大上下文限制在8192 tokens以内。别开满4096以上的超长上下文本地数字人的单轮对话根本用不了那么多反而白白占显存。模型加载走的是Ollama服务好处是它自动处理KV cache、批处理这些细节还能在保持进程不退出时反复调用。在Voice Companion里我把Ollama当成一个本地服务来用对话请求走HTTP接口不需要自己在Python里加载大模型省了一个大坑。2.3 语音合成本地TTS的三条路线声音这关我折腾得最久。看起来谁都会合成但实际体验天差地别。第一条路edge-tts。微软的在线接口音色非常自然免费支持中文多人声。但它本质是联网服务和“本地部署”的初衷冲突而且每次请求都要访问外网接口断网就哑巴。我只把它放在“快速测试音色”的场景用。第二条路piper。完全离线、CPU推理中文模型大概60MB延迟极低在我的机器上合成一句5秒的话耗时在300~500毫秒。缺点是音色机械感强一些不如云端那种自然但作为本地数字人的默认选择它在延迟和离线两个核心指标上完胜。第三条路CosyVoice。阿里开源的TTS自然度非常高甚至能模仿音色模型里有300M和500M两个规格。但它有两个门槛一是需要约2GB显存或较长的CPU推理时间二是环境依赖复杂。如果你执意要最自然的声音建议换12G以上显存的显卡或者接受CPU推理的慢速。我的最终选择是piper做默认、edge-tts做可选音色包。Voice Companion里我留了TTS引擎的抽象层改一个配置就能切换体验上不折腾。2.4 数字人形象从“剪映视频”到“实时形象”很多人受“剪映卡通人物数字人”这类内容影响以为数字人就是一段做好的卡通视频。但其实那是离线内容生成——你录一段话软件生成一个卡通人在说话的视频。而咱们本地数字人是实时交互它必须在你说完后1~2秒内开口回应还要同步嘴型这个节奏下不可能现渲染视频。正解是用Live2D或VRM模型。Live2D是2D的立绘式形象VRM是3D的。它们都是“表情参数骨骼动画”驱动能实时响应输入。在Voice Companion里我用的是浏览器端渲染方案前端是一个HTML页面用live2d-widget加载一个卡通模型。后端通过WebSocket把“开始说话/停止说话”状态推给前端。前端在播放TTS音频的同时播放一个“张嘴闭嘴”的循环动画。这个方案的好处是模型渲染完全不吃显卡显存8G全部留给LLM。而且Live2D模型资源非常多看到喜欢的卡通人物就能直接换。3. 实操落地搭一个会说话的卡通数字人3.1 环境准备依赖、模型和目录结构我用的是Windows 11机器显卡是RTX 4060 8G驱动和CUDA 12.1。如果换Linux流程基本一致Python依赖装法略有区别。先装基础依赖建议用虚拟环境管理pip install faster-whisper pyaudio openwakeword ollama websockets pydub numpyOllama单独装装好后拉取模型ollama pull qwen2.5:7b-instruct-q4_k_mpiper需要单独下载Windows二进制和中文语音模型解压后放在项目目录的models/piper_zh/下。目录结构我给一个参考voice-companion/ ├── main.py ├── engines/ │ ├── asr.py │ ├── llm.py │ ├── tts.py │ └── avatar.py ├── models/ │ ├── piper_zh/ │ ├── wakeword/ │ └── live2d/ └── config.yaml配置文件我放在config.yaml里所有模块参数集中管理。后续想换TTS引擎或把whisper从CPU切到GPU改这一个文件就行。3.2 主循环实现唤醒、识别、生成、播放最核心的代码逻辑是一个状态机大致流程如下import pyaudio import numpy as np import queue from faster_whisper import WhisperModel from openwakeword import Model as WakeWordModel # 初始化 asr WhisperModel(small, devicecpu, compute_typeint8) wake WakeWordModel(wakeword_models[hey_jarvis.onnx]) # 音频参数16kHz单声道80ms分片 FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 CHUNK 1280 # 80ms 16000Hz audio_queue queue.Queue() def audio_callback(in_data, frame_count, time_info, status): audio_queue.put(np.frombuffer(in_data, dtypenp.int16)) return (in_data, pyaudio.paContinue) pa pyaudio.PyAudio() stream pa.open( formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK, stream_callbackaudio_callback ) # 循环体 frames_buffer [] is_listening False while True: audio_chunk audio_queue.get() if not is_listening: # 唤醒检测只喂最后1秒的音频 frames_buffer.append(audio_chunk) frames_buffer frames_buffer[-13:] audio_1s np.concatenate(frames_buffer) pred wake.predict(audio_1s) # 唤醒词得分超过0.5就进入对话模式 if pred[hey_jarvis] 0.5: is_listening True frames_buffer [] print(已唤醒请说话...) else: # 静音超时则结束录音进入处理流程 frames_buffer.append(audio_chunk) # 连续1.2秒RMS低于阈值判定说话结束 rms np.sqrt(np.mean((audio_chunk.astype(np.float32) / 32768.0) ** 2)) if rms 0.01 and len(frames_buffer) 15: user_audio np.concatenate(frames_buffer) # 转文字 segments, _ asr.transcribe(user_audio, languagezh, vad_filterTrue) user_text .join(s.text for s in segments) print(f识别结果: {user_text}) # 交给LLM生成回答 answer generate_ollama(user_text) # TTS合成并播放 tts_play(answer) # 通知前端开始说 avatar.set_talking(True) frames_buffer [] is_listening False这段代码省略了LLM和TTS的具体实现但主循环的骨架就是这样。几个要点唤醒检测只喂“最近1秒”的音频避免录音越长越卡。用静音超时判断说话结束比按键触发自然得多。阈值要调麦克风底噪太大的房间阈值太低会永远不触发。唤醒词模型放CPU用的是openwakeword的预置hey_jarvis你也可以换中文唤醒词比如“你好小智”需要录制几段音频去训练项目README里会有说明。3.3 嘴型同步低成本但自然的效果说完一句话TTS开始播放音频的同时数字人的嘴要动起来。我见过不少人在这块搞得特别复杂用音频特征驱动嘴型参数算RMS、算频带能量其实没必要。Live2D模型大多有内置的mouth_open参数。最简单的方案是播放音频时直接把mouth_open设成一个稳定的张口状态配合呼吸动画效果就非常自然了。我用的方案是因为TTS音频是一段一段的前端播放时知道了总时长就把口型动画的时间线对齐。播放期间嘴巴参数在0.3~0.6之间平滑跳动像说话时的自然摆动停顿时嘴巴回到0.0。这个方案不需要分析音频频谱连前端几行代码都够了const mouthParam { open: () model.setParam(mouthOpen, 0.4), close: () model.setParam(mouthOpen, 0.0) }; // WebSocket收到开始说话 ws.onmessage (e) { const data JSON.parse(e.data); if (data.type talking) mouthParam.open(); else mouthParam.close(); };真正细节是说的内容和表情要有呼应。Voice Companion里我在LLM返回后先做一次简单的关键词判断高兴、无奈、思考把表情状态也打包发给前端数字人会在说话前先做一个对应的表情切换。这个很小的改动能让数字人从“没感情的工具”变成“有反应的人”提升非常明显。3.4 人设注入数字人的性格写在system prompt里数字人要不要懂礼貌、要不要高冷、会不会开你玩笑全看prompt怎么设计。这一步不用复杂提示词工程但有几个关键点角色定位明确身份比如“你是桌面上的一位数字伙伴名字叫小光”。说话风格要求口语化、短句、自然敢用语气词。能力边界告诉模型遇到回答不了的问题就直说不要编造。长度控制明确“回答控制在50字以内”本地数字人场景下15秒以上的长篇大论很影响体验。system: 你是小光一位住在用户电脑里的数字伙伴。 你的风格口语化、简洁、偶尔幽默。 回答中文长度不超过50字。 如果用户问你不懂的技术问题直接说不会不要编造。在Voice Companion里这段system文本会随每次对话请求发给Ollama。我实测下来Qwen2.5 7B对这个prompt的跟随性很稳长时间对话后不太容易“人格漂移”。4. 延迟优化和常见问题排查实录4.1 延迟算一笔账到底慢在哪一个完整的发问到回应延迟由三部分组成ASR识别用户说完后到识别出文字faster-whisper small在CPU上约300~500ms。LLM推理7B Q4_K_M在4060上生成50字回答约600~900ms。TTS合成piper合成5秒中文音频约300~500ms。加起来总延迟在1.2~1.9秒之间实际体验是人说完话后约1秒出头数字人开始开口。这个延迟完全可以接受关键是别让三个模块串行叠加地等。Voice Companion里我做了流水线优化用户说话的同时不用等完整录音结束才开始录音音量的检测ASR的结果到达后先发一个“思考中”的表情给前端让用户知道它听到了。真正的并行优化是TTS合成时LLM已经开始处理下一句上下文了——当然这个在单轮场景下用得不多。如果想进一步压延迟把ASR从CPU切换到GPU是立竿见影的识别时间能从400ms降到150ms左右代价是显存多占1.5~2GB。8G显卡用户可以自行取舍。4.2 踩坑实录几类高频问题的排查方法第一类CUDA out of memory。这是我遇到最多的报错。原因通常是whisper或者TTS占了一部分GPU把7B模型挤爆了。排查思路打开nvidia-smi看进程占用给Ollama设置环境变量限制能看到GPU的显存上限让它提前换KVCache策略最省事的办法是把ASR切成CPU。数字人是交互应用稳定性优先于单次识别速度。第二类唤醒词不灵敏或误触发。openwakeword在安静房间里表现还好一开风扇或放音乐就开始乱喊。调整方向有三个提高唤醒阈值从0.5改到0.6或0.7在唤醒之前加一个能量门控只有总音量足够大才进行判定检查麦克风是不是采集了48kHz但代码里误写成16kHz导致音频变形。第三类数字人声音卡顿、爆音。piper合成的WAV数据飘一次就爆音。原因是TTS返回的采样率与播放设备不一致。我处理的办法是先用pydub统一转成16bit单声道16kHz的WAV再交给播放器。这里不要用系统默认的媒体播放器去播WAV那类播放器初始化延迟太高建议直接用sounddevice或PyAudio播放原始PCM数据。4.3 常见问题速查表现象主要原因快速解法识别结果乱码采样率不匹配统一强制16kHz唤醒后立刻退出打开麦克风失败检查其他程序是否独占麦克风数字人回应慢LLM或ASR串行耗时先切CPU/GPU分工再看流水线TTS声音很机械piper天然机械感换edge-tts测试或换CosyVoice显存溢出其它模块占GPUOllama设GPU显存上限ASR换CPU前端形象不动WebSocket连接失败检查端口和CORS配置长时间运行后变卡音频队列堆积队列设置最大长度丢弃旧数据这些坑我基本都是在第一周逐个踩完的。最惨的一次是调了一整天最后发现只是麦克风的采样率写错了气到想把USB声卡扔了。最后想聊两句我把这套Voice Companion跑通之后桌面上那个Live2D卡通角色就再也没被关掉过。它更像一个“数字室友”你问它天气、让它算个乘法、跟它聊一会天都比打开一个冷冰冰的网页对话框有感觉得多。我个人的建议是第一版不要追求配置完美先按默认参数跑通闭环然后再一个个模块去替换和优化。先能用再谈好用本地AI折腾这个路子比一开始就想着上完美方案要实在得多。如果你想往下一步扩展可以试试把唤醒词换成中文的、把形象从Live2D换成VRM 3D模型、或者让它在回答时自动唤起本地的一些自动化脚本。8G显卡的上限其实挺高的看你怎么用。
