Добавить поддержку speech-to-text (ASR) моделей

Привет. Мы — команда Serokell (https://serokell.io), и мы хотели бы заняться интеграцией ASR (преобразование речи в текст). Мы рассматриваем это предложение специально для ASR (TTS — это отдельная проблема, и мы оставляем ее здесь в стороне). Ниже: почему ASR хорошо подходит и какие модели, где проверка вывода затруднена, влияние PoC и сетевой нагрузки, а также предлагаемый нами план.

Почему ASR и какие модели

ASR — хорошая первая аудиомодальность для Gonka по трем причинам. Во-первых, насколько нам известно, сегодня ни одна децентрализованная сеть не предлагает стимулирующий ASR, поэтому слот выглядит открытым, а транскрипция является устоявшимся коммерческим рынком. Во-вторых, это добавляется к аппаратному обеспечению, которое уже работает в сети: модели ASR являются более легкими по сравнению с текущими LLM, поэтому графический процессор класса центра обработки данных обеспечивает транскрипцию с высокой пропускной способностью, что делает ASR новой модальностью и источником дохода на уже работающих аппаратных хостах. Дополнительным преимуществом является то, что относительно однородный парк серверов и графических процессоров потенциально облегчает вопрос межаппаратной стабильности журналов, поскольку большинство честных повторов происходит на одном и том же кристалле. И если сеть когда-либо расширится за счет более мелких моделей, малая занимаемая площадь ASR будет проще для новых хостов. В-третьих, выходные данные представляют собой последовательность токенов, которая является предварительным условием для повторного использования проверки logprob-distance в Gonka вообще.

Этот третий пункт несет в себе архитектурное ограничение, о котором следует четко говорить. Современный ASR делится на три семейства:

• Авторегрессионный кодер-декодер (Whisper): аудиокодер conv+transformer использует спектрограмму log-Mel, а декодер-трансформер авторегрессионно генерирует текстовые токены посредством перекрестного внимания. Существуют пробные журналы для каждого токена, и принуждение учителей четко определено. Это семейство совместимо с текущим потоком проверки.

• Audio-LLM (Qwen3-ASR, Voxtral): аудиокодер + адаптер проецирует звук в пространство встраивания стандартного LLM, предназначенного только для декодера, который затем декодирует текст. Выходная сторона — обычный LLM-декодер. Это семейство также совместимо с проверкой.

• Преобразователи CTC/RNN-T/TDT (NVIDIA Parakeet/Canary): кадрово-синхронное декодирование по решетке выравнивания с преобладанием пробелов, без распределения по текстовым токенам, обусловленного предшествующим текстом. Это самые быстрые модели в таблицах лидеров (RTFx ~ 2700–3400, в 10–100 раз больше семейств AR), но они несовместимы с текущими требованиями учителей по принудительному_токенам. Для их проверки потребуется другая метрика (оценка решетки/принудительного выравнивания), то есть отдельная исследовательская работа, выходящая за рамки, по крайней мере, на данный момент.

Таким образом, самая быстрая архитектура ASR — это именно та, которую Gonka не может дешево проверить. Наши рекомендуемые кандидаты на данный момент — Qwen3-ASR-1.7B в качестве основной цели (точность открытия SOTA, ~1,6%/3,4% WER на LibriSpeech test-clean/test-other, Apache-2.0, поддерживаемая конечной точкой транскрипции vLLM и декодер в стиле LLM, который соответствует существующему механизму проверки) и Whisper-large-v3 в качестве открытой базовой версии (MIT, широко используемый, ~2,0%/3,6% WER) для пороговой калибровки между графическими процессорами, которую более широкое сообщество может воспроизвести независимо. Теоретически один порт Enforced_tokens охватывает обе модели, поскольку обе являются моделями авторегрессионного декодера. Если более полное заполнение большого графического процессора является приоритетом, существуют более тяжелые аудио-LLM, такие как Voxtral-Small-24B, хотя лидеры по точности невелики, поэтому лучшим использованием большого оборудования здесь является высокая пакетная пропускная способность.

Валидация

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

Сегодня существует только обслуживающий уровень. Форк Gonka vLLM уже включает модуль voice_to_text/, реализующий /v1/audio/transcriptions , но это исходный код vLLM. Таким образом, вы можете предоставить стенограмму, но не хватает всего, что превращает обслуживание в модальность сети Gonka: запуск модели и доказательство ее честного запуска, перенаправление к ней платных запросов и вознаграждение за работу:

• Проверка: в этом вся суть. Gonka проверяет вывод, воспроизводя его с принудительной форсировкой учителя_tokens и сравнивая распределения logprob, но эта инфраструктура (vllm/validation.py, переопределение сэмплера в vllm/v1/sample/, переключатель logprobs_mode) подключена только к путиchat_completion/. Он не был портирован в voice_to_text/serving.py. Итак, сегодня вы можете предоставить стенограмму, но не можете доказать, что исполнитель действительно запустил модель, а модальность, которую вы не можете проверить, не может быть ненадежной.

• DAPI: нет пути аудиозапроса (нет маршрута, обработки полезной нагрузки или расчетной проводки для аудио), поэтому разработчик вообще не может отправить платный проверенный аудиозапрос.

• В цепочке: нет ModelType (перечисление категорий, LLM, VLM или ASR, обозначающее, какой путь обслуживания/проверки использует модель; поле имени модели уже существует отдельно), нет регистрации модели, нет соглашения о ценах на аудио.

Поскольку модуль voice_to_text/serving и строительные блоки Enforced_tokens (в пути чата) уже существуют, обслуживающая сторона на месте, и работа заключается в добавлении проверки Gonka поверх нее.

Безопасность проверки logprob Gonka основана на свойстве, которое мы наблюдаем на практике: для развернутых LLM/VLM распределение logprob по токенам от честного оборудования воспроизводится в пределах жесткого, калиброванного допуска, в то время как узел, пропустивший вычисления, не может его воспроизвести. ASR усложняет гарантию воспроизводимости, и проблема заключается на стороне ввода: аудиовход сначала проходит через аппаратно-чувствительный конвейер с плавающей запятой, прежде чем будет создан какой-либо logprob.

Текстовые входные данные LLM — это идентификаторы токенов: дискретные, точно воспроизводимые. Входные данные ASR — это необработанный звук, который проходит через интерфейс с большим количеством операций с плавающей запятой, которого нет в текстовых моделях: декодирование/ресэмплирование -> мел-спектрограмма -> сверточный стебель -> аудиокодер преобразователя -> перекрестное внимание на декодер. Каждый этап выполняется с плавающей запятой и чувствителен к архитектуре (свертки и сокращения cuDNN не идентичны по битам для разных поколений графических процессоров или форм пакетов). Enforced_tokens закрепляет путь токена декодера, но ничего не делает с кодировщиком. Таким образом, оставшаяся разница в измерении расстояния L1 валидатора для ASR составляет:

Различия с плавающей запятой декодера + разницы с плавающей запятой кодера/интерфейсного интерфейса, переносимые через перекрестное внимание.

Для текста этот второй член структурно равен нулю (текстовая модель не имеет кодировщика и предварительной обработки входных данных с плавающей запятой, поэтому перед декодером ничего не может отличаться), поэтому результат LLM «устанавливается». Для ASR оно присутствует и неизмеримо. Существует прямой прецедент: это тот же класс проблем, который, как показала работа VLM, можно решить: VLM имеет визуальный кодировщик с тем же символом, а тесты #1026 (https://github.com/gonka-ai/gonka/issues/1026)/PR #1150 (https://github.com/gonka-ai/gonka/pull/1150) сообщают об обнаружении мошенничества примерно на 99%. Две вещи также работают в нашу пользу: перекрестное внимание усредняется по многим позициям кодировщика, что уменьшает небольшие различия между кодировщиками, а в конструкции аудио-LLM выходной сигнал кодера проходит через весь стек LLM и повторно нормализуется на каждом уровне. Это причины ожидать, что честное разброс между графическими процессорами будет небольшим, но это аргументы в пользу того, как работает модель, и это число еще предстоит измерить. Измерение честного разброса logprob между графическими процессорами (и подтверждение того, что он остается ниже того, что достигает дешевая подделка) решает, жизнеспособн ли весь подход, и это первое, что мы должны сделать.

Проблема канонизации ввода. Аудио не имеет канонической формы байтов: один и тот же звук, как WAV, так и MP3, с разными частотами дискретизации дает разные байты и разные функции мелирования. Два честных узла, которые декодируют/пересчитывают по-разному, будут подавать в модель разные аудио и не соглашаться, создавая именно ту разницу, которую валидатор должен воспринимать как мошенничество. Таким образом, протокол должен требовать канонического ввода перед хешированием и перед моделью: декодировать в фиксированный формат (например, 16 кГц моно PCM) с закрепленным алгоритмом передискретизации и закрепленными параметрами mel, хешировать канонический PCM (а не отправленный контейнер) и распределять этот артефакт как по исполнителю, так и по валидатору. Для ввода текста этот шаг никогда не требовался.

Одно конкретное осложнение Шепота. Шепот разделяет длинный звук на границах тишины; разное оборудование может располагаться в разных точках разделения из-за округления FP при обнаружении тишины, что изменяет границы фрагментов и нарушает принуждение учителя. Исправление: сохраняйте явные временные метки фрагментов в полезных данных, чтобы валидатор воспроизводился с идентичными границами вместо повторного запуска обнаружения тишины.

Наш подход: расширить существующую проверку logprob на аудио. Мы сохраняем текущий метод доказательства вычислений Gonka: CompareLogits, конвейер калибровки SPRT и значение validation_threshold для каждой модели — все применяются без изменений. Здесь есть две работы:

• Изменение кода: перенос принудительного преподавания Enforced_tokens на путь кодер-декодер. Это отражает существующую реализацию пути чата и имеет хорошую область применения.

• Эмпирическое исследование по установке validation_threshold. Порог должен быть измерен эмпирически. Мы запускаем обе модели-кандидаты на нескольких типах графических процессоров, расшифровываем набор речевых данных под принуждением учителя, собираем распределения logprob для каждого токена, измеряем, насколько далеко расходится честное оборудование (диапазон честности), генерируем сценарии мошенничества (меньшая/квантованная/неправильная модель), чтобы получить диапазон мошенничества, и запускаем калибровку SPRT, чтобы найти порог, который разделяет эти две модели, если таковой существует. Это более масштабная из двух задач, которая несет в себе наибольший риск; это то, что охватывает Фаза 1 ниже.

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

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

PoC не нуждается в новой инфраструктуре: многомодельная инфраструктура PoC ( PoCModelConfig ) уже не зависит от модальности.

Фаза 1 (без новой инфраструктуры). Хосты ASR выполняют существующий спринт PoC точно так же, как это делают сегодня хосты VLM. Возможности ASR доказываются путем проверки вывода. Это позволит включить ASR в цепочку без какой-либо новой работы PoC.

Фаза 2 (отдельный GIP, позже): спринт, ориентированный на аудио, который отражает сегодняшний спринт по генерации токенов: в фиксированном временном окне хост расшифровывает как можно больше эталонного аудио, а пропускная способность измеряется и проверяется так же, как и текущий спринт (как мы понимаем текущий PoC), поэтому хост не может просто сообщить об этом самостоятельно. Эталонный звук должен быть непредсказуемым (например, полученным из хеша недавнего блока и вращающимся в каждой эпохе), чтобы его нельзя было предварительно расшифровать и кэшировать. PoCModelConfig.seq_len можно изменить в зависимости от длины клипа. Формула веса также должна учитывать форму пропускной способности ASR: у кодера фиксированная стоимость за 30-секундное окно, а у декодера масштабирование в зависимости от длины транскрипта. Это остается открытым вопросом проектирования Фазы 2.

Блокчейн и нагрузка на сеть

Ончейн: практически не изменился. Мы не помещаем в цепочку аудио, только существующие хеши/коммитты. Изменение протокола вывода не требуется, если мы используем синтетическое количество токенов: Prompt_token_count = ceil(duration_секунды × 50) . Цены и ограничитель пропускной способности работают без изменений в соответствии с этим соглашением, а условное депонирование соответствует существующей модели devshard: разработчик депонирует заранее, при необходимости делает выводы относительно хостов devshard, затем производит расчет и возвращает остаток. Звук движется по тому же принципу, если его цена определяется по продолжительности. Никаких изменений в model.proto также не требуется: модель может быть помечена как ASR по соглашению (флаг транскрипции --task в model_args плюс тип аудиоконтента в сохраненной полезной нагрузке), и именно так валидатор будет знать, что нужно воспроизвести по пути аудио, а не по пути чата. Насколько мы можем судить, именно так сегодня обращаются с VLM. Перечисление ModelType в model.proto было бы более чистым и явным способом пометить его (и в то же время правильно пометить VLM) за счет изменения прототипа и миграции состояния, но необязательно.

Офчейн: нагрузка растет. Аудио-полезные данные намного тяжелее текстовых, поэтому увеличивается как объем памяти, так и трафик. Мы будем хранить аудио в хранилище объектов с адресацией по содержимому (гибридный бэкэнд в Managed_storage.go уже поддерживает это); при размерах аудио встроенный Postgres BYTEA будет раздувать таблицы. Валидаторы извлекают аудиобайты только для тех выводов, которые они фактически проверяют. При типичной частоте выборки при проверке (~ 5–10%) объем за эпоху остается управляемым; Увеличение размера полезной нагрузки — это главное, что нужно планировать.

DAPI — самое сложное изменение инфраструктуры. Аудио использует multipart/form-data (двоичную загрузку), тогда как чат использует application/json, поэтому ему нужен новый post_audio_handler.go; метод ModifyRequestBody(), ориентированный на JSON, не охватывает составные части. Прокси-сервер MLNode уже дословно пересылает каждый путь /v1/*, поэтому никаких изменений здесь не требуется. Путь devshard требует одинаковой обработки в аналогичной области: валидаторы цепочки и devshard используют одну среду выполнения (shared_runtime.go), поэтому ветвь проверки звука записывается один раз для обоих, а в противном случае devshard просто нужна новая модель и ее цена на основе продолжительности, следуя текущему потоку.

Предлагаемый план

Мы хотели бы собрать для этого команду и перейти от исследований к интеграции. Предварительный план:

• Сначала исследуйте и снижайте риски. Запустите эксперимент по стабильности logprob между графическими процессорами, который решит, работает ли подход logprob для ASR: запустите Qwen3-ASR-1.7B и Whisper-large-v3 для всех типов графических процессоров парка под принуждением учителя, измерьте, насколько честные прогоны расходятся с тем, что дает более дешевая/неправильная модель, и проверьте, разделяет ли их единый порог. Определите порог проверки, контракт канонизации ввода и окончательный выбор модели. Это основной решающий эксперимент, он не требует изменений в форке или протоколе, и мы опубликуем результаты, прежде чем переходить к остальным.

• Реализуйте дизайн на основе полученных результатов. Добавляем тесты и документацию по ходу дела: переносим Enforced_tokens в путь транскрипции в ответвлении vLLM, добавляем обработчик звука DAPI и ветку проверки ASR, а также подключаем хранилище полезной нагрузки аудио.

• Напишите интеграционные тесты (testermint), охватывающие счастливые и несчастливые пути, включая хосты, которые пытаются обмануть проверку (поддельные или более дешевые стенограммы).

• Задокументируйте передачу сообществу и команде Gonka, а также отправьте регистрацию модели и любые предложения по управлению.

• [Необязательно] Обеспечьте постоянную поддержку и обслуживание модальности ASR.

Мы начнем с шага 1 независимо и поделимся результатами, прежде чем идти дальше. Если у команды Лаборатории машинного интеллекта ( @fedor-konovalенко (https://github.com/fedor-konovalko)) есть активные планы ASR, мы будем рады скоординировать разделение работы. Особенно приветствуются отзывы о подходе, моделях-кандидатах и воротах проверки.

Привет!

@ivan-smetannikov-serokell (https://github.com/ivan-smetannikov-serokell)

Вот обновленный список моделей и гипотез ASR.

Исследование аудиоверификации Gonka

Цель

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

Основная цель — проверка того, что вывод был выполнен с помощью конкретного семейства целевых моделей с ожидаемым числовым поведением.

Трек А (основной)

Крупные LLM-программы в области аудио с открытым исходным кодом

Мотивация

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

Типичная архитектура:

Аудиокодер → Проектор / Q-Former → Декодер LLM → Текстовые токены

Примеры:

Qwen3-Omni-30B-A3B-Instruct — https://huggingface.co/Qwen/Qwen3-Omni-30B-A3B-Instruct

Qwen2.5-Omni — https://huggingface.co/Qwen/Qwen2.5-Omni-7B

САЛМОНН-13Б — https://github.com/bytedance/SALMONN

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

Гипотеза исследования

Большие аудио LLM создают стабильные вероятностные сигнатуры на тщательно отобранных звуковых подсказках.

Модификации модели, такие как:

квантование

замена архитектуры

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

Конвейер проверки

Шаг 1

Подготовьте тестовый набор аудиозаданий.

Желаемые свойства:

многоязычная речь

шумная речь

перекрывающиеся динамики

длинноконтекстное аудио

двусмысленные высказывания

редкая терминология

Тест должен максимизировать неопределенность декодера и выявить тонкие различия в вероятности.

Также можно использовать тест с открытым исходным кодом, например. https://github.com/revdotcom/speech-datasets

Шаг 2

Выполните вывод по эталонной модели.

Собрать:

сгенерированные токены

токен logprobs

топ-к дистрибутивов

профиль энтропии

вероятность последовательности

Затем сравните артефакты вывода для разных моделей и разного оборудования:

FP16 (FP8) против INT4

A100 против H100

H100 против H100

Ожидаемый результат

Верификатор должен достоверно различать:

эталонная модель

низкобитные квантованные версии

модели-заменители меньшего размера

сохраняя при этом низкий уровень ложноположительных результатов.

Трек B (альтернативный)

Большие модели ASR с открытым исходным кодом

Мотивация

Многие производственные речевые системы используют специализированную архитектуру ASR, а не модели аудиоязыка.

Примеры включают:

Whisper Large V3 — https://huggingface.co/openai/whisper-large-v3

Whisper Large V3 Turbo — https://huggingface.co/openai/whisper-large-v3-turbo

Попугай — https://huggingface.co/nvidia/parakeet-tdt-0.6b-v2

NVIDIA NeMo ASR — https://github.com/NVIDIA/NeMo

Эти системы имеют принципиально другую архитектуру.

Типичный трубопровод:

Аудиокодер → Декодер / Головка CTC → Расшифровка

В результате снятие отпечатков токенов в стиле LLM не подходит.

Требуется отдельная методология проверки.

Гипотеза исследования

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

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

Конвейер проверки

Шаг 1

Выполните эталонный вывод с помощью подготовленного эталонного теста.

Собрать:

стенограмма

баллы уверенности в словах

вероятность последовательности

кривые временной достоверности

Шаг 2

Вычисление отпечатков пальцев, специфичных для ASR.

Логарифм правдоподобия последовательности

Оценить:

log P(расшифровка | аудио)

Квантованные и дистиллированные модели часто систематически сдвигают это значение.

Профиль уверенности в слове

Проанализируйте распределение достоверности по словам.

Полезная статистика:

имею в виду уверенность

дисперсия

поведение хвоста

Кривая энтропии

Отслеживайте неопределенность во время декодирования.

Различные реализации модели часто создают характерные энтропийные сигнатуры.

Подпись калибровки

Измерьте взаимосвязь между прогнозируемой достоверностью и фактической ошибкой транскрипции. Это часто меняется после квантования или сжатия.

Ожидаемый результат

Верификатор должен различать:

эталонная модель ASR

квантованные развертывания

замещающие архитектуры

даже если окончательная расшифровка остается практически неизменной.