Поддержка Gonka новых модальностей помимо текста
Здравствуйте! Я изучаю возможность поддержки модели преобразования текста в видео Wan2.2-T2V-A14B в сети Gonka, и мне хотелось бы обсудить несколько возникших препятствий.
Почему именно эта модель: возможно, это лучшая на сегодняшний день модель преобразования текста в видео с открытым исходным кодом, имеющая разрешительную лицензию (Apache 2.0). LTX-2.3 сопоставим по производительности, но имеет гораздо более ограничительную пользовательскую лицензию, что может создать дополнительные ненужные препятствия.
Проверка вывода
Современные модели генерации видео SOTA преимущественно основаны на диффузионных преобразователях (DiT). В отличие от авторегрессионных преобразователей, используемых в LLM, DiT не создают окончательный результат по токенам. Вместо этого они начинают со случайного шума и неоднократно удаляют его, пока он не станет похож на конечный результат. В то время как авторегрессионные преобразователи предсказывают следующий токен, DiT прогнозируют разницу/расстояние между шумным входным сигналом и немного менее шумным выходным сигналом.
В настоящее время для проверки вывода в Gonka исполнители сохраняют logprobs для каждого сгенерированного токена, а затем валидаторы «воспроизводят» вывод и сравнивают logprobs. Это не очень хорошо сработает для DiT, потому что прогнозы намного сложнее (мы не можем просто выбрать прогноз DiT). Но что еще более важно, сравнивать эти прогнозы даже не имеет смысла, потому что в моделях SOTA результат, который мы получаем от запуска DiT, не является окончательным результатом.
В частности, в Wan2.2 DiT работает со скрытым/сжатым представлением видео, и чтобы получить реальные видеокадры, нам нужно передать это скрытое представление через декодер VAE (который по сути представляет собой сверточную нейронную сеть). Кроме того, чтобы получить окончательный видеофайл, необходимо выполнить некоторую постобработку и закодировать кадры в видеоконтейнер.
Чтобы честно проверить вывод и защититься от фальсификации, нам нужно сравнить конечный результат (фактический видеофайл, хэш которого мы храним в цепочке). К сожалению, учитывая вышесказанное, это непросто, но вот что я предлагаю:
- Я думаю, что от большей части недетерминизма можно избавиться, подав тот же случайный шум, что и на вход DiT (возможно, мы даже сможем сгенерировать его, задавая PRNG вместо сохранения входного шума в качестве артефакта на машинах-исполнителях).
- Из-за присущей графическим процессорам недетерминированности результат никогда не будет прежним, но я считаю, что он будет практически неотличим для человеческого глаза (хотя это необходимо проверить).
- Тогда возникает вопрос: «Учитывая, что видеофайл исполнителя и видеофайл валидатора сгенерированы из одного и того же скрытого шума, как мы можем сказать, что они воспринимаются одинаково?» .
Я пока не уверен, как лучше всего ответить на этот вопрос, но вот несколько идей:
- Мы можем попробовать закодировать видео исполнителя через кодировщик VAE (который вообще не используется при выводе) в скрытое представление, а затем сравнить, насколько оно близко к тому, которое мы получили во время повтора на стороне валидатора.
- Или, возможно, мы можем сравнить два видео покадрово, используя такие показатели сходства, как SSIM или PSNR.
Также стоит отметить, что если предложение TEE (https://github.com/gonka-ai/gonka/discussions/951) реализовано, то другим вариантом будет ограничение моделей преобразования текста в видео доверенными средами.
Доказательство вычислений
PoC должен быть специфичным для модели, поскольку идея состоит в том, чтобы доказать вычислительную мощность для запуска модели. Благодаря многомодельному PoC (https://github.com/gonka-ai/gonka/discussions/800) теперь можно иметь разные модели со своими собственными PoC, но проблема в том, что он по-прежнему основан на архитектуре LLM и тесно интегрирован с vLLM (https://github.com/gonka-ai/gonka/blob/main/proposals/poc/README.md) (что вполне имеет смысл, кстати).
Прежде всего, нам нужно будет адаптировать PoC на основе трансформатора к DiT (подозреваю, что это будет очень похоже на то, как это сейчас сделано в форке vLLM Gonka, но это необходимо проверить). Однако, как мы видели выше, модели генерации видео имеют более сложный конвейер, поэтому простого структурирования PoC после DiT-части архитектуры видеомодели может быть недостаточно. В отличие от LLM, которые в основном имеют один вычислительно значимый шаг (повторяющиеся прямые проходы через сеть на основе трансформатора), модели генерации видео также имеют дополнительные кодеры (в случае Wan2.2 это небольшой текстовый кодировщик (https://huggingface.co/docs/transformers/model_doc/umt5) для текстового приглашения и автокодировщик VAE) и этапы постобработки. Согласно документу Wan2.1 (https://arxiv.org/pdf/2503.20314) (см. 4.3.1 АНАЛИЗ РАБОЧЕЙ НАГРУЗКИ) на DiT приходится 85% вычислений во время обучения, поэтому можно с уверенностью предположить, что во время вывода ситуация, по крайней мере, не хуже (а, вероятно, даже лучше, например 95%+). Итак, вопрос в том, нужно ли нам вообще учитывать другие части, такие как автоэнкодер VAE? Или накладные расходы настолько малы, что мы могли бы просто игнорировать эту разницу? Я склоняюсь к последнему.
Другая проблема, конечно, заключается в том, что узлы ML работают на vLLM, который просто не поддерживает другие модальности. Кажется, что лучший вариант — использовать проект vLLM-Omni (https://github.com/vllm-project/vllm-omni), который построен на основе vLLM и поддерживает Wan2.2 (https://docs.vllm.ai/projects/recipes/en/latest/Wan-AI/Wan2.2.html). Но это по-прежнему кажется огромной задачей, и я не могу реально оценить, сколько усилий потребуется, чтобы перенести на нее узлы ML.
Ценовая политика
Когда дело доходит до LLM, ценообразование простое: мы просто взимаем плату за каждый токен. Это работает хорошо, поскольку модели являются авторегрессионными, а благодаря KV-кэшированию вычислительные затраты растут более или менее линейно с длиной последовательности.
Что касается генерации видео, у нас нет такого показателя. Хорошей новостью является то, что окончательная цена одного вывода должна быть практически одинаковой, если запрошенное разрешение, количество кадров и количество шагов шумоподавления одинаковы (независимо от подсказки). Но в отличие от моделей авторегрессии, связь между этими параметрами и необходимыми вычислительными усилиями не является линейной.
ТЛ;ДР:
- Проверка вывода кажется разрешимой, но требует некоторых экспериментов.
- Проблема доказательства вычислений немного более расплывчата, особенно в том, сколько усилий это потребует.
- Ценовая политика требует определенного внимания.
Мне очень хотелось бы услышать ваше мнение по этому поводу.
(подробнее об этом здесь: #1155 (https://github.com/gonka-ai/gonka/discussions/1155))
Наша команда недавно провела исследование возможности вывода и проверки моделей image2text; результаты можно найти здесь.
#1026 (https://github.com/gonka-ai/gonka/issues/1026)
На текущем этапе мы реализовали подход базовой проверки, аналогичный методу проверки вывода, используемому в Gonka. Следующим логическим шагом будет адаптация и расширение этого подхода специально для рабочих процессов на основе мультимодальных изображений.
В продолжение этого исследования наша команда могла бы изучить стратегии вывода и проверки для семейства речевых моделей Qwen 3, включая модель TTS из коллекции Qwen3-TTS (https://huggingface.co/collections/Qwen/qwen3-tts) и модель ASR из коллекции Qwen3-ASR (https://huggingface.co/collections/Qwen/qwen3-asr).
Для моделей ASR существующая стратегия проверки, основанная на сравнении логарифмических вероятностей Top-N, вероятно, может быть повторно использована с минимальной адаптацией, поскольку выходные данные остаются основанными на токенах и достаточно детерминированными для достоверной оценки и проверок воспроизводимости.
Однако проверка TTS потребует отдельного исследования, поскольку на выходе будет непрерывный звук, а не отдельные токены. Можно изучить несколько направлений валидации:
Проверка на основе спектрограммы:
- Преобразуйте сгенерированный звук в спектрограммы Mel или спектрограммы log-Mel и сравните их с эталонными выходными данными.
- Используйте метрики сходства, такие как косинусное сходство, MSE, SSIM или расстояние восприятия между внедрениями спектрограмм.
- Спектрограммы можно хранить в сжатом формате NumPy (.npz) или в сериализованных тензорах для эффективного автономного сравнения и регрессионного тестирования.
Круговая проверка: (требуется дополнительный этап вывода, более дорогой)
- Пропустите сгенерированный звук TTS через модель ASR и сравните восстановленный текст с исходным приглашением.
- Такие показатели, как WER/CER, могут обеспечить косвенную проверку разборчивости и стабильности.
Показатели качества звука:
- Оцените объективные показатели, такие как PESQ (https://lightning.ai/docs/torchmetrics/stable/audio/perceptual_evaluation_speech_quality.html), STOI (https://lightning.ai/docs/torchmetrics/stable/audio/short_time_objective_intelligibility.html), SI-SDR. (https://lightning.ai/docs/torchmetrics/stable/audio/scale_invariant_signal_distortion_ratio.html) или DNSMOS (https://lightning.ai/docs/torchmetrics/stable/audio/deep_noise_suppression_mean_opinion_score.html), где это применимо.
- Эти метрики могут помочь обнаружить ухудшение, вызванное квантованием, изменениями в серверной части или оптимизацией вывода.
Привет @fedor-konovalенко (https://github.com/fedor-konovalенко), мы тоже рассматривали ASR (преобразование речи в текст) для Gonka и только что написали предложение: #1335 (https://github.com/gonka-ai/gonka/discussions/1335). Вы упомянули здесь семейство речи Qwen3, и, судя по нашим предварительным исследованиям, оно явно пересекается с тем, что вы делаете, из-за особенностей архитектуры. Вы уже работаете над ASR или он еще открыт?
Привет!
Нет, мы еще не приступили к реализации; мы все еще обсуждаем планы и расставляем приоритеты. Буду рад сотрудничеству и сотрудничеству. Я прочитал ваше предложение, оно очень хорошо продумано. Мы действительно можем начать с моделей, совместимых с существующим механизмом проверки. Затем мы можем распределить задачи по ASR, чтобы избежать дублирования одних и тех же областей.
@ivan-smetannikov-serokell (https://github.com/ivan-smetannikov-serokell)
Отлично, спасибо за подтверждение! На следующей неделе мы разберемся с некоторыми вопросами и свяжемся с вами, чтобы вместе разработать план.
А как насчет PoC для этих случаев?
Полного дизайна пока нет, просто хотел еще раз подтвердить, что эта задача все еще доступна. Но мы считаем, что PoC должен в основном повторно использовать спринт: случайные встраивания с одинаковым заполнением, просто проходящие через слои модели ASR/TTS, теоретически это должно работать для авторегрессионных моделей. Для Qwen3-ASR это немного проще, чем Whisper (из-за тяжелого аудиокодера), поэтому мы можем начать с него, чтобы проверить почву, а затем двигаться дальше с другими.
Я хотел бы начать обсуждение того, как мы разрабатываем gonka для поддержки новых модальностей в сети, таких как преобразование речи в текст, понимание изображений, создание видео и т. д.
Основными задачами любой новой модальности являются:
Как проверить вывод в этой модальности
Как запустить PoC на основе этой модальности
- Какую нагрузку может создать новая модальность в сети, включая интернет-трафик, хранилище, нагрузку на блокчейн и т. д.
Я бы предложил использовать это обсуждение как бесплатный чат по этому поводу, возможные идеи и агрегатор предложений.
Здравствуйте! Я изучаю возможность поддержки модели преобразования текста в видео Wan2.2-T2V-A14B в сети Gonka, и мне хотелось бы обсудить несколько возникших препятствий.
Почему именно эта модель: возможно, это лучшая на сегодняшний день модель преобразования текста в видео с открытым исходным кодом, имеющая разрешительную лицензию (Apache 2.0). LTX-2.3 сопоставим по производительности, но имеет гораздо более ограничительную пользовательскую лицензию, что может создать дополнительные ненужные препятствия.
Проверка вывода
Современные модели генерации видео SOTA преимущественно основаны на диффузионных преобразователях (DiT). В отличие от авторегрессионных преобразователей, используемых в LLM, DiT не создают окончательный результат по токенам. Вместо этого они начинают со случайного шума и неоднократно удаляют его, пока он не станет похож на конечный результат. В то время как авторегрессионные преобразователи предсказывают следующий токен, DiT прогнозируют разницу/расстояние между шумным входным сигналом и немного менее шумным выходным сигналом.
В настоящее время для проверки вывода в Gonka исполнители сохраняют logprobs для каждого сгенерированного токена, а затем валидаторы «воспроизводят» вывод и сравнивают logprobs. Это не очень хорошо сработает для DiT, потому что прогнозы намного сложнее (мы не можем просто выбрать прогноз DiT). Но что еще более важно, сравнивать эти прогнозы даже не имеет смысла, потому что в моделях SOTA результат, который мы получаем от запуска DiT, не является окончательным результатом.
В частности, в Wan2.2 DiT работает со скрытым/сжатым представлением видео, и чтобы получить реальные видеокадры, нам нужно передать это скрытое представление через декодер VAE (который по сути представляет собой сверточную нейронную сеть). Кроме того, чтобы получить окончательный видеофайл, необходимо выполнить некоторую постобработку и закодировать кадры в видеоконтейнер.
Чтобы честно проверить вывод и защититься от фальсификации, нам нужно сравнить конечный результат (фактический видеофайл, хэш которого мы храним в цепочке). К сожалению, учитывая вышесказанное, это непросто, но вот что я предлагаю:
- Я думаю, что от большей части недетерминизма можно избавиться, подав тот же случайный шум, что и на вход DiT (возможно, мы даже сможем сгенерировать его, задавая PRNG вместо сохранения входного шума в качестве артефакта на машинах-исполнителях).
- Из-за присущей графическим процессорам недетерминированности результат никогда не будет прежним, но я считаю, что он будет практически неотличим для человеческого глаза (хотя это необходимо проверить).
- Тогда возникает вопрос: «Учитывая, что видеофайл исполнителя и видеофайл валидатора сгенерированы из одного и того же скрытого шума, как мы можем сказать, что они воспринимаются одинаково?» .
Я пока не уверен, как лучше всего ответить на этот вопрос, но вот несколько идей:
- Мы можем попробовать закодировать видео исполнителя через кодировщик VAE (который вообще не используется при выводе) в скрытое представление, а затем сравнить, насколько оно близко к тому, которое мы получили во время повтора на стороне валидатора.
- Или, возможно, мы можем сравнить два видео покадрово, используя такие показатели сходства, как SSIM или PSNR.
Также стоит отметить, что если предложение TEE (https://github.com/gonka-ai/gonka/discussions/951) реализовано, то другим вариантом будет ограничение моделей преобразования текста в видео доверенными средами.
Доказательство вычислений
PoC должен быть специфичным для модели, поскольку идея состоит в том, чтобы доказать вычислительную мощность для запуска модели. Благодаря многомодельному PoC (https://github.com/gonka-ai/gonka/discussions/800) теперь можно иметь разные модели со своими собственными PoC, но проблема в том, что он по-прежнему основан на архитектуре LLM и тесно интегрирован с vLLM (https://github.com/gonka-ai/gonka/blob/main/proposals/poc/README.md) (что вполне имеет смысл, кстати).
Прежде всего, нам нужно будет адаптировать PoC на основе трансформатора к DiT (подозреваю, что это будет очень похоже на то, как это сейчас сделано в форке vLLM Gonka, но это необходимо проверить). Однако, как мы видели выше, модели генерации видео имеют более сложный конвейер, поэтому простого структурирования PoC после DiT-части архитектуры видеомодели может быть недостаточно. В отличие от LLM, которые в основном имеют один вычислительно значимый шаг (повторяющиеся прямые проходы через сеть на основе трансформатора), модели генерации видео также имеют дополнительные кодеры (в случае Wan2.2 это небольшой текстовый кодировщик (https://huggingface.co/docs/transformers/model_doc/umt5) для текстового приглашения и автокодировщик VAE) и этапы постобработки. Согласно документу Wan2.1 (https://arxiv.org/pdf/2503.20314) (см. 4.3.1 АНАЛИЗ РАБОЧЕЙ НАГРУЗКИ) на DiT приходится 85% вычислений во время обучения, поэтому можно с уверенностью предположить, что во время вывода ситуация, по крайней мере, не хуже (а, вероятно, даже лучше, например 95%+). Итак, вопрос в том, нужно ли нам вообще учитывать другие части, такие как автоэнкодер VAE? Или накладные расходы настолько малы, что мы могли бы просто игнорировать эту разницу? Я склоняюсь к последнему.
Другая проблема, конечно, заключается в том, что узлы ML работают на vLLM, который просто не поддерживает другие модальности. Кажется, что лучший вариант — использовать проект vLLM-Omni (https://github.com/vllm-project/vllm-omni), который построен на основе vLLM и поддерживает Wan2.2 (https://docs.vllm.ai/projects/recipes/en/latest/Wan-AI/Wan2.2.html). Но это по-прежнему кажется огромной задачей, и я не могу реально оценить, сколько усилий потребуется, чтобы перенести на нее узлы ML.
Ценовая политика
Когда дело доходит до LLM, ценообразование простое: мы просто взимаем плату за каждый токен. Это работает хорошо, поскольку модели являются авторегрессионными, а благодаря KV-кэшированию вычислительные затраты растут более или менее линейно с длиной последовательности.
Что касается генерации видео, у нас нет такого показателя. Хорошей новостью является то, что окончательная цена одного вывода должна быть практически одинаковой, если запрошенное разрешение, количество кадров и количество шагов шумоподавления одинаковы (независимо от подсказки). Но в отличие от моделей авторегрессии, связь между этими параметрами и необходимыми вычислительными усилиями не является линейной.
ТЛ;ДР:
- Проверка вывода кажется разрешимой, но требует некоторых экспериментов.
- Проблема доказательства вычислений немного более расплывчата, особенно в том, сколько усилий это потребует.
- Ценовая политика требует определенного внимания.
Мне очень хотелось бы услышать ваше мнение по этому поводу.
(подробнее об этом здесь: #1155 (https://github.com/gonka-ai/gonka/discussions/1155))
Наша команда недавно провела исследование возможности вывода и проверки моделей image2text; результаты можно найти здесь.
#1026 (https://github.com/gonka-ai/gonka/issues/1026)
На текущем этапе мы реализовали подход базовой проверки, аналогичный методу проверки вывода, используемому в Gonka. Следующим логическим шагом будет адаптация и расширение этого подхода специально для рабочих процессов на основе мультимодальных изображений.
В продолжение этого исследования наша команда могла бы изучить стратегии вывода и проверки для семейства речевых моделей Qwen 3, включая модель TTS из коллекции Qwen3-TTS (https://huggingface.co/collections/Qwen/qwen3-tts) и модель ASR из коллекции Qwen3-ASR (https://huggingface.co/collections/Qwen/qwen3-asr).
Для моделей ASR существующая стратегия проверки, основанная на сравнении логарифмических вероятностей Top-N, вероятно, может быть повторно использована с минимальной адаптацией, поскольку выходные данные остаются основанными на токенах и достаточно детерминированными для достоверной оценки и проверок воспроизводимости.
Однако проверка TTS потребует отдельного исследования, поскольку на выходе будет непрерывный звук, а не отдельные токены. Можно изучить несколько направлений валидации:
Проверка на основе спектрограммы:
- Преобразуйте сгенерированный звук в спектрограммы Mel или спектрограммы log-Mel и сравните их с эталонными выходными данными.
- Используйте метрики сходства, такие как косинусное сходство, MSE, SSIM или расстояние восприятия между внедрениями спектрограмм.
- Спектрограммы можно хранить в сжатом формате NumPy (.npz) или в сериализованных тензорах для эффективного автономного сравнения и регрессионного тестирования.
Круговая проверка: (требуется дополнительный этап вывода, более дорогой)
- Пропустите сгенерированный звук TTS через модель ASR и сравните восстановленный текст с исходным приглашением.
- Такие показатели, как WER/CER, могут обеспечить косвенную проверку разборчивости и стабильности.
Показатели качества звука:
- Оцените объективные показатели, такие как PESQ (https://lightning.ai/docs/torchmetrics/stable/audio/perceptual_evaluation_speech_quality.html), STOI (https://lightning.ai/docs/torchmetrics/stable/audio/short_time_objective_intelligibility.html), SI-SDR. (https://lightning.ai/docs/torchmetrics/stable/audio/scale_invariant_signal_distortion_ratio.html) или DNSMOS (https://lightning.ai/docs/torchmetrics/stable/audio/deep_noise_suppression_mean_opinion_score.html), где это применимо.
- Эти метрики могут помочь обнаружить ухудшение, вызванное квантованием, изменениями в серверной части или оптимизацией вывода.
Привет @fedor-konovalенко (https://github.com/fedor-konovalенко), мы тоже рассматривали ASR (преобразование речи в текст) для Gonka и только что написали предложение: #1335 (https://github.com/gonka-ai/gonka/discussions/1335). Вы упомянули здесь семейство речи Qwen3, и, судя по нашим предварительным исследованиям, оно явно пересекается с тем, что вы делаете, из-за особенностей архитектуры. Вы уже работаете над ASR или он еще открыт?
Привет!
Нет, мы еще не приступили к реализации; мы все еще обсуждаем планы и расставляем приоритеты. Буду рад сотрудничеству и сотрудничеству. Я прочитал ваше предложение, оно очень хорошо продумано. Мы действительно можем начать с моделей, совместимых с существующим механизмом проверки. Затем мы можем распределить задачи по ASR, чтобы избежать дублирования одних и тех же областей.
@ivan-smetannikov-serokell (https://github.com/ivan-smetannikov-serokell)
Отлично, спасибо за подтверждение! На следующей неделе мы разберемся с некоторыми вопросами и свяжемся с вами, чтобы вместе разработать план.
А как насчет PoC для этих случаев?
Полного дизайна пока нет, просто хотел еще раз подтвердить, что эта задача все еще доступна. Но мы считаем, что PoC должен в основном повторно использовать спринт: случайные встраивания с одинаковым заполнением, просто проходящие через слои модели ASR/TTS, теоретически это должно работать для авторегрессионных моделей. Для Qwen3-ASR это немного проще, чем Whisper (из-за тяжелого аудиокодера), поэтому мы можем начать с него, чтобы проверить почву, а затем двигаться дальше с другими.
I'd like to start a discussion on how we develop gonka to support new modalities on the network, like speech-to-text, image understanding, video generation etc.
The core tasks for any new modality are:
How to validate inference in this modality
How to run PoC based on this modality
- How much load a new modality can create on the network including internet traffic, storage, blockchain load etc.
I'd suggest to use this discussion as free chat on this, possible ideas and aggregator of proposals.
Hello! I'm exploring the possibility of supporting the Wan2.2-T2V-A14B text-to-video model on the Gonka network, and I'd like to discuss a few obstacles that came up.
Why this model in particular: it's arguably 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.
Inference validation
Current SOTA video generation models are predominantly based on diffusion transformers (DiTs). Unlike autoregressive transformers used in LLMs, DiTs don't build the final result token-by-token. Instead, they start with random noise and repeatedly de-noise 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.
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 (we can't just sample the DiTs prediction). More importantly, though, it doesn't even make sense to compare these predictions because in SOTA models the result we get from running the DiT is not the final result.
Specifically, in Wan2.2, DiT 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 (the actual video file which hash we store on-chain). Unfortunately, given the above, it's not straightforward, but here's what I propose:
- I think it should be possible to get rid of most of the nondeterminism by supplying the same random noise as input to DiT (maybe we can even generate it by seeding PRNG instead of storing the input noise as an artifact on executor machines).
- Due to inherent nondeterminism of GPUs the result will never be the same, but I believe it will be virtually non-distinguishable to a human eye (this needs to be checked, though).
- Then, the question becomes "Given the executor's video file, and the validator's video file generated from the same noisy latent, how can we tell that they are perceptually the same?" .
I'm not sure yet what's the best way to answer this question, but here are some ideas:
- We can try encoding the executor's video via VAE encoder (which is not used during inference at all) into the latent representation, then compare how close it is to the one we got during the replay on the validator's side.
- Or, perhaps, we can compare the two videos frame-by-frame using similarity metrics such as SSIM or PSNR.
It's also worth mentioning that is TEE proposal (https://github.com/gonka-ai/gonka/discussions/951) is implemented, then another option would be limiting text-to-video models to the trusted environments.
Proof-of-Compute
PoC should be specific to the model because the idea is to prove the computational capacity to run the model. Thanks to multi-model PoC (https://github.com/gonka-ai/gonka/discussions/800) it's now possible to have different models with their own PoCs, but the problem is that it's still based on the LLMs architecture and is tightly integrated into vLLM (https://github.com/gonka-ai/gonka/blob/main/proposals/poc/README.md) (which totally makes sense, by the way).
First of all, we would need to adapt the transformer-based PoC to DiTs (I suspect it'd be very similar to how it's currently done in the Gonka's vLLM fork, but this needs to be checked). However, as we saw above, video generation models have a more complex pipeline, so simply structuring PoC after the DiT part of the video model architecture may not be enough. Unlike LLMs that basically have a single computationally significant step (repeated forward passes through the transformer-based network), video generation models also have additional encoders (in case of Wan2.2 it's a small text encoder (https://huggingface.co/docs/transformers/model_doc/umt5) for the text prompt, and the VAE autoencoder) and post-processing steps. According to the Wan2.1 paper (https://arxiv.org/pdf/2503.20314) (see 4.3.1 WORKLOAD ANALYSIS ) DiT accounts to 85% of computation during training, so it's safe to assume that during inference the situation is at the very least not worse (and likely even better, e.g. 95%+). So, the question is, do we even need to account for other parts such as VAE autoencoder? Or is the overhead so small that we could simply disregard this difference? I'm leaning towards the latter.
Another issue, of course, is the fact that ML nodes run on vLLM which simply doesn't support other modalities. It seems that the best option is to make use of the vLLM-Omni (https://github.com/vllm-project/vllm-omni) project which is built on top of vLLM and supports Wan2.2 (https://docs.vllm.ai/projects/recipes/en/latest/Wan-AI/Wan2.2.html) . But it still seems like a huge undertaking and I can't realistically estimate how much effort would it take to migrate ML nodes to this.
Pricing policy
When it comes to LLMs, pricing is straightforward: we simply charge per token. This works well because the models are autoregressive and, thanks to KV caching, the computational effort grows more or less linearly with the sequence length.
With video generation, we don't have such a metric. The good news is that the final price of a single inference should be pretty much the same if the requested resolution, frame count, and the number of de-noising steps is the same (no matter the prompt). But unlike with autoregressive models, the relationship between these parameters and the needed computational effort is not linear.
TL;DR:
- Inference validation seems solvable, but needs some experimentation.
- Proof-of-Compute issue is a bit more vague, especially in how much effort it'd take.
- Pricing policy needs some consideration.
I'd very much like to hear your opinions on this.
(expanded on this here: #1155 (https://github.com/gonka-ai/gonka/discussions/1155) )
Our team recently conducted research into the feasibility of inference and validation for image2text models; the results can be found here.
#1026 (https://github.com/gonka-ai/gonka/issues/1026)
At the current stage, we have implemented a baseline validation approach similar to the inference validation method used in Gonka. The next logical step would be to adapt and extend this approach specifically for multimodal image-based workflows.
As a continuation of this research, our team could explore inference and validation strategies for the Qwen 3 speech models family, including the TTS model from Qwen3-TTS Collection (https://huggingface.co/collections/Qwen/qwen3-tts) and the ASR model from Qwen3-ASR Collection (https://huggingface.co/collections/Qwen/qwen3-asr) .
For ASR models, the existing validation strategy based on Top-N log-probability comparison could likely be reused with minimal adaptation, since the output remains token-based and deterministic enough for confidence estimation and reproducibility checks.
TTS validation, however, would require separate research because the output is continuous audio rather than discrete tokens. Several validation directions could be investigated:
Spectrogram-based validation:
- Convert generated audio into Mel spectrograms or log-Mel spectrograms and compare them against reference outputs.
- Use similarity metrics such as cosine similarity, MSE, SSIM, or perceptual distance between spectrogram embeddings.
- Spectrograms could be stored in compressed NumPy (.npz) format or serialized tensors for efficient offline comparison and regression testing.
Round-trip validation: (additional inference step is needed, more expensive)
- Pass generated TTS audio through an ASR model and compare the reconstructed text against the original prompt.
- Metrics such as WER/CER could provide indirect validation of intelligibility and stability.
Audio quality metrics:
- Evaluate objective metrics such as PESQ (https://lightning.ai/docs/torchmetrics/stable/audio/perceptual_evaluation_speech_quality.html) , STOI (https://lightning.ai/docs/torchmetrics/stable/audio/short_time_objective_intelligibility.html) , SI-SDR (https://lightning.ai/docs/torchmetrics/stable/audio/scale_invariant_signal_distortion_ratio.html) , or DNSMOS (https://lightning.ai/docs/torchmetrics/stable/audio/deep_noise_suppression_mean_opinion_score.html) where applicable.
- These metrics may help detect degradation caused by quantization, backend changes, or inference optimizations.
Hi @fedor-konovalenko (https://github.com/fedor-konovalenko) , we've been looking at ASR (speech-to-text) for Gonka too, and just wrote up a proposal: #1335 (https://github.com/gonka-ai/gonka/discussions/1335) . You mentioned the Qwen3 speech family here, and from our pre-research it clearly overlaps with what you're doing due to the architectural specifics. Are you already working on ASR, or is it still open?
Hi!
No, we haven't started implementation yet; we're still discussing plans and setting priorities. I'd be happy to collaborate and work together. I read your proposal, it's very well thought out. We can indeed start with models that are compatible with the existing validation mechanism. We can then distribute tasks across ASR to avoid duplicating the same areas.
@ivan-smetannikov-serokell (https://github.com/ivan-smetannikov-serokell)
Nice, thanks for the confirmation! We'll sort a few things out on our side next week and get back to you to work out the plan together then.
And what about PoC for these cases?
No full design yet, just wanted to re-confirm that this task is still available. But we think PoC should mostly reuse the sprint: same seeded random embeddings, just run through the ASR/TTS model's layers, in theory it should work for autoregressive models. For Qwen3-ASR it is a bit simpler than Whisper (due to the heavy audio encoder), so we can start with it to test the waters and then move forward with others.
Я хотел бы начать обсуждение того, как мы разрабатываем gonka для поддержки новых модальностей в сети, таких как преобразование речи в текст, понимание изображений, создание видео и т. д.
Основными задачами любой новой модальности являются:
Как проверить вывод в этой модальности
Как запустить PoC на основе этой модальности
Я бы предложил использовать это обсуждение как бесплатный чат по этому поводу, возможные идеи и агрегатор предложений.