1. 漫剧推文量产的显存瓶颈到底长什么样

我最早接触这个项目时，甲方只有一个朴素的需求：把一批漫画IP的剧情拆成推文短视频，内容平台每天要稳定产出几十条成品。起初的做法很简单，一条条排队生成，跑完一条再跑下一条，时间虽然慢，但人力和算力都够用。直到任务池从零零散散的个位数变成上百条待处理队列，问题才真正暴露出来——GPU明明没有跑满，任务却在排队等待，整体吞吐量上不去，甚至偶尔半夜爬起来看监控，发现一张8卡机器只有两张在工作，其余六张空空如也。

这种“资源感觉没满，但活就是出不来”的状态，几乎每个做过AI内容批量生成的人都遇到过。漫剧推文短视频的生产链路长，中间涉及文案生成、分镜拆解、图生图、配音、字幕渲染和视频合成，几乎每个环节都在跟模型和显存打交道。市面上大多数教程只教你怎么跑通单条任务的pipeline，遇到批量场景立刻抓瞎。

这篇文章我想把过去几个月在“AI漫剧推文短视频批量生成”项目里做的显存池化和并发调度实践完整拆开讲讲。核心解决三件事：显存怎么复用、任务怎么调度、线上怎么排查。适合正在做AI短视频、AI绘画批量生成、或者准备搭建自己多卡推理管线的工程师阅读。如果你是做内容运营的，也可以跳过技术细节，直接看后面关于调度策略和成本对比的部分，照样有收获。

1.1 一条短视频背后的显存开销拆解

在讨论池化和调度之前，先得搞清楚一条漫剧推文短视频到底是怎么把显存吃掉的。

我们目前的生成链路大致分五段：

• 文案改写与分镜生成：这一步跑的是大语言模型，显存占用取决于上下文长度和batch大小，通常可控。
• 角色一致性图生图：获取分镜描述后，用Stable Diffusion系列模型生成漫画风格画面，这是显存占用的大头。
• 配音合成：CPU可以扛一部分，但用了较新的语音合成模型后，GPU推理也是常态。
• 字幕渲染与特效：这一层以前是纯CPU，后来加了超分模型，也开始吃显存。
• 视频合成：把图、音、字幕组合渲染，大部分在CPU端完成，但在批量场景下容易被忽略。

单条任务里，图生图环节峰值显存可能到8GB以上，文案模型推理可能只要2GB，配音模型要3GB左右。最让人头疼的是，这些模型的显存请求不是均匀分布的，而是典型的脉冲式占用：图生图跑到一半的时候，另一个任务刚好在加载权重，两个波峰叠加，显存瞬间超过单卡容量，OOM随即出现。

1.2 串行管线的问题：GPU明明空闲，任务却全部卡死

在没有池化和调度机制前，我们用的是最朴素的方案：搮架一个进程池，每个进程独占一张卡，一条任务从开始到结束一直占着这张卡。问题显而易见——任务在文案生成阶段只用了2GB显存，但整张卡的其余10GB全空着；等到图生图阶段确实需要撑满，但这时候其他任务又挤不进来，因为卡已经被占用了。

串行的另一个隐藏问题是模型加载时间。一个Stable Diffusion模型权重动辄几GB，从磁盘加载到显存需要几十秒。我们当时有六个不同风格的模型，每个任务只在图生图阶段用到其中一个。串行跑的话，每条任务都要经历“加载模型→生成图片→释放模型→加载下一个模型”的循环，光加载耗时就占了单条任务总耗时的将近三成。

后来我算了一笔账：一天的产能目标假设是100条成品视频，串行管线至少需要跑超过20小时，而且这还没算任务失败重试和临时加急带来的资源抢占。现实情况是，推广周期在变短，热点在变快，我们对吞吐量的要求早就不是“今天能出片就行”，而是“这批100条能不能在两小时内出完”。

这个需求直接推动了后面整个显存池化和并发调度的设计。刚开始我也犹豫过，是不是直接上多机分布式就完事了。后来想明白，问题的核心根本不是卡不够多，而是单机多卡资源没有被有效复用。多买卡当然能缓解，但成本翻倍、运维复杂度翻倍，而且不解决“模型重复加载”和“显存碎片化”这类结构性问题。与其盲目扩容，不如先把单机的资源榨干净。

