六个 G 的显存，我塞了四个程序

我在测一句短语音的合成时间。同样的文本、同样的参数，前一天测是 3.9 秒，这次跑了半天没出结果。去翻语音服务的日志：

0%|          | 20/1500 [00:26<26:53, 1.09it/s]

1.09it/s。正常应该是 17 左右——慢了十五倍。

看显卡

nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv,noheader
5639 MiB, 6144 MiB, 100 %

6G 的显存用了 5.6G，GPU 利用率满格。把占用进程列出来：

F:\kafu-tts\GPT-SoVITS-v2pro\runtime\python.exe    ← 语音合成
F:\AI-VTuber\tools\ollama\lib\ollama\llama-server.exe  ← 本地对话模型
D:\steam\steamapps\common\VTube Studio\VTube Studio.exe ← 虚拟形象
C:\Program Files\obs-studio\bin\64bit\obs64.exe    ← 画面合成

四个，全在抢同一块显卡。对话模型那个单独占 2.16G：

{"name":"qwen2.5:3b", "size_vram": 2160000000, "context_length": 4096}

为什么语音合成对显存这么敏感

GPT-SoVITS 生成语音是逐帧自回归的——一帧一帧往下推，1500 帧就是 1500 次前向。日志里那个进度条走的就是帧数。这种负载最怕的就是算力被分走：不是排队等，是每一帧都变慢，累积起来就成倍地拖。

所以它不是"卡住了"，是单纯地在慢慢跑。我把 bash 的超时从 120 秒加到 300 秒，还是被 SIGTERM 掉——因为我那个测试脚本一连跑八条合成，每条十几秒，加起来超了。

先试了一个"用完就退"的方案

对话模型和语音合成其实是串行的：先想好说什么，再合成语音。没必要让对话模型一直占着显存。

Ollama 支持 keep_alive，我用 AstrBot 的 provider 配置透传进去：

{"custom_extra_body": {"keep_alive": "25s"}}

意思是模型用完 25 秒后自动卸载，把显存让给语音合成。代价是两条弹幕间隔超过 25 秒的话，下次生成要重新加载模型。

有效果，但不够。因为云端没有算力限制，本地这块显卡还要同时喂 VTS 和 OBS，显存腾出来一点也还是紧张。

最后把对话模型整个搬走

我换成了云 API。配置在 cmd_config.json 里：

{
  "id": "deepseek_api/deepseek-chat",
  "model": "deepseek-chat",
  "provider_source_id": "deepseek_api"
}

然后把本地的 ollama 服务停掉。

改造前：5639 / 6144 MiB
改造后：4223 / 6144 MiB    ← 释放 1.4G

空闲显存从 400M 涨到 1.9G。语音合成那边立刻回到正常速度，实测短句 3.9 秒。

顺手把 OBS 的编码器从 nvenc 换成了 x264——前者用显卡编码，也和语音合成抢资源；后者用 CPU，画质几乎看不出差别。

选模型时踩的一个小坑

我一开始配的是 deepseek-flash，测出来响应里带 reasoning_tokens，三十个 token 全花在"思考"上，正文回来是空的。查了一下是推理模型，得先想再答。直播要的是秒回，不是深思熟虑，换成 deepseek-chat 就好了，一千字左右的回复一秒出结果。

现在的账

本地只剩语音合成和虚拟形象两个吃显卡的（OBS 编码交给 CPU 了），对话和记忆这些文本活全在云上。6G 的卡刚够用，但也差不多到顶了——再加一个本地模型就又得打架。