本文是「数字伴侣建造记」的第二篇，记录整个项目的第一次重大放弃：本地实时口型。评估对象是三个开源方案——wav2lip（经 LiveTalking 引擎）、MuseTalk v15（同）与 LatentSync（离线）。结论先行：三者都没有达到“照片级伴侣”所需的质感门槛，且这不是调参能弥补的差距。
测试环境与方法
原生 Windows 11，RTX 5070 Ti 16GB（Blackwell，sm_120），PyTorch 2.9.1+cu128。素材为 1904×1072 的真人质感视频。
验证不靠目测。两个脚本量化口型是否真的在工作：从人脸坐标文件取真实嘴部框，比较说话段与静音段的帧间差；再计算说话段减静音段的逐像素运动图，确认运动集中在嘴部而非全脸噪声。
这个方法立刻付了学费：第一次测量得出“嘴几乎没动”（比值 0.97×），追查后发现两个后端的坐标文件字段顺序相反（一个 y1,y2,x1,x2，一个 x1,y1,x2,y2），且都没有注释——按直觉顺序读会安静地量到脸旁边的区域，不报任何错。修正后比值 1.52×，运动图峰值精确落在嘴部。
实测数据
同一段素材、同一段音频、同一台机器：
| 指标 | wav2lip256 | MuseTalk v15 |
|---|---|---|
| 渲染帧率 | 24.9–25.1 fps | 24.9–25.1 fps |
| 音频→开口延迟 | 217 ms | 443 ms |
| 启动显存 | 6.2 GB | 9.4 GB |
| 批大小 | 16（默认） | 必须降到 4 |
| 嘴部运动量（说话/静音） | 0.941 | 1.626 |
画质对比是决定性的：wav2lip 的嘴几乎不张开、嘴周有一块发灰的矩形贴片痕迹，边界肉眼可见；MuseTalk 嘴真正张开、可见牙齿、无贴合边界。若必须二选一，MuseTalk 胜——但“若必须”不成立，见结论。
七个非显性故障
这一段可能比数据更有复用价值。共同特征：都不报错，都以“看起来正常”的方式坏掉。
- 显存回退不抛 OOM。高分辨率人脸检测叠加服务占用超出 16GB 时，Windows NVIDIA 驱动不抛异常，而是回退到系统内存——代码里的 OOM 重试逻辑永远不触发，只是慢上百倍，15 分钟卡在第一个批次。
- MuseTalk 高分辨率下的同款陷阱：批大小 16 时启动即占满显存，空闲帧率正常 25，一旦推理崩到 1 fps，音频积压十几秒，全程 0 异常。
- 复制帧卡顿。用
-r 25做 24→25 fps 转换靠复制帧——每秒冻结一帧、间隔规律得刺眼，且被烘进形象帧里，渲染端无法弥补。服务端与浏览器的帧率统计都是完美的 25.0、零丢帧。改用运动插值后重复帧归零。 - 0 帧静默完成。视频路径打不开时，抽帧工具不报错、任务照样上报 completed 100%，错误要到播放时才以除零异常出现在另一个线程。
- 脏目录污染。重新生成形象不清空旧帧目录，用更短素材重生成时，上一版的尾部帧会留下来——而且恰好接在精心处理的无缝接缝之后，把接缝破坏掉。
- LatentSync 的路径陷阱：内部 ffmpeg 命令未对带空格的路径加引号，中间文件静默缺失，最终以一个看似“人脸检测失败”的堆栈崩溃——真正的原因隐藏在两层之外。
- 坐标顺序陷阱（见上文测试方法一节）。
放弃的判断
放弃不是因为跑不通——三个方案都跑通了，帧率都稳。放弃是因为：
- 质感差距是质变而非量变。与成熟商业方案对比，开源方案的贴片边界、微表情缺失、恐怖谷观感不是参数问题，是模型代差。
- 这条路线的三难困境：超写实风格的实时表情 + 口型 + 动作控制，当前要么需要远超消费级的显存（更大的模型），要么接受秒级延迟（更重的离线管线），要么接受画质妥协（轻量模型）。三个都不可接受时，这条路在这个时间点就是墙。
对本项目而言，出路是重新定义问题：放弃“嘴对上每一个字”，改为预渲染的高质量剪辑池 + 独立的语音层。画面质感与声音质感各自保住，代价是口型不同步——实际体验中，这个代价远小于恐怖谷。
留下的东西
这条被放弃的路线留下了可复用的产物：正向播放模式与 25fps 插值转换工具（已按上游许可修改）、0 帧守卫、脏目录清理，以及本文的验证方法。最重要的遗产是一个工作原则：每个“看起来正常”都值得用数据再确认一次。