LivePortrait 是快手 KwaiVGI 团队开源的实时人像动画(Portrait Animation)框架,解决的核心问题是:给一张静态人像照片和一段驱动视频,让照片里的人像跟随视频中的表情与头部姿态动起来,同时保持人物身份、躯干和背景的自然一致。它不需要真人重拍,也不需要昂贵的动捕设备,在单张消费级 GPU 上即可达到实时推理速度:官方论文报告在 RTX 4090 上单帧推理约 12.8ms。与同类方案相比,LivePortrait 的差异化在于显式设计了 Stitching(拼接)与 Retargeting(重定向)两个轻量模块:前者解决“脸部动了但躯干/背景没动”的形变错位,后者解决“表情幅度迁移后失真”的控制问题。项目以 Apache-2.0 协议开源,可商用,提供 CLI 与 Gradio WebUI 双入口,预训练权重通过 Hugging Face 与 ModelScope 分发,是目前数字人、AIGC 视频方向上手成本最低的人像驱动方案之一。本文按“速览—安装—上手—核心能力—生产部署—选型—场景—误区—面试”的结构展开,读者按序操作即可跑通完整链路。

岗位关联

掌握 LivePortrait,等于掌握数字人内容生产中最核心的“人像驱动”能力,是 AIGC 视频工程师、数字人产品团队与直播技术团队的高频技能项。

目录
  1. 为什么需要 LivePortrait:视频驱动 + 自然拼接,替代高成本重拍
  2. 安装与环境配置:3 步就绪
  3. 快速上手:5 分钟跑通第一个示例
  4. 核心能力详解:4 大支柱
  5. 生产部署与监控:从上线到运维
  6. 版本迭代
  7. AI 应用场景
  8. 常见误区
  9. 面试题
  10. 参考来源
工具类型
开源人像动画 / 人脸驱动框架
开发商
快手 KwaiVGI 团队
开源协议
Apache-2.0(可商用)
GitHub Stars
主要语言
Python(PyTorch)
当前版本
v2(2025-04 发布,兼容 v1 权重)
安装方式
git clone 源码 + conda + pip 安装依赖(非 PyPI 包)
下载地址
官方文档
上手难度
★★☆☆☆(低)
适合人群
AIGC 视频工程师、数字人产品团队、内容创作者
同类工具
SadTalker、MuseTalk、Wav2Lip
托管服务
无

速览卡是工具类内容的固定首屏模块: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,并确认权重目录结构完整。

bash20 行
# 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 相对模式(仅迁移表情与姿态的“变化量”)比绝对模式更稳定;官方默认开启相对模式。

bash13 行
# 官方示例:默认参数跑通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>

维度LivePortraitSadTalkerMuseTalkWav2Lip
定位视频驱动的人像动画(表情+姿态迁移)音频驱动的静态图说话头生成音频驱动的实时唇形同步经典音频驱动唇形同步
驱动方式驱动视频运动序列音频 → 3DMM 系数 → 渲染音频 → 潜空间特征 → 嘴部重绘音频 → 唇形贴回原视频
实时性高(RTX 4090 约 12.8ms/帧)中低(数秒生成数秒视频)高(潜空间运行,可实时)中(GPU 上接近实时)
输出一致性保持源图身份、躯干与背景,拼接自然身份保持较好,躯干依赖裁切保持原视频画面、仅改嘴部仅改唇部,其他区域不变
控制粒度眼睛/嘴部/姿态重定向系数独立可调表情风格参数有限速度与区域参数少量基本无公开控制参数
部署复杂度低-中(单卡 + CLI/Gradio)中(需 3DMM 模型与对齐)中-高(依赖面部分析与检测模块群)低(模型轻量)
LicenseApache-2.0MITMIT未明确(学术用途声明)
适合谁需要表情与姿态双重控制的数字人、AIGC 视频纯口播与虚拟主播快速生成直播数字人实时唇形同步在已有视频上快速修嘴型

选型建议:以“说话口播”为核心、不关心头部表演细节的场景,优先选 SadTalker 或 MuseTalk;需要迁移真实表演(表情+姿态)、追求角色一致性与可控幅度时,选 LivePortrait;只做存量视频改嘴型,选 Wav2Lip 成本最低。LivePortrait 本身不提供音频输入链路,音频驱动的完整数字人方案需要外接 TTS 生成驱动视频,或叠加 MuseTalk 类唇形模块。

版本迭代

LivePortrait 于 2024 年 7 月随论文开源,v1 以 Stitching 与 Retargeting 两个模块解决形变伪影问题;2025 年 4 月发布 v2 模型,主仓库支持 v1/v2 权重切换。仓库不维护语义化 Release tag,版本以 README 与权重仓库为准。

版本时间变化提升
v1.02024-07首次开源推理代码、预训练权重、CLI 与 Gradio 双入口;RTX 4090 上报告单帧约 12.8ms
v22025-04v2 模型发布新增 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 的正确输入组合是?

单选题 · easy

  • A.一段文本字幕
  • B.一张人像照片加一段驱动视频← 正确答案
  • C.一段音频文件
  • D.一张人脸 3D 网格

