PhysisServe 完全拆解：百亿世界模型如何输出千赫兹物理控制信号

问题不只是把世界模型跑快#

2026 年 10 月 13 日，逆矩阵联合智源研究院、vLLM 与北京大学发布了 PhysisServe 技术报告。它面向的不是传统聊天请求，而是 Action-Conditioned World Model（ACWM）与 World Action Model（WAM）这类持续生成物理状态或动作的模型。系统试图回答一个很具体的问题：模型变大以后，能否继续以物理任务要求的频率稳定地产生输出？

语言模型慢一些，通常意味着用户多等几秒；物理智能系统慢一些，可能意味着输出抵达时对应的观测已经过期。机械臂仍在移动，接触状态已经改变，上一时刻正确的动作此刻可能造成碰撞。实时性在这里不是交互体验指标，而是控制闭环的一部分。

这种负载大致分成两类：

ACWM（Action-Conditioned World Model）接收当前观测与动作，持续生成未来画面或潜状态。它可以充当可交互仿真环境，为策略评测、闭环推演或大规模 rollout 提供环境响应。
WAM（World Action Model）接收机器人观测，持续生成可执行动作。它不一定输出可视画面，而可能直接给出动作 chunk 或关节控制序列。

两者的共同点是持续流式生成。请求不是“输入一次、返回一次”，而是一条长时间存活、内部带状态、必须周期性交付结果的流。通用大模型服务常用的请求级吞吐、首 token 延迟和每 token 延迟仍有参考价值，却不足以描述这种负载。

PhysisServe 的关键判断是：自回归去噪模型内部存在两维可以展开的结构——去噪步与 Transformer block。以往方案只沿其中一维切分，单路请求可使用的 GPU 数量很快触顶；PhysisServe 把两维的笛卡尔积都变成流水线 stage，让不同 chunk 同时占据不同 stage。极限配置很昂贵，但它揭示了一条系统路径：模型总计算量决定填满流水线要多久，最慢 stage 决定流水线填满后多久交付一个新 chunk。

公开系统的量级差距说明了问题为什么值得专门设计。官方报告汇总的 ACWM 中，LingBot-World 约 28B 参数、每步激活约 14B，输出约 16 FPS；MAGI-1 为 24B，在 24 张高端 GPU 上用约 0.98 秒生成 24 帧，折合约 24 FPS。WAM 中，DreamZero 14B 约以 7 Hz 生成 action chunk；LingBot-VA 2.0 约有 15.3B 参数、每 token 激活约 2.5B，生成延迟为 142 毫秒每 chunk。另一端的 Figure S0 能达到 1 kHz 关节级输出，但模型只有约 10M 参数。它们不是严格同机对比，却共同呈现出一个现实：大模型通常在数十赫兹一侧，高频底层控制通常依赖小模型。

“千赫兹输出”究竟指什么#

“千赫兹”很容易被误解成“33B 模型收到新相机帧后，1 毫秒内完成一次端到端推理”。官方报告明确不是这个含义。PhysisServe 测量的是稳定状态下相邻输出的间隔，即 output latency；它不是新观测进入系统后第一次影响输出所需的 response latency。

设第 $i$ 个 chunk 的完成时刻为 $C_i$ ，稳定态输出间隔为：

T_{\mathrm{out}} = C_{i+1} - C_i

对应的 chunk 吞吐率是：

R_{\mathrm{chunk}} = \frac{1}{T_{\mathrm{out}}}

报告中 MiniMax H3 33B 的最短实测输出间隔为 $4.083\ \mathrm{ms}$ ，所以每秒完成的 chunk 数约为：

R_{\mathrm{chunk}} = \frac{1000}{4.083} \approx 244.9\ \mathrm{chunk/s}

“约 1000 帧每秒”是在每个 latent chunk 解码为 4 帧的 ACWM 口径下换算得到的：

R_{\mathrm{frame}} \approx 244.9 \times 4 \approx 980\ \mathrm{frame/s}

如果按 LingBot-VA 2.0 的口径，把一个 latent 换算为 16 个控制步，则得到约 $3919\ \mathrm{Hz}$ ；如果按 DreamZero 的口径，两个 latent 组成一个 action chunk，则约为每秒 $122.5$ 个 action chunk。这三个数描述的是同一条 DiT 去噪流水线按不同输出语义进行的换算，不能互相混用。

还要加上三条限定：

计时只覆盖 DiT 去噪，不包含 VAE 解码、图像预处理、传感器采集、网络传输、动作下发与执行器响应。
这是稳态吞吐，不是首次输出延迟，也不是闭环控制频率的实测值。
MiniMax H3 的极限点使用 50 个 block、4 个去噪步，共 200 个 stage；一 stage 一 GPU 的极限映射对应 200 张 GPU。它说明并行上限可以继续扩展，不代表这是经济的常规部署配置。

因此，更准确的表述是：PhysisServe 让 33B 自回归扩散模型的 DiT 部分在流水线填满后，每约 4.1 毫秒完成一个 latent chunk；该 chunk 按 ACWM 口径相当于约 4 帧。这个成绩依然重要，但其意义是“高频连续交付”，不是“1 毫秒感知到动作”。

自回归去噪为什么能流水化#

