Qwen3.5-Omni S2S: голосовой роутинг через DashScope

Самое сложное решение при построении голосового AI-pipeline — не выбор конкретной модели, а выбор архитектуры. Alibaba Cloud DashScope формализовал эту дилемму с семейством Qwen3.5-Omni: полный стек speech-to-speech (S2S) с WebSocket realtime API и HTTP batch-режимом на четырёх региональных endpoint'ах. Выбор между S2S и классическим ASR → LLM → TTS pipeline затрагивает роутинг, задержку, observability и fallback — и последствия этого выбора переживут любую смену модели.

Что произошло

Alibaba Cloud Model Studio (百炼/DashScope) опубликовал полное руководство по S2S, выведя в production три семейства моделей:

• Qwen3.5-Omni (qwen3.5-omni-plus и qwen3.5-omni-flash): флагманские мультимодальные модели с поддержкой текста, аудио, изображений и видео; function calling и веб-поиск; 29 языков вывода. Доступны через WebSocket (суффикс -realtime) и HTTP.
• Qwen3.5-Livetranslate (qwen3.5-livetranslate-flash-realtime): специализированная модель синхронного перевода, 60 языков, задержка около 3 секунд, работает через WebSocket.
• Qwen3-Omni-Flash (qwen3-omni-flash): облегчённый вариант только с HTTP, добавляет режим глубокого рассуждения (thinking mode) при более низкой стоимости; 11 языков вывода.

Для команд, которым нужна стабильность, доступны датированные алиасы (qwen3.5-omni-plus-2026-03-15). Документация quickstart теперь явно указывает четыре региональных base URL:

https://dashscope.aliyuncs.com/compatible-mode/v1          # Пекин (Китай)
https://dashscope-us.aliyuncs.com/compatible-mode/v1       # Вирджиния (США)
https://dashscope-intl.aliyuncs.com/compatible-mode/v1     # Сингапур
https://<WorkspaceId>.eu-central-1.maas.aliyuncs.com/compatible-mode/v1  # Франкфурт (ЕС)

Эти endpoint'ы не взаимозаменяемы — каждый регион использует отдельный base URL, а франкфуртский endpoint требует поддомена уровня workspace. Любой универсальный DashScope-прокси, жёстко прописывающий пекинский endpoint, будет давать тихие ошибки при роутинге за пределы Китая.

Почему это важно для AI-команд

Выбор между S2S и Pipeline — архитектурное решение, а не просто замена модели:

Pipeline выигрывает, когда нужна точная кастомизация голоса (CosyVoice), независимое A/B-тестирование LLM или SLA-мониторинг на уровне этапов. S2S выигрывает для realtime-диалогов, колл-центровых ботов и синхронного перевода, где сквозная задержка и восприятие эмоций важнее, чем заменяемость компонентов.

Function calling и веб-поиск доступны только в Qwen3.5-Omni — ни в Livetranslate, ни в realtime-режиме Qwen3-Omni-Flash их нет. Если агент должен вызывать инструменты внутри голосового цикла, Qwen3.5-Omni — единственный вариант на DashScope.

Региональная архитектура endpoint'ов важна и для compliance-чувствительных нагрузок: требования к резидентности данных в ЕС предполагают использование франкфуртского workspace-endpoint, а не просто маршрутизацию через региональный CDN. Команды, работающие через универсальный DashScope-прокси, должны убедиться, что провайдер прозрачно обрабатывает региональный роутинг.

Router/operator-угол

Несколько неочевидных операционных последствий этого API:

1. Фрагментация протоколов. Realtime WebSocket API отделён от стандартного OpenAI-compatible /v1/chat/completions. Большинство роутеров и прокси не смогут направить запрос к qwen3.5-omni-plus-realtime без явной поддержки WebSocket. Поддержка S2S-роутинга — это ворота по capability, а не просто смена provider.

2. Регионально-осведомлённый роутинг. Многорегиональная модель DashScope требует, чтобы router знал региональный endpoint каждого ключа: base URL'ы структурно различаются (франкфуртский использует workspace-поддомен). Простая ротация ключей без учёта их регионального происхождения приведёт к тихим ошибкам аутентификации.

3. Датированные алиасы моделей. Как и другие семейства DashScope, Qwen3.5-Omni предоставляет датированные алиасы (-2026-03-15). Команды, чувствительные к дрейфу поведения, должны фиксировать версии для голосовых агентов; команды, желающие автоматических улучшений, могут оставаться на последнем алиасе, но должны покрыть регрессионными тестами качество голосового вывода.

4. Режим thinking только в HTTP. Qwen3-Omni-Flash (только HTTP) поддерживает thinking mode; Qwen3.5-Omni — нет. Если голосовому pipeline нужна глубокая логика рассуждений внутри петли ответа, это вынуждает использовать не-realtime облегчённую модель — неочевидный компромисс, который должен быть явно задокументирован в политике роутинга.

5. Fallback с учётом capability. Цепочка fallback, включающая Qwen3.5-Omni и текстовую модель, должна проверять, содержит ли входящий запрос аудио. Тихая маршрутизация голосового запроса к текстовому fallback'у усекает мультимодальный контент и может давать результат хуже, чем явная ошибка.

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

S2S realtime-путь требует WebSocket-роутинга, архитектурно отличного от стандартного /v1/chat/completions. Команды, оценивающие DashScope Omni API, должны явно проверить свой routing-слой:

• Поддерживает ли ваш provider-прокси WebSocket upgrade для DashScope realtime endpoint?
• Настроены ли региональные DashScope base URL как отдельные provider'ы, а не как единый пул с ротацией ключей?
• Если первый provider в fallback-цепочке возвращает ошибку протокола, 5xx или несовместимость capability — как ведёт себя ваша fallback-логика?

Для команд, уже использующих DashScope для текстовых моделей (через документацию TheRouter по DashScope/Qwen), первостепенное действие — определить, какие нагрузки выиграют от S2S, и проверить доступность нужного регионального endpoint в текущей конфигурации роутинга. Франкфуртский EU endpoint с workspace-поддоменом наиболее уязвим к сбоям при использовании naive-прокси.

Qwen3.5-Livetranslate заслуживает отдельного внимания для команд, строящих многоязычные workflow: 60 языков при задержке около 3 секунд с WebSocket API, близким к OpenAI-compatible, — это существенный выигрыш по стоимости и задержке по сравнению с Pipeline-подходом, особенно для языковых пар Восточной и Юго-Восточной Азии, где старый qwen-omni-turbo поддерживал только китайский и английский.