HelixWorld 的显存占用没有一个能照抄的固定值：它随分辨率或帧尺寸、单帧采样步数、批量或并发数、精度类型、缓存长度，以及你用的驱动和 CUDA 版本一起变。所以「吃多少显存」这个问题只能在你自己那台机器、你自己那套参数档上回答。判断「单卡能不能撑住实时交互」也同理——先量出启动前后的显存差值，再量出固定长度交互下的单帧耗时分布，最后拿这两个读数去比你显卡的实际可用余量和交互要求的上限。下面给的是三步测量、一张对照表、一套判瓶颈规则，参数名一律以仓库配置文件里真实存在的字段为准。

不要用「显存总量减模型权重」估算占用，启动前后差值、运行峰值差值才是能复核的数。先跑固定帧数、固定输入的交互，把单帧耗时记成分布而不是平均值；显卡利用率高、显存留有余量，瓶颈在算力，优先降步数；利用率低而耗时抖动大，多半卡在数据搬运，先查主机与设备之间的拷贝。任一项结论只在记录的参数档和硬件上成立，换分辨率或换机器都要重测。

确认启动前后显存读数的差值

别把整张卡的显存都算在模型头上。进程还没加载权重时，CUDA context、驱动侧预留、桌面合成器以及其他残留进程已经吃掉一部分；权重加载后常驻占用再涨一截；真正跑起来时临时张量和缓存又会把峰值顶高一档。这三段要分开采，采之前先把其他在用 GPU 的进程停掉，否则差值里混着别人的占用。

# 加载前，先采一次（连采三次看稳定性）
nvidia-smi `--query-gpu`=index,memory.total,memory.used,memory.free `--format`=csv

# 需要连续采样时，记录到文件再取稳定值
nvidia-smi `--query-gpu`=memory.used `--format`=csv,noheader,nounits -lms 200 > vram_before.csv

# 模型进程启动、加载完成但还没跑交互时，再采一次
nvidia-smi `--query-gpu`=memory.used `--format`=csv,noheader,nounits

# 交互跑起来时再采一次（或直接看第 2 节的 torch 峰值）
nvidia-smi `--query-gpu`=memory.used `--format`=csv,noheader,nounits

计算方式：常驻占用 = 加载后空闲读数 − 加载前读数，运行峰值占用 = 运行期最高读数 − 加载前读数。多卡机器上 memory.used 会输出多行，要按 GPU index 对齐，别把整机合计当成单卡占用。如果加载前后差值明显小于你预期的权重体积，先怀疑权重是懒加载或分片加载，跑过一帧再采一次。

跑固定长度的交互并记录单帧耗时分布

实时交互关心的是最慢那几帧，不是一个平均值。用固定的输入尺寸、固定的帧数（比如连续 100 到 300 帧）、固定随机种子跑一遍，把每帧耗时逐条记下来。计时必须做 CUDA 同步，否则只量到任务入队的时间，结果会好看得离谱。下面的骨架可以直接放进你仓库的评测脚本里，把 model.step 换成实际的推理入口。

import time, csv, torch

torch.cuda.synchronize()
rows = []
for i, sample in enumerate(loader):
    torch.cuda.reset_peak_memory_stats()
    torch.cuda.synchronize()
    t0 = time.perf_counter()
    out = model.step(sample)          # 替换为仓库里的实际推理入口
    torch.cuda.synchronize()          # 不同步，计时无效
    ms = (time.perf_counter() - t0) * 1000
    rows.append({
        'frame': i,
        'warmup': int(i < 10),        # 前若干帧单独标记，统计时剔除
        'ms': round(ms, 2),
        'peak_alloc_mb': round(torch.cuda.max_memory_allocated() / 2**20, 1),
        'peak_reserved_mb': round(torch.cuda.max_memory_reserved() / 2**20, 1),
    })

with open('frame_log.csv', 'w', newline='') as f:
    w = csv.DictWriter(f, fieldnames=rows[0].keys())
    w.writeheader(); w.writerows(rows)

记录字段至少四项：帧号、单帧耗时（毫秒）、该帧显存峰值（allocated 与 reserved 都记，两者差距大说明有碎片或缓存没释放）、是否预热帧。跑完统计 P50、P90、P99 和最慢帧，同时看清第一帧比稳态慢多少——首帧通常包含编译和缓存初始化，不能算进实时基线。

一次只改一个可调参数做对照

找到性价比最高那一档的办法只有对照，不能靠猜。每轮只改一个参数，其余全部锁死，跑同样帧数、同样输入，各记一份 frame_log.csv。参数名以配置文件里实际存在的字段为准，下面这份表格只是留位：

常见的候选是分辨率或帧尺寸、采样步数、批量或并发数、精度类型、缓存或上下文长度、分块尺寸。降低分辨率通常同时减少显存和算力，但画面质量变化要一起看；降低采样步数主要省算力，显存改善有限。哪一档的延迟下降在你能接受的画质边界内，就停在那一档，不要继续往下压。

判断瓶颈在显存、算力还是数据搬运

换硬件之前先做这个判断，否则很容易花钱买错方向。同时看三样：nvidia-smi 里的 GPU 利用率和显存占用、主机侧 CPU 占用、以及单帧耗时的抖动幅度。

• 显存瓶颈：接近卡容量、出现 OOM、或 reserved 远高于 allocated 且逐帧上涨。下一步是降分辨率、降精度、缩短缓存或减少并发，先让它稳定跑完再说延迟。
• 算力瓶颈：GPU 利用率持续接近满载，显存仍有余量，单帧耗时随步数近似线性增长。下一步是减步数、减小模型或换更强的卡，调数据管道没用。
• 数据搬运瓶颈：GPU 利用率低且波动，主机 CPU 某几个核吃满，首帧与后续帧差距大，耗时抖动明显但显存不紧张。下一步是查预处理是否在 CPU 上重复做、主机与设备之间是否有逐帧往返拷贝、有没有做预取。

把模型卸载到主机内存只能让任务跑起来，代价是延迟更差，它不是性能方案，只适合本地验证。判定「撑得住」的标准建议写成条件式：在锁定的参数档和输入尺寸下，P99 单帧耗时低于你的交互间隔要求，且整段交互期间显存峰值留有一定余量（通常建议留出能让系统和其他进程正常运行的空白），并且连续跑满你预期的最长会话不 OOM。三条都满足才算撑得住，缺一条就要回到前面几节改参数。

把结论写回自己的运行参数

测完就把参数固定下来，写成一份可复现的配置，和日志放在一起。下次换机器或换版本，重跑同一份配置就能对比，而不是凭印象说「好像变快了」。

# run_profile.yaml（字段名按仓库配置文件实际项替换）
run_name: helixworld_interactive_baseline
resolution: <你的固定值>
steps: <你的固定值>
batch_or_concurrency: <你的固定值>
dtype: <你的固定值>
cache_len: <你的固定值>
frames: 200
warmup_frames: 10
seed: <你的固定值>

配套的实测记录建议单列一份纯文本，包含：机器与显卡型号、驱动和 CUDA 版本、仓库提交号、上面这份配置、加载前后显存差值、运行峰值显存、P50/P90/P99 单帧耗时、最慢帧编号、以及是否出现 OOM。结论只在这个组合下成立，换分辨率、换并发、换驱动都要重新量一遍。