2. 显存池化：把显存从独立包间改成共享食堂

显存池化听起来高大上，本质就一句话：不再让每条任务独占一块显存，而是让所有任务共享同一批显存资源，按需分配、用后归还。就像公司食堂，以前每个人单独坐一个包间，包间再大也只能招待一个人；现在改成大食堂，桌子可以拼、位置可以流转，同样面积能容纳更多人就餐。

具体到实现上，我们分了三层来做。

2.1 模型层池化：权重加载一次，服务N个任务

第一层是模型级池化。把任务的模型加载逻辑从进程内搬到独立服务，所有模型常驻显存，任务通过接口请求模型服务，用完不释放，由下一个任务继续复用。

这里核心的技巧是用一个模型仓库设计模式来实现。每个模型文件在磁盘上只保留一份，在显存里只加载一份。模型服务持有一个模型表，记录每个模型的加载状态、显存占用、当前引用计数和最近使用时间。任务请求某个模型时，模型服务先查表，命中就直接返回句柄，未命中才走加载流程。

class ModelPool: def __init__(self, device, max_memory): self.registry = {} self.device = device self.usage_log = [] def acquire(self, model_name): if model_name in self.registry: self.registry[model_name].ref_count += 1 self.registry[model_name].last_used = time.time() return self.registry[model_name] else: handle = load_model_to_device(model_name, self.device) handle.ref_count = 1 handle.last_used = time.time() self.registry[model_name] = handle return handle def release(self, model_name): handle = self.registry[model_name] handle.ref_count -= 1 if handle.ref_count == 0 and time.time() - handle.last_used > self.idle_threshold: unload_model(handle) del self.registry[model_name]

这样做的好处，最直观的是加载时间被摊薄了。以前每条任务图生图阶段都要等40秒模型加载，现在白天高频使用的模型常驻在显存里，任务进来直接推理，等于省掉了那40秒。另一个好处是显存复用：六个模型虽然权重总和超过了单卡的显存上限，但实际使用频率不一样，高频模型常驻，低频模型在用完冷却之后就被卸载，把显存让给其他热点任务。

这个模式让我想起做Web服务时的连接池——数据库连接复用和模型显存复用，本质上都是把“创建成本高的资源”从创建一次用一次，改成创建一次用很多次。做过后端的人看到这个设计应该秒懂。

2.2 显存块复用与碎片整理

模型层池化解决的是“模型重复加载”的问题，但还没解决“显存块碎片的浪费”。PyTorch默认的缓存分配器是请求多少就分配多少，任务跑完了，显存块虽然释放了，但分配到的不一定是最优位置，久而久之就形成碎片。

最典型的表现是：跑了几十个小时之后，nvidia-smi显示显存使用率不高，但每次新任务进来都报OOM。这种情况十有八九是显存碎片化导致的——空闲总量足够，却找不到一块连续的大空间给大请求用。

我们的做法是启动一个任务级的显存池管理。每个任务不再直接向PyTorch申请显存，而是统一向一个显存中心申请。这个中心维护着一张“大块显存台账”，把显存预切成若干个固定尺寸的大块，比如统一按512MB进行切分。任务请求小于等于512MB，直接分配一个或多个块；请求超过512MB，才启用特殊大块分配逻辑。

这种预切分的思路牺牲了一点点灵活性（某些任务确实用不满一块512MB的显存块，造成少量内部浪费），但换来了两个巨大的收益：一是避免频繁向底层申请和释放显存引发的碎片堆积；二是让调度器能够精确知道当前有多少块空闲，方便判断还能并发跑几条任务。碎片率从平均15%降到了3%以内，这是很划算的交换。

2.3 池化分配的边界情况：当请求超过单块上限怎么办

预切分显存并非万能，任务中偶尔会有超大分辨率图片的生成请求，显存动量一下冲到12GB以上。我的处理方式是在显存中心里留一组保留块，这组块平时不参与普通分配，当超过阈值的请求到来时，临时从保留区拼一个大块出来，用完立刻归还。

