LivePortrait 是快手 KwaiVGI 团队开源的实时人像动画(Portrait Animation)框架,解决的核心问题是:给一张静态人像照片和一段驱动视频,让照片里的人像跟随视频中的表情与头部姿态动起来,同时保持人物身份、躯干和背景的自然一致。它不需要真人重拍,也不需要昂贵的动捕设备,在单张消费级 GPU 上即可达到实时推理速度:官方论文报告在 RTX 4090 上单帧推理约 12.8ms。与同类方案相比,LivePortrait 的差异化在于显式设计了 Stitching(拼接)与 Retargeting(重定向)两个轻量模块:前者解决“脸部动了但躯干/背景没动”的形变错位,后者解决“表情幅度迁移后失真”的控制问题。项目以 Apache-2.0 协议开源,可商用,提供 CLI 与 Gradio WebUI 双入口,预训练权重通过 Hugging Face 与 ModelScope 分发,是目前数字人、AIGC 视频方向上手成本最低的人像驱动方案之一。本文按“速览—安装—上手—核心能力—生产部署—选型—场景—误区—面试”的结构展开,读者按序操作即可跑通完整链路。
掌握 LivePortrait,等于掌握数字人内容生产中最核心的“人像驱动”能力,是 AIGC 视频工程师、数字人产品团队与直播技术团队的高频技能项。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 LivePortrait:视频驱动 + 自然拼接,替代高成本重拍
传统“让一张照片说话”的方案存在三处硬伤。第一是成本:真人口播需要化妆、布光、拍摄、剪辑,单条素材的人力与时间成本都很高;第二是效果:基于 3DMM 参数的旧方案(如 SadTalker 系)在弱纹理、大角度、夸张表情场景下容易出现面部扭曲与躯干抖动;第三是控制力:多数开源方案只解决“嘴型对得上”,无法同时迁移头部姿态、眉毛与眼睛的细微表演。LivePortrait 用一段视频作为驱动信号,把真实表演的细节(不是单一音频特征)迁移到目标人像上,在保留身份特征的同时输出自然表情与姿态,从源头绕开了“形变伪影”这一传统难点。
它解决这一问题的方式是显式建模两个此前被忽略的环节:拼接(Stitching)与重定向(Retargeting)。拼接模块负责把生成的脸部运动自然接回源图的躯干与背景,避免“头是头、身体是身体”的断层感;重定向模块则对眼睛闭合度、嘴部开合度、头部姿态做独立系数控制,避免驱动人表情夸张时目标人像跟着“崩坏”。搭配官方报告的单帧 12.8ms(RTX 4090)推理速度,它把“可实时、可控制、可商用”三个要求同时落地,这也是它与纯音频驱动方案最本质的差异——LivePortrait 优先保证“演的像”,而不只是“嘴在动”。
对同一领域的从业者来说,LivePortrait 的价值还在于工程形态完整:CLI 一条命令出片、Gradio 拖拽即用、权重托管在国内外两个站点、协议允许商用,可以零门槛嵌入到数字人、短视频、直播等生产链路中。
安装与环境配置:3 步就绪
步骤一:克隆仓库并创建 Python 环境。 项目未发布到 PyPI,必须从 GitHub 克隆源码。环境建议使用 Python 3.10,通过 conda 创建独立环境,避免依赖冲突。
步骤二:安装依赖并下载预训练权重。 依赖以 requirements.txt 管理;权重不在代码仓库内,必须单独下载到 pretrained_weights/ 目录,否则运行时会报文件不存在。国内网络建议使用 ModelScope 源。
步骤三:验证环境。 检查 PyTorch 是否识别 CUDA,并确认权重目录结构完整。
# 1. 克隆仓库并创建环境git clone https://github.com/KwaiVGI/LivePortrait.gitcd LivePortraitconda create -n liveportrait python=3.10 -yconda activate liveportrait # 2. 安装依赖(PyTorch 需按本机 CUDA 版本安装,仓库默认支持 CUDA 11.8+)pip install -r requirements.txt # 3. 下载预训练权重(Hugging Face 与 ModelScope 二选一)pip install -U "huggingface_hub[cli]"huggingface-cli download KwaiVGI/LivePortrait --local-dir pretrained_weights --local-dir-use-symlinks=False # 国内加速可用 ModelScope:# pip install modelscope# modelscope download --model KwaiVGI/LivePortrait --local_dir ./pretrained_weights # 4. 验证环境python -c "import torch; print('torch', torch.__version__); print('cuda', torch.cuda.is_available())"ls pretrained_weights
快速上手:5 分钟跑通第一个示例
思路是先用仓库自带的示例素材验证全链路,再替换成自己的素材。仓库 assets/examples/ 下已提供源图(source/s9.jpg)与驱动视频(driving/d0.mp4),无需准备额外数据。首次运行会加载人脸检测与动画模型,耗时取决于 GPU;推理完成后在 animations/ 目录下生成结果视频。
分步操作:
1. 运行官方示例命令:python inference.py --source assets/examples/source/s9.jpg --driving assets/examples/driving/d0.mp4 --crop --scale 2.3。--crop 表示先做人脸检测与裁剪对齐,--scale 2.3 为裁剪缩放系数。
2. 检查输出:打开 animations/ 下生成的 mp4,确认人脸跟随驱动视频运动、躯干与背景无错位。
3. 换用自己的素材:源图建议正脸或半侧脸、光照均匀、无遮挡;驱动视频要求画面中仅一张正脸,时长不限。
4. 调节表情幅度:若嘴部动作过大或过小,调整 --lips_retargeting_multiplier;眼睛同理。以 1.0 为基准,按 0.1 步长微调。
5. 体验可视化界面:运行 python app.py,浏览器打开 http://127.0.0.1:7860,上传源图与驱动视频,调整参数后点击生成。
进阶技巧:当源图与驱动视频不是同一个人时,使用 --relative 相对模式(仅迁移表情与姿态的“变化量”)比绝对模式更稳定;官方默认开启相对模式。
# 官方示例:默认参数跑通python inference.py \ --source assets/examples/source/s9.jpg \ --driving assets/examples/driving/d0.mp4 \ --crop --scale 2.3 # 控制表情幅度:眼睛 0.7、嘴部 0.8python inference.py \ --source assets/examples/source/s9.jpg \ --driving assets/examples/driving/d0.mp4 \ --crop \ --eyes_retargeting_multiplier 0.7 \ --lips_retargeting_multiplier 0.8
核心能力详解:4 大支柱
支柱一·视频驱动的运动迁移。 LivePortrait 采用隐式关键点(Implicit Keypoint)框架:模型不直接估计 3DMM 参数或显式人脸关键点,而是让 MotionExtractor 从驱动视频中学习一组低维向量来编码表情与姿态变化,再与 AppearanceFeatureExtractor 提取的源图外观特征融合,通过 WarpingModule 解码生成运动后的帧。隐式关键点的优势在于对弱纹理区域(如额头、下巴)更鲁棒,这也是它在大角度下优于 3DMM 系方案的原因。
支柱二·拼接模块(Stitching)。 人脸区域运动时,源图的躯干和背景保持静止,直接替换会产生明显的“错位断层”。Stitching 模块预测一个形变补偿场(由 stitching multiplier 与 stitching offset 构成),让生成的脸部自然“长回”躯干与背景上。官方把它设计为插入到形变网络中的轻量模块,参与“推理时校准”——训练阶段不做拼接,推理时开启,从而避免训练与推理不一致的伪影问题。
支柱三·重定向模块(Retargeting)。 驱动人的表情幅度与目标人像不一定匹配:驱动人嘴张得很大,目标人像跟着张大会失真。Retargeting 模块用可分离的方式分别估计头部姿态、眼睛闭合度与嘴部幅度,并允许通过 CLI 参数独立调节(eyes、lips、stitching、face 四个 multiplier)。开发者可以在不重新训练的前提下控制“表演强度”,这是生产环境中迭代素材风格最常用的手段。
支柱四·批量与实时推理。 官方在 RTX 4090 上报告约 12.8ms 单帧推理,可支撑实时驱动;同一驱动视频支持驱动多张源图,便于批量生成同一表演下的多角色版本。代码仓库同时提供 CLI(inference.py)与 Gradio(app.py)两个入口,权重通过 Hugging Face 与 ModelScope 双通道分发,部署时无需额外注册或鉴权。
生产部署与监控:从上线到运维
部署方式一:单机 GPU 批处理管线。 适用于素材批量生产场景。以定时任务或消息队列驱动,每次调用 inference.py 处理一批(源图 × 驱动视频)组合,输出统一落盘到对象存储。需固定 PyTorch 与 CUDA 版本、锁定 requirements.txt,避免环境漂移;批处理作业要按 GPU 显存控制并发数,避免 OOM 导致整批失败。
部署方式二:Web 服务化。 官方 Gradio 应用可直接作为内网 Web 服务:通过 launch(server_name="0.0.0.0", server_port=7860) 暴露到内网,供内容团队上传素材生成结果;对外正式服务建议自封装 REST API(FastAPI),将推理封装为独立进程或独立服务,通过 HTTP 接收源图 URL 与参数、异步返回生成结果。注意端到端时延 = 人脸检测 + 裁剪 + 模型推理 + 视频编解码 + 网络传输,模型推理的 12.8ms 只是其中一环。
可观测性。 至少采集四类指标:GPU 利用率与显存占用(nvidia-smi 或 pynvml 定时上报)、单条任务耗时(按源图数量与视频帧数拆分统计)、失败率与失败原因(缺失权重、无检测到人脸、OOM)、队列积压量。输入输出建议做内容哈希记录,便于追责与重放。权重文件用 git-lfs 或对象存储管理并固化版本号;代码升级后先跑官方示例回归,再放量生产。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>权重不随代码仓库分发,忘记下载到 pretrained_weights/ 会在运行时直接报错;首次配置后先 ls 确认目录非空。</li><li>对整张高清图直接推理通常效果更差:模型面向对齐裁剪后的输入,整图缩放会丢失面部细节且背景干扰运动估计;应用 --crop 做裁剪推理,再合成回原图背景。</li><li>不要用 --scale 和 retargeting multiplier 互相替代:--scale 控制裁剪采样范围,multiplier 控制表情幅度,两者作用链路不同,调错会同时引入形变和模糊。</li></ul>
| 维度 | LivePortrait | SadTalker | MuseTalk | Wav2Lip |
|---|---|---|---|---|
| 定位 | 视频驱动的人像动画(表情+姿态迁移) | 音频驱动的静态图说话头生成 | 音频驱动的实时唇形同步 | 经典音频驱动唇形同步 |
| 驱动方式 | 驱动视频运动序列 | 音频 → 3DMM 系数 → 渲染 | 音频 → 潜空间特征 → 嘴部重绘 | 音频 → 唇形贴回原视频 |
| 实时性 | 高(RTX 4090 约 12.8ms/帧) | 中低(数秒生成数秒视频) | 高(潜空间运行,可实时) | 中(GPU 上接近实时) |
| 输出一致性 | 保持源图身份、躯干与背景,拼接自然 | 身份保持较好,躯干依赖裁切 | 保持原视频画面、仅改嘴部 | 仅改唇部,其他区域不变 |
| 控制粒度 | 眼睛/嘴部/姿态重定向系数独立可调 | 表情风格参数有限 | 速度与区域参数少量 | 基本无公开控制参数 |
| 部署复杂度 | 低-中(单卡 + CLI/Gradio) | 中(需 3DMM 模型与对齐) | 中-高(依赖面部分析与检测模块群) | 低(模型轻量) |
| License | Apache-2.0 | MIT | MIT | 未明确(学术用途声明) |
| 适合谁 | 需要表情与姿态双重控制的数字人、AIGC 视频 | 纯口播与虚拟主播快速生成 | 直播数字人实时唇形同步 | 在已有视频上快速修嘴型 |
选型建议:以“说话口播”为核心、不关心头部表演细节的场景,优先选 SadTalker 或 MuseTalk;需要迁移真实表演(表情+姿态)、追求角色一致性与可控幅度时,选 LivePortrait;只做存量视频改嘴型,选 Wav2Lip 成本最低。LivePortrait 本身不提供音频输入链路,音频驱动的完整数字人方案需要外接 TTS 生成驱动视频,或叠加 MuseTalk 类唇形模块。
版本迭代
LivePortrait 于 2024 年 7 月随论文开源,v1 以 Stitching 与 Retargeting 两个模块解决形变伪影问题;2025 年 4 月发布 v2 模型,主仓库支持 v1/v2 权重切换。仓库不维护语义化 Release tag,版本以 README 与权重仓库为准。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.0 | 2024-07 | 首次开源 | 推理代码、预训练权重、CLI 与 Gradio 双入口;RTX 4090 上报告单帧约 12.8ms |
| v2 | 2025-04 | v2 模型发布 | 新增 v1/v2 双模型加载方式;表情与姿态驱动的自然度整体升级 |
v1 主打轻量可控与可复现性,v2 侧重视觉质量与自然度。选型建议:追求稳定复现与社区资料兼容选 v1;对画质敏感、愿意承担升级回归成本选 v2;生产环境在固定硬件上分别跑官方示例做对比后决定。
AI 应用场景
数字人口播素材批量生产
阶段:人像动画生成 / 口播视频制作
解决的问题:真人口播需拍摄、化妆、剪辑,单条成本高;LivePortrait 用一张形象照 + 一条驱动视频批量生成口播素材,且能通过 retargeting 系数控制表情幅度,保证同一形象在不同文案下的风格统一。
具体案例:以 RTX 4090 单卡为准,一条 30 秒 30fps 的口播视频约 900 帧,模型驱动推理部分约 12 秒(900×12.8ms),配合模板化文案与批量脚本,单机日均可产出数十条初剪素材,待人工审片后发布。
虚拟主播与直播实时驱动
阶段:实时人像驱动链路搭建
解决的问题:传统虚拟直播依赖动捕设备或无版权风险的换脸方案,成本与风险高;LivePortrait 提供单卡可跑的实时推理能力,配合摄像头采集驱动信号即可驱动虚拟形象。
具体案例:部署时需明确 12.8ms/帧仅是模型推理,端到端链路需额外计入摄像头采集、人脸检测、视频编码延迟;工程上通过减小编码分辨率、开启 NVENC 硬件编码,可控制在观众可接受的时延范围内。
演员选角与镜头预演
阶段:影视前期预览 / 角色测试
解决的问题:短剧与广告拍摄前需要验证“某个演员的表演放在某个角色妆造上是否成立”,重拍成本高;用 LivePortrait 将同一段试镜驱动视频迁移到多张候选演员形象照上,快速输出各版本的表演样片。
具体案例:一组 10 张候选形象照 × 1 条 15 秒驱动视频的批处理,模型推理约 60 秒内完成,替代原本按天计算的试妆试拍排期,用于导演初筛。
常见误区
误区以为输入一段文字或音频就能让照片说话,像 HeyGen 那样输入文案直接出片。
正解LivePortrait 是视频驱动的人像动画框架,必须有“一张源图 + 一段驱动视频(提供表情与姿态)”。它不做 TTS、不做文本到视频的语义生成;音频驱动的完整方案需要外部串联 TTS,并把生成的语音先转成驱动视频(如用真人或 3D 形象录制的口播模板)。
为何常见:数字人产品多对外宣称“照片+文案出片”,掩盖了中间链路;实际拆解后,LivePortrait 只承担其中“人像运动”一环。
误区以为 `git clone` 成功即安装完成,运行时报文件不存在。
正解预训练权重单独托管在 Hugging Face 与 ModelScope,需按文档下载到 pretrained_weights/ 目录;权重约数 GB,下载完成后检查目录非空再运行。代码仓库更新时权重不一定同步更新,需关注 README 中的版本兼容说明。
为何常见:多数 Python 项目依赖 pip 自动拉取,惯性思维忽略了模型权重这类大文件走独立分发的惯例。
误区裁剪会降低分辨率,直接喂整张 4K 原图应该更清晰。
正解模型在固定尺寸的对齐裁剪输入上训练,直接输入整张图会被缩放至模型输入尺寸,面部占比变小、细节反而丢失,且背景内容会干扰运动估计;正确做法是 --crop 裁剪人脸区域做驱动,最终合成回原图背景,兼顾清晰度与一致性。
为何常见:从“通用超分”的直觉出发,忽略了人脸动画模型对输入对齐格式的强依赖。
误区拿到 12.8ms 数字,认为部署后即可直接用于直播。
正解该数字是官方论文中 RTX 4090 上单帧模型推理耗时,不含人脸检测、裁剪、视频解码、编码与网络传输。直播或实时预览需单独设计采集与推流链路,端到端时延通常以“百毫秒”计。
为何常见:论文与 README 突出推理速度,工程人员容易忽略统计口径边界。
误区把 `--eyes_retargeting_multiplier`、`--lips_retargeting_multiplier` 拉到 2 或 3,以为表情会更生动。
正解multiplier 控制的是“重定向映射强度”,超范围会导致形变伪影、模糊甚至五官扭曲;以 1.0 为基准,一般仅在 0.6-1.5 区间内按 0.1 步长微调,且需同时观察嘴部与眼睛区域的合成质量。
为何常见:把系数理解为“音量旋钮”,忽略了它作用于非线性映射模块、存在输出饱和与过度形变边界。
面试题
Q1. LivePortrait 的正确输入组合是?
- A.一段文本字幕
- B.一张人像照片加一段驱动视频← 正确答案
- C.一段音频文件
- D.一张人脸 3D 网格
答案:B。LivePortrait 是视频驱动的人像动画框架,源图提供身份外观,驱动视频提供表情与姿态序列。选项 A/C 是文本或音频驱动链路的需求,LivePortrait 本身不做语义生成与语音合成;选项 D 是 3D 类方案的输入,与隐式关键点框架不符。
Q2. 首次使用时,预训练权重应放在哪个目录?
- A.src/weights
- B.pretrained_weights← 正确答案
- C.assets/driving
- D.项目根目录
答案:B。官方 README 规定权重下载到仓库根目录下的 pretrained_weights/,CLI 与 Gradio 均按此相对路径加载。assets 目录仅存放示例素材,src 目录是源码,下载到错误位置会在运行时抛出文件不存在的错误。
Q3. 启动 Gradio 交互界面的命令是?
- A.python app.py← 正确答案
- B.python gui.py
- C.python server.py
- D.python start.py
答案:A。仓库根目录的入口脚本为 app.py,启动后默认监听 7860 端口。inference.py 是命令行推理入口,不提供界面;其余文件名在仓库中不存在。
Q4. Stitching 模块直接解决什么问题?
- A.音频与嘴型不对齐
- B.头部运动与原始躯干背景的形变不一致← 正确答案
- C.视频分辨率过低
- D.多显卡负载不均
答案:B。脸部运动时躯干与背景保持静止,直接替换会产生“断层”错位,Stitching 模块预测形变补偿让脸部自然接回躯干。音频对齐属于唇形同步模块的职责,分辨率与负载问题与拼接无关。
Q5. --relative 模式的含义是?
- A.仅迁移相对的表情与姿态变化← 正确答案
- B.降低输出视频帧率
- C.将源图裁剪到相对区域
- D.使用相对路径加载视频文件
答案:A。相对模式计算驱动序列相对首帧的变化量,再叠加到源图姿态上,源图与驱动人姿态差异较大时更稳定;绝对模式直接迁移驱动人的全局姿态,源图姿态不匹配时易产生极端变形。该参数与帧率、裁剪路径均无关。
Q6. 官方论文报告的 RTX 4090 单帧推理速度约为?
- A.12.8ms← 正确答案
- B.128ms
- C.1.28s
- D.12.8s
答案:A。论文摘要明确给出 RTX 4090 上单帧约 12.8ms 的推理耗时,这是模型推理部分,不含检测与编解码。BCD 与数量级相差过大,且官方未报告过此类速度。
Q7. 不裁剪直接驱动整张高清图通常效果更差,主要原因是?
- A.模型训练于对齐裁剪输入,整图缩放会丢失面部细节且背景干扰运动估计← 正确答案
- B.人脸检测模块强制固定缩放比
- C.高清图像无法在 GPU 上运行
- D.裁剪会改变输出视频的时长
答案:A。模型面向 512 级对齐裁剪图训练,整图输入会被缩放到同一尺寸,面部区域占比变小、细节下降,同时背景纹理进入运动估计范围产生干扰。官方推荐 --crop 裁剪驱动再合成回原图背景。检测模块不强制缩放比,GPU 只是显存问题,裁剪与时长无关。
Q8. 想单独减小嘴部驱动幅度,应调整哪个参数?
- A.--lips_retargeting_multiplier← 正确答案
- B.--eyes_retargeting_multiplier
- C.--scale
- D.--relative
答案:A。重定向模块对嘴部与眼睛分别提供独立系数,--lips_retargeting_multiplier 控制嘴部幅度、--eyes_retargeting_multiplier 控制眼睛幅度。--scale 控制裁剪缩放,--relative 控制相对/绝对驱动模式,均不直接作用于嘴部幅度。
Q9. 下列属于 LivePortrait 核心组成模块的有?
- A.MotionExtractor 运动提取← 正确答案
- B.AppearanceFeatureExtractor 外观提取← 正确答案
- C.StitchingAndRetargetingModule 拼接与重定向← 正确答案
- D.CLIP 文本编码器
答案:ABC。LivePortrait 由运动提取、外观提取、形变(warping)与拼接重定向四大模块构成,前三项即 A/B/C 所述。CLIP 文本编码器用于图文跨模态任务,不参与人脸动画推理链路。
Q10. 关于 LivePortrait 生产部署,理解正确的有?
- A.12.8ms每帧仅指模型推理,不含人脸检测与视频编解码← 正确答案
- B.Gradio 入口可通过 launch 参数暴露为内网 Web 服务← 正确答案
- C.权重与代码版本需匹配,升级后需回归测试← 正确答案
- D.必须多卡并行才能达到实时推理
答案:ABC。官方速度指标仅覆盖模型推理;Gradio 基于 launch(server_name, server_port) 可部署为内网服务;代码与权重版本不匹配会报兼容性错误,升级必须回归。单张 RTX 4090 已达实时推理,D 描述与官方数据矛盾。
参考来源
- webpageGitHub 仓库官方源码、CLI 用法与更新日志