一张消费级显卡跑住游戏世界：单卡世界模型要先算三笔代价
一、这笔交换到底换掉了什么
据公开报道，有一个做视频生成的游戏世界模型团队开源了代码与权重，并被报道称可以在一张消费级显卡上运行。我们没有跑过这套权重，公开报道里出现的帧率、分辨率、参数量与名次都不作为本篇的任何判据，那些数字既不需要我们复算，也不构成任何选型结论。值得单独拎出来的只有一句话：单卡不是免费的。把世界模型压进一张卡，本质是拿质量维度去换部署维度，换回来的东西很实在，一台工作站就能起服务、数据不用出门、并发成本可预测；换出去的东西则要在被压缩的三项上逐项清点。
先立一条纪律：不要把某一款机型当成唯一可行硬件。单卡可行性由四个变量的组合决定，换一张卡只是改变预算总量，组合本身不变。所以下面所有口径都按”给定一张卡”来写，具体是哪张卡留给读者自己的预算去回答。
三笔代价通常被概括成分辨率、时长与物理一致性，但这三项并不并列。分辨率和时长是显存与算力的表现形式，真正决定这个模型能不能被使用的是物理一致性，而它又要拆成三个可测的维度：时间、空间、因果。
二、三笔代价要先有测量口径
| 代价项 | 测什么 | 可操作的测法 | 不合格信号 |
|---|---|---|---|
| 时间一致性 | 连续操作之后，场景能否回到原来的状态 | 预先写好一条回环操作序列：前进若干步、转向、再原路返回；把起点帧与回到原点那一帧对同一批标注物体做属性对照，比在不在、朝向、外观细节，至少重复十次 | 回到原位后物体消失或换了外观；同一条序列每次回环结果都不一样 |
| 空间一致性 | 视角改变、被遮挡再露出时，物体是否还是同一个 | 在同一场景里对固定目标做环绕、拉远、经过遮挡物后重访；每个重访点记录一次对照结论，重点看几何关系与标识文字 | 遮挡重访后物体被替换；视差不连续；场景里的标识每次被重新画一遍 |
| 因果延迟 | 从输入动作到画面出现对应变化的滞后，是否可感知、是否稳定 | 用输入时刻已知的事件打点，与画面变化所在帧对齐，记录中位数与波动区间，不看平均值 | 延迟本身可接受但抖动很大；出现因果错位，比如按下跳跃后先落地再起跳 |
表格里最容易被糊弄过去的是测法那一列。人眼看着挺连贯不算测过，因为人脑会自动补全不一致。可复用的做法是把操作序列写成脚本，把要对照的物体和属性提前标成清单，事后逐帧核对，而不是实时盯着屏幕打分。另外报告要分桶：训练分布内的场景与换风格之后的场景各报一组，只报前者等于没报。
三、决定单卡可行性的四个变量
| 变量 | 它在消耗什么 | 压缩之后的典型副作用 | 怎么定标 |
|---|---|---|---|
| 上下文窗口长度 | 历史帧占用的显存与算力，通常是单卡上最大的一项 | 几秒之后场景被遗忘，物体身份漂移，回环测试大面积失败 | 用业务动作定下限：完成一次标准操作序列之后，还能不能看见起点状态。不看任何宣传口径 |
| 每帧的潜空间预算 | 分辨率、通道、去噪步数与一次生成的帧数相乘出来的开销 | 细节丢失、纹理发糊、小目标不可辨认 | 把下游决策要读到的最小物体换算成像素，倒推预算下限，再决定牺牲哪一项 |
| 精度模式 | 权重与激活的数值存算方式，省显存最直接 | 长序列误差累积、色彩缓慢漂移、偶发崩坏帧 | 同一脚本在两种精度下各跑若干遍，比对回环一致率与崩坏率，而不是比单帧观感 |
| 是否把物理与碰撞交给外部引擎 | 状态归属：生成器自己维持世界，还是只负责出画面 | 自己维持时物理约束会被生成掉；交给引擎时画面与几何边界处容易不一致 | 先回答谁拥有世界状态：碰撞、刚体、可交互对象是否由引擎给出确定答案，再谈画质 |
这四个变量互相耦合。窗口拉长会挤掉每帧预算，预算不够就有人倾向降精度，而降精度在长序列上的代价恰好落在时间一致性上。一张卡能不能跑住一个世界，取决于这圈耦合里有没有一组参数同时满足业务下限，跟某一次实测的漂亮数字关系不大。第四个变量最容易被忽略，却决定上限：世界状态如果由生成器自己维持，一致性只能靠统计规律去赌；如果交给外部引擎，一致性问题就变成接口问题，工程上可控得多。
四、能跑不等于能用来做决策
视觉流畅与状态可依赖是两类评测，混在一起做会得到一个危险的结论：画面看起来没问题，于是下游系统开始相信它输出的状态。要分开，至少按下面四步。
- 把验收问题改写成可判定句子。这个世界像不像真不合格，打开门之后房间里的物体是否和上次进入时一致才合格。
- 建一组操作剧本，覆盖回环、遮挡重访、快速转向、静止一段时间后重新操作四类，每类固定输入顺序。
- 帧级留证。把输入事件的时间戳与生成帧序号一起落盘，事后对照，允许复核，不依赖当时在场的人的主观印象。
- 分桶报最差而不是报平均。同一模型在不同精度、不同窗口长度下的结果要分开列，平均值会掩盖崩坏率。
只有把第 2 步与第 3 步合起来，才谈得上能用来做决策。第 1 类评测做得再细，也只是在证明这个模型很会画。
五、开源权重之后，工作量才刚开始
代码和权重公开，省掉的是训练，省不掉的是把别人的仓库变成可交付系统。三块工作量要提前排进预算。
- 依赖复现：环境依赖的版本配对、算子与后端库、权重分片与索引文件、配置里那些没写进文档的隐含约定。这一步在异构显卡上的移植成本尤其容易被低估，算子覆盖度和精度模式的支持程度都要现场验。
- 推理与训练分离：不少公开仓库只给推理侧。要判断能不能做域内适配、能不能微调，得看有没有训练入口、数据构造脚本和关键超参。缺任何一项，开源就只意味着可以调用，不意味着可以改造。
- 许可证逐条读：开源不等于可商用。商用条款、再分发条款（衍生权重要不要按同样条款发布）、生成内容的归属与标识义务、禁用场景，这四件事要分别确认。在逐条读完之前，我们不会把它写进任何给客户的方案里，也不替读者断言这套权重可以商用。
技术报告不等于复现说明。它讲的是结果怎么得到，不一定讲环境怎么搭、随机性怎么控、评测脚本放在哪里。按一个需要自己搭脚手架的模型来排期，比按一个下载即用的服务来排期更接近真实工时。
六、接进业务前的四道检查，以及什么时候该选单卡
四道检查，按顺序问。
- 输入分布：我方实际场景与训练时见过的画面差多远。换一种美术风格、换一类操作节奏，都属于分布外。
- 失败模式：坏起来是什么样子。崩坏帧、状态漂移、显存溢出、进程卡死，每一种都要有检测手段和恢复路径，只写一句会偶发异常等于没写。
- 单位成本：一张卡能起几路并发，单路每小时多少钱，里面要含功耗、散热、故障率和人的运维时间。云端按量调用与本地常驻的成本曲线会随并发上升而交叉，交叉点要自己算。
- 责任归属：如果下游动作依赖了这个模型输出的世界状态，出错算谁。这一条最后必须落到合同的验收条款上，不能停在口头共识。
至于什么场景值得为这三笔代价买单，我们的判据是四条：交互链路等不起一次网络往返的延迟敏感场景；现场断网或者数据不能出域的离线场景；长时间大批量生成轨迹、按量账单不可预测的并发场景；需要自己换权重、改条件输入、做域内适配的可控性场景。反过来，需要开放世界泛化、需要长时间可依赖状态、需要复杂因果推演的任务，硬把单卡小模型塞进去，省下的部署钱会以返工的形式还回来。
洹拓在内部讨论这类选型时只设一个入场条件：先把三笔代价的测量口径写出来，再讨论要不要单卡。没有口径的效果很好和能跑起来，在我们这里都不算证据。