关于保留区的大小，我们调了一阵子。最开始固定20%，后来发现平时用不满，浪费了；调小到10%，又偶尔出现超大请求时不够用。最后改成动态保留——根据过去一小时的超大请求比例自动调节，某段时间大图任务多就多留点，少就降下来。这套机制上线后，超大请求的OOM次数基本归零，同时保留区的平均使用率也维持在85%以上。

3. 并发调度：让任务排队但不堵车的排队系统

显存池化解决了资源复用问题，但如果没有合理的调度策略，任务一窝蜂涌进来，照样会出乱子。因为批量生成场景的任务形态千奇百怪，有的是30秒就能跑完的小任务，有的是需要连续占用显存好几分钟的大任务，还有中间穿插着配音、渲染等轻CPU任务。不同任务的特性和资源需求差异巨大，并发调度就成了让整个系统稳定运转的交通警察。

3.1 调度器结构：队列、优先级与水位

我们用的调度器模型参考了操作系统的进程调度思路，结构上有三个核心组件：任务队列、优先级权重、显存水位监控。

任务队列分两条，一条是正常任务队列，一条是加急队列。正常任务按提交时间排序，加急队列支持随时插入并优先执行。每条任务在提交时携带一个资源需求表，标记预期峰值显存、预计运行时长、模型依赖。这个表不用太精确，先后续调度器会根据运行中的实际占用动态校正。

显存水位监控负责实时统计显存池的空闲块数目。调度器每两秒钟从显存中心拉取一次水位快照，对比当前正在运行的任务数量，决定是否放行新的任务。

def scheduler_loop(): while True: snapshot = memory_center.snapshot() running = active_tasks() if can_allocate(snapshot, running): next_task = priority_queue.pop() launch_task(next_task) else: # 水位不够，等待有任务释放后再重试 time.sleep(2)

这段逻辑看似简单，实际考验的是“can_allocate”的判断标准。用占用率算还是用空闲块算，结果差异非常大。我们一开始按总体占用率判断，允许在80%占用率以下继续放任务，结果发现图生图任务一上来，显存瞬间顶满，立刻OOM。后来改成按空闲大块数加安全垫判断：小于两个空闲块就停止放行新任务，宁可让调度器空转一会，也不要冒险塞入可能超限的任务。

这个“安全垫”的思路贯穿了整个调度设计。批量生成场景里，任务之间的显存需求波动很大，调度器必须对“下一秒可能来一个大请求”这件事有预判，而不是等OOM发生后才做反应。

3.2 动态并发度控制：谁在什么时候可以占用显存

接下来是并发度的控制。并发度不是固定的“最多同时跑5条任务”，而是随着显存水位动态变化的。

我把任务分成了三类：

• A类：图生图为主，峰值显存高，持续时间短
• B类：配音和推理混合，中等显存需求，持续时间长
• C类：字幕渲染、视频合成，CPU为主，显存需求极低

调度器维护一个并发预算池，默认并发度为8，但每个任务实际能拿到的额度和任务类型绑定的评分挂钩。高显存需求的A类任务会消耗较多并发预算，C类型几乎不消耗。调度时优先填满C类，因为它们的显存占用低、不会和A类抢夺资源，能够充分利用GPU的空闲时段。

最开始我们用的是最简单的FIFO队列，结果大任务堵在队首，后面一大堆小任务全部跟着排队。后来给任务加了预估时间权重：短任务优先，长任务在系统空闲时才放行。单条任务平均等待时间从原来的25分钟降到了6分钟。

3.3 失败重试与幂等设计：批量场景最容易忽略的一环

批量生成场景中，任务失败的频率远超想象。模型推理偶发CUDA error，网络超时导致配音任务中断，单个分镜生成结果不符合预期需要重跑，这些都会导致任务重试。如果没有处理好重试逻辑，调度器会被同一批失败任务反复冲击，最后演变成全部任务都在Retry，一个都完成不了。

