PhysisServe: 基于细粒度流水编排的自回归去噪高效推理
Introduction
人工智能的下一站是物理世界。物理智能体要在一个不停变化的世界里行动。对 LLM 而言,变慢通常只是为同一个回答多等一会儿;对物理智能体而言,延迟可能使动作在执行前就已过时。因此,物理智能体对模型的要求是双重的:既要足够大的模型来准确理解与预测物理世界,又要足够快的输出以跟上物理过程与执行器的节拍。而现实是,前沿机器人模型的规模至今远小于 LLM:通用机器人模型停留在数十亿参数量,开源 LLM 已跨入万亿 [1]——差距背后是硬约束,模型必须装进能实时运行的硬件,智能因而被延迟与成本所限。物理 AI 面临一个根本性的推理服务问题:如何让更大、更强的模型以物理任务所需的输出频率运行。这正是 PhysisServe 所要解决的问题。
当前,社区对“世界模型”的定义和边界尚未完全统一。本文不比较不同架构的优劣,而是从交互过程中的输入输出形式出发,讨论两类与本文服务系统直接相关的实现方式。
-
Action-Conditioned World Model(ACWM)。 这类模型以当前环境的观测或画面,以及智能体的动作或指令为条件,生成后续的观测或画面。动作或指令可以在生成过程中持续输入,因此生成轨迹会随着智能体的行为实时改变,并可作为智能体训练或测评的环境。Dreamer 4 和 Genie 3 都把环境状态与智能体的动作或指令放在生成环路中,根据交互过程不断生成未来的观测 [2, 3]。
-
World Action Model(WAM)。 这类模型以机器人对环境的观测为输入,持续生成后续动作。输出不再是未来画面,而是可以直接用于控制机器人的动作序列,因此能够作为策略或策略模块使用。DreamZero 和 LingBot-VA 2.0 都读取机器人对环境的连续观测,并将模型输出转化为下一步可执行的动作 [4, 5]。
ACWM 与 WAM 都可以采用自回归去噪的方式生成。自回归去噪与大语言模型逐 token 的生成同属自回归,区别在于后一次输出是否必须等待前一次完成。大语言模型每次生成一个 token,后一个 token 必须等前一个 token 经过全部 Transformer block 后才能开始计算,因此各 token 依次生成(图 1 左)。自回归去噪则以 chunk 为单位生成连续帧:每个 chunk 从纯噪声出发,经过若干去噪步逐步变得清晰。后一个 chunk 不必等待前一个 chunk 完全去噪;前一个 chunk 每完成一个去噪步,后一个 chunk 就可以读取其在该步仍带噪声的 KV cache,并执行自身对应的去噪步骤 [6]。相邻 chunk 的去噪因此可以前后错开、相互重叠,使各个 chunk 以较短的间隔连续完成(图 1 右)。在本文中,输出延迟指连续完成的 chunk 之间的稳定态间隔,而不是对新输入的响应时间。
模型所需的输出频率,取决于任务对响应速度和动作控制精度的要求。在人形机器人的仿真训练中,为了准确模拟机器人与环境之间的接触,仿真频率可达数千 Hz [7]。实际部署时,越接近底层执行器,控制指令的更新频率通常越高:语义规划层更新较慢,运行频率通常低于 50 Hz;动作与伺服层则需要更频繁地调整,运行频率可达数百赫兹 [1]。
然而,参数量大与输出频率高难以兼得。智能来自规模,规模却拖慢速率:模型越大,对世界的刻画越准确,每次生成要计算得也越多;而自回归去噪的串行依赖无法并行,算得越多,生成就越慢。于是,智能要求模型更大,实时要求模型更小,二者难以兼得。这一取舍也体现在公开模型中。ACWM 方面,LingBot-World 采用约 28B 参数的 MoE 结构(每步激活约 14B),输出 16 FPS;MAGI-1 为 24B,在 24 张高端 GPU 上约以 0.98 秒生成 24 帧的 chunk,相当于约 24 FPS [8, 9]。WAM 方面,DreamZero 为 14B,约以 7 Hz 生成 action chunk;LingBot-VA 2.0 约有 15.3B 个训练参数(每个 token 激活约 2.5B),生成延迟为 142 ms/chunk,约对应 7.0 chunks/s 和 225 Hz 的峰值异步控制频率 [4, 5]。Figure S0 则以 10M 参数在 1 kHz 输出关节级指令 [10]。如果参数量大的模型也能保持足够高的输出频率,其应用范围便可以从视频生成和高层交互进一步拓展到高频仿真与底层控制;这些场景要求的输出频率,与现有大参数量模型能提供的实际频率仍相差约两个数量级。
目前还没有一个自回归去噪推理引擎能让模型规模与输出频率兼得(图 2)。Wave Forcing 的切分粒度是去噪步:每张卡持有完整模型、负责一个去噪步,chunk 与去噪步沿对角线推进 [11],一路最多用到与去噪步数相当的卡,输出延迟不短于完整模型前向一次的时间 —— 模型越大,单次前向越慢,输出频率越低。StreamDiffusionV2 的切分粒度是 block:模型按 block 切分到多张卡上组成流水线,并把同一 block 在各去噪步上的计算合成一个 batch 以提高利用率 [6]。这带来两个限制:一路最多用到与 block 数相同的卡,卡数上限锁死在 block 数上;去噪步越多、合进 batch 的计算越多,batch 越大,单次前向越慢,而对 batch 的组成与调度并不灵活。卡数超过上限后,输出频率不再提高;模型越大,能达到的输出频率越低。
我们提出 PhysisServe,一种让大模型与高频输出结合起来的自回归去噪推理框架。只要算力充足,PhysisServe 的设计目标是在模型扩展到数百亿、数千亿乃至万亿参数时,仍能维持任务所需的输出频率。PhysisServe 将模型切分为多个 stage,每个 stage 对应某一个去噪步上的某一个 Transformer block,并以 stage 作为算力分配与调度的基本单位。系统设计沿着单路提速、算力共享和多路扩展三个层面展开:
-
Stage-wise 流水线。 去噪步与 Transformer block 两个维度同时流水线化,使单路可利用的 GPU 数量扩展为二者数量的乘积。在稳定运行状态下,输出延迟由最慢 stage 的计算时间决定;增加去噪步数或模型深度主要增加流水线深度与所需 GPU 数量,而不再直接降低输出频率。
-
时分复用。 将 stage 与物理 GPU 解耦,使一张 GPU 能够在不同时间片轮流执行多个 stage 任务。对于同一 block 上来自不同 chunk 的任务,调度器将其合并为 batch 后集中执行,从而复用权重加载和 kernel 调度开销。这样,GPU 的空闲时间可以被其他 chunk 的计算占用,不再要求每个 stage 独占一张卡;在不追求极限输出延迟时,单路请求可以用更少的 GPU 完成,同时满足目标 SLO。
-
虚拟 rank 的动态放置。 将每条流在各个 stage 上的计算任务与运行状态封装为虚拟 rank,再将虚拟 rank 映射到物理 GPU。新流到达时,调度器根据各卡的剩余容量为其选择放置位置;只有当整条流的所有 stage 都能被容纳时才接纳,已经运行的流不迁移。这样既能保持已有服务的稳定性,也能均衡卡间负载并利用零散的空闲容量。
我们在 ACWM 与 WAM 常用的五个 backbone 上评估 PhysisServe:Wan2.1 1.3B、Wan2.2 TI2V 5B、Wan2.1 14B、LTX-2.5 22B 与 MiniMax H3 33B [12]a模型配置:blocks 30/30/40/48/50;去噪 4 步;LTX-2.5 仅视频分支。Wan2.1 使用 StreamDiffusionV2 权重 [6];其余模型采用带噪 KV 微调(基于 Rolling Forcing [13] 二次开发)。历史窗口:MiniMax H3、Wan2.2 TI2V 5B 为 18 latent;Wan2.1 1.3B、LTX-2.5 为 21;Wan2.1 14B 为 6,另加 1 个 attention sink。,权重均未经剪枝、压缩或量化b每个 chunk 包含 1 个 latent。Wan2.1、Wan2.2 TI2V 和 MiniMax H3 解码为 4 帧,LTX-2.5 解码为 8 帧。计时仅覆盖 DiT 去噪,不包含 VAE 解码。。每个 stage 独占一张卡时,33B 的 MiniMax H3 单路输出延迟实测为 4.1 毫秒。图 3 展示不同模型在不同 GPU 数量下的输出频率;MiniMax H3 在每个 stage 独占一张卡时的原始测量值为 4.083 msc1000 / 4.083 = 244.9/s,取 245。,即每秒输出约 245 个 chunk,按 ACWM 的输出口径约合每秒 1000 帧dACWM 口径:1 latent 解码为 4 帧;244.9 × 4 ≈ 980 帧/s。,按 WAM 的输出口径约合每秒 3900 个控制步eLingBot-VA 2.0 口径:16 控制步/latent;244.9 × 16 ≈ 3919 Hz。,或每秒 120 个 action chunkfDreamZero 口径:2 latent/action chunk;244.9 / 2 ≈ 122.5 action chunks/s。。这些频率是对实测 DiT 吞吐量的换算,并非实测的闭环控制频率。五个模型的最短输出延迟为 1.9–7.6 毫秒,取决于 block 计算量与跨卡传输;在这些测试中,它不会随参数量单调增加:33B 的 MiniMax H3 的输出间隔短于 1.3B 的 Wan2.1。
Stage-wise 流水线
PhysisServe 将自回归去噪中的计算拆解为可跨 chunk 重叠执行的 stage 级任务,使不同 chunk 同时处于不同流水线阶段,从而在算力充足时将单路输出延迟降低到单个 stage 的计算时间。
一个 chunk 依次经过全部 stage,一个 stage 上的计算称为一个任务。每个任务依赖同一 chunk 在前一 stage 的输出,以及前一 chunk 在同一 stage 上产生的 KV cache。带噪 KV cache 使后一个 chunk 不必等待前一个 chunk 完全去噪:它可以读取前一个 chunk 在当前去噪步留下的 KV cache,沿着不同 stage 与前一个 chunk 错开执行。于是,不同 chunk 的任务沿对角线推进并形成流水线重叠(图 4)。
以两个去噪步、四个 block 的模型为例,PhysisServe 将模型拆成八个 stage,并映射到八张 GPU(图 5)。chunk 沿流水线逐级推进;流水线充满后,每经过一个流水线间隔就完成一个 chunk。模型深度和去噪步数主要增加流水线级数与所需 GPU 数量,而不直接增加稳定状态下的输出延迟。为使每一级尽量只含计算,KV cache 始终留在本卡,跨卡只传 hidden state;下游 GPU 将收到的 hidden state 缓存到下一个流水线间隔再使用,使传输与计算重叠;GPU 之间不设置全局同步。
图 6 测量了五个模型在不同 GPU 数量下的单路输出延迟。GPU 较少时,增加 GPU 会降低输出延迟;当每个 stage 独占一张 GPU 后,延迟逐渐收敛到 1.9–7.6 毫秒。收敛值由单个 stage 的计算与相邻 stage 间的传输共同决定,模型之间的差异主要来自 block 计算量、chunk token 数、历史长度和通信开销。
Stage-wise 流水线给出了单路输出延迟的极限边界,但这种配置要求每个 stage 独占一张 GPU。对于不需要极限低延迟的场景,还可以通过复用流水线中的空闲资源来减少单路所需的 GPU 数量。
单路的时分复用
在目标输出延迟较为宽松时,PhysisServe 通过轮流执行与合批,让多个 stage 共享同一张 GPU,在满足单路 SLO 的同时减少所需的 GPU 数量。
Stage-wise 流水线中的不同 stage 计算时间并不完全相同,固定的一卡一 stage 映射会留下空闲时间。轮流执行让一张 GPU 在不同时间片内承载多个 stage,回收这些空隙。就绪的、来自不同 chunk 和去噪步的同一 block 任务共享模型权重,并可在彼此没有数据依赖时合并为一个 batch;合批复用权重加载和 kernel 调度开销,降低任务总耗时。两种机制结合后,一张 GPU 可以在一个输出延迟内完成更多任务。
如图 7 所示,在包含两个去噪步、四个 block 的示例中,对照方案在 GPU 之间静态分配 stage,且不进行合批。由于不同 stage 的计算耗时存在差异,GPU 之间容易出现负载不均,部分 GPU 在等待其他 stage 时处于空闲状态,因此需要 3 张 GPU 才能达到目标输出频率。PhysisServe 则通过时分复用让多个 stage 共享同一张 GPU,并将同一 block 上来自不同 chunk 的任务合并为 batch。合批会使单个 batch 的执行时间有所增加,但摊销到其中的多个任务后,可以减少权重加载和 kernel 调度等固定开销,使每个任务的平均耗时反而降低。结合 stage 之间的时间复用,PhysisServe 最终仅需 2 张 GPU 即可达到相同的输出频率。
单个 batch 的执行时间与线性参考的比较见图 8。实测耗时低于逐个执行的线性边界,说明合批虽然会增加单个 batch 的执行时间,但能够摊薄权重加载和 kernel 调度等固定开销。
如图 9 所示,我们通过实验评估了不同 GPU 资源配置下两种调度策略对应的单流 SLO:stage-wise 静态切分且不进行合批的传统流水线方案,以及 stage-level 时分复用方案。这里的 SLO 以实测 chunk 输出延迟表示。相比前者,stage-level 时分复用(深色)在多数配置下均能降低所需 SLO。例如,在单卡运行 Wan2.2 5B 时,PhysisServe 将单流 SLO 从 173 ms 降至 98 ms,降低约 43%;在双卡运行 Wan2.1 1.3B 时,单流 SLO 从 187 ms 降至 139 ms,降低约 26%。从实验结果来看,PhysisServe 在多数配置下取得了优于传统流水线方案的效果,尤其是在 GPU 资源受限时优势更加明显。这说明 PhysisServe 的 stage-level 时分复用编排策略能够有效优化算力分配,从而在模型和算力固定的情况下提升输出频率。
单路时分复用将 Stage-wise 流水线从固定的一卡一 stage 扩展为多个 stage 共享 GPU,使系统能够用更少的资源满足单路 SLO。对于 ACWM 而言,实际部署通常需要同时为多个用户或多个智能体提供持续的交互式预测,因此还需要进一步将这种资源复用扩展到多路请求之间。
多路的联合调度
当 ACWM 从服务单个用户或智能体扩展到多个用户或智能体时,PhysisServe 让多路请求共享整个 GPU 池,并在请求之间进行时分复用与合批,从而在有限算力和满足每路 SLO 的条件下最大化同时服务的路数。
均分卡组会造成 GPU 数量向上取整,每个 batch 也只包含一路任务,不同请求之间的空闲显存和计算时间无法共享。联合调度让多路请求共享整个 GPU 池:GPU 以 batch 为粒度在不同请求之间轮流执行,同一 block 上来自不同请求的任务可以跨路合批(图 10)。
PhysisServe 把一路的 stage 分成若干组,每组称为一个虚拟 rank:它负责一组 stage 的计算并保存对应的 KV cache,同一 block 上不同去噪步的任务可以在其中合批。虚拟 rank 是放置的基本单位,一张 GPU 可以同时承载多路的虚拟 rank。新请求根据显存、计算时间和 SLO 进行放置,采用 Best-Fit [14] 结合 Limited Discrepancy Search(LDS)[15]:优先将虚拟 rank 放入已经较满、但仍放得下的 GPU;只有整路放得下且单独运行时能满足 SLO 才接纳,否则拒绝;已接纳请求保持不迁移(图 11)。
图 12 比较固定 24 张 GPU 时,两种做法在 SLO=1000、1200、1600 毫秒下能够持续服务的最大已验证路数。均分卡组让每一路独占一组卡,按 stage 均分、不合批;联合调度即上述做法。一路开始输出后,只有所有后续输出延迟都不超过 SLO,且通过完整重复测试,才计入服务路数。
SLO 为 1600 毫秒时,均分卡组与联合调度的已验证服务路数分别为:Wan2.1 1.3B 为 12→39,Wan2.2 TI2V 5B 为 24→46,Wan2.1 14B 为 24→18,LTX-2.5 22B 为 8→18,MiniMax H3 33B 为 6→10。联合调度在其中四个模型上提升了并发路数,提升倍数为 1.7–3.3;Wan2.1 14B 则因资源余量有限而下降。
联合调度的收益主要来自回收不同请求之间原本无法共享的显存和计算时间。单路资源占用较低的模型在均分卡组下会留下较多空闲容量,因此收益更明显;对于资源余量较小、已经接近单卡容量上限的模型,共享空间有限,联合调度的收益也会相应减弱。具体而言,显存余量较大时,调度器可以将更多路的虚拟 rank 放置到同一张 GPU 上;计算负载不满时,跨路合批和时分复用还可以填补原本的空闲时间。对于参数量较大的模型,联合调度还能够通过共享已经驻留的 block 权重,减少不同请求之间的权重副本;而当显存和计算都接近饱和时,继续接纳请求反而可能使输出延迟超过 SLO。
联合调度将资源复用从单路内部扩展到多路请求之间:虚拟 rank 提供细粒度的任务放置,跨路合批和时分复用回收碎片化的显存与计算容量,接纳约束旨在保护已运行请求的 SLO。它并不改变单路的最短输出延迟,而是在给定 GPU 预算和输出延迟要求下,提高系统能够同时服务的请求数量;实际收益取决于不同模型可共享的显存和计算余量。
讨论与未来工作
据我们所知,PhysisServe 是首个让 30B 级参数的自回归扩散模型以不足 10 毫秒的 chunk 间隔持续输出、并支持多路高频任务共享同一组 GPU 的推理系统。 PhysisServe 的流水线可以通过增加 GPU 支持更多 block 和去噪步,而不会直接延长稳定态输出间隔。MiniMax H3(50 个 block、4 步去噪)在 200 张 GPU 上每 4.1 毫秒输出一个 chunk,约合每秒 1000 帧,不包含 VAE 解码。现有大型实时世界模型报告的输出频率为每秒数十帧,但硬件和计时范围存在差异。多路结果采用单独的 24-GPU 配置。输出延迟与模型规模解耦,让“智能要求模型更大、实时要求模型更小”的取舍有了调和的空间——PhysisServe 为这一取舍提供了一个可行方案。
输出延迟与模型规模的解耦并不意味着实时世界模型的推理问题已被完全解决。我们的推理方案在算法与系统两个层面仍存在局限,也由此引出了值得社区共同探索的开放问题。
- 带噪 KV cache 管理。 PhysisServe 的流水线去噪要求模型在带噪的 KV cache 上推理,这一范式下的后训练算法尚不成熟,带噪 KV cache 推理与干净 KV cache 推理在生成质量上的差异及其性能边界也不明朗。我们相信,带噪 KV cache 推理相较于干净 KV cache 推理能让模型兼具大参数量和高输出频率,能够吸引社区关注并投入带噪 KV cache 后训练算法的开发。
- 响应延迟。 本文尝试解决的是输出延迟,而非动作响应延迟——新的动作或观测进入模型到首次反映在输出中仍需依次经过全部 stage,高频闭环控制场景因此仍受到诸多限制。我们相信,这一限制可以通过量化、剪枝与模型架构创新等基础设施层面的手段,以及芯片算力的不断增长而逐步缓解。
结论
世界模型越大,对物理世界的理解与预测有望越准确;但物理世界对实时性的要求很高,模型的输出频率一旦跟不上环境变化,再准确的预测也会失去价值。对于基于自回归去噪的世界模型来说,模型规模与输出频率长期难以兼得。这一矛盾的重要原因在于,现有推理方案的流水线切分粒度过粗,限制了其并行度,进而制约了输出频率,使得世界模型的实时性难以随算力增加而持续提升,成为世界模型落地真实场景的主要瓶颈。
为了突破这一瓶颈,PhysisServe 把流水编排的切分粒度细化到了 stage 级别(即某一去噪步上的某一个 block),并做了如下三层设计:
- Stage-wise 流水线。 通过细粒度的流水编排,使单路输出延迟主要由单个 stage 的计算与传输决定。
- 时分复用。 通过轮流执行与合批减少单路所需的算力。
- 虚拟 rank。 让多路请求共享同一卡池,将原本按路分卡时因取整产生的空闲容量转化为可服务的请求数。
实验结果表明,PhysisServe 能够将不同规模模型的单路输出延迟稳定在毫秒级范围内:五个模型的最短输出延迟为 1.895–7.547 ms,33B 的 MiniMax H3 达到 4.083 ms,按每个 chunk 解码 4 帧计算,约合每秒 1000 帧。当前结果未显示最短输出延迟随模型参数规模单调增加。
在多路服务中,联合调度能够显著提升多数模型的并发服务能力,但收益取决于模型结构和资源余量,并非对所有模型都一致。整体上,实验证明通过合理调度与分配 GPU 计算与显存资源,在计算资源有限的情况下,依然可以缓解模型规模与输出频率之间的取舍。
让参数量足够大的模型智能跟上物理世界的节拍,PhysisServe 朝这一目标迈出了探索性的一步。
Citation
Please cite this work as:
Physis AI Infra Team, "PhysisServe: Efficient Autoregressive Denoising Serving with Fine-Grained Stage-wise Pipelining," Physis AI, Oct. 12, 2026.
Or use the BibTeX citation:
@article{physisserve2026,
author = {Physis AI Infra Team},
title = {PhysisServe: Efficient Autoregressive Denoising Serving with Fine-Grained Stage-wise Pipelining},
journal = {Physis AI},
year = {2026},
month = {oct},
url = {https://physis-ai.com/blog/physisserve}
}
参考文献
- , “A Brain Too Big to Carry — On-Device vs Datacenter Inference,” SemiAnalysis, Sep. 14, 2026. [Online]. Available: https://newsletter.semianalysis.com/p/a-brain-too-big-to-carry-on-device. Accessed: Oct. 13, 2026.
- , “Training Agents Inside of Scalable World Models,” arXiv preprint, 2025. arXiv:2509.24527.
- , “Genie 3: A New Frontier for World Models,” Google DeepMind blog, Aug. 5, 2025. [Online]. Available: https://deepmind.google/blog/genie-3-a-new-frontier-for-world-models/. Accessed: Oct. 13, 2026.
- , “World Action Models are Zero-shot Policies,” arXiv preprint, 2026. arXiv:2602.15922.
- , “Native Video-Action Pretraining for Generalizable Robot Control,” arXiv preprint, 2026. arXiv:2607.08639.
- , “StreamDiffusionV2: A Streaming System for Dynamic and Interactive Video Generation,” in Proceedings of Machine Learning and Systems, vol. 8, pp. 1656–1669, MLSys, 2026. [Online]. Available: https://proceedings.mlsys.org/paper_files/paper/2026/file/698cfaf72a208aef2e78bcac55b74328-Paper-Conference.pdf.
- , “Learning Athletic Humanoid Tennis Skills from Imperfect Human Motion Data,” arXiv preprint, 2026. arXiv:2603.12686.
- , “Advancing Open-source World Models,” arXiv preprint, 2026. arXiv:2601.20540.
- , “MAGI-1: Autoregressive Video Generation at Scale,” arXiv preprint, 2025. arXiv:2505.13211.
- , “Introducing Helix 02: Full-Body Autonomy,” Company technical article, Jan. 27, 2026. [Online]. Available: https://www.figure.ai/news/helix-02. Accessed: Oct. 13, 2026.
- , “Wave Forcing: Towards Speed-of-Light Streaming Video Generation,” Project blog, Shanghai Jiao Tong University, 2026. [Online]. Available: https://sjtu-deng-lab.github.io/WaveForcing/. Accessed: Oct. 13, 2026.
- , “MiniMax H3,” Hugging Face model card, 2026. [Online]. Available: https://huggingface.co/MiniMaxAI/MiniMax-H3. Accessed: Oct. 13, 2026.
- , “Rolling Forcing: Autoregressive Long Video Diffusion in Real Time,” in International Conference on Learning Representations, vol. 2026, pp. 91177–91196, 2026. [Online]. Available: https://proceedings.iclr.cc/paper_files/paper/2026/file/935151cc6cb5d8b6816133b75233775a-Paper-Conference.pdf.
- , “Heuristics for Vector Bin Packing,” Unpublished manuscript, Jan. 2011. [Online]. Available: https://www.microsoft.com/en-us/research/publication/heuristics-for-vector-bin-packing/.
- , “Limited Discrepancy Search,” in Proceedings of the Fourteenth International Joint Conference on Artificial Intelligence, vol. 1, pp. 607–613, Morgan Kaufmann, 1995. [Online]. Available: https://www.ijcai.org/Proceedings/95-1/Papers/080.pdf.
