MAI-Transcribe-2-Streaming vs Gemini 3.5 Transcribe Live: те же $9, другой компромисс

MAI-Transcribe-2-Streaming и Gemini 3.5 Transcribe Live стоят одинаково и построены на противоположных представлениях о том, для чего нужен потоковый транскрайбер. Обе оказываются примерно на уровне $9.00 за 1 000 минут потокового аудио. Модель Microsoft, выпущенная 1 октября 2026 года, — это инструмент точности: заявленная потоковая частота ошибок в словах 2,5% при 0,13 секунды до итоговой расшифровки; по собственным данным Microsoft, первая по точности как итоговых, так и частичных расшифровок, измеренная по методологии потоковой передачи Artificial Analysis, но ещё не отображённая строкой на этом табло. Другая модель, находящаяся в публичной предварительной версии с 26 августа 2026 года и обслуживаемая через Live API, — это инструмент охвата: 85+ языков с переключением в середине потока, бесплатный тариф и потоковая частота ошибок в словах 4,00% при 0,40 секунды — показатель, который для неё измеряет Artificial Analysis. Ни одна из них не является очевидным выбором, и причина в том, что на самом деле они не конкурируют за одну и ту же рабочую нагрузку.

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

Однострочная версия

• Точность и задержка — MAI-Transcribe-2-Streaming, согласно опубликованным цифрам. Microsoft заявляет 2,5 % потокового WER при 0,13 секунды до финальной расшифровки, первое место по точности как для финальных, так и для частичных расшифровок, и 2,5 % на первой частичной за 0,12 секунды. В противовес этому Artificial Analysis имеет Gemini 3.5 Transcribe Live с 4,00 % при 0,40 секунды. Заявленное преимущество Microsoft составляет 1,5 пункта и примерно в три раза быстрее до стабилизации. Оговорка в том, что трекер ещё не отобразил сам MAI-Transcribe-2-Streaming — текущий лидер таблицы — Grok Voice Transcribe 2.0 с 2,73 % и 0,49 секунды, а Muse Voice Transcribe — с 3,06 % и 0,16 секунды — так что 2,5 % — это цифра вендора, сопоставляемая с областью, которую трекер действительно измеряет. Это не близкий разрыв по оси, которую публикуют обе модели, но только одна её сторона публикуется независимо.

• Языковой охват — Gemini 3.5 Transcribe Live. 85+ языков с автоматическим определением и возможностью переключения языка в середине потока без перезапуска сеанса, что является главным заявлением Google для Live API. MAI-Transcribe-2-Streaming охватывает 60 языков с автоматическим непрерывным определением языка. Нижняя планка Microsoft выше; верхняя планка Google шире, и разрыв в 25 языков в основном приходится на языки, где одноязычная потоковая модель вообще неприменима.

• Форма сессии — Gemini 3.5 Transcribe Live, и здесь палка о двух концах. Live API — это сессия WebSocket с ограничением в 10 минут, что нормально для одной реплики голосового агента и неудобно для часовой встречи; Microsoft не публикует аналогичного ограничения длительности сессии для своей потоковой модели, а это важно, если единица вашей работы — звонок, а не разговорная реплика.

• Стоимость входа — Gemini 3.5 Transcribe Live. Есть бесплатный тариф, а комбинированная ставка Google при токеновой модели ценообразования составляет около $0,009 за минуту. $0,54 у Microsoft за час аудио — это вводная ставка, которая, по словам Microsoft, действует до конца года, при этом стандартная цена не раскрывается — та же структура, что и у сентябрьского запуска пакетной обработки.

Почему разрыв в точности больше, чем кажется

Разница в 1,5 процентного пункта в частоте ошибок в словах звучит как погрешность округления, пока не оценишь её в деньгах. При 4,00% потоковой WER Gemini 3.5 Transcribe Live ошибается примерно в 40 словах из 1000; при заявленных Microsoft 2,5% MAI-Transcribe-2-Streaming допускает 25 ошибок. На объёмах, которые выдаёт конвейер реального времени, — организация поддержки, обрабатывающая 5 000 часов звонков в месяц, это 300 000 минут, более 45 миллионов слов при разговорной скорости, — этот разрыв составляет миллионы неправильных слов в год, сосредоточенных в сущностях, от которых зависят нижестоящие системы: названиях аккаунтов, номерах заявок, дозировках, адресах.

Разницу в задержке продать сложнее. Разница в 0,13 секунды против 0,40 секунды после окончания речи ощутима в потоке живых субтитров — менее примерно 0,2 секунды воспринимается как одновременность, а треть секунды — как будто транскрипт догоняет говорящего, — но она неощутима в панели агент-ассиста, которая обновляется в человеческом временном масштабе. Если ваш потребитель — человек, читающий вслед, преимущество Microsoft по задержке — это и есть продукт. Если ваш потребитель — модель, получающая финальный транскрипт по завершении реплики, это просто число.

