陈博远独家解读：物理AI推理引擎PhysisServe如何兼顾智能与高频输出｜甲子光年

栏目：互联网 | 来源：甲子光年 | 2026-10-21 17:33

当物理AI模型不断变大，能否通过扩展算力，让它们跟上物理世界的节拍？

特邀作者｜陈博远（逆矩阵创始人）

一个330亿参数的模型，连续产生结果的间隔，能比一个13亿参数的模型更短吗？

近日，逆矩阵与vLLM、智源研究院、北京大学联合发布的物理AI推理系统PhysisServe，给出了一组这样的实验结果：在各自充分并行的配置下，33B参数的MiniMax H3，其稳态输出间隔短于1.3B参数的Wan2.1。

其中，MiniMax H3在200张GPU上，每隔4.083毫秒完成一个chunk（视频块），约每秒输出245个chunk。按每个chunk对应4帧换算，等效帧吞吐接近每秒1000帧。

这个区别可以用生产线来理解：一件产品从进入工厂到完成，需要经过所有工序；但生产线填满后，可以每隔很短的时间就交付一件产品。PhysisServe提升的，正是持续交付的频率。

这组结果指向一个值得关注的问题：当物理AI模型不断变大，能否通过扩展算力，让它们跟上物理世界的节拍？

技术博客：

https://physis-ai.com/blog/physisserve/en

开源地址：

https://github.com/Physis-AI/PhysisServe

1.物理AI将会产生新的基座模型范式， Physical AI Infra是立身之本

PhysisServe背后首先是一个关于物理AI的基础判断。

随着数据、模型规模与算力持续增长，物理世界也会像数字世界的大语言模型一样存在基座模型的Scaling Law，而如何让超大规模参数量的模型持续、高频地交付预测或动作将成为核心问题。

近期社区爆火讨论的GPT-6 Astra操纵具身机器人的例子，给出一种物理AI的可能性——通用大语言模型结合工具链，确实可以完成简单的诸如拼接、摆放物体甚至绘画等机器人任务。

现在LLM推理效率，动辄每秒生成数百甚至上千token，听起来很快。但这个数字描述的是连续输出时的吞吐，放到需要反复“观察—决策—执行”的交互场景里，真正卡脖子的不是模型一口气能吐多少字，而是它完成一轮闭环决策要花多久。

SE3 Labs的实验提供了一个具体的参照[3]，GPT-6 Astra在执行中持续观察并发出指令，控制YAM机械臂把红色LEGO放入盒子，20次尝试成功18次，合计记录了774次模型调用和79300个输出token。若每次推理对应一轮同步工具交互，则每条轨迹平均经历38.7轮、生成3965个token。

Agentic控制模式下，通用语言模型每做一次决策、发一条指令，这个过程要花多久？

参考一下当前第三方测试的最先进水平：SemiAnalysis对Qwen3.5 397B的测算[4]显示，即便是这样一个百B级的稀疏模型，在最优硬件与推理优化配置下，单用户有效生成速度也就在700 tokens/s量级。

Qwen3.5 397B的交互速度与成本效率

沿用这一平均生成量，假设Astra也能达到Qwen3.5 397B [4]的生成速率，则每轮仅生成就需约0.146秒，对应约6.8Hz，即每秒约7轮高层交互。

我们把这个数字需要放在高层交互的层级上理解。6.8 Hz是大模型“做一次决策、发一条指令”的频率，不是机械臂关节的控制频率——后者可以由独立的低层控制器完成，不必每一步都等大模型推理。

但问题在于：凡是需要大模型理解场景、规划动作、处理异常的高层环节，每一步都要等一串token逐一生成完毕。即便堆上顶级芯片并对推理基础设施做充分优化，逐token串行解码的依赖仍然存在，高层决策频率就此被卡在几赫兹量级。

而物理世界是流动的、延迟敏感的：当机器人需要根据视觉、力觉等传感器信号实时调整动作时，决策回路必须在足够短的时间内闭环。

这和数字世界是根本性的不同：对LLM而言，变慢通常只是为同一个回答多等一会儿；对物理智能体而言，延迟可能使动作在执行前就已过时，模型再强也无法保证安全、流畅的交互。

