Question: Why hard-reset KV cache instead of sliding-window eviction?

[l1jiahao]

Context

When current_start_frame >= local_attn_size, the current implementation (wan_flow_matching_action_tf.py:1410-1414) resets current_start_frame to 0, which triggers a full re-initialization on the next call: re-encode CLIP features, re-encode VAE, re-build all KV cache from scratch.

elif self.current_start_frame >= self.model.local_attn_size:
    print("current_start_frame >= local_attn_size, reset current_start_frame to 0")
    self.current_start_frame = 0

An alternative approach would be a sliding-window eviction: drop the oldest num_frame_per_block entries from the KV cache and shift the window forward, preserving recent history without a full restart.

Questions

1. What is the observed quality degradation at the reset boundary? Since all history is lost at once, the first few chunks after a reset lack historical context. Is there a measurable action prediction quality dip right after reset?

[seonghyeonye]

Hi, thanks for the great question and suggestion. We did not implement sliding-window eviction by default because the WAN backbone utilizes CLIP image embeddings. Implementing eviction might require re-encoding the CLIP features every time a window shift occurs, which could lead to significant inference slowdowns.

Regarding your question about the reset boundary: we have not yet quantified the potential performance dip or compared it against alternative implementations like sliding windows. It’s a great point for further optimization.