8G显存也能跑本地AI数字人：Voice Companion完整搭建指南-北京尧图网络

以前别人问我8G显存能不能跑本地AI数字人我的答案基本就一个字难。随便一个7B大模型动辄占用五六GB显存再加上语音识别、语音合成、数字人渲染显存直接不够看。但最近我把Voice Companion这套链路完整跑通了8G显存不仅能跑而且效果相当可用。这篇文章我把完整的搭建思路、技术选型、实操步骤和踩坑记录都整理出来想折腾本地AI语音助手或者数字人的朋友可以直接照着抄作业。我是把整个流程拆成四块来做的本地大模型推理LLM、本地语音识别ASR、本地语音合成TTS以及最上层的语音交互主控逻辑。数字人形象属于可选模块我后面也会单独聊聊怎么把它加进去。整个方案以Ollama作为模型推理后端Python写编排逻辑全程不需要奇奇怪怪的云服务隐私数据不出本机适合对数据敏感或者单纯想折腾的玩家。1. 为什么是8G显存聊聊Voice Companion的定位和价值1.1 8G显存曾经的数字人“禁区”先别急着看方案我觉得有必要先搞清楚一个问题为什么偏偏是8G显存这么有讨论度你看看市面上主流笔记本和台式机的显卡配置尤其是中端价位的显存基本都是6G、8G、12G这几个档位。8G正好卡在一个尴尬的位置——比上不足比下有余。跑大模型的时候显存决定了一件事你最多能把多大的模型塞进去。12G显存基本可以畅玩14B量级的量化模型8G显存则刚好卡在7B~9B量化模型的临界线上稍微贪心一点想上14B就得精打细算每一个字节。以前大家默认搞数字人、搞AI语音交互怎么着也得上个24G显存的卡不然连模型都加载不进去。但实际需求层面8G显存的用户群体非常庞大所以围绕这档显存做优化比你去推荐别人买显卡更有现实意义。另一个维度是数字人“开口说话”不是一个模型的事它是一条链路先把用户的话转成文字ASR再把文字喂给大模型去理解思考LLM最后把回答转成语音播出来TTS。链路里每一环都要占资源所以真正的难点不在于单个模型能不能跑而在于三个模型叠加之后怎么在8G这个有限的空间里让它们协同工作、互不干扰并且还能保持一个可接受的响应速度。1.2 Voice Companion 解决的三个核心问题Voice Companion这套方案说白了就是一个“给本地AI装上嘴巴和耳朵”的语音交互框架。它要解决的核心问题我总结下来就三条。第一解决本地语音链路的闭环问题。很多朋友本地跑过大模型但只是用网页聊天窗口文字对话。想要语音对话要么自己拼凑各家API要么忍受云端服务的数据安全风险。Voice Companion把麦克风采集、语音识别、大模型推理、语音合成、音频播放这条链路串成一个完整的本地闭环数据从头到尾不出机器。第二解决低显存下的资源分配问题。8G显存不是不能跑而是要讲究策略。这套方案的核心思路是显存优先给真正耗资源的大模型语音识别和语音合成尽量跑CPU或者用极小模型数字人形象模块做到可选、可降级。这样8G显存才能撑起完整的交互体验。第三解决AI“干巴巴”的问题。纯文字聊天最大的问题是毫无温度感。加上语音识别和合成之后你可以对着电脑说“今天有什么安排”它会像个人一样回答你而且支持打断、支持连续对话。这种体验和敲键盘完全不一样更像是在跟一个真实存在的助手说话数字人形象反倒成了锦上添花的事情。1.3 这套方案适合谁我捋了一下这套方案主要适合下面这几类人。第一类是AI爱好者、极客玩家。手头正好有一张8G显存的显卡或者一台6G/8G显存的笔记本不想花钱买云服务就想在本地折腾出点有意思的东西。第二类是对数据隐私敏感的用户。所有语音数据、文本数据都在本机处理不会传出去这一点在企业场景或者个人隐私场景下尤其重要。第三类是想低成本验证数字人产品的人。做Demo、做原型、做毕业设计用这套方案搭底子比直接用云服务灵活得多而且可控性更强。说白了Voice Companion把过去需要高性能显卡才能玩的东西拉到了主流配置也能跑的水平这个定位本身就是它的价值所在。2. 底层逻辑8G显存凭什么能跑起来2.1 显存、参数、量化三者的关系很多人搞不明白“显存的作用和模型参数的关系”看到模型是7B就觉得得十几个G显存看到14B就觉得没有24G卡别想碰。这里面的关键变量是量化。先说模型占用的计算方式。大模型推理的时候显存占用主要由三部分组成模型权重、KV Cache、激活值。其中模型权重是大头推理过程中KV Cache会随着对话长度增长激活值则取决于batch size和序列长度。对于一个FP16半精度的7B模型光权重就需要大约14GB显存这个数字看起来吓人但量化之后就不一样了。量化是什么意思简单理解就是把原本用16位浮点数存储的权重压缩成4位整数或者8位整数来存储。精度会有轻微损失但换来的是体积的大幅缩小。以GGUF格式的Q4_K_M量化为例7B模型权重大约只要4.7GB14B模型大约要9GB左右。这样一来8G显存跑7B量化模型绰绰有余甚至能尝试小参数的MoE模型。我还是想强调一句不是模型参数总量越小越好也不是越大越好关键看量化后的大小和实际推理所需的KV Cache加在一起能不能在你那张卡上放下。我见过有人在8G卡上硬跑FP16的7B模型结果直接OOM或者加载完之后上下文一长就爆显存这就是没算明白这笔账。2.2 选模型的黄金法则不只盯着参数总量看那具体选什么模型我记得网上有个热门讨论叫“moe架构要全部参数进显存吗”这个问题问得很关键。我先给结论MoEMixture of Experts混合专家模型推理的时候虽然每次只激活一部分专家参数但权重文件本身还是要全部加载进显存的。不过MoE的价值在于它的“总参数量”和“激活参数量”是两回事。比如Qwen1.5-MoE-A2.7B总参数量高达14.3B但每次前向计算只激活约2.7B参数。这意味着它的推理速度非常快接近小模型的速度而量化后权重大约8GB刚好卡在8G显存的边缘。如果你想让8G显卡“用最小的显存跑出相对聪明的模型”这类小而精的MoE模型是非常值得关注的方向。基于我在8G显存环境下的实际测试我整理了一张推荐表大家可以直接参考模型总参数量量化方式权重显存占用8G显存可用性推荐场景Qwen2.5-7B-Instruct7.6BQ4_K_M约4.7GB非常舒适日常对话、知识问答、Agent工具调用GLM-4-9B-Chat9.4BQ4_K_M约5.5GB可用留足KV Cache余量中文能力出色适合中文数字人Qwen2.5-14B-Instruct14.8BQ4_K_M约9GB偏极限需要关闭部分模块和降低上下文长度追求更高智商可牺牲实时性Qwen1.5-MoE-A2.7B14.3B总/2.7B激活Q4_K_M约8GB紧凑可用速度优先的智能对话MiniCPM3-4B3.7BQ4_K_M约2.5GB非常轻松显存占用极致压缩、可配合更高上下文我个人在8G显存下首选Qwen2.5-7B-Instruct或GLM-4-9B-Chat。前者胜在生态成熟工具调用能力强后者中文表达更自然各有各的优势。如果特别在意上下文长度可以考虑MiniCPM3-4B这类小模型显存占用很轻松可以把多的显存全部让给KV Cache支持很长的对话历史。2.3 语音模块的“去显存化”策略我前面提到了一个核心策略把显存留给大模型语音模块尽量不占显存。这一节的逻辑就在这里。先说语音识别ASR。目前常用的几个本地ASR方案比如sherpa-onnx配SenseVoice-Small模型、Paraformer、Zipformer等这些模型本身非常小。SenseVoice-Small模型的参数量大约只有230M跑在CPU上毫无压力识别速度远超实时中文效果相当不错。很多人一听到“AI语音识别”就以为要上GPU其实完全没必要大材小用。再说语音合成TTS。这一部分是整个链路里比较吃性能的环节。有些TTS模型比如XTTS v2、ChatTTS虽然也能跑CPU但速度会明显变慢。我的策略很简单如果8G显存还有富余就把TTS放在GPU上跑速度更快如果显存吃紧就强制TTS跑CPU延迟高一点但至少不会爆显存。我在后面实操部分会给出两种配置的具体方案。这个资源分配策略是整个方案的核心指导思想。8G显存不是不能跑数字人而是要把每一MB显存都用在刀刃上。让语音识别和TTS去抢大模型的显存那就和“8G也能跑”这个目标背道而驰了。3. 实战搭建从零开始让8G显存的数字人开口说话3.1 准备工作软件与模型全清单正式开始操作之前我先列一下要准备的东西避免半途发现缺这缺那。操作系统我建议Windows 11或者Ubuntu 22.04 LTS两者我都试过Ubuntu下的音频设备管理稍微麻烦一点Windows下门槛更低。需要安装的软件包括Ollama目前最省心的本地大模型推理服务安装之后一条命令就能拉起模型服务还自带OpenAI兼容的API接口。Python 3.10主控逻辑全靠它推荐用3.10或3.11版本太新的版本个别音频库可能还没适配。sherpa-onnx语音识别推理库支持多种ASR模型格式安装方式很简单pip一条命令搞定。音频处理库sounddevice负责从麦克风采集音频配合numpy做数据处理。TTS引擎推荐ChatTTS或者IndexTTS具体选哪个后面会说。如果你只想快速跑通也可以先用pip安装edge-tts走在线接口但这就违反了本地原则正式方案我会用纯本地版本。模型方面需要准备的是一个LLM模型用Ollama拉取一个ASR模型从sherpa-onnx官方GitHub Releases下载一个TTS模型从Hugging Face下载或者用pip直接装。命令部分我建议这样操作# 安装OllamaWindows直接去官网下载安装包Linux用下面这行 curl -fsSL https://ollama.com/install.sh | sh # 拉取我推荐的主力模型Qwen2.5-7B-Instruct ollama pull qwen2.5:7b # 安装Python依赖 pip install ollama sounddevice numpy sherpa-onnxOllama拉取模型的时候会自动下载适合当前平台的量化版本默认就是Q4_K_M级别的量化省事。如果你想要更精细的控制也可以去Hugging Face下载GGUF文件再用Ollama的Modelfile导入但新手阶段直接用ollama pull就行了。3.2 语音识别模块接入让电脑先“听”懂人话语音识别是数字人的耳朵。我用的是sherpa-onnx配合阿里开源的SenseVoice-Small模型原因很简单效果好、体积小、中文识别能力在同类小模型里属于第一梯队。先把模型下下来。sherpa-onnx官方提供打包好的模型文件直接下载解压就能用。以SenseVoice为例需要下载包含model.onnx和tokens.txt的目录然后放到项目的models/sensevoice文件夹下。接下来写一个ASR的Python模块核心代码大概是这样的import sherpa_onnx import numpy as np import sounddevice as sd class SpeechRecognizer: def __init__(self, model_path: str, tokens_path: str): self.recognizer sherpa_onnx.OfflineRecognizer.from_sensevoice( modelmodel_path, tokenstokens_path, num_threads4, use_gpuFalse, # 关键跑CPU不占显存 ) self.sample_rate 16000 def recognize(self, audio: np.ndarray) - str: # 将float32音频转为16位PCM audio_int16 (audio * 32767).astype(np.int16) stream self.recognizer.create_stream() stream.accept_waveform(self.sample_rate, audio_int16) self.recognizer.decode_stream(stream) return stream.result.text # 录音函数采集麦克风音频并返回 def record_audio(duration: float 5.0, sample_rate: int 16000) - np.ndarray: audio sd.rec(int(duration * sample_rate), sampleratesample_rate, channels1, dtypefloat32) sd.wait() return audio[:, 0]有几个细节值得注意。第一采样率一定要是16kHz这是绝大多数ASR模型的基准采样率。第二录音的时长处理后面我会讲这里只是最基础的版本。第三use_gpuFalse不是妥协而是刻意为之。这么大点模型在GPU上跑纯属浪费CPU性能完全足够。实测下来SenseVoice-Small在CPU上的实时率大约是0.05~0.1也就是处理1秒音频只需要0.05~0.1秒识别速度和准确率都完全在可接受范围内而且显存占用直接为0。3.3 大模型智能体模块让本地AI拥有“大脑”和“工具”接下来是大模型部分这也是8G显存方案里最核心的一环。Ollama提供了非常简洁的API支持流式输出这让数字人可以实现“边说边想”的效果而不是等全部生成完才一次性播报。大模型模块的代码不复杂import ollama class LLMAgent: def __init__(self, model_name: str qwen2.5:7b): self.model model_name self.messages [ {role: system, content: 你是一个友好的桌面语音助手回答尽量简洁自然适合口播。} ] def chat_stream(self, user_input: str): self.messages.append({role: user, content: user_input}) stream ollama.chat( modelself.model, messagesself.messages, streamTrue, options{num_ctx: 8192}, # 控制上下文长度避免KV Cache爆显存 ) for chunk in stream: yield chunk[message][content] self.messages.append({role: assistant, content: .join([c[message][content] for c in ollama.chat(modelself.model, messagesself.messages)])})等等上面这段代码我写得有点绕实际应用中我更推荐下面这种清晰的写法先把完整回答收集起来同时通过生成器把片段交给TTS做流式合成。import ollama from typing import Generator class LLMAgent: def __init__(self, model_name: str qwen2.5:7b): self.model model_name self.messages [ {role: system, content: 你是Voice Companion本地助手回答口语化、简洁控制在一百字以内。} ] def chat_stream(self, user_input: str) - Generator[str, None, str]: 流式返回回答片段结束后返回完整文本。 self.messages.append({role: user, content: user_input}) full_answer [] stream ollama.chat( modelself.model, messagesself.messages, streamTrue, options{num_ctx: 8192}, ) for chunk in stream: piece chunk[message][content] full_answer.append(piece) yield piece # 片段实时传给TTS answer .join(full_answer) self.messages.append({role: assistant, content: answer}) return answer这段代码里有个细节num_ctx控制模型的上下文窗口长度。8G显存跑7B模型时上下文窗口越长KV Cache占用越多。我实测8192是一个比较稳妥的值既能记录多轮对话又不会在对话过程中突然爆显存。要是你选了更大的模型建议把这个值降到4096。顺便说一句Qwen2.5-7B这个模型支持OpenAI兼容的工具调用。如果你想玩Agent玩法可以让AI调用本地的天气接口、日历接口、甚至执行Python脚本。这个后面我再单独开一篇细聊这里先聚焦语音交互主线。3.4 语音合成模块让AI的声音不再“机械”语音合成是数字人的嘴巴。目前本地TTS方案里我推荐大家关注两个ChatTTS和IndexTTS。ChatTTS是专门为对话场景设计的TTS模型特点是口语化自然、支持笑声和停顿等副语言现象听起来非常接近真人而且显存占用可以控制在2GB以内。IndexTTS是最近比较火的中文TTS音色和韵律表现更好但对硬件的要求稍高。如果你只有8G显存且还要同时跑7B大模型建议优先用ChatTTS如果显存剩余比较多再考虑IndexTTS。ChatTTS的部署和使用也非常直接import ChatTTS import torch import sounddevice as sd import numpy as np class TTSEngine: def __init__(self, use_gpu: bool True): self.chat ChatTTS.Chat() self.chat.load(compileFalse) # 关闭编译减少显存占用 self.use_gpu use_gpu and torch.cuda.is_available() if self.use_gpu: self.chat.to_device(cuda) def speak_live(self, text: str): 合成并播放语音返回是否成功。 # 流式合成需要按句子切分避免一次性生成太长的音频 sentences [s for s in text.replace(。, .\n).replace(, !\n).replace(, ?\n).split(\n) if s.strip()] for sent in sentences: wavs self.chat.infer(textsent, streamFalse)[0] audio wavs[0].detach().cpu().numpy() sd.play(audio, samplerate24000) sd.wait()这段代码关键在infer这一步。ChatTTS默认只使用一个GPU的显存但如果你的显存实在不够可以在初始化的地方加一句self.chat.to_device(cpu)把它完全放在CPU上跑。代价就是合成速度会从实时率的几倍变成勉强实时但至少不会爆显存。另外ChatTTS的采样率是24000Hz播放的时候要用24000作为采样率否则声音会变调或者出现奇怪的杂音。这个坑我踩过后面常见问题里我会再提到。3.5 数字人形象与开合嘴让“人”真正出现很多朋友搞数字人最关心的其实是“能不能看到一个能张嘴说话的人”。这里我先说句大实话语音交互链路是数字人的灵魂形象是锦上添花。先把语音链路跑通再考虑要不要加形象。在8G显存约束下我推荐三种数字人方案从轻到重排列。第一种是轻量级方案用LIVE2D模型配合音频驱动嘴型代表项目有DeepLive2D等。这类方案的原理是分析音频的音量包络然后驱动2D角色的嘴部参数让角色看起来像是在说话。显存占用极低基本可以忽略不计效果也比较自然适合二次元风格或插画风格的虚拟形象。第二种是视频级方案用SadTalker或者EMO这类模型输入一张静态照片和音频生成一段嘴型匹配的视频。效果很逼真但最大的问题是在GPU上运行要占用显存而且生成速度慢、延迟高。8G显存跑LLM和TTS已经很紧张再同时跑SadTalker基本不现实只能作为离线生成视频的方案不适合实时对话。第三种是拼接方案用剪映或者其他工具预先生成一段“数字人形象视频库”然后根据语音合成结果拼接对应的口型视频片段。这个方法的好处是运行时不占用显存但灵活性差只能做固定话术播报没法应对任意对话内容。我的建议非常明确8G显存玩家优先用第一种LIVE2D方案把形象渲染和音频驱动完全放在CPU上跑显存留给LLM和TTS。这样既能见到“活”的数字人又不影响对话体验。3.6 主控逻辑唤醒、对话、打断与连续对话有了耳朵、大脑和嘴巴就差一个把它们串起来的“中枢神经系统”了。主控逻辑要处理三件事怎么知道用户要开始说话唤醒、用户说完了没有VAD、以及说话过程中能不能打断AI打断。唤醒词可以用Porcupine或者sherpa-onnx自带的唤醒词检测模型但更简单的做法是用“按键开始说话”模式。考虑到数字人通常是在电脑前用我给一个比较实用的方案按住某个快捷键开始录音松开后自动识别并回答。这个方案最稳定也不存在误唤醒的问题。打断的实现也很关键。语音互动的核心体验之一就是“AI正在说话的时候用户可以直接插话打断”。技术上其实不复杂在AI播放语音的时候后台持续监听麦克风的音量一旦检测到超过阈值的语音能量就停止当前的TTS播放重新进入录音状态。我贴一段主控循环的伪代码帮助理解整个流程def main_loop(): while True: wait_for_wake_key() # 等待快捷键按下 audio record_speech() # 录音直到检测到静音 text asr.recognize(audio) # 语音转文字 if text.strip(): print(你:, text) # 流式合成并播放回答 for chunk in llm.chat_stream(text): tts.speak_live_interruptible(chunk)看到这里你应该明白了Voice Companion这套方案的灵魂并不在于某一个模型多强大而在于链路的高效协同。每一层都在做自己最擅长的事ASR只负责快速把声音变成文字LLM只负责思考和生成内容TTS只负责把文字变成动听的声音主控逻辑负责调度。这种模块化设计的好处是任何一层都可以单独替换升级不影响其他部分。4. 踩坑记录与性能调优实测下来的经验都在这里4.1 显存爆了怎么办我的三级降级方案实操过程中最让人头大的问题就是莫名其妙爆显存。明明模型不大对话聊着聊着就OOM了。我总结了一套层层递进的显存降级方案按优先级排列第一步关掉TTS的GPU加速。ChatTTS在GPU上大概占1.5~2GB显存这可不是小数目。把它强制放到CPU上立刻能腾出一大块空间给KV Cache和上下文窗口。语音合成速度会慢一些但在8G显存条件下这是性价比最高的让步。第二步降低num_ctx上下文窗口长度。从8192降到4096KV Cache占用直接减半。如果你的对话场景比较单一比如只是问答、查天气、控制设备4096完全够用。这一步可以显著减少长对话场景下的显存压力。第三步换更小的模型。从7B降到4B或者3B级别比如MiniCPM3-4B、Llama 3.2 3B。它们量化后只有2.5GB左右显存占用瞬间宽裕很多代价是智商下降但应对日常闲聊和基础问答完全够用。我把这三级降级方案整理成了一张表方便你对照排查优先级操作释放显存体验影响第一级TTS强制CPU约1.5~2GB合成速度略慢无实质影响第二级num_ctx从8192降到4096约1~2GB短期记忆变短常见对话没问题第三级模型从7B换到4B/3B约2~3GB回答质量下降但语音链路稳定4.2 从“能说话”到“好意思开口”延迟优化记录刚跑通的时候我的数字人交互体验很差按下说话键录完音要等好几秒AI才开始回答而且回答是从头到尾一次性合成完才播放感觉就像跟一个反应迟钝的人在聊天。我做了三个优化之后体验有了质的飞跃。第一个优化是流式TTS。大模型生成回答的时候不是等全部文字生成完再开始合成语音而是每生成一小段文字就立刻交给TTS合成并播放。这样用户听到第一句话的时间能提前好几秒体感上AI“开口”变快了。这也是为什么我在前面的代码里用了生成器一边从Ollama拿流式输出一边把文字片段喂给TTS。第二个优化是每句话独立播放。TTS合成整段文字的时候如果文字太长AI需要先“读稿”好久才开始说话。我在代码里把回答按标点符号切分成短句每合成一句就播放一句。效果非常明显用户听到的是一个人一句一句地说话而不是在等待一个漫长的合成过程。第三个优化是预加载模型。把所有模型在程序启动时就全部加载到内存和显存中避免每次对话都重新加载一遍。这些模型初始化本来就慢如果每次录音结束才加载那光加载时间就够用户喝杯水了。我做了一组简单对比优化前从按下说话键到听到回答大约需要8秒。优化后这个时间缩短到2秒以内。8秒是什么感受基本没法用用户早就没了耐心。2秒呢虽然比真人对话还是慢一点但至少在一个可接受的对话节奏里。4.3 常见问题速查表从爆显存到音频怪声我把自己上手过程中遇到的所有问题汇总成了一个速查表都是真实踩过的坑你照着表排查能省不少时间。问题现象根本原因解决办法运行一段时间后OOM崩溃对话变长导致KV Cache增长超出显存降低num_ctx或换更小模型播放语音有杂音或掉字采样率不匹配TTS输出24000Hz但播放用了16000Hz统一使用TTS模型的原始采样率播放识别出来的文字全是乱码ASR模型和tokenizer不匹配或使用了未训练的输入格式检查tokens.txt是否匹配model.onnx确保采样率16kHzAI回答到一半被截断TTS播放被杀进程或中断逻辑误判检查VAD阈值把静音检测阈值调高避免环境噪音误触发ChatTTS首次运行特别慢需要加载声学特征和说话人embedding模型加载过程走一次之后常驻内存不要反复初始化麦克风采集无声音默认输入设备错误或权限未开启检查系统麦克风权限用sounddevice查询默认设备IDGPU占用看着很高但速度慢模型未使用GPU算力实际在CPU跑在Ollama和TTS中明确设置GPU设备并确认torch.cuda.is_available()返回True对话历史越聊越“弱智”上下文被旧消息塞满新的重要信息被挤掉定期裁剪早期消息只保留最近几轮对话唤醒词说话时总是误触发VAD阈值过低环境噪音被判断为人声动态调整VAD阈值或改用“按键说话”模式这里我想重点说一下采样率匹配的坑。有一次我把ChatTTS的音频直接喂给播放器结果声音又尖又哑我还以为是模型出了问题。后来仔细一看ChatTTS生成的是24kHz的音频播放器却被我硬设置成了16kHz相当于所有音频都变调了。很多初学朋友遇到类似问题第一反应往往是模型坏了其实是采样率没对齐。做音频处理脑子里要时刻有一根弦每一段音频数据都必须明确知道它的采样率是多少。4.4 8G显存极限配置参考我最推荐的一套组合说了这么多理论最后我直接给一套我测试下来最稳定、体验最好的8G显存配置组合。大模型用Qwen2.5-7B-Instruct的Q4_K_M量化版本num_ctx设置8192。ASR用sherpa-onnx SenseVoice-SmallCPU运行占0显存。TTS用ChatTTSGPU优先占用约2GB显存。数字人形象如果确实需要用LIVE2D方案跑CPU。整体显存分配大致是这样模型权重4.7GB KV Cache约1GB ChatTTS约2GB加起来在7.7GB左右系统还有一点余量不会因为显存占满导致驱动崩溃。这套配置下我实测的非流式延迟大约2~3秒流式首响延迟约1秒以内。识别准确率在普通话环境下超过95%回答质量和语音自然度都达到了可日常使用的水平。如果你想追求更高的AI智商可以试试GLM-4-9B-Chat的Q4量化版本代价是把TTS放到CPU上跑。如果你想追求更快的响应可以换成MiniCPM3-4BTTS随便用GPU对话流畅度会更高。说到底8G显存跑本地AI数字人不需要做什么逆天改造核心就是四个字合理取舍。每个模块都选最合适的配置别贪心别想着样样都拉满这方案就可以稳定跑很久。最后再分享一点我的个人体会。折腾数字人最有趣的地方不是模型跑得多快、回答多聪明而是当你的电脑第一次“喊出你的名字”、第一次主动提醒你喝水的时候你会觉得这个本地数字人不只是一个技术Demo它真的像是一个有一点性格的合作伙伴。这套系统后续还可以接知识库、接智能家居控制、接入日历提醒甚至给不同角色定制不同的音色和人格。8G显存不是限制反而逼着你把方案优化到极致。希望这篇文章能帮你少走弯路早日让你的数字人开口说话。

8G显存也能跑本地AI数字人：Voice Companion完整搭建指南

相关推荐

企业级SaaS系统五层架构设计与实践

Git高效使用技巧与团队协作最佳实践

GPT-4o与Claude API合规接入指南

更多资讯

《算法导论》核心概念：复杂度分析、大O记号与算法设计方法

因果表征学习中的连续机制建模与TRACE框架

Amber分子动力学模拟蛋白结构准备流程与避坑指南

机器学习项目全流程实战：从数据到部署

揭秘中转站模型冒充：用tokenizer指纹和行为测试识别真假GPT-6

Jev 框架入门：TypeSafe 约束解码与结构化输出实战

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？