TalkLikeYou 模型加载慢、显存占用高、输出帧不稳、先量清显存和批大小

TalkLikeYou 这类实时数字人本地运行，加载慢、显存吃满、输出帧不稳，通常对应三个可测量的变量：批大小、输入分辨率、以及模型加载与推理各自占用的显存。判断顺序建议是——先在加载前、加载完成后、连续推理中三个时间点记录显存，确认峰值出现在哪一段；再固定同一段音频和图像做单变量对比，把显存和帧率的变化归因到某一个参数；最后按你能接受的最低帧率和显存余量挑组合。换设备通常是最后一步，因为不先量清变量，换了机器也未必知道瓶颈在哪。

加载慢和帧不稳往往不是同一个原因：显存吃满多与批大小、输入分辨率有关，帧间隔抖动则可能来自计算量偏大或输入队列积压。建议先用 nvidia-smi 按秒采样，分清显存峰值出现在加载阶段还是推理阶段，再固定同一段音频和图像做单变量对比。确认可接受的最低帧率后，在显存余量内选批大小与分辨率组合；余量的具体数值需要结合本机环境确认，不建议照搬他人配置。

用 nvidia-smi 或等价工具记录加载前后的显存变化

目的是分清显存峰值出现的阶段：如果加载完成、还没开始推理就接近上限，那问题在模型与权重加载；如果是推理中才涨上去，那更可能和批大小、输入分辨率、缓存帧数有关。可以先开一个终端持续采样，再在另一个终端启动服务。

# 终端 A：每秒采样一次，输出到日志，方便回看
nvidia-smi `--query-gpu`=timestamp,index,memory.used,memory.total,utilization.gpu \
  `--format`=csv -l 1 > gpu_mem.csv

# 若 nvidia-smi -l 在你的环境不可用，可以改用循环采样
while true; do
  date +%s
  nvidia-smi `--query-gpu`=memory.used `--format`=csv,noheader
  sleep 1
done | tee gpu_mem.log

记录时至少标注三个时间点：启动前的空载基线、模型加载完成后（还没送入第一帧）、连续推理一段时间之后。把这三段的 memory.used 抄进表格，就能看出峰值到底在哪一段。日志里的时间戳和你的操作时间对齐即可，不需要额外工具。

在配置文件中找到批大小和输入分辨率字段

不同仓库的字段名和层级不一样，先搜再改，别照抄别人的配置。可以在项目目录执行：

grep -rniE 'batch_size|batch-size|image_size|resolution|fps|chunk' \
  `--include`='*.yaml' `--include`='*.yml' `--include`='*.json' `--include`='*.toml' .

下面是一个通用配置片段示意，字段名以你仓库的实际配置为准，这里不代替真实参数名：

model:
  device: cuda:0
  dtype: fp16          # 有 fp16/bf16 时优先试半精度，属于可测量项
inference:
  batch_size: 4        # 批大小，常见可调项
  fps: 25              # 目标输出帧率
  num_worker: 2        # 并行工作线程，影响队列积压
input:
  image_size: 512      # 图像/人脸区域输入分辨率
  audio_chunk_ms: 500  # 音频切片长度，同样会影响显存与延迟

改之前先复制一份配置当基线，后面做对比时只动一个字段，其余保持原样。如果代码里还有 CLI 参数覆盖配置，记得先确认哪一边生效，避免改了文件却没起作用。

固定音频和图像输入做单变量对比

单变量对比的意义是：一次只改一个参数，显存和帧率的变化才能归因。准备一段固定音频和一张固定图像，跑同样时长，先做批大小对比，再做分辨率对比。命令骨架如下，参数名以实际 CLI 为准；若没有对应参数，就直接改配置文件副本再启动。

# 基线组：分辨率不变，只改批大小
python app.py `--config` config_base.yaml `--batch-size` 1
python app.py `--config` config_base.yaml `--batch-size` 4

# 对照组：批大小不变，只改输入分辨率
python app.py `--config` config_base.yaml `--batch-size` 2 `--image-size` 256
python app.py `--config` config_base.yaml `--batch-size` 2 `--image-size` 512

每次启动前清空上一次的采样日志，跑完后分别记录：加载后显存、推理中显存峰值、以及同一段输入的平均帧率。平均帧率可以先用日志里输出帧数除以运行时长算出，后面再用脚本做更细的统计。如果改批大小后显存几乎不动但帧率下降，瓶颈更可能在计算或调度，而不是显存。

用脚本统计连续推理的帧间隔和掉帧次数

平均帧率会掩盖抖动：可能平均看着够，但每隔一段就卡一帧。用下面这个骨架统计帧间隔，可以判断是计算量偏大还是输入队列积压。

import time

N = 200
target_fps = 25
threshold = 1.0 / target_fps * 1.5   # 超过目标帧间隔约一点五倍记为一次明显掉帧

frame_times = []
prev = time.perf_counter()
for i in range(N):
    run_once(model, frame)          # 替换成实际的单帧推理调用
    now = time.perf_counter()
    frame_times.append(now - prev)
    prev = now

avg = sum(frame_times) / len(frame_times)
mx = max(frame_times)
over = sum(1 for d in frame_times if d > threshold)
print(f'avg={avg*1000:.1f}ms max={mx*1000:.1f}ms over={over}/{len(frame_times)}')

读法：如果平均间隔本身就超过目标帧间隔，说明单帧计算量偏大，优先降分辨率或降批大小；如果平均间隔达标、但最大间隔明显偏大且 over 次数多，更像队列积压或线程调度抖动，可以去看输入队列长度、num_worker 和帧缓存设置。两种情况处理方向不同，不要混着调。

按可接受的最低帧率和显存余量确定配置

先把上面几组测量结果填进同一张表，再据此做取舍。表格模板如下，每一行都用同一段音频和图像、相同推理时长测得。

批大小 | 输入分辨率 | 显存峰值(MiB) | 平均帧率(FPS) | 最大帧间隔(ms) | 备注
1     | 256        |               |                |                |
1     | 512        |               |                |                |
2     | 256        |               |                |                |
2     | 512        |               |                |                |
4     | 512        |               |                |                |

选择顺序建议是：先写下你能接受的最低帧率，筛掉平均帧率不达标的行；再看剩下的行里，显存峰值是否给系统和其它进程留出余量。余量留多少需要结合本机环境确认，通常不建议贴着显卡上限跑，因为加载峰值和推理峰值不一定同时出现，留一点空间能减少意外。在满足帧率和余量的行里，优先选分辨率更高的一行，因为画质通常比批大小更影响观感；如果所有行都超出余量，先降分辨率再考虑降批大小或换设备。