SD-WebUI-SadTalker：单图音频驱动口播视频实战

前两天一个做电商的朋友甩过来一张模特图，问能不能让图上的人把那段 30 秒的口播文案念完，还不用重新约拍摄。这个问题我这两年听过太多次了，做课程的、做短视频的、给企业做宣传物料的小团队，几乎都绕不开同一个诉求——手里只有一张静态照片，但想要一段能动的、嘴型对得上的视频素材。SD-WebUI-SadTalker 就是解决这个需求的一条现成路子：它把 SadTalker 这套音频驱动人脸动画的能力，封装成了 Stable Diffusion WebUI 里的一个扩展面板，上传一张人脸照片、上传一段音频、点一下生成，等几分钟就能拿到一段 MP4。

先说清楚它是什么。SadTalker 是一个开源的音频驱动说话头像生成方案，核心思路是把音频里的语音特征映射成 3D 人脸的关键点运动，再把运动贴回你给的那张原图，最后做面部增强输出视频。WebUI 版本的扩展做的事情很朴素：把命令行那一堆参数变成面板上的几个选项，让你不用敲 python 命令就能跑。它不做实时，不做全身动作，也不做长视频直播，它专注的就是“单人、正脸或微侧脸、说一段话”这个场景。

适合谁看这篇？三类人最对口。第一类是没有代码基础的内容创作者，只想要结果，那重点看素材准备和参数面板那两节就够了。第二类是运营岗要批量出片的，重点看批量脚本和长音频分段。第三类是想搞清楚内部怎么跑起来的开发者，前半段原理拆解和模型权重那部分会对你有用。下面我按从原理到落地、从装环境到调参踩坑的顺序完整讲一遍。

1. 先搞清楚这个工具到底在做什么

1.1 从一张照片到一段对上口型的视频

很多人第一次看到生成结果会觉得很神奇，其实就是个固定的流水线：给定一张图 A 和一段音频 B，输出视频 C。视频里的人脸取自 A，嘴型和头部的小幅晃动跟着 B 的节奏走。这里有一个很容易被忽略的细节——SadTalker 生成的头部姿态和表情，不是从原图里“学”出来的，而是从音频里“推”出来的。也就是说，你给的图只提供身份外观，动起来的方式是由音频决定的。

这个设计带来两个直接后果。好消息是同一张图可以配任意多段音频，批量产出很省事；坏消息是它的动作幅度有上限，因为姿态预测模型是在训练集上学到的统计规律，遇到特别长的音频、特别快的语速，或者特别夸张的情绪，输出会偏向保守，你看到的就是“头微微动、嘴在动、但整体有点平淡”。

和另外两条常见路线比一下更清楚。换脸类方案是把别人的动态视频里的脸换掉，动作是真实拍摄的，自然度高但需要源视频，而且动作不随音频变；实时数字人类方案追求低延迟交互，对算力要求高、画质往往更糙。SadTalker 的位置在中间偏“离线出片”：不追求实时，但允许你用单张图、几秒钟音频，在消费级显卡上产出一段嘴型基本对得上的口播视频。这个定位决定了它最适合录播类、宣讲类、文案类内容，不适合需要大幅度表演的场景。

我在实际项目里最常见的用法是：先让设计把人物照片精修好（去背景、补光、统一色温），再拿配音稿的音频批量跑，最后在剪辑软件里加字幕和转场。整个链路里，生成环节反而是最省心的，前面素材准备花的时间通常占七成。

1.2 拆开看：音频、3DMM、渲染三段式管线

想调好参数，得知道它内部大概分几步。SadTalker 的管线可以粗暴地分成三段：音频编码、3D 人脸系数预测、渲染回原图。

第一段是音频编码。你上传的音频文件会先被重采样成固定采样率，然后送进语音特征提取模型，把波形变成一串带时序的特征向量。这一步很关键：切分的最小粒度决定了嘴型变化的精细程度。音频质量差、有底噪、有混响，特征就脏，后面再怎么调参数都救不回来。这也是为什么我后面会反复强调音频预处理。

