#1155 Добавить поддержку моделей генерации видео

Discussion #1155

Добавить поддержку моделей генерации видео

Оригинал: Add support for video generation models

Мотивация

Модели создания видео с открытым весом значительно улучшились за последние несколько лет и достигли уровня качества, который делает их пригодными для реальных рабочих процессов производства видео. Добавление поддержки этих моделей в сеть Gonka может снизить производственные затраты. Кроме того, это откроет путь к поддержке других методов в будущем.

Предлагаю начать с поддержки моделей преобразования текста в видео, как наиболее общего случая. Точнее, с моделью Wan2.2-T2V-A14B, потому что на сегодняшний день это лучшая модель преобразования текста в видео с открытым исходным кодом, имеющая разрешительную лицензию (Apache 2.0). LTX-2.3 сопоставим с точки зрения производительности, но имеет гораздо более ограничительную пользовательскую лицензию, которая на этом этапе может создать дополнительные ненужные препятствия.

Проблемы

Давайте сначала обрисуем проблемы, с которыми мы сталкиваемся из-за архитектурных различий между моделями генерации видео и LLM.

Проверка вывода

Современные модели генерации видео SOTA представляют собой преимущественно диффузионные преобразователи (DiT). В отличие от авторегрессионных моделей, таких как LLM, DiT не создают конечный результат по токенам. Вместо этого они начинают со случайного шума и неоднократно удаляют его, пока он не станет похож на конечный результат. В то время как авторегрессионные преобразователи прогнозируют следующий токен, DiT прогнозируют разницу/расстояние между шумным входом и немного менее шумным выходом (эта разница затем применяется к входу, прежде чем мы перейдем к следующему шагу шумоподавления).

В настоящее время для проверки вывода в Gonka исполнители сохраняют logprobs для каждого сгенерированного токена, а затем валидаторы «воспроизводят» вывод и сравнивают logprobs. Это не будет работать очень хорошо для DiT, потому что прогнозы намного тяжелее (обычно той же формы, что и скрытые входные данные), и мы не можем просто выбирать прогноз DiT, как мы делаем с прогнозами моделей авторегрессии.

Однако, что еще более важно, нет смысла напрямую сравнивать прогнозы DiT, поскольку результат, который мы получаем от запуска DiT, не является конечным результатом запуска модели. В частности, в Wan2.2 преобразователь работает со скрытым/сжатым представлением видео, и чтобы получить реальные видеокадры, нам нужно передать это скрытое представление через декодер VAE (который, по сути, представляет собой сверточную нейронную сеть). Кроме того, чтобы получить окончательный видеофайл, необходимо выполнить некоторую постобработку и закодировать кадры в видеоконтейнер.

Чтобы честно проверить вывод и защититься от подделки, нам нужно сравнить конечный результат генерации (т. е. реальный видеофайл, хэш которого мы храним в цепочке), но из-за присущего недетерминированности вычислений с плавающей запятой в графических процессорах мы не можем полагаться на побитовую идентичность выходных данных.

Доказательство вычислений