逐 token 语言模型存在严格因果依赖：生成 token $y_i$ 之前必须得到 $y_{i-1}$ ，而 $y_{i-1}$ 又要完整经过所有 Transformer block。张量并行可以加快单个 token 的前向，流水线并行却难以让同一序列的多个未来 token 同时穿过不同层，因为未来 token 尚不存在。

自回归去噪的依赖图不同。每个 chunk 从噪声状态开始，依次经过 $D$ 个去噪步；每个去噪步内部又经过 $L$ 个 Transformer block。记 chunk 为 $c$ 、去噪步为 $d$ 、block 为 $l$ ，则一个 stage 可以写成：

s = (d,l), \qquad 0 \le d < D,\quad 0 \le l < L

总 stage 数为：

S = D \times L

每个任务 $X_{c,d,l}$ 有两类依赖。第一类是同一 chunk 的前一 stage，保证它沿模型拓扑向前传播；第二类是前一 chunk 在相同去噪步留下的 KV cache，提供时间上下文。可概括为：

X_{c,d,l} \leftarrow X_{c,d,l-1},\; K_{c-1,d,l}

从去噪状态看，chunk $c$ 在第 $d$ 步持有带噪 latent $z_c^{(d)}$ ，经过该步的网络计算得到更干净的 $z_c^{(d-1)}$ 。网络还要读取历史 chunk 在同一噪声层级的缓存：

z_c^{(d-1)} = \Phi_d\!\left(z_c^{(d)}, K_{<c}^{(d)}, \mathrm{cond}_c\right)

$\Phi_d$ 表示第 $d$ 个去噪更新， $K_{<c}^{(d)}$ 是历史 chunk 在相同去噪层级产生的 KV， $\mathrm{cond}_c$ 是动作、文本或当前观测等条件。如果必须等历史变成最终干净状态 $K_{<c}^{(0)}$ 才能计算当前 chunk，那么依赖边会从当前 chunk 一直连到前一 chunk 的终点，波前无法展开；使用 $K_{<c}^{(d)}$ 则把依赖缩短到同一去噪层级。

这不是单纯的调度技巧，因为模型必须能在这种缓存语义下保持质量。PhysisServe 对 Wan2.1 使用 StreamDiffusionV2 权重，其余测试模型使用基于 Rolling Forcing 二次开发的带噪 KV 适配；它没有声称任意离线视频模型都能不经适配直接套用。

如果模型只允许读取前一 chunk 已完全去噪后的干净 KV，那么 chunk $c$ 必须等待 chunk $c-1$ 走完所有去噪步，跨 chunk 并行被串行依赖封死。PhysisServe 所依赖的模型允许读取前一 chunk 在相同去噪步产生的带噪 KV。于是 chunk $c-1$ 离开某个 stage 后，chunk $c$ 就能跟进；多个 chunk 沿二维依赖图形成对角波前。

图 1：逐 token 自回归必须串行产生 token；自回归去噪的相邻 chunk 可以错开推进。来源：PhysisServe 官方技术报告。

图中右侧第一次输出并没有更早，因为第一个 chunk 仍需穿过完整流水线；优势出现在稳定态：后续 chunk 已在后方 stage 中同时推进，流水线末端能以短得多的间隔连续交付。这个差异正是理解全文的钥匙：PhysisServe 优化的是相邻 chunk 的稳定态间隔，而不是把单个 chunk 的全部依赖消掉。

PhysisServe 的系统架构#

PhysisServe 的设计可以分成三个层次：Stage-wise 流水线压低单路的最短输出间隔；时分复用在较宽松的 SLO 下减少单路占用的 GPU；虚拟 rank 与联合调度让多条流共享整个 GPU 池。三者分别回答“如何更快”“如何少用卡”和“如何服务更多流”。

为什么要细化到 stage#

已有两类流式扩散方案的切分粒度更粗。

Wave Forcing 按去噪步切分。一张 GPU 持有完整模型并负责一个去噪步，所以一条流最多自然扩展到 $D$ 张卡。每个 stage 仍然是整模型前向，稳定态间隔的下界仍受完整模型前向时间约束。模型越深，这个间隔越长。

StreamDiffusionV2 按 Transformer block 切分，把同一 block 在多个去噪步上的任务合成 batch。一条流最多扩展到 $L$ 张卡，稳定态间隔由一个“包含多个去噪步任务的 block batch”决定。去噪步增加时，batch 也变大；当 GPU 数达到 block 数后，继续加卡不会自然增加流水级数。

PhysisServe 不先把去噪维合并，而是把 $(d,l)$ 的每个组合保留成独立 stage。可供单流使用的并行度从 $D$ 或 $L$ 扩展为 $D\times L$ 。代价也很直接：极限配置需要同等数量的 GPU，且每个 stage 都要处理跨卡激活传输和自己的 KV 状态。

Stage-wise 流水线的时间模型#

设 stage $s$ 的计算与不可隐藏通信时间为 $t_s$ 。在一 stage 一 GPU、流水线已经填满的理想情况下，稳定态周期近似由最慢 stage 决定：

T_{\mathrm{period}} \ge \max_{0\le s<S} t_s

而一个新 chunk 从入口走到出口的响应时间仍近似是所有 stage 之和：

T_{\mathrm{response}} \approx \sum_{s=0}^{S-1} t_s

