8G显存在AI本地化圈子里处境挺尴尬的：你说它能跑模型吧，7B量化之后勉强能聊；你说它跑不好吧，又确实比集显强太多。大多数教程讲的都是怎么用Ollama跑一个聊天模型，但很少有人说可以更进一步——把它变成一只能听懂人话、还会开口回话的本地AI数字人。我用Voice Companion在一块8G显存的卡上把这事做成了。简单说，就是麦克风收音，语音识别转文字，大模型思考生成回复，语音合成再开口说话，整条链路人跑的本地。

这个说法听起来简单，但中间全是细节：显存怎么分配、模型怎么选、工具怎么串。这篇就把我这段时间的搭建过程、踩坑记录和调优经验完整写一遍，给想在8G显存上做语音数字人的朋友一个真实可以参考的路线。

1. 8G显存的账先算清楚：ASR、LLM、TTS各占多少显存

动手之前，我先把数字人涉及的三个AI模块拆开看了一遍。一个能听会说的数字人，背后至少要有三套模型在轮流干活：语音识别（ASR）负责把麦克风里的声音变成文字，大语言模型（LLM）负责理解并生成回复，语音合成（TTS）负责把回复文字变成可播放的语音。很多人的第一反应是：这三个加起来怎么也得10G以上显存吧，8G卡直接劝退。但真算下来并不是这么回事。

以我当时测试的配置为例，识别部分用的faster-whisper small模型，int8量化后占用大概0.5G到0.8G显存；大模型用Qwen2.5 7B的Q4_K_M量化版本，模型权重4.1G左右，再加上上下文KV cache，跑4096上下文大概再多占0.5G到1G；语音合成用ChatTTS，FP16权重占用1.5G上下，如果换更轻量的VITS类模型，0.5G到1G就能拿下。理论上这三个模块同时常驻显存，加起来大概6G出头，8G卡看起来是能塞下的。

但事情没那么简单。ASR、LLM、TTS三者在推理时并不总是同时工作。用户在说话的时候，LLM和TTS基本是空闲的；LLM在生成的时候，ASR已经结束，TTS还没开始；真正重叠的场景只有一个——上一次回复还在播放的时候，用户已经开口说下一句了。这种时候ASR模型需要能够立刻被唤醒，如果不能做到ASR常驻，就会出现"听不见人说话"或者"断句延迟半秒"的糟糕体验。

再一个问题是显存碎片和缓存开销。模型权重不是全部，推理时的激活值、beam search的缓存、CUDA context本身就占几百兆。你按纯权重去算账，数字好看，但一跑起来就发现还剩不到200M的空余，一个长句子进来直接OOM。所以我的方案是：ASR用一个很小的模型常驻，LLM用量化后的7B常驻，TTS不常驻GPU，需要合成时再加载，合成完立即释放。TTS单个句子推理时间也就一两秒，加载一个1.5G的模型在这个速度量级上，完全可以通过模型缓存策略做到无明显卡顿。

提示：不要拿"模型权重总和"去判断显存够不够，一定要给CUDA context、KV cache、激活值留出余量，8G卡实际可用大概按6.5G到7G去规划比较稳。

这版配置跑了一段时间后，我发现核心瓶颈其实不在显存容量，而在"三个模型谁先谁后"的调度。这就引出了工具选型的问题。

2. 为啥选Voice Companion：它把语音识别、大模型、语音合成串成了一条流水线

如果你自己从零搭一个语音数字人，要写的东西远比想象中多：麦克风音频采集和采样率处理、端点检测（VAD）、识别结果的断句与清洗、流式播放和音频缓冲、打断逻辑，更别说维护多轮对话的记忆状态。这些东西每一项都不难，但合在一起就很琐碎。Voice Companion的价值在于，它把ASR、LLM、TTS三段串成了一条可配置的流水线，把"从麦克风到扬声器"这件事做成了开箱即用的服务，我只管组装模型，不必从头写状态机。

我动手前其实对比过几条路线。一条是自己写个Python脚本把faster-whisper、ollama、edge-tts串起来。优点是可以完全自定义，缺点是语音识别完成后文本如何进入聊天上下文、TTS合成会不会阻塞主循环、音频播放用阻塞模式还是缓冲模式，这些都要自己做。实际改起来最麻烦的是"用户说半句话停顿了一下"这种场景，VAD没写好，整个对话就乱套了。

