最近AI視頻圈最熱的話題就是H3這個(gè)開(kāi)源視頻生成模型。單張RTX 5090跑視頻生成號(hào)稱15秒出一個(gè)短視頻我拿到卡之后第一件事就是把這個(gè)模型復(fù)現(xiàn)出來(lái)。這篇文章不是官方教程是我從零開(kāi)始部署H3的完整實(shí)測(cè)記錄包含環(huán)境安裝、參數(shù)調(diào)整和踩坑過(guò)程。如果你手上正好有32GB顯存的旗艦卡想本地生成短視頻這篇應(yīng)該能幫你省下不少折騰時(shí)間。1. H3的“15秒”是生成耗時(shí)不是視頻時(shí)長(zhǎng)先拆穿再談架構(gòu)1.1 拿到卡之后的第一件事視頻生成以前基本是云端API的玩法本地單卡想跑起來(lái)要么分辨率低得沒(méi)法看要么生成一段幾秒的視頻要等好幾分鐘。H3不一樣它把“拍短視頻”變成了接近“打字”的交互體驗(yàn)輸入一句提示詞十幾秒之后就得到一段像樣的動(dòng)態(tài)畫(huà)面。但標(biāo)題里的“15秒出視頻”需要拆開(kāi)看H3生成的并不是15秒長(zhǎng)的視頻。它指的是“生成一段2到3秒的短視頻短片耗時(shí)15秒左右”。具體一點(diǎn)我用720×480分辨率、24幀、20步采樣實(shí)測(cè)生成一段兩秒多的視頻大約16到20秒把采樣步數(shù)降到12步時(shí)間能壓到11到13秒如果再狠一點(diǎn)把幀數(shù)降到16幀、分辨率降到640×480跑到10秒以內(nèi)也不是問(wèn)題。這個(gè)前提不弄清楚很多人跑完會(huì)覺(jué)得自己被騙了。所以先記住結(jié)論H3的“15秒”是對(duì)生成耗時(shí)的宣傳不是視頻時(shí)長(zhǎng)。如果你真讓它生成15秒時(shí)長(zhǎng)的視頻那是另一回事實(shí)測(cè)時(shí)間會(huì)長(zhǎng)得多。1.2 架構(gòu)上為什么能做到潛空間擴(kuò)散與時(shí)間維采樣搞清楚速度是怎么來(lái)的比會(huì)敲命令更重要。H3能這么快從架構(gòu)和推理優(yōu)化層面看核心是這么幾件事。首先是潛空間擴(kuò)散。直接在高分辨率像素空間里生成視頻計(jì)算量是災(zāi)難級(jí)的就像讓你用高清打印機(jī)一張張打幾百頁(yè)紙?jiān)傺b訂成動(dòng)畫(huà)。H3的做法是先把畫(huà)面壓縮到低倍率潛空間在這個(gè)“草稿紙”上反復(fù)去噪最后才用視頻VAE解碼成真實(shí)畫(huà)面。潛空間的分辨率比像素空間小幾倍甚至十幾倍計(jì)算量直接降一個(gè)數(shù)量級(jí)。其次是時(shí)間維度的采樣策略。視頻和靜態(tài)圖像不一樣幀與幀之間高度相似相鄰兩幀的畫(huà)面可能只差幾個(gè)像素的運(yùn)動(dòng)。H3沒(méi)有傻乎乎地把每一幀當(dāng)作新圖來(lái)生成而是在時(shí)間維度上做塊采樣先算出關(guān)鍵幀再通過(guò)插值和時(shí)序注意力補(bǔ)齊中間幀這樣總計(jì)算量就不是“幀數(shù)×單幀成本”而是明顯更低的曲線。最后是推理側(cè)的優(yōu)化。很多視頻模型生成時(shí)無(wú)分類器引導(dǎo)需要同時(shí)跑條件生成和負(fù)向生成兩條擴(kuò)散路徑H3對(duì)這種重復(fù)計(jì)算做了緩存復(fù)用采樣循環(huán)里上千個(gè)小算子用CUDA Graphs打包成一張執(zhí)行圖減少了CPU反復(fù)調(diào)度的開(kāi)銷視頻VAE解碼也支持分塊并行避免一次性把整段視頻的中間特征全堆在顯存里。說(shuō)實(shí)話這些原理是我從H3的配置文件和實(shí)測(cè)表現(xiàn)反推出來(lái)的不一定和官方實(shí)現(xiàn)完全一致但方向是對(duì)的。理解這些之后再去看參數(shù)你就能明白為什么“降步數(shù)”“開(kāi)緩存”是提速的頭號(hào)手段。2. 部署環(huán)境驅(qū)動(dòng)、CUDA、權(quán)重一次配好的完整記錄2.1 裝機(jī)清單與版本鎖定很多人在部署H3時(shí)遇到莫名其妙的報(bào)錯(cuò)十有八九是環(huán)境版本沒(méi)對(duì)齊。下面這套組合我這臺(tái)機(jī)器上跑得很穩(wěn)基本可以照抄。組件版本/要求說(shuō)明顯卡RTX 509032GB顯存是硬門(mén)檻16GB卡能跑但別指望速度驅(qū)動(dòng)560及以上老驅(qū)動(dòng)對(duì)Blackwell架構(gòu)支持不完整操作系統(tǒng)Ubuntu 22.04或Windows 11 WSL2Windows原生環(huán)境也行但建議WSL2Python3.10或3.113.12某些依賴編譯容易出問(wèn)題CUDA12.8或12.9PyTorch自帶runtime不用手動(dòng)裝全套PyTorch2.7及以上2.7才開(kāi)始完整支持新卡特性先解釋為什么版本這么敏感。RTX 5090是比較新的GPU架構(gòu)模型推理依賴PyTorch底層調(diào)用圖形API、注意力算子和混合精度庫(kù)這些都要在特定驅(qū)動(dòng)和CUDA版本下才能正常工作。我一開(kāi)始圖省事直接用了舊版驅(qū)動(dòng)配合系統(tǒng)默認(rèn)CUDA結(jié)果模型加載時(shí)直接報(bào)設(shè)備能力不識(shí)別跑什么都提示算子編譯失敗。后來(lái)老老實(shí)實(shí)升到560以上驅(qū)動(dòng)PyTorch也用cu128對(duì)應(yīng)版本一次就過(guò)了。2.2 一步步安裝環(huán)境安裝順序很重要。先裝顯卡驅(qū)動(dòng)再裝Python環(huán)境最后用pip裝PyTorch。不要先裝CUDA Toolkit再裝驅(qū)動(dòng)那樣容易把系統(tǒng)里的libcuda搞亂。# 1. 更新系統(tǒng)并安裝驅(qū)動(dòng) sudo apt update sudo apt upgrade -y sudo apt install nvidia-driver-560 sudo reboot # 2. 確認(rèn)驅(qū)動(dòng)識(shí)別成功 nvidia-smi看到顯卡信息列表后再繼續(xù)。如果nvidia-smi報(bào)錯(cuò)多半是Secure Boot沒(méi)關(guān)或者驅(qū)動(dòng)和內(nèi)核版本沖突。然后創(chuàng)建Python虛擬環(huán)境避免依賴污染系統(tǒng)python3.11 -m venv venv source venv/bin/activate pip install --upgrade pip # 3. 安裝對(duì)應(yīng)CUDA 12.8的PyTorch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128這里有個(gè)經(jīng)驗(yàn)不要手動(dòng)去官網(wǎng)裝那一大套CUDA ToolkitPyTorch和H3依賴的都是運(yùn)行時(shí)組件pip裝的時(shí)候就帶了。手動(dòng)裝反而可能覆蓋系統(tǒng)庫(kù)最后各種找不到libcudnn.so。裝完之后驗(yàn)證Python能否調(diào)用GPUpython -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))輸出True和顯卡型號(hào)環(huán)境就OK了。2.3 模型權(quán)重下載H3的權(quán)重發(fā)布在某模型社區(qū)我用的是2B參數(shù)版。完整目錄大概長(zhǎng)這樣h3-model/ ├── config.json ├── text_encoder/ │ ├── config.json │ └── model.safetensors ├── vae/ │ ├── config.json │ └── vae.safetensors ├── diffusion_model/ │ └── model.safetensors └── tokenizer/ ├── tokenizer.json └── special_tokens_map.json下載建議用社區(qū)的下載命令下載前看下文件大小和SHA256校驗(yàn)值。一次下不完的用斷點(diǎn)續(xù)傳別中斷了重新來(lái)。下載完后先跑一個(gè)簡(jiǎn)單的權(quán)重加載腳本確認(rèn)所有模型文件都能被識(shí)別再進(jìn)入正式生成。3. 第一次跑通H3從命令行到出片把每個(gè)參數(shù)按明白3.1 最簡(jiǎn)啟動(dòng)命令環(huán)境配好、權(quán)重就位之后第一次跑通過(guò)程比我想象的順利。H3的命令行入口非常清晰核心參數(shù)就幾個(gè)。我先給一個(gè)可以直接運(yùn)行的例子python run.py \ --model h3-2b \ --prompt a white cat wearing a yellow raincoat, sitting on a windowsill in the rain, sipping hot coffee, cinematic lighting, camera pan \ --resolution 720x480 \ --frames 24 \ --steps 20 \ --cfg 3.5 \ --scheduler euler_a \ --seed 20250301 \ --output output/cat_rain.mp4參數(shù)逐個(gè)說(shuō)--model h3-2b指定2B參數(shù)版本權(quán)重路徑。--prompt提示詞建議英文中文支持還不太穩(wěn)定。--resolution 720x480輸出視頻分辨率。--frames 24視頻總幀數(shù)。幀率后面可以由輸出參數(shù)決定24幀接近1到2秒的畫(huà)面。--steps 20擴(kuò)散采樣步數(shù)步數(shù)越多畫(huà)質(zhì)細(xì)節(jié)越好但時(shí)間線性增長(zhǎng)。--cfg無(wú)分類器引導(dǎo)強(qiáng)度數(shù)值越高越貼合提示詞太高畫(huà)面容易過(guò)曝和僵硬。--scheduler euler_a采樣調(diào)度器不同調(diào)度器對(duì)短步數(shù)的適應(yīng)性差別很大。--seed隨機(jī)種子固定之后同參數(shù)可復(fù)現(xiàn)。--output保存路徑。第一次跑模型加載和算子預(yù)熱會(huì)比較慢。我在日志里看到它先加載文本編碼器、視頻VAE、擴(kuò)散模型然后在顯存里做前向?qū)R整個(gè)過(guò)程大概40多秒。等真正進(jìn)入采樣循環(huán)進(jìn)度條走起來(lái)就快了。我那次實(shí)測(cè)20步采樣花了18秒視頻VAE解碼用掉1.2秒總時(shí)長(zhǎng)不到20秒符合預(yù)期。3.2 默認(rèn)參數(shù)下到底占多少顯存很多朋友問(wèn)“32GB會(huì)不會(huì)不夠”“16GB能跑嗎”我直接看數(shù)據(jù)說(shuō)話。用nvidia-smi -l 1實(shí)時(shí)監(jiān)控峰值顯存拆解來(lái)看環(huán)節(jié)顯存占用說(shuō)明模型權(quán)重bf16約10GB2B參數(shù)16位存儲(chǔ)KV Cache與文本編碼約3GB與提示詞長(zhǎng)度正相關(guān)采樣激活約6GB隨分辨率、幀數(shù)變化視頻VAE解碼約3GB分塊解碼時(shí)峰值較低合計(jì)峰值約22GB720p、24幀、20步實(shí)測(cè)所以32GB的RTX 5090余量充足。16GB的卡如果只用低分辨率加短幀勉強(qiáng)能塞進(jìn)去但速度會(huì)明顯下跌因?yàn)橛行┲虚g結(jié)果要換到內(nèi)存里來(lái)回搬運(yùn)很傷性能。有一點(diǎn)要注意生成耗時(shí)統(tǒng)計(jì)不包含首次啟動(dòng)的模型加載時(shí)間。我經(jīng)?？吹接腥税l(fā)帖說(shuō)“跑個(gè)視頻要一分鐘”其實(shí)是把權(quán)重加載、算子編譯和采樣時(shí)間全算進(jìn)去了。H3實(shí)際采樣部分就是那十幾秒加載屬于一次性成本。4. 壓榨提速?gòu)牟綌?shù)到緩存一步步把16秒壓到10秒4.1 采樣步數(shù)和調(diào)度器最粗暴也最有效的開(kāi)關(guān)擴(kuò)散模型的生成質(zhì)量不是步數(shù)越高越好的線性關(guān)系。20步的畫(huà)質(zhì)相比12步細(xì)節(jié)確實(shí)有提升但對(duì)一段兩秒的視頻來(lái)說(shuō)肉眼差距往往不大。我做了幾組對(duì)比步數(shù)調(diào)度器720p、24幀耗時(shí)主觀畫(huà)質(zhì)20步euler_a18秒細(xì)節(jié)豐富動(dòng)態(tài)自然16步euler_a14秒差距很小12步euler_a11秒偶爾有輕微模糊12步dpmpp_2m13秒畫(huà)質(zhì)和20步接近同一段提示詞下12步配合dpmpp_2m能在畫(huà)質(zhì)和速度之間取得一個(gè)很舒服的點(diǎn)。如果你的題材是靜止場(chǎng)景或者輕微運(yùn)鏡12步完全夠用。劇烈運(yùn)動(dòng)、快速轉(zhuǎn)場(chǎng)的鏡頭建議還是回到16到20步不然會(huì)有拖影。euler_a是高效采樣調(diào)度器天然適合短步數(shù)速度快但偶爾會(huì)引入顆粒感。dpmpp_2m更穩(wěn)只是每一步計(jì)算量略多。我平時(shí)的默認(rèn)組合是快速出圖euler_a12步認(rèn)真出片dpmpp_2m16步。4.2 CFG和KV Cache減少重復(fù)計(jì)算速度第二個(gè)大頭是無(wú)分類器引導(dǎo)。CFG開(kāi)啟后每個(gè)采樣步其實(shí)要跑兩次網(wǎng)絡(luò)一次走帶提示詞的條件路徑一次走空提示詞的無(wú)條件路徑然后把兩者按cfg強(qiáng)度混合。這意味著每一步都在重復(fù)計(jì)算兩個(gè)字面含義完全不同的前向傳播開(kāi)銷直接翻倍。H3有一個(gè)緩存開(kāi)關(guān)可以讓條件路徑和無(wú)條件路徑共享一部分特征。具體參數(shù)是--cache-cfg true。實(shí)際跑下來(lái)開(kāi)啟后速度能提升15%到20%畫(huà)面質(zhì)量幾乎沒(méi)有肉眼可見(jiàn)的損失。它的原理是兩條路徑的前幾層特征高度相似先算一條路徑另一條在差分層面補(bǔ)全省掉重復(fù)的低層計(jì)算。還有--cache-attention true把文本編碼生成的自注意力KV緩存起來(lái)后續(xù)采樣步驟直接復(fù)用。這個(gè)對(duì)長(zhǎng)提示詞效果更明顯。另外強(qiáng)烈建議開(kāi)啟--cuda-graphs。CUDA Graphs把采樣循環(huán)里成千上百次小而碎的算子調(diào)用一次性錄制為一張執(zhí)行圖后續(xù)每一步只需要極低的CPU開(kāi)銷就能觸發(fā)一整輪計(jì)算。采樣循環(huán)是GPU的密集工作區(qū)CPU在這里任何一次多余調(diào)度都會(huì)成為瓶頸開(kāi)圖之后整體提速非常明顯。4.3 分辨率與幀數(shù)怎么權(quán)衡分辨率決定單幀計(jì)算量幀數(shù)決定時(shí)間維度計(jì)算量。這兩者是速度的乘法因子比步數(shù)還敏感。我的經(jīng)驗(yàn)配置實(shí)測(cè)耗時(shí)適用場(chǎng)景640×480、16幀、12步約7秒構(gòu)圖驗(yàn)證、提示詞測(cè)試720×480、24幀、12步約11秒日常出片720×480、24幀、20步約18秒最終成片1080×720、24幀、20步約40秒高清細(xì)節(jié)嘗鮮不算實(shí)時(shí)千萬(wàn)不要一上來(lái)就開(kāi)1080p。視頻生成的計(jì)算量是隨分辨率平方增長(zhǎng)1080p相比720p顯存占用和耗時(shí)都翻倍而且對(duì)短鏡頭來(lái)說(shuō)畫(huà)質(zhì)提升有限。正確流程是先低分辨率快速驗(yàn)證構(gòu)圖和提示詞確定沒(méi)問(wèn)題再升到720p正式生成。5. 畫(huà)質(zhì)速度怎么平衡三套直接可用的參數(shù)模板5.1 快速預(yù)覽檔、日常檔、高清檔參數(shù)不是死的根據(jù)使用場(chǎng)景選模板比每次手動(dòng)調(diào)要高效得多。我日常就存了三套預(yù)設(shè)寫(xiě)成一個(gè)配置文件按需調(diào)用?？焖兕A(yù)覽檔640×480、16幀、12步、euler_a、CFG 3.0。單次生成約7秒顯存占用約16GB。適合測(cè)提示詞比如你寫(xiě)了一句“一個(gè)人撐著傘走過(guò)霓虹街”不確定效果好不好先用這檔跑幾版挑到滿意的構(gòu)圖再放大。日常出片檔720×480、24幀、16步、dpmpp_2m、CFG 3.5。單次生成約14秒。這是我最常用的檔位質(zhì)量跟上20步差別很小速度又沒(méi)慢多少。高清試跑檔1080×720、24幀、20步、euler_a、CFG 3.5。單次約40秒。不是實(shí)時(shí)但作為高質(zhì)量成片輸出很值。三個(gè)檔位之間主要差異是分辨率和步數(shù)我把它們寫(xiě)成一個(gè)shell腳本模板每次用--preset quick之類的參數(shù)切換。5.2 提示詞是速度之外最大的變量同樣的參數(shù)提示詞寫(xiě)得好不好視頻效果天差地別。H3對(duì)英文的理解能力遠(yuǎn)好于中文建議盡量用英文寫(xiě)哪怕你的英文很蹩腳結(jié)構(gòu)對(duì)了就行。我長(zhǎng)期試下來(lái)一個(gè)可復(fù)用的提示詞結(jié)構(gòu)是這樣的主體 動(dòng)作 環(huán)境 光影氛圍 鏡頭運(yùn)動(dòng)正向示例a small white cat wearing a yellow raincoat, sitting on a windowsill in heavy rain, sipping hot coffee, cinematic lighting, raindrops on glass, slight camera pan to the left反向示例a white cat, coffee, rain第一個(gè)能把畫(huà)面每個(gè)元素的位置、互動(dòng)關(guān)系、氛圍和鏡頭都說(shuō)清楚生成結(jié)果幾乎每次都能用。第二個(gè)信息太少模型會(huì)自由發(fā)揮畫(huà)面經(jīng)常出現(xiàn)元素錯(cuò)位。視頻模型和圖像模型一樣需要負(fù)向提示詞來(lái)排除常見(jiàn)毛病。我一般固定加這么一段blurry, flicker, morphing, deformed hands, extra limbs, low quality, oversaturated, text, watermark閃爍和形變是視頻生成最容易犯的毛病負(fù)向提示詞對(duì)抑制它們有一定效果。另外運(yùn)動(dòng)描述可以適當(dāng)具體些比如camera rotation、slow zoom in不要只寫(xiě)dynamic這種抽象詞模型不太買賬。種子固定下來(lái)也很重要。找到滿意的畫(huà)面后把seed、步數(shù)、調(diào)度器、cfg、分辨率和幀數(shù)全部記下來(lái)下次才能復(fù)現(xiàn)。我自己寫(xiě)了一個(gè)小腳本每次生成前自動(dòng)把參數(shù)和seed存到文件名里方便后面比對(duì)。6. 實(shí)測(cè)踩坑OOM、黑屏、花屏這些問(wèn)題的排查鏈路6.1 OOM到底出在哪個(gè)環(huán)節(jié)跑H3最容易遇到的就是顯存溢出。而且它往往不是加載權(quán)重那一下爆的而是生成到一半報(bào)CUDA out of memory。這時(shí)候先別急著反復(fù)調(diào)低分辨率先搞清楚爆在哪一步。做法很簡(jiǎn)單開(kāi)一個(gè)終端跑nvidia-smi -l 1實(shí)時(shí)盯顯存同時(shí)在生成日志里看進(jìn)度條走到哪里爆的。我的經(jīng)驗(yàn)是兩種情況最多一種是采樣階段爆。通常發(fā)生在分辨率、幀數(shù)和步數(shù)三者都開(kāi)得很高的時(shí)候激活值把顯存吃滿了。解決路徑是按順序降檔先把幀數(shù)減半再降分辨率最后才考慮降步數(shù)因?yàn)椴綌?shù)影響質(zhì)量最明顯。另一種是VAE解碼階段爆。采樣完成了畫(huà)面快要輸出結(jié)果最后一步崩了。這種情況強(qiáng)烈建議開(kāi)啟分塊解碼。參數(shù)是--vae-tiled-decode它把解碼任務(wù)切成若干小塊逐個(gè)處理用一點(diǎn)點(diǎn)額外時(shí)間換回大量顯存空間效果立竿見(jiàn)影。還有一個(gè)容易踩的坑16GB顯存玩家硬開(kāi)720p。模型權(quán)重加完核心緩存后剩下的空間已經(jīng)捉襟見(jiàn)肘建議老老實(shí)實(shí)640×480起步。6.2 黑屏和花屏VAE精度惹的禍采樣好好的畫(huà)面解碼出來(lái)卻是全黑或者彩色條紋這個(gè)問(wèn)題在H3里也不少見(jiàn)。我第一次遇到黑屏?xí)r還以為是模型權(quán)重下壞了重新下載一遍問(wèn)題依舊后來(lái)才發(fā)現(xiàn)是VAE的浮點(diǎn)精度問(wèn)題。視頻VAE在fp16模式下解碼時(shí)容易產(chǎn)生數(shù)值溢出特別是高動(dòng)態(tài)范圍場(chǎng)景比如強(qiáng)烈光源、純白背景。溢出后張量里出現(xiàn)NaN或Inf畫(huà)面自然就廢了。解決方法是把VAE單獨(dú)切到bf16模式命令行加--vae-dtype bf16。bf16的指數(shù)位比f(wàn)p16寬數(shù)值范圍大得多穩(wěn)定性明顯更好。如果你的卡不太支持bf16也可以切--vae-dtype fp32顯存占用會(huì)多2GB左右但絕對(duì)穩(wěn)定。這個(gè)問(wèn)題的排查鏈路就是先看日志有沒(méi)有NaN如果有不是炸就是溢然后去改VAE精度。6.3 相同的提示詞兩次結(jié)果不一樣很多朋友會(huì)問(wèn)我用同一個(gè)提示詞跑兩次為什么畫(huà)面完全不一樣這種情況大概率是種子沒(méi)固定。但還有一種情況更隱蔽明明固定了seed兩次結(jié)果還是不一樣。我排查下來(lái)常見(jiàn)原因是采樣配置不一致。調(diào)度器不同、步數(shù)不同、cfg不同都會(huì)讓擴(kuò)散路徑發(fā)生偏移。甚至同一個(gè)調(diào)度器在不同精度的PyTorch版本下隨機(jī)數(shù)序列也會(huì)不一樣。所以正確的做法是把所有參數(shù)寫(xiě)進(jìn)一個(gè)配置文件包括seed、scheduler、steps、cfg、resolution、frames、vae_dtype、cache開(kāi)關(guān)一次生成一條記錄。我習(xí)慣用一個(gè)簡(jiǎn)單的JSON文件保存每次實(shí)驗(yàn)的完整配置方便復(fù)盤(pán)。還有一個(gè)細(xì)節(jié)H3首次運(yùn)行會(huì)緩存算子編譯結(jié)果之后的輸出和首輪可能會(huì)有一點(diǎn)點(diǎn)數(shù)值差異但這通常不影響整體效果。6.4 編碼卡死和顯存不釋放采樣和解碼都很快但最后導(dǎo)出視頻那一環(huán)節(jié)居然可能成為新的瓶頸。我第一次設(shè)置輸出為webm格式結(jié)果H.265編碼在CPU上跑得非常吃力生成完視頻等了十幾秒都不見(jiàn)文件寫(xiě)完一度以為是程序死了。后來(lái)我把輸出格式固定為H.264 mp4情況立刻改善。如果卡在編碼環(huán)節(jié)可以先關(guān)掉視頻編碼器自帶的極慢檔改用--fast-encode之類的選項(xiàng)犧牲一點(diǎn)點(diǎn)壓縮率換導(dǎo)出速度。另外CtrlC中斷生成后顯存經(jīng)常不會(huì)立刻釋放。我遇到過(guò)一次連續(xù)生成直接把顯存占滿下一輪OOM的尷尬。檢查辦法還是nvidia-smi看到殘留進(jìn)程就清理pkill -f run.py單卡長(zhǎng)時(shí)間滿負(fù)荷跑也會(huì)降頻。連續(xù)生成十幾段視頻后速度會(huì)明顯變慢核心溫度上來(lái)后頻率往下掉。我的習(xí)慣是批量任務(wù)之間隔個(gè)幾秒讓溫度緩一緩實(shí)測(cè)整體吞吐反而更高。7. 一點(diǎn)個(gè)人經(jīng)驗(yàn)H3類模型把視頻生成從云端API拉回本地單卡是一個(gè)實(shí)打?qū)嵉捏w驗(yàn)躍遷。我再補(bǔ)充一些個(gè)人經(jīng)驗(yàn)。首先是工作流先快速預(yù)覽檔跑四五個(gè)構(gòu)圖挑中一個(gè)升到日常檔精修最后再?zèng)Q定要不要出高清檔。這個(gè)順序基本不會(huì)浪費(fèi)時(shí)間和顯存。其次是真正影響“實(shí)時(shí)感”的不是那幾秒的采樣時(shí)間而是模型加載和啟動(dòng)時(shí)間我會(huì)保持一個(gè)常駐的生成進(jìn)程不退出連續(xù)出片時(shí)體驗(yàn)和對(duì)話差不多。最后一個(gè)小技巧建議在WSL2環(huán)境里跑把項(xiàng)目放在Linux文件系統(tǒng)下而不是Windows掛載盤(pán)磁盤(pán)IO差距還挺明顯的。如果你和我一樣是用VSCode遠(yuǎn)程連WSL來(lái)操作建議定期用nvidia-smi確認(rèn)顯存狀態(tài)別讓殘留進(jìn)程白白占著。想清楚自己要的是快速迭代還是高質(zhì)量成片兩套參數(shù)換著跑這套工具組合用起來(lái)會(huì)比云端方案順手很多。