如果各 stage 耗时接近 $t$ ，就有：

T_{\mathrm{period}} \approx t, \qquad T_{\mathrm{response}} \approx S\cdot t

这正好解释“高输出频率与较长响应延迟可以同时存在”。装配线每 4 毫秒下线一件产品，不等于原料进入后 4 毫秒就完成；第一件产品仍要走完整条装配线。

以 $D=2$ 、 $L=4$ 为例，八个 stage 依次记作 $s_0$ 到 $s_7$ 。忽略跨 chunk 的额外等待后，前几个周期大致如下：

周期	GPU0 / $s_0$	GPU1 / $s_1$	GPU2 / $s_2$	…	GPU7 / $s_7$	输出
0	$C_0$	空	空	…	空	无
1	$C_1$	$C_0$	空	…	空	无
2	$C_2$	$C_1$	$C_0$	…	空	无
7	$C_7$	$C_6$	$C_5$	…	$C_0$	$C_0$
8	$C_8$	$C_7$	$C_6$	…	$C_1$	$C_1$

第一个 chunk 要到第 7 个周期才完成，之后每个周期都能完成一个。对长度为 $N$ 的有限流，理想流水线需要约 $N+S-1$ 个周期，填充与排空气泡占比为：

\eta_{\mathrm{pipe}} = \frac{N}{N+S-1}

当 $N\gg S$ 时， $\eta_{\mathrm{pipe}}$ 接近 1，长时间持续交互最能摊销深流水线；短视频或偶发请求则会被填充开销主导。这也是 PhysisServe 更像“持续流服务系统”，而不是普通单次视频生成加速器的原因。

图 2：示例包含 2 个去噪步、4 个 block，因此有 8 个 stage。流水线填满后，末级每完成一次计算就交付一个新 chunk。来源：PhysisServe 官方技术报告。

图 2 上半部分的行是 stage，列是 chunk；对角线上的就绪任务说明不同 chunk 同时处在不同 stage。下半部分给出一 stage 一 GPU 的极限映射。单个 chunk 仍要依次经过 GPU0 到 GPU7，但多个 chunk 重叠后，输出间隔只剩一个 stage 周期。

真实 stage 耗时并不整齐。若某个 stage 耗时 $t_{\max}$ 明显大于其他级，它不仅限制输出周期，还会让上游任务排队、下游出现饥饿。系统可以通过调整 stage 分组、给重 stage 分配更多执行份额或降低同周期负载来缓解，但任何处理都不能破坏带噪 KV 的依赖顺序。因而这里的调度不是任意 DAG 执行，而是带周期截止时间的有状态流水线调度。

KV 留在本卡，只传 hidden state#

跨卡流水线容易被通信吞噬。PhysisServe 的处理方式是让每个 stage 的 KV cache 常驻负责它的 GPU，不在 chunk 推进时搬运整段 KV；相邻 stage 之间只传 hidden state。下游 GPU 收到激活后先缓存，下一流水线周期再消费，从而把传输与当前周期的计算重叠。

这种设计有三个原因。第一，KV 随历史窗口增长，搬运 KV 的通信量远大于传递当前 chunk 的隐藏状态。第二，KV 与 stage 绑定后，缓存的所有权清晰，不需要全局 block table 在每一步重定位。第三，无全局同步允许快 stage 先推进，只要局部依赖满足即可；否则 200 个 stage 中一次抖动就会让所有 GPU 在 barrier 前等待。

它也带来严格约束：某个 stage 的 KV cache 不能随意迁移，物理 GPU 故障或负载再平衡会涉及有状态迁移；隐藏状态传输必须稳定落在流水周期内；最慢 stage 会成为全局节拍器，因此 block 切分、通信拓扑和负载均衡都会影响最终周期。

还可以从数据量看为什么“KV 留在本卡”重要。若每个 chunk 有 $n$ 个 latent token、隐藏维度为 $h$ 、元素宽度为 $b$ 字节，相邻 stage 一次传输的激活量大致为：

M_{\mathrm{act}} \approx n\cdot h\cdot b

而一个 stage 对历史窗口 $H$ 保存的 K/V 至少随 $2Hnhb$ 增长，前面的 2 来自 K 与 V。持续搬运历史缓存会让通信量随窗口长度扩大；只发送当前 hidden state，通信量不直接乘上 $H$ 。官方测试的历史窗口也并不相同：MiniMax H3 与 Wan2.2 5B 为 18 latent，Wan2.1 1.3B 与 LTX-2.5 为 21，Wan2.1 14B 为 6 并额外使用一个 attention sink。窗口差异会同时影响 KV 容量、注意力计算和图 3 的 stage 周期。

三种流水方案的设计空间#

把三种方案写成统一符号后，PhysisServe 的选择会更清楚。设一次完整模型前向耗时为 $T_{\mathrm{model}}$ ，单个 block 在 batch size 为 $B$ 时耗时为 $t_l(B)$ ：

方案	切分单位	单流自然扩展上限	稳态周期近似	主要代价
Wave Forcing	去噪步	$D$ 张 GPU	$T_{\mathrm{model}}$	每卡持有完整模型，深模型周期长
StreamDiffusionV2	block	$L$ 张 GPU	$\max_l t_l(D)$	多去噪步形成大 batch，卡数受 block 数限制
PhysisServe	去噪步 × block	$D\times L$ 张 GPU	$\max_{d,l} t_{d,l}(1)$	极限配置卡数多、通信边多、流水线更深