В отличие от LLM, которые в основном имеют один значимый в вычислительном отношении шаг (повторяющиеся прямые проходы через сеть на основе трансформатора), конвейер вывода моделей генерации видео немного сложнее. В случае Wan2.2 он также имеет небольшой текстовый кодировщик (https://huggingface.co/docs/transformers/model_doc/umt5) (для текстового приглашения), автокодировщик VAE и этапы постобработки.

Я считаю, что эти различия можно в значительной степени игнорировать, поскольку, по моей оценке, шаги по шумоподавлению DiT по-прежнему занимают >95% вычислений и >80% видеопамяти, необходимой для вывода. Для узла нет смысла обманывать PoC, экономя на кодировщике текста и весах VAE, поскольку негативные последствия (например, неудачные проверки) перевесят преимущества. Таким образом, я думаю, что доказательства того, что данный узел способен выполнять шаги шумоподавления, должно быть достаточно.

Ценовая политика

Когда дело доходит до LLM, ценообразование просто: мы просто взимаем плату за каждый токен (https://github.com/gonka-ai/gonka/blob/d8b8e9073d1a420d344d3ecc33ef23957f4142b1/inference-chain/x/inference/calculations/inference_state.go#L200). Это работает хорошо, поскольку модели являются авторегрессионными, и благодаря кэшированию KV каждый новый токен может повторно использовать кэшированные ключи и значения из предыдущих токенов (кроме периода предварительного заполнения). Это приводит к тому, что стоимость генерации растет примерно линейно с количеством выходных токенов. На практике это позволяет нам приблизительно оценить стоимость одного вывода как (prompt_token_count + response_token_count) * цена_per_token. Для DiT это не сработает.

В случае с DiT мы можем рассматривать скрытые патчи как наши токены. Скрытые патчи — это небольшие фрагменты скрытого представления модели. Однако, в отличие от моделей авторегрессии, DiT обрабатывают все скрытые исправления вместе на каждом этапе шумоподавления, а не генерируют их по одному, полагаясь на кэширование KV. Поскольку самообслуживание действует на всех патчах, стоимость одного прямого прохода возрастает примерно квадратично с количеством скрытых патчей. Кроме того, стоимость также линейно зависит от запрошенного количества шагов шумоподавления.

Решение высокого уровня

Перцептивное сходство для проверки умозаключений

Как мы видели выше, в диффузионных моделях мы оперируем скрытыми/сжатыми представлениями. Сила этого сжатия определяется шагом VAE (https://github.com/Wan-Video/Wan2.2/blob/42bf4cfaa384bc21833865abc2f9e6c0e67233dc/wan/configs/wan_t2v_A14B.py#L17) и количеством скрытых каналов. Для Wan2.2-T2V-A14B шаг (https://github.com/Wan-Video/Wan2.2/blob/42bf4cfaa384bc21833865abc2f9e6c0e67233dc/wan/configs/wan_t2v_A14B.py#L17) равен [4, 8, 8], а число каналов (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers/blob/main/vae/config.json#L55) составляет 16 . При включенном CFG (управление без классификатора) мы делаем два прохода вперед (https://github.com/huggingface/diffusers/blob/a851ce1058d5a465d7951687235cdaeac1978de2/src/diffusers/pipelines/wan/pipeline_wan.py#L620) на каждом шаге шумоподавления. Таким образом, мы можем подсчитать, что если бы мы сохраняли артефакты после каждого прямого прохода для одного видео с разрешением 1280x720 при 16 кадрах в секунду и длительностью 5 секунд за 40 шагов шумоподавления, потребовалось бы ~750 МБ памяти для видео, которое само по себе сжато примерно на ~5 МБ. Это слишком много для одного вывода.

По этой причине я предлагаю не хранить никаких артефактов, кроме самого итогового видеофайла. Вместо этого давайте сосредоточимся на повторном создании видео из исходного приглашения таким образом, чтобы наш результат был достаточно близок к результату исходного исполнителя, чтобы мы могли сравнивать их алгоритмически.

Прежде всего, нам необходимо избавиться от всех источников недетерминированности при выводе, которые находятся под нашим контролем:

Скрытый стартовый шум. Это тензор, содержащий случайный гауссов шум, из которого генерируется окончательное видео при каждом прямом проходе. Это основной источник недетерминизма. Часто в механизмах вывода он контролируется начальным числом ГПСЧ, поэтому нет необходимости хранить его как артефакт во время вывода, если мы гарантируем, что сможем детерминированно сгенерировать его из одного и того же начального числа на двух разных машинах.

Стек среды выполнения/аппаратного обеспечения. Различные реализации могут привести к разным активациям даже при одном и том же начальном скрытом шуме, и эти различия усугубляются на этапах шумоподавления, что приводит к разным результатам. Таким образом, чтобы получить результат, который, как мы можем с уверенностью сказать, внешне очень похож, нам необходимо убедиться, что мы фиксируем время выполнения для каждого вывода (например, используемый бэкэнд внимания, архитектура графического процессора и т. д.). Это означает, что если исполнитель использовал графические процессоры NVIDIA для получения результата, то валидатор также должен использовать графические процессоры NVIDIA.

Я считаю, что если мы сможем определить эти два источника недетерминизма, то результат вывода во время проверки должен быть достаточно близок к исходному результату, чтобы мы могли затем сравнивать видео покадрово, используя метрики сходства (https://github.com/chaofengc/IQA-PyTorch). В частности, DISTS (https://arxiv.org/abs/2004.07728) (глубокая структура изображения и сходство текстур) кажется хорошим вариантом, поскольку он утверждает, что обладает «толерантностью к повторной выборке текстур» и «относительно нечувствителен к геометрическим преобразованиям». LPIPS (https://richzhang.github.io/PerceptualSimilarity/) — еще один популярный вариант, но на данный момент он может быть немного устаревшим. Однако подходящую метрику можно было найти только экспериментальным путем.

Адаптируйте алгоритм PoC к DiT в vLLM-Omni

В настоящее время PoC тесно интегрирован с vLLM (https://github.com/gonka-ai/gonka/blob/main/proposals/poc/README.md#vllm), который не поддерживает модели диффузии. Первой задачей будет миграция узлов ML на vLLM-Omni (https://github.com/vllm-project/vllm-omni). Поскольку vLLM-Omni (https://github.com/vllm-project/vllm-omni) построен на основе vLLM, перенос существующей логики из вилки vLLM Gonka в вилку vLLM-Omni Gonka не должен быть проблемой.

Следующим шагом будет адаптация существующего механизма PoC для DiT. По сути, DiT по-прежнему являются преобразователями, поэтому должен работать тот же подход: вместо разгрузки модели вывода мы можем случайным образом «перемешать» способ применения весов, чтобы его можно было воспроизвести позже с учетом начального числа.

Однако есть одно важное отличие: смесь экспертов имеет тенденцию работать немного по-другому в диффузионных моделях. Точнее, в Wan2.2-T2V-A14B не изучается маршрутизатор MoE. У него есть два эксперта (с низким уровнем шума или с высоким уровнем шума), которых он выбирает детерминированно на основе текущего этапа шумоподавления. Эксперт с высоким уровнем шума используется на ранних стадиях шумоподавления (для общего макета и движения), а эксперт с низким уровнем шума используется позже при шумоподавлении (для уточнения деталей).

Это означает, что независимо от того, как мы преобразуем каждый слой, при начальном прямом проходе всегда будет использоваться эксперт с высоким уровнем шума. Таким образом, мы не будем доказывать, что узел действительно выполняет полную модель 27B, поскольку узел мог загрузить только эксперт с высоким уровнем шума. Таким образом, подход PoC должен учитывать эту ситуацию путем внедрения дополнительных перехватчиков в маршрутизатор MoE и выбирать эксперта случайным образом на основе начального числа.

Отдельная модель ценообразования для DiTs

Как обсуждалось ранее, вывод DiT отличается от вывода LLM по нескольким важным аспектам. Эти различия настолько значительны, что для DiT требуется отдельная модель ценообразования.

В настоящее время цена за токен для текстовых моделей определяется динамически в зависимости от использования модели (https://github.com/gonka-ai/gonka/blob/d8b8e9073d1a420d344d3ecc33ef23957f4142b1/inference-chain/x/inference/keeper/dynamic_pricing.go#L100). Мы можем повторно использовать ту же логику для DiT, но сначала нам нужно определить единицу выполнения. Разумной единицей измерения будет один прямой проход через модель с использованием минимальной поддерживаемой конфигурации, то есть настроек, которые приводят к наименьшим вычислительным затратам, таких как минимальное поддерживаемое разрешение, частота кадров в секунду и другие соответствующие параметры.

Тогда возникает вопрос: «Как нам вычислить количество единиц для данного запроса на вывод?» Хорошей новостью является то, что, в отличие от моделей авторегрессии, где мы не знаем окончательное количество сгенерированных токенов перед обработкой запроса, стоимость вывода DiT можно в значительной степени оценить заранее на основе запрошенных параметров.

Более конкретно, мы можем получить стоимость вывода из количества скрытых патчей и количества прямых проходов. Количество скрытых патчей зависит от запрошенной ширины, высоты и количества кадров, а также от параметров, специфичных для модели, таких как шаг VAE и размер скрытого патча. Число прямых проходов зависит от запрошенного количества шагов шумоподавления и реализации модели.

Тогда стоимость вывода может выглядеть так:

Стоимость вывода = цена_за_единицу * номер_перехода * (альфа * номер_латентного_патча^2 + бета * номер_латентного_патча)

Здесь latent_patch_num^2 фиксирует квадратичную стоимость самообслуживания по скрытым исправлениям, а latent_patch_num фиксирует примерно линейные части прямого прохода, такие как уровни MLP, нормализация, встраивания и т. д. Коэффициенты альфа и бета зависят от модели. Они зависят от архитектуры модели, такой как количество слоев, голов внимания, размер MLP и т. д. Мы можем оценить их эмпирически для каждой модели.

Дорожная карта реализации

ЭТАП 1: Проверка гипотезы проверки вывода. Сгенерируйте достаточно большой набор данных видео, используя одни и те же параметры на разных машинах, фиксируя при этом время выполнения и скрытый стартовый шум. Проведите эксперименты с различными показателями сходства, чтобы определить, какой из них работает лучше всего.

Сгенерируйте достаточно большой набор данных видео, используя одни и те же параметры на разных машинах, фиксируя при этом время выполнения и скрытый стартовый шум.

Проведите эксперименты с различными показателями сходства, чтобы определить, какой из них работает лучше всего.

ЭТАП 2. Миграция на vLLM-Omni. Перенесите пользовательскую логику PoC из вилки vLLM в вилку vLLM-Omni. Перенесите узлы ML на vLLM-Omni.

Перенесите пользовательскую логику PoC из вилки vLLM в вилку vLLM-Omni.

Перенесите узлы ML на vLLM-Omni.

ЭТАП 3: Поддержка Wan2.2-T2V-A14B. Внедрение проверки вывода. Убедитесь, что узлы проверяют вывод только по совпадающим узлам. Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу. Внедрите Proof-of-Compute, адаптировав существующую логику PoC для DiT. Внедрить модель ценообразования, специфичную для DiT.

Внедрить проверку вывода. Убедитесь, что узлы проверяют вывод только по совпадающим узлам. Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу.

Убедитесь, что узлы проверяют вывод только по совпадающим узлам.

Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу.

Внедрите Proof-of-Compute, адаптировав существующую логику PoC для DiT.

Внедрить модель ценообразования, специфичную для DiT.

Открытые вопросы

Насколько мы можем быть уверены в том, что определение времени выполнения и скрытого начального шума будет постоянно создавать видео, достаточно похожие, чтобы их можно было сравнить с показателями сходства восприятия?

Я предполагаю, что это должно иметь место на практике, но мы можем проверить это только посредством экспериментов: создания видео на разных машинах, способных запускать модель, и сравнения результатов.

Однако если эта гипотеза окажется ненадежной, мы могли бы использовать запасной вариант: сохранить дополнительные промежуточные артефакты во время вывода. Эти артефакты будут не самими предсказаниями DiT, а входными данными DiT, то есть скрытыми шумами видео. Нам также не нужно будет сохранять их на каждом этапе шумоподавления. Вместо этого исполнитель может сохранить небольшое количество промежуточных шумовых латентных состояний на выбранных шагах.

Во время проверки валидатор будет выполнять вывод до одного из этих шагов и сравнивать его промежуточное скрытое представление с тем, которое сохранено исполнителем. Если расстояние между двумя скрытыми представлениями слишком велико, проверка не удалась. Если расстояние достаточно мало, валидатор может продолжить генерацию из предоставленного исполнителем скрытого видео и повторить процесс со следующей сохраненной контрольной точки, в конечном итоге сравнивая окончательно сгенерированное видео как обычно.

Можем ли мы просто ограничить вывод DiT доверенными средами выполнения?

Проверка вывода, вероятно, самая сложная часть поддержки DiT, поэтому заманчиво предположить, что если предложение TEE (https://github.com/gonka-ai/gonka/discussions/951) будет реализовано, мы могли бы просто ограничить вывод текста в видео доверенными средами выполнения. Однако у TEE, похоже, есть свои нерешенные проблемы, о чем свидетельствует tee.fail (https://tee.fail/). Следовательно, даже если TEE станут частью Gonka в будущем, мы должны рассматривать их как возможный дополнительный уровень защиты, а не как основной механизм проверки вывода DiT.

Как обусловленность влияет на модель ценообразования DiT?

В случае Wan2.2-T2V-A14B единственным условием является текстовая подсказка. Поскольку длина подсказки ограничена, я не думаю, что нам нужно учитывать ее отдельно при оценке стоимости вывода.

Однако, если в будущем Gonka будет поддерживать другие модели DiT, они могут использовать более тяжелые формы обработки, такие как изображения, аудио или видео. Эти входные данные могут существенно повлиять на стоимость вывода. Если это произойдет, модель ценообразования, вероятно, придется расширить, чтобы учесть затраты на кондиционирование.

baygeldin

Я хотел бы расширить это предложение, чтобы помочь нам оценить, сколько вычислений нам понадобится для ЭТАПА 1.

План эксперимента для проверки видеовывода

Я предлагаю использовать документ «DiFR: проверка вывода, несмотря на недетерминизм» (https://arxiv.org/abs/2511.20621) в качестве основного справочника для проверки нашей гипотезы проверки вывода для генерации видео.

Почему DiFR является полезным справочником

DiFR изучает аналогичную проблему: как проверить, что вывод был выполнен в соответствии с заявленной спецификацией, несмотря на мягкий недетерминизм. В статье основное внимание уделяется текстовым моделям, но я думаю, что их методология здесь имеет непосредственное отношение.

Параллели с предложенным нами подходом:

Подход Token-DiFR приводит к получению скалярной оценки, рассчитанной на основе доверенной ссылки, показывающей, насколько близко вывод соответствует этой ссылке. Аналогичным образом, наша метрика сходства восприятия будет скалярной оценкой, рассчитанной на основе генерации эталонного видео.

Расширение Activation-DiFR похоже на идею контрольных точек, описанную в разделе «Открытые вопросы» предложения, в том смысле, что оно сравнивает промежуточные артефакты вывода с соответствующими промежуточными состояниями вывода проверяющего.

В статье представлена полезная методология:

Он определяет одну каноническую справочную спецификацию.

Он определяет доброкачественные отклонения, то есть конфигурации «правильные, но шумные». Они моделируют «незначительный числовой шум, генерируя выходные данные с использованием настроек, которые алгебраически эквивалентны эталонной конфигурации, за исключением порядка сокращений с плавающей запятой» (например, различные микроархитектуры графического процессора).

Он определяет неправильные/злонамеренные конфигурации: реальные отклонения от спецификации, такие как неправильные веса, неправильное квантование, неправильное начальное значение выборки и т. д.

Ключевой вопрос — выбор порога: можно ли четко отделить допустимые межмашинные пары от недействительных или подделанных пар?

Он оценивает качество обнаружения при целевом показателе ложных срабатываний в 1%.

ПРИМЕЧАНИЕ. Мне также кажется интересным, что в документе утверждается, что он превосходит TOPLOC («Activation-DiFR достигает AUC около 0,999 при 7,25 байтах на токен, в то время как TOPLOC требует 32 байта на токен, чтобы соответствовать этой точности») благодаря использованию эффективного сжатия с помощью леммы Джонсона-Линденштрауса.

Конфигурации

Справочная спецификация

Я предлагаю использовать следующую каноническую конфигурацию:

NVIDIA H100 (или H200)

нет тензорного параллелизма

без квантования (тип BF16)

Cache-DiT отключен

Конфигурация графиков включена

40 шагов шумоподавления

фиксированное начальное значение PRNG для каждого запроса

Кроме того, мы должны закрепить следующее для всех конфигураций:

механизм вывода (vLLM-Omni)

Серверная часть внимания (FlashAttention)

настройки планировщика (мы можем использовать настройки по умолчанию (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers/blob/main/scheduler/scheduler_config.json))

версия модели (точный хеш коммита HuggingFace (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers))

настройки видеокодера

Доброкачественные отклонения

Давайте использовать конфигурации, аналогичные статье DiFR:

NVIDIA A100 без тензорного параллелизма

NVIDIA H100 с 4-сторонним тензорным параллелизмом (TP-4)

NVIDIA A100 с 4-сторонним тензорным параллелизмом (TP-4). ПРИМЕЧАНИЕ. Это действует как безопасное отклонение в худшем случае, поскольку сочетает в себе другие безопасные отклонения.

ПРИМЕЧАНИЕ. Это действует как доброкачественное отклонение в худшем случае, поскольку сочетает в себе другие доброкачественные отклонения.

(дополнительно) AMD MI300X ПРИМЕЧАНИЕ. Если доброкачественные отклонения NVIDIA слишком легко отличить от злокачественных, мы также можем провести стресс-тестирование подхода на AMD. Я бы не ожидал, что это сработает хорошо, потому что это меняет слишком много вещей одновременно.

ПРИМЕЧАНИЕ. Если доброкачественные отклонения NVIDIA слишком легко отличить от злокачественных, мы могли бы также провести стресс-тестирование подхода на AMD. Я бы не ожидал, что это сработает хорошо, потому что это меняет слишком много вещей одновременно.

ПРИМЕЧАНИЕ. Версия CUDA, версия драйвера, версия PyTorch и версия vLLM-Omni также могут влиять на выходные данные, но, вероятно, в меньшей степени, чем отклонения, перечисленные выше. В документе DiFR также не выделяются эти различия; он даже тестирует различные механизмы вывода. Поэтому я бы не стал включать в эксперимент изменения версий программного стека.

Злокачественные отклонения

Для генерации видео эти отклонения можно считать злокачественными:

39 шагов шумоподавления

30 шагов шумоподавления

Квантованная модель FP8 ПРИМЕЧАНИЕ. Это может быть сложно; см. примечание ниже.

ПРИМЕЧАНИЕ. Это может быть сложно; см. примечание ниже.

CFG отключен. ПРИМЕЧАНИЕ. Это уменьшает количество проходов вперед вдвое.

ПРИМЕЧАНИЕ. Это уменьшает количество проходов вперед вдвое.

Включение Cache-DiT ПРИМЕЧАНИЕ. Само по себе это не обязательно является вредоносным, поскольку это компромисс между VRAM и производительностью, но полезно проверить, можем ли мы отличить его от эталонного поколения.

ПРИМЕЧАНИЕ. Само по себе это не обязательно является злом, поскольку это компромисс между видеопамятью и производительностью, но полезно проверить, можем ли мы отличить его от эталонного поколения.

другое начальное значение PRNG ПРИМЕЧАНИЕ. Случай с другим начальным значением сам по себе не является реалистичной стратегией мошенничества, но он полезен в качестве базовой линии, поскольку должен давать заметно отличающийся результат.

ПРИМЕЧАНИЕ. Случай с разными исходными кодами сам по себе не является реалистичной стратегией мошенничества, но он полезен в качестве базового уровня, поскольку должен давать заметно отличающийся результат.

Примечание по модели FP8: в идеале весь эксперимент должен использовать vLLM-Omni в качестве механизма вывода, чтобы работу можно было повторно использовать на более поздних этапах реализации. Однако пока не ясно, сможет ли vLLM-Omni надежно запускать квантованный вариант Wan2.2-T2V-A14B. В документации vLLM-Omni Wan2.2 помечен как «не проверенный» (https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/quantization/fp8/#diffusion-model-qwen-image-wan22).

Если не получается, есть два варианта:

Пропустите отклонение FP8 в первом раунде и добавьте его, как только vLLM-Omni поддержит его.

Запустите только это отклонение через другой механизм вывода, например запустите Wan2.2-T2V-A14B-Diffusers-FP8 (https://huggingface.co/nvidia/Wan2.2-T2V-A14B-Diffusers-FP8) через TRT-LLM, и четко отметьте его как сомнительное отклонение, поскольку изменились механизм квантования и вывода.

Первый вариант более чист с научной точки зрения. Второй вариант по-прежнему полезен в качестве практического стресс-теста, но результат не следует интерпретировать как изолированный эффект только квантования.

Размер набора данных

В статье DiFR авторы собрали примерно 1 миллион выходных токенов на конфигурацию, по 9 конфигураций на модель. Затем они разделили токены в каждой конфигурации на непересекающиеся пакеты и рассчитали статистику на уровне пакета путем агрегирования оценок Token-DiFR. При размере партии в 10 000 токенов это дает ~900 экземпляров на модель. При размере партии в 1000 токенов это соответственно дает ~9000 экземпляров на модель.

Для генерации видео нам не нужно одинаково изменять размеры пакетов токенов, поскольку каждое поколение имеет примерно одинаковое количество кадров. Но мы все равно можем использовать это как приблизительный ориентир для определения того, сколько примеров нужно создать для эксперимента.

Для каждого запроса мы можем создать одно эталонное видео и одно видео для каждой доброкачественной и вредоносной конфигурации. При одной канонической конфигурации, 3 доброкачественных отклонениях и 6 злокачественных отклонениях это означает 10 поколений на одно приглашение.

Таким образом, используя примерно 1000 подсказок/примеров, можно создать около 10 000 видеофайлов.

Для этого эксперимента нет необходимости создавать видео высокого разрешения. Мы должны использовать минимальный поддерживаемый формат:

Разрешение 832x480

81 кадр при 16 кадрах в секунду (~5 секунд)

Всего это около 14 часов сгенерированного видео.

Артефакты, которые нужно сохранить

Для каждого поколения мы должны сохранить:

полное описание конфигурации

полные параметры генерации

окончательный закодированный видеофайл

избранные промежуточные латентные

Промежуточные латентные состояния должны включать как минимум:

начальный скрытый шум ПРИМЕЧАНИЕ. Это проверка работоспособности, призванная подтвердить, что фиксированное начальное значение действительно создает одинаковый начальный скрытый шум во всех конфигурациях. В противном случае мы можем в конечном итоге измерить расхождение, вызванное различным начальным шумом, а не самим изменением конфигурации.

ПРИМЕЧАНИЕ. Это проверка работоспособности, призванная подтвердить, что фиксированное начальное значение действительно создает одинаковый начальный шум, скрытый во всех конфигурациях. В противном случае мы можем в конечном итоге измерить расхождение, вызванное различным начальным шумом, а не самим изменением конфигурации.

скрытый непосредственно перед экспертным переключением с высокого уровня шума на низкий уровень шума

последний скрытый перед декодированием VAE

Эти скрытые артефакты предназначены для эксперимента, а не для производства. Они помогают нам понять, где появляется расхождение. Если сравнение восприятия финального видео окажется надежным, производственная валидация позволит избежать хранения скрытых данных. Если он окажется ненадежным, эти скрытые контрольные точки станут запасным путем проверки.

Сами закодированные видеофайлы должны занимать около 35 ГБ памяти. Для выбранных промежуточных скрытых данных потребуется примерно ~125 ГБ, если они хранятся как тензоры BF16/FP16, или ~250 ГБ, если они хранятся как тензоры FP32. Итак, в целом нам понадобится около 200-300 ГБ памяти.

Вычислить оценку

Нам необходимо запустить следующие конфигурации:

Каноническая конфигурация H100 + 6 злонамеренных неправильных конфигураций (7000 поколений)

4xH100 щадящая конфигурация с TP-4 (1000 поколений)

Доброкачественная конфигурация A100 (1000 поколений)

Доброкачественная конфигурация 4xA100 с TP-4 (1000 поколений)

Используя официальный тест Wan2.2 T2V-A14B (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B#computational-efficiency-on- Different-gpus) в качестве грубой оценки:

1xH100: 326,9 с/видео

4xH100: 91,7 с/видео

1xA100: 785,7 с/видео

4xA100: 215,2 с/видео

Это дает:

H100: (7000 * 326,9 + 1000 * 91,7 * 4) / 3600 = ~738 графических часов

A100: (1000 * 785,7 + 1000 * 215,2 * 4) / 3600 = ~457 графических часов

Таким образом, общая сумма составляет около 1200 часов графического процессора только для генерации. Чтобы оставить место для повторных попыток, отладки, неудачных запусков и небольших изменений конфигурации, нам, вероятно, следует заложить в бюджет около 1500 часов графического процессора.

Русский перевод

baygeldinАвтор

Мотивация

Проблемы

Проверка вывода

Доказательство вычислений

Ценовая политика

Решение высокого уровня

Перцептивное сходство для проверки умозаключений

Скрытый стартовый шум. Это тензор, содержащий случайный гауссов шум, из которого генерируется окончательное видео при каждом прямом проходе. Это основной источник недетерминизма. Часто в механизмах вывода он контролируется начальным числом ГПСЧ, поэтому нет необходимости хранить его как артефакт во время вывода, если мы гарантируем, что сможем детерминированно сгенерировать его из одного и того же начального числа на двух разных машинах.

Стек среды выполнения/аппаратного обеспечения. Различные реализации могут привести к разным активациям даже при одном и том же начальном скрытом шуме, и эти различия усугубляются на этапах шумоподавления, что приводит к разным результатам. Таким образом, чтобы получить результат, который, как мы можем с уверенностью сказать, внешне очень похож, нам необходимо убедиться, что мы фиксируем время выполнения для каждого вывода (например, используемый бэкэнд внимания, архитектура графического процессора и т. д.). Это означает, что если исполнитель использовал графические процессоры NVIDIA для получения результата, то валидатор также должен использовать графические процессоры NVIDIA.

Адаптируйте алгоритм PoC к DiT в vLLM-Omni

Отдельная модель ценообразования для DiTs

Тогда стоимость вывода может выглядеть так:

Стоимость вывода = цена_за_единицу * номер_перехода * (альфа * номер_латентного_патча^2 + бета * номер_латентного_патча)

Дорожная карта реализации

ЭТАП 1: Проверка гипотезы проверки вывода. Сгенерируйте достаточно большой набор данных видео, используя одни и те же параметры на разных машинах, фиксируя при этом время выполнения и скрытый стартовый шум. Проведите эксперименты с различными показателями сходства, чтобы определить, какой из них работает лучше всего.

Сгенерируйте достаточно большой набор данных видео, используя одни и те же параметры на разных машинах, фиксируя при этом время выполнения и скрытый стартовый шум.

Проведите эксперименты с различными показателями сходства, чтобы определить, какой из них работает лучше всего.

ЭТАП 2. Миграция на vLLM-Omni. Перенесите пользовательскую логику PoC из вилки vLLM в вилку vLLM-Omni. Перенесите узлы ML на vLLM-Omni.

Перенесите пользовательскую логику PoC из вилки vLLM в вилку vLLM-Omni.

Перенесите узлы ML на vLLM-Omni.

ЭТАП 3: Поддержка Wan2.2-T2V-A14B. Внедрение проверки вывода. Убедитесь, что узлы проверяют вывод только по совпадающим узлам. Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу. Внедрите Proof-of-Compute, адаптировав существующую логику PoC для DiT. Внедрить модель ценообразования, специфичную для DiT.

Внедрить проверку вывода. Убедитесь, что узлы проверяют вывод только по совпадающим узлам. Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу.

Убедитесь, что узлы проверяют вывод только по совпадающим узлам.

Если узел не соответствует среде выполнения исполнителя, он должен делегировать проверку другому узлу.

Внедрите Proof-of-Compute, адаптировав существующую логику PoC для DiT.

Внедрить модель ценообразования, специфичную для DiT.

Открытые вопросы

Можем ли мы просто ограничить вывод DiT доверенными средами выполнения?

Как обусловленность влияет на модель ценообразования DiT?

baygeldin

План эксперимента для проверки видеовывода

Почему DiFR является полезным справочником

Параллели с предложенным нами подходом:

Подход Token-DiFR приводит к получению скалярной оценки, рассчитанной на основе доверенной ссылки, показывающей, насколько близко вывод соответствует этой ссылке. Аналогичным образом, наша метрика сходства восприятия будет скалярной оценкой, рассчитанной на основе генерации эталонного видео.

Расширение Activation-DiFR похоже на идею контрольных точек, описанную в разделе «Открытые вопросы» предложения, в том смысле, что оно сравнивает промежуточные артефакты вывода с соответствующими промежуточными состояниями вывода проверяющего.

В статье представлена полезная методология:

Он определяет одну каноническую справочную спецификацию.

Он определяет доброкачественные отклонения, то есть конфигурации «правильные, но шумные». Они моделируют «незначительный числовой шум, генерируя выходные данные с использованием настроек, которые алгебраически эквивалентны эталонной конфигурации, за исключением порядка сокращений с плавающей запятой» (например, различные микроархитектуры графического процессора).

Он определяет неправильные/злонамеренные конфигурации: реальные отклонения от спецификации, такие как неправильные веса, неправильное квантование, неправильное начальное значение выборки и т. д.

Ключевой вопрос — выбор порога: можно ли четко отделить допустимые межмашинные пары от недействительных или подделанных пар?

Он оценивает качество обнаружения при целевом показателе ложных срабатываний в 1%.

Конфигурации

Справочная спецификация

Я предлагаю использовать следующую каноническую конфигурацию:

NVIDIA H100 (или H200)

нет тензорного параллелизма

без квантования (тип BF16)

Cache-DiT отключен

Конфигурация графиков включена

40 шагов шумоподавления

фиксированное начальное значение PRNG для каждого запроса

Кроме того, мы должны закрепить следующее для всех конфигураций:

механизм вывода (vLLM-Omni)

Серверная часть внимания (FlashAttention)

настройки планировщика (мы можем использовать настройки по умолчанию (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers/blob/main/scheduler/scheduler_config.json))

версия модели (точный хеш коммита HuggingFace (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers))

настройки видеокодера

Доброкачественные отклонения

Давайте использовать конфигурации, аналогичные статье DiFR:

NVIDIA A100 без тензорного параллелизма

NVIDIA H100 с 4-сторонним тензорным параллелизмом (TP-4)

NVIDIA A100 с 4-сторонним тензорным параллелизмом (TP-4). ПРИМЕЧАНИЕ. Это действует как безопасное отклонение в худшем случае, поскольку сочетает в себе другие безопасные отклонения.

ПРИМЕЧАНИЕ. Это действует как доброкачественное отклонение в худшем случае, поскольку сочетает в себе другие доброкачественные отклонения.

(дополнительно) AMD MI300X ПРИМЕЧАНИЕ. Если доброкачественные отклонения NVIDIA слишком легко отличить от злокачественных, мы также можем провести стресс-тестирование подхода на AMD. Я бы не ожидал, что это сработает хорошо, потому что это меняет слишком много вещей одновременно.

ПРИМЕЧАНИЕ. Если доброкачественные отклонения NVIDIA слишком легко отличить от злокачественных, мы могли бы также провести стресс-тестирование подхода на AMD. Я бы не ожидал, что это сработает хорошо, потому что это меняет слишком много вещей одновременно.

Злокачественные отклонения

Для генерации видео эти отклонения можно считать злокачественными:

39 шагов шумоподавления

30 шагов шумоподавления

Квантованная модель FP8 ПРИМЕЧАНИЕ. Это может быть сложно; см. примечание ниже.

ПРИМЕЧАНИЕ. Это может быть сложно; см. примечание ниже.

CFG отключен. ПРИМЕЧАНИЕ. Это уменьшает количество проходов вперед вдвое.

ПРИМЕЧАНИЕ. Это уменьшает количество проходов вперед вдвое.

Включение Cache-DiT ПРИМЕЧАНИЕ. Само по себе это не обязательно является вредоносным, поскольку это компромисс между VRAM и производительностью, но полезно проверить, можем ли мы отличить его от эталонного поколения.

ПРИМЕЧАНИЕ. Само по себе это не обязательно является злом, поскольку это компромисс между видеопамятью и производительностью, но полезно проверить, можем ли мы отличить его от эталонного поколения.

другое начальное значение PRNG ПРИМЕЧАНИЕ. Случай с другим начальным значением сам по себе не является реалистичной стратегией мошенничества, но он полезен в качестве базовой линии, поскольку должен давать заметно отличающийся результат.

ПРИМЕЧАНИЕ. Случай с разными исходными кодами сам по себе не является реалистичной стратегией мошенничества, но он полезен в качестве базового уровня, поскольку должен давать заметно отличающийся результат.

Если не получается, есть два варианта:

Пропустите отклонение FP8 в первом раунде и добавьте его, как только vLLM-Omni поддержит его.

Запустите только это отклонение через другой механизм вывода, например запустите Wan2.2-T2V-A14B-Diffusers-FP8 (https://huggingface.co/nvidia/Wan2.2-T2V-A14B-Diffusers-FP8) через TRT-LLM, и четко отметьте его как сомнительное отклонение, поскольку изменились механизм квантования и вывода.

Размер набора данных

Таким образом, используя примерно 1000 подсказок/примеров, можно создать около 10 000 видеофайлов.

Разрешение 832x480

81 кадр при 16 кадрах в секунду (~5 секунд)

Всего это около 14 часов сгенерированного видео.

Артефакты, которые нужно сохранить

Для каждого поколения мы должны сохранить:

полное описание конфигурации

полные параметры генерации

окончательный закодированный видеофайл

избранные промежуточные латентные

Промежуточные латентные состояния должны включать как минимум:

начальный скрытый шум ПРИМЕЧАНИЕ. Это проверка работоспособности, призванная подтвердить, что фиксированное начальное значение действительно создает одинаковый начальный скрытый шум во всех конфигурациях. В противном случае мы можем в конечном итоге измерить расхождение, вызванное различным начальным шумом, а не самим изменением конфигурации.

ПРИМЕЧАНИЕ. Это проверка работоспособности, призванная подтвердить, что фиксированное начальное значение действительно создает одинаковый начальный шум, скрытый во всех конфигурациях. В противном случае мы можем в конечном итоге измерить расхождение, вызванное различным начальным шумом, а не самим изменением конфигурации.

скрытый непосредственно перед экспертным переключением с высокого уровня шума на низкий уровень шума

последний скрытый перед декодированием VAE

Вычислить оценку

Нам необходимо запустить следующие конфигурации:

Каноническая конфигурация H100 + 6 злонамеренных неправильных конфигураций (7000 поколений)

4xH100 щадящая конфигурация с TP-4 (1000 поколений)

Доброкачественная конфигурация A100 (1000 поколений)

Доброкачественная конфигурация 4xA100 с TP-4 (1000 поколений)

1xH100: 326,9 с/видео

4xH100: 91,7 с/видео

1xA100: 785,7 с/видео

4xA100: 215,2 с/видео

Это дает:

H100: (7000 * 326,9 + 1000 * 91,7 * 4) / 3600 = ~738 графических часов

A100: (1000 * 785,7 + 1000 * 215,2 * 4) / 3600 = ~457 графических часов

Оригинал

baygeldinАвтор

Motivation

Open-weight video generation models have improved significantly over the past few years and have reached a level of quality that makes them viable for real-world video production workflows. Adding support for these models to the Gonka network has the potential to reduce production costs. Additionally, it would open a path toward supporting other modalities in the future.

I propose to start with supporting text-to-video models as the most general case. More specifically, with the Wan2.2-T2V-A14B model because it seems to be the best open-source text-to-video model to date that has a permissive license (Apache 2.0). LTX-2.3 is comparable in terms of performance, but has a much more restrictive custom license which might present additional unnecessary hurdles at this point.

Challenges

Let's first outline the challenges we face due to the architectural differences between video generation models and LLMs.

Inference validation

Current SOTA video generation models are predominantly diffusion transformers (DiTs). Unlike autoregressive models such as LLMs, DiTs don't build the final result token-by-token. Instead, they start with random noise and repeatedly denoise it until it resembles the final result. While autoregressive transformers predict the next token, DiTs predict the difference/distance between the noisy input and the slightly less noisy output (this difference is then applied to the input before we move to the next denoising step).

Currently, to validate inference in Gonka, executors store logprobs for each generated token, and then validators "replay" the inference and compare logprobs. This wouldn't work very well for DiTs because the predictions are much heavier (usually the same shape as the input latent) and we can't just sample the DiTs prediction like we do with autoregressive models predictions.

More importantly, though, it doesn't make sense to compare the DiTs predictions directly because the result we get from running the DiT is not the final result of running the model. Specifically, in Wan2.2, the transformer operates on a latent/compressed representation of the video, and to get the actual video frames we need to pass that latent representation through a VAE decoder (which is essentially a convolutional neural network). Additionally, to get the final video file it needs to do some post-processing and encode the frames into a video container.

To validate inference honestly and protect against tampering we need to compare the final result of the generation (i.e. the actual video file which hash we store on-chain), but due to inherent nondeterminism of floating point math in GPUs we can't rely on outputs being bitwise-identical.

Proof-of-Compute

Unlike LLMs that basically have a single computationally significant step (repeated forward passes through the transformer-based network), video generation models inference pipeline is a bit more complex. In case of Wan2.2, it also has a small text encoder (https://huggingface.co/docs/transformers/model_doc/umt5) (for the text prompt), VAE autoencoder, and post-processing steps.

I believe that these differences could be largely disregarded because by my estimate, DiT denoising steps still seem to account for >95% of compute and >80% of VRAM needed during inference. It makes little sense for a node to trick PoC by saving on text encoder and VAE weights because negatives (such as failed validations) would outweigh the benefits. Thus, I think that proving that a given node is able to run the denoising steps should be enough.

Pricing policy

When it comes to LLMs, pricing is straightforward: we simply charge per token (https://github.com/gonka-ai/gonka/blob/d8b8e9073d1a420d344d3ecc33ef23957f4142b1/inference-chain/x/inference/calculations/inference_state.go#L200) . This works well because the models are autoregressive and, thanks to KV caching, each new token can reuse the cached keys and values from previous tokens (except during prefill). This makes generation cost grow roughly linearly with the number of output tokens. In practice, this lets us approximate the cost of a single inference as something like (prompt_token_count + response_token_count) * price_per_token . This wouldn't work for DiTs.

In case of DiTs, we can think of latent patches as our tokens. Latent patches are small chunks of the model's latent representation. Unlike autoregressive models, however, DiTs process all latent patches together at each denoising step rather than generating them one at a time while relying on KV caching. Because self-attention operates over all patches, the cost of a single forward pass grows roughly quadratically with the number of latent patches. Additionally, the cost is also linearly driven by the requested number of denoising steps.

High-Level Solution

Perceptual similarity for inference validation

As we saw above, in diffusion models we operate on the latent/compressed representations. The strength of that compression is defined by the VAE stride (https://github.com/Wan-Video/Wan2.2/blob/42bf4cfaa384bc21833865abc2f9e6c0e67233dc/wan/configs/wan_t2v_A14B.py#L17) and the number of latent channels. For Wan2.2-T2V-A14B the stride (https://github.com/Wan-Video/Wan2.2/blob/42bf4cfaa384bc21833865abc2f9e6c0e67233dc/wan/configs/wan_t2v_A14B.py#L17) is [4, 8, 8] and the the number of channels (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers/blob/main/vae/config.json#L55) is 16 . With CFG (Classifier-Free Guidance) enabled, we make two forward passes (https://github.com/huggingface/diffusers/blob/a851ce1058d5a465d7951687235cdaeac1978de2/src/diffusers/pipelines/wan/pipeline_wan.py#L620) per denoising step. Thus, we can estimate that if we were to save artifacts after each forward pass, for a single 1280x720@16FPS video with the duration of 5s over 40 denoising steps, it'd take ~750MB of storage for a video that itself is only about ~5MB compressed. This is too much for a single inference.

For this reason, I propose not to store any artifacts except the final video file itself. Instead, let's focus on re-generating the video from the original prompt in a way that our result is close enough to the original executor's result, so that we could compare them algorithmically.

First of all, we need to get rid of all sources of nondeterminism during inference that are under our control:

Starting noise latent. This is a tensor containing random Gaussian noise from which the final video is generated with each forward pass. It's the main source of nondeterminism. Often, it's controlled by the PRNG seed in inference engines, so it's not necessary to store it as an artifact during inference if we ensure that we can deterministically generate it from the same seed on two different machines.

Runtime/hardware stack. Different implementations could result different activations even with the same starting noise latent, and these differences compound over denoising steps leading to different results. Thus, to get a result that we can confidently say is visibly very similar, we need to make sure that we pin the runtime for each inference (e.g. attention backend used, GPU architecture, etc). This means that if the executor used NVIDIA GPUs to produce the result, then the validator should also use NVIDIA GPUs.

I believe that if we can pin these two sources of nondeterminism, then the result of the inference during validation should be close enough to the original result that we can then compare the videos frame-by-frame using similarity metrics (https://github.com/chaofengc/IQA-PyTorch) . Particularly, DISTS (https://arxiv.org/abs/2004.07728) (Deep Image Structure and Texture Similarity) seems like a good option as it claims to have "tolerance to texture resampling" and "relatively insensitive to geometric transformation". LPIPS (https://richzhang.github.io/PerceptualSimilarity/) is another popular option, but it may be a bit outdated at this point. However, the appropriate metric could only be found through experimentation.

Adapt PoC algorithm to DiTs in vLLM-Omni

Currently, PoC is tightly integrated into vLLM (https://github.com/gonka-ai/gonka/blob/main/proposals/poc/README.md#vllm) which doesn't support diffusion models. The first task would be to migrate ML nodes to vLLM-Omni (https://github.com/vllm-project/vllm-omni) . Since vLLM-Omni (https://github.com/vllm-project/vllm-omni) is built on top of vLLM, porting the existing logic from Gonka's vLLM fork to Gonka's vLLM-Omni fork shouldn't be a problem.

The next step would be adapt the existing PoC mechanism for DiTs . At the core, DiTs are still transformers, so the same approach should work: instead of offloading the inference model, we can randomly "scramble" how the weights are applied in a way that could be reproduced later given the seed.

However, there's one important difference: Mixture-of-Experts tends to work a bit differently in the diffusion models. More specifically, in Wan2.2-T2V-A14B the MoE router is not learned. It has two experts (low-noise or high-noise) which it chooses deterministically based on the current denoising step. High-noise expert is used early in denoising (for overall layout and motion), and low-noise expert is used later in denoising (for refining details).

This means that no matter how we transform each layer, the initial forward pass would always use the high-noise expert. So, we won't prove that the node actually runs the full 27B model since the node could have loaded only the high-noise expert. Thus, PoC approach needs to account for this situation by implementing additional hooks into the MoE router, and choose the expert randomly based on the seed.

Separate pricing model for DiTs

As discussed earlier, DiT inference differs from LLM inference in several important ways. These differences are significant enough that DiTs require a separate pricing model.

Currently, the price per token for text models is determined dynamically based on the model's utilization (https://github.com/gonka-ai/gonka/blob/d8b8e9073d1a420d344d3ecc33ef23957f4142b1/inference-chain/x/inference/keeper/dynamic_pricing.go#L100) . We can reuse the same logic for DiTs, but we first need to define a unit of execution . A reasonable unit would be a single forward pass through the model using the minimum supported configuration, meaning the settings that result in the lowest computational cost, such as the minimum supported resolution, FPS, and other relevant parameters.

Then the question becomes: "How do we compute the number of units for a given inference request?" The good news is that, unlike with autoregressive models, where we do not know the final number of generated tokens before processing the request, DiT inference cost can be pretty much estimated upfront from the requested parameters.

More specifically, we can derive the inference cost from the number of latent patches and the number of forward passes . The latent patch count depends on the requested width, height, and frame count, together with model-specific parameters such as the VAE stride and latent patch size. The forward-pass count depends on the requested number of denoising steps and model's implementation.

Then the inference cost can look like this:

inference cost = price_per_unit * forward_pass_num * ( alpha * latent_patch_num^2 + beta * latent_patch_num )

Here, latent_patch_num^2 captures the quadratic cost of self-attention over latent patches, while latent_patch_num captures the roughly linear parts of the forward pass, such as MLP layers, normalization, embeddings, etc. The coefficients alpha and beta are model-specific. They depend on the model architecture such as the number of layers, attention heads, MLP size, etc. We can estimate them empirically for each model.

Implementation Roadmap

STAGE 1: Verify the inference validation hypothesis Generate a sufficiently large dataset of videos using the same parameters on different machines, while pinning the runtime and the starting noise latent. Run experiments with different similarity metrics to determine which one works best.

Generate a sufficiently large dataset of videos using the same parameters on different machines, while pinning the runtime and the starting noise latent.

Run experiments with different similarity metrics to determine which one works best.

STAGE 2: Migrate to vLLM-Omni Port the custom PoC logic from the vLLM fork to the vLLM-Omni fork. Migrate ML nodes to vLLM-Omni.

Port the custom PoC logic from the vLLM fork to the vLLM-Omni fork.

Migrate ML nodes to vLLM-Omni.

STAGE 3: Support Wan2.2-T2V-A14B Implement inference validation. Ensure that nodes validate inference only against matching nodes. If a node does not match the executor's runtime, it should delegate validation to another node. Implement Proof-of-Compute by adapting the existing PoC logic for DiTs. Implement the DiT-specific pricing model.

Implement inference validation. Ensure that nodes validate inference only against matching nodes. If a node does not match the executor's runtime, it should delegate validation to another node.

Ensure that nodes validate inference only against matching nodes.

If a node does not match the executor's runtime, it should delegate validation to another node.

Implement Proof-of-Compute by adapting the existing PoC logic for DiTs.

Implement the DiT-specific pricing model.

Open questions

How confident can we be that pinning the runtime and the starting noise latent would consistently produce videos similar enough to compare with perceptual similarity metrics?

My assumption is that this should hold in practice, but we can only verify it through experiments: generating videos on different machines capable of running the model and comparing the results.

If this hypothesis proves unreliable though, we could use a fallback approach: saving additional intermediate artifacts during inference. These artifacts would not be the DiT predictions themselves, but the DiT inputs, meaning the noisy video latents. We also would not need to save them at every denoising step. Instead, the executor could save a small number of intermediate noisy latents at selected steps.

During validation, the validator would run inference up to one of those steps and compare its intermediate latent representation with the one saved by the executor. If the distance between the two latent representations is too large, validation fails. If the distance is small enough, the validator can continue generation from the executor-provided latent and repeat the process from the next saved checkpoint, eventually comparing the final generated video as usual.

Could we simply limit DiT inference to Trusted Execution Environments?

Inference validation is probably the trickiest part of supporting DiTs, so it is tempting to assume that if the TEE proposal (https://github.com/gonka-ai/gonka/discussions/951) is implemented, we could simply restrict text-to-video inference to trusted execution environments. However, TEEs appear to have their own unresolved issues, as shown by tee.fail (https://tee.fail/) . Therefore, even if TEEs become part of Gonka in the future, we should treat them as a possible additional layer of protection rather than as the primary validation mechanism for DiT inference.

How does conditioning factor into the DiT pricing model?

In the case of Wan2.2-T2V-A14B, the only conditioning comes from the text prompt. Since the prompt length is capped, I do not think we need to account for it separately when estimating inference cost.

However, if Gonka supports other DiT models in the future, they may use heavier forms of conditioning, such as images, audio, or video. These inputs could meaningfully affect inference cost. If that happens, the pricing model would probably need to be extended to account for conditioning cost.

baygeldin

I'd like to expand on the proposal to help us estimate how much compute we'd need for STAGE 1 .

Experiment design for video inference validation

I propose using the "DiFR: Inference Verification Despite Nondeterminism" (https://arxiv.org/abs/2511.20621) paper as the main reference for testing our inference-validation hypothesis for video generation.

Why DiFR is a useful reference

DiFR studies a similar problem: how to verify that inference was performed according to a declared specification despite benign nondeterminism. The paper focuses on text models, but I think their methodology is directly relevant here.

The parallels with our proposed approach:

Token-DiFR approach results in a scalar score calculated against a trusted reference, indicating how closely the inference matches that reference. Similarly, our perceptual similarity metric would be a scalar score calculated against a reference video generation.

Activation-DiFR extension is similar to the checkpointing idea described in the "Open Questions" section of the proposal in a sense that it compares intermediate inference artifacts against the verifier's corresponding intermediate inference states.

The paper provides a useful methodology:

It defines one canonical reference specification .

It defines benign deviations , meaning "correct-but-noisy" configurations. They simulate "benign numerical noise by generating outputs using setups that are algebraically equivalent to the reference configuration apart from the ordering of floating-point reductions" (e.g. different GPU microarchitectures).

It defines incorrect/malicious misconfigurations : real deviations from the specification, such as wrong weights, incorrect quantization, incorrect sampling seed, etc.

The key question is threshold selection : can valid cross-machine pairs be separated cleanly from invalid or tampered pairs?

It evaluates detection quality at a target false positive rate of 1% .

NOTE: I also find it interesting that the paper claims to outperform TOPLOC ( "Activation-DiFR reaches AUC near 0.999 at 7.25 bytes per token, while TOPLOC requires 32 bytes per token to match this accuracy" ) thanks to relying on the efficient compression via Johnson–Lindenstrauss lemma.

Configurations

Reference specification

I propose using the following canonical configuration:

NVIDIA H100 (or H200)

no tensor parallelism

no quantization (BF16 dtype)

Cache-DiT disabled

CFG enabled

40 denoising steps

fixed PRNG seed per prompt

Additionally, we should pin the following for all configurations:

inference engine (vLLM-Omni)

attention backend (FlashAttention)

scheduler settings (we can use default settings (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers/blob/main/scheduler/scheduler_config.json) )

model revision (exact HuggingFace (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B-Diffusers) commit hash)

video encoder settings

Benign deviations

Let's use configurations similar to the DiFR paper:

NVIDIA A100 without tensor parallelism

NVIDIA H100 with 4-way tensor parallelism (TP-4)

NVIDIA A100 with 4-way tensor parallelism (TP-4) NOTE: this acts as the worst-case benign deviation because it combines the other benign deviations.

NOTE: this acts as the worst-case benign deviation because it combines the other benign deviations.

(optional) AMD MI300X NOTE: if the NVIDIA benign deviations are too easy to separate from malign deviations, we could also stress-test the approach on AMD. I would not expect this to work well because it changes too many things at once.

NOTE: if the NVIDIA benign deviations are too easy to separate from malign deviations, we could also stress-test the approach on AMD. I would not expect this to work well because it changes too many things at once.

NOTE: CUDA version, driver version, PyTorch version, and vLLM-Omni version may also affect the output, but probably less than the deviations listed above. The DiFR paper does not isolate these differences either; it even tests across different inference engines. I would therefore not include software-stack version changes in the experiment.

Malign deviations

For video generation, we can consider these deviations as malign:

39 denoising steps

30 denoising steps

FP8 quantized model NOTE: this may be tricky; see the note below.

NOTE: this may be tricky; see the note below.

CFG disabled NOTE: this reduces the number of forward passes by half.

NOTE: this reduces the number of forward passes by half.

Cache-DiT enabled NOTE: this is not necessarily malign by itself, since it is a VRAM/performance tradeoff, but it is useful to test whether we can distinguish it from the reference generation.

NOTE: this is not necessarily malign by itself, since it is a VRAM/performance tradeoff, but it is useful to test whether we can distinguish it from the reference generation.

different PRNG seed NOTE: the different-seed case is not a realistic cheating strategy by itself, but it is useful as a baseline because it should produce a visibly different result.

NOTE: the different-seed case is not a realistic cheating strategy by itself, but it is useful as a baseline because it should produce a visibly different result.

Note on the FP8 model: Ideally, the entire experiment should use vLLM-Omni as the inference engine so that the work can be reused in later implementation stages. However, it is not yet clear whether vLLM-Omni can run the quantized Wan2.2-T2V-A14B variant reliably. Its vLLM-Omni documentation marks Wan2.2 as "not validated" (https://docs.vllm.ai/projects/vllm-omni/en/latest/user_guide/quantization/fp8/#diffusion-model-qwen-image-wan22) .

If it cannot, there are two options:

Skip the FP8 deviation in the first round and add it once vLLM-Omni supports it.

Run only this deviation through a different inference engine, for example run Wan2.2-T2V-A14B-Diffusers-FP8 (https://huggingface.co/nvidia/Wan2.2-T2V-A14B-Diffusers-FP8) via TRT-LLM, and clearly label it as a confounded deviation because both quantization and inference engine changed.

The first option is cleaner scientifically. The second option is still useful as a practical stress test, but the result should not be interpreted as isolating the effect of quantization alone.

Dataset size

In the DiFR paper, the authors collected approximately 1 million output tokens per configuration , with 9 configurations per model . They then split the tokens in each configuration into non-overlapping batches and calculated a batch-level statistic by aggregating Token-DiFR scores. For a batch size of 10,000 tokens, this gives ~900 examples per model . For a batch size of 1,000 tokens, this gives ~9000 examples per model accordingly.

For video generation, we do not need to vary token batch sizes in the same way, because each generation has roughly the same number of frames. But we can still use this as a rough reference point for how many examples to generate for the experiment.

For each prompt, we can generate one reference video and one video for each benign and malign configuration. With one canonical configuration, 3 benign deviations, and 6 malign deviations, this means 10 generations per prompt.

Using roughly 1,000 prompts/examples would therefore produce about 10,000 video files.

There is no need to generate high-resolution videos for this experiment. We should use the minimum supported format:

832x480 resolution

81 frames at 16 fps (~5 seconds)

This is about 14 hours of generated video in total.

Artifacts to save

For each generation, we should save:

full configuration description

full generation parameters

final encoded video file

selected intermediate latents

The intermediate latents should include at least:

the initial noise latent NOTE: this is a sanity check to confirm that the fixed seed actually produces the same initial noise latent across configurations. Otherwise, we may end up measuring divergence caused by different starting noise rather than by the configuration change itself.

NOTE: this is a sanity check to confirm that the fixed seed actually produces the same initial noise latent across configurations. Otherwise, we may end up measuring divergence caused by different starting noise rather than by the configuration change itself.

the latent immediately before the high-noise to low-noise expert switch

the final latent before VAE decoding

These latent artifacts are for the experiment, not necessarily for production. They help us understand where divergence appears. If final-video perceptual comparison proves reliable, production validation can avoid storing latents. If it proves unreliable, these latent checkpoints become the fallback validation path.

The encoded video files themselves should require about 35GB of storage. The selected intermediate latents should require roughly ~125GB if stored as BF16/FP16 tensors, or ~250GB if stored as FP32 tensors. So, overall, we'd need about 200-300GB of storage.

Compute estimate

We need to run the following configurations:

H100 canonical configuration + 6 malign misconfigurations (7,000 generations)

4xH100 benign configuration with TP-4 (1,000 generations)

A100 benign configuration (1,000 generations)

4xA100 benign configuration with TP-4 (1,000 generations)

Using the official Wan2.2 T2V-A14B benchmark (https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B#computational-efficiency-on-different-gpus) as a rough estimate:

1xH100: 326.9s/video

4xH100: 91.7s/video

1xA100: 785.7s/video

4xA100: 215.2s/video

This gives:

H100: (7,000 * 326.9 + 1,000 * 91.7 * 4) / 3,600 = ~738 GPU-hours

A100: (1,000 * 785.7 + 1,000 * 215.2 * 4) / 3,600 = ~457 GPU-hours

So the total is about 1,200 GPU-hours for generation alone. To leave room for retries, debugging, failed runs, and small configuration changes, we should probably budget about 1,500 GPU-hours .