第二段是系数预测，这是 SadTalker 的核心。它不直接生成像素，而是预测 3DMM（三维形变人脸模型）的系数。具体拆成两条支路：一条负责表情系数，由音频特征驱动，管的是嘴巴张合、眉毛、眼睛这些；另一条负责头部姿态，通常用序列模型来生成，管的是点头、轻微左右转。把表情和姿态分开预测是这套方案里最讨巧的地方，因为头部晃动和嘴型之间本来就没有强相关，混在一起学容易互相干扰，拆开之后两边的可解释性和可控性都好很多。

第三段是渲染。有了 3D 系数，就能重建出一个三维人脸网格，但这时候出来的东西是“白模”质感的，跟你的原图没任何关系。所以还有一步关键的映射：把三维的运动迁移回原始二维图片上，用的是基于关键点的面部重演网络，把源图的外观和预测出的运动结合起来。这一步直接决定了脸崩不崩。最后一道工序是面部增强，调用 GFPGAN 或者 CodeFormer 之类的修复模型，把重演过程中糊掉的五官细节重新补回来。

理解了这三段，很多参数选择就自然明白了。比如“增强器”参数只在第三段起作用，它救不了第一段音频脏的问题；比如“表情强度”是在第二段调节表情系数幅度，调太大嘴会张成黑洞；比如“预处理模式”其实是在决定第二段的输入怎么裁剪、第三段往哪贴回去。

1.3 它擅长什么、明确不擅长什么

老实说，工具的能力边界比它的功能列表更重要。我把实测下来比较稳和容易翻车的场景各列一下。

比较稳的：正脸或者左右偏转不超过 15 度的半身照；纯色或虚化背景；光照均匀、没有强烈侧光；嘴部没有被遮挡；照片分辨率在 512 到 1024 之间；音频是干净的人声，单声道，语速正常。这类素材跑 256 尺寸，出片率基本在九成以上。

容易翻车的：大侧脸（超过 45 度）几乎必崩，因为重演网络看到的半边脸信息太少；戴帽子、口罩、手托腮、麦克风挡住嘴，遮挡区域会跟着乱动；多人合影，它只会挑一张脸处理，其他脸会变成静止的诡异存在；全身照，人动不了，只有头在动，看起来像贴上去的；大幅度的表情比如大笑、唱歌，超出训练分布，嘴型会失控。

还有一个诚实的提醒：它做不了“情绪表演”。你给它一段平静的旁白和一段激动的演讲，输出的动作差异非常有限。想要强烈的情绪表达，得靠后期剪辑节奏、配乐、字幕来补，或者在这个工具之外再接别的方案。

2. 部署与环境：先把地基打平

2.1 三种接入方式，按你的产出方式选

同一个底层能力有三种用法，选错了会白白浪费很多时间。

第一种是 WebUI 扩展面板。适合已经在用 Stable Diffusion WebUI 的人，装完在顶部标签栏多一个入口，上传图、上传音频、勾参数、点生成，全程图形化。优点是零命令行，缺点是依赖 WebUI 的 Python 环境，一旦 WebUI 本体升级或者依赖冲突，扩展可能整个加载失败。

第二种是独立命令行仓库。适合要批量跑、要接自动化流水线的人。好处是环境隔离干净，参数直接写在命令里，容易版本控制；坏处是模型权重要自己下、目录结构要自己对。

第三种是自己写脚本调用内部模块，适合开发者做二次封装，比如接到自己的后端服务里，做成任务队列。

我一般建议：第一次接触先用扩展面板跑通一次，看到效果建立信心；确认要长期用，再迁到独立环境去做批量。反过来先啃命令行，很容易在依赖阶段就劝退。

2.2 依赖安装的实操顺序与卡点

依赖这块的坑基本集中在三处：音视频处理库、人脸对齐模型、以及修复模型的版本兼容。

第一步是音视频处理。系统里必须能找到 ffmpeg 的可执行文件，不是 Python 包装了就完事。Windows 上建议下载静态构建版本，把 bin 目录加进 PATH，然后在终端执行一次ffmpeg -version确认能打印出版本号。Linux 用包管理器直接装。

ffmpeg -version ffprobe -version

第二步是深度学习运行时。PyTorch 和 CUDA 版本必须匹配你的显卡驱动，这一步装错了后面全是玄学报错。装之前先确认驱动支持的 CUDA 上限，再挑对应的 PyTorch 轮子，不要凭记忆抄别人的命令。

