🐈FLM-Audio: новая англо-китайская full-duplex модель, чем она лучше Moshi ?

Тык, сегодня снова про аудио тех 🔔
🔗FLM-Audio: Natural Monologues Improves Native Full-Duplex Chatbots via Dual Training

Голосовой ассистент, который одновременно слушает и говорит, моментально замолкает при перебивании, поддакивает "угу". Это full-duplex модели, и их пока можно пересчитать по пальцам, а ведь Moshi вышла уже год назад. Потому что одновременно слушать и говорить — технически не очень просто.

‼Немного про full-duplex

Большинство (около-)дуплексных моделей используют Time Division Multiplexing: контекст это чередующиеся чанки того, что говорит пользователь, что отвечает модель, и текст ответа.

Kyutai Labs в Moshi предложили native full-duplex — она моделирует три потока параллельно: входное аудио пользователя, своё выходное аудио и текстовый inner-monologue. 😮 Для каждого аудиофрейма (12.5 Hz) модель генерит свои аудио и текстовые токены монолога (когда молчит, то все равно генерит пустые токены), затем эти потоки объединяются и подаются обратно на вход LLM.

Но есть сложность: текст и аудио имеют разные частоты. Одно слово произносится за ~300ms, а аудио кодек / энкодер выдает порядка ~100 токенов в секунду (зависит, но сильно больше чем кол-во слов). Их нужно синхронизировать.

😭 Проблема Moshi: 65% padding'а

Moshi выравнивает текст на уровне слов: для каждого слова создаётся временная метка, и текст растягивается pad-токенами. Получается: Привет <pad> <pad> <pad> <pad> как <pad> <pad> дела <pad> <pad>

Значительная часть текстового потока становится шумом. LLM моделирует язык на последовательности, где много токенов ничего не значат. При таком подходе Moshi проактивно отвечает, но становится слабее как языковая модель 🐈 — может выдавать странные фразы, неуместно перебивать. Плюс нужны точные временные метки на уровне слов для всего корпуса. Это сложно масштабируется.

💭FLM-Audio: natural monologues

В FLM-Audio предложили идею: а что если выравнивать текст и аудио на уровне предложений, а не слов?

Inner-monologue генерится как непрерывный текст, опережая аудио на ~2 токена. Модель думает полными предложениями и сразу говорит. Пока аудио заканчивает генерацию, текстовый канал заполняется <wait> токенами. Для понимания речи есть Follow Mode, где монолог следует за аудио (ASR режим). Тут нужны только транскрипции предложений, без временных меток слов.

Что и как тренировали?

Основа это Qwen-2.5-VL (7B), RQ-Transformer для аудио, Mimi кодек. Три канала эмбеддингов объединяются на каждом шаге, LLM генерит hidden states, из которых одна голова производит текст, а depth transformer 8 аудио токенов (все похоже на Moshi).

Обучение в четыре стадии. Post-training на ~1М часов (у Moshi было 7М) с dual-форматом: Lead (TTS режим, текст опережает аудио генерацию на ~2 токена) и Follow (ASR режим, текст после аудио). Затем supervised fine-tuning: сначала semi-duplex, потом full-duplex с симуляцией прерываний.

🗯Интересно: авторы подмешивают речь модели в listening канал с вероятностью 0.3, чтобы она научилась игнорировать собственный голос.

Результаты лучше Moshi, но есть вопросики

⏺ASR (LibriSpeech-clean): 3.2% WER против 5.7% у Moshi — на 44% лучше. В spoken QA авторы заявляют 56.3% vs 43.7 у Moshi (хотя в своей статье Moshi показывала 62.3%).

⏺Human eval: FLM выше Qwen-2.5-Omni по naturalness (8.2 vs 7.9), responsiveness (8.8 vs 8.1), robustness (8.0 vs 7.7).

Похожую идею отказа от строгого word-level выравнивания уже предлагали в SALM-Duplex (вот разбор), но её не сравнивают. Это странно: SALM-Duplex показала 94.5% успешных прерываний против 55.1% у Moshi при 1.1B парам-ов и всего 26.5k часов данных.