Wave Forcing 适合去噪步不多、模型完整前向已经足够快的情况；它的 DAG 简单，但模型加深会直接拉长周期。StreamDiffusionV2 把 block 变成流水级并用跨去噪步 batch 提高算力利用率，资源效率通常比一 stage 一卡更自然，但去噪步越多，单个 block batch 越重。PhysisServe 把这个 batch 再拆开，先获得最细粒度的并行上限，然后用时分复用按目标 SLO 把 stage 合回较少的 GPU。

因此，PhysisServe 不是简单否定前两种切分。它更像把“合并哪些任务”从框架预先固定的规则，变成由 profile、GPU 预算与 SLO 决定的调度变量。极限点选择完全拆分，成本优先点可以重新合并；这比只有一种静态切分更容易覆盖从单流低间隔到多流高利用率的工作区间。

高频吞吐从哪里来#

第一层：更多 GPU 缩短单流输出间隔#

官方在 Wan2.1 1.3B、Wan2.2 TI2V 5B、Wan2.1 14B、LTX-2.5 22B 和 MiniMax H3 33B 五个 backbone 上测试。模型均采用 4 个去噪步，block 数依次为 30、30、40、48、50，因此极限 stage 数分别为 120、120、160、192、200。

图 3：横轴是 GPU 数量，纵轴是稳定态 chunk 输出间隔。虚线表示一 stage 一 GPU 后的最短实测间隔。来源：PhysisServe 官方技术报告。

图 3 的纵轴是对数尺度。GPU 较少时，加卡会显著缩短输出间隔；接近一 stage 一 GPU 后，曲线逐渐收敛到单 stage 计算与相邻 stage 通信的下界。五个模型的最短间隔落在 1.895–7.547 毫秒之间。

这里有个看似反直觉的结果：33B 的 MiniMax H3 达到 4.083 毫秒，而 1.3B 的 Wan2.1 最短间隔更长。原因是流水线周期不由总参数量直接决定，而由最慢 stage 的 block 计算量、chunk token 数、历史窗口和跨卡传输共同决定。参数量影响 stage 数量与总资源，单 stage 的形状才直接影响稳态周期。因此，“与模型规模解耦”是把规模代价转化为更多流水级和更多 GPU，并非规模不再消耗算力。

第二层：时分复用回收单流空洞#

一 stage 一 GPU 给出输出频率的上界，却也会留下大量空洞。不同 block 的耗时不完全相同，通信到达时间也不同；如果每张 GPU 只守着一个 stage，完成当前任务后只能等待下一个 chunk。

PhysisServe 将逻辑 stage 与物理 GPU 解耦，让一张卡在不同时间片执行多个 stage。只要满足依赖和截止时间，调度器就可以把原本分散在多张卡上的任务排到较少的卡上。它还会把“同一个 block、来自不同 chunk 或不同去噪步、彼此无依赖”的就绪任务合成一个 batch。

“同一个 block”是关键限制。不同 block 使用不同权重，把它们放进普通 batch 并不能复用同一组矩阵；同一 block 在不同去噪步上的任务结构相同，才可以共享已经驻留的权重。极限的一 stage 一卡方案会让同一个 block 在 $D$ 个去噪步上分散到 $D$ 张卡，形成多份权重驻留；把这些 stage 合理映射到同一 GPU，既能跨步合批，也可能减少权重副本。代价是这些 stage 必须轮流执行，一个周期内的计算预算更紧。

合批不是免费加速。batch 越大，单次 kernel 的绝对执行时间通常越长；收益来自权重只需从显存读取一次、kernel launch 等固定成本只付一次，并且矩阵乘维度变大后更容易提高 Tensor Core 利用率。若 batch 大小为 $B$ ，单任务平均成本为：

\bar{t}(B)=\frac{t_{\mathrm{batch}}(B)}{B}

只要 $t_{\mathrm{batch}}(B)<B\cdot t_{\mathrm{batch}}(1)$ ，合批就降低了平均任务成本。但调度器仍要保证变长后的 batch 不会越过输出截止时间。

图 4：左右两种排法保持相同输出频率；左侧只轮流执行需要 3 张卡，右侧通过同 block 合批压缩到 2 张卡。来源：PhysisServe 官方技术报告。

官方实验给出了资源受限时的收益：Wan2.2 5B 单卡运行时，时分复用把单流 SLO 从 173 毫秒降到 98 毫秒，约降低 43%；Wan2.1 1.3B 双卡运行时，从 187 毫秒降到 139 毫秒，约降低 26%。这里比较的是相同模型与 GPU 数下的实测 chunk 间隔，不是与 200 卡极限点混在一起比较。

图中的 Buffer 也不是装饰。合批后的任务可能集中完成，而外部接口要求按固定节拍交付；输出缓存把内部的突发完成平滑成周期输出。若第 $i$ 个输出的计算完成时刻为 $F_i$ 、计划交付时刻为 $D_i$ ，系统至少要满足：

F_i \le D_i

