Как устроены voice-2-voice модели

Вы говорите в телефон: «Объясни квантовую запутанность за минуту». Через долю секунды из динамика отвечает живой голос — не робот из навигатора, а почти собеседник: с паузами, интонацией, даже с лёгким «хм» перед сложным местом. Это voice-2-voice (V2V): модель принимает аудио и отвечает аудио. В этой статье мы разберём, как устроен этот фокус — от волны в микрофоне до звука в динамике.

Откуда взялась статья

Мне довелось поработать в Newo.ai — компании, которую основал Давид Ян, создатель ABBYY и один из тех, кто ещё в девяностые показал, что из России могут выходить продукты мирового уровня. Я занимался внедрением голосовых решений в реальные проекты на европейском рынке: не сценой на конференции, а продакшеном, где счёт идёт на миллисекунды, а неудачный тон ответа слышен в оттоке клиентов.

Именно там я впервые всерьёз столкнулся с voice-2-voice — системами, которые принимают речь и отвечают речью. Снаружи всё выглядит просто; внутри — нейронные кодеки, трансформеры, три принципиально разные архитектуры и месяцы обучения, о которых в рекламных брошюрах обычно не пишут. Мне захотелось разобраться, как это устроено на самом деле и чем одни V2V- модели отличаются от других — не по презентациям, а по механизму.

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

О чём эта статья

Если вы знаете, как работают языковые модели (или читали книгу «Как работает LLM»), вам знаком главный принцип: предсказать следующий токен. V2V-модели — близкие родственники этой идеи, только «токены» теперь описывают не буквы и слова, а фрагменты звука.

Статья рассчитана на ИТ-специалиста: вы понимаете, что такое API, GPU и трансформер, но, возможно, никогда не касались speech ML. Мы не будем упрощать до «нейросеть слушает и говорит» — пройдём весь путь: представления звука, три архитектурные парадигмы, обучение, стриминг и ограничения.

Основной текст объясняет идеи на пальцах, примеры кода — на Swift (github.com/asaptf/v2v-models-article-ru — каждый файл без зависимостей и запускается одной командой), а врезки дают инженерную глубину: 💡 главная мысль, 📐 аналогия, 🛠 инженерные детали, ⚠️ частая ошибка, 📜 история, 📚 ссылки.

С чего начнём: чёрный ящик

Снаружи V2V-система выглядит предельно просто:

Речь входит — речь выходит. Никакого промежуточного текста, который вы могли бы прочитать (хотя внутри он иногда всё же появляется — об этом в разделе 2). Вся статья — о том, что происходит внутри этого ящика.

💡 Главная мысль статьи: современные V2V-модели во многом похожи на языковые модели для звука. Та же идея «угадай следующий элемент последовательности», но вместо слов — токены речи, сжатые нейронным кодеком. Аналогия не полная: аудио требует кодеков, нескольких потоков токенов, отдельного обучения очерёдности реплик и борьбы за миллисекунды задержки.

📐 Аналогия: текстовая LLM — это писатель, который набирает ответ по буквам. V2V-модель — диктор-собеседник, который набирает ответ крошечными фрагментами звука и в realtime-режиме ещё следит за паузами, перебиваниями и интонацией. И писатель, и диктор учатся на огромных корпусах примеров «что было дальше».

Чем V2V отличается от «просто TTS»

Синтез речи (TTS, text-to-speech) существует десятилетиями: вы даёте текст — получаете голос. V2V — другое:

V2V объединяет три способности, которые раньше жили отдельно: распознавание речи (ASR), понимание и рассуждение (LLM), синтез речи (TTS). Вопрос в том, делать ли это тремя блоками подряд или одной сквозной моделью — к этому мы перейдём во втором разделе.

⚠️ Частая ошибка: называть любой голосовой ассистент «V2V-моделью». Если внутри классический конвейер «Whisper → GPT → ElevenLabs», это каскад, а не нативная voice-2-voice модель. Разница важна: каскад проще отлаживать, но теряет интонацию, эмоции и невербальные сигналы (вздох, смешок), которые не попадают в текст.

1. Звук как данные — три представления

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

1.1. Сырая волна: слишком много чисел

Когда вы говорите в микрофон, он записывает амплитуду звукового давления десятки тысяч раз в секунду. Стандартная частота дискретизации для речи — 16 000 или 24 000 Гц (измерений в секунду). Одна секунда речи при 24 kHz — это 24 000 чисел.

Для сравнения: предложение из 15 слов в текстовой LLM — это примерно 15–25 токенов. Секунда речи в «сыром» виде — на три порядка больше. Подавать такой поток напрямую в трансформер дорого: внимание масштабируется квадратично от длины последовательности.

Посчитаем на пальцах — полный скрипт в ch01_audio_compression.swift:

let sampleRate = 24_000let durationSec = 1.0let rawSamples = Int(Double(sampleRate) * durationSec)   // 24 000 чиселlet tokensPerSec = 50.0let speechTokens = Int(tokensPerSec * durationSec)       // 50 токеновprint("Сжатие волна → токены: ×\(rawSamples / speechTokens)")  // ×480

📐 Аналогия: сырая волна — как фильм в формате 8K без сжатия: каждый кадр прекрасен, но хранить и обрабатывать его для задачи «понять сюжет» — расточительство. Нужен кодек.

1.2. Спектрограмма: звук как картинка

Первый уровень сжатия — спектрограмма (mel-spectrogram). Звук разбивают на короткие окна (обычно 20–30 мс), для каждого окна считают, сколько энергии приходится на каждую частоту. Результат — двумерная «картинка»: ось X — время, ось Y — частота, цвет/яркость — громкость.

Частота кадров спектрограммы — обычно 50–100 в секунду (вместо 24 000). Уже лучше, но всё ещё много: каждый кадр — вектор из ~80–128 чисел (mel-каналов).

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

Кстати, если вы хоть раз включали режим спектрограммы в Audacity — вы это представление уже видели. Опытные фонетисты умеют «читать» по такой картинке гласные, без всякого ML.

1.3. Токены речи: дискретные «слова звука»

Третий уровень — нейронный аудиокодек, который превращает спектрограмму (или волну) в последовательность целых чисел — токенов речи. Типичная частота: 25–75 токенов в секунду. Секунда речи ≈ 50 токенов — не 24 000. Это всё ещё плотнее текста (та же секунда, записанная буквами, — токена три-четыре), но уже тот масштаб, с которым трансформеры прекрасно живут.

💡 Главная мысль: V2V-модели работают не с волной, а с токенами речи — дискретной последовательностью, к которой применима та же логика, что и к тексту: «предскажи следующий токен». Нейронный кодек — мост между физическим звуком и языковой моделью.

