手上只有一张消费级卡，想知道 Cosmos 3 Edge 这个 4B 参数模型能不能跑，答案不在参数量本身，而在你打算喂给它的输入规模上。权重只决定显存账的起点，推理过程中的激活和缓存才是把显存撑爆的那部分。比较稳妥的做法是：先按精度算出权重下限，用一个只加载不推理的探针脚本量出加载占用，再逐项把推理开销加回来，最后用自己测到的数字判断要不要换卡。

4B 模型在 fp16/bf16 下权重约 7.5–8 GiB，8bit 约 3.7–4 GiB，这只是下限，不含激活、缓存和 CUDA 上下文。建议先用探针脚本把加载占用和推理峰值分开计量，再按帧数、分辨率、精度的顺序逐项加压。能否在消费级卡上跑，以自己环境里读到的 max_memory_allocated 为准；同一张卡换了驱动、框架版本或输入尺寸，结果都可能变化。

先把参数量和精度换算成权重占用的理论下限

这一步不用跑任何模型，拿纸笔或者计算器就能做完。公式是：参数量 × 每参字节数 = 权重字节数，再除以 1024³ 换成 GiB。Cosmos 3 Edge 的 4B 通常指约 40 亿参数，按这个口径先算一遍。

这张表给出的数字只能当起点。权重之外至少还有三块固定开销：CUDA 上下文（通常数百 MiB 量级，随驱动和框架变化）、推理框架自己的图与工作区、以及显存分配器的最小分配粒度。所以看到“4B 模型 8 GiB 权重”就认为 8 GiB 卡够用，通常会失望。建议把这张表算出的权重值记成 W，后面所有对比都以 W 为基准看倍数，而不是看绝对数字。

写一个只加载不推理的显存探针脚本

把加载占用和推理占用分开计量，是后面所有判断的前提。如果两件事混在一起测，OOM 时你无法区分是权重本身放不下，还是输入太大。下面是一个通用骨架，放在模型加载脚本的同级目录执行，把 load_model 那一行替换成你实际使用的加载调用即可。

import torch

def report(tag):
    torch.cuda.synchronize()
    alloc = torch.cuda.memory_allocated() / 1024**3
    reserved = torch.cuda.memory_reserved() / 1024**3
    peak = torch.cuda.max_memory_allocated() / 1024**3
    print('[%s] allocated=%.2fGiB reserved=%.2fGiB peak=%.2fGiB' % (tag, alloc, reserved, peak))

report('baseline')                      # 加载前，空进程
model = load_model('/path/to/cosmos-3-edge')   # 替换为实际加载调用
report('after_load')                    # 只加载，不做任何前向

torch.cuda.reset_peak_memory_stats()
# 到这里为止不要调用 model(...)，保持“只加载不推理”

跑完关注三个数：baseline 是空进程占用的底噪；after_load 减去 baseline 才是权重真正吃掉的显存；peak 在加载阶段如果明显高于 allocated，说明存在中转拷贝，峰值判断要按 peak 算。同时建议另开一个终端跑一次 nvidia-smi，它的数字会比你脚本里读到的更大，差额主要是 CUDA 上下文和进程其他占用——两个数都记下来，判断余量时用 nvidia-smi 更保守。验证方式很简单：如果 after_load 阶段就接近显卡容量，那问题不在推理参数，得先换精度或者换卡。

逐项加回推理开销：帧数、分辨率、精度

加载通过之后，再开始加推理。关键是每次只改一个变量，其余固定，否则测出来的数字无法归因。下面三组对照实验，建议按顺序做，每组跑一次就记录一次。

• 第一组只改帧数：分辨率固定、精度固定，帧数从 1 开始逐级往上加，例如 1 → 4 → 8 → 16，直到 OOM 或者业务能接受的上限。
• 第二组只改分辨率：帧数固定在上一组不 OOM 的最大值，精度固定，分辨率按常见档位逐级提高。
• 第三组只改精度：帧数和分辨率都固定在前两组的安全值，把精度在 fp16/bf16 与 8bit 之间切换。

每一组实验都要记录这几个字段：输入帧数、分辨率、精度、max_memory_allocated、是否 OOM、单次前向耗时、以及输出是否还能用。最后一项容易被忽略——降精度之后如果结果明显劣化，那这个档位实际上不可用，记录里要标注清楚，不要只看显存数字好看就采用。

卡在临界值时先降输入规模而不是换卡

如果峰值显存离显卡容量只差一点，先别急着升级硬件，按下面的顺序降，通常前两步就能腾出空间。每一步只改一个维度，改完立刻重跑探针脚本看 max_memory_allocated 和是否 OOM。

1. 先降帧数。看峰值显存的下降幅度，同时确认业务上能接受的最少帧数是多少。这一步对显存的影响通常最直接，对输出可用性的影响却未必最大。
2. 再降分辨率。固定已经降好的帧数，逐步降低分辨率，看峰值显存与输出细节的变化。这里要盯的是画面细节是否还满足用途，而不只是显存降了多少。
3. 最后降精度。前两步都不够时再动精度，从 fp16/bf16 切到 8bit。看的是两件事：峰值显存是否降到容量以内，以及同样输入下的输出质量能否接受。

不建议一上来就用 CPU offload、显存换页或量化到更低比特这类手段。它们能让进程不 OOM，但会显著拖慢单次推理，把问题从“跑不动”变成“跑得极慢”，对交互式场景帮助有限。把 offload 当作临时验证手段可以，当作长期方案要谨慎。

把实测值转成选卡判断

测完之后，把数据填进下面这张表，它就变成了你自己的选卡依据。填法是：每一行对应一次成功的推理配置，峰值显存填 max_memory_allocated，帧数和分辨率填该次实际使用的值，最后一行写“余量”一栏——建议至少留出总显存的一成到两成给系统和其他进程，不要贴着上限跑。

填完之后，判断逻辑就很简单：如果你的常用配置那一行“是否留有余量”是“否”，那这张卡在这个输入规模下就是临界状态，要么降一档输入，要么换卡；如果最上面那行最小可用配置都留不出余量，那这张卡基本不适合跑 Cosmos 3 Edge，换卡才有意义。

外推的时候要小心几点：这些数字只对当前的驱动版本、框架版本、推理后端、以及没有其他进程抢占显存的条件下成立。换驱动、换框架、开启或关闭某些算子实现、同一张卡上同时跑别的任务，都会让峰值显存变化。所以表里记录的环境信息要一并写上，下次对比时才有意义。