并让 $D_{i+1}-D_i$ 不超过 SLO。缓存过浅会在一次 kernel 抖动后断供，缓存过深又会增加动作年龄。工程上不仅要看平均 $F_i$ ，还要为通信抖动、batch 变化和系统噪声留出安全裕量；否则平均吞吐达标，机器人仍会周期性错过截止时间。

调度器真正要守住的是截止时间#

单流时分复用解决的是一条流内部的空洞。实际 ACWM 服务往往同时承载多个用户、机器人或仿真环境。如果简单把 24 张 GPU 平均切成若干独立卡组，会出现两类浪费：每路所需卡数不能整除时产生取整碎片；每个卡组只看到本路任务，跨路可合批的同 block 任务彼此不可见。

PhysisServe 引入虚拟 rank。一个虚拟 rank 包含一组 stage 的计算职责、对应的 KV cache 和运行状态；物理 GPU 则可以同时承载来自多条流的多个虚拟 rank。逻辑流水线不再等同于固定的物理卡组，调度器可以在全局 GPU 池上放置新流。

图 5：每个虚拟 rank 同时占用显存槽位与一个周期内的计算预算，调度器把新流的全部 rank 放入现有 GPU 碎片。来源：PhysisServe 官方技术报告。

可以把每个虚拟 rank $r$ 抽象成二维资源需求：显存 $m_r$ 与每周期计算时间 $c_r$ 。对 GPU $g$ ，放置必须满足：

\sum_{r\in\mathcal{R}_g} m_r \le M_g

\sum_{b\in\mathcal{B}_g} t_b \le T_{\mathrm{SLO}}

$\mathcal{R}_g$ 是放在 GPU $g$ 上的虚拟 rank 集合， $M_g$ 是可用显存； $\mathcal{B}_g$ 是一个输出周期内排到该 GPU 的 batch 集合， $t_b$ 是实测或预测的 batch 耗时。第二个约束不是简单把单任务耗时相加，因为跨 chunk、跨去噪步甚至跨请求的同 block 任务可能被合批，batch 成本是非线性的。

官方方案以 Best-Fit 配合 Limited Discrepancy Search（LDS）寻找放置：优先塞进已经较满但仍能容纳的 GPU，减少新碎片；LDS 允许有限次数偏离贪心选择，避免第一个局部决定堵死后续 rank。更重要的是接纳规则：只有新流的全部虚拟 rank 都能放下，而且单独运行时满足 SLO，系统才接纳它；已运行流不迁移。

Best-Fit 之所以还要配 LDS，是因为这里不是普通的一维“箱子装物品”。一个看似最省显存的位置，可能已经没有足够计算时间容纳该 rank；一个计算余量大的位置，又可能缺少 KV 空间。同 block rank 放在一起还能改变后续 batch 成本，使放置收益相互依赖。LDS 从贪心解出发，只在少数决策点尝试次优候选，在搜索质量和在线开销之间折中。

运行时的跨路合批也必须受 deadline 约束。等待更多同 block 任务能形成更大 batch、提高 GPU 效率，但等待本身会消耗某条流的松弛时间。设任务 $j$ 的截止时刻为 $d_j$ 、当前时刻为 $t$ 、预计执行时间为 $e_j$ ，它的剩余松弛量是：

s_j=d_j-t-e_j

$s_j$ 越小，越不能继续等待合批。官方报告没有公布具体在线队列策略，但从 SLO 目标可以推知，任何实现都需要在“大 batch 的效率”与“最紧任务的截止时间”之间动态取舍，不能沿用只最大化平均吞吐的静态 batching。

“整流接纳、不迁移”牺牲了一部分全局最优，却保护了实时系统最重要的可预测性。如果只放下一半流水线再等待资源，已经保留的显存与算力会变成死锁式占用；如果为追求更紧凑的装箱频繁迁移 KV，迁移抖动会直接伤害在服流的截止时间。PhysisServe 选择在 admission control 阶段做较重的搜索，运行阶段保持映射稳定。

固定 24 张 GPU、SLO 为 1600 毫秒时，均分卡组与联合调度的最大已验证并发路数如下：

模型	均分卡组	联合调度	变化
Wan2.1 1.3B	12	39	3.25 倍
Wan2.2 TI2V 5B	24	46	1.92 倍
Wan2.1 14B	24	18	降至 0.75 倍
LTX-2.5 22B	8	18	2.25 倍
MiniMax H3 33B	6	10	1.67 倍

这组数据很有价值，因为它没有制造“联合调度必然更好”的假象。Wan2.1 14B 在该配置下反而从 24 路降到 18 路：当显存和计算已经接近饱和，跨路合批与共享没有足够余量抵消调度干扰。联合调度的收益取决于可回收碎片，而不是来自某个无条件成立的算法倍数。

智能与频率为什么不再是简单二选一#

PhysisServe 没有让一次 Transformer block 计算变得免费，也没有证明更大模型一定更懂物理。它改变的是资源扩展方式：传统粗粒度方案达到去噪步数或 block 数的并行上限后，加 GPU 很难继续缩短单流输出间隔；stage 粒度把并行上限扩展到二者乘积，使更多算力仍有明确的落点。

设单个 block stage 的工作量约为 $W_{\mathrm{block}}$ ，模型有 $D$ 个去噪步、 $L$ 个 block。忽略通信时，一个 chunk 的总工作量仍然是：

