AREX Feed Article
vLLM 与 Physis-AI 联合介绍 PhysisServe 推理系统，称其核心技术将进入 vLLM-Omni
北京时间 10 月 20 日 13 时 06 分，vLLM 项目官方 X 账号 发帖，宣布与 Physis-AI 联合介绍推理系统 PhysisServe，并称赞其背后的 Physis-AI Infra 团队。按帖文说法，这套系统通过细粒度阶段流水线（stage pipelining）、分时（time-sharing）与多流联合调度，推进自回归去噪（autoregressive denoising）模型的推理服务（serving），在同一套推理系统内同时优化单流输出延迟与多流系统效率；vLLM 还承诺，PhysisServe 的核心技术将进入 vLLM-Omni，两个团队正紧密合作推进落地。
帖文给出的技术定位与合作说法目前均为发帖方口径。不过 PhysisServe 并非只有一句介绍：署名 Physis AI Infra Team 的技术报告已在 10 月 12 日发布于 ，给出五款 1.3B～33B 模型的实测数字，其中 33B 的 MiniMax H3 在 200 块 GPU 上做到每 4.1 毫秒输出一个数据块。
帖文本身：称赞、祝贺与没有公布的细节
帖文以一句「Physis-AI Infra 团队干得漂亮」开头，以祝贺 PhysisServe 「强势登场」（strong debut）收尾，中间没有给出任何性能数字，也没有说明集成的形式、时间表、代码仓库或许可证。在可见的回复里，用户 写道：「阶段流水线的细节，是让它感觉像一个真实系统、而不只是一篇论文的部分。」
难题：模型越大越准，物理世界等不起
从部署约束讲起：物理智能体（physical agent）身处一个不停变化的世界，慢一点的 LLM 只意味着等更久，而物理智能体的延迟可能让动作在执行前就已过时。它因此需要同时满足两个条件——模型够大、能准确预测物理世界，输出够快、能跟上物理过程与执行器。报告把「通用机器人模型停在几十亿参数、开源 LLM 已进入万亿参数区间」解读为硬约束的结果：模型必须装进能实时运行的硬件，智能被延迟和成本封顶。
报告讨论了两类用自回归去噪生成的模型。动作条件世界模型（ACWM）以当前观察加智能体动作为条件生成后续帧，Dreamer 4 和 Genie 3 属于这一类；世界动作模型（WAM）输入机器人观察、直接输出动作序列，如 DreamZero 与 LingBot-VA 2.0。自回归去噪与 LLM 逐 token（词元）生成的区别在于：后者要等前一个 token 走完全部 Transformer 块，前者以数据块（chunk）为单位，后一个块不必等前一个块完成全部去噪步，而是读走前块在同一步留下的带噪声 KV 缓存（key-value cache）接着算，相邻块的去噪可以错开、重叠。报告特别定义：文中的输出延迟指稳态下相邻两个数据块完成输出的间隔，不是对新输入的响应时间。
大模型与高频率在现有系统里难以兼得。报告列出的公开模型：LingBot-World 用约 28B 参数的 MoE（混合专家架构，每步约 14B 激活）跑出 16 FPS；MAGI-1 有 24B 参数，在 24 块高端 GPU 上约 0.98 秒生成一个 24 帧块，折合约 24 FPS；DreamZero 14B 约 7 Hz；LingBot-VA 2.0 约 15.3B 参数（每 token 约 2.5B 激活），142 毫秒一个块，约 7.0 块/秒，异步控制峰值 225 Hz。而人形机器人仿真训练为精确建模接触，仿真频率可达数千 Hz；部署中语义规划层通常低于 50 Hz，动作与伺服层要数百 Hz。报告的判断是：现有大参数模型提供的输出频率，与高频场景所需仍差约两个数量级。
三层设计：把流水线切到「一个块 × 一个去噪步」
报告称，尚无自回归去噪推理引擎同时调和模型规模与输出频率：Wave Forcing 按去噪步划分，每块 GPU 装完整模型，输出延迟不可能低于一次完整模型前向；StreamDiffusionV2 按块划分做流水线，单流可用 GPU 数被块数封顶，去噪步一多、批内计算变重，频率反而下降。
PhysisServe 的做法分三层。第一层是阶段流水线：把模型切成「某个去噪步上的某个 Transformer 块」这样的阶段（stage），去噪步与块两个维度同时做流水线，单流可用 GPU 数扩大到两者的乘积；稳态输出延迟只由最慢阶段的计算决定，加深模型或增加去噪步主要增加流水线深度和 GPU 数量，而不是拉长延迟。KV 缓存留在各自 GPU 上，GPU 之间只传隐状态，且无全局同步。以 2 个去噪步、4 个块的模型为例：8 个阶段对应 8 块 GPU，流水线充满后每个间隔产出一个块。
第二层是分时：阶段与物理 GPU 解耦，一块 GPU 在不同时间片里轮流执行多个阶段的任务；同一块上来自不同块、不同去噪步的任务可合并成批，摊薄权重加载与 kernel（算子内核）启动开销。实测中，Wan2.2 5B 在 1 块 GPU 上的单流 SLO（服务水平目标，报告中以实测块输出延迟表示）从 173 毫秒降到 98 毫秒（约 43%）；Wan2.1 1.3B 在 2 块 GPU 上从 187 毫秒降到 139 毫秒（约 26%）。
第三层是多流联合调度：每条流的各阶段任务与运行状态被打包成「虚拟 rank」，再映射到物理 GPU，放置采用 Best-Fit 与 Limited Discrepancy Search（LDS）；新流到达时按剩余容量放置，只有当整条流放得下、且单独运行也能满足 SLO 时才准入，已运行的流不做迁移。在固定 24 块 GPU、SLO 1,600 毫秒的测试里，与按流均分 GPU 组相比，联合调度把可验证的并发流数从 12 提到 39（Wan2.1 1.3B）、24 提到 46（Wan2.2 TI2V 5B）、8 提到 18（LTX-2.5 22B）、6 提到 10（MiniMax H3 33B）；四款模型提升 1.7～3.3 倍，Wan2.1 14B 反而从 24 降到 18。报告解释：它接近单卡容量上限，可共享的余量小。
实测数字，以及报告自己写明的边界
评测覆盖五款 ACWM/WAM 常用骨干：Wan2.1 1.3B、Wan2.2 TI2V 5B、Wan2.1 14B、LTX-2.5 22B、MiniMax H3 33B，分别有 30/30/40/48/50 个 Transformer 块、各 4 个去噪步，权重未做剪枝、压缩或量化（Wan2.1 用 StreamDiffusionV2 权重，其余采用基于 Rolling Forcing 的噪声 KV 微调）。每阶段占一块 GPU 时，33B 的 MiniMax H3（50 块 × 4 步 = 200 个阶段）单流输出延迟实测 4.083 毫秒，约 245 块/秒；按 ACWM 口径（每块含 1 个 latent，即潜变量，解码 4 帧）约合每秒 1,000 帧，按 WAM 口径（每个 latent 对应 16 个控制步）约合 3,900 Hz。五款模型的最小输出延迟在 1.895～7.547 毫秒之间，且不随参数量单调上升——33B 比 1.3B 还快。
报告给这些数字加了几道限定。其一，上述频率是 DiT（Diffusion Transformer）吞吐的换算值，不是闭环控制实测，也不含 VAE（变分自编码器）解码；其二，与公开系统对比时各家硬件配置与计时口径不一，只宜比数量级；其三，报告解决的是输出延迟而非响应延迟，新动作或新观察仍要走完全部阶段才会首次出现在输出里，高频闭环控制仍受实质限制；其四，噪声 KV 缓存推理的后训练算法尚不成熟，与干净 KV 推理的质量差异仍不清楚。报告还写道：「据我们所知」，PhysisServe 是第一个让 30B 级自回归扩散模型以低于 10 毫秒的块间隔连续输出、并让多路高频任务共享同一 GPU 池的推理系统。
各方口径：从技术报告、智源与北大到 vLLM-Omni
技术报告站点页脚标注「© 2026 北京逆矩阵科技有限公司」。 10 月 15 日发帖称，PhysisServe 由智源与 Physis、北京大学及 vLLM 项目合作开发，并称其让 10B+ 参数世界模型达到 kHz 级实时输出、比现有 SOTA 快 1～2 个数量级。
vLLM-Omni 则是 描述的全模态推理框架：把 vLLM 从文本自回归扩展到文本、图像、音频、视频与动作数据，支持 DiT 等非自回归架构，提供阶段流水线执行与基于 OmniConnector 的全分离部署（fully disaggregated serving），代码放在 仓库。文档列出的扩散模型支持名单里就有 MiniMax H3、LTX-2.5、Wan2.2，与 PhysisServe 评测用的骨干同族。
vLLM 帖文把 PhysisServe 的工作归于 Physis-AI Infra 团队，署名与 10 月 12 日报告的作者（Physis AI Infra Team）一致；这次发帖是链条上最新的一步，官方账号把 PhysisServe 的技术与 vLLM-Omni 明确挂钩。截至发稿，vLLM-Omni 官方文档首页尚未出现 PhysisServe 的条目。PhysisServe 目前可核验的公开载体仍是那份技术报告，其核心技术何时、以何种形式进入 vLLM-Omni 的仓库，要看后续提交。