🛠️ Инженерная вставка: параметры аудио.

• Частота дискретизации : 16 kHz (телефония) или 24 kHz (широкополосная речь).

• Размер окна FFT: обычно 25 мс, шаг (hop) 10 мс → ~100 кадров/с до даунсэмплинга.

• Mel-шкала: — аппроксимирует восприятие ухом.

• Токены кодека: кодовая книга размером (часто или ), несколько уровней RVQ (см. раздел 3).

• Битрейт токенов: при 50 токен/с и бит ≈ 500 бит/с на уровень; с 4 уровнями RVQ — порядка 2 кбит/с (против ~384 кбит/с у несжатого 24 kHz PCM).

1.4. Что теряется при сжатии

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

• тонкие нюансы дыхания и пауз;

• фоновые шумы (иногда это плюс);

• музыку и неречевые звуки (кодеки обучают преимущественно на речи).

Для диалогового ассистента это обычно приемлемо. Для музыкального AI — нужны другие кодеки (например, EnCodec обучали и на музыке).

⚠️ Частая ошибка: думать, что токен речи = слог или фонема. На практике один токен кодирует короткий фрагмент (~20–40 мс) акустики — примерно как один символ в BPE- токенизации не равен одной букве. Соответствие «токен ↔ лингвистическая единица» не фиксировано и выучивается моделью неявно.

2. Три парадигмы voice-2-voice

Как соединить «услышать» и «ответить»? Индустрия пришла к трём принципиально разным ответам. Они не взаимоисключающие — сегодня все три живут в продакшене. Понимание различий поможет вам читать анонсы моделей без маркетингового тумана.

2.1. Парадигма A: каскад (конвейер)

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

🎤 аудио → [ASR] → текст → [LLM] → текст → [TTS] → 🔊 аудио

• ASR (automatic speech recognition) — Whisper, Google Speech, и др.

• LLM — GPT-класса, Claude, Gemini в текстовом режиме.

• TTS — ElevenLabs, OpenAI TTS, Google Cloud TTS.

Плюсы: каждый блок можно менять, тестировать и масштабировать отдельно; промежуточный текст удобен для логирования и модерации. Минусы: задержка суммируется (ASR + LLM + TTS = 1–3 секунды и больше); при переводе в текст исчезают интонация, эмоция, акцент, смех, вздохи — всё, что не выразимо буквами.

Задержки складываются буквально — см. ch02_cascaded_latency.swift:

struct Stage { let name: String; let latencyMs: Double }let cascade = [    Stage(name: "ASR", latencyMs: 400),    Stage(name: "LLM (первый токен)", latencyMs: 350),    Stage(name: "TTS (первый звук)", latencyMs: 300),]let totalMs = cascade.reduce(0.0) { $0 + $1.latencyMs }   // ~1050 мс + VAD и сеть

📜 Из истории: именно так устроены классические голосовые ассистенты — Siri (2011), Alexa (2014), ранний ChatGPT Voice (2023). Это не «плохой» подход: он до сих пор доминирует там, где важна надёжность и прозрачность, а не минимальная задержка.

2.2. Парадигма B: сквозная модель на токенах речи

Вторая идея — не переводить речь в текст на промежуточных этапах. Вместо этого:

1. Нейронный кодек кодирует входящую речь в токены.

2. Трансформер (как текстовая LLM) предсказывает следующие токены ответа.

3. Декодер кодека превращает токены обратно в звук.

🎤 → [кодек] → токены → [трансформер] → токены → [декодер] → 🔊

Модель может оперировать смешанными последовательностями: токены речи + текстовые токены в одном контексте. Представители: AudioLM (Google, 2022), VALL-E (Microsoft, 2023), SpeechGPT, Sesame CSM (2025).

💡 Главная мысль: парадигма B очень похожа на LLM для звука. Тот же авторегрессионный трансформер, та же идея «предскажи следующий токен», но словарь — не 50 000 слов, а кодовая книга нейронного кодека, часто ещё и несколько RVQ-потоков на один временной шаг.

🛠️ Инженерная вставка: иерархическое предсказание (AudioLM). AudioLM предсказывает токены на трёх уровнях:

1. Семантические токены (низкая частота, от HuBERT/wav2vec) — «о чём» звучит речь.

2. Акустические токены (средняя частота) — тембр и артикуляция.

3. Токены кодека (высокая частота) — точная волна.

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

2.3. Парадигма C: нативный realtime / дуплекс

Третья парадигма — одна модель или тесно связанная модельная система, которая принимает аудио (или его компактное представление) и генерирует аудио в реальном времени. Здесь важно различать два уровня:

• Realtime speech-to-speech — модель отвечает голосом с низкой задержкой, поддерживает прерывания (barge-in/interrupt), tool calling и общее состояние сессии.

• Настоящий full-duplex — более сильное требование: модель постоянно моделирует два аудиопотока и может слушать, молчать, вставлять короткие реакции или говорить поверх пользователя как участник живого разговора.

🎤 ──→ [ единый трансформер ] ──→ 🔊         ↑ слушает и говорит         ↓ одновременно

Примеры realtime S2S: OpenAI Realtime API (gpt-realtime, GPT-Realtime-2), Gemini Live API (Google), Amazon Nova Sonic. Открытый референс настоящего full-duplex — Moshi (Kyutai, 2024).

Ключевые свойства:

• Прерывания и turn-taking — пользователь может перебить ответ; система останавливает воспроизведение и обновляет контекст.

• Полный дуплекс — в моделях уровня Moshi модель не ждёт строгой смены реплик; она может вставлять backchanneling («hm», «ok») и работать с overlap.

• Низкая задержка — целевые 200–500 мс от конца вашей фразы до начала ответа.

• Нативная мультимодальность — аудио не «прикручено» к текстовой LLM, а встроено в архитектуру с самого начала.

📐 Аналогия: каскад — это переводчик, который записывает вашу речь в блокнот, думает, пишет ответ и зачитывает его вслух. Сквозная модель на токенах — полиглот, который «думает» прямо звуком. Нативный realtime — телефонная линия без блокнота; full-duplex — собеседник, который ещё и не теряет поток, когда реплики накладываются.

2.4. Сравнительная таблица

⚠️ Частая ошибка: считать, что realtime S2S автоматически означает настоящий full-duplex и что «нативный» всегда лучше. Для корпоративного IVR, юридического бота или системы с жёстким compliance каскад с читаемым текстовым логом часто предпочтительнее. Нативный realtime выигрывает там, где важны естественность и скорость — голосовой компаньон, языковой репетитор, hands-free ассистент.

2.5. Куда движется индустрия