W_{\mathrm{chunk}} \approx D\cdot L\cdot W_{\mathrm{block}}

PhysisServe 没有减少这个总量，只把它分布到最多 $D\cdot L$ 个并行 stage 上。模型从 30 层扩到 50 层时，极限输出间隔未必增长，但需要的 GPU 数、流水线填充时间、KV 副本和集群通信都随之增加。这是一种用横向资源换稳定态频率的 scale-out 设计。

所谓“智能与频率兼得”，更精确的含义是：系统不再要求为了达到高输出频率而把模型压缩到很小；只要模型属于可流水化的自回归去噪范式，且有足够 GPU，较大的模型也能保持较短的稳态输出间隔。这里并没有绕开成本、功耗与响应延迟，而是把原先隐藏在模型大小里的取舍显式转化为集群资源配置问题。

这条路线特别适合两类场景。第一类是云端高频物理仿真，同一模型持续生成大量环境轨迹，流水线填充成本容易摊销。第二类是共享式 ACWM 服务，多条长生命周期流可以跨路合批并共享权重。对于只有一个短请求、只有少量 GPU、或必须让新观测在数毫秒内影响动作的本体控制，PhysisServe 的极限配置并不自然占优。

从目标 SLO 反推部署配置#

PhysisServe 不是只有“一 stage 一 GPU”和“单卡运行”两个档位。真正部署时，需要从业务截止时间向回求解一张周期调度表。

第一步是固定语义口径。目标究竟是每秒 latent chunk 数、像素帧数、action chunk 数，还是控制步播放频率？如果一个 chunk 含 $q$ 个外部输出，目标频率为 $f$ ，则 chunk 周期上限是：

T_{\mathrm{SLO}} \le \frac{q}{f}

只有当 $q$ 的定义一致时，不同部署点才可比较。把 16 个控制步都算成独立重规划，会把系统能力夸大 16 倍。

第二步是逐 stage profile。需要测量每个 $(d,l)$ 在候选 batch 大小、精度和历史窗口下的计算时间、激活大小、KV 容量与权重容量。平均 block 时间不够，因为最慢 stage 决定极限周期，batch 成本又通常不是线性的。

第三步是确定逻辑分组。若追求最短周期，就让更多 stage 独占 GPU；若目标 SLO 宽松，就把同 block、不同去噪步的 stage 尽量归入可共享权重的虚拟 rank，并预计算允许的 batch 组合。分组过大虽然节省权重副本，却可能让一个 rank 在周期内排不完。

第四步是拓扑感知放置。相邻 stage 需要传 hidden state，通信重的边应优先落在 NVLink 或同一高速域内；仅满足显存和计算容量、却把关键边跨到慢链路，会让纸面可行的周期失效。对于 120 到 200 级的长流水线，拓扑不是二级优化，而是周期的一部分。

第五步是生成周期表并留裕量。若预测周期恰好等于 SLO，任何操作系统抖动或通信尾延迟都会违约。部署应以 p99 stage 时间而非平均值估算，并给输出 buffer 留出少量吸收抖动的空间，同时限制 buffer 深度以免动作过时。

第六步才是多流接纳。新流到达后，用 Best-Fit 与 LDS 检查全部虚拟 rank 是否能放入现有显存槽和计算周期；放不下就拒绝或进入外部队列，而不是挤压已承诺的流。由此得到的系统容量不是理论 FLOPS 除以单请求 FLOPS，而是满足每路周期 SLO 的 goodput。

可以把经济性写成每个有效输出的 GPU 成本：

C_{\mathrm{out}}= \frac{N_{\mathrm{GPU}}\cdot T_{\mathrm{wall}}} {N_{\mathrm{on\mbox{-}time\ outputs}}}

分母只统计按时交付的输出。极限流水线可能拥有最高频率，却未必有最低 $C_{\mathrm{out}}$ ；时分复用和联合调度的目标，正是在 SLO 足够时降低这个成本。

运行时应该观测什么#

深流水线最危险的问题不是“整体变慢”这么容易发现，而是局部 stage 先产生背压，若干周期后才在出口表现为 deadline miss。监控需要沿同一个 chunk ID 串起入口、每个 stage、跨卡传输、输出 buffer 与外部交付。

最少应记录五组指标：

每个 stage 的平均、p99 计算时间和排队时间，用于定位真正的节拍器；
每条相邻 stage 边的传输字节数、带宽、等待时间与重传异常，用于区分计算瓶颈和拓扑瓶颈；
每张 GPU 的权重、KV、激活和临时 workspace 占用，避免只看总显存而看不到不可复用碎片；
batch 的来源组成、大小、等待形成时间与摊销收益，判断合批是否为了省计算反而错过 deadline；
每条流的实际输出间隔、response latency、buffer 深度、动作年龄和 SLO 违约次数。

背压可以用相邻 stage 的队列长度差识别。如果 stage $s$ 的到达率 $\lambda_s$ 长时间大于服务率 $\mu_s$ ，其队列会持续增长：

\lambda_s > \mu_s \quad \Longrightarrow \quad Q_s(t)\uparrow

