企业官网建设流程全解析

做AI视频生成的人，早早晚晚都会撞上同一个问题：显卡怎么又不够了。我在群里见过太多类似场景——有人拿4090跑ComfyUI里的图片模型已经挺顺，一换到视频模型就直接OOM；有人纠结到底该买4090还是咬牙上A100；还有人问双GPU是不是能当一张大显存卡来用。这些问题背后其实是同一个逻辑：AI视频模型的GPU消耗逻辑和图片模型、语言模型都不一样，按照老经验选算力必然翻车。今天这篇就把两件事拆开讲透：视频模型到底把GPU算力和显存吃在了哪里，以及真正部署时该怎么一步步选算力。

1. 视频模型吃显存的三座大山：时序、注意力和3D VAE

1.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，隐藏维度是2048，8个注意力头。注意力分数矩阵的大小大约是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都有关系：

注意看，HunyuanVideo权重26GB，但实测跑720p需要40GB以上显存，中间多出来的十几GB就是激活值、KV Cache和VAE解码开销。很多人只看权重文件大小，觉得自己24GB的4090怎么着也能跑26GB的模型，结果连加载都费劲。

2.2 精度和采样步数：参数一改，算力需求翻倍

选卡时还要考虑一个变量：你打算用什么精度跑、采样多少步。这两个参数对显存和算力的影响比想象中大得多。

先说精度。FP16下权重2字节/参数，FP8变成1字节/参数，INT4再减半。比如CogVideoX-5B，FP16权重10GB，FP8约5GB，INT4约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 size=1的情况下，Transformer的权重搬运和激活读写占了大量时间，整个推理过程是偏memory-bound的。显存带宽高，意味着同样的权重和激活能在更短时间里被读完，生成速度直接受益。

我直接给几块主流卡的数据：

我自己实测过同样跑HunyuanVideo，A100 80G和L40S 48G都不开offload，A100在一定步数下能比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双卡跑张量并行要划算得多。

从成本角度看，两张4090（24GB×2）或者一张4090加一张3090（24GB），实际可用显存范围接近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-gpu=index,timestamp,utilization.gpu,memory.used,power.draw,temperature.gpu --format=csv -l 1 > gpu_metrics.csv

这个命令每秒记录一次显存使用、GPU利用率、功耗和温度。生成任务跑完后，打开CSV看一下显存曲线的峰值和持续时间，就能准确判断瓶颈在哪。

4.2 显存曲线和延迟数据怎么解读

拿我之前实测的某个开源视频模型在4090上的数据举个例子：

这组数据传达的信息量很大。首先，同样的模型和分辨率，帧数翻倍，显存增长不是线性而是超线性的，因为时间注意力是二次方复杂度。其次，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下又重度依赖显存带宽。选算力之前，先把你自己的模型、分辨率、帧数、并发这些变量全部列出来，做一轮实测，让数据告诉你该买什么卡、租多少卡，这才是最靠谱的路径。我自己在给团队做技术方案时也始终坚持这个顺序：先拿目标模型在候选卡上跑基准测试，再谈采购，最后才谈成本优化。这套方法帮你避开的坑，远比一张参数表值钱。