การใช้การแพ็กคอนเท็กซ์ของเฟรมอินพุตในโมเดล Next-Frame Prediction สำหรับการสร้างวิดีโอ

 (lllyasviel.github.io)
2 คะแนน โดย GN⁺ 2025-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • FramePack เป็นแนวทางที่อิงกับ Next-Frame Prediction เพื่อให้สามารถใช้โมเดลวิดีโอดิฟฟิวชันขนาด 13B สร้างวิดีโอยาวได้แม้บนหน่วยความจำ GPU โน้ตบุ๊ก 6GB
  • แทนที่จะปฏิบัติต่อเฟรมอินพุตทุกเฟรมด้วยความยาวเท่ากัน ระบบจะใช้ patchifying kernel ที่ต่างกันในแต่ละเฟรม เพื่อจัดสรรทรัพยากร GPU ให้มากขึ้นกับเฟรมสำคัญที่อยู่ใกล้กับเป้าหมายการพยากรณ์
  • สำหรับ HunyuanVideo เฟรม 480p สามารถลดจากประมาณ 1536 โทเค็นที่ (1, 2, 2) ลงเหลือ 192 โทเค็นที่ (2, 4, 4) ได้ และความซับซ้อนในการคำนวณแบบสตรีมมิงเป็น O(1)
  • FramePack Scheduling ปรับทั้งความสำคัญของเฟรมและอัตราการบีบอัดได้ และในงาน image-to-video ก็สามารถใช้การจัดตารางที่ให้เฟรมเริ่มต้นมีความสำคัญเท่ากันได้
  • เพื่อลดปัญหา drifting ที่เกิดจากความคลาดเคลื่อนสะสมในการสร้างวิดีโอยาว จะใช้การสุ่มตัวอย่างแบบสองทิศทางที่ทำลาย causality และ inverted anti-drifting sampling เหมาะกับ image-to-video

การแพ็กคอนเท็กซ์ของเฟรมอินพุตใน FramePack

  • FramePack เป็นวิธีที่ให้โมเดล Next-Frame หรือ Next-Frame-Section Prediction รับหลายเฟรมอินพุต แล้วสร้างเฟรมใหม่ด้วยการดิฟฟิวชัน
  • ประสิทธิภาพเป้าหมายและเงื่อนไขการใช้งานมีดังนี้
    • ใช้โมเดล 13B สร้างหลายพันเฟรมที่ fps 30 บน หน่วยความจำ GPU โน้ตบุ๊ก 6GB
    • ไฟน์จูนโมเดลวิดีโอ 13B ด้วย batch size 64 บนโหนดเดี่ยว 8xA100/H100
    • สร้างได้ที่ 2.5 วินาที/เฟรมก่อนการปรับแต่ง และ 1.5 วินาที/เฟรมเมื่อใช้ teacache บน RTX 4090 ส่วนตัว
    • ไม่มี timestep distillation
  • แกนสำคัญคือ แทนที่จะนำภาพเฟรมอินพุตมาต่อกันตรง ๆ จะจัดวางความยาวคอนเท็กซ์ของแต่ละเฟรมให้ต่างกันใน GPU memory layout เชิงตรรกะ
  • ความยาวคอนเท็กซ์ของแต่ละเฟรมถูกควบคุมด้วย patchifying kernel ที่ต่างกัน
    • ใน HunyuanVideo เฟรม 480p มีประมาณ 1536 โทเค็นเมื่อใช้ patchifying kernel (1, 2, 2)
    • หากเปลี่ยนเป็น patchifying kernel (2, 4, 4) จะเหลือ 192 โทเค็นต่อเฟรม
  • เฟรมที่สำคัญกว่า เช่น เฟรมที่อยู่ใกล้กับเป้าหมายของการพยากรณ์เฟรมถัดไป จะได้รับคอนเท็กซ์ที่ยาวกว่า
  • ความซับซ้อนในการคำนวณแบบสตรีมมิงเป็น O(1) ไม่ใช่ O(nlogn) หรือ O(n)

การจัดตารางและการป้องกันดริฟต์

  • FramePack Scheduling รองรับกรณีที่ความสำคัญของเฟรมไม่ได้เป็นไปตามรูปแบบง่าย ๆ, ต้องการเปลี่ยนอัตราการบีบอัด, หรือผู้ใช้ต้องการกำหนดให้บางเฟรมสำคัญมากขึ้น
  • ใน image-to-video เฟรมแรกมีความสำคัญ จึงสามารถใช้การจัดตารางที่ทำให้เฟรมเริ่มต้นมีความสำคัญเท่ากันได้
  • การจัดตารางทั้งหมดเป็น O(1) และการประเมินการจัดตารางหลายแบบรวมอยู่ใน Paper
  • ในโมเดล Next-Frame Prediction ปัญหา drifting ที่คุณภาพลดลงเมื่อวิดีโอยาวขึ้นเป็นเรื่องที่พบได้ทั่วไป
    • หากนำเฟรมที่สร้างล่าสุดกลับมาใส่ซ้ำเพื่อสร้างวิดีโอยาว ภาพจะเริ่มพังอย่างรวดเร็วหลัง 5~6 รอบ และอาจเสื่อมหนักหลังราว 10 รอบ
    • ปัญหานี้เรียกอีกอย่างว่า error accumulation หรือ exposure bias
  • การทดลองเกี่ยวกับวิธีเดิมอย่าง history noise augmentation, special cfg guidance, rolling diffusion timesteps ก็รวมอยู่ในงานวิจัยนี้เช่นกัน
  • หากต้องการจัดการ drifting ที่ต้นตอ จำเป็นต้องทำลาย causality และเปลี่ยนการสุ่มตัวอย่างให้เป็นแบบ สองทิศทาง
    • vanilla sampling เท่านั้นที่เป็นแบบ causal
    • anti-drifting sampling และ inverted anti-drifting sampling เป็นวิธีแบบสองทิศทาง
    • inverted anti-drifting sampling ปฏิบัติต่อเฟรมแรกเป็นเป้าหมายเชิงประมาณในทุกการอนุมาน และเหมาะกับ image-to-video

