原贴链接

博客：[https://huggingface.co/blog/RhymesAI/allegro]；论文：[https://arxiv.org/abs/2410.15458]；Hugging Face：[https://huggingface.co/rhymes - ai/Allegro]。快速浏览了论文，写得非常详细。https://llminfo.image.fangd123.cn/images/o4h0ng2ig8wd1.png!/format/webp。他们之前的开源视觉语言模型（VLM）Aria也很棒，有非常详细的微调指南，我一直在尝试将其用于我的监控基础和推理任务。

讨论总结

这个讨论围绕新的text - to - video模型Allegro展开。部分人对其在本地视频生成领域的先进性表示肯定，且对领域发展感到高兴。同时，许多人关注模型的性能，如生成速度慢、VRAM使用量在有或无CPU卸载时的情况，也有人提及模型灵活性的问题。此外，还有用户遇到访问受限的情况并探讨解决途径，总体氛围是积极探索新模型的特点和解决使用中的问题。

主要观点

  1. 👍 认为Allegro是本地文本到视频的SOTA。
    • 支持理由：未提及具体理由，但直接表明观点。
    • 反对声音：无。
  2. 🔥 模型运行速度慢，生成单个视频耗时较长。
    • 正方观点：多位评论者分享自己的试用体验，如在A100设备上生成单个视频需40分钟。
    • 反方观点：无。
  3. 💡 量化T5可降低VRAM使用量以适配不同显存的显卡。
    • 解释：FullOf_Bad_Ideas提出量化T5能解决VRAM使用量过大的问题。
  4. 🤔 可根据经验牺牲模型生成质量来减少VRAM使用量和生成时间。
    • 解释：Comprehensive_Poem27根据自身经验提出这种平衡模型性能的方法。
  5. 😕 在使用diffusers访问Allegro时遇到访问受限的问题。
    • 解释：goddamnit_1反馈了这一问题。

金句与有趣评论

  1. “😂 Seems like new local text to video SOTA, I am happy local video generation space is heating up.”
    • 亮点：表达了对Allegro成为本地文本到视频SOTA的看法，同时体现出对本地视频生成领域发展的积极态度。
  2. “🤔 This model is also apache - 2.0 which makes me happy.”
    • 亮点：体现出对模型采用apache - 2.0协议的满意态度。
  3. “👀 Edit: tried it now, about 60 - 90 mins per generation. Ouch.”
    • 亮点：通过分享试用时生成单个视频的时长，直观地展现出模型生成速度慢的问题。
  4. “😎 kahdeg: vram 9.3G with CPU offload and significant increased inference time”
    • 亮点：提供了模型在有CPU卸载时VRAM使用量和推理时间增加的具体数据。
  5. “😏 Comprehensive_Poem27: From my experience with other models, It’s really flexible, like you can sacrifice the generation quality in exchange for very little vram and generation time( like more than 10 minutes less than half an hour)?”
    • 亮点：从自身经验出发，阐述了模型在性能平衡方面的灵活性。

情感分析

总体情感倾向是积极探索的。主要分歧点较少，大家更多是在分享自己对模型性能和使用的不同发现。可能的原因是新模型刚推出，大家都在积极探索其特点、优势以及存在的问题，更多是信息的交流而非观点的对抗。

趋势与预测

  • 新兴话题：可能会有更多关于如何提高模型速度、减少VRAM使用量以及解决访问受限问题的讨论。
  • 潜在影响：如果这些问题得到解决，可能会推动文本到视频模型在更多领域的应用，如视频创作、监控领域的视频生成等。

详细内容：

标题：关于新文本转视频模型 Allegro 的热门讨论

近日，Reddit 上出现了关于新文本转视频模型 Allegro 的热烈讨论，该帖子引起了众多用户的关注。帖子中提供了有关 Allegro 的多个链接，包括博客https://huggingface.co/blog/RhymesAI/allegro、论文https://arxiv.org/abs/2410.15458以及相关的 HF 链接https://huggingface.co/rhymes-ai/Allegro。有人表示快速浏览了论文，称赞其非常详细。

讨论焦点主要集中在该模型的性能和使用体验上。有人认为这似乎是新的本地文本转视频的 SOTA，对本地视频生成领域的发展感到高兴，因为该模型是 Apache-2.0 协议。但也有人吐槽尝试使用后，每个生成过程约 60 - 90 分钟，太慢了。比如在 A100 80gb 上，不进行 CPU 卸载时生成一个视频需要 40 分钟。还有用户提到在使用过程中存在的各种技术问题，如 VRAM 占用、推理时间增加、模型运行速度慢等。

有人分享说，使用 CPU 卸载时 VRAM 为 9.3G，推理时间显著增加，不使用 CPU 卸载时 VRAM 为 27.5G，不确定内存要求和 CPU 卸载会增加多长时间。还有人提到可以对 T5 进行量化以适应不同的 VRAM 卡。有人提供了一个脚本https://gist.github.com/Downtown-Case/d4b5718bb5a119da3ee1d53cf14a8145，称其使用 HF quanto 将 T5/Flux 量化为 int8，可能会有帮助，但也提醒会有问题。

有人根据自己的经验表示，该模型很灵活，可以牺牲生成质量来换取更少的 VRAM 和生成时间，比如减少 10 分钟以上，不到半小时。但也有人表示在尝试时遇到了访问问题，称使用 diffusers 时显示需要盖茨访问。

综合来看，大家对 Allegro 模型的性能和使用体验存在较大争议。一方面认可其在某些方面的创新性和灵活性，另一方面对其速度慢等问题表示不满，希望能有进一步的改进和优化。