我们的处理方式是在任务层加入幂等状态机。每一条任务有唯一ID，状态在“等待中→生成中→已完成→失败”之间流转。重试只在“失败”状态下允许，且重试次数有限制，默认三次。超过三次的任务自动进入人工介入队列，不参与自动调度。

更重要的是，任务重试时需要能精确恢复到之前的某个中间状态。比如一条任务已经完成了前三个分镜的图片生成，第四个分镜生成失败，重试时不需要全链路从头跑，而是从第四个分镜开始继续。这个透传断点信息的设计减少了超过一半的无效重算，也为后面提升整体吞吐打下了基础。

4. 上线之后的三个坑：一次从显存OOM到任务拥塞的完整排查

前面讲的全是顺风顺水的设计思路，但真实项目往往在细节处翻车。下面这三个坑都是我们上线后真实踩过的，每一个都让人头大，也给整套系统带来了实质性的改进。

4.1 坑一：画幅不一致引发的显存碎片雪崩

上线后第二天，监控突然报警，大批任务在图像生成阶段OOM。当时第一反应是并发度设置太高，显存不够用，把并发度从8降到4，问题短暂缓解了一个小时，随后又出现了。

后来详细排查才发现，真正的原因是画幅不一致。漫剧推文的图片素材尺寸并不统一，有的是竖屏1080×1920，有的是横屏1920×1080，还有少数4K片源转过来的高分辨率图。模型推理时，不同尺寸生成的中间张量大小差异巨大，有些高分辨率请求的显存占用可能是普通请求的四倍。

显存池预切512MB的块，对普通请求绰绰有余，但高分辨率请求一来，需要拼接大量连续空闲块，拼接不成功就触发OOM。这和我前面提的碎片化问题不一样，是任务本身显存波动剧烈导致的类似“高分请求饿死”的问题。

解决方案有两步：第一步，所有进入推理管线的图片先统一缩放和裁切，固定成几种标准尺寸，把显存请求的方差压下来，这条改动让碎片化雪球问题直接消失；第二步，对于特殊需要超高分辨率的任务，单独走一条慢速通道，分配保留区大块显存，不参与普通池的调度。现在想想，如果在流程设计初期就把尺寸标准化做好，这批坑完全可以避免。

4.2 坑二：调度器死锁与任务堆积

第二个坑出现在并发调度器跑了一周之后。某天凌晨，系统突然安静下来，新任务一个都跑不完，老任务全部卡在“运行中”状态。查看日志发现，调度器的水位判断逻辑出现了死锁。

具体情况是：两个A类任务同时开始运行，各占了一块大显存，但运行到中途，其中一个任务因为配音模型加载占用了额外的显存块，此时显存池的空闲块数量降至安全垫以下。调度器检测到水位不足，停止放行新的任务，等待正在运行的任务释放显存。问题在于，正在运行的两个任务自己也在等一个B类任务释放配音模型——而B类任务在队列里根本没被放行。这就成了一个环路等待：调度器等任务释放，任务等队列放行。

修复思路是引入超时自愈机制。调度器不再无限期等待水位恢复，一旦检测到“所有运行中任务都在等待资源”的异常状态持续超过30秒，就主动暂停最轻量的运行中任务，腾出显存，打破死锁圈。另外，在任务请求额外模型时，如果提前知道会导致水位不足，直接拒绝该请求，让任务以降级模式运行，而不是硬着头皮占用更多显存。

这个坑教会我一个道理：并发系统里，不只要考虑正常情况下怎么调度，更要考虑异常情况下怎么降级。调度器对任务状态的感知必须足够细，不然就是拿着红绿灯当摆设。

4.3 坑三：模型权重反复搬运拖垮吞吐

第三个坑是在前两个修完、系统跑得越来越快之后暴露的：吞吐量虽然上去了，但GPU利用率依然有将近30%的时间处于低效状态。用profiling工具看了一段时间后发现问题集中在模型的CPU与GPU搬运上。

