วิดีโออวตารจะดูน่าเชื่อถือได้ก็ต่อเมื่อบุคคลในวิดีโอดูสม่ำเสมอต่อเนื่องกันไปเรื่อยๆ เมื่อใบหน้าเคลื่อนหลุดเฟรม ฟันเปลี่ยนไป ลิปซิงก์คลาดเคลื่อน หรือท่าทางรีเซ็ตใหม่ระหว่างคลิป ผู้ชมจะสังเกตเห็นได้ทันที เรื่องนี้สำคัญกับอวตารมากกว่างานสร้างวิดีโอแบบอื่นๆ เพราะผู้ชมกำลังดูคนคนหนึ่งพูดอยู่ต่อหน้า มุมใกล้ และเป็นเวลานาน
ในโลกของการสร้างวิดีโอด้วย AI ในปัจจุบัน ระยะเวลายังคงเป็นหนึ่งในข้อจำกัดที่มองเห็นได้ชัดที่สุด โมเดลและผลิตภัณฑ์จำนวนมากเปิดให้สร้างวิดีโอเป็นคลิปความยาวคงที่เพียงไม่กี่วินาที และมีเพียงไม่กี่ระบบที่สร้างวิดีโอได้นานเกินกว่าสองสามนาที สำหรับผลิตภัณฑ์อวตาร ข้อจำกัดนี้ส่งผลโดยตรงต่อเวิร์กโฟลว์ของลูกค้า ลูกค้าต้องการฉากหรือวิดีโอที่ยาวและมีความสม่ำเสมอมากขึ้นสำหรับวิดีโอเทรนนิง เดโมการขาย วิดีโอสาธิตการใช้งาน การศึกษา ซัพพอร์ต และเอเจนต์ที่ควรพูดต่อเนื่องจนกว่างานจะเสร็จ และยังต้องการพรีวิวที่รวดเร็วเพื่อใช้ไอเทอเรตพรอมต์ ท่าทางการเคลื่อนไหว และสคริปต์
สำหรับ HeyGen ข้อจำกัดเหล่านี้ถูกแปลงมาเป็น 3 ความต้องการที่ชัดเจนดังนี้:
- ความสม่ำเสมอในฉากยาวอวตารต้องคงเอกลักษณ์ การลิปซิงก์ สีหน้า และความต่อเนื่องของการเคลื่อนไหวไว้ให้ได้ไม่ใช่แค่ในคลิปสั้นๆ คลิปเดียว แต่ต้องทำได้ตลอดหลายส่วนของวิดีโอที่สร้างจาก AI
- ไม่มีการจำกัดระยะเวลาแบบตายตัวการสร้างหนึ่งครั้งอาจใช้เวลา 10 วินาที 10 นาที หรือเป็นเซสชันแบบเรียลไทม์ที่ไม่จำกัดเวลา
- พรีวิวรวดเร็ว สร้างแบบเรียลไทม์หรือเร็วกว่าระหว่างรันระบบควรเริ่มสร้างเฟรมได้อย่างรวดเร็วและยังสามารถสตรีมเฟรมที่สร้างออกไปได้ในขณะที่การอินเฟอเรนซ์ยังดำเนินอยู่
โพสต์นี้อธิบายกรอบการทำงานของการอนุมานที่เราสร้างขึ้นเพื่อตอบโจทย์ความต้องการเหล่านั้น
สถาปัตยกรรมโมเดลเบื้องหลัง
เฟรมเวิร์กนี้ถูกพัฒนาขึ้นบนโมเดลสร้างวิดีโออวตารของ HeyGen ได้แก่ตระกูล Avatar IV และ Avatar V โดยในภาพรวมโมเดลจะรับภาพหรือวิดีโออ้างอิง เสียงพูดนำ และตัวเลือกข้อความหรือเงื่อนไขของฉาก จากนั้นสร้างวิดีโอของอวตารตัวนั้นที่พูดด้วยเอกลักษณ์ สีหน้า และการเคลื่อนไหวที่ถูกต้อง
โมเดลการสร้างหลักคือ Diffusion Transformer หรือ DiT ที่ผ่านการเทรนด้วยเทคนิค flow matching แทนที่จะบีบอัดบุคคลให้เหลือเป็น identity embedding ขนาดเล็ก โมเดลจะอ้างอิงจาก reference token ที่มีข้อมูลละเอียดเพื่อรักษารายละเอียดสำคัญสำหรับอวตาร เช่น รูปหน้า ฟัน เนื้อผิว การขยับปาก สไตล์ท่าทาง และจังหวะการพูด
เส้นทางการอนุมานในขั้นตอนการผลิตแบ่งออกเป็น 3 ขั้นตอนหลัก:
- การสร้างวิดีโอจากเสียงโมเดล DiT พื้นฐานจะสร้าง latent วิดีโอความละเอียดต่ำจากตัวตนอ้างอิง คุณลักษณะเสียง และสัญญาณกำกับ ขั้นตอนนี้เน้นการเคลื่อนไหว การลิปซิงก์ และความต่อเนื่องของภาพตามเวลา
- ซูเปอร์เรโซลูชันที่เข้าใจเอกลักษณ์บุคคล โมเดลตัวที่สองจะปรับแต่งลาเทนต์เหล่านั้นให้เป็นผลลัพธ์ความละเอียดสูง โดยให้ความสำคัญเป็นพิเศษกับบริเวณที่ผู้ใช้มักสังเกตเห็นความผิดปกติมากที่สุด โดยเฉพาะใบหน้าและปาก
- การถอดรหัสแบบสตรีมมิงด้วย VAEตัวถอดรหัส VAE จะแปลงข้อมูลแฝงความละเอียดสูงให้เป็นเฟรม RGB แบบแบ่งเป็นชิ้นย่อย ทำให้สามารถส่งออกเฟรมได้ก่อนที่วิดีโอทั้งคลิปจะสร้างเสร็จสมบูรณ์
เพื่อสร้างวิดีโอแบบยาว ระบบจะประมวลผลข้อมูลเป็นชุดย่อย โดยชุดแรกจะอ้างอิงจากภาพอ้างอิงแบบคงที่ทั้งหมด ส่วนชุดถัดไปจะใช้ข้อมูลขอบเขตจากเซกเมนต์ก่อนหน้า ทำให้อวตารสามารถพูดต่อเนื่องได้อย่างเป็นธรรมชาติโดยไม่ต้องเริ่มท่าทางหรือเอกลักษณ์ใหม่ตั้งแต่ต้น
เฟรมเวิร์กการสตรีมและวงรอบ Pipeline
เพื่อรองรับการประมวลผลแบบแบ่งเป็นชิ้น เฟรมเวิร์กสำหรับการอนุมานใช้สถาปัตยกรรมแบบโมดูลาร์สามชั้นที่ทำงานบนช่วงเวลาย่อยในแต่ละส่วน และคืนทรัพยากรทันทีหลังจากประมวลผลแต่ละชิ้นเสร็จ
- โมดูล: ตัวห่อหุ้มรอบโมเดลเฉพาะและเช็คพอยต์ของโมเดลนั้น (เช่น A2V DiT, Super-Resolution DiT, ส่วนประกอบ VAE, ตัวเข้ารหัสข้อความ/เสียง)
- สเตจ: หน่วยประมวลผลแบบกำหนดประเภทที่ใช้ประสานงานโมดูลหนึ่งตัวหรือหลายตัว (เช่น การสร้างคอนเท็กซ์ การซูเปอร์เรโซลูชัน)
- Pipeline: กราฟการทำงานที่เชื่อมต่อสเตจต่างๆ เข้าด้วยกัน จัดการสถานะที่ใช้ร่วมกัน และประสานการทำงานแบบสตรีมมิงหรือแบบแบตช์
ขั้นตอนเริ่มต้นจะเข้ารหัสอัตลักษณ์อ้างอิงเป็นค่าแฝงหนึ่งครั้งต่อคำขอ จากนั้น pipeline จะรันลูปต่อเนื่องผ่านสเตจที่เหลือจนกว่าสตรีมเสียงขาเข้าจะสิ้นสุดลง:
- การสร้างคอนเท็กซ์: แปลงเซกเมนต์เสียงที่รับเข้ามาให้เป็นฟีเจอร์ ผสานกับข้อความหรือเงื่อนไขของฉาก และเตรียมเทนเซอร์สัญญาณรบกวนเป้าหมาย
- Audio-to-Video: ทำการดิฟฟิวชันหลายขั้นตอนเพื่อสร้างลาเทนต์ความละเอียดต่ำ ขั้นตอนนี้จะกำหนดเงื่อนไขของชังก์ปัจจุบันด้วยเฟรมขอบเขตของชังก์ก่อนหน้าเพื่อรักษาความต่อเนื่องของการเคลื่อนไหว
- ซูเปอร์เรโซลูชัน: ขยายความละเอียดของเลเทนต์การเคลื่อนไหวให้เป็นความละเอียดเต็มในขั้นตอนเดียว โดยให้ความสำคัญกับรายละเอียดเชิงพื้นที่บนใบหน้า
- VAE Decode-and-Publish: ถอดรหัสลาเทนต์ความละเอียดสูงเป็นเฟรม RGB และเขียนส่งตรงไปยังตัวเข้ารหัสเอาต์พุต (H.264 / AAC) เพื่อบันทึกเก็บทันทีหรือเล่นแบบสด
ความต่อเนื่องของขอบเขตและความสม่ำเสมอของชังก์
การสร้างวิดีโอเป็นเซกเมนต์แยกกันอาจทำให้เกิดความไม่ต่อเนื่องที่ขอบเขตของแต่ละส่วนได้ เฟรมเวิร์กนี้ลดปัญหาดังกล่าวด้วยการใช้การจัดประเภทชังก์ 2 รูปแบบที่แตกต่างกัน:
- N Chunks: ส่วนที่ใช้สร้างไทม์ไลน์หลักของอวตาร
- I Chunks (Interpolation): เซกเมนต์ที่ออกแบบมาเพื่อทำให้การเปลี่ยนผ่านระหว่าง N chunks ที่ต่อเนื่องกันลื่นไหลขึ้น
ลำดับการทำงานมีโครงสร้างดังนี้:
N0 -> N1 -> I0 -> N2 -> I1 -> N3 -> I2 -> ...
ส่วน I จะถูกสร้างขึ้นก็ต่อเมื่อส่วน N ก่อนหน้าและหลังจากมันเสร็จสมบูรณ์แล้วเท่านั้น โดยใช้เฟรมสุดท้ายของส่วน N ก่อนหน้าและเฟรมต้นของส่วน N ปัจจุบันเป็นเฟรมยึดเพื่อคำนวณการเคลื่อนไหวช่วงเปลี่ยน ระหว่างการสร้างจะทิ้งการทำนายเฟรมยึดที่ซ้ำซ้อนออกไป เหลือไว้เฉพาะการเปลี่ยนผ่านที่ถูกอินเทอร์โพเลตให้ลื่นไหล กลไกนี้ช่วยจำกัดขนาดหน้าต่างบริบทที่ต้องใช้พร้อมทั้งยังคงความต่อเนื่องของเวลาไว้
หน่วยความจำคงที่ตลอดระยะเวลา
พายป์ไลน์วิดีโอแบบดั้งเดิมจะสะสมค่า latent เฟรมที่ถอดรหัสแล้ว และบริบทของ attention ระหว่างการประมวลผล ทำให้การใช้หน่วยความจำ GPU เพิ่มขึ้นตามความยาวของวิดีโอแบบเชิงเส้น
เพื่อรองรับการสร้างวิดีโอแบบต่อเนื่องไม่จำกัด เฟรมเวิร์กนี้จะคงสถานะการประมวลผลแบบโรลลิงที่เข้มงวดไว้ โดยระบบจะเก็บเฉพาะเงื่อนไขอ้างอิงแบบคงที่และชุดเทนเซอร์สมอขั้นต่ำที่จำเป็นสำหรับการเปลี่ยนผ่านระหว่างชังก์เท่านั้น ทรัพยากรตัวกลางทั้งหมด เช่น คุณลักษณะเสียง เทนเซอร์ของสัญญาณรบกวน แอ็กทิเวชันภายใน และเฟรมภาพ RGB ดิบ จะถูกลบออกจากหน่วยความจำทันทีหลังจากชังก์นั้นถูกถอดรหัสและเขียนเสร็จ
ผลลัพธ์คือโปรไฟล์การใช้หน่วยความจำสูงสุดของ GPU ยังคงที่ไม่ว่าจะสร้างคลิปสั้นหรือวิดีโอลำดับยาว การใช้ทรัพยากรจะปรับตามขนาดชังก์ที่กำหนดแทนที่จะขึ้นกับระยะเวลารวมของเซสชัน
ขั้นตอนการโหลด/ถ่ายโอนภายในไปป์ไลน์
แต่ละคำขอจะรันบนโหนดที่มี 8 GPU เราใช้ FSDP เพื่อแบ่งพารามิเตอร์ของโมเดลขนาดใหญ่กระจายไปบน GPU แต่ละตัว แต่ละ rank จะถือครองเฉพาะส่วนหนึ่งของ weight ดึงพารามิเตอร์ที่ต้องใช้สำหรับการคำนวณแล้วจึงคืนหน่วยความจำให้ว่างอีกครั้ง วิธีนี้ทำให้สามารถวางโมเดลขนาดใหญ่หลายตัว ได้แก่ base DiT, super-resolution DiT, text encoder, audio encoder และ VAE ไว้บนโหนดเดียวได้
มีข้อแลกเปลี่ยนที่ต้องยอมรับ FSDP ทำให้เกิดโอเวอร์เฮดด้านการสื่อสารระหว่างการรันอินเฟอเรนซ์เพราะต้องรวบรวมพารามิเตอร์ระหว่างการทำ forward pass เราใช้เทคนิคหลายอย่างร่วมกันเพื่อลดโอเวอร์เฮดนี้และย้ายโมเดลที่รันร่วมกันออกจาก GPU เมื่อไม่ได้ใช้งาน:
- การดึงล่วงหน้าแบบ Forwardคำสั่ง AllGather สำหรับพารามิเตอร์ของบล็อกถัดไปจะถูกเรียกใช้ล่วงหน้าและประมวลผลซ้อนทับไปกับการคำนวณของบล็อกปัจจุบัน เพื่อลดระยะเวลาหน่วงของการดึงข้อมูลบนเส้นทางวิกฤต
- การยกเลิกการแบ่งชาร์ดแบบรายบล็อกจาก CPU แบบ Lazyเมื่อโมเดลถูกโหลดกลับมาจาก pinned CPU memory เราจะไม่ย้ายชุด weights ทั้งหมดขึ้นมาบนดีไวซ์ล่วงหน้า แต่ละ transformer block จะถูก unshard (คัดลอกจาก host ไปยัง device + ทำ AllGather) ทันทีที่ก่อนเริ่มทำ forward pass ทำให้การโอนข้อมูล H2D ของบล็อก n+1 ซ้อนทับไปกับการคำนวณของบล็อก n
- การออฟโหลดจาก CPU แบบ pinned ระหว่างสเตจ พารามิเตอร์ของโมเดลที่ไม่ได้รันอยู่จะถูกเก็บไว้ในหน่วยความจำ CPU แบบ pinned ทำให้โมเดลที่รันอยู่บนเครื่องเดียวกัน (base DiT, super-resolution DiT, text encoder, audio encoder, VAE) ไม่จำเป็นต้องเก็บ weights ไว้บน GPU พร้อมกันทั้งหมด หน่วยความจำแบบ pinned ทำให้การคัดลอกข้อมูลแบบ H2D เร็วพอที่จะซ้อนทับไปกับการคำนวณได้
- การจัดวางโปรเซสให้สอดคล้องกับ NUMAแต่ละโปรเซสจะถูกผูกไว้กับ NUMA node เดียวกับ GPU ที่ได้รับมอบหมาย ทำให้การถ่ายโอนข้อมูลระหว่าง CPU↔GPU ทำงานได้เต็มแบนด์วิดท์ของ PCIe/NVLink โดยไม่ต้องวิ่งข้าม inter-socket interconnect
สลับโมเดลระหว่างสเตจได้ในเวลาไม่ถึง 10 มิลลิวินาที
ผลลัพธ์เชิงปฏิบัติของเทคนิคข้างต้นคือการส่งต่อ GPU จากโมเดลในแต่ละสเตจไปยังสเตจถัดไป เช่น A2V DiT → Super-Resolution DiT หรือ SR DiT → VAE decoder แทบไม่มีต้นทุนเพิ่มเลย เนื่องจากโมเดลที่ใช้งานเสร็จแล้วจะถูก offload แบบ asynchronous และบล็อกแรกของโมเดลถัดไปจะถูก unshard แบบ just-in-time การคัดลอก H2D และ AllGather จึงถูกซ่อนอยู่หลังงานคำนวณที่กำลังรันอยู่แล้ว เมื่อมองแบบ end-to-end ค่า overhead ต่อการสลับหนึ่งครั้งที่สังเกตได้จะต่ำกว่า 10ms ซึ่งต่ำกว่าบัดเจ็ตต่อเฟรมที่เฟรมเรตเป้าหมายของเราอย่างมาก ในทางปฏิบัติ นี่คือสิ่งที่ทำให้สตรีมมิง pipeline loop (Context Gen → A2V → SR → VAE Decode-and-Publish) สามารถวนผ่านโมเดลขนาดใหญ่หลายตัวต่อหนึ่งชังก์ได้ โดยที่การสลับโมเดลเองไม่กลายเป็นคอขวด
การเผยแพร่แบบสตรีมมิงเรียลไทม์
เพื่อให้โมเดลสามารถสตรีมแบบเรียลไทม์ได้อย่างรวดเร็ว เราได้ปรับแต่งการทำอินเฟอเรนซ์อย่างมาก โปรดดูที่ https://www.heygen.com/research/avatar-v-inference สำหรับรายละเอียดเพิ่มเติมในส่วนนี้
เมื่อ pipeline ส่งออกวิดีโอเป็นชิ้นย่อยแบบเรียลไทม์ การสตรีมจึงกลายเป็นส่วนขยายตามธรรมชาติของขั้นตอน inference แทนที่จะเป็นขั้นตอน post-processing แยกต่างหาก
สำหรับเส้นทางการประมวลผลแบบเรียลไทม์ในลักษณะออกอากาศ เราจะส่งเฟรมที่สร้างขึ้นไปยัง Amazon Kinesis Video Streams (KVS) โดยตรง KVS มักถูกพูดถึงในบริบทของกล้อง อุปกรณ์ IoT และสื่อที่อัปโหลดไว้ล่วงหน้า แต่ในกรณีของเรา "กล้อง" คืออินเฟอเรนซ์ไพป์ไลน์เอง เฟรมถูกสร้างโดยโมเดล เข้ารหัสทันที แล้วส่งเข้า KVS เป็นสตรีมสด
ตัวเขียนผลลัพธ์จะรับเฟรม RGB ที่ถอดรหัสแล้วจากสตรีมมิง VAE และส่งต่อเข้าไปยัง GStreamer pipeline วิดีโอจะถูกเข้ารหัสเป็น H.264 และเสียงเป็น AAC จากนั้นทั้งสองแทร็กจะถูกส่งไปยัง kvssink ซึ่งเป็น KVS producer sink จากจุดนั้นผู้ชมสามารถเล่นเซสชันกลับแบบสตรีมสดได้ในขณะที่วิดีโอยังถูกสร้างอยู่
ผลลัพธ์และสิ่งที่ได้เรียนรู้
เฟรมเวิร์กนี้เปลี่ยนการสร้าง Avatar IV และ Avatar V จากการเรนเดอร์ฉากแบบตายตัวมาเป็นการสร้างแบบสตรีมมิงต่อเนื่องแบบเปิด ทำให้ได้ผลลัพธ์สำคัญอย่างหนึ่งที่ชัดเจนคือ เราสามารถลบข้อจำกัดระยะเวลาฉากสำหรับ Avatar IV และ Avatar V ได้ สำหรับการสร้าง Avatar IV แบบเรียลไทม์ เราทำเวลาเฟรมแรกได้ต่ำกว่า 5 วินาที และสร้างได้มากกว่า 27 เฟรมต่อวินาทีสำหรับวิดีโอ Avatar IV ความละเอียด 720p ซึ่งเร็วกว่าการเล่นวิดีโอแบบเรียลไทม์