买笔记本的时候，我在RTX 5060和RTX 5070之间纠结了很久。5070有12GB显存，贵了将近两千块。我当时想的是：8GB应该够了吧？我又不训练模型，只是推理而已。现在回想起来，这个想法"对了一半，错了一半"——8GB确实够用，但前提是你得花大量精力去做显存优化。
这篇文章我想聊聊我在RTX 5060 8GB这块显卡上做AI视频工具的真实体验。包括显存是怎么分配的、遇到了哪些问题、用了什么优化技巧，以及最后是怎么把两个AI模型稳稳地塞进8GB显存里的。如果你也在用中低端显卡跑AI，或者正在考虑买什么显卡，希望我的经验对你有帮助。
先算一笔账：8GB显存到底能装什么？
在做任何优化之前，我先做了一件事：搞清楚每个组件到底占多少显存。这不是猜的，是一个一个用 nvidia-smi 和PyTorch的 torch.cuda.memory_allocated() 实测出来的。
首先，PyTorch的CUDA context本身就要占用一部分显存，大概400-500MB。这是不管你跑什么模型都省不掉的，是CUDA运行时的固定开销。
然后是IndexTTS2模型。用fp32精度加载的话，大概占3.5GB。如果用fp16，可以压到1.8GB左右。这里说的是模型权重的显存占用，不包括推理时的中间tensor。
LatentSync就更大了。这是一个基于diffusion的唇形同步模型，参数量不小。fp32精度加载大概占5.5GB，fp16精度大概占2.8GB。
你算一下：如果两个模型都用fp32，光是模型权重就要3.5 + 5.5 = 9GB，加上CUDA context就是9.5GB，8GB显存根本塞不下。即使用fp16，1.8 + 2.8 = 4.6GB，加上context大约5GB，看起来还有3GB余量，但推理时的中间tensor才是真正的"隐形杀手"。
第一次翻车：CUDA Out of Memory
我记得特别清楚，那天晚上我兴冲冲地把两个模型都用fp16加载好了，准备跑第一个完整的视频生成流程。先从TTS开始——顺利，1.8GB显存占着。然后到LatentSync——也加载上了，显存占用到了4.8GB，看起来还好。
然后开始推理。LatentSync在处理视频帧的时候，会在GPU上创建大量的中间tensor：编码后的图像特征、diffusion的噪声图、每一步的去噪中间结果……这些东西是动态分配的，推理完就会被释放，但在推理过程中它们会同时存在于显存中。
处理到第15帧左右的时候——啪，CUDA out of memory。我看了一眼nvidia-smi，8GB全满了。那一刻的心情，说崩溃也不为过。
策略一：模型懒加载，不要同时驻留
第一个想到的策略是最直接的：既然两个模型不能同时在显存里，那就轮流来。用户的任务流程本身就是串行的——先生成语音，再做唇形同步。所以理论上TTS跑完之后可以把模型卸载掉，再加载LatentSync。
我做了一个模型管理器，每次推理前加载模型，推理完立刻卸载。卸载不是简单的 del model，而是要显式调用 torch.cuda.empty_cache() 来清理PyTorch的缓存。光 del 是不够的，PyTorch有自己的内存分配器，不会马上把显存还给系统。
这个方案解决了"同时加载"的问题，但带来了一个新问题：每次切换模型都要重新加载。IndexTTS2加载一次大概15秒，LatentSync加载一次大概20秒。如果用户连续生成三个视频，就要反复加载卸载六次，总等待时间超过一分半钟。这对用户体验来说是不可接受的。
所以我需要的是：模型常驻显存，但不能同时占着。这是一个矛盾的需求，解决它的关键在下一层优化。
策略二：fp16精度 + 更极致的显存压缩
fp16精度加载是最基础的优化，基本上所有的推理场景都应该做。PyTorch里一行代码的事：model.half()。但光做fp16还不够，因为LatentSync在fp16下还是要2.8GB。
我进一步做了几件事：
第一，强制CPU offload非核心模块。LatentSync里面有些模块在推理时不是每一步都需要常驻GPU的。比如参考图像的编码器，只需要在开始时跑一次，之后就可以把它的权重和中间结果移到CPU上。我用的是PyTorch的 accelerate 库里的 cpu_offload 功能，把不常用的子模块自动在GPU和CPU之间迁移。
第二，降低批处理大小。LatentSync默认一次处理8帧，我把这个参数降到4帧。虽然推理时间变长了一点点（大概多了15%），但峰值显存占用降低了将近40%。对8GB显存来说，这40%太关键了。
第三，使用gradient checkpointing。这个技巧本来是训练时用来省显存的，但推理时也可以用。原理是不保存中间激活值，用到的时候重新计算。用时间换空间。对于diffusion模型这种有很多中间步骤的场景，效果很明显。
经过这三步优化，LatentSync的峰值显存占用从2.8GB降到了约1.6GB。加上IndexTTS2的1.8GB和CUDA context的500MB，总共约3.9GB。这下两个模型可以同时驻留了！但别高兴太早，还要留推理时的动态显存。
策略三：推理中间结果的显存管理
模型能同时驻留了，但推理的时候还是会爆。问题的根源是：LatentSync在diffusion的每一步都会创建新的tensor，而这些tensor在一步结束后如果不及时清理，就会堆积在显存里。
正常的PyTorch代码里，中间tensor会在变量超出作用域后被垃圾回收。但GPU显存的回收不是实时的，PyTorch会缓存一段显存以备下次使用。这本身是一种优化策略，但在显存紧张的时候就成了问题。
我的做法是：在diffusion循环的每一步结束时，显式地把不需要的中间tensor移到CPU上，然后调用 torch.cuda.empty_cache()。这个操作是有开销的——每次大约几十毫秒——但相比于显存爆掉导致整个任务失败，这点开销完全可以接受。
还有一个技巧是使用 torch.no_grad() 上下文。推理的时候不需要计算梯度，加上这个可以让PyTorch不保存梯度相关的中间数据，省一些显存。
另外，我还改了一个细节：生成视频帧的时候，不要把所有的帧都存在GPU上。LatentSync的输出是一帧一帧的图片，默认实现会把所有帧存在一个list里最后一起返回。我改成了每生成一帧就立刻用PIL保存到临时文件，然后把GPU tensor释放掉。这样GPU上永远只有当前处理的那一帧，而不是整个视频的所有帧。
策略四：微服务架构 = 物理隔离
前面说了这么多优化，都是让两个模型能"和平共处"在同一个进程的同一块显存里。但还有一个更根本的解决方案：让它们根本不在同一个进程里。
这就是我最终采用的微服务架构。TTS服务跑在8101端口，独占一个Python进程，只加载IndexTTS2，占用约2GB显存。Latent服务跑在8102端口，独占另一个Python进程，只加载LatentSync，占用约2GB显存。两个进程各自有独立的CUDA context，互不影响。总显存占用约4GB，还有4GB的缓冲空间，绰绰有余。
而且这个架构还有一个好处：如果未来换了更大的模型，或者买了更好的显卡，每个服务可以独立调整。TTS的模型升级了，只影响TTS服务的显存占用；Latent换了一个更大的模型，也只影响Latent服务。不会出现"改了一个模型导致另一个模型跑不了"的连锁反应。
实际运行数据：优化前后的对比
优化前，单体架构、fp32加载、没有任何显存管理，两个模型尝试同时加载——直接CUDA OOM，跑都跑不起来。
优化后，微服务架构、fp16加载、CPU offload、按帧释放、gradient checkpointing。TTS服务稳定占用约2.1GB，Latent服务稳定占用约2.4GB（推理时峰值约3.2GB），总峰值约5.3GB。8GB显存还剩大约2.7GB，完全够用。
推理速度方面，TTS一个30秒的音频生成大约需要5秒（模型常驻后），LatentSync处理30秒的视频大约需要90秒。虽然不算快，但在这个级别的硬件上已经是能接受的极限了。
给8GB显存用户的实用建议
如果你也用8GB显存的卡跑AI应用，这里有些实用建议：
- 能fp16就fp16。推理场景下fp16的精度损失几乎可以忽略，但显存直接减半，这是性价比最高的优化。
- 能拆服务就拆服务。如果多个模型有依赖冲突或者显存冲突，用微服务隔离是最干净的解决方案。
- 中间结果别留在GPU上。处理完就移到CPU或者保存到磁盘，GPU显存是稀缺资源。
- 监控显存使用。装个nvtop或者定期跑nvidia-smi，了解你的显存到底花在哪里了。不知道瓶颈在哪就没法优化。
- 别怕CUDA OOM。遇到OOM不要慌，它只是告诉你当前配置不行。逐步降低batch size、逐步offload更多的模块到CPU，总能找到能跑的配置。
最后我想说，8GB显存确实不算大，但对于推理场景来说，只要优化得当，能干的事情远比你想的多。我的这个AI口播视频工具，两个AI模型轮流或同时运行，在8GB的RTX 5060上稳定跑了好几个月，一次OOM都没再出现过。显存不够不可怕，可怕的是不知道该怎么省。