答案:B。LivePortrait 是视频驱动的人像动画框架,源图提供身份外观,驱动视频提供表情与姿态序列。选项 A/C 是文本或音频驱动链路的需求,LivePortrait 本身不做语义生成与语音合成;选项 D 是 3D 类方案的输入,与隐式关键点框架不符。

Q2. 首次使用时,预训练权重应放在哪个目录?

单选题 · easy

  • A.src/weights
  • B.pretrained_weights← 正确答案
  • C.assets/driving
  • D.项目根目录

答案:B。官方 README 规定权重下载到仓库根目录下的 pretrained_weights/,CLI 与 Gradio 均按此相对路径加载。assets 目录仅存放示例素材,src 目录是源码,下载到错误位置会在运行时抛出文件不存在的错误。

Q3. 启动 Gradio 交互界面的命令是?

单选题 · easy

  • A.python app.py← 正确答案
  • B.python gui.py
  • C.python server.py
  • D.python start.py

答案:A。仓库根目录的入口脚本为 app.py,启动后默认监听 7860 端口。inference.py 是命令行推理入口,不提供界面;其余文件名在仓库中不存在。

Q4. Stitching 模块直接解决什么问题?

单选题 · mid

  • A.音频与嘴型不对齐
  • B.头部运动与原始躯干背景的形变不一致← 正确答案
  • C.视频分辨率过低
  • D.多显卡负载不均

答案:B。脸部运动时躯干与背景保持静止,直接替换会产生“断层”错位,Stitching 模块预测形变补偿让脸部自然接回躯干。音频对齐属于唇形同步模块的职责,分辨率与负载问题与拼接无关。

Q5. --relative 模式的含义是?

单选题 · mid

  • A.仅迁移相对的表情与姿态变化← 正确答案
  • B.降低输出视频帧率
  • C.将源图裁剪到相对区域
  • D.使用相对路径加载视频文件

答案:A。相对模式计算驱动序列相对首帧的变化量,再叠加到源图姿态上,源图与驱动人姿态差异较大时更稳定;绝对模式直接迁移驱动人的全局姿态,源图姿态不匹配时易产生极端变形。该参数与帧率、裁剪路径均无关。

Q6. 官方论文报告的 RTX 4090 单帧推理速度约为?

单选题 · mid

  • A.12.8ms← 正确答案
  • B.128ms
  • C.1.28s
  • D.12.8s

答案:A。论文摘要明确给出 RTX 4090 上单帧约 12.8ms 的推理耗时,这是模型推理部分,不含检测与编解码。BCD 与数量级相差过大,且官方未报告过此类速度。

Q7. 不裁剪直接驱动整张高清图通常效果更差,主要原因是?

单选题 · hard

  • A.模型训练于对齐裁剪输入,整图缩放会丢失面部细节且背景干扰运动估计← 正确答案
  • B.人脸检测模块强制固定缩放比
  • C.高清图像无法在 GPU 上运行
  • D.裁剪会改变输出视频的时长

答案:A。模型面向 512 级对齐裁剪图训练,整图输入会被缩放到同一尺寸,面部区域占比变小、细节下降,同时背景纹理进入运动估计范围产生干扰。官方推荐 --crop 裁剪驱动再合成回原图背景。检测模块不强制缩放比,GPU 只是显存问题,裁剪与时长无关。

Q8. 想单独减小嘴部驱动幅度,应调整哪个参数?

单选题 · mid

  • A.--lips_retargeting_multiplier← 正确答案
  • B.--eyes_retargeting_multiplier
  • C.--scale
  • D.--relative

答案:A。重定向模块对嘴部与眼睛分别提供独立系数,--lips_retargeting_multiplier 控制嘴部幅度、--eyes_retargeting_multiplier 控制眼睛幅度。--scale 控制裁剪缩放,--relative 控制相对/绝对驱动模式,均不直接作用于嘴部幅度。

Q9. 下列属于 LivePortrait 核心组成模块的有?

多选题 · mid

  • A.MotionExtractor 运动提取← 正确答案
  • B.AppearanceFeatureExtractor 外观提取← 正确答案
  • C.StitchingAndRetargetingModule 拼接与重定向← 正确答案
  • D.CLIP 文本编码器

答案:ABC。LivePortrait 由运动提取、外观提取、形变(warping)与拼接重定向四大模块构成,前三项即 A/B/C 所述。CLIP 文本编码器用于图文跨模态任务,不参与人脸动画推理链路。

Q10. 关于 LivePortrait 生产部署,理解正确的有?

多选题 · hard

  • A.12.8ms每帧仅指模型推理,不含人脸检测与视频编解码← 正确答案
  • B.Gradio 入口可通过 launch 参数暴露为内网 Web 服务← 正确答案
  • C.权重与代码版本需匹配,升级后需回归测试← 正确答案
  • D.必须多卡并行才能达到实时推理

答案:ABC。官方速度指标仅覆盖模型推理;Gradio 基于 launch(server_name, server_port) 可部署为内网服务;代码与权重版本不匹配会报兼容性错误,升级必须回归。单张 RTX 4090 已达实时推理,D 描述与官方数据矛盾。

参考来源