You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Autoregressive Diffusion Techniques such as Self Forcing rely on a rolling KV Cache across video frame chunks to transfer information from past context frames to the current frames being denoised.
This rolling KV Cache design (or variants similar to it) is likely to show up in other types of long video generation/ world models, so it would be good to see if we can support it natively in Diffusers.
I was just about opening this issue; it would be great! @kuantuna, you might be interested in this since your MAGI-1 PR-continuation is related to KV-Caching too.
Hello @sayakpaul , Here's my proposal:
First Before moving to the implementation I wanted to make sure that I understood Rolling KV cache properly , I went through the linked paper for Self-Forcing https://arxiv.org/abs/2506.08009 & also one another which was referenced inside it for inspiration https://arxiv.org/abs/2309.17453 streaming language model with attention sink:
the core algorithm ( sink based ) looks like this:
compute queries, keys, value for the current step.
identify sink tokens (fixed)
if adding new tokens would exceed the kv cache size, we remove the oldest kv entries after the sink region , shift the remainig to left & insert the new tokens
frame_seqlen=math.prod(grid_sizes[0][1:]).item()
current_start_frame=current_start//frame_seqlenroped_query=causal_rope_apply(
q, grid_sizes, freqs, start_frame=current_start_frame).type_as(v)
roped_key=causal_rope_apply(
k, grid_sizes, freqs, start_frame=current_start_frame).type_as(v)
current_end=current_start+roped_query.shape[1]
sink_tokens=self.sink_size*frame_seqlen# If we are using local attention and the current KV cache size is larger than the local attention size, we need to truncate the KV cachekv_cache_size=kv_cache["k"].shape[1]
num_new_tokens=roped_query.shape[1]
ifself.local_attn_size!=-1and (current_end>kv_cache["global_end_index"].item()) and (
num_new_tokens+kv_cache["local_end_index"].item() >kv_cache_size):
# Calculate the number of new tokens added in this step# Shift existing cache content left to discard oldest tokens# Clone the source slice to avoid overlapping memory errornum_evicted_tokens=num_new_tokens+kv_cache["local_end_index"].item() -kv_cache_sizenum_rolled_tokens=kv_cache["local_end_index"].item() -num_evicted_tokens-sink_tokenskv_cache["k"][:, sink_tokens:sink_tokens+num_rolled_tokens] = \
kv_cache["k"][:, sink_tokens+num_evicted_tokens:sink_tokens+num_evicted_tokens+num_rolled_tokens].clone()
kv_cache["v"][:, sink_tokens:sink_tokens+num_rolled_tokens] = \
kv_cache["v"][:, sink_tokens+num_evicted_tokens:sink_tokens+num_evicted_tokens+num_rolled_tokens].clone()
# Insert the new keys/values at the endlocal_end_index=kv_cache["local_end_index"].item() +current_end- \
kv_cache["global_end_index"].item() -num_evicted_tokenslocal_start_index=local_end_index-num_new_tokenskv_cache["k"][:, local_start_index:local_end_index] =roped_keykv_cache["v"][:, local_start_index:local_end_index] =v
however rolling kv cache has mutiple possible variants- like naive sliding window, StreamingLLM style with sink tokens etc So do we want to implement a single recommended implementation or a configurable system supporting multiple variants.
Proposed implementation : hook based design
I went through the FirstBlockCache & FasterCache implementations based on hook designs, for Rolling KV Cache we can also follow a similar structure,
at high level It would require implementing RollingKVCacheState to store & manage kv tensors, an AttentionHook performing the core logic.
Also for a cleaner implementation I would like to work on Modular block for wan pipelines as a follow up PR.
Please let me know you thoughts and I will start working on PR accordingly.
Hi @11happy I think we have decided to handle this one internally since it might require some changes to the design of the cache system. Apologies for inconvenience. Would you be okay to consider any of the other issues listed in the program?
Hi @11happy I think we have decided to handle this one internally since it might require some changes to the design of the cache system. Apologies for inconvenience. Would you be okay to consider any of the other issues listed in the program?
Sure, no worries, I took a look at the listed issues & issue #11966 seems interesting to me, I will take a deeper look at the issue & get back with the proposal. I will just do a comment there as well to make it easier to track, Thank you : )
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.
Please note that issues that do not follow the contributing guidelines are likely to be ignored.
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.
Please note that issues that do not follow the contributing guidelines are likely to be ignored.
The motivation from our side is that autoregressive DiTs (with KV caching) are a clear trend in world models, and we'd like to leverage the HF diffusers ecosystem to ship models to our partners in a familiar framework with minimal custom code.
I extracted/rebuilt an internal implementation we have at Odyssey as #13569 as an MVP similar to #12773 but a bit tighter in scope.
OK, I can definitely make it Wan-specific explicitly. In reality most people work on top of Wan or Wan-like architectures in any way, e.g., Self forcing and the many methods inspired by it, some recent work from Krea, etc.
Right now the PR does a bit of a ducktyping dance around generic-ish aspects, but in perfect honesty it does replicate Wan rope and assumes Wan-like norm placement.
I'll send an updated PR early next week if that's ok. Appreciate your help and general openness to this :)
Activity
tolgacangoz commentedon Nov 6, 2025
I was just about opening this issue; it would be great!
@kuantuna, you might be interested in this since your MAGI-1 PR-continuation is related to KV-Caching too.
sayakpaul commentedon Nov 6, 2025
@DN6 for clarity, to be able to perform inference, the one also needs a trained model right that supports rolling KV caching?
11happy commentedon Nov 12, 2025
Hii @sayakpaul , I would like to work on this as a part of Diffusers MVP program.
Thank you : )
11happy commentedon Nov 16, 2025
Hello @sayakpaul , Here's my proposal:
First Before moving to the implementation I wanted to make sure that I understood Rolling KV cache properly , I went through the linked paper for Self-Forcing https://arxiv.org/abs/2506.08009 & also one another which was referenced inside it for inspiration https://arxiv.org/abs/2309.17453 streaming language model with attention sink:
the core algorithm ( sink based ) looks like this:
I also went through the self forcing paper linked codebase & found this relavant code section
Link: https://github.com/guandeh17/Self-Forcing/blob/33593df3e81fa3ec10239271dd2c100facac6de1/wan/modules/causal_model.py#L206
however rolling kv cache has mutiple possible variants- like naive sliding window, StreamingLLM style with sink tokens etc So do we want to implement a single recommended implementation or a configurable system supporting multiple variants.
Proposed implementation : hook based design
I went through the
FirstBlockCache&FasterCacheimplementations based on hook designs, for Rolling KV Cache we can also follow a similar structure,at high level It would require implementing RollingKVCacheState to store & manage kv tensors, an AttentionHook performing the core logic.
Also for a cleaner implementation I would like to work on Modular block for wan pipelines as a follow up PR.
Please let me know you thoughts and I will start working on PR accordingly.
Thank you : )
sayakpaul commentedon Nov 16, 2025
@DN6 ^
toilaluan commentedon Nov 18, 2025
I converted self-forcing checkpoint to diffusers format so it can be loaded directly by
Code
Details
11happy commentedon Nov 19, 2025
Hii @DN6, would like to hear your thoughts on the proposal & questions.
Thank you : )
DN6 commentedon Nov 19, 2025
Hi @11happy I think we have decided to handle this one internally since it might require some changes to the design of the cache system. Apologies for inconvenience. Would you be okay to consider any of the other issues listed in the program?
11happy commentedon Nov 19, 2025
Sure, no worries, I took a look at the listed issues & issue #11966 seems interesting to me, I will take a deeper look at the issue & get back with the proposal. I will just do a comment there as well to make it easier to track, Thank you : )
github-actions commentedon Jan 9, 2026
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.
Please note that issues that do not follow the contributing guidelines are likely to be ignored.
github-actions commentedon Feb 3, 2026
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.
Please note that issues that do not follow the contributing guidelines are likely to be ignored.
gueraf commentedon May 1, 2026
Hi,
is there appetite for reviving this line of work?
The motivation from our side is that autoregressive DiTs (with KV caching) are a clear trend in world models, and we'd like to leverage the HF diffusers ecosystem to ship models to our partners in a familiar framework with minimal custom code.
I extracted/rebuilt an internal implementation we have at Odyssey as #13569 as an MVP similar to #12773 but a bit tighter in scope.
Please let me know what you think.
Cheers,
Fabian
sayakpaul commentedon May 1, 2026
I think the models with KVcaching we have added to the core codebase (KleinKV, for example) implement their own KVcache class.
Once we start seeing some patterns, we could try to uniformize some of the abstractions.
gueraf commentedon May 1, 2026
OK, I can definitely make it Wan-specific explicitly. In reality most people work on top of Wan or Wan-like architectures in any way, e.g., Self forcing and the many methods inspired by it, some recent work from Krea, etc.
Right now the PR does a bit of a ducktyping dance around generic-ish aspects, but in perfect honesty it does replicate Wan rope and assumes Wan-like norm placement.
I'll send an updated PR early next week if that's ok. Appreciate your help and general openness to this :)
gueraf commentedon May 6, 2026
Sorry for the delay. I sent out #13681. Thanks @sayakpaul for your help!
cc @nicolasgriffiths @jeff-hawke