python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"

第三步是修复模型相关的依赖。这一块是历史遗留问题最多的，basicsr、facexlib、gfpgan 这几个包对 torchvision 和 numpy 的版本比较挑剔。我的经验是先装主流程依赖，跑通一次基础生成（增强器先关掉），确认能出片之后再回去补增强模型的依赖。分两步装，出问题时能立刻定位是哪一层的锅。

注意：如果你用的是 WebUI 扩展形态，装完依赖后重启 WebUI 主进程，光刷新网页不会重新加载 Python 模块。很多“装完了没反应”的情况都是没重启。

另外还要留意人脸检测模型首次运行时会自动下载权重到用户目录，如果网络环境不稳，会卡在初始化阶段很久，看起来像死机。稳妥做法是提前把权重文件放到对应缓存目录，让它跳过下载。

2.3 模型权重放哪里、显存怎么算

主模型的权重文件通常是几个固定名字：256 分辨率的版本、512 分辨率的版本，以及两个映射网络的文件。这些文件要放在扩展目录下指定的 checkpoints 文件夹里，文件名不能改。增强模型（GFPGAN、CodeFormer）和检测模型（人脸检测、通用对齐）一般放在单独的 gfpgan/weights 目录。

目录结构大致是这样：

extensions/ sd-webui-sadtalker/ checkpoints/ SadTalker_V0.0.2_256.safetensors SadTalker_V0.0.2_512.safetensors mapping_00109-model.pth.tar mapping_00229-model.pth.tar gfpgan/ weights/ detection_Resnet50_Final.pth alignment_WFLW_4HG.pth GFPGANv1.4.pth parsing_parsenet.pth

显存怎么估？给个我实测的经验值，都是 8G 显存卡上的观察，仅供参考：

算法很简单：显存 ≈ 基础占用（约 2.5G，含模型加载）+ 单帧占用 × 批量大小。256 分辨率下单帧约 1G，512 分辨率下翻三到四倍。如果你的卡是 6G 显存，就老老实实 256 加批量 1 或 2，别硬上 512，爆了之后不是降速而是直接中断，前面跑的全白费。

还有一点值得提醒：音频长度和耗时不完全是线性的。因为面部重演那一步是按帧处理的，帧数一多，中间缓存的中间结果也占内存。我跑过一段 5 分钟的音频，虽然显存没爆，但系统内存吃掉了十几个 G，机器开始疯狂读写磁盘。所以真要处理长音频，后面第六节讲的分段策略是必须的。

3. 素材准备决定七成效果

3.1 照片：这五个指标必须过关

照片是整个流水线里最容易糊弄、也最影响结果的一环。我总结下来有五个必须看的指标。

分辨率。太低（低于 256）五官信息不够，重演网络抠不出足够细节，出来就是一团糊；太高（超过 2048）也不是好事，因为内部会缩放，缩放过程中的细节丢失反而引入伪影，而且预处理会不稳定。我的经验甜区是 512 到 1024 之间，长边落在这个范围最省心。

人脸占比。人脸在画面里最好占到三成以上，太小的话检测框会漏，预处理裁出来的区域分辨率不够。如果原图是全身照，建议先手动裁成半身，把脸放大，再喂进去。

角度。正脸最佳，左右偏转 15 度以内都还行，超过 30 度开始出现一侧脸颊拉扯，超过 45 度基本可以放弃。抬头低头同理，仰拍和俯拍都会让重演网络的映射出现垂直方向的挤压。

光照。均匀的正面光最好。侧光会在脸上留一条硬阴影，重演的时候这条阴影不会跟着动，观感非常怪。逆光更糟，脸是黑的，增强模型会把噪点也一起放大。

遮挡。嘴部绝对不能有遮挡，麦克风、手、口罩、高领毛衣都算。眼睛有眼镜框是可以的，但镜片反光会导致增强阶段出现奇怪的高光。

实操技巧：如果手头只有一张不太理想的图，可以先做三步预处理——抠掉背景换成纯灰或纯色、用局部提亮把脸上的阴影压平、稍微锐化一下五官边缘。这三步做完，出片质量往往能提升一档，比在参数面板上来回试有效得多。