Тренд очевиден: от A к C. Но переход не мгновенный — нативные realtime-модели дороже в обучении, сложнее в оценке качества и пока уступают каскадам в контролируемости (сложно заставить модель «говорить только по скрипту»).

Практичный компромисс 2025–2026: гибриды — нативная модель для быстрого диалога, текстовый LLM для сложных рассуждений, каскад как fallback. OpenAI Realtime API, например, поддерживает и голосовой, и текстовый режим в одной сессии.

По моему опыту внедрений расклад приземлённее, чем в анонсах: заказчик приходит за «голосом как в демо OpenAI», но после первого разговора про compliance и разбор инцидентов выбирает каскад с читаемыми логами. Нативный realtime добирается до прода там, где естественность беседы — сам продукт: компаньоны, репетиторы, консьерж-сервисы.

3. Нейронный аудиокодек — сердце сжатия

Текстовая LLM не работает с буквами — она работает с токенами. V2V-модель не работает с волной — она работает с токенами речи. Их создаёт нейронный кодек: отдельная нейросеть, обученная сжимать и восстанавливать звук. Без кодека не было бы парадигм B и C.

3.1. Зачем нужен отдельный кодек

Представьте, что вы хотите применить трансформер к аудио. Прямая подача 24 000 чисел за каждую секунду звука — вычислительный кошмар. Нужно:

1. Сжать непрерывный сигнал в короткую дискретную последовательность.

2. Сохранить достаточно информации для разборчивой речи.

3. Сделать сжатие обратимым — из токенов можно восстановить звук.

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

3.2. RVQ: остаточное векторное квантование

Ключевая техника современных кодеков — RVQ (residual vector quantization). Идея проста:

1. Энкодер выдаёт непрерывный вектор для каждого фрагмента звука (~20–40 мс).

2. Первый уровень квантования находит ближайший вектор в кодовой книге (размер , обычно 1024–8192) → получаем токен .

3. Считаем остаток .

4. Второй уровень квантует остаток → токен .

5. Повторяем для 4–8 уровней.

Упрощённая демонстрация на Swift — ch03_rvq_demo.swift:

let (t1, q1) = nearest(z, in: codebookL1)   // первый токен + квантованный векторlet r1 = subtract(z, q1)                     // остатокlet (t2, q2) = nearest(r1, in: codebookL2)   // второй токенlet reconstructed = add(q1, q2)              // z ≈ q1 + q2// На выходе: [t1, t2] — дискретные токены вместо непрерывного z

📐 Аналогия: это как описать цвет стены: сначала грубо («бежевый», уровень 1), потом уточнить оттенок («тёплый песочный», уровень 2), потом текстуру («матовый», уровень 3). Каждый уровень добавляет деталь к предыдущему.

RVQ — из тех приёмов, что кажутся очевидными ровно после того, как вам их объяснили. До этого вопрос «как упаковать непрерывный звук в целые числа, не убив разборчивость» выглядит неподъёмным.

🛠️ Инженерная вставка: формула RVQ. Пусть — выход энкодера. Тогда:

На инференсе V2V-модель предсказывает токены для каждого временного шага. Декодер суммирует векторы из кодовых книг и синтезирует волну. Типичные параметры: – уровней, –, частота ~25–75 Гц.

3.3. Известные кодеки

Кодек обучают отдельно от V2V-модели — на корпусах от тысяч до миллионов часов аудио, у кого сколько есть. Затем веса кодека замораживают, и трансформер учится оперировать его токенами.

💡 Главная мысль: качество кодека — потолок качества всей V2V-системы. Если кодек плохо передаёт шёпот или эмоциональные всплески, никакой трансформер это не восстановит. Поэтому в 2024–2025 кодеки стали отдельным полем исследований.

3.4. Семантические vs акустические токены

Продвинутые системы (AudioLM, Moshi) различают два вида токенов:

• Семантические — «что сказано»: смысл, фонемы. Их дают предобученные энкодеры вроде HuBERT или w2v-BERT (в AudioLM — 25 токенов/с).

• Акустические — «как сказано»: тембр, просодия, эмоция. Это токены кодека (в AudioLM — 50 кадров/с от SoundStream).

AudioLM предсказывает их по очереди: сначала семантику, потом акустику. Mimi пошёл дальше и упаковал оба вида в один поток 12.5 Гц: первый уровень RVQ дистиллирован из семантического энкодера (WavLM), остальные несут акустику. Цель в обоих случаях одна: помочь модели понимать смысл, не путая его с манерой произнесения.

⚠️ Частая ошибка: путать нейронный кодек с MP3/AAC. Классические аудиокодеки используют ручную инженерию (MDCT, психоакустика). Нейронные кодеки учатся на данных и оптимизированы под задачу «токены → трансформер → токены», а не под прослушивание музыки в плеере.

4. Архитектура V2V-модели изнутри

Мы знаем три парадигмы и роль кодека. Теперь соберём полную картину: что стоит между микрофоном и динамиком в современной сквозной или нативной системе. Спойлер: в центре — тот же трансформер, что и в ChatGPT.

4.1. Общая схема (парадигмы B и C)

Типичная сквозная V2V-система состоит из четырёх блоков:

┌──────────┐    ┌─────────────┐    ┌──────────────┐    ┌──────────┐│  Энкодер │ →  │ Трансформер │ →  │   Декодер    │ →  │  Вокодер ││  (вход)  │    │  (мозг)     │    │  (выход)     │    │  (звук)  │└──────────┘    └─────────────┘    └──────────────┘    └──────────┘

1. Энкодер входа — превращает аудио пользователя в последовательность эмбеддингов (или токенов). Это может быть замороженный кодек + embedding layer, или обучаемый speech encoder (Whisper-encoder, Conformer).

2. Трансформер — стек decoder-only или encoder-decoder блоков с вниманием. Здесь происходит понимание, рассуждение и планирование ответа.

3. Декодер (голова предсказания) — для каждого временного шага выдаёт распределение над токенами кодека (или непрерывными латентами) и выбирает следующий токен.

4. Вокодер — превращает предсказанные токены обратно в аудиоволну; обычно это декодер нейронного кодека из раздела 3.

В моделях настоящего full-duplex (например, Moshi) энкодер и декодер делят один общий трансформер: входящий и исходящий аудиопотоки — два «канала» в одной последовательности.

4.2. Трансформер: что общего с LLM

Если вы работали с текстовыми LLM, узнаете знакомые детали:

• Decoder-only архитектура (как GPT) — модель видит только прошлое и предсказывает будущее. Для речи это естественно: мы не знаем, что пользователь скажет дальше.

• Causal mask — при обучении и инференсе токен не может «подглядывать» в токены .