此时增加输出 buffer 只能推迟故障暴露，不能修复容量不足。系统应停止接纳新流、缩小低优先级 batch，或重新选择更宽松的 SLO 配置。由于 PhysisServe 不迁移已接纳流，事前 profile 准确性和 admission control 会比普通离线吞吐任务更重要。

故障恢复同样需要以状态为中心。一个 GPU 丢失的不只是权重执行能力，还包括该 GPU 上虚拟 rank 的带噪 KV 与流水位置。若没有可恢复快照，重建流可能要从更早的干净边界重新生成；若做副本，又会增加显存与同步流量。官方报告尚未给出这部分机制，它是走向长期在线服务必须补齐的一环。

如何正确阅读性能数字#

读 PhysisServe 的数字，需要始终把“测了什么”与“没有测什么”放在一起。

4.083 毫秒是 chunk 间隔，不是端到端延迟#

MiniMax H3 的 4.083 毫秒是流水线稳态下相邻 latent chunk 的完成间隔。新输入要影响输出，仍需沿完整流水线传播。官方也把响应延迟列为开放问题。因此不能据此宣称 33B 模型实现了 4.1 毫秒感知—动作闭环。

1000 FPS 是换算结果，不包含 VAE#

每个 latent 解码为 4 帧， $244.9\ \mathrm{chunk/s}$ 换算为约 $980\ \mathrm{FPS}$ 。报告明确计时只覆盖 DiT 去噪，不含 VAE 解码。真实 ACWM 若要输出像素帧，VAE、后处理和传输仍可能成为瓶颈。若下游直接消费 latent，则 VAE 可以不在关键路径上，但那已是不同的系统接口。

3900 Hz 不是实测机器人闭环频率#

3900 Hz 来自一个 latent 对应 16 个控制步的语义换算。控制步可能由一个 action chunk 一次生成，再由控制器按更高频率播放；这与模型每 0.256 毫秒读取一次新传感器并重新规划完全不同。动作播放频率、模型重规划频率和传感闭环频率必须分别报告。

物理系统至少有四个容易混淆的频率：传感器采样频率 $f_{\mathrm{sensor}}$ 、模型接收新观测并重规划的频率 $f_{\mathrm{replan}}$ 、模型交付 chunk 的频率 $f_{\mathrm{chunk}}$ 、执行器播放 chunk 内控制点的频率 $f_{\mathrm{servo}}$ 。通常有：

f_{\mathrm{servo}} \ge f_{\mathrm{chunk}}, \qquad f_{\mathrm{servo}} \ge f_{\mathrm{replan}}

但这不意味着 $f_{\mathrm{chunk}}$ 或 $f_{\mathrm{replan}}$ 等于 $f_{\mathrm{servo}}$ 。真正反映控制新鲜度的是观测年龄：

A_{\mathrm{action}}= T_{\mathrm{capture}}+T_{\mathrm{queue}}+T_{\mathrm{response}}+T_{\mathrm{handoff}}

高稳态吞吐可以避免动作流断供，却不自动降低 $T_{\mathrm{response}}$ 。判断系统能否进入底层闭环，必须同时给出动作年龄和截止时间违约率。

200 张 GPU 是极限并行点，不是成本最优点#

50 个 block 乘 4 个去噪步得到 200 个 stage，一 stage 一 GPU 才到 4.083 毫秒的极限点。这个实验说明单路输出间隔可以继续随卡数下降，证明的是可扩展性。真正部署要在输出 SLO、单流卡数、并发路数和总成本之间选工作点，时分复用与联合调度正是为非极限配置准备的。

跨方案曲线不是严格同条件榜单#

官方图同时包含自行测量与其他项目公开报告的结果，不同点在 GPU 型号、GPU 数量、精度、是否包含 VAE、chunk 大小和历史窗口上并不完全一致。适合比较数量级和缩放趋势，不适合把细小差异当作同机 benchmark 的胜负。

与 vLLM、通用 VLA Runtime 的关系#

PhysisServe 的发布方包含 vLLM，但它解决的并不是“把视频 token 直接塞进现有 vLLM 调度器”这么简单。官方技术报告目前没有说明哪些模块直接复用了 vLLM，也没有把 PhysisServe 描述成 vLLM 的一个 backend；因此，更稳妥的理解是比较两类系统抽象，而不是推断代码继承关系。

vLLM 的核心工作单元是某条序列在一次迭代中要计算的 token。调度器在 token budget 与 KV block 容量内拼接请求，PagedAttention 用逻辑块到物理块的映射解决 KV 碎片。关于这条链路，可以结合 vLLM 源码完全拆解（一）与连续批处理完全拆解阅读。

PhysisServe 的核心工作单元则是某条流、某个 chunk、某个去噪步、某个 Transformer block 的 stage 任务。它面对的是二维依赖图、长生命周期流、带噪 KV、周期性输出 SLO 和跨 GPU stage 放置。二者的差别可以归纳为：

维度	vLLM 类 LLM 服务	PhysisServe
生成依赖	token 严格因果串行	chunk 可沿去噪步与 block 形成波前
调度单位	token / sequence group	stage task / virtual rank
缓存抽象	分页 token KV block	stage 本地的带噪 KV 与运行状态
合批边界	同次模型迭代中的序列	同 block 的跨 chunk、跨步、跨流任务
主要指标	TTFT、TPOT、throughput、goodput	稳态 chunk 间隔、响应延迟、SLO 内并发流数
横向扩展	TP、PP、DP 与多实例	去噪步 × block 的 stage 流水线