3.2 音频：采样率和语速的影响比想象中大

音频这边经常被当成“随便录一段就行”，其实它对口型的影响非常直接。

采样率与声道。统一转成单声道，采样率 16k 或 44.1k 都可以，内部会重采样，但别用奇怪的采样率比如 8k 或 96k，容易在读帧的时候出现对齐问题。立体声没必要，白占体积。

底噪与混响。这是最大的杀手。有明显底噪的音频，语音特征提取会把噪声也当成语音内容，表现出来就是嘴在没声音的地方乱动或者一直微张。混响（在空房间里录的）会让语音边界变糊，嘴型切换拖泥带水。录的时候靠近麦克风、房间里挂点吸音的东西，比后期降噪效果好得多。

语速与停顿。SadTalker 对正常语速表现最好。语速极快的片段，相邻音素太近，嘴型会来不及变，观感像在“抖动”。长停顿倒是没问题，只是停顿期间头部会保持微动，看起来有点发呆，后期剪掉或者加个转场就能掩盖。

音量归一化。不同段落的音量差异太大会导致口型幅度忽大忽小，建议在生成前统一做一次响度归一化，让每个片段的峰值电平接近。

3.3 几个典型的坏素材案例

说几个我踩过的具体例子，比抽象的原则好记。

第一个，用了一张抠图后边缘有白边的图。结果脸和背景交界处每一帧都在闪，因为重演网络认为那条白边是脸部结构的一部分。后来重新做了边缘羽化才好。

第二个，音频里有一段背景音乐没去掉。人声被音乐的低频包住，输出视频里嘴型一直在小幅抖动，看起来像在默念。去掉音乐后立刻正常。

第三个，照片是侧逆光，脸有一半在阴影里。输出的时候暗部那一侧的脸颊每帧都在变色，增强模型在拼命“猜”细节。换成正面光重拍一张，问题消失。

第四个，用了戴细框眼镜的图。镜片有反光点，增强器把反光点当成眼睛高光反复强化，最后出来眼睛像在发光。这种只能换图或者手动把反光修掉。

4. 参数面板逐项拆解与实操流程

4.1 预处理模式：五种选项到底选哪个

这是最容易点错、也最容易导致“输出视频里人脸位置不对”的参数。它的作用是告诉程序：拿到你的原图之后，怎么裁剪出要处理的人脸区域，以及生成之后怎么贴回原来的画布。

我的默认选择是 extfull：它既保留了原图的完整构图和背景，又给了重演网络足够的上下文，贴回去的时候位置也不会漂。只有当原图背景很乱、或者人脸特别小的时候，才会退到 extcrop 先把脸放大处理好，再用后期软件叠回原背景。

注意：如果你选 crop 或 extcrop，输出的视频尺寸和原图不一样，后面接剪辑的时候要重新对时间轴。批量跑之前先确认下游流程能不能接受这种尺寸变化。

4.2 still 模式、姿态风格、表情强度、增强器

这四个参数决定了成片的“观感风格”，值得单独说。

still 模式是控制头部运动的。一般有 0 到 3 几档，0 是完全不约束（头会自然晃动），数值越大越倾向于固定头部姿态。口播类内容我通常用中间档，头部有轻微起伏但不夸张；如果是证件照风格的播报，直接开到最大，只让嘴动，画面最稳。完全不约束的那档，遇到长音频后段容易出现头部逐渐偏出去、最后歪着的情况。

姿态风格（pose style）是一个整数，用来索引预置的姿态模板，范围通常在几十个之内。不同模板对应不同的头部晃动幅度和节奏倾向。这个东西有点像抽卡，同一个模板对不同音频的表现不完全一样。我的做法是：先用默认值跑一遍，如果觉得太呆板就换几个相邻的值对比，一般试三到五次能找到一个舒服的。别在这上面花太多时间，收益有限。

表情强度（expression scale）调节表情系数的幅度。默认值附近是最稳的，往上调嘴张得更大、眉毛动作更明显，但超过一定幅度就会出现嘴巴边缘撕裂、牙齿区域变成一片黑。往下调会变得很平淡，像在念经。我的经验区间是默认值上下浮动两成，超出这个范围基本都会出问题。

