Відео з аватаром зі ШІ виглядає переконливо лише тоді, коли людина залишається послідовною з часом. Якщо обличчя «пливе», змінюються зуби, порушується lip-sync або рухи скидаються між кліпами, люди одразу це помічають. Для аватарів це особливо важливо, ніж для багатьох інших завдань зі створення відео, адже глядач спостерігає за конкретною людиною, яка говорить, часто зблизька і протягом тривалого часу.

У сучасному світі створення відео зі ШІ тривалість усе ще залишається одним із найпомітніших обмежень. Багато моделей і продуктів пропонують створення як кліп фіксованої довжини — кілька секунд, і лише небагато систем здатні створювати відео довше, ніж на кілька хвилин. Для продуктів з аватарами це обмеження безпосередньо впливає на робочі процеси клієнтів. Клієнтам потрібні довші, послідовні сцени/відео для навчальних матеріалів, демонстрацій продажів, оглядів продукту, освіти, підтримки та агентів, які мають говорити доти, доки завдання не буде виконано, а також їм потрібний швидкий попередній перегляд, щоб швидко змінювати промпти, рух і сценарій.

У HeyGen це перетворилося на три конкретні вимоги:

1. Послідовність у довгих сценахАватар має зберігати цілісність особистості, lip-sync, міміку та безперервність рухів не лише в одному короткому фрагменті, а й у багатьох частинах створеного відео.
2. Без фіксованого обмеження тривалостіСтворення може тривати десять секунд, десять хвилин або бути безперервною сеансом у режимі реального часу.
3. Швидкий попередній перегляд, робота в режимі реального часу або швидше за реальний часСистема має швидко починати створювати кадри й навіть дозволяти транслювати назовні створювані кадри, поки обчислення ще тривають.

У цій публікації ми розглянемо фреймворк для інференсу, який створили, щоб задовольнити ці вимоги.

Базова архітектура моделі

Фреймворк побудований навколо моделей створення аватар-відео HeyGen — лінійок Avatar IV та Avatar V. На високому рівні модель бере референтне зображення або відео, керівну аудіодоріжку та додатковий текстовий чи сценічний контекст, а потім створює відео цього аватара, який говорить із правильною ідентичністю, мімікою та рухами.

Основна модель створення — це Diffusion Transformer, або DiT, навчена з використанням flow matching. Замість того щоб стискати людину в невелике вбудовування ідентичності, модель працює з багатими референсними токенами, щоб зберегти деталі, важливі для аватарів: форму обличчя, зуби, текстуру шкіри, рухи рота, стиль жестів і ритм мовлення.

Робочий процес продакшн-інференсу має три основні етапи:

1. Створення відео з аудіо Базова модель DiT створює низькороздільні латентні представлення відео на основі еталонної особи, аудіофіч і керувальних сигналів. На цьому етапі основна увага приділяється руху, lip-sync та часовій узгодженості.
2. Суперроздільна здатність з урахуванням ідентичності. Другий модуль уточнює ці латентні представлення до зображення з високою роздільною здатністю, приділяючи особливу увагу ділянкам, де люди найбільше помічають артефакти, зокрема обличчю та роту.
3. Потокове декодування VAE. Декодер VAE перетворює високоякісні латентні представлення на RGB-кадри частинами, тож кадри можна виводити ще до завершення всього відео.

Щоб створювати довгі відео, система обробляє дані частинами. Поки перша частина повністю спирається на статичний референс, наступні частини використовують граничні дані з попередніх сегментів. Це дає змогу аватару продовжувати говорити природно, без повного скидання пози чи ідентичності.

Стрімінговий фреймворк і цикл конвеєра

Щоб забезпечити виконання на основі фрагментів, інференс-фреймворк використовує модульну трирівневу архітектуру, яка працює з локалізованими часовими вікнами та звільняє ресурси одразу після обробки кожного фрагмента.