Ну и выводы такие..

Natural monologues решают проблему с padding'ом. Результаты по ASR это подтверждают, субъективные оценки положительные. Но без объективных метрик full-duplex способностей трудно оценить, действительно ли FLM-Audio лучше. Отсутствие сравнения с SALM-Duplex — это прям упущение.

🥹 Как считаете, стоит ли full-duplex такой архитектурной сложности? И как вам Moshi, если удалось потестить?

🎧StableToken: A Noise-Robust Semantic Speech Tokenizer for Resilient SpeechLLMs

🔗статья

LLM оперируют дискретными токенами. Для обучения модели на аудио модальности звук тоже часто представляют дискретно. Аудио токены могут использоваться для понимания речи (ASR, эмоции) и генерации (TTS - модель предсказывает токены, декодер превращает в звук).

Вот основные подходы

🪻Semantic‑distilled, например, RVQ codec Mimi в Moshi: первый codebook ближе к семантике, часто дистиллирован из SSL-эмбеддингов вроде HuBERT/WavLM, последующие добавляют акустику: интонации, тембр, эмоции

🌸Fully supervised tokenizers (GLM‑4‑Voice, CosyVoice2): берем speech encoder (например, Whisper), надстраиваем квантайзер (одноуровневый VQ) и учим под ASR objective. Несмотря на то, что такие токены натренированы на семантику, они также неявно учат просодию (видимо, иногда это полезно для транскрибации) и могут быть использованы для реконструкции

‼ Но, возьмем чистую аудио запись. Добавим небольшой шум (SNR 25), и токенайзер уже выдаст последовательность, где ~четверть токенов другие

Для ASR: модель видит разные токены для одного и того же слова — учится компенсировать нестабильность при извлечении паттернов. Для TTS результатом может стать менее разборчивая синтезированная речь

Авторы StableToken показывают, что стабилизация токенов в условиях шума значимо облегчает задачу LLM и ведет лучшим метриках понимания и генерации. И что самое интересное — без компромисса reconstruction quality. Разберем, что это за токенайзер

❤‍🩹 Voting-LFQ

Традиционная Vector Quantization (VQ) использует learned codebook — таблицу из N векторов. Для каждого эмбеддинга аудио фрейма ищем ближайший вектор в таблице и берём его индекс.

Lookup-Free Quantization (LFQ) работает проще: проецируем эмбеддинг в d-мерное пространство (в StableToken d=13) и применяем sign к каждой размерности. Получаем d-битный вектор (например, [1, -1, 1, 1, -1, ...]). Интерпретируем как бинарное число — вот и токен. Никаких codebook'ов. Каждая возможная комбинация битов автоматически валидна, поэтому стимулирует равномерное использование всего кодбука (в RVQ же бывает codebook collapse).

Авторы расширили LFQ до Voting-LFQ на базе Whisper-large-v3. Вместо одной проекции 5 параллельных веток. Каждая независимо проецирует эмбеддинг, получая свой 13-битный вектор. Но вместо выбора одной ветки, делаем побитовое majority vote (см. картинку)

😏 Noise aware consensus training

Во время тренировки для входного аудио w также генерят и зашумленное w’. Далее несколько веток квантизируют h’ из шумного, а остальные из чистого. Это позволяет модели стабилизироваться. Также авторы добавляют consensus loss: l2 между проекцией p_i ветки и среднего по веткам, чтоб заставлять модель стабилизировать шумные проекции еще до квантизации. Попытки учить «token-level consistency» сразу на дискретных давали нестабильные градиенты, поэтому consensus loss учат на непрерывных проекциях.

Результаты 🥤

Авторы оценивают Unit Edit Distance (error rate на токенах) в условиях разного зашумления звука и демонстрируют, что их StableTokenizer имеет наименьшие сдвиги даже среди конкурентов, натренированных на robustness (R-Spin) ☝ см. Таблицу

Reconstruction quality: в своем классе токенайзеров обгоняет CosyVoice2, GLM-4-Voice с самым низким WER, по MOS на уровне GLM-4-Voice. Более того, StableTokenizer выдает реконструкцию лучше чем Mimi и SpeechTokenzier