Оба показателя сопровождает одна и та же оговорка, и её стоит привести сразу: это результаты одного прогона из таблицы отслеживания, в которой 37 моделей, а разрыв между первым и третьим местом в этой таблице — меньше одного пункта. Повторный прогон может перетасовать верхнюю часть таблицы лидеров потоковых тестов так, как не способен сделать разрыв в два пункта в пакетной таблице. К тому же 2,5% Microsoft пока вообще нет в таблице — это заявление вендора, измеренное по методологии трекера, а это не то же самое, что строка, которую публикует трекер.

Ограничения — это то, где на самом деле живёт решение.

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

Gemini 3.5 Transcribe Live имеет три задокументированных ограничения: 10-минутный лимит сеанса в Live API, отсутствие диаризации говорящих и отсутствие временных меток на уровне отдельных слов. Первое — архитектурное: у потоковой передачи через сеанс WebSocket по своей конструкции есть потолок, — и это означает, что длительную живую транскрипцию приходится сшивать между сеансами, а обработка стыков остаётся на вас. Два оставшихся — абсолютны: если вашему продукту нужно приписывать речь конкретному говорящему или привязывать слово к временной метке для поиска либо синхронизации субтитров, Gemini 3.5 Transcribe Live не делает этого ни за какие деньги.

Ограничения MAI-Transcribe-2-Streaming менее задокументированы, и это само по себе информация. Microsoft не делает заявлений ни о диаризации для потоковой модели, ни о временных метках на уровне слов; пакетная MAI-Transcribe-2 включает диаризацию и возвращает временные метки на уровне слов, но это пакетный продукт, и предполагать, что потоковый SKU наследует их, — ровно тот тип вывода, который призваны предотвращать материалы запуска. Что Microsoft действительно заявляет, так это 60 языков с непрерывным определением языка и позиционирование на границе Парето по точности в сравнении с задержкой — оба заявления вендора, с которыми согласуются данные трекера.

Итак, честная оценка возможностей такова: ни одна из потоковых моделей не публикует данные о диаризации или временных метках слов. У Gemini 3.5 Transcribe Live есть опубликованное ограничение на длительность сессии и бесплатный тариф; у MAI-Transcribe-2-Streaming опубликовано количество языков, но нет опубликованного ограничения. Если ваши требования включают диаризацию, ни один из этих вариантов не подходит, и вы смотрите на пакетную транскрипцию с прикрученным спереди потоковым слоем.

Что на самом деле говорит вам паритет цен

То, что два поставщика приходят к одной и той же цене $9 за 1000 минут с противоположных сторон, — самый интересный факт в этом сравнении. Google пришёл к этому через ценообразование на основе токенов в сессии Live API: аудио на входе по $3.50 за миллион токенов, текст на выходе по $21 за миллион, и приблизительное потребление 175 текстовых токенов в минуту, что в сумме даёт около $0.009 в минуту. Microsoft пришла к этому, указав фиксированную цену $0.54 за аудиочас для модели из семейства, пакетный аналог которой стоит $0.10. Одна — это тарифицируемая сессия в реальном времени; другая — фиксированная поминутная ставка со вступительной скидкой.

Эти структуры ведут себя по-разному при масштабировании. Фиксированная ставка предсказуема, и её легко заложить в бюджет; сессия с оплатой по токенам зависит от того, сколько отвечает модель, и как долго сессия остаётся открытой в простое. Для высоконагруженного конвейера фиксированная ставка — более удобный счёт; для прототипа или низконагруженной функции бесплатный тариф и оплата по токенам — более удобный вариант для старта.

Что не меняет ни одна из этих структур — так это слой над транскриптом. Какая бы модель его ни создавала, живой транскрипт служит входными данными для суммаризации, классификации, удаления конфиденциальной информации и маршрутизации, и у этих этапов свои кривые затрат и качества — обычно они выполняются на нескольких моделях, а не на одной. Именно этот слой охватывает OrcaRouter: единый API для более чем 200 моделей, прайс-листовые цены провайдеров, передаваемые с наценкой 0%, автоматическое переключение при сбое и DSL маршрутизации, который может направлять транскрипт по разным моделям в зависимости от рабочей нагрузки. Ни MAI-Transcribe-2-Streaming, ни Gemini 3.5 Transcribe Live не входят в этот список — они обслуживаются через собственные речевые стеки Microsoft и Google соответственно — и смысл не в том, чтобы маршрутизировать их, а в том, чтобы сохранить переносимость всего, что идёт после них.

Какой выбрать?

Выбирайте MAI-Transcribe-2-Streaming, когда продукт — это точность и время стабилизации: живые субтитры, которые читает человек, оценка соответствия требованиям или качества в реальном времени, где ошибка в распознанной сущности чего-то стоит, или длинные сессии, которые из-за 10-минутного потолка Gemini пришлось бы сшивать вручную. Выбирайте Gemini 3.5 Transcribe Live, когда продукт — это охват: глобальное развёртывание на языках, которые вы не можете перечислить заранее, переключение языка посреди потока или прототип, где бесплатный тариф и оплата за токены снимают необходимость брать на себя обязательства. Команды, которым нужно и то и другое, не в тупике — это два разных API с разными моделями сессий, и честная архитектура состоит в том, чтобы маршрутизировать по типу нагрузки, а не стандартизироваться на одном из них.

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