另一条是用现成的智能家居语音管道。这条路线依赖家里的智能家居体系，而且默认云端方案居多，不适合我这种想在纯本地跑数字人的场景。

Voice Companion正好卡在中间：它支持本地ASR（faster-whisper）、本地LLM（Ollama/llama.cpp）、本地TTS（ChatTTS等），三端本地，显存可控，又不用我花两三个周末去写那些底层的音频逻辑。

它的核心调度逻辑其实不难理解。一句话说清楚：VAD检测到用户开口，采集音频，ASR转文字，拼接最近的对话历史送给LLM，LLM生成回复，回复文本按标点断句，每句交给TTS合成并排队播放。如果用户在新回复播放时再次开口，打断当前播放，重新进入采集状态。这套逻辑听起来简单，但实现得够不够稳，直接决定日常使用中是"顺畅聊天"还是"经常卡壳"。

Voice Companion还有一个我觉得挺聪明的设计：模型实例可以配置为常驻或按需加载。AI数字人平时不聊天的时候，TTS模型没必要占着显存，可以配置成"合成了就执行、空闲就释放"；想要低延迟的话，也可以把所有模型都设成常驻。显存怎么分配，完全交给使用者根据自己显卡来权衡，而不是一刀切地"全加载"或"全释放"。

3. 本地数字人搭建全流程：从麦克风到扬声器的完整链路

接下来是实操部分。我的环境是一张8G显存的显卡、32G内存、Ubuntu系统，麦克风和扬声器都是普通USB外设。整个过程分成环境准备、安装、配置、启动联调四步，每步我会把容易出问题的地方单独圈出来。

3.1 环境准备：别忽略ffmpeg和音频权限

先装基础依赖。Python版本建议3.10以上，CUDA用11.8或12.x都可以，看用的pytorch版本匹配。需要装的东西就三样：ffmpeg、conda或venv、以及对应的GPU版pytorch。

ffmpeg是最容易被忽略的那个。faster-whisper虽然可以直接处理音频流，但如果麦克风采到的音频格式不对，或者你想录一段测试音频验证识别效果，没有ffmpeg会寸步难行。Ubuntu下一条命令装好：

sudo apt install ffmpeg

接下来创建虚拟环境装pytorch。CUDA版本和pytorch版本必须对齐，不然后面模型推理的时候会报CUDA driver版本不兼容。装好后用一个简单的命令验证GPU可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

提示：如果打印结果是False，不要先怀疑显卡坏了，大概率是pytorch装成了CPU版本，或者CUDA环境变量没配置好。

还有一个音频层面的坑：如果是Linux桌面系统，麦克风的权限和默认输入设备经常不是一回事。打开系统设置，先确认默认输入设备确实是你要用的麦克风，再确认音量没被静音。很多"数字人不理我"的问题，其实只是麦克风没被应用正确读取。

3.2 安装Voice Companion并跑通默认配置

从项目仓库克隆源码后，进目录用pip安装依赖。安装方式就是标准的git clone加pip install -r requirements.txt，不需要额外编译什么。装完先不要急着改配置，把默认配置里的ASR、LLM、TTS都指到一个最小可用的模型，先跑通一次"我说一句它回一句"的完整链路。这一步的意义是验证环境没有问题，排除"音频采集坏了"还是"模型加载坏了"这种初级问题。我第一次跑的时候就是跳过默认测试直接上大模型，结果半天分不清是TTS卡了还是LLM没启起来。

3.3 配置文件逐项解析

Voice Companion的配置是一个YAML文件，我最终用的配置如下，加了注释说明每一项的作用：

asr: engine: faster-whisper model: small # 可选 base/small/medium language: zh # 识别语言，中文环境务必指定 device: cuda # 识别速度更快，但也占显存 vad: true # 开启人声检测，过滤静音 llm: engine: ollama model: qwen2.5:7b-q4_K_M context_length: 4096 # 上下文长度，8G显存不要开太大 temperature: 0.7 num_predict: 512 tts: engine: chattts device: cuda speaker: default max_sentence_length: 80 # 超过该长度自动断句 wake_word: enabled: false # 开启后会监听唤醒词，占用额外资源

有几个配置项值得多说两句。language: zh这一项必须明确指定。如果你不指定，faster-whisper在检测到环境噪音或者口音时会在语言间跳来跳去，中文里偶尔蹦出英文识别结果，对话体验非常割裂。context_length不要贪大。8G显存跑7B模型，上下文开得越长，KV cache占用越多，4096已经是一个足够日常聊天的长度，没必要上8192。