เงื่อนไขเดโมและแหล่งอ้างอิง

  • ผลเดโมคำนวณจาก RTX 3060 6GB โน้ตบุ๊กและ HY variant ขนาด 13B
    • image-to-5-seconds: 30fps, 150 เฟรม
    • image-to-60-seconds: 30fps, 1800 เฟรม
    • วิดีโอถูกบีบอัดด้วย h264crf18 เพื่อให้ตรงกับที่เก็บ GitHub
  • มีเอกสารที่เกี่ยวข้อง ได้แก่ Paper, Code, FramePack-P1 Preview

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-21
ความคิดเห็นจาก Hacker News

  • คนคนนี้เป็นอัจฉริยะจริง ๆ บางคนอาจไม่รู้ แต่ ControlNet ก็เป็นผลงานของเขาเช่นกัน
    เรื่องนี้สำคัญมาก เพราะเป็น โมเดลสร้างวิดีโอ ตัวแรกที่ใช้งานได้จริงบนฮาร์ดแวร์ระดับผู้บริโภค และคาดว่าเร็ว ๆ นี้จะรองรับท่าทางแบบ ControlNet ด้วย

    • IC-Light ก็เป็นผลงานของเขาเหมือนกัน สงสัยว่าทำไมเขายังมีส่วนร่วมกับโอเพนซอร์สอยู่
      บริษัทใหญ่ ๆ น่าจะยื่นข้อเสนอมหาศาลให้แล้ว เขามีพรสวรรค์โดดเด่นจริง ๆ
    • ผมใจร้อนกับงานสร้างวิดีโอเลยยังไม่ได้ลองจริงจัง แต่ Wan ก็ถือว่าใช้ได้ค่อนข้างดีบนฮาร์ดแวร์ทั่วไปไม่ใช่หรือ?

  • ตลกตรงที่ดูเหมือนจะพยายามทำให้คนเต้นให้ได้ แม้แต่คนที่นั่งรอสัมภาษณ์ก็เริ่มเต้นทั้งที่ยังนั่งอยู่

    • น่าจะเพราะมีคำว่าเต้นอยู่ในพรอมป์ ถ้าเปลี่ยนพรอมป์ก็คงสั่งให้ทำอย่างอื่นได้ แต่คงไม่สนุกเท่า
    • ดูเหมือนเป็นอิทธิพลจาก ชุดข้อมูลฝึก TikTok สาธารณะขนาดใหญ่ที่นักวิจัยวิดีโอจำนวนมากใช้
    • เป็นข้อสังเกตที่น่าสนใจ
      ในภาพนิ่ง เรามักมองหา ดวงตา เสมอ ส่วนในวิดีโอ เรามักมองหา การเต้น เสมอ

  • ตัวอย่างค่อนข้างน่าประทับใจ แต่ทรัพยากรที่ใช้สร้างจริง ๆ แทบจะไม่มากเลย ดูเหมือนรัน inference ได้แม้บน ฮาร์ดแวร์ผู้บริโภครุ่นก่อนหน้า
    สักวันหนึ่งอยากเห็นตัวเลข throughput ของ inference บน 5090 ด้วย

  • ทำแบบนี้ในทิศทางเชิงพื้นที่ได้ไหม? เช่น ไม่สร้างภาพทั้งภาพในครั้งเดียว แต่สร้างแบบ จากบนลงล่าง ได้หรือเปล่า

  • เอาสิ่งนี้ไปใช้กับ การแทรกเฟรมวิดีโอ แทนการ extrapolation ได้ไหม?

    • สิ่งที่บทความเรียกว่า “inverted anti-drifting” โดยพื้นฐานแล้วใกล้เคียงกับการ extrapolate ไปไกล ๆ ก่อน แล้วค่อยทำ interpolation ย้อนกลับ

  • น่าทึ่งมาก ถ้ามีทรัพยากรอย่าง RAM มากขึ้น จะทำให้เร็วขึ้นได้ไหม? สงสัยด้วยว่าจะดันความเร็วได้มากกว่านี้บน H100 หรือ H200 หรือไม่

  • ดูเหมือนว่าการเคลื่อนไหวที่ทำได้จริง ๆ แทบจะมีแค่ การเต้น เท่านั้น

    • มีการเคลื่อนไหวที่ไม่ใช่การเต้นอยู่พอสมควร ตัวอย่างที่ท่าเท้าไม่ใช่การเต้นมีแค่หนึ่งหรือสองอัน แต่สิ่งที่ขยับก็ไม่ได้มีแค่เท้า
    • เพราะรับ พรอมป์ข้อความ ควบคู่กับภาพอินพุตด้วย จึงมีความเป็นไปได้สูงว่าตัวอย่างใส่การเต้นไว้ในพรอมป์