• Multi-head attention — модель учится связывать фрагменты речи на разных временных масштабах (аналогия с длинным контекстом в тексте).

• KV-cache — при стриминге прошлые ключи и значения кэшируются, чтобы не пересчитывать их при каждом новом чанке (подробнее в разделе 6).

🛠️ Инженерная вставка: функция потерь. На предобучении V2V-модели минимизируют кросс-энтропию предсказания следующего токена речи при заданном контексте:

Если в контексте есть и текст, и речь — словарь объединённый: специальные токены разделяют модальности. На дообучении добавляют потери для «правильного» диалогового поведения (SFT) и preference loss (DPO/RLHF).

4.3. Мультимодальный контекст

Современные V2V-модели редко работают только с аудио. Типичный контекст сессии:

[SYSTEM] инструкция ассистента (текст)[USER_AUDIO] токены речи пользователя[ASSISTANT_AUDIO] токены речи ассистента (при обучении — ground truth)

При инференсе модель авторегрессивно дописывает [ASSISTANT_AUDIO], токен за токеном. Текстовые инструкции (system prompt) задают личность, язык, ограничения — ровно как в ChatGPT, только «ответ» генерируется в аудиотокенах.

Моделируем контекст сессии на Swift — ch04_speech_autoregress.swift:

enum Modality { case system, userAudio, assistantAudio }struct ContextToken {    let modality: Modality    let id: Int?       // токен речи; nil для текстовой инструкции    let label: String}// Модель дописывает assistantAudio токен за токеном:for token in predictedReply {    seq.append(ContextToken(modality: .assistantAudio, id: token, label: "audio:\(token)"))}

💡 Главная мысль: V2V-модель — это мультимодальный трансформер или связка трансформеров, в которой аудио — равноправная модальность рядом с текстом. Модели OpenAI Realtime и Gemini Live показывают этот сдвиг: голосовой режим всё чаще становится не отдельной «озвучкой», а частью общего мультимодального контекста.

⚠️ Где аналогия с LLM ломается: текстовый токен можно прочитать глазами, а аудиотокен зависит от кодека и нескольких RVQ-уровней. Кроме next-token loss приходится отдельно учить просодию, endpointing, turn-taking, прерывания и безопасность голоса.

4.4. Дуплекс: два потока в одной модели

Moshi (Kyutai, июль 2024) — показательный пример настоящего full-duplex. Архитектура:

• Backbone Helium 7B + отдельный аудио-трансформер; кодек Mimi (12.5 Гц).

• Вход: поток токенов пользователя с частотой ~12.5 Гц.

• Выход: поток токенов модели (речь ассистента) с той же частотой.

• Оба потока интерливированы в одной последовательности (multi-stream attention).

• Inner Monologue: на каждый кадр сначала предсказывается текстовый токен (скрытая «мысль»), затем семантический, затем акустические — речь становится связнее.

• Заявленная задержка: ~200 мс (теоретический минимум 160 мс).

Это позволяет:

• начинать ответ до того, как пользователь закончил фразу;

• вставлять backchanneling («угу», «понятно») во время речи собеседника;

• естественно обрабатывать перебивания.

Это сильнее, чем обычный barge-in в realtime API: там клиент часто просто останавливает воспроизведение ответа при новой речи пользователя, а Moshi моделирует входящий и исходящий потоки как параллельные части одной сцены.

Это легко проверить самому на moshi.chat: первую минуту кажется, что собеседник просто вежлив, а потом ловишь момент, когда он «угукает» ровно там, где вы набираете воздух. Немного жутко — и очень убедительно.

📐 Аналогия: каскадная система — почтальон: принял письмо целиком, отнёс, принёс ответ. Realtime S2S — телефонная линия без блокнота: отвечаете быстро, можете перебить. Full-duplex вроде Moshi — собеседник, который не выпадает из потока, когда реплики накладываются.

⚠️ Частая ошибка: думать, что дуплекс = «модель говорит, пока вы молчите». Настоящий дуплекс — это перекрывающиеся потоки. Обучить такое поведение сложно: нужны данные с естественными диалогами (перебивания, паузы, overlap) и специальные loss-функции для turn-taking.

5. Как обучают V2V-модели

Пустой трансформер со случайными весами — как новорождённый: он ничего не слышит и не говорит. Оживление занимает месяцы работы GPU-кластеров. Разберём конвейер обучения — от кодека до RLHF — по шагам, как мы делали для текстовых LLM.

5.1. Карта стадий

Пропорции аналогичны текстовым LLM: предобучение съедает почти всё.

5.2. Стадия 1: обучение кодека

Кодек обучают до основной модели, на задаче реконструкции:

1. Берём фрагмент аудио (1–10 с).

2. Энкодер → RVQ → токены → декодер → восстановленное аудио.

3. Минимизируем разницу с оригиналом (spectral loss + adversarial loss от дискриминатора, как в GAN).

Данные: подкасты, аудиокниги, YouTube, звонки — без разметки. Это чистый самоконтроль, как предобучение LLM на тексте.

🛠️ Инженерная вставка: функция потерь кодека.

• — L1/L2 между mel-спектрограммами оригинала и реконструкции.

• — дискриминатор отличает настоящий звук от синтезированного.

• — штраф за «разброс» векторов в кодовой книге (стабильность RVQ).

5.3. Стадия 2: предобучение речевой LM

Здесь начинается главное. Берём десятки тысяч часов записанной речи, прогоняем через замороженный кодек, получаем последовательности токенов. Модель учится:

— предсказывать следующий токен речи. По форме это близко к задаче текстовой LLM, только «алфавит» — кодовая книга, а один момент времени может описываться несколькими уровнями RVQ.

Откуда данные:

• LibriLight (60 000+ часов аудиокниг, Meta)

• Common Voice, GigaSpeech, VoxPopuli

• Внутренние корпуса компаний (звонки, подкасты, видео с субтитрами)

Самоконтроль на речи: как в текстовых LLM текст сам себе учитель, так здесь речь сама себе учитель — правильный «следующий токен» уже записан в аудиофайле.

Тот же приём, что при обучении текстовых LLM, но для токенов речи — ch05_training_pairs.swift:

let speechTokens = [412, 891, 37, 204, 556]for i in 1..<speechTokens.count {    let context = Array(speechTokens[0..<i])   // всё, что слева    let target = speechTokens[i]                 // «правильный ответ» уже в записи    print("\(context) → \(target)")}

А функция потерь на каждом шаге — та же кросс-энтропия, что у текстовой LLM (ch05_cross_entropy.swift):

let probs = softmax(logits)            // P(следующий токен | контекст)let loss = -log(probs[trueToken]!)     // штраф, если модель не угадала

💡 Главная мысль: предобучение V2V — это «прочитать» десятки тысяч часов речи и научиться продолжать её правдоподобно. Отсюда рождается знание языка, акцента, просодии — без единой размеченной пары «вопрос-ответ».

5.4. Самоконтролируемые энкодеры (wav2vec, HuBERT)

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

• wav2vec 2.0 (Meta, 2020) — берёт сырую волну, маскирует случайные фрагменты её внутреннего представления и учится угадывать скрытое. Даёт мощные семантические представления.

• HuBERT (Meta, 2021) — кластеризует скрытые состояния и использует номера кластеров как псевдо-метки.

• w2v-BERT (Google, 2021) — объединяет контрастивное обучение wav2vec с масками в духе BERT; именно его токены ест AudioLM.

Эти энкодеры дают семантические токены (низкая частота) для иерархических моделей вроде AudioLM и Moshi. Их тоже предобучают на тысячах часов, затем замораживают или дообучают с малым learning rate.

5.5. Стадия 3: выравнивание речи и текста

Чтобы модель понимала смысл (а не только имитировала акустику), её учат на парах аудио + транскрипт:

• 10 000 часов подкастов с автоматическими субтитрами;

• LibriSpeech (1000 ч, чистые аудиокниги + текст);

• мультиязычные наборы (YODAS, MLS).

Задачи:

• ASR-подобная: предсказать текстовые токены по аудиотокенам.

• TTS-подобная: предсказать аудиотокены по тексту.

• Совместная: в одном контексте и речь, и текст — модель учится переключаться.

📜 Из истории: выравнивание — наследие десятилетий speech research. Whisper (OpenAI, 2022) показал, что масштабирование этой задачи на 680 000 часов даёт энкодер, который «понимает» речь на уровне, достаточном для V2V.

5.6. Стадия 4: SFT (supervised fine-tuning)

Предобученная модель умеет продолжать речь, но не вести диалог. SFT учит формат разговора — пары «реплика пользователя → реплика ассистента» в токенах речи:

struct DialogTurn {    let userTokens: [Int]    let assistantTokens: [Int]}let example = DialogTurn(    userTokens: [412, 891, 37],                    // «Какая погода в Барселоне?»    assistantTokens: [204, 556, 119, 88]          // «Сейчас +22, солнечно…»)// При SFT модель учится: после userTokens генерировать assistantTokens

Данные:

• Синтетические диалоги (LLM генерирует текст → TTS озвучивает → получаем пары).

• Реальные записи разговоров (с согласия участников).

• Актёрские записи с нужным стилем (дружелюбный, профессиональный).

Типичный объём: 10 000–100 000 диалогов — капля по сравнению с предобучением.

Отдельно забавно, что заметная часть «голосовых» диалоговых данных в индустрии — это текст, сгенерированный LLM и озвученный TTS: одни нейросети пишут учебники для других. Выглядит как змея, кусающая свой хвост, — но работает.

5.7. Стадия 5: RLHF и DPO

Финальная полировка — как в текстовых LLM:

1. Собирают оценки: какой голосовой ответ лучше (естественнее, точнее, безопаснее).

2. Обучают reward model на парах (хороший ответ, плохой ответ).

3. Дообучают политику (PPO в RLHF) или напрямую оптимизируют предпочтения (DPO).

Для V2V добавляются специфичные критерии:

• Естественность просодии (не робот).

• Очерёдность (не перебивать без причины).

• Краткость (не монологировать).

• Безопасность (не имитировать конкретных людей без разрешения).

⚠️ Частая ошибка: считать, что RLHF «делает модель умнее». RLHF делает модель удобнее и безопаснее для пользователя; фактические знания приходят в основном с предобучения и выравнивания. Для V2V RLHF ещё и учит манере — как говорить, а не только что.

5.8. Обучение turn-taking (очерёдность)

Отдельная подзадача — когда молчать, когда говорить. Человек не ждёт полной тишины: мы перебиваем, вставляем «угу», делаем паузы. Модели учат этому:

• На данных с перекрывающейся речью (два спикера говорят одновременно).

• С явными метками: <wait>, <speak>, <backchannel>.

• Через reinforcement: штраф за неуместное перебивание, награда за вовремя подхваченную реплику.

Moshi явно моделирует full-duplex, а realtime API вроде OpenAI Realtime и Gemini Live поддерживают turn-taking и barge-in на уровне сессии. В обоих случаях это результат целенаправленного обучения и инженерии, а не «само получилось» из предобучения.

6. Реальное время: стриминг и задержка

Текстовый ChatGPT может думать две секунды — вы не заметите. Голосовой собеседник, который молчит полсекунды, уже кажется «зависшим». В этой главе — инженерия низкой задержки: чанки, кэш, дуплекс и детектор голоса.

6.1. Почему задержка критична

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

Порог примерно в 300 мс я в своё время прочувствовал на живых звонках: выше него люди говорят с ботом как с рацией — дожидаются полной тишины и чеканят команды. Ниже — начинают перебивать, поддакивать и шутить, как с живым собеседником.

Текстовый LLM генерирует по одному токену (~20–50 мс на токен на GPU) — первый токен может появиться через 200–500 мс. Для речи нужно ещё время на синтез звука из токенов. Поэтому нативные V2V-модели проектируют с расчётом на стриминг с первого чанка.

6.2. Чанковая обработка

Вместо ожидания полной фразы пользователя система работает чанками (фрагментами по 80–240 мс аудио):

1. Микрофон непрерывно шлёт чанки по WebSocket.

2. Энкодер превращает каждый чанк в токены.

3. Трансформер дополняет контекст новыми токенами.

4. Как только модель «уверена» — начинает генерировать выходные токены.

5. Декодер синтезирует звук по мере поступления токенов (не ждёт конца фразы).

Симуляция чанков, endpointing и barge-in на Swift — ch06_streaming_chunks.swift:

struct AudioChunk { let durationMs: Int; let rmsEnergy: Double }func isSpeech(_ chunk: AudioChunk, threshold: Double = 0.15) -> Bool {    chunk.rmsEnergy > threshold}// Речь → +10 токенов в контекст (50 токен/с). 200 мс тишины после речи → endpoint:// генерируем ответ. Речь во время ответа → barge-in: глушим вывод, слушаем дальше.

💡 Главная мысль: стриминг V2V — это двойная авторегрессия: вход нарастает чанк за чанком, выход — токен за токеном. Оба потока идут параллельно, как два независимых «хвоста» одной модели.

6.3. KV-кэш

При каждом новом входном чанке трансформеру не нужно заново считать внимание над всем прошлым контекстом. Ключи (K) и значения (V) прошлых позиций кэшируются — та же техника, что ускоряет инференс текстовых LLM.

Без KV-кэша задержка росла бы линейно с длиной разговора: к 10-й минуте беседы модель бы «зависала». С кэшем — стоимость каждого нового чанка постоянна (пропорциональна длине чанка, а не всего диалога).

Оценка памяти на одну сессию — ch06_kv_cache_size.swift:

let kvBytes = 2 * numLayers * numHeads * headDim * seqLen * bytesPerFloat// Для 32 слоёв, контекст 4096, fp16 → ~2 ГБ на сессию

🛠️ Инженерная вставка: оценка памяти KV-кэша. Память ≈ . Для модели 7B, контекст 4096 токенов, fp16: порядка 1–2 ГБ на сессию; современные модели с GQA (группы голов делят одну пару K/V) укладываются в 4–8 раз меньше. Для продакшена с тысячами параллельных звонков это определяет стоимость инфраструктуры не меньше, чем FLOPs.

6.4. VAD и endpointing

VAD (voice activity detection) — детектор, который отличает речь от тишины и шума. Endpointing — решение «пользователь закончил фразу, пора отвечать».

В каскадных системах endpointing тривиален: ASR сообщает «финальный результат». В нативных V2V всё сложнее:

• Пользователь может сделать паузу внутри мысли — рано отвечать.

• Пользователь может ещё говорить — нельзя перебивать (или можно, если дуплекс).

Современные системы комбинируют:

• классический VAD (энергия сигнала, Silero VAD);

• learned endpointing — маленькая нейросеть на последних токенах контекста;

• правила (минимальная пауза 300 мс, максимальное ожидание 2 с).

6.5. Дуплекс в продакшене

Настоящий full-duplex (Moshi) — эталон живого overlap-разговора, но многие продакшен-API 2025–2026 работают как realtime S2S с быстрым переключением:

• Пока пользователь говорит — модель слушает (накапливает контекст).

• Когда VAD фиксирует конец фразы — модель генерирует ответ.

• Если пользователь перебивает — генерация прерывается, контекст обновляется.

OpenAI Realtime API и Gemini Live API поддерживают barge-in/interrupt: клиент или сессия могут остановить воспроизведение ответа при новом входящем аудио. Это практичный компромисс между истинным full-duplex и надёжностью.

⚠️ Частая ошибка: путать латентность сети с латентностью модели. WebSocket из Европы в US-east добавляет 80–150 мс RTT. Для V2V критично размещать inference близко к пользователю или использовать edge-ноды. 200 мс модели + 150 мс сети = уже 350 мс — на грани комфорта.

7. Примеры моделей — кто есть кто

Теория без имён — абстракция. Здесь — конкретные системы, которые вы можете попробовать или интегрировать через API. Для каждой — парадигма, сильные стороны и ограничения.

7.1. OpenAI Realtime API: gpt-realtime и GPT-Realtime-2

Одна из первых продакшен-ready нативных V2V-систем. Realtime API обрабатывает и генерирует аудио напрямую через одну модель/API — без явного конвейера ASR → LLM → TTS в середине. Поддерживает function calling голосом, переключение языка, прерывание ответа и работу с состоянием сессии. GPT-Realtime-2 добавил рассуждение GPT-5-класса, контекст 128k токенов и параллельные вызовы инструментов прямо посреди разговора.

Для разработчика: в WebSocket-режиме сессия использует события вроде input_audio_buffer.append и response.output_audio.delta; для браузерных голосовых агентов обычно удобнее WebRTC. Важно: это realtime S2S с barge-in, но не обязательно full-duplex в смысле Moshi.

📚 Ссылки: OpenAI Realtime API docs, анонс GPT-Realtime-2, -Translate и -Whisper (май 2026).

7.2. Google Gemini Live API

Gemini Live API принимает аудио, изображения и текст в непрерывной сессии — можно показать объект или экран и спросить голосом. Модель рассуждает и генерирует речь нативно в аудио — не через ASR→TTS в середине.

Отдельная сильная сторона — эмоции и просодия: режим affective dialog (в Gemini 2.5 Flash Live) подстраивает стиль ответа под тон пользователя; style control позволяет текстом задавать акцент, шёпот и выразительность. Подробно — в разделе 8.

📚 Ссылки: Gemini Live API docs, Affective dialog, Native audio capabilities.

7.3. Moshi (Kyutai)

Moshi — один из главных открытых референсов настоящего full-duplex. Модель генерирует свою речь, пока слушает вашу, и демонстрирует backchanneling («hm», «ok»). Предобучена на ~7 млн часов аудио, затем дообучена на реальных телефонных разговорах (корпус Fisher) и синтетических диалогах.

Сильные стороны: открытые веса, можно изучать и дообучать. Слабости: уступает закрытым API по общим знаниям и следованию сложным инструкциям.

📚 Ссылки: статья Moshi: a speech-text foundation model for real-time dialogue (Kyutai, 2024), репозиторий Moshi.

7.4. Sesame CSM (Conversational Speech Model)

Sesame (2025) строит разговорные модели с акцентом на просодию — паузы, вздохи, эмоциональные оттенки. Открытый CSM генерирует RVQ-коды Mimi из текстового и аудиоконтекста: Llama-backbone отвечает за основную последовательность, а компактный audio-decoder добирает аудиокоды. Это снижает задержку по сравнению с «плоским» предсказанием всех уровней кодека на каждом шаге.

🛠️ Инженерная вставка: CSM генерирует контекстно-уместную просодию, но не моделирует полный дуплекс (перебивания, overlap) — для этого нужны системы класса Moshi. См. SesameAILabs/csm.

7.5. Каскадные системы (базовая линия)

Не нативные V2V, но до сих пор основа продакшена:

Связка Whisper + GPT-класса + ElevenLabs — рабочий V2V-прототип за день разработки. Задержка выше, интонация беднее — но предсказуемость и логируемость выше. С такой связки начинался не один мой прод. Мигрируют потом по кусочку: сначала стриминговый TTS, потом более быстрый ASR — пока не упрёшься в потолок самой архитектуры.

7.6. Исследовательские предшественники

Эти работы заложили техники, которые вошли в продакшен 2024–2025.

💡 Главная мысль: ландшафт V2V в 2026 — три слоя: открытые исследовательские модели (Moshi, Ultravox, Sesame CSM), закрытые realtime API (OpenAI, Google), и каскады из лучших компонентов. Для прототипа начните с каскада; для продукта «как в фильме» — нативный realtime API, а для overlap-разговора ищите именно full-duplex архитектуру.

8. Эмоции и просодия — как V2V «чувствует» тон

«Спасибо» — одно слово. Но «Спа-си-бо» с восторгом и «спасибо…» с усталостью — для уха это разные реплики. Текстовая LLM видит одинаковые буквы; хорошая V2V-модель слышит разницу и отвечает соответственно. В этой главе — откуда берётся эмоция в голосовом AI и почему Gemini Live выделяется режимом affective dialog.

8.1. Смысл, просодия, эмоция — не путать

В речи есть три слоя, и V2V-модели работают с каждым по-своему:

Текстовая LLM после ASR получает в основном семантику. Просодия и эмоция в транскрипте обычно исчезают — отсюда роботичность каскадных ассистентов. Нативные V2V-модели стараются сохранить все три слоя, потому что на вход и выход идёт аудио, а не строка.

💡 Главная мысль: эмоция в V2V — это не отдельная «кнопка грусти» в интерфейсе. Это просодия в аудиотокенах: модель учится связывать тон входа со стилем выхода и кодировать оба в токенах речи.

8.2. Почему каскад эмоции теряет

Вспомним конвейер из раздела 2:

🎤 → ASR → «заказ опоздал» → LLM → «мне жаль» → TTS → 🔊

ASR выдаёт слова без:

• повышенной высоты голоса на «два дня»;

• вздоха перед фразой;

• ускоренного темпа.

LLM видит нейтральный текст и может угадать эмоцию только по словам — иногда верно, часто нет. TTS потом получает сухую строку «мне жаль» и озвучивает её «как получится», если явно не указать стиль.

Как эмоции добавляют в каскад:

1. Промпт к LLM — «пользователь раздражён, отвечай спокойно и эмпатично».

2. Теги / SSML в TTS — <prosody rate="slow">, emotion markers (зависит от движка).

3. Отдельный классификатор эмоций на аудио → метка → prompt для TTS (ElevenLabs, Cartesia и др.).

Работает, но это три места, где эмоция может сломаться, и задержка растёт.

Вживую сломанная цепочка выглядит так: классификатор уловил раздражение, LLM потерял его при пересказе, а TTS зачитал извинение жизнерадостным тоном промо-ролика. Кто собирал каскад «с эмоциями», тот эту сцену видел.

8.3. Как эмоции живут в нативной V2V

В сквозных и realtime-моделях эмоция «вшита» в архитектуру иначе.

Уровень 1: акустические токены

Нейронный кодек (раздел 3) кодирует не только фонемы, но и манеру произнесения — тембр, микропаузы, напряжение. Нижние уровни RVQ несут именно акустику. Модель, предсказывающая следующий токен речи, фактически выбирает не только «какое слово звучит дальше», но и как оно звучит.

Уровень 2: модель слышит входной тон

В нативном realtime аудиопоток пользователя попадает в трансформер целиком. Модель может различить: те же слова «всё нормально» сказаны спокойно или сквозь зубы. Это основа affective dialog (аффективный диалог) — ответ подстраивается под выражение и тон собеседника, а не только под лексику.

Уровень 3: явное управление стилем

Даже нативная модель принимает текстовые инструкции в сессии:

• system prompt: «ты — терпеливый репетитор»;

• style control (Gemini): «говори шёпотом», «с лёгким британским акцентом»;

• OpenAI Realtime: «спокойно и уверенно, пока решаешь проблему; добавь энергии при успехе».

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

📐 Аналогия: каскад — актёр, который получил сухой сценарий и сам додумывает, как играть. Нативная V2V — актёр на импровизации, который видел и слышал сцену перед ответом и подстраивает интонацию под партнёра.

8.4. Как этому учат на тренировке

Эмоции не появляются из предобучения «угадай следующий токен» сами по себе — нужны целенаправленные данные и полировка (см. раздел 5):

1. Корпуса с выразительной речью — подкасты, аудиокниги с актёрами, дубляж, call-центры (с согласия), синтетика от эмоциональных TTS.

2. SFT на диалогах — пары, где уместный ответ не только по смыслу, но и по манере: пользователь нервничает → ассистент мягче и короче.

3. RLHF / DPO — оценщики (люди или модели) ранжируют: «какой голосовой ответ звучит естественнее / уместнее / не раздражает».

4. Актёрские метки — в данных явно размечают стиль: <empathetic>, <cheerful>, или просто разные спикеры с разной манерой.

Sesame CSM и Gemini native audio делают ставку на то, что просодия зашита в токены — модель не «включает эмоцию» постфактум, а генерирует сразу выразительный аудиопоток.

🛠️ Инженерная вставка: что оптимизирует обучение. На уровне loss функции всё тот же — но контекст включает аудиовход пользователя. Модель штрафуется, если при раздражённом тоне входа она генерирует бодрый весёлый ответ на те же слова. Отдельного «emotion head» может не быть — стиль распределён по весам трансформера и кодека.

8.5. Gemini Live и affective dialog

Gemini Live API — наглядный пример нативной работы с эмоциями. В блоге Google о native audio (июнь 2025) прямо названы две связанные возможности:

• Affective dialog — модель реагирует на тон голоса пользователя; одни и те же слова при разной интонации ведут к разному стилю ответа.

• Style control — разработчик или пользователь текстом задаёт манеру: акцент, шёпот, экспрессия.

Для разработчиков в Live API есть флаг enable_affective_dialog в конфигурации сессии (см. capabilities guide). Включив его, вы просите модель подстраивать стиль ответа под выражение и тон входящего аудио.

// Псевдоконфиг сессии (идея, не полный API-клиент)struct LiveSessionConfig {    let responseModalities: [String] = ["AUDIO"]    let enableAffectiveDialog: Bool = true   // Gemini 2.5 Flash Live    let voiceName: String = "Kore"}

⚠️ Важный нюанс 2026: в таблице сравнения моделей affective dialog поддерживает Gemini 2.5 Flash Live Preview, а у Gemini 3.1 Flash Live Preview этой опции пока нет — зато другие фичи (thinking levels, иной формат событий). Перед продакшеном сверяйте capabilities конкретной модели, а не бренд «Gemini» в целом.

Демонстрация идеи на Swift (упрощённо, не внутренности Google) — ch08_emotion_prosody.swift:

func detectTone(_ hint: ProsodyHint) -> UserTone {    if hint.energyRms > 0.45 && hint.avgPitchHz > 180 { return .frustrated }    // ...}func responseStyle(for tone: UserTone) -> String {    switch tone {    case .frustrated: return "спокойнее, эмпатично, без назидательности"    case .excited:    return "энергичнее, короче фразы"    // ...    }}

В реальной Gemini вместо эвристик по pitch/energy работает нативное аудиопонимание внутри одной модели.

8.6. OpenAI Realtime и другие системы

OpenAI Realtime (gpt-realtime, GPT-Realtime-2) делает ставку на управляемую подачу: тон и манера задаются инструкциями сессии — «спокойно, пока решаешь проблему», «энергично подтверди успех». Отдельного маркетингового термина вроде «affective dialog» у OpenAI нет; это ближе к явному style control, но механизм тот же: модель генерирует аудиотокены с нужной просодией, а не текст + внешний TTS.

Moshi демонстрирует эмоцию через натуральность дуплекса — вздохи, «hm», смех в потоке; обучение на диалогах с overlap. Sesame CSM — через качество просодии в long-form речи, без полного дуплекса.

8.7. Ограничения — эмоции не безграничны

• Не психотерапевт: подстройка тона ≠ понимание психического состояния; для кризисных сценариев нужны жёсткие правила и эскалация к человеку.

• Культурные различия: «вежливый» тон в одной культуре звучит холодно в другой.

• Злоупотребления: эмоционально убедительный голос усиливает доверие к галлюцинациям (см. раздел 9).

• Стабильность: эмоциональность может плавать от сессии к сессии; в продакшене нужны тесты и фиксированные voice profiles.

⚠️ Частая ошибка: думать, что enable_affective_dialog = true заменяет продуктовый дизайн. Флаг включает способность модели; политика тона (формальный банк vs дружелюбный репетитор) всё равно задаётся system prompt, выбором голоса и RLHF-полировкой конкретного продукта.

📚 Ссылки:

• Gemini 2.5 native audio

• Live API capabilities — Affective dialog

• OpenAI GPT-Realtime-2 announcement

9. Ограничения, риски и будущее

Голосовой AI звучит волшебно — пока не попросишь его посчитать налоги на трёх языках с перебиваниями. В финальном разделе — честный разбор того, что V2V пока не умеет, и куда движется поле.

9.1. Технические ограничения

Знания и рассуждение. V2V-модели наследуют «эрудицию» от предобучения, но голосовой режим часто использует облегчённый inference path. Сложные задачи (математика, код, многошаговое планирование) надёжнее в текстовом режиме той же модели. Практический совет: гибрид «голос для диалога, текст для работы».

Длинный контекст. 30-минутный разговор = десятки тысяч аудиотокенов. KV-кэш растёт, качество может деградировать (как у текстовых LLM на длинных сессиях). Пока типичный голосовой сеанс — 5–15 минут.

Языки и акценты. Качество сильно зависит от представленности языка в обучающих данных. Английский и основные европейские языки — хорошо; редкие языки и сильные акценты — хуже.

Шум и канал. Телефония (8 kHz), Bluetooth-гарнитура, кафе с музыкой — всё это роняет качество. VAD может срабатывать ложно; ASR в каскаде путает слова.

9.2. Галлюцинации — теперь вслух

Текстовая LLM, придумавшая факт, хотя бы оставляет его в чате — вы можете перечитать. V2V-модель озвучит галлюцинацию уверенным голосом. Это опаснее:

• Пользователь не видит текст — сложнее проверить.

• Уверенная просодия усиливает доверие к ошибке.

• Нет ссылок и цитат в голосовом ответе.

Живьём это пробирает сильнее, чем на бумаге: выдуманную дозировку модель произносит тем же ровным доброжелательным тоном, что и часы работы аптеки. Ни запинки, ни «кажется».

⚠️ Частая ошибка: доверять голосовому ответу о фактах (даты, дозировки, юридические формулировки) без верификации. V2V — собеседник, не энциклопедия. Для критичных доменов нужен каскад с текстовым логом или явное «я не уверен, проверьте».

9.3. Безопасность и deepfake

V2V открывает новые векторы атак:

• Клонирование голоса — VALL-E показал: 3 секунды образца достаточно для узнаваемого синтеза. Защита: watermarking, consent-based voice profiles, детекторы синтеза.

• Социальная инженерия — живой голос в телефоне убедительнее текста.

• Jailbreak голосом — интонация и паузы могут обходить текстовые фильтры.

Регуляторы (EU AI Act, FTC) всё активнее требуют маркировки синтетической речи.

9.4. Стоимость и инфраструктура

Нативный V2V дороже текста на тот же диалог:

• Аудиотокены плотнее текстовых (50 токен/с vs ~3 токен/с речи).

• Непрерывный стриминг держит GPU занятым всю сессию (не batch-запрос).

• KV-кэш ест память.

Ориентир 2026: у GPT-Realtime-2 миллион аудиотокенов стоит $32 на входе и $64 на выходе — в десятки раз дороже текстового входа тех же моделей, и самих токенов на ту же реплику уходит больше. Итог: минута голосового диалога через API обходится на 1–2 порядка дороже текстового эквивалента. Для массового продукта это определяет бизнес-модель (подписка, лимиты минут).

9.5. Что дальше

Несколько направлений, которые формируют 2026–2027:

1. Ещё ниже задержка — дистилляция, спекулятивное декодирование аудиотокенов, edge inference на NPU телефона.

2. Более зрелый turn-taking — от простого interrupt к настоящему full-duplex там, где он нужен.

3. Мультимодальность — голос + жесты + экран (Gemini Live уже показывает).

4. Персонализация — ваш голос, ваш стиль, ваша память — без дообучения всей модели (adapters, voice profiles).

5. Открытые веса — Moshi, Ultravox, Qwen3-Omni снижают порог входа для разработчиков.

💡 Главная мысль финала: V2V — не отдельная вселенная, а следующий слой на том же фундаменте, что и LLM: трансформер, предсказание токенов, предобучение на масштабе, RLHF для удобства. Если вы понимаете LLM — вы уже понимаете 80% V2V. Оставшиеся 20% — кодеки, просодия и борьба с миллисекундами.

Заключение

Мы прошли путь от звуковой волны до живого диалога:

• Звук сжимается нейронным кодеком в токены.

• Три парадигмы — каскад, сквозная LM, нативный realtime (а full-duplex — его сильнейшая форма) — решают компромисс между качеством, задержкой и контролируемостью.

• Обучение повторяет LLM: предобучение на масштабе, SFT, RLHF — плюс turn-taking.

• Инференс — стриминг чанков с KV-кэшем, VAD, борьба за < 300 мс.

Голосовой AI перестаёт быть фантастикой и становится инфраструктурой — как текстовый чат пять лет назад. Разобраться в механизме сейчас — значит не удивляться продуктам завтра.

📚 Что читать дальше:

• Книга «Как работает LLM» (А. Сапунов) — фундамент трансформеров и обучения.

• AudioLM, SoundStream, Moshi — статьи на arXiv (поиск по названию).

• Документация OpenAI Realtime API и Google Gemini Live — для практики.

• Hugging Face: модели kyutai/moshiko-*, fixie-ai/ultravox — открытые веса.