增强器（enhancer）用来在生成后修复面部细节。常见选项是无、GFPGAN、CodeFormer 几类。开启后五官会锐利很多，代价是速度慢一些，而且偶尔会把皮肤磨得过于光滑，失去质感。我的建议是：素材质量好的时候可以不开，或者用轻量档；素材偏糊的时候必须开，否则脸会像蒙了层雾。

4.3 完整跑一遍：从上传到出片

讲一遍我现在固定用的流程，你可以直接照着走。

第一步，素材预处理。照片统一裁到长边 768 左右，人脸居中偏上，背景抠成纯灰；音频统一转单声道、做响度归一化、剪掉首尾静音。

ffmpeg -i input.wav -ac 1 -ar 44100 -af "loudnorm=I=-16:TP=-1.5:LRA=11" -y voice_norm.wav

这里的响度参数用的是常见播客标准，I 是目标响度，TP 是峰值上限，LRA 是响度范围。这样处理过的音频，口型幅度会比较一致。

第二步，面板设置。预处理选 extfull，尺寸先 256，still 模式中间档，增强器先关掉，批量大小 2。第一次跑别开增强器，能大幅缩短单次试错时间。

第三步，先跑短样本。剪 5 到 8 秒的音频做验证，看三个点：脸有没有崩、口型对不对得上、头部运镜能不能接受。这三点都没问题再跑全片。这一步能省掉大量“跑了十分钟发现方向错了”的时间。

第四步，跑全片并开增强。确认短样本没问题后，把完整音频放进去，打开增强器，尺寸按需决定是否提到 512，批量大小按显存往下调。

第五步，输出后处理。拿到的 MP4 一般是 25 帧每秒，直接进剪辑软件对齐时间轴、加字幕、配乐。

整条流程走熟了，一段 30 秒的内容从准备到出片大概二十多分钟，其中生成只占五到八分钟。

5. 出问题怎么查

5.1 画面类问题

脸崩、变形、抖动，是最常见的三类画面问题，原因各不相同。

脸糊得看不清五官，通常是三重原因叠加：原图分辨率太低、增强器没开、尺寸选了 256。按顺序排查，先把尺寸提到 512 试一次，再看增强器有没有生效，最后检查原图。

脸在每一帧都有轻微位移或者像在“呼吸”式缩放，这多半是预处理模式选错导致的重贴偏差。换成 extfull 重跑通常能解决。如果还不行，检查原图里是不是有多张脸，程序可能在不同的帧里锁定了不同的脸。

脸的边缘有明显的一条“补丁”痕迹，是因为裁剪区域和原图背景的色温、亮度不一致。这个在后期不太好修，最好的办法是原图先用纯色背景，让边界过渡自然。

背景跟着一起扭曲，是用了 full 或者 extfull 但背景里有强直线结构（比如书架、窗框），重演网络的形变波及到了背景。换成 extcrop 只输出头肩，再在后期合成回背景，可以规避。

5.2 口型与音频类问题

嘴型对不上或者乱动，排查顺序和画面问题完全不一样。

嘴在没声音的时候也在动，九成是音频底噪。用降噪或者干脆重录。

嘴型整体慢半拍，检查音频开头有没有一段静音被吞掉，或者剪辑软件导入时时间轴有没有偏移。有些工具在读写音频时会补一小段填充，导致整体延后几十毫秒，人眼对这种延迟很敏感。

嘴张不开，一直是微张状态，检查表情强度是不是被调低了，或者音频本身音量太小、响度不够。

明显该张嘴的音节嘴没动，通常是音素级别的对齐问题，语速太快或者音频有严重的压缩失真。这种没法通过参数解决，只能重录或者放慢语速。

5.3 性能与报错类问题

还有一类不容易发现的问题：跑完之后视频能播，但音画不同步。这通常是因为输入的音频采样率和内部处理的不一致，转码时补了填充。统一转成 44.1k 单声道基本能避免。

6. 进阶：长音频、批量与后处理

6.1 长音频分段拼接

单次处理超过 60 秒的音频，出问题的概率明显上升：头部姿态会漂、显存和内存压力大、中途失败重跑成本高。我的做法是切成 20 到 30 秒的段落分别生成，再拼接。