Для оценки на down-stream авторы тренили единый сетап на базе Qwen2.5-3B. StableTokenizer обгоняет GLM-4-Voice на ChiME test-real датасете с WER 35.90 против 51.08 , а это так то очень сложный шумный и много-голосный датасет

TTS (SEED-TTS): EN — WER 4.43 vs 6.19 при сопоставимом MOS. Похоже, что стабильные семантические токены снижают «шум в таргетах» и делают речь разборчивее

🐦 Вот такие дела, что думаете по этому токенайзеру? Нужны ли нам вообще стабильные токены?

🎧 Align2Speak: TTS для мало-ресурсного языка на 30 минутах аудио

Статья о том, как прокачать синтез речи для мало-ресурсных языков. Авторы показывают, что даже на 30 мин парных данных (аудио & текст) можно получить качественный TTS с помощью GRPO post-training.

🔗Align2Speak: Improving TTS for Low Resource Languages via ASR-Guided Online Preference Optimization

Статья понравилась, потому что идея простая и прикладная (разбирать что-то сложное пока нет времени). Ну и интересно все, что связано с бутстрэппингом на новые языки. Это, кстати, продолжение 🔗Koel-TTS (NVIDIA) от той же команды.

💻 Архитектура

Здесь у нас encoder-decoder из Koel-TTS. Не самое современное решение на фоне диффузионок, но надёжное и показывает хорошие результаты при ограниченных данных.

Текст, что нужно озвучить, проходит через NAR text encoder, затем AR transformer decoder получает аудио-токены референсного голоса в контекст и через cross-attention считывает текстовые представления. Декодер оперирует только аудио-токенами, ему не нужно учить мульти-модальность, что выгодно для мало-ресурсных сценариев. Такая архитектура была признана оптимальной в Koel-TTS, так как перенос голоса через контекст сработал лучше, чем через spk embedding. На каждом шаге модель параллельно генерит все токены кодбуков 🔗Nanocodec.

Базовая модель построена на IPA токенах (International Phonetic Alphabet). Это универсальные фонетические представления, позволяют модели выучить относительно независимый от языка мэппинг между звуками и речевыми токенами.

😑 Как адаптировали к новому языку?

Базовая TTS натренена на ~21к часов речи, где ~18к это англ, а все остальное европейские языки (German, Dutch, Spanish, French). Затем адаптировали к польскому, португальскому и хинди — трём языкам, которых модель не видела.

1⃣ Fine-tune на миксе пре-трейна и 30 минут - 5 часов нового языка
2⃣ GRPO (Group Relative Policy Optimization) с композитным reward из трёх сигналов: Character Error Rate (Whisper-v3-large), Speaker Similarity (TitaNet embeddings) и PESQ

При генерации вариантов для GRPO на 50% примеров включили CFG (Classifier-Free Guidance)

🤔 Результаты

Авторы оценивали по четырём метрикам: Intelligibility (CER от того же Whisper-v3-large), Speaker Similarity (TitaNet), Audio Quality (PESQ), Naturalness (Squim-MOS).

🐹 GRPO дает стабильные приросты, особенно в разборчивости (например, на португальском с 30 мин данных FT + GRPO CER падает с 33% до 3.94%). Конечно, использование whisper и в reward, и в оценке создаёт определённый bias, ведь мы учим модель подстраиваться под ASR (и ее галлюцинации). Но фреймворк гибкий, компоненты reward можно заменить под ваш сетап.

🐹 И даже без fine-tune на целевом языке, только через GRPO, модель значительно улучшает разборчивость. Даже на хинди, который сильно далёк от европейских языков в пре-трейне (54%➡32.6%). Модель не видела реальных пар текст-аудио, но научилась генерить внятную речь. Думаю, что во многом благодаря IPA, дают универсальную инициализацию.

🐹 На английском (high-resource язык из пре-трейна) тоже получили заметные улучшения после GRPO (лучше DPO). То есть метод работает не только для адаптации, но и для общего улучшения качества.

А чем бы вы заменили whisper? А еще, пробовали ли CFG в TTS?