两者的共同思想同样清楚：把逻辑请求状态与物理设备解耦，让调度器看到全局碎片；以细粒度任务进行连续合批；用接纳控制保护 SLO，而不是只追求平均吞吐。vLLM 对 Physical AI 最重要的启发不是某个 API，而是“先选对可调度对象，再围绕它设计内存、批处理和执行引擎”。PhysisServe 把这个对象从 token 换成了 stage。

与通用 VLA Runtime 相比，PhysisServe 的边界也更窄、更激进。PhyAI 一类系统强调用同一 runtime 适配 $\pi_0$ 、GR00T、Cosmos 等多种 VLA/WAM 架构，并覆盖端侧、边缘与云端；PhysisServe 集中攻击可自回归去噪的 ACWM/WAM，把依赖图展开到 stage 级以追求高频连续输出。前者优先统一性与可移植性，后者优先特定生成范式下的 scale-out 上限。

部署边界与仍待公开的问题#

带噪 KV 是并行性的算法前提#

Stage-wise 波前成立的前提，是后一个 chunk 能读取前一个 chunk 在相同去噪步留下的带噪 KV。官方报告指出，这种模型适配方法仍不成熟，带噪 KV 与干净 KV 的生成质量差异及边界尚不清楚。也就是说，PhysisServe 并非对任意现成视频扩散模型做无损系统替换；模型需要支持这种缓存语义，质量与并行度之间仍有算法耦合。

响应延迟仍可能不适合底层闭环#

新动作或新观测必须依次经过全部 stage 才能反映到输出里。流水线越深，稳定态输出越密，但输入“新鲜度”不一定越高。对于突然碰撞、急停或高速不稳定系统，高频播放旧观测生成的动作不能替代低响应延迟。实际机器人仍需要独立的安全回路、状态估计器和本地控制器；关于不同控制层为何需要不同频率，可参考 NeuroVLA 完全拆解。

极限配置把单机问题变成集群问题#

200 张 GPU 意味着 199 个相邻边界上的激活传输、更多故障点和更复杂的拓扑放置。若相邻 stage 落在低带宽链路两侧，通信就会成为最慢 stage；任一 GPU 抖动也可能沿流水线形成背压。报告展示了输出间隔随 GPU 数下降的实测趋势，但完整复现仍需要明确 GPU 型号、互连拓扑、精度、通信与计算重叠方式、tail latency 和故障恢复策略。

VAE 与系统 I/O 可能接管瓶颈#

千 FPS 数据不包含 VAE 解码。如果目标是像素级仿真，VAE、渲染、视频编码与网络传输必须共同达到相同节拍。如果目标是 WAM，动作后处理、控制总线与执行器也有独立上限。系统应报告从传感时间戳到动作生效时间戳的全链路分布，而不只报告 DiT 核心的平均周期。

联合调度需要尾延迟证据#

当前多流结果要求后续输出均不超过 SLO，并通过完整重复测试后才计入路数，这是比平均吞吐更合理的口径。但生产部署还需要 p99/p99.9 输出间隔、流到达与离开时的抖动、batch 形状变化、拒绝率和长时间运行稳定性。尤其在不迁移策略下，流的到达顺序可能造成长期碎片，Best-Fit 与 LDS 的在线效果需要真实轨迹验证。

“更大”不能替代闭环任务质量#

测试覆盖 1.3B 到 33B 模型，说明调度机制能跨规模工作；它并没有单独证明参数量增加必然提高物理推理或机器人成功率。完整评测还应把输出周期、响应延迟、任务成功率、物理一致性、GPU 小时与能耗放在同一张 Pareto 曲线上。否则系统可能做到更高频地输出质量不足的轨迹，或者用不可接受的成本换取一个并不需要的频率。

小结#

PhysisServe 的核心不是某个 kernel 小优化，而是重新选择流水线切分粒度。自回归去噪包含“去噪步 × Transformer block”的二维计算图；把每个组合定义为独立 stage 后，不同 chunk 可以沿带噪 KV 依赖形成对角波前。流水线填满以后，模型总深度主要影响 stage 数量与 GPU 需求，最慢 stage 才决定相邻输出间隔。

在这个极限流水线之上，系统又加入两层资源效率设计：单流内部用时分复用和同 block 合批回收空洞；多流之间用虚拟 rank、Best-Fit、LDS 与整流接纳共享显存和计算碎片。这使 PhysisServe 不只回答“堆很多卡能有多快”，也开始回答“给定 SLO 和卡数能服务多少条持续流”。

最重要的阅读边界同样明确：4.083 毫秒是稳态 chunk 间隔；约 1000 FPS 和 3900 Hz 是基于 latent 语义的换算；VAE 与端到端闭环不在计时范围；200 GPU 是 50 个 block、4 个去噪步的一 stage 一卡极限配置。PhysisServe 证明了大参数量自回归去噪模型可以把更多算力转化为更高的连续输出频率，但响应新观测的速度、带噪 KV 的质量边界、集群成本和真实闭环可靠性仍是下一步必须回答的问题。

音乐

音乐