口型同步聽起來像是個「把嘴巴對上聲音」的簡單問題，實際做起來卻是整條技術鏈裡最容易翻車的一環。我自己測過不少同類工具，很多模型第一秒對得挺準，講到第三十秒就開始飄，嘴巴閉不上、或者聲音停了嘴還在動。InfiniteTalk 這類整合包之所以被拿來討論，很大原因就在於它把「長時間不漂移」當成賣點，而這背後的實現思路，其實跟早期的 Wav2Lip 已經完全不是一回事了。
從聲音到嘴形，中間到底發生了什麼
最核心的一步是音訊特徵抽取。現在主流做法不是直接分析波形振幅，而是丟給 Wav2Vec2 這類自監督語音模型，抽出帶有語義的高維特徵向量。為什麼要這樣？因為單看音量大小，只能判斷「有沒有在說話」，判斷不出來這是「啊」還是「烏」。Wav2Vec2 的中間層特徵能隱含地表示音素資訊，模型就有機會學到音素與視覺唇形單元（viseme）之間的對應關係。
值得一提的是，中文和英文的 viseme 集合並不完全通用。英文大約歸納出 12 到 15 組視覺唇形，中文因為有大量介音和聲調，實際上更依賴上下文。像「不」這個爆破音，唇部先閉合再彈開的過程只佔兩三帧（以 25fps 計算），漏掉就會明顯感覺假。這也是為什麼很多國外模型直接跑中文音訊，總有種說不出的違和感。
特徵怎麼「灌」進生成模型
抽完特徵之後，這些音訊 embedding 會透過 cross-attention 注入到擴散模型的去噪過程中。簡單講，模型在生成每一帧的時候，都會去「問」對應時間點的音訊特徵：這一刻嘴應該張多大？這一步的時間對齊精度要求很高，通常需要把音訊按 40ms 一個窗口切分，剛好對上 25fps 的每一帧。
真正棘手的是長影片。逐段生成必然產生接縫，前一段的最後一帧和下一段的第一帧如果對不上，就會出現抖動。目前比較有效的解法是 sparse-frame 或 motion frame 機制——把上一段結尾的若干帧當作條件輸入，讓新片段的運動狀態延續下去。這也是「無時長限制」能成立的技術前提，不然顯存根本撐不住一次性生成幾分鐘。
為什麼有些工具口型準，表情卻很僵
因為這兩件事往往是分開建模的。純口型同步只需要控制下半臉區域，計算量小、也容易做得精準；但頭部擺動、眉毛牽動、眨眼節奏這些跟語調和情緒相關的部分，需要模型從音訊的韻律特徵（音高、能量、停頓）裡額外學習。全臉一起驅動，難度直接上一個量級，也更吃顯存——這大概就是 8G 顯存能跑起來但要接受某些取捨的原因。
實務上判斷一個口型同步效果好不好，除了肉眼看，業界常用 LSE-D 和 LSE-C 這兩個指標，前者衡量音視訊的距離誤差，後者看同步置信度。不過老實說，這兩個分數高不代表觀感就自然，眨眼太規律、脖子完全不動的影片，一眼還是能看出是 AI 生的。
真正想做到耐看，我的經驗是輸入端就要下功夫：音訊盡量乾淨、去掉背景音樂、語速別太快，人像照片選正臉且嘴部無遮擋。這些前置條件的影響，經常比換模型更明顯。
評論（15）
最後那段講輸入端的建議最有感，我之前音檔沒去背景音樂，嘴巴整個亂動
「聲音停了嘴還在動」這個太真實了😂
中文介音那段解釋了我一直說不上來的違和感
想問一下 8G 顯存實測大概幾分鐘的片要跑多久
爆破音只佔兩三帧這種細節平常真的不會去想
所以指標分數高其實也沒那麼準對吧，眨眼太規律一眼就看出來
motion frame 這個做法有點聰明，等於把上一段的狀態接下去
語速別太快這點我踩過，念快一點就開始糊
一直以為口型同步就是對音量大小，原來早就不是這樣了
表情僵的問題我以為是模型不夠好，沒想到是分開建模
40ms 對 25fps 這個剛好對上，蠻巧的設計
人像一定要正臉這個限制有點麻煩，側臉的素材基本廢了
第三十秒開始飄，說的就是我上次那支片
想知道韻律特徵那部分現在做到什麼程度了，眉毛能跟上情緒嗎
看完覺得換模型之前先把音檔處理乾淨比較實在