Microsoft предлагает использовать speech-LLM для оценки качества синтетической речи. Идея практичная, стандартные протоколы типа MOS и A/B тестов трудозатратны, а на выходе получаем оценку без качественных инсайтов, что именно пошло не так

🔗SpeechLLM-as-Judges: Towards General and Interpretable Speech Quality Evaluation

🐯 SQ-LLM

Авторы собрали датасет SpeechEval: 32к аудио (реальных и синтетики, включая коммерческие TTS), 128к аннотаций на 4 языках (en/zh/ja/fr). Аннотации включают оценки по 8 измерениям: overall quality, intelligibility, distortion, speech rate, dynamic range, emotional impact, artistic expression, subjective experience, а также развернутое текстовое описание «что не так».

Модель SQ-LLM на базе Qwen2.5-Omni-7B. Файн-тьюн LLM через LoRA, аудио энкодер не трогали. Обучали на 4: speech quality assessment (краткий текстовый разбор по 8 измерениям), парные сравнения A/B по тем же аспектам, генерация советов по улучшению, и детекция дипфейков.

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

Эксперименты в статье не совсем убедительны. Но есть все же несколько инсайтов 🌸

🌀Без доп. файн-тюна все speech-LLM дают слабую корреляцию с человеческими оценками (zero-shot не в деле). Эмерджентности не наблюдается, speechLLM, обычно крайне чувствительны к out-of-domain задачам. ‼️ Между их SQ-LLM и их же кастомными бейзлайнами (Whisper+Qwen3-8B, WavLM+Qwen3-4B) большой разницы тоже не вижу...

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

🐈CoT улучшает метрики, логично: 8 промежуточных численных предсказаний дают модели доп. сигналы помимо текста. Это мотивирует модель выучить отдельно факторы влияющие на качество и численно их оценивать, подкрепляя ответ. Полагаю, CoT еще снижает кол-во связных и красивых, но фактически некорректных формулировок

RL в виде GRPO даёт прирост по всем задачам, особенно на детекции дипфейков: модель достигает EER 6.2% и точности 89.4% против 15-18% у спец. систем типа RawNet2 (EER 15.84%, ACC 72.04%)

В своих проектах пришла к похожим выводам: учим LLM’ку извлекать и предсказывать количественные и качественные характеристики аудио внутри цепочки CoT (даже те, которые лишь косвенно связаны с down-stream) — получаем лучшее качество на основной задаче. Правда, это лишь мое эмпирическое наблюдение.

Что не понравилось в статье 😭

🟡Система якобы решает проблему интерпретируемости, но ни одного человеческого исследования нет, было бы круто прогнать на какую-нибудь TTS и проанализировать отзывы модели

🔴SQ-LLM показывает, что speech-LLM можно адаптировать для оценки качества речи со средней точностью.. Pearson correlation 0.476 на оценке качества это скромно (хотелось бы 0.7+). Точность 67% в парных сравнениях, что всего на 17 п. выше угадывания

🟡Непонятно, как файн-тюнили кастомные бейзлайны: была ли LoRA, был ли CoT? Не хватает сравнения разных аудио-энкодеров и LLM-декодеров

Самое главное: датасет не выпущен. Авторы собрали ценный ресурс, 128к качественных аннотаций, но пока не зарелизили

Выводы?

Я все еще скептически отношусь к LLM as a judge. Но для частичной автоматизации оценивания, почему бы и нет, например, чтобы выловить сложные примеры и углубиться в их анализ уже вручную.

P.S.: В этом году вела проект аннотации данных: подготовка, дизайн UI, правила для аннотаторов, обработка edge cases. Впечатление, что компании, специализирующиеся на данных, уже чаще вовлекают людей только для проверки и исправления ошибок ML пайплайнов. Это оптимизация и ускорение, но критически важна due diligence аннотаторов, не кликнуть на «тут все верно, идем дальше», если есть ошибки

Пока дописывала пост, релизнули 🔗OmniVinci. Идём читать 🤓

🐹 ARC-Encoder от Kyutai: plug-and-play компрессия для LLM

