做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(n2·d)n是token數d是隱藏維度。token翻三倍時注意力矩陣尺寸直接翻九倍這才是視頻模型算力消耗猛增的核心原因。我拿實際參數算一筆賬假設一段視頻經過VAE壓縮后還剩N個token隱藏維度是20488個注意力頭。注意力分數矩陣的大小大約是N2×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下又重度依賴顯存帶寬。選算力之前先把你自己的模型、分辨率、幀數、并發這些變量全部列出來做一輪實測讓數據告訴你該買什么卡、租多少卡這才是最靠譜的路徑。我自己在給團隊做技術方案時也始終堅持這個順序先拿目標模型在候選卡上跑基準測試再談采購最后才談成本優化。這套方法幫你避開的坑遠比一張參數表值錢。