AI 数字人要在直播里开口说话的同时把口型、表情、头部动作全部画出来,留给每一帧的时间只有二三十毫秒,这篇文章把这条实时流水线拆开看,看清楚时间都花在哪。
先拆一遍流水线:从音频到画面的五步
第一步进来的是音频流。系统先把声音切成二十毫秒左右的小段,提取音高、能量、频谱这些特征,这一步决定了后面口型跟得紧不紧。第二步是语义层:如果驱动源是文字稿,会先走一遍语音合成生成带时间戳的朗读;如果直接拿真人声音驱动,就跳过合成、只做特征提取。
第三步是驱动参数回归。模型拿着音频特征,预测面部关键点、口型开合度、眨眼概率、头部姿态这些数值,进来的是特征,出去的是一张参数表。第四步把参数表套到形象上:2D 方案直接变换原图,3D 方案驱动绑定好的骨骼与表情基。第五步渲染出帧、编码推流,观众端才看到画面。
毫秒预算怎么分:哪个环节最吃时间
以每秒二十五帧计,每帧预算四十毫秒,工程上通常压到二十毫秒以内给网络留余量。经验上特征提取只占一两毫秒,参数回归用轻量模型能压在五毫秒上下,真正吃时间的是渲染和编码:复杂 3D 场景一帧要几毫秒到十几毫秒,编码还要再抢走几毫秒。所以常见做法是脸部区域高帧率、背景低帧率,省下的算力全给嘴部。
按每秒二十五帧、每帧四十毫秒的预算,各环节大致这样分。
| 流水线环节 | 单帧大致耗时 | 工程上的做法 |
|---|---|---|
| 特征提取 | 一两毫秒 | 把声音切成二十毫秒左右的小段,提取音高、能量、频谱 |
| 参数回归 | 五毫秒上下 | 用轻量模型预测面部关键点、口型开合度、眨眼概率、头部姿态 |
| 渲染 | 几毫秒到十几毫秒 | 复杂 3D 场景最吃时间,常见做法是脸部区域高帧率、背景低帧率 |
| 编码推流 | 再抢走几毫秒 | 渲染出帧后编码推流,省下的算力全给嘴部 |
另一个决定延迟的环节是缓冲。流式推理要求模型边听边出参数,不能等一句话说完才动嘴,因此停顿判断和分块策略很关键,内部门道在端点检测是怎么判断停顿的里有展开。
口型和表情从哪来:驱动信号的来源
纯音频驱动最常见,有声音就能动,缺点是情绪靠猜;音频加文本双输入能让口型对得更准,因为文字直接告诉模型哪个音节对应哪个嘴形。表情还能从真人视频迁移,把采集到的关键点序列直接喂给驱动模型。豆包、腾讯元宝里能开口说话的助手形象,走的就是这类轻量实时方案。
声音这边同样有讲究:同一个形象换个声线,观众会觉得换了个人,音色在模型里存在哪、怎么搬运,可以看声音的「音色」存在模型的哪里;画面发虚时不能靠拉伸硬放大,超分是怎么补出细节的与插帧是怎么算出中间帧的是同一条流水线上的邻居。
类比与失效:像主播念稿但不只是放录像
把实时数字人理解成照着提词器念稿的主播,口型对声音、表情对内容、动作对节奏,这个类比抓住了同步的本质。但类比失效的地方在于:主播的嘴是真实器官,数字人的嘴是每帧重新算出来的画面,算力不够时会卡顿、掉帧甚至口型错位,这不是态度问题,是预算问题。
带走一个判断:挑实时数字人方案,先问三件事——端到端延迟多少毫秒、口型驱动用的什么规模模型、断流重连后声画能不能对齐。这三问比看演示视频可靠。
实时数字人自查清单
- 端到端延迟是否压在两百毫秒以内;
- 每帧预算里渲染和编码占了多少;
- 驱动信号是纯音频还是音频加文本;
- 断流重连后画面与声音能否对齐。
一句话:延迟是算出来的,不是许愿出来的。
关于数字人再多问三句
- 为什么嘴有时比声音慢半拍?:多半是缓冲攒多了,系统为了流式稳定把音频切块放大,宁可慢一点也不肯断流,牺牲的正是同步感。
- 它能完全替代真人出镜吗?:念稿、口播这类可预测内容它接得住,遇到即兴互动和临场反应,目前还是真人更稳。
- 自己搭一个门槛高吗?:用扣子这类编排平台串起语音合成加驱动模型就能跑通原型,门槛比两年前低了不少。


