拿到 LingBot-Video 之后，真正卡人的不是模型能不能出结果，而是这次推理到底该喂文本指令、喂动作序列，还是两者一起。多数开源仓库会把这两类输入做成不同的入口或不同的字段——文本走语言分支，动作走条件分支；把动作数组塞进文本字段、或者同时给两条路径各塞一份，最常见的表现是参数解析阶段直接报错，或者跑出了一个时长、帧率对不上的输出，却不知道错在哪一步。稳妥的顺序是：先在仓库里定位推理入口和输入字段，再单独跑通一条文本指令，然后换成动作序列跑第二遍做对照，最后才去试帧数与分辨率的变化边界。

LingBot-Video 上手阶段建议把文本指令和动作序列当成两条独立输入路径来验证：先定位推理脚本里实际解析的字段，确认哪些必填、哪些是二选一；再分别用纯文本和纯动作序列各跑一次最小前向，比较输出文件的时长、帧率和大小；确认单路都能跑通之后，再考虑组合输入。混喂通常先在参数解析或张量形状拼接处失败，报错关键词会指向具体那一步，不要靠猜。适用边界是本地单机、单次推理的调试场景，批量与生产规模的输入约束需要另行测试。

在开源仓库里定位推理入口和输入字段

不要凭印象猜模型吃什么。先看仓库目录，常见的结构是 configs/、scripts/ 或 inference/、models/、requirements.txt，推理入口一般就在 scripts 或 inference 目录下的某个 *.py。用两条命令基本能锁定：

grep -rn "def main\|if __name__\|argparse\|ArgumentParser" `--include`=*.py .
grep -rn "add_argument" `--include`=*.py . | head -50

第二条命令的输出就是输入字段清单。判断必填不要只看提示文字，要看 add_argument 里有没有 required=True，或者读后续代码里该变量被直接用、没有兜底默认值。下面这张表是按常见形态整理的对照，字段名要以你本地仓库实际输出为准，替换后再用。

如果发现文本字段和动作字段在同一个入口里独立成两个分支，说明仓库默认就是分开调用的；如果两个字段被拼进同一个 batch 或同一个条件张量，就要格外注意顺序和维度，别把动作数组当成附加文本。

用一条文本指令跑通最小前向

先只喂文本，目的是确认环境和依赖能撑起一次完整推理。装依赖按仓库说明走，没有说明时优先 requirements.txt；涉及 CUDA 版本的部分要对齐本机驱动，版本错配会在导入阶段就报错。

python -m pip install -r requirements.txt
python scripts/infer.py `--ckpt` ./weights/model.pth `--prompt` "a robot arm picks up a cube" `--num`_frames 16 `--output` ./outputs/text_run.mp4

命令里的脚本路径、参数名都按上一节 grep 出来的真实字段替换。跑完后先确认输出落在 `--output` 指定的位置，再看格式：视频类通常是 mp4 或一组帧图目录，配置文件里可能还会额外写出一个 json 记录参数。首次运行的耗时主要花在权重加载和设备初始化上，通常比同一进程内的后续调用慢；具体秒数受硬件、权重体积和分辨率影响，用 time 自己记一次即可，不要照搬别人的数字。这一步跑通，说明文本路径可用，后面才有对照基准。

把文本换成动作序列再跑一次

动作序列样例按你自己的机器人接口导出，一个可替换的起点是形状 [16, 7] 的数组：16 帧、每帧 7 维（位置三维、姿态三维、夹爪一维），存成 npy 或 json 后由脚本加载。把上一步的命令改成动作分支，文本字段留空或直接不传：

python scripts/infer.py `--ckpt` ./weights/model.pth `--action` ./samples/action_16x7.npy `--num`_frames 16 `--output` ./outputs/action_run.mp4

两次输出要放在同一条件下比较，才有判断价值。用下面几条命令各取一组读数，填进自己的记录表：

ffprobe -v error -show_entries format=duration:stream=avg_frame_rate,width,height -of default=nw=1 ./outputs/text_run.mp4
ffprobe -v error -show_entries format=duration:stream=avg_frame_rate,width,height -of default=nw=1 ./outputs/action_run.mp4
ls -lh ./outputs/*.mp4

重点看三件事：时长是否对得上输入帧数与默认帧率、输出分辨率是否被动作维度间接影响、文件大小差距是否在合理范围内。如果动作序列跑出来时长明显偏离 num_frames 除以帧率的结果，先怀疑动作帧数与 num_frames 不一致，而不是怀疑模型本身。混喂文本与动作序列时，很多仓库会在拼接处把动作张量当成额外 token 或相反，输出会出现画面正常但语义漂移、或直接形状报错，这个差异值得单独记一次再决定要不要组合输入。

记录帧数与分辨率变化时的资源占用

找出本机可承受的规模边界，靠的是把 num_frames 和分辨率参数逐个往上加，同时盯住显存和内存。参数就在前面那条命令里，改完立刻重跑。读数建议开两个窗口或者用带时间戳的采样命令，别只看最后一眼：

nvidia-smi `--query-gpu`=memory.used,memory.total `--format`=csv -l 1
/usr/bin/time -v python scripts/infer.py `--ckpt` ./weights/model.pth `--prompt` "..." `--num`_frames 32 `--output` ./outputs/f32.mp4

先从 num_frames=16 起步，再试 32、64；分辨率同理按配置文件里能改的最小步长往上加。显存或内存顶不住时，报错通常形如 torch.cuda.OutOfMemoryError: CUDA out of memory，或者被系统 OOM killer 杀掉并出现 Killed。前一种指向显存不够，常见于帧数或分辨率单次上采样过猛；后一种指向主机内存不够，常见于一次把过多帧读进内存、或者数据加载进程数开太多。把每一档的帧数、分辨率、峰值显存和是否成功记成一行，边界自然就出来了。

把可复现的输入范围写成一句话边界

把这轮试出来的结果压成一句话规则，放到后续自建流程的配置注释里，比放一堆截图有用。推荐的写法是：在明确硬件与权重版本下，文本输入使用 num_frames 与分辨率某个区间可稳定跑通，动作输入需保证动作帧数与 num_frames 一致，两类输入不要在同一次调用里同时提供。

报错关键词和对应步骤可以一起记下来，方便排查：出现 argparse 相关的 unrecognized arguments 或 the following arguments are required，说明卡在参数解析这一步，字段名或必填项写错了；出现 shape、dimension 或 size mismatch 这类报错，说明卡在输入张量拼接或动作维度校验这一步，重点查动作序列的第二维是否和模型期望一致；出现 CUDA out of memory 则卡在模型前向的设备内存分配，降帧数或降分辨率再试；出现 Killed 则卡在主机内存，先检查数据加载和帧缓存方式。能稳定跑通的组合、会报错的组合、以及报错关键词各自落在哪一步，这三样写清楚，后面的流程就不用每次重新摸边界了。