UnifoLM-VLA vs LingBot-VA：动作输出方式对比
name: Act chunk comparison
overview: 对比 UnifoLM-VLA 和 LingBot-VA 两个模型的 server 出动作方式，分析 LingBot-VA 是否必须逐步吐动作，以及如何让真机一次拿到整 chunk。
todos: []
isProject: false
UnifoLM-VLA vs LingBot-VA：动作输出方式对比
架构本质差异
两个模型的架构完全不同，导致它们出动作的方式有根本区别：
UnifoLM-VLA（无状态，每次全量推理）
- 无 KV cache / 无状态：每次请求都是独立的，VLM 全量编码图像 + text
- 一次返回整个 action_horizon：比如
(16, action_dim)就是 16 步动作 - 不需要 buffer：server 没有任何跨请求的状态
- 没有
/act_chunk：因为/act本身就返回多步
LingBot-VA（有状态，自回归 chunk 推理 + KV cache）
- 有状态 + KV cache：Transformer 在 chunk 间保持 KV cache，后续 chunk 的推理依赖前面所有 chunk 的 key_frames 和 predicted actions
- 一次推理产出一个 chunk：
frame_chunk_size=4, action_per_frame=8→ 一个 chunk = 32 步（首次 24 步） - 关键约束：后续 chunk 推理前，必须先用中间的观测图像（key_frames）更新 KV cache，这些 key_frames 是在执行动作过程中采集的真实图像
核心问题解答
LingBot-VA 是否必须一个一个吐？
不是。模型本身一次推理就产出一整个 chunk（24/32 步）。当前/act接口设计成逐步返回只是为了：
- 在每
action_per_frame=8步时，用当时的真实图像记录 key_frame - 这些 key_frames 用于下一 chunk 推理前的 KV cache 更新
但/act_chunk接口已经支持一次性返回整个 chunk。问题在于真机端需要自己在执行过程中采集 key_frames，然后在下一次请求时带上。
推荐方案：真机用/act_chunk+ 自行采集 key_frames
真机客户端的工作流：
需要修改的内容很少，只需要确保/act_chunk的key_frames处理逻辑正确即可（当前已实现）。
对比总结
- UnifoLM-VLA: 无状态，每次
/act= 全量推理 → 返回完整 horizon。简单但每次都要重新编码 - LingBot-VA: 有状态（KV cache），每次
/act_chunk= 用 cache 加速推理 → 返回完整 chunk。更快（后续 chunk 不用重新编码历史），但需要 key_frames 回传
结论：LingBot-VA 完全可以一次吐出整个 chunk，用/act_chunk就行。逐步吐只是为了在 server 端自动收集 key_frames，如果真机端自己收集并传回来，就可以直接用/act_chunk。