Sử dụng đóng gói ngữ cảnh khung hình đầu vào trong mô hình Next-Frame Prediction để tạo video

• FramePack là một cách tiếp cận dựa trên Next-Frame Prediction nhằm dùng mô hình khuếch tán video 13B để tạo video dài ngay cả với 6GB bộ nhớ GPU trên laptop
• Thay vì xử lý các khung hình đầu vào với cùng độ dài, hệ thống dùng patchifying kernel khác nhau cho từng khung hình để phân bổ nhiều tài nguyên GPU hơn cho các khung hình quan trọng gần mục tiêu dự đoán
• Với HunyuanVideo, một khung hình 480p có thể giảm từ khoảng 1536 token ở (1, 2, 2) xuống còn 192 token ở (2, 4, 4), và độ phức tạp tính toán streaming là O(1)
• FramePack Scheduling điều chỉnh mức độ quan trọng của khung hình và tỷ lệ nén; trong image-to-video cũng có thể dùng lịch trình xem các khung hình khởi đầu là quan trọng như nhau
• Để giảm drifting do lỗi tích lũy khi tạo video dài, phương pháp dùng lấy mẫu hai chiều phá vỡ causality; inverted anti-drifting sampling phù hợp với image-to-video

---

Đóng gói ngữ cảnh khung hình đầu vào của FramePack

• FramePack là phương thức trong đó mô hình Next-Frame hoặc Next-Frame-Section Prediction nhận nhiều khung hình đầu vào và tạo khuếch tán các khung hình mới
• Hiệu năng mục tiêu và điều kiện sử dụng như sau
  • Tạo hàng nghìn khung hình ở fps 30 bằng mô hình 13B trên 6GB bộ nhớ GPU laptop
  • Fine-tune mô hình video 13B với batch size 64 trên một node 8xA100/H100 duy nhất
  • Tạo ở mức 2,5 giây/khung hình trên RTX 4090 cá nhân trước tối ưu, 1,5 giây/khung hình khi dùng teacache
  • Không có timestep distillation
• Điểm cốt lõi là thay vì chỉ nối các ảnh khung hình đầu vào lại với nhau, hệ thống bố trí độ dài ngữ cảnh khác nhau cho từng khung hình trong layout bộ nhớ GPU logic
• Độ dài ngữ cảnh theo từng khung hình được điều chỉnh bằng các patchifying kernel khác nhau
  • Trong HunyuanVideo, khung hình 480p có khoảng 1536 token khi dùng patchifying kernel (1, 2, 2)
  • Khi đổi sang patchifying kernel (2, 4, 4), còn 192 token cho mỗi khung hình
• Các khung hình quan trọng hơn, chẳng hạn như khung hình gần mục tiêu dự đoán khung hình tiếp theo, được cấp ngữ cảnh dài hơn
• Độ phức tạp tính toán streaming là O(1), không phải O(nlogn) hay O(n)

Lập lịch và chống trôi dạt

• FramePack Scheduling hỗ trợ các trường hợp mức độ quan trọng của khung hình không theo một mẫu đơn giản, thay đổi tỷ lệ nén, hoặc xử lý các khung hình do người dùng chỉ định là quan trọng hơn
• Trong image-to-video, vì khung hình đầu tiên quan trọng, có thể dùng lịch trình khiến các khung hình bắt đầu có mức độ quan trọng như nhau
• Mọi lịch trình đều là O(1), và đánh giá về nhiều cách lập lịch được đưa vào Paper
• Trong mô hình Next-Frame Prediction, drifting — chất lượng giảm khi video dài hơn — là một vấn đề phổ biến
  • Nếu lặp lại việc đưa khung hình cuối cùng đã tạo vào làm đầu vào để tạo video dài, video nhanh chóng hỏng sau 5–6 lần và có thể suy giảm nghiêm trọng sau khoảng 10 lần
  • Vấn đề này còn được gọi là error accumulation hoặc exposure bias