有些任务因为流程编排的问题，中间会多次加载同一个模型：一开始图生图用了一次，后来局部修复需要再次调用同一个模型，按我们的缓存策略，释放后缓存被清掉，第二次请求只能重新从磁盘加载。高频任务的加急逻辑也会导致模型频繁被踢出缓存：加急任务插队后，缓存里的模型被替换成加急任务需要的模型，加急任务跑完，普通任务又要把原来的模型重新加载回来。一进一出，时间全浪费在搬运上了。

修这个问题的核心思路是把模型缓存策略从LRU改成LRU加引用计数混合。运行中的任务对模型有引用时，即使该模型长时间未使用，也不允许被驱逐；只有引用计数为零且超过冷却时间，才允许替换。另外，对于高频重复的局部修复场景，直接让任务携带一个“本次会话模型列表”，会话期间模型常驻不释放，从根源上避免反复搬运。

这次调优之后，模型加载造成的GPU空转时间从每日累计约3.5小时降到了半小时内，提升非常直观。

5. 批量生成管线的演进方向与实测数据

显存池化和并发调度跑通之后，整套系统已经能稳定支撑日均几百条漫剧推文短视频的生成。在此基础上，我们又做了几层优化，把吞吐和成本再往下压了一截。

5.1 异步预取与CPU-GPU流水化

一个自然而然的优化方向是流水线化。以前的任务流程是“加载模型→生成图片→释放模型→生成下一批”，每个环节都串行等待。现在我们把数据准备、模型预取和推理计算重叠起来：任务运行图生图的同时，CPU已经在为下一个分镜预处理图片，显存池也在后台把下个任务可能用到的模型权重预先搬运到GPU侧的缓存地址。

这个思路类似于CPU的流水线架构，把等待时间藏起来，让GPU始终有算的活。实测下来，单条任务的平均生成时间缩短了大约16%，整体吞吐量提升了将近两成。

5.2 让副渲染不再抢显存

漫剧推文的配音、字幕渲染和视频合成，虽然显存占用不算大，但并发量一旦上来，依然会挤压核心的图像生成任务。我们的处理方式是给这些轻量任务指定专门的CPU执行通道，并用进程池隔离，避免它们在显存池里抢占高水位资源。

这么做的收益是让GPU所有的显存都优先保障图生图和视频超分环节，其他环节的排队时长有所增加，但对整体交付时间几乎没有影响。任务混跑时，GPU层面的OOM率从之前的4%降到了0.1%以下。

5.3 实测对比：吞吐、利用率与成本

在投入同样4张RTX 4090的情况下，我用三组数据来说明优化前后的差异。

另外算了一笔账，按云GPU按小时计费的话，同样产出100条视频，优化后的成本大约是优化前的40%不到，等于把计算资源利用效率翻了一倍还多。对于内容团队来说，这直接带来的价值就是更短的出片周期和更低的边际成本，热点来了可以更从容地铺量，不再因为算力预算而限制选题数量。

6. 一套可以直接抄走的显存池化与调度参考配置

最后把一些偏实践层面的配置和经验总结成清单，方便你直接拿去参考。这套配置基于我们自己环境的实测，不一定完全适配你的硬件，但是思路可以复用。

6.1 环境与硬件选型建议

• GPU建议选24GB显存以上的型号，比如A100、4090，能容纳主流Stable Diffusion和视频生成模型。
• 显存池预切块大小默认512MB，如果你的常见任务显存需求特别大，可以调到768MB或1GB。
• 保留区比例建议设置为10%，动态调节窗口为历史60分钟。
• 调度器安全垫建议保留两个空闲大块，水位轮询间隔建议2秒。
• 任务并发度从4开始调，稳定后逐步增加，观察OOM率是否上升。

6.2 关键配置参数速查表

6.3 常见问题与对策对照表

每次上线新模型或者调整模型版本，我都会先在测试环境跑一遍“稳定性压测”，模拟长时间高频任务混跑的场景，观察显存池的分配曲线有没有异常波动。相比功能正确性，批量生成系统更看重的是长时间运行的稳定性——一次OOM导致全网任务堆积，代价远高于单次任务速度慢一点。显存池化和并发调度的全部意义，就是让你能在长时间、高并发的前提下，保持稳定、可控、有预测性的输出节奏。