切分点的选择有讲究。不要按固定秒数硬切，会切在词中间，拼起来嘴型会顿一下。用静音检测来切，在自然停顿处分段。切的时候给前后各留 0.2 秒的余量，拼接时再对齐。

段与段之间的衔接处最容易露馅：上一段结束时头是偏的，下一段开头是正的，中间就会跳。解决办法是让所有分段用同一张图、同一组参数、同一个随机种子，并且在选段的时候优先选头部姿态接近的。必要时在剪辑软件里加一个极短的交叉叠化，把跳变藏掉。

帧数换算是这么算的：25 帧每秒 × 时长（秒）= 总帧数。30 秒就是 750 帧。三个分段 30 秒，显存峰值只受单段影响，但总耗时基本是线性叠加，稍微多一点是因为每段都要重新加载模型。所以批量跑的时候，宁可贵一点显存去换批量，也不要为了剩显存把段切得太碎。

6.2 批量脚本化

一次要出十条八条的时候，手动点面板肯定不行。思路很简单：把待处理的图片和音频按命名配对，写个循环调用。

for f in audio/*.wav; do name=$(basename "$f" .wav) python inference.py \ --driven_audio "$f" \ --source_image "images/${name}.png" \ --result_dir "output/${name}" \ --still \ --preprocess extfull \ --size 256 \ --enhancer gfpgan \ --batch_size 2 done

几个实践要点：输出目录按素材名分开，避免同名覆盖；每条任务跑完打印一行日志，方便失败后定位；失败不要中断整个循环，加个判断继续下一条，最后统一看哪些没成功。我还会在循环外面加一个总计时，跑完能大致估算出单位时长的处理成本。

如果任务很多，建议按 5 到 10 条一批分开跑，中间留个间隔。连续跑久了显存碎片会累积，偶发的显存不足往往出现在第十几条上。

6.3 后处理：从能用变成好看

生成出来的原始素材是“能用”的级别，直接发出去总差点意思。后处理这一步花的时间不多，但提升很明显。

第一是锐化和降噪。生成视频的面部往往有一层轻微的模糊感，用剪辑软件里的轻度锐化加一点点降噪，观感会干净不少。注意别过头，锐化过度会让牙齿和眼白出现振铃。

第二是调色。生成的人和原图背景之间经常有色温差异，全局统一一下色温和对比度就能缓解。

第三是加动态元素。因为头部动作幅度有限，画面会显得有点静。加一点轻微的缓慢推镜、或者叠加一层很淡的光斑流动，观感立刻不那么死板。

第四是字幕和节奏。口播类内容里，字幕出现的时间点跟嘴型对上，观众的“同步感”会强很多，即使个别音节嘴型没对得特别准也容易被忽略。

7. 几个我踩过之后才明白的点

写到这里差不多了，最后分享几条只有真跑过才会总结出来的经验。

不要拿一张精修过度的图去跑。磨皮磨到没有毛孔、脸型液化改过的图，输出时五官会显得浮在皮肤上，因为重演网络找不到真实的结构锚点。用轻度修图或者原图，效果反而更扎实。

不要迷信 512 分辨率。512 确实细节更多，但前提是原图本身分辨率够、光照够均匀。原图本身是 512 的图硬跑 512 输出，等于放大，出来反而更糊。判断标准很简单：原图长边至少是目标输出尺寸的两倍，否则就老实待在 256。

不要在第一次就跑完整音频。先用 5 秒样本确认方向，这个习惯能省下的时间比任何参数优化都多。我见过太多人花半小时跑了一条三分钟的视频，结果发现预处理选错，输出的人脸根本没在画面里。

不要忽视系统内存。显存够用不代表内存够用，长音频处理时中间结果会吃掉大量内存。给自己留至少 16G 空闲内存，跑长任务前把浏览器标签关一关。

最后一点，这套工具的核心价值不是“以假乱真”，而是把内容生产的门槛降到了一张图加一段录音。想清楚这一点，你就不会在参数里死磕那几个百分点的画质提升，而是把精力放在脚本、节奏和素材质量上——那才是观众真正能感知到的部分。