• Bài báo cũng bao gồm các thử nghiệm với những phương pháp hiện có như history noise augmentation, special cfg guidance và rolling diffusion timesteps
• Để xử lý drifting một cách căn bản, cần phá vỡ causality và biến quá trình lấy mẫu thành hai chiều
  • Chỉ vanilla sampling là phương thức causal
  • anti-drifting sampling và inverted anti-drifting sampling là phương thức hai chiều
  • inverted anti-drifting sampling coi khung hình đầu tiên là mục tiêu xấp xỉ trong mọi lần suy luận, nên phù hợp với image-to-video

Điều kiện demo và tài liệu tham khảo

• Kết quả demo được tính toán bằng RTX 3060 6GB laptop và biến thể 13B HY
  • image-to-5-seconds: 30fps, 150 khung hình
  • image-to-60-seconds: 30fps, 1800 khung hình
  • Để phù hợp với kho GitHub, video được nén bằng h264crf18
• Các tài liệu liên quan gồm Paper, Code, FramePack-P1 Preview

[GN⁺]

Các ý kiến trên Hacker News

• Người này đúng là thiên tài. Có thể có người chưa biết, nhưng ControlNet cũng là do người này tạo ra
  Đây là mô hình tạo video đầu tiên đủ dùng chạy được trên phần cứng tiêu dùng, nên rất có ý nghĩa; tôi cũng kỳ vọng sắp tới sẽ có hỗ trợ tư thế ControlNet

  • IC-Light cũng do người này tạo ra. Tôi thắc mắc vì sao đến giờ họ vẫn đóng góp cho mã nguồn mở
    Chắc các công ty lớn đã đưa ra những đề nghị khổng lồ, thật sự là tài năng xuất chúng
  • Tôi chưa thử nghiêm túc việc tạo video vì khá thiếu kiên nhẫn, nhưng Wan cũng khá ổn trên phần cứng phổ thông mà nhỉ?

• Buồn cười ở chỗ dường như nó cứ nhất quyết bắt mọi người nhảy. Người đang ngồi để phỏng vấn cũng bắt đầu nhảy ngay khi vẫn ngồi

  • Có lẽ là vì prompt có chữ nhảy trong đó. Nếu đổi prompt thì chắc có thể khiến họ làm hành động khác, nhưng có lẽ sẽ kém vui hơn
  • Có vẻ là ảnh hưởng từ bộ dữ liệu huấn luyện TikTok công khai quy mô lớn mà nhiều nhà nghiên cứu video sử dụng
  • Một quan sát thú vị
    Với ảnh tĩnh thì lúc nào cũng tìm mắt, còn với video thì lúc nào cũng tìm điệu nhảy

• Các ví dụ khá ấn tượng, trong khi tài nguyên dùng để tạo ra chúng thực ra gần như không đáng kể. Có vẻ có thể chạy suy luận ngay cả trên phần cứng tiêu dùng thế hệ trước
  Một lúc nào đó tôi cũng muốn thấy số liệu thông lượng suy luận trên 5090

• Liệu có thể làm việc này theo hướng không gian không? Ví dụ, thay vì tạo cả ảnh cùng lúc, liệu có thể tạo ảnh theo kiểu từ trên xuống dưới không?

• Có thể dùng cái này cho nội suy video thay vì ngoại suy không?

  • “inverted anti-drifting” mà bài báo nói về cơ bản gần với cách trước tiên ngoại suy thật nhiều, rồi nội suy ngược lại

• Đáng kinh ngạc. Nếu có nhiều tài nguyên hơn như RAM thì có thể nhanh hơn không? Tôi cũng tò mò liệu có thể đẩy tốc độ cao hơn trên H100 hay H200 không

• Trông như các chuyển động nó làm được thực chất chỉ có nhảy

  • Cũng có khá nhiều chuyển động không phải nhảy. Ví dụ chân không nhảy thì chỉ có một hai cái, nhưng không phải chỉ có chân là chuyển động
  • Vì nó cũng nhận prompt văn bản cùng với ảnh đầu vào, nên nhiều khả năng họ đã đưa nhảy vào các ví dụ