name: Act chunk comparisonoverview: 对比 UnifoLM-VLA 和 LingBot-VA 两个模型的 server 出动作方式分析 LingBot-VA 是否必须逐步吐动作以及如何让真机一次拿到整 chunk。todos: []isProject: falseUnifoLM-VLA vs LingBot-VA动作输出方式对比架构本质差异两个模型的架构完全不同导致它们出动作的方式有根本区别UnifoLM-VLA无状态每次全量推理POST /act(图state)Qwen-VL 全量编码DiT Action Head(flow-matching)actions: (T, D)一次性返回整个 horizonPOST /act(新图state)重新全量编码DiT Action Headactions: (T, D)无 KV cache / 无状态每次请求都是独立的VLM 全量编码图像 text一次返回整个 action_horizon比如(16, action_dim)就是 16 步动作不需要 bufferserver 没有任何跨请求的状态没有/act_chunk因为/act本身就返回多步LingBot-VA有状态自回归 chunk 推理 KV cacheChunk 2: 后续推理compute_kv_cache(key_frames 上次 action)更新 Transformer KV cacheTransformer 去噪(利用 KV cache)生成下一 chunkaction bufferF*H 步消费 bufferPOST /act → pop 1步POST /act → pop 1步每 H 步存 key_frame... 直到 buffer 空Chunk 1: 首次推理POST /act (图)VAE 编码图像→ latentTransformer 去噪生成 video latent actionaction buffer(F-1)*H 步有状态 KV cacheTransformer 在 chunk 间保持 KV cache后续 chunk 的推理依赖前面所有 chunk 的 key_frames 和 predicted actions一次推理产出一个 chunkframe_chunk_size4, action_per_frame8→ 一个 chunk 32 步首次 24 步关键约束后续 chunk 推理前必须先用中间的观测图像key_frames更新 KV cache这些 key_frames 是在执行动作过程中采集的真实图像核心问题解答LingBot-VA 是否必须一个一个吐不是。模型本身一次推理就产出一整个 chunk24/32 步。当前/act接口设计成逐步返回只是为了在每action_per_frame8步时用当时的真实图像记录 key_frame这些 key_frames 用于下一 chunk 推理前的 KV cache 更新但/act_chunk接口已经支持一次性返回整个 chunk。问题在于真机端需要自己在执行过程中采集 key_frames然后在下一次请求时带上。推荐方案真机用/act_chunk 自行采集 key_frames真机客户端的工作流ServerRobotServerRobotloop[每执行 8 步]loop[每执行 8 步]以此类推...POST /act_chunk {image, instruction, state}{actions: [24步], action_per_frame: 8}执行 action[0..7]拍照存为 key_framePOST /act_chunk {image, instruction, state, key_frames: [3张图]}{actions: [32步], action_per_frame: 8}执行 action[0..7]拍照存为 key_framePOST /act_chunk {key_frames: [4张图]}需要修改的内容很少只需要确保/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。