面对这个约束，一种直觉的做法是把模型做小，以换取更快的推理速度。

但我们认为这条路长期走不通。物理世界的信息只会越来越丰富：当前模型主要接收视觉观测，未来必然要引入力觉、温度、接触等更多模态。模型要理解和融合这些越来越复杂的输入，规模就不能一直停留在几十亿参数的水平。

因此，物理智能体对模型的要求是双重的：既要足够大的模型来准确理解与预测物理世界，又要足够快的输出以跟上物理过程与执行器的节拍。

针对这个问题，我们团队的回答是：最终的出路不是把模型做小，而是从架构和系统层面让模型能更密集、更并行地产出动作预测。

"智能密度定律"（Densing Law）[1]指向同一方向：随着数据量、模态数和任务复杂度增长，单位参数能承载的智能密度有上限，模型参数规模最终必须随之扩张；没有更高效的计算架构，物理AI的能力增长迟早会撞上延迟的墙。

Scaling law本身并不绑定特定架构或算法。在LLM领域，无论是各种Transformer注意力变体，还是基于RNN架构的RWKV、基于扩散机制的LLaDA等路线，持续扩大数据、参数与算力都能带来可预测的能力提升；架构决定的是扩展效率、推理成本和延迟表现，而不是“能不能scaling”这件事本身。

这意味着，物理AI完全可以也必须去探索一种新的模型架构：它不牺牲参数规模带来的能力增长，同时从根本上摆脱逐token串行解码的延迟瓶颈。

LLM领域已经出现DSpark[1]、DFlash[2]等工作，通过草稿模型、块并行生成等方式尝试压缩串行解码的等待；对数字任务而言，这些更多是体验与成本层面的优化。对物理AI来说，高频实时交互的要求决定了并行生成不能只是事后加速，而需要在模型架构与推理系统设计之初就被纳入考量。

PhysisServe所探索的自回归去噪流水线，正是围绕这一需求展开的系统设计，也是回答“如何让超大规模参数量的物理智能模型持续、高频地交付预测或动作”问题的关键一步。

在这一方向下，两个层面的协同同样值得探索。在系统层面，计算将围绕反应时间，在端、边、云之间重新分工。在芯片层面，留在本体里的计算需要更高效地使用能源，模型、芯片和本体的设计会更加紧密——计算放在哪里、数据怎样流动、哪些能力必须随时可用，将越来越需要共同决定。

2.让相邻输出重叠推进

PhysisServe面向采用自回归去噪的世界模型与世界动作模型：前者根据观测和动作预测后续环境，后者根据观测生成动作序列。它们以chunk为单位连续生成，每个chunk经过多次去噪形成结果。

技术报告在ACWM与WAM常用的五个backbone上对PhysisServe展开评估：Wan2.1 1.3B、Wan2.2 TI2V 5B、Wan2.1 14B、LTX-2.5 22B与MiniMax H3 33B。

图中的关键区别是等待关系。在常规逐token自回归中，下一个token依赖前一个token完成；在支持带噪历史的自回归去噪中，后一个chunk可以读取前一个chunk在对应阶段留下的带噪KV cache，不必等其全部去噪完成。多个chunk因而能够交错推进。这一方式需要模型支持带噪历史条件，并可能需要后训练适配。

相邻chunk的计算可以重叠，缩短的是流水线稳定运行后的连续输出间隔

3.把完整计算拆成更细的流水线

PhysisServe将“某个去噪步上的某个Transformer block”定义为一个stage，同时沿去噪步与模型层两个维度拆分计算。图中2个去噪步、4个block被展开为8个stage，分别由8张GPU执行。每个chunk仍须走完整条路径，但不同chunk可以同时占据不同stage。

MiniMax H3 33B的实验采用50个block、4个去噪步，对应200个stage；每个stage独占一张GPU时，实测稳态输出间隔为4.083毫秒，约245chunks/s。流水线填满后，输出节拍主要取决于最慢stage的计算与通信成本。因此，总参数量不能独自决定输出频率；代价是更多GPU，以及仍需单独评估的新输入响应时间。