三千帧、每帧二十万个点，一共十八个吉字节。这一页讲的不是怎么算得更快， 是怎么让要算的东西本来就不大。
3000 帧 × 每帧约 6 MB ≈ 18 GB光读一遍就要好几分钟。于是很自然会想：换更快的解析器、上 SSD、多线程解码。
这些都有用，但它们优化的不是主要矛盾。
p(t) = f( p(t−1), 运动模型 )
↑
只依赖上一帧的状态，不依赖上一帧的点云所以点云用一次就可以扔。而"状态"是什么？每帧每个物体几十个字节： 身份、位置、朝向、尺寸。
这就是"跑得动"的真正原因：不是算得快，是要算的东西本来就不大。
| 用途 | 读多少帧 | 分辨率 |
|---|---|---|
| 传播 | 0 | — |
| 关键帧取观测 | 关键帧数，通常五十分之一 | 全分辨率 |
| 校验 | 抽样加可疑段 | 降采样就够 |
算下来大概是：六十帧全分辨率加三百帧降采样，合计约 450 MB，而不是 18 GB。 降了四十倍。
传播不读点云很省，可是你怎么知道它算对了？如果永远不回头读，第五张骨牌倒了靠什么发现？
所以真正的问题不是"要不要读"，是"读多少才够"和"读来干什么"。
它在标注系统里的位置很具体：
| 用途 | 要全分辨率吗 | 能用 LOD 吗 |
|---|---|---|
| 关键帧上精确标注 | ✅ 必须 | ❌ 不能 |
| 校验，看框飘没飘 | ❌ 不需要 | ✅ 正好用 |
因为校验看的是"框和车的相对位置对不对"，不是"边界精确到几厘米"。 降到二十分之一，框飘出去一米照样一眼看得见。但你想靠降采样的点云精确定位一辆车， 那是做不到的。
远处：降采样
↓
┌────────┐
│ 目标 │ 全分辨率
└────────┘整帧降采样是错的，近处全、远处降才对。这也是点云标注工具里 "裁一块区域出来，周围保留一点"的做法。
纯链式传播是串行的，帧 t 依赖 t 减 1，加机器也没用。
而分段锚定之后，每个窗口独立，窗口之间就可以并行。这是分段锚定的第三个好处： 前两个是不累积误差、回退便宜。
性能问题的第一解不是"算得更快"，是"少算"。而少算的前提是想清楚哪些东西是每帧都要的。
这里的答案是：状态每帧都要，但它很小；点云很大，但它只在关键帧和校验时要。 把这两件事分开，数量级就变了。