Questions about changing the history length, and the training cose of framepack

Nobody has claimed this yet.

Dear authors,

Thanks for your inspiring work! I read through your code and paper and found that the history length used in the code implementation is 1+2+16=19 latent frames. The paper said the method should support longer length, so I am wondering if variable length of history frames can be supported by finetuning the currently provided framepack model with e.g. LoRA training?

Also, I have a question about the training cost. In the paper, you said "FramePack achieves a batch size of 64 on a single 8×A100-80G node with the
13B HunyuanVideo model at 480p resolution". Do you mean full-parameter training of framepack with 13B Hunyuan base model can be trained with 8*80G GPUs? I have tested LoRA training using code from [musubi-tuner](https://github.com/[kohya-ss/musubi-tuner](https://github.com/kohya-ss/musubi-tuner/tree/main)/tree/main), but it cost about 38G for training lora only.

I hope you can help about these questions. Thank you so much!

Start by comparing the history-length implementation described in the FramePack code with the paper's claim about longer histories. Then review the linked musubi-tuner LoRA training code and the paper's 13B HunyuanVideo, 480p, and 8×A100-80G training details; done means documenting whether variable history can be fine-tuned and clarifying the stated training setup.

Written by the indexing model from the issue text.