你正在一个 AI 生成的虚拟世界里行走。系统忽然把会话从繁忙的 GPU 换到另一块 GPU。画面看着没断，门的位置却变了，刚才拿起的东西也不见了。对普通网页，这或许只是一次重新加载；对交互世界模型，却意味着原来的世界已经结束。
论文 Stateful Worlds, Stateless Elasticity: Exact-State Serving for Interactive World Models 讨论的正是这次“搬家”。作者 Jin Li 与 Jiawei Chen 提出 WorldMove：迁移一个仍在运行的会话时，新 GPU 收到的内部状态必须与旧 GPU 逐比特相同，否则就不启用副本。它想解决的不是模型怎样生成更好的世界，而是这些世界上线以后，怎样接受扩容、维护和负载调度，又不在换机器时悄悄改变。
需要先说明，本文的性能数字和结论都来自作者论文及其自报实验，目前没有独立复现或第三方测评。
难搬的不是模型，而是正在发生的世界
在线服务通常喜欢“弹性调度”——负载升高就增加计算资源，并把任务从忙碌设备挪到空闲设备。无状态请求很好处理：换一台机器，再算一次即可。但交互世界模型属于有状态服务。它不只接收用户此刻的动作，还要保存此前演化出的内部状态，就像游戏服务器必须记住玩家、物体和地图现在在哪里。
这里最重的一件行李是 attention cache，也就是注意力缓存。它与大语言模型里的 KV Cache 类似：模型把处理历史时产生的中间结果留在 GPU 显存里，免得每走一步都从头计算。论文测量的 Matrix-Game 2.0 实例，每个会话有 5.32 GB KV Cache；其中实际迁移的部分为 1.67 GB。更麻烦的是，这不是一箱封好后不再变化的档案。作者称，每个生成步骤会改写约四分之三的缓存。
因此，常见的迁移办法都遇到麻烦。重新计算赶不上交互时限；近似恢复会改变世界；先复制旧内容、再补少量变化的传统方案，也很难追上一份持续大面积改写的状态。会话于是被固定在原 GPU 上，弹性调度失去作用。
WorldMove 怎样保证“搬完还是原来的世界”
WorldMove 的核心思路很克制：不猜哪些内容可以丢，也不接受“看起来差不多”，而是把需要保留的状态展平、传输、校验，再在目标端恢复。目标 GPU 先把数据放进一个不对外服务的影子位置。只有状态指纹确认两端字节完全一致，系统才提交迁移；校验失败，就保持原会话不动。
这叫位级一致（bit-identical）：迁移前后每一个二进制位都相同。它比画面相似严格得多。作者报告，一台租用主机的 GPU 直连路径曾在传输中悄悄损坏数据。端点 CRC 校验——一种用校验值发现数据变化的方法——拦住了这次错误，因此损坏的世界没有被启用。
同节点实验中，WorldMove 在两块 H100 之间搬运 1.67 GB、450 个张量叶节点，用时 18.8 ms。按作者比较，这比 save/load 快 101 倍。另一组 2×A800 实验把迁移放进真实生成循环：会话在 GPU 0 运行，在视频块边界迁到 GPU 1，再继续生成。预热目标引擎后，安装耗时 101.2 ms，在论文采用的交互期限内没有增加 deadline miss——也就是没有新增超时。
作者还让迁移器追赶一个正在生成、因而持续改写缓存的会话。预复制阶段无法在生成期间收敛；一旦模型到达 block boundary（一个视频块生成结束、可安全暂停的边界），最后一轮复制便完成。目标端随后生成的三个块，与源端假设不迁移时的后续结果逐比特一致。
先判断能不能搬，再决定搬不搬
WorldMove 不认为每次迁移都应该执行。论文提出一个准入条件：迁移必须在 readout horizon 内完成。这个词指用户能够容忍的读取或停顿期限；同时，可用带宽还必须覆盖完整状态以及生成期间继续产生的改写量。
可以把它理解为搬一块不断被人改写的白板。卡车不仅要装下白板当前的全部内容，还要追上搬运期间新增的笔迹，并在下一次展示前完成校验。如果网络太慢，或者多路迁移同时涌向一个接收端，系统就应直接拒绝这次搬家，而不是冒险超时。
这也解释了论文另一个重要发现：传对字节，不等于按时传完。作者在 100 Gb 网络上报告了经 checksum 验证的 92.1–94.8 Gb/s 吞吐。但多个发送端同时向一个接收端传输时，会形成 incast——许多流量在同一时刻汇入一个入口。接收路径上的校验可能让传输停顿到协议计时器的时间尺度；即使最终收到的每个字节都正确，吞吐仍可能崩塌。
论文据此加入理解 incast 的准入控制器。在作者设置的 1.4 倍 offered load——请求负载达到系统基准承载量的 1.4 倍——下，它保持零超时，并把无法承受的迁移明确拒绝。作者还测试了无损 GPU 编解码器：它不改变恢复后的状态，只压缩线上载荷，让一些原始搬运无法及时完成的网络也可能通过准入门槛。
为什么值得现在看
这项工作的价值，在于把“一个用户占住一块 GPU”重新定义为调度问题，而不是世界模型不可改变的宿命。只要状态体积、改写速度、网络带宽和交互期限都能测量，系统就能判断某次迁移是否安全，也能为整理 GPU 碎片、维护撤离和故障切换留下空间。
作者报告，受该条件控制的整合循环在两个云提供商上完成了 48/48 次迁移，全部保持位级一致。这个结果仍不能证明系统已经适合普遍部署，但它指出了一个容易被忽略的事实：在线世界模型的扩展能力，不只取决于模型推理多快，还取决于网络能否在期限内搬走并验证一整个持续变化的世界。
局限与未知
- 位级一致只在同一种 GPU architecture（GPU 架构）的受控配置内成立。跨架构运行会从第一个生成块开始出现缓存差异，因此这里的“无缝换 GPU”不包括任意 GPU、跨代或跨架构迁移。
- 论文分别完成了 serving loop（服务循环）和 mover（迁移器）的端到端实验，但尚未在同一条高速网络上构建二者完整组合的系统，不能把它描述成已经完成的生产级方案。
- 论文的一些摘要数字缺少完整部署上下文，例如两个云提供商的名称、部分网络拓扑和准入期限。18.8 ms、92.1–94.8 Gb/s、48/48 与零超时等结果适用于作者的实验配置，不能直接外推到一般部署。