TTS的max_sentence_length也很关键。ChatTTS一次合成长文本容易声调飘、语气不稳定，把它限制到80个字符以内，按标点或长度断成短句再合成，音频的自然度会明显提升。这个参数我一开始设成200，合成的语音后半段经常读崩，后来改成80就稳了。

3.4 启动服务并完成一次语音对话

配置完成后启动服务：

python app.py --config config.yaml

启动过程会依次加载ASR模型和LLM模型。第一次启动需要下载模型权重，faster-whisper的small模型大概500M，Qwen2.5 7B量化版本大概4G多，都要从模型仓库拉，时间取决于网络。等日志出现监听提示后，对着麦克风说一句"你好"，正常一两秒内会听到合成语音回复。

如果卡住，按我的排查顺序来：先看控制台有没有ASR识别日志。如果"你好"被识别成了别的文字，先修ASR；如果ASR正确但LLM没回，去Ollama那边单独验证服务是否正常；如果LLM有输出但没声音，把TTS单独跑一段文本看能否合成MP3。从输入端到输出端逐段隔离定位，比瞎改配置高效得多。

4. 显存优化与延迟控制：这些坑帮我省了至少一周

8G显存的数字人，难点不在"能跑通"，而在"跑得稳、延迟能接受"。我第一次跑通时，端到端延迟在5秒以上，每句话中间都像在等服务器响应，根本不像在跟数字人聊天。后来围绕显存和延迟做了四轮优化，思路可以分享出来。

4.1 爆显存的完整排查链路

第一次用medium版ASR加8K上下文的7B模型，再常驻TTS，还没说完第一句话就崩了，报错信息是CUDA out of memory。当时我一度以为是模型权重占用太大，后来用nvidia-smi盯进程看，发现OOM发生在LLM推理长句子的瞬间，而不是模型加载阶段。原因在于KV cache会随输入长度动态增长，长对话时即便模型权重只有4.1G，KV cache和激活值瞬间能吃掉2G多，三个模块同时常驻就成了压垮显存的最后一根稻草。

解决思路是给模型排优先级。ASR必须常驻，因为用户随时可能开口；LLM也尽量常驻，因为回复质量主要靠它，而且它启动加载时间最长；TTS改成延迟加载——平时不占显存，需要合成时再加载。这样一来，稳态显存占用控制在6G以内，余量留给KV cache波动。

4.2 量化等级与上下文长度的权衡

LLM的量化等级我做过一组对比测试。Q8量化的7B权重约7.2G，推理质量最好，但8G卡上基本没有余量给KV cache，长对话必爆；Q4_K_M权重4.1G，质量有明显但不夸张的下降，胜在余量充足；Q5_K_M权重约5G，质量和显存占用平衡得比较好。

我的最终选择是Q4_K_M，不是因为它质量最好，而是因为它把显存余量留给了上下文记忆。数字人多轮对话靠的是上下文长度，上下文一短，前面聊过的内容就记不住，体验反而比量化损失更糟糕。Ollama的GPU层数参数也值得调。默认全层上GPU，如果显存压力大，可以留几层给CPU跑。实测把最后几层扔到CPU，能省出400M左右显存，速度损失在多轮短句场景下几乎感知不到，但长回复生成时会明显变慢。这个参数适合在"就差临门一脚"的临界场景里用。

4.3 流式合成与打断机制：延迟从5秒降到2秒

TTS合成是延迟大户。如果等LLM把整个回复全部生成完，再一次性交给TTS合成，长回复的等待时间会非常难受。我在Voice Companion里配置的是流式模式，LLM每生成一个短句就立刻交给TTS，音频边合成边排队边播放。用户听到的不是"整段沉默然后突然说话"，而是"思考半秒后逐句开口"，体感差距非常明显。

打断机制同样关键。数字人正在播放回复时，用户直接说下一句话，系统要能立即停止播放、保存当前对话上下文、重新进入ASR监听。没有打断机制的语音助手，会让用户觉得"它只顾自己说话，根本不听我"。Voice Companion在播放过程中ASR一直保持活动状态，VAD一旦检测到人声就中断播放并启动新一轮识别。日常使用下来，这是提升交互自然度最重要的一环。

4.4 值得单独说的一个坑：Wake Word别乱开