На прошлой неделе вышла крутая статья от Kyutai Labs (да, я им симпатизирую): 🔗ARC-Encoder learning compressed text representations for large language models

Почему-то осталась относительно незамеченной, хотя на мой взгляд работа хорошо сделана и достойна deep-dive чтения. Как уже видно из названия, эта статья даже не про TTS & STT, здесь авторы придумали универсальный энкодер для сжатия длинных контекстов в LLM'ках в х4-8 раз практически без потерь качества ответов на различных downstream задачах (QA, text summarization, перевод), включая ICL

ARC-Encoder сжимает контекст в короткую последовательность эмбеддингов, которые напрямую подставляются в LLM декодер (после embedding layer), при этому саму LLM не до-обучают❕. И в дополнение, ARC-Encoder можно легко адаптировать к нескольким разным декодерам через небольшие MLP модули

🍅 Немного про context compression

LLM-пайплайны (RAG, multi-document QA) нуждаются в длинных контекстах. Но pre-fill на длинных промптах стоит дорого и быстро упирается в лимиты контекстного окна. Можно просто дропнуть наименее важные токены, или кратко суммаризировать промпт. Это hard compression. Альтернативный подход, soft compression, подразумевает извлечение смысловых эмбеддингов из пассажей контекста (инструкции промпта или документы). Часто такие методы также подразумевают fine-tune LLM декодера, ведь ему нужно еще научиться использовать эти сжатые репрезентации. ARC-Encoder же тем хорош, что никак не трогает decoder LLM, таким образом модель никак не будет менять своего поведения на других задачах 💲🤩


☕️ Архитектура

⭐️В недавней работе (тут) показали, что LLM декодер можно успешно использовать для компресси текста. Поэтому авторы взяли за основу LLaMA‑3.2‑3B, убрав output head и cаusal mask (чтобы энкодер видел весь контекст сразу, а не только влево)

⭐️Поверх последнего self-attention блока применяют pooling (average) с фактором сжатия от 4 до 8, но только для queries, в то время keys & values остаются полноразмерными. Авторы пишут, что пробовали пулить на разных слоях, но эффективнее всего на последнем, что логично, репрезентации на последнем слое семантически богаче

⭐️Далее MLP слой (без активации🌸) отображает encoder outputs в размерность латентного пространства LLM. Получившиеся эмбеддинги просто подставляются в латентное пространство LLM декодера (на вход transformer layers)

Как и что тренили?

1️⃣ Pre-training на Common Crawl на двух задачах (см. картинку): реконструкция последовательности (а) и продолжение последовательности (б), что оказалось критично, так как это по сути та же задача, что и любой downstream task

2️⃣ Fine-tuning делали на миксе синтетических и реальных QA, summarization и др. датасетах. При этом сжатые эмбеддинги перемежаются с обычными токенами, что сохраняет few-shot способности модели

Понравился оценочный сетап. Модели‑декодеры: Llama‑3.1‑8B и Mistral‑7B (base). Бейзлайны авторы ре-имплементили сами на базе тех же декодеров, данных и задачах. Дополнительно оценили open book (весь промпт вместе с документами для QA у модели в контексте) и closed book сетапы. Тренировочные сеты бенчмарков предусмотрительно не включали в тренировки.

🟣На всех бенчах context compression ARC держится близко к open‑book на Llama‑3.1‑8B и обгоняет closed‑book и большинство бейзлайнов; на Mistral‑7B отставание от open‑book небольшое, что ожидаемо (архитектурно декодер Mistral дальше от Llama-3.2 энкодера)

🔴Также круто: удалось увеличить эффективнй контекст Llama2-chat с 4 до 32k обогнав по некоторым метрикам Llama2-32k Instruct (специально до-трененную на длинных последовательностях)

🥹 А что же дальше?

На мой взгляд вся идея хорошо ложится на речевые и аудио модели, в которых проблема длинных контекстов стоит еще острее. Как думаете, является ли эта работа своего рода proof of concept и увидим ли мы эту идею в следующем Moshi? Также интересно, как далеко можно зайти с multi-decoder подходом: один универсальный энкодер для сжатия + мини адаптеры под каждую LLM

