做AI视频生成的人早早晚晚都会撞上同一个问题显卡怎么又不够了。我在群里见过太多类似场景——有人拿4090跑ComfyUI里的图片模型已经挺顺一换到视频模型就直接OOM有人纠结到底该买4090还是咬牙上A100还有人问双GPU是不是能当一张大显存卡来用。这些问题背后其实是同一个逻辑AI视频模型的GPU消耗逻辑和图片模型、语言模型都不一样按照老经验选算力必然翻车。今天这篇就把两件事拆开讲透视频模型到底把GPU算力和显存吃在了哪里以及真正部署时该怎么一步步选算力。1. 视频模型吃显存的三座大山时序、注意力和3D VAE1.1 你以为的多几十帧实际是多两个数量级大部分人最开始的直觉是视频不就是一堆图片吗图片生成一张要那么多显存视频生成72帧也就是72倍吧。这个直觉错得很离谱。先说输入数据量。一张1280×720的RGB图片FP16精度下大概是1280×720×3通道×2字节约5.5MB。一段3秒24fps的视频就是72帧数据量确实就是图片的72倍约400MB。但问题在于模型从拿到输入到输出结果中间生成的特征图远比原始数据大而且是逐层保留的。现在主流视频生成模型走的是Diffusion Transformer路线把视频切patch变成token序列。每个patch在多层Transformer里都会被展开成高维向量中间激活值activation一路保存到推理结束。视频模型吃显存的大头从来不是那几十MB的原始视频文件而是这些动辄几十GB的中间张量。我可以用一个更直观的对比跑一张512分辨率图片DiT模型的token量大概在几千到一万跑一段512分辨率的16帧视频即使经过3D VAE压缩token量也会涨到两三万甚至更高。token量翻了三四倍Transformer每一层的QKV矩阵计算和KV缓存也跟着涨最终显存占用不是3倍而是接近一个数量级地往上跳。1.2 时间注意力带来的二次方膨胀视频模型为什么不能简单地把图片模型对每一帧单独跑一遍因为那样生成的视频每一帧可能都很精美但连起来看会发现人物跳变、背景闪烁根本没有时序连贯性。为了解决这个问题现在的视频架构普遍引入时间注意力temporal attention或者3D自注意力把整个视频的token放到一起计算。自注意力机制的复杂度是O(n²·d)n是token数d是隐藏维度。token翻三倍时注意力矩阵尺寸直接翻九倍这才是视频模型算力消耗猛增的核心原因。我拿实际参数算一笔账假设一段视频经过VAE压缩后还剩N个token隐藏维度是20488个注意力头。注意力分数矩阵的大小大约是N²×8如果N从5000涨到15000注意力矩阵直接从200M膨胀到1.8B级别这还只是单层单样本。这也是为什么所有跑视频模型的推理框架都在强调flash attention——它不是为了炫技而是不这么做显存根本装不下。所以视频生成这种任务在低batch size下其实非常吃显存带宽和容量算力、带宽、显存三样全都拉满。理解了这一点再看市面上那些视频模型动辄标注推荐40GB以上显存就不会觉得奇怪了。1.3 3D VAE是隐藏的显存杀手很多人在部署视频模型时有个误区只看DiT主模型的参数量和权重大小觉得12B模型FP16权重也就24GB一张4090的24GB显存好像能塞下。结果一跑就爆爆的位置还经常不在DiT阶段而在VAE解码阶段。视频模型用的VAE不是普通图片模型的二维VAE而是3D VAE它不仅要压缩空间分辨率还要在时间维度上做压缩。比如把16帧的视频压成16个潜在帧解码时再一步步恢复。解码到最后一层时需要同时输出整段视频的所有帧中间特征图在空间和时间维度上都是完整的这个阶段会形成一个非常高的显存峰值。如果做的是视频生视频或者图生视频前面还要加一个VAE编码流程把输入视频先压缩成潜空间表示。输入视频越长编码过程需要缓存的帧特征就越多显存被进一步推高。我在实际部署中见过太多次DiT跑完了VAE爆了的情况。所以后面选卡时我总会把VAE解码阶段的开销单独估算进去不能只看权重文件大小。2. 先卡显存还是先卡算力选卡前必须先做的一道判断题2.1 一张表看懂主流视频模型的最低显存很多朋友找我问选卡建议第一句话就是我想跑某某模型需要多大显存。这个问题不是不能回答但直接给一个数字没意义因为不同模型、不同分辨率、不同帧数下的显存需求差了十万八千里。下面这张表是我在多个推理后端下实测出来的顺利运行参考值不是官方最低配置注意这和你的采样步数、是否开CFG、是否做CPU offload都有关系模型参数量FP16权重大小典型测试规格实测显存峰值Stable Video Diffusion1.4B约3GB576×102414帧8~12GBOpen-Sora 2.02B约4GB512×51216帧8~16GBCogVideoX-5B5B约10GB720×48049帧16~20GBMochi 110B约20GB480p5秒24~40GBHunyuanVideo 13B13B约26GB720p5秒40GB以上Wan 2.1 14B14B约28GB720p5秒45GB以上注意看HunyuanVideo权重26GB但实测跑720p需要40GB以上显存中间多出来的十几GB就是激活值、KV Cache和VAE解码开销。很多人只看权重文件大小觉得自己24GB的4090怎么着也能跑26GB的模型结果连加载都费劲。2.2 精度和采样步数参数一改算力需求翻倍选卡时还要考虑一个变量你打算用什么精度跑、采样多少步。这两个参数对显存和算力的影响比想象中大得多。先说精度。FP16下权重2字节/参数FP8变成1字节/参数INT4再减半。比如CogVideoX-5BFP16权重10GBFP8约5GBINT4约2.5GB。对于24GB显存来说能不能量化常常是能不能跑的生死线。但我要提醒一句视频模型对量化的容忍度比语言模型低。LLM量化后最多是回答质量下降视频模型量化激进的话会出现画质劣化、画面闪烁、运动鬼影。我个人经验是优先试FP8画质OK就停在FP8不要一上来就冲INT4省下的那点显存远不够补偿花在排查画面问题上的时间。再说采样步数。视频DiT每采样一步就是一次完整的模型前向传播。20步和50步算力消耗差了2.5倍。如果还开了CFG扩散引导每一步要同时跑两个样本显存和计算量几乎再翻一倍。很多人买到高性能卡却觉得速度没上来先检查一下自己的采样步数和CFG配置别急着骂卡不行。2.3 显存不够和算力不够的应对方式完全不同显存不够和算力不够是两种完全不同的问题应对手段也截然不同。显存不够的表现是直接OOM报错信息会把你看懵。解决办法可以是降低分辨率、减帧数、量化、开VAE offload或者直接换更大显存的卡。但如果你卡在24GB显存上再怎么优化也不可能把40GB显存需求的模型流畅跑起来这时候选卡方向就是48GB或80GB产品。算力不够的表现则是能跑但慢到怀疑人生。一段5秒视频生成要40分钟你等不起。这种情况优化手段是换更高算力的卡、降低采样步数、优化后端或者上多卡做并行。判断自己卡在哪一步最简单的办法是用nvidia-smi监控生成过程中的显存和SM利用率。如果是显存一直顶在99%附近属于显存不够如果显存还有不少余量但SM利用率很高、生成很慢属于纯算力不够。我后面会专门讲怎么抓这些数据。3. 选卡的核心三要素显存容量、显存带宽、并行通信3.1 显存带宽为什么比核心数更影响视频模型体验大多数人选显卡只看两个数显存大小和算力TOPS。但在视频模型推理这件事上第三个指标——显存带宽——往往才是最影响体验的那个。原理其实不复杂。视频生成的batch size通常只能是1因为一条视频就能把显存塞得很满。在batch size1的情况下Transformer的权重搬运和激活读写占了大量时间整个推理过程是偏memory-bound的。显存带宽高意味着同样的权重和激活能在更短时间里被读完生成速度直接受益。我直接给几块主流卡的数据GPU显存容量显存带宽适合场景RTX 409024GB1018 GB/s个人折腾、小分辨率视频RTX 6000 Ada48GB960 GB/s大显存但预算有限L40S48GB864 GB/s服务化部署的性价比卡A100 80G80GB2039 GB/s超大模型、多卡并行H100 80G80GB3350 GB/s高并发生产环境我自己实测过同样跑HunyuanVideoA100 80G和L40S 48G都不开offloadA100在一定步数下能比L40S快接近一半核心差距就在带宽。很多人迷信L40S的48GB大显存觉得比4090的24GB强多了但真跑视频任务时L40S带宽反而比4090低一点部分小分辨率场景下速度没有想象中那么碾压。3.2 单卡、双卡、多卡三种并行方式和视频模型的匹配度确认需要多大的显存之后下一个问题就是一张卡不够的话能不能用两张卡拼起来这个问题得掰开揉碎讲因为并行不是简单地一张卡装不下就拆到两张卡。目前多卡推理主要有三种并行方式张量并行Tensor Parallelism把同一层的权重按维度切到多张卡上大家一起算一层再通信合并。这是大模型多卡推理最常用的方式但对卡间通信带宽要求极高。如果两张4090只走PCIe连接没有NVLink做张量并行可能因为通信开销导致速度不升反降。流水线并行Pipeline Parallelism把模型的不同层分到不同卡上第一张卡算完一层把结果传给第二张卡。这种方式的通信压力小一些但卡之间有明显的阶段依赖空闲窗口比较大。模块拆分Pipeline Offload / Heterogeneous把文本编码器、DiT主模型、VAE解码器分别放到不同卡上。这个方式在视频模型场景下特别实用也是很多人说的视频模型双GPU方案的真实价值所在。数据并行Data Parallelism每张卡上放一份完整模型并行处理不同请求。这种方式不解决单条视频显存不够的问题但能提升整体吞吐服务化部署常用。3.3 双GPU的正确用法模块拆分而非简单拼算力现在常有人问双GPU跑视频模型是不是等于显存翻倍答案是不能直接等号。视频模型和LLM不太一样它没有那种天然支持跨卡张量并行的成熟生态你如果只是把模型平均切到两张卡上通信开销可能直接把收益吃掉。真正实用的是模块拆分。我自己的经验是把DiT主模型放在主卡上把VAE和文本编码器丢给副卡。这样DiT阶段和VAE解码阶段各自拥有完整的显存空间总的峰值需求被摊薄而且两卡之间的数据交换只在关键节点发生通信压力小得多。在ComfyUI这类工具里已经有显存管理方案能实现这种调度把不同模块分配到不同GPU设备。如果你打算做视频生成服务这个方案比无脑上NVLink双卡跑张量并行要划算得多。从成本角度看两张409024GB×2或者一张4090加一张309024GB实际可用显存范围接近40GB级别能覆盖不少中大型视频模型成本却只有一张A100的几分之一。但前提是你必须把模块拆分做好否则双卡只是花了两份钱跑出和单卡一样的速度。3.4 GPU实例化这回事视频模型最好别切成小实例有些平台提供vGPU、MIG这类GPU实例化方案能把一块大卡切成好几个小逻辑卡。这里要先搞清楚实例化减少的到底是什么它减少的是你单实例可用的显存配额和算力上限换来的是更好的隔离性和更灵活的按需分配。对LLM部署来说实例化是好事因为你可以把一个80GB的A100切成4个20GB实例跑4个7B的小模型互不干扰。但对视频模型来说我基本不建议开小实例。原因就是前面讲过的视频生成需要大块连续的显存空间尤其在VAE解码阶段。你切出来的每个小实例显存都不够反而把整卡跑大模型的灵活性给砍没了。如果平台能按整卡租优先整卡实在需要共享算力也一定要确认实例的显存上限能覆盖你模型的最大峰值需求。4. 部署前实测用数据决定买卡还是租卡4.1 上线前必做的三类压测不管你已经有了卡还是准备租卡我强烈建议先做一轮完整的基准测试再决定下一步。很多人跳过了这一步结果业务上线第二天才发现显卡选错了后面返工成本极高。我的建议是至少做三组压测第一组是固定模型和步数测不同分辨率下的显存和延迟。比如512×512、768×768、1280×720分别跑一遍记录峰值显存和单条视频耗时。第二组是固定分辨率和模型测不同帧数/帧率下的表现。8帧、16帧、32帧分别测看显存和时延如何随帧数变化。第三组是测并发。如果是做服务化部署用任务队列同时提交2个、3个、5个任务测排队时间和吞吐量。执行这些测试时我一般直接用nvidia-smi的周期性采样nvidia-smi --query-gpuindex,timestamp,utilization.gpu,memory.used,power.draw,temperature.gpu --formatcsv -l 1 gpu_metrics.csv这个命令每秒记录一次显存使用、GPU利用率、功耗和温度。生成任务跑完后打开CSV看一下显存曲线的峰值和持续时间就能准确判断瓶颈在哪。4.2 显存曲线和延迟数据怎么解读拿我之前实测的某个开源视频模型在4090上的数据举个例子测试规格显存峰值24步采样耗时结果512×5128帧12GB61秒顺畅运行512×51216帧17GB118秒接近显存边界1280×72016帧24GB直接OOM跑不了这组数据传达的信息量很大。首先同样的模型和分辨率帧数翻倍显存增长不是线性而是超线性的因为时间注意力是二次方复杂度。其次720p对4090来说是明显分水岭不是靠换来卡能解决的必须换48GB或80GB以上显存的型号。这种曲线对你业务的意义是如果你打算对用户开放720p视频生成4090单卡方案根本接不住选型时直接排除如果你只做短视频且能限制分辨率4090反而够用把预算花在别处更合理。我个人的习惯是把这些测试数据固化成一个简单的评估报告包含显存峰值、平均SM利用率、平均功耗、单任务时延、并发能力五个核心指标。拿着这份报告无论是向公司申请预算还是去租赁平台选配置都有理有据。4.3 小卡跑大模型的现实路径量化、offload与显存复用如果你的卡实在不够但又必须跑某个超显存模型还有几条现实路径可以凑合一下但你要清楚代价。第一种是量化。把FP16模型量化成FP8或INT4权重直接减半甚至减到四分之一。我在前面提过视频模型对量化比较敏感建议最多量化到FP8跑通了再对比画面质量。第二种是CPU offload把模型权重的一部分放到内存里计算时再换进显存。这个方法能让你用24GB显存去跑40GB需求的模型但速度会断崖式下降。我自己测过开offload之后HunyuanVideo的生成时间能从A100上的4分钟涨到30分钟以上差了接近8倍。这种方案只适合个人玩家慢慢折腾不适合任何面向用户的业务。第三种是显存复用调整推理框架的缓存策略把文本编码器、VAE这些非核心模块在不用时及时卸载。很多工具其实默认不会激进清理显存你手动调整一下调度策略很可能就把峰值需求压下来了。ComfyUI里的模型管理设置把VAE和文本编码器的加载/卸载策略改成功后释放能省出不少空间。这三种方法不是互相排斥的实际部署时我经常组合使用FP8量化加VAE及时卸载能把峰值显存压低30%到40%同时速度损失可控。5. 成本测算和运维租卡还是自购的平衡点5.1 把业务量折算成算力需求再反推卡数很多团队买卡的时候只问哪张卡最强这是典型的思路错误。正确的做法是先算清楚业务需要多少算力再倒推需要什么卡。具体算下来并不复杂。首先明确你的业务性质是给用户文生视频、图生视频还是视频编辑每条任务大概多少帧、什么分辨率拿你压测得到的单卡单任务耗时再估算一个高峰期同时会有多少个任务在排队。举个例子假设你用A100跑一条720p 5秒的视频实测需要5分钟。业务上要求高峰期同时支持3个任务并发处理那至少需要3张A100。如果你能接受排队那2张卡也能跑但用户体验会打折扣。如果想让估得更细还可以把自己的任务量折算成token消耗。一个视频任务的token量大约就是视频token数乘以采样步数再乘以模型层数虽然没有精确标准但用来横向对比不同模型和不同方案的成本差异足够用了。我自己做需求评估时会把过去一个月的任务日志拉出来统计每类任务的平均耗时和峰值并发然后直接套用压测数据算出需要的总卡时数再去对照租赁报价或采购预算。5.2 租用的灵活性和自购的持有成本算清楚算力需求后剩下来的问题就是这些卡是租还是买。租赁的核心优势是灵活。视频模型迭代快你会发现半年前买的旗舰卡在新模型面前可能就变成了显存够但带宽不够的尴尬存在。用类似共绩这类算力租赁平台按小时租卡项目验证阶段、流量波动大的阶段会很香你可以随时切换不同配置的显卡不用承担硬件折旧风险。自购的核心优势是单位成本低适合长期稳定跑量的业务。但光看卡价是不够的要把电费、机柜、散热、驱动运维、故障替换全算进去。我见过不少团队买了8张卡最后发现机房电费比预期高好几倍一张卡风扇坏了返修半个月导致整个集群瘫痪。GPU服务器运维不只是装个驱动那么简单多卡通信故障、显存温度过高、CUDA版本不匹配都是日常问题。我的经验是分两个阶段走项目验证期用租赁平台跑通流程、拿到真实压测数据后再决定要不要自购自购也只买稳定服役一年以上的型号避免追新卡当小白鼠。5.3 多台算力服务器和算力池的管理经验如果最终选择了自购多台服务器下一步就是解决算力调度问题。我的经验是不要急着上复杂的集群调度系统先把最基本的两件事做好。第一统一监控。所有服务器的GPU状态要能汇总到一个面板上我通常用Prometheus加Grafana或者自写一个定时采集脚本把每台卡的显存、利用率、温度、功耗聚合起来。这样哪张卡在空转、哪张卡温度异常一眼就能看出来。第二任务调度。任务队列要绑定GPU资源需求。单卡任务可以调度到任意一张余量充足的卡上多卡任务则必须检查目标机器上多卡之间的通信拓扑是NVLink还是PCIe直连再决定要不要分配给它。模型权重建议放在共享存储上运行时拉到本地缓存不要让每台机器各自存一份否则版本管理会变成事故现场。这些工作看起来琐碎但恰恰是视频模型服务能不能稳定跑下去的关键。很多人买完卡才发现真正的成本不在于硬件本身而在于把这堆卡稳定、高效地运转起来。说到底AI视频模型比图片和语言模型更吃GPU不是某个厂商的营销话术而是由它的架构决定的token多、注意力二次方膨胀、3D VAE峰值高、低batch size下又重度依赖显存带宽。选算力之前先把你自己的模型、分辨率、帧数、并发这些变量全部列出来做一轮实测让数据告诉你该买什么卡、租多少卡这才是最靠谱的路径。我自己在给团队做技术方案时也始终坚持这个顺序先拿目标模型在候选卡上跑基准测试再谈采购最后才谈成本优化。这套方法帮你避开的坑远比一张参数表值钱。
AI视频生成GPU选卡指南：显存、带宽与部署策略
做AI视频生成的人早早晚晚都会撞上同一个问题显卡怎么又不够了。我在群里见过太多类似场景——有人拿4090跑ComfyUI里的图片模型已经挺顺一换到视频模型就直接OOM有人纠结到底该买4090还是咬牙上A100还有人问双GPU是不是能当一张大显存卡来用。这些问题背后其实是同一个逻辑AI视频模型的GPU消耗逻辑和图片模型、语言模型都不一样按照老经验选算力必然翻车。今天这篇就把两件事拆开讲透视频模型到底把GPU算力和显存吃在了哪里以及真正部署时该怎么一步步选算力。1. 视频模型吃显存的三座大山时序、注意力和3D VAE1.1 你以为的多几十帧实际是多两个数量级大部分人最开始的直觉是视频不就是一堆图片吗图片生成一张要那么多显存视频生成72帧也就是72倍吧。这个直觉错得很离谱。先说输入数据量。一张1280×720的RGB图片FP16精度下大概是1280×720×3通道×2字节约5.5MB。一段3秒24fps的视频就是72帧数据量确实就是图片的72倍约400MB。但问题在于模型从拿到输入到输出结果中间生成的特征图远比原始数据大而且是逐层保留的。现在主流视频生成模型走的是Diffusion Transformer路线把视频切patch变成token序列。每个patch在多层Transformer里都会被展开成高维向量中间激活值activation一路保存到推理结束。视频模型吃显存的大头从来不是那几十MB的原始视频文件而是这些动辄几十GB的中间张量。我可以用一个更直观的对比跑一张512分辨率图片DiT模型的token量大概在几千到一万跑一段512分辨率的16帧视频即使经过3D VAE压缩token量也会涨到两三万甚至更高。token量翻了三四倍Transformer每一层的QKV矩阵计算和KV缓存也跟着涨最终显存占用不是3倍而是接近一个数量级地往上跳。1.2 时间注意力带来的二次方膨胀视频模型为什么不能简单地把图片模型对每一帧单独跑一遍因为那样生成的视频每一帧可能都很精美但连起来看会发现人物跳变、背景闪烁根本没有时序连贯性。为了解决这个问题现在的视频架构普遍引入时间注意力temporal attention或者3D自注意力把整个视频的token放到一起计算。自注意力机制的复杂度是O(n²·d)n是token数d是隐藏维度。token翻三倍时注意力矩阵尺寸直接翻九倍这才是视频模型算力消耗猛增的核心原因。我拿实际参数算一笔账假设一段视频经过VAE压缩后还剩N个token隐藏维度是20488个注意力头。注意力分数矩阵的大小大约是N²×8如果N从5000涨到15000注意力矩阵直接从200M膨胀到1.8B级别这还只是单层单样本。这也是为什么所有跑视频模型的推理框架都在强调flash attention——它不是为了炫技而是不这么做显存根本装不下。所以视频生成这种任务在低batch size下其实非常吃显存带宽和容量算力、带宽、显存三样全都拉满。理解了这一点再看市面上那些视频模型动辄标注推荐40GB以上显存就不会觉得奇怪了。1.3 3D VAE是隐藏的显存杀手很多人在部署视频模型时有个误区只看DiT主模型的参数量和权重大小觉得12B模型FP16权重也就24GB一张4090的24GB显存好像能塞下。结果一跑就爆爆的位置还经常不在DiT阶段而在VAE解码阶段。视频模型用的VAE不是普通图片模型的二维VAE而是3D VAE它不仅要压缩空间分辨率还要在时间维度上做压缩。比如把16帧的视频压成16个潜在帧解码时再一步步恢复。解码到最后一层时需要同时输出整段视频的所有帧中间特征图在空间和时间维度上都是完整的这个阶段会形成一个非常高的显存峰值。如果做的是视频生视频或者图生视频前面还要加一个VAE编码流程把输入视频先压缩成潜空间表示。输入视频越长编码过程需要缓存的帧特征就越多显存被进一步推高。我在实际部署中见过太多次DiT跑完了VAE爆了的情况。所以后面选卡时我总会把VAE解码阶段的开销单独估算进去不能只看权重文件大小。2. 先卡显存还是先卡算力选卡前必须先做的一道判断题2.1 一张表看懂主流视频模型的最低显存很多朋友找我问选卡建议第一句话就是我想跑某某模型需要多大显存。这个问题不是不能回答但直接给一个数字没意义因为不同模型、不同分辨率、不同帧数下的显存需求差了十万八千里。下面这张表是我在多个推理后端下实测出来的顺利运行参考值不是官方最低配置注意这和你的采样步数、是否开CFG、是否做CPU offload都有关系模型参数量FP16权重大小典型测试规格实测显存峰值Stable Video Diffusion1.4B约3GB576×102414帧8~12GBOpen-Sora 2.02B约4GB512×51216帧8~16GBCogVideoX-5B5B约10GB720×48049帧16~20GBMochi 110B约20GB480p5秒24~40GBHunyuanVideo 13B13B约26GB720p5秒40GB以上Wan 2.1 14B14B约28GB720p5秒45GB以上注意看HunyuanVideo权重26GB但实测跑720p需要40GB以上显存中间多出来的十几GB就是激活值、KV Cache和VAE解码开销。很多人只看权重文件大小觉得自己24GB的4090怎么着也能跑26GB的模型结果连加载都费劲。2.2 精度和采样步数参数一改算力需求翻倍选卡时还要考虑一个变量你打算用什么精度跑、采样多少步。这两个参数对显存和算力的影响比想象中大得多。先说精度。FP16下权重2字节/参数FP8变成1字节/参数INT4再减半。比如CogVideoX-5BFP16权重10GBFP8约5GBINT4约2.5GB。对于24GB显存来说能不能量化常常是能不能跑的生死线。但我要提醒一句视频模型对量化的容忍度比语言模型低。LLM量化后最多是回答质量下降视频模型量化激进的话会出现画质劣化、画面闪烁、运动鬼影。我个人经验是优先试FP8画质OK就停在FP8不要一上来就冲INT4省下的那点显存远不够补偿花在排查画面问题上的时间。再说采样步数。视频DiT每采样一步就是一次完整的模型前向传播。20步和50步算力消耗差了2.5倍。如果还开了CFG扩散引导每一步要同时跑两个样本显存和计算量几乎再翻一倍。很多人买到高性能卡却觉得速度没上来先检查一下自己的采样步数和CFG配置别急着骂卡不行。2.3 显存不够和算力不够的应对方式完全不同显存不够和算力不够是两种完全不同的问题应对手段也截然不同。显存不够的表现是直接OOM报错信息会把你看懵。解决办法可以是降低分辨率、减帧数、量化、开VAE offload或者直接换更大显存的卡。但如果你卡在24GB显存上再怎么优化也不可能把40GB显存需求的模型流畅跑起来这时候选卡方向就是48GB或80GB产品。算力不够的表现则是能跑但慢到怀疑人生。一段5秒视频生成要40分钟你等不起。这种情况优化手段是换更高算力的卡、降低采样步数、优化后端或者上多卡做并行。判断自己卡在哪一步最简单的办法是用nvidia-smi监控生成过程中的显存和SM利用率。如果是显存一直顶在99%附近属于显存不够如果显存还有不少余量但SM利用率很高、生成很慢属于纯算力不够。我后面会专门讲怎么抓这些数据。3. 选卡的核心三要素显存容量、显存带宽、并行通信3.1 显存带宽为什么比核心数更影响视频模型体验大多数人选显卡只看两个数显存大小和算力TOPS。但在视频模型推理这件事上第三个指标——显存带宽——往往才是最影响体验的那个。原理其实不复杂。视频生成的batch size通常只能是1因为一条视频就能把显存塞得很满。在batch size1的情况下Transformer的权重搬运和激活读写占了大量时间整个推理过程是偏memory-bound的。显存带宽高意味着同样的权重和激活能在更短时间里被读完生成速度直接受益。我直接给几块主流卡的数据GPU显存容量显存带宽适合场景RTX 409024GB1018 GB/s个人折腾、小分辨率视频RTX 6000 Ada48GB960 GB/s大显存但预算有限L40S48GB864 GB/s服务化部署的性价比卡A100 80G80GB2039 GB/s超大模型、多卡并行H100 80G80GB3350 GB/s高并发生产环境我自己实测过同样跑HunyuanVideoA100 80G和L40S 48G都不开offloadA100在一定步数下能比L40S快接近一半核心差距就在带宽。很多人迷信L40S的48GB大显存觉得比4090的24GB强多了但真跑视频任务时L40S带宽反而比4090低一点部分小分辨率场景下速度没有想象中那么碾压。3.2 单卡、双卡、多卡三种并行方式和视频模型的匹配度确认需要多大的显存之后下一个问题就是一张卡不够的话能不能用两张卡拼起来这个问题得掰开揉碎讲因为并行不是简单地一张卡装不下就拆到两张卡。目前多卡推理主要有三种并行方式张量并行Tensor Parallelism把同一层的权重按维度切到多张卡上大家一起算一层再通信合并。这是大模型多卡推理最常用的方式但对卡间通信带宽要求极高。如果两张4090只走PCIe连接没有NVLink做张量并行可能因为通信开销导致速度不升反降。流水线并行Pipeline Parallelism把模型的不同层分到不同卡上第一张卡算完一层把结果传给第二张卡。这种方式的通信压力小一些但卡之间有明显的阶段依赖空闲窗口比较大。模块拆分Pipeline Offload / Heterogeneous把文本编码器、DiT主模型、VAE解码器分别放到不同卡上。这个方式在视频模型场景下特别实用也是很多人说的视频模型双GPU方案的真实价值所在。数据并行Data Parallelism每张卡上放一份完整模型并行处理不同请求。这种方式不解决单条视频显存不够的问题但能提升整体吞吐服务化部署常用。3.3 双GPU的正确用法模块拆分而非简单拼算力现在常有人问双GPU跑视频模型是不是等于显存翻倍答案是不能直接等号。视频模型和LLM不太一样它没有那种天然支持跨卡张量并行的成熟生态你如果只是把模型平均切到两张卡上通信开销可能直接把收益吃掉。真正实用的是模块拆分。我自己的经验是把DiT主模型放在主卡上把VAE和文本编码器丢给副卡。这样DiT阶段和VAE解码阶段各自拥有完整的显存空间总的峰值需求被摊薄而且两卡之间的数据交换只在关键节点发生通信压力小得多。在ComfyUI这类工具里已经有显存管理方案能实现这种调度把不同模块分配到不同GPU设备。如果你打算做视频生成服务这个方案比无脑上NVLink双卡跑张量并行要划算得多。从成本角度看两张409024GB×2或者一张4090加一张309024GB实际可用显存范围接近40GB级别能覆盖不少中大型视频模型成本却只有一张A100的几分之一。但前提是你必须把模块拆分做好否则双卡只是花了两份钱跑出和单卡一样的速度。3.4 GPU实例化这回事视频模型最好别切成小实例有些平台提供vGPU、MIG这类GPU实例化方案能把一块大卡切成好几个小逻辑卡。这里要先搞清楚实例化减少的到底是什么它减少的是你单实例可用的显存配额和算力上限换来的是更好的隔离性和更灵活的按需分配。对LLM部署来说实例化是好事因为你可以把一个80GB的A100切成4个20GB实例跑4个7B的小模型互不干扰。但对视频模型来说我基本不建议开小实例。原因就是前面讲过的视频生成需要大块连续的显存空间尤其在VAE解码阶段。你切出来的每个小实例显存都不够反而把整卡跑大模型的灵活性给砍没了。如果平台能按整卡租优先整卡实在需要共享算力也一定要确认实例的显存上限能覆盖你模型的最大峰值需求。4. 部署前实测用数据决定买卡还是租卡4.1 上线前必做的三类压测不管你已经有了卡还是准备租卡我强烈建议先做一轮完整的基准测试再决定下一步。很多人跳过了这一步结果业务上线第二天才发现显卡选错了后面返工成本极高。我的建议是至少做三组压测第一组是固定模型和步数测不同分辨率下的显存和延迟。比如512×512、768×768、1280×720分别跑一遍记录峰值显存和单条视频耗时。第二组是固定分辨率和模型测不同帧数/帧率下的表现。8帧、16帧、32帧分别测看显存和时延如何随帧数变化。第三组是测并发。如果是做服务化部署用任务队列同时提交2个、3个、5个任务测排队时间和吞吐量。执行这些测试时我一般直接用nvidia-smi的周期性采样nvidia-smi --query-gpuindex,timestamp,utilization.gpu,memory.used,power.draw,temperature.gpu --formatcsv -l 1 gpu_metrics.csv这个命令每秒记录一次显存使用、GPU利用率、功耗和温度。生成任务跑完后打开CSV看一下显存曲线的峰值和持续时间就能准确判断瓶颈在哪。4.2 显存曲线和延迟数据怎么解读拿我之前实测的某个开源视频模型在4090上的数据举个例子测试规格显存峰值24步采样耗时结果512×5128帧12GB61秒顺畅运行512×51216帧17GB118秒接近显存边界1280×72016帧24GB直接OOM跑不了这组数据传达的信息量很大。首先同样的模型和分辨率帧数翻倍显存增长不是线性而是超线性的因为时间注意力是二次方复杂度。其次720p对4090来说是明显分水岭不是靠换来卡能解决的必须换48GB或80GB以上显存的型号。这种曲线对你业务的意义是如果你打算对用户开放720p视频生成4090单卡方案根本接不住选型时直接排除如果你只做短视频且能限制分辨率4090反而够用把预算花在别处更合理。我个人的习惯是把这些测试数据固化成一个简单的评估报告包含显存峰值、平均SM利用率、平均功耗、单任务时延、并发能力五个核心指标。拿着这份报告无论是向公司申请预算还是去租赁平台选配置都有理有据。4.3 小卡跑大模型的现实路径量化、offload与显存复用如果你的卡实在不够但又必须跑某个超显存模型还有几条现实路径可以凑合一下但你要清楚代价。第一种是量化。把FP16模型量化成FP8或INT4权重直接减半甚至减到四分之一。我在前面提过视频模型对量化比较敏感建议最多量化到FP8跑通了再对比画面质量。第二种是CPU offload把模型权重的一部分放到内存里计算时再换进显存。这个方法能让你用24GB显存去跑40GB需求的模型但速度会断崖式下降。我自己测过开offload之后HunyuanVideo的生成时间能从A100上的4分钟涨到30分钟以上差了接近8倍。这种方案只适合个人玩家慢慢折腾不适合任何面向用户的业务。第三种是显存复用调整推理框架的缓存策略把文本编码器、VAE这些非核心模块在不用时及时卸载。很多工具其实默认不会激进清理显存你手动调整一下调度策略很可能就把峰值需求压下来了。ComfyUI里的模型管理设置把VAE和文本编码器的加载/卸载策略改成功后释放能省出不少空间。这三种方法不是互相排斥的实际部署时我经常组合使用FP8量化加VAE及时卸载能把峰值显存压低30%到40%同时速度损失可控。5. 成本测算和运维租卡还是自购的平衡点5.1 把业务量折算成算力需求再反推卡数很多团队买卡的时候只问哪张卡最强这是典型的思路错误。正确的做法是先算清楚业务需要多少算力再倒推需要什么卡。具体算下来并不复杂。首先明确你的业务性质是给用户文生视频、图生视频还是视频编辑每条任务大概多少帧、什么分辨率拿你压测得到的单卡单任务耗时再估算一个高峰期同时会有多少个任务在排队。举个例子假设你用A100跑一条720p 5秒的视频实测需要5分钟。业务上要求高峰期同时支持3个任务并发处理那至少需要3张A100。如果你能接受排队那2张卡也能跑但用户体验会打折扣。如果想让估得更细还可以把自己的任务量折算成token消耗。一个视频任务的token量大约就是视频token数乘以采样步数再乘以模型层数虽然没有精确标准但用来横向对比不同模型和不同方案的成本差异足够用了。我自己做需求评估时会把过去一个月的任务日志拉出来统计每类任务的平均耗时和峰值并发然后直接套用压测数据算出需要的总卡时数再去对照租赁报价或采购预算。5.2 租用的灵活性和自购的持有成本算清楚算力需求后剩下来的问题就是这些卡是租还是买。租赁的核心优势是灵活。视频模型迭代快你会发现半年前买的旗舰卡在新模型面前可能就变成了显存够但带宽不够的尴尬存在。用类似共绩这类算力租赁平台按小时租卡项目验证阶段、流量波动大的阶段会很香你可以随时切换不同配置的显卡不用承担硬件折旧风险。自购的核心优势是单位成本低适合长期稳定跑量的业务。但光看卡价是不够的要把电费、机柜、散热、驱动运维、故障替换全算进去。我见过不少团队买了8张卡最后发现机房电费比预期高好几倍一张卡风扇坏了返修半个月导致整个集群瘫痪。GPU服务器运维不只是装个驱动那么简单多卡通信故障、显存温度过高、CUDA版本不匹配都是日常问题。我的经验是分两个阶段走项目验证期用租赁平台跑通流程、拿到真实压测数据后再决定要不要自购自购也只买稳定服役一年以上的型号避免追新卡当小白鼠。5.3 多台算力服务器和算力池的管理经验如果最终选择了自购多台服务器下一步就是解决算力调度问题。我的经验是不要急着上复杂的集群调度系统先把最基本的两件事做好。第一统一监控。所有服务器的GPU状态要能汇总到一个面板上我通常用Prometheus加Grafana或者自写一个定时采集脚本把每台卡的显存、利用率、温度、功耗聚合起来。这样哪张卡在空转、哪张卡温度异常一眼就能看出来。第二任务调度。任务队列要绑定GPU资源需求。单卡任务可以调度到任意一张余量充足的卡上多卡任务则必须检查目标机器上多卡之间的通信拓扑是NVLink还是PCIe直连再决定要不要分配给它。模型权重建议放在共享存储上运行时拉到本地缓存不要让每台机器各自存一份否则版本管理会变成事故现场。这些工作看起来琐碎但恰恰是视频模型服务能不能稳定跑下去的关键。很多人买完卡才发现真正的成本不在于硬件本身而在于把这堆卡稳定、高效地运转起来。说到底AI视频模型比图片和语言模型更吃GPU不是某个厂商的营销话术而是由它的架构决定的token多、注意力二次方膨胀、3D VAE峰值高、低batch size下又重度依赖显存带宽。选算力之前先把你自己的模型、分辨率、帧数、并发这些变量全部列出来做一轮实测让数据告诉你该买什么卡、租多少卡这才是最靠谱的路径。我自己在给团队做技术方案时也始终坚持这个顺序先拿目标模型在候选卡上跑基准测试再谈采购最后才谈成本优化。这套方法帮你避开的坑远比一张参数表值钱。