• Модуль: обгортка навколо конкретної моделі та її контрольної точки (наприклад, A2V DiT, Super-Resolution DiT, компоненти VAE, текстові/аудіо енкодери).
• Етап: типізований блок виконання, який координує один або кілька модулів (наприклад, створення контексту, суперроздільна здатність).
• Конвеєр: граф виконання, який поєднує етапи між собою, керує спільним станом і координує режими потокового або пакетного виконання.

Етап ініціалізації один раз на запит кодує еталонну особу в латентні представлення. Потім pipeline безперервно проходить по решті етапів, доки вхідний аудіопотік не буде вичерпано:

• Створення контексту: перетворює вхідні аудіосегменти на ознаки, поєднує їх із текстовою або сценічною умовою та готує цільові тензори шуму.
• Перетворення аудіо у відео: Виконує багатокроковий дифузійний прохід для створення латентних представлень низької роздільної здатності. На цьому етапі поточний фрагмент узгоджується з граничними кадрами попереднього фрагмента, щоб зберегти безперервність руху.
• Суперроздільна здатність: Масштабує латенти руху до повної роздільної здатності за один крок, приділяючи пріоритетну увагу просторовим деталям обличчя.
• VAE Decode-and-Publish: декодує високоякісні латентні представлення в RGB-кадри та записує їх безпосередньо в вихідний енкодер (H.264 / AAC) для негайного збереження або живого відтворення.

Неперервність меж і узгодженість фрагментів

Створення відео окремими сегментами може призводити до потенційних розривів на межах. Фреймворк зменшує цей ризик, використовуючи два різні типи класифікації фрагментів:

• N-фрагменти: сегменти, які створюють основну часову шкалу аватара.
• I Chunks (інтерполяція): сегменти, призначені для згладжування переходів між послідовними N chunks.

Послідовність виконання має таку структуру:

N0 -> N1 -> I0 -> N2 -> I1 -> N3 -> I2 -> ...

Фрагмент I створюється лише після того, як будуть завершені попередній і наступний фрагменти N. Він використовує фінальний кадр попереднього фрагмента N та ранній кадр поточного фрагмента N як опорні кадри для обчислення перехідного руху. Після створення зайві опорні передбачення відкидаються, і залишається лише плавно інтерпольований перехід. Цей механізм обмежує потрібне вікно контексту, зберігаючи водночас часову узгодженість.

Постійний обсяг пам'яті протягом усього періоду

Звичайний відеопроцес накопичує латентні представлення, декодовані кадри та контекст уваги під час виконання, через що споживання пам'яті GPU зростає лінійно зі збільшенням тривалості відео.

Щоб забезпечити відкриту, необмежену в часі генерацію, ця фреймворк-архітектура підтримує суворий ковзний стан. Система зберігає лише статичні референсні умови та мінімальний набір опорних тензорів, необхідних для переходів між чанками. Усі проміжні артефакти — зокрема аудіофічі, тензори шуму, внутрішні активації та сирі RGB-кадри — негайно очищаються з пам’яті одразу після того, як відповідний чанк декодовано й записано.

У результаті піковий профіль використання пам’яті GPU залишається сталим незалежно від того, чи створюєте Ви короткий кліп, чи довгу послідовність; використання ресурсів масштабується відповідно до заданого розміру фрагмента, а не загальної тривалості сесії.

Етапи завантаження та вивантаження в межах конвеєра

Кожен запит виконується на вузлі з 8 GPU. Ми використовуємо FSDP, щоб розподіляти параметри великої моделі між GPU. Кожен ранг володіє лише частиною ваг, збирає параметри, потрібні йому для обчислення, а потім знову звільняє їх. Саме це дає змогу розмістити на одному вузлі кілька великих моделей — базову DiT, DiT для суперроздільності, текстовий енкодер, аудіоенкодер і VAE.

Є певний компроміс. FSDP створює додаткові витрати на обмін даними під час інференсу, оскільки параметри потрібно збирати під час прямого проходу. Ми використовуємо поєднання різних технік, щоб приховати ці витрати та тримати розміщені разом моделі поза GPU, коли вони не використовуються:

• Попереднє вибіркове завантаження (forward prefetching)Операція AllGather для параметрів наступного блоку запускається завчасно й виконується паралельно з обчисленнями поточного блоку, приховуючи затримку збирання на критичному шляху.
• Ліниве розшардування кожного блоку з CPU. Коли модель повертається з закріпленої в пам’яті CPU, ми не завантажуємо наперед увесь набір ваг. Кожен трансформерний блок розшардується (копіювання з хоста на пристрій + AllGather) безпосередньо перед своїм прямим проходом, тож передавання H2D для блоку n+1 перекривається з обчисленням блоку n.
• Закріплене вивантаження на CPU між етапами. Параметри моделі, яка зараз не виконується, зберігаються в закріпленій пам’яті CPU, тож розміщені на одному вузлі моделі (базова DiT, DiT для суперроздільності, текстовий енкодер, аудіоенкодер, VAE) не мусять одночасно тримати свої ваги в пам’яті GPU. Саме закріплена пам’ять робить копіювання H2D достатньо швидким, щоб його можна було перекривати з обчисленнями.
• Розміщення процесів з урахуванням NUMA. Кожен процес закріплено за тим самим NUMA-вузлом, що й призначений йому GPU, тож передавання даних між CPU↔GPU відбувається на повній швидкості шини PCIe/NVLink без перетину міжсокетного інтерконекту.

Перемикання моделей між етапами менш ніж за 10 мс

Практична вигода описаних вище підходів полягає в тому, що передавання GPU від моделі одного етапу до наступного — наприклад, A2V DiT → Super-Resolution DiT або SR DiT → VAE decoder — фактично нічого не «коштує». Оскільки вихідна модель вивантажується асинхронно, а перший блок вхідної моделі розшардується just-in-time, і копіювання H2D, і AllGather повністю приховані за обчисленнями, які вже виконуються. У підсумку спостережувані накладні витрати на одне перемикання становлять менше 10 мс — значно менше бюджету одного кадру за наших цільових частот кадрів. По суті, саме це дає змогу стримінговому конвеєру (Context Gen → A2V → SR → VAE Decode-and-Publish) проходити через кілька великих моделей на один чанк, не перетворюючи саме перемикання моделей на «вузьке місце».

Публікація потокового відео в реальному часі

Щоб зробити модель достатньо швидкою для потокової роботи в режимі реального часу, ми виконали багато оптимізацій інференсу, докладніше дивіться на https://www.heygen.com/research/avatar-v-inference для отримання додаткової інформації щодо цієї частини.

Коли конвеєр у режимі реального часу видає відео фрагмент за фрагментом, потокова доставка стає природним продовженням етапу інференсу, а не окремим кроком післяобробки.

Для трансляційного режиму роботи в реальному часі ми надсилаємо створені кадри до Amazon Kinesis Video Streams (KVS). KVS зазвичай розглядають у контексті камер, IoT-пристроїв та завантажених медіафайлів. У нашому випадку «камерою» є сама інференс-пайплайн: кадри створюються моделлю, одразу кодуються й надсилаються до KVS як живий стрім.

Модуль запису вихідних даних отримує декодовані RGB-кадри зі streaming VAE та надсилає їх у конвеєр GStreamer. Відео кодується у формат H.264, а аудіо — у формат AAC, після чого обидві доріжки передаються в kvssink, вихідний sink-продюсер KVS. Звідти глядачі можуть відтворювати сесію як пряму трансляцію ще під час її створення.

Результати та висновки

Фреймворк змінив створення Avatar IV та Avatar V із рендерингу фіксованих сцен на відкриту потокову генерацію. Найважливіший результат простий: ми прибрали обмеження тривалості сцени для Avatar IV та Avatar V. Для створення Avatar IV у режимі реального часу нам вдалося досягти часу до першого кадру менш ніж 5 секунд і швидкості створення понад 27 кадрів на секунду для 720p відео Avatar IV — швидше, ніж відтворення в реальному часі.