В далеком 2020 году вывели степенные законы масштабирования для pre-training. Теперь команда Meta (и партнеры из академии) попытались сделать то же самое для RL

🔗«The Art of Scaling RL Compute for LLMs» показывает, что это предсказуемая сигмоида и предлагает ScaleRL рецепт стабильного RL проверенный на 100k GPU‑часов

😑 Почему не power law, а sigmoid?

В отличие от pre-training, где cross-entropy loss следует степенному закону, в RL метрики обычно ограничены сверху (accuracy, pass@k) и ведут себя как sigmoid. Логично: в начале модель исследует пространство, учится базовым навыкам, рост медленный. Затем наступает начинает собирать атомарные навыки в сложные стратегии, и точность взлетает. Ближе к потолку прогресс снова замедляется, образуя S-кривую.

Зачем это нужно? 💵 Чтобы на малом compute 10k GPU-часов предсказать, что будет на 100k, и не тратить бюджет на алгоритм, который рано упрется в потолок

Авторы выяснили, что компоненты рецепта влияют на два параметра: асимптотический потолок (достижимая точность) и крутизну кривой (скорость обучения)

А теперь три самых важных параметра в RL тренировочном рецепте:

💪 Pipeline-RL off-policy архитектура

Обычный PPO синхронный. Генераторы создают роллауты, ждут, пока тренирующиеся обновят веса, получают новые веса, повторяют. Получается, что половину времени кто-то ожидает

А вот PipelineRL‑k стримит роллауты и делает на лету обновление весов генераторам даже посреди генерации последовательности (со старым KV‑кэшем); тренирующиеся инстансы ждут, если ушли вперёд более чем на k шагов. При схожей верхней асимптотике PipelineRL‑k значительно ускоряет обучение

🕺 Loss функция: CISPO vs DAPO

Сравнили лоссы основанные на GRPO: DAPO (GRPO с asymmetric DAPO clipping) CISPO (из Minimax) и GSPO. И вот у DAPO верхнюю границу оценили гораздо ниже (см. картинку), что критично на практике

GRPO в свое время запустил всю эту волну reasoning моделей (см. картинку). Идея такая: давайте избавимся от critic model и будем считать для каждого сэмпла advantage в зависимости от того, какой реворд он получил относительно всех других кандидатов в группе.

Последующие работы документировали недостатки алгоритма. Например была такая тема с fork токенами ("однако", "но", "следует", …), которые в базовой модели получали низкую вероятность, но они важны в рассуждениях и в RL получают высокий реворд, а из-за clipping’а не могут особо повлиять на тренировку и сдвинуть output distribution в верном направлении

CISPO возвращается к REINFORCE, но клипает только importance sampling ratio, оставляя градиент по самим токенам: sg(clip(π_new/π_old, ε)) × Â. Stop-gradient делает это коэффициентом. GSPO в отличие от GRPO (и DAPO) переходит к importance sampling на уровне всей последовательности и стабильнее на длинных ответах

❕FP32 для LM головы

FP32 precision для LLM лоджитов. Это третий столп стабильного RL. Проблема в том, что генераторы и тренирующиеся используют разные compute kernels, к небольшим численным отличия в лоджитах. В importance sampling расхождения дестабилизируют, а FP32 для финального слоя почти устраняет проблему

Авторы вывели рецепт самых «оптимальных решений для RL». Там множество трюков: исключение промптов, где все генерации имеют одинаковый реворд, форсирование ответа на длинных цепочках и др.

Так как эксперименты ограничены проверяемыми задачами с бинарным ревордом (математика, кодинг), то я бы пока просто приняла к сведению идеи. Непонятно, будет ли ScaleRL скейлиться на непроверяемых задачах, например prosody в TTS, мало абляций на downstream задачах.

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

😎 P.S.: О precision в RL давно спорят, в x идет движ по этой статье. Предлагают переходить с bf16 на fp16. Оба типа занимают 16 бит, но fp16 аллоцирует больше бит под мантиссу, дает большую точность (при меньшем диапазоне) и помогает избежать коллапса тренировки