The Community Is Asking for Usability, Not Training Materials

[Dev0Lab1]

I’m not sure what is going on with your team, but the strategy behind releasing this model/code seems flawed from the start.

After reading your last two responses, I see either a lack of understanding of the community's needs, or your intentions for releasing this model are not being communicated clearly.

If your goal is simply to release a model and you do not care whether the community adopts it, then continue on your current path. However, if you actually want the model to be used, you should stop focusing on what you think the community needs and start listening to what the community is asking for.

For example, a user asked about ComfyUI and FP8 support, and your response largely deflected the question by talking about releasing training materials. At this stage, who cares about training materials when the model is not even being used yet? The priority should be usability, compatibility, and adoption. Training resources become relevant only after people have a reason to use the model in the first place.

[guanw-pku]

Thanks for the feedback, and sorry for the frustration here.

We agree that usability and adoption are important. The main issue on our side is limited bandwidth at the moment, with several TODOs being handled in parallel, so some things are taking longer than expected.

ComfyUI support is already in progress and should be pushed in the next few days. We’ll also look into FP8 and other usability-related requests as we continue improving the release.

Just to clarify, we prioritized the training code because several users had asked for it by email. We’ll keep working on usability and compatibility as we improve the release.

Thanks again for raising this. We appreciate the feedback and will keep iterating.

[Dev0Lab1]

I can see the effort and attention you've put into the repository, especially with the recent addition of FP8 and ComfyUI support. However, I have not been able to use the code/model effectively.

From what I can tell, the ComfyUI implementation appears to be more of a wrapper around the existing codebase rather than a native integration. As a result, it still seems to load entire models into memory, quickly consuming over 40 GB of combined VRAM and RAM. This makes even the initial model loading process take several minutes. Since most consumer GPUs do not have that much VRAM available, a significant portion of the model ends up spilling into system RAM, which is many times slower and negatively impacts overall performance.

On the same system, I can run Wan 2.2 I2V 14B models (Q5 quantized, approximately 10 GB on disk) together with the text encoders, VAE, and other components while staying entirely within about 11 GB of VRAM. Loading is nearly instantaneous, and generation is smooth and fast. Given this, I would expect your model to be usable in a similar manner, but so far I have been unable to get it running that way.

Additionally, if I let the generation continue for an extended period, the resulting video becomes completely corrupted or broken.

My main motivation for trying this model is its ability to generate audio that is synchronized with the video. For video generation alone, my existing Wan 2.2 14B setup already works flawlessly, delivering high-quality results with fast generation times.