很多数字人项目都支持唤醒词功能，比如喊"小助手"才激活。这个功能看起来方便，但我强烈建议在8G显存上先关掉。唤醒词模型本身是一个一直在监听音频流的模型，即使不做复杂推理，也会常驻一部分显存和CPU资源，而且麦克风一直开着，环境里的电视声、键盘声都可能误触发。我测试时开了一下午，误触发七八次，索性关了。现在的使用方式是无唤醒词模式，靠近麦克风直接说话，系统VAD检测到人声后自动开始识别，体验反而更干净。

5. 实测记录：对话质量、音色调校与日常使用建议

5.1 端到端延迟实测

调优后我做了几十轮对话的实测记录。短句问答的端到端延迟（从说出最后一个字到听到回复第一个字）大概在1.5到2.5秒之间，其中ASR识别约0.3秒，LLM生成首token约0.8秒，TTS首句合成和播放约0.6秒。长句回复会稍微慢一点，但有了流式合成回放，用户其实在第一个短句出来后就会开始听，后半段的延迟被很好地掩盖了。这个量级我可以接受，跟真人对话还是有差距，但已经达到了"能正常交流"的及格线。

5.2 中文识别的小技巧

中文场景下，ASR的准确率直接影响对话质量。实测下来，faster-whisper的small模型在安静环境、普通话口音较轻时准确率可以接受，但遇到专有名词或者略带口音的句子，识别错误率会明显上升。后来我在配置里加了一组自定义热词，把常见的人名、产品名、日常短语加进去，识别错误率降低了不少。

另外一个容易被忽略的点是标点符号。ASR识别文本如果不带标点，LLM读起来会觉得喘不过气，回复的断句也会变得奇怪。faster-whisper默认输出自带标点，我建议保留，并且让LLM在生成回复时尽量使用完整标点。这在语音会话里是个很小的细节，但对听感的影响非常直接。

5.3 音色选择与稳定性的实测

ChatTTS的音色调节我用的是预设的说话人和少量参数。整体听感比传统TTS自然很多，尤其在语气词的表达上有明显优势。但它的一个缺点是音色稳定性：同一段文本在多次合成时，情绪和重音会有差异，偶尔会冒出一句语气奇怪的。我的处理方式是让max_sentence_length保持较小值，短句合成能降低不稳定出现的概率，同时关闭随机采样，让每次合成输出更可控。

5.4 数字人的"人格"怎么调

模型选完只是第一步，数字人的说话风格还需要在LLM层面调。我用的Qwen2.5本身中文能力强，配合system prompt设定人格，效果就有很大差别。一个简单的设定是："你是一个温和、幽默的桌面数字人，说话简短口语化，不要用书面语长篇大论。"实测下来，设定口语化之后，回复的对话感明显更自然。

另一个技巧是把"打断"行为在prompt里也设定清楚。比如告诉模型"用户可能随时打断你，所以你要尽快在完整的句子处停顿"。这会让LLM生成的回复结构更倾向于短句，变相改善TTS的断句质量和听感。

5.5 日常使用中它适合放在什么场景

调试稳定后，我把这个数字人放在了桌面上，日常用得最多的场景有三个。一是快速信息查询，问天气、算数、查单位换算，不用打开浏览器；二是写代码时当语音备忘录，提出一个设计问题然后让它碎碎念着梳理思路，不用切走IDE窗口；三是纯粹为了有个人陪着说说话，这也是数字人跟聊天窗口最不一样的地方——声音会带来某种陪伴感，这是文字对话给不了的。

5.6 边界与不足，我还是要说实话

必须坦白说，这个方案有它的边界。第一，ASR和TTS虽然本地化了，但效果上限肯定不如云端成熟商业产品，噪声环境下的识别准确率、复杂情感的语音合成，都还有差距。第二，8G显存决定了LLM只能用7B级别模型，推理能力和更大参数的模型不在一个档次，复杂逻辑推理、长文问答都会露怯。第三，如果麦克风降噪不好，环境音一吵，整体体验会崩得很快——因为ASR这环错一个词，后面整个回复就跑偏了。

我现在的使用习惯是：把它定位成"一个能陪我聊天的桌面助手"，而不是"替代商业语音助手"的存在。在这个预期管理下，它很合格，而且每一个环节的数据都留在自己手里，这是云方案给不了的踏实感。最后再分享一个小建议：如果你也准备在8G显存上折腾，务必给自己留出至少一个完整的下午来调VAD和打断参数，这两个细节决定了数字人是"能用"还是"好用"，是整条流水线里最值得打磨的地方。