Qwen3.5-Omni API: цены, лимиты и варианты развёртывания (2026)

Привет! Это Дора — делюсь своим удивлением, когда в конце марта увидела выход Qwen3.5-Omni. В тот момент моей первой мыслью было не «вау, крутая модель», а: во сколько мне это реально обойдётся за вызов?

Потому что всё дело вот в чём — я уже обжигалась. Я строила пайплайн на блестящем новом мультимодальном API, недостаточно внимательно прочитала документацию по тарификации, а потом наблюдала, как мой ежемесячный счёт вырос в четыре раза, когда обработка аудио вышла на диапазоны длинного контекста. Поэтому на этот раз я села с документацией по ценам DashScope и официальным справочником API, прежде чем написала хотя бы одну строчку кода интеграции.

Если вы технический руководитель или ответственный за инфраструктуру и оцениваете, строить ли на Qwen3.5-Omni или разворачивать самостоятельно, — здесь разобрано то, что действительно важно для вашей модели затрат, включая структуру ценообразования, которая по-настоящему неочевидна, пока не разберёшься в ней как следует.

Как устроено ценообразование Qwen3.5-Omni

Многоуровневое ценообразование DashScope: модель на основе входных токенов

Самое важное, что нужно понять сразу: DashScope не берёт фиксированную цену за токен. Для Qwen3.5-Omni (и ряда других моделей Qwen, включая qwen3.5-plus) ценообразование многоуровневое — в зависимости от количества входных токенов в текущем запросе. Не от накопленных токенов сессии — именно размер входных данных одного запроса определяет, в какой тарифный диапазон вы попадаете.

Это неочевидно и имеет реальные последствия. Короткий запрос на 5К токенов и запрос, заполняющий 240К токенов, оцениваются не просто пропорционально иначе — они попадают в совершенно разные тарифные диапазоны. Структура поощряет короткие запросы, что может напрямую противоречить причине, по которой вы вообще обращаетесь к модели с контекстом 256К.

Официальная страница цен DashScope показывает эту многоуровневую структуру применительно к Qwen-Plus и родственным семействам моделей. Конкретное ценообразование Omni-модальности за аудиотокен и видеокадр задокументировано отдельно в разделе мультимодального биллинга.

Plus vs. Flash vs. Light: соотношение цены и производительности

Qwen3.5-Omni поставляется в трёх вариантах с чётким позиционированием:

Plus — это флагманская модель для бенчмарков: именно она превзошла Gemini 3.1 Pro в понимании аудио. Flash жертвует частью этих возможностей ради меньшей задержки и, предположительно, более низкой стоимости вызова. Light — это уровень с открытыми весами: бесплатно запустить, но инфраструктура на вас.

Для пользователей API практический выбор — это Plus против Flash. Если ваша задача — высокоточная транскрипция длинных записей или клонирование голоса для клиентского продукта, нужен Plus. Если вы занимаетесь диалогом в реальном времени с жёсткими требованиями по задержке, стоит сначала протестировать Flash.

Бесплатная квота: что включено и когда заканчивается

Новые аккаунты DashScope в Международном регионе (конечная точка в Сингапуре) получают бесплатную квоту в размере 1 миллиона входных токенов и 1 миллиона выходных токенов, действительную 90 дней с момента активации Model Studio. Режим развёртывания Global (US Virginia) не имеет бесплатной квоты — это важно, если ваша команда находится в США и хочет тестировать с ближайшей конечной точки.

Потратить эту бесплатную квоту можно быстрее, чем ожидаешь, если проводить тесты с большим объёмом аудио. Один аудиофайл длиной 10 часов упирается в предел контекста 256К, что за один запрос израсходует примерно 256К из вашей квоты в 1М входных токенов.

Экономика контекстного окна

256К токенов на практике: часы аудио, секунды видео и реальная стоимость

Официальная цифра: 256К токенов обрабатывает «более 10 часов непрерывного аудио» или «около 400 секунд видео 720p с аудио». Переведём это в интуитивное понимание стоимости.

Аудио токенизируется примерно с плотностью 25 600 токенов на час (256К ÷ 10 часов). Это примерно 427 токенов на минуту аудио. Для видео при частоте дискретизации 1 кадр/с 400 секунд контента 720p заполняют весь контекст.

Сопоставив это с тарифными диапазонами, рассмотрим два сценария:

Короткий запрос (например, 5-минутный фрагмент совещания ≈ ~2 100 токенов): Попадает в нижний тарифный диапазон. Дёшево за вызов.

Длинный запрос (например, 3-часовой подкаст ≈ ~77 000 токенов): Переходит в средний тарифный диапазон. Цена за токен возрастает, поэтому стоимость минуты аудио заметно выше, чем в сценарии с коротким запросом, — не потому что используется больше токенов, а потому что диапазон другой.

Запрос, близкий к максимальному (например, 8-часовой аудиофайл ≈ ~205 000 токенов): Вы в самом высоком диапазоне. Обработка полного рабочего дня аудио по ценам верхнего диапазона обойдётся значительно дороже, чем 40 эквивалентных 12-минутных клипов, обработанных по отдельности. Это архитектурное решение, которое навязывает многоуровневая модель: пакетная обработка длинных входных данных против разбивки на фрагменты.

Для разработчиков, обрабатывающих большие объёмы аудио, разбивка на части может быть дешевле, чем использование полного контекстного окна, — что иронично, поскольку большой контекст отчасти и является ключевым преимуществом.

Когда длинный аудиовход становится дорогим

Существует точка безубыточности где-то между коротким и длинным контекстом, где разбивка на части выигрывает по стоимости. Точные цифры зависят от конкретных цен на вашу модальность (цены на аудиотокены в биллинге DashScope отличаются от цен на текстовые токены), поэтому перед фиксацией архитектуры рекомендую сделать быстрый расчёт: прогоните ожидаемое распределение длины аудио через формулу многоуровневого ценообразования и через подход на основе фрагментов.

Ограничения скорости и пропускная способность

Что известно об ограничениях QPS / параллелизма

Подробности ограничений скорости для Qwen3.5-Omni не задокументированы публично так же детально, как для текстовых моделей. Общий подход DashScope для пользователей API — ограничения QPS (запросов в секунду) и параллелизма на уровне аккаунта, которые можно увеличить через запросы на повышение квоты для корпоративных аккаунтов. Если вам нужны подтверждённые цифры для планирования мощностей, направьте запрос на увеличение квоты в службу поддержки DashScope — они ответят с реальными ограничениями для вашего уровня аккаунта.

Международные конечные точки DashScope vs. Китайский mainland

Для команд за пределами Китая нужно знать о трёх основных регионах конечных точек:

International (Сингапур): https://dashscope-intl.aliyuncs.com/compatible-mode/v1 — данные и конечная точка в Сингапуре, инференс распределяется глобально (исключая материковый Китай). Это стандарт для большинства международных разработчиков. Бесплатная квота применяется.
Global (US Virginia / Германия Франкфурт): https://dashscope-us.aliyuncs.com/compatible-mode/v1 — данные и конечная точка в регионе US Virginia, вычисления распределяются глобально. Бесплатной квоты нет. Лучше для требований по задержке в США.
Mainland China (Пекин): https://dashscope.aliyuncs.com/compatible-mode/v1 — ограничено командами, работающими в Китае. Значительно более низкая цена за токен.

Доступность в регионе США (конечная точка Virginia)

Конечная точка US (Virginia) доступна для текстовых моделей Qwen. По состоянию на сегодняшний день уточните напрямую через справочник API DashScope, маршрутизируется ли мультимодальный инференс Qwen3.5-Omni через конечную точку в США или откатывается к Сингапуру. Общий шаблон мультимодальной конечной точки:

POST https://dashscope-us.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation

Для команд с требованиями к локализации данных уточните у Alibaba Cloud, хранится ли аудио/видеоконтент, обрабатываемый через конечную точку в США, за пределами США на каком-либо этапе инференс-пайплайна.

Самостоятельное развёртывание с vLLM

Почему команда Qwen рекомендует vLLM вместо HuggingFace Transformers для MoE

Qwen3.5-Omni-Plus использует архитектуру Hybrid-Attention Mixture-of-Experts (MoE). Команда Qwen явно рекомендует vLLM вместо HuggingFace Transformers для любых производственных нагрузок — и причина специфична для MoE: маршрутизация экспертов в MoE-моделях вызывает нерегулярные паттерны доступа к памяти, которые HuggingFace Transformers не оптимизирует должным образом. PagedAttention vLLM и MoE-aware-планирование справляются с этим значительно лучше, что выражается в реальных различиях пропускной способности под нагрузкой. Для крупномасштабных вызовов или требований к низкой задержке официальная рекомендация — vLLM или напрямую API DashScope, но не чистый Transformers.

Требования к инфраструктуре для Plus (класс 30B-A3B)

Вариант Plus (30B параметров всего, 3B активных на токен) требует не менее 40 ГБ VRAM для комфортного инференса в BF16. На практике:

Одна A100 80GB: Жизнеспособна для Plus в квантизации FP8 или INT8. BF16 при полном контексте — впритык.
Одна H100 80GB: Комфортно в BF16 с запасом для KV-кэша при коротких контекстах.
RTX 4090 (24GB): Недостаточно для Plus. Работает для Flash или Light-вариантов с квантизацией.

Для Omni-моделей конкретно нужно также учитывать память аудиокодека компонента Talker — это не только веса языковой модели. По сообщениям, RTX 4090D с 48 ГБ VRAM запускает Qwen3-Omni 30B-A3B при AWQ 4-битной квантизации, но с минимальным запасом для KV-кэша и пропускной способностью генерации около 64 токенов/с.

Доступность образа Docker и настройка

Команда Qwen предоставляет образ Docker, в котором собран полный рантайм как для HuggingFace Transformers, так и для vLLM. Используйте его — ручная настройка Omni-специфичного форка vLLM (ветка qwen3_omni) — дело хлопотное. Установка с официальным стеком:

# Клонировать Omni-специфичный форк vLLM
git clone -b qwen3_omni https://github.com/wangxiongts/vllm.git
cd vllm

# Установить зависимости
pip install -r requirements/build.txt
pip install -r requirements/cuda.txt
VLLM_USE_PRECOMPILED=1 pip install -e . -v --no-build-isolation

# Установить необходимые пакеты
pip install transformers==4.57.3 accelerate
pip install qwen-omni-utils -U
pip install -U flash-attn --no-build-isolation

Затем запустить сервер:

vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

Ограничение max-model-len 32768 практично для однографических карточных сетапов — расширение к контексту 256К на одной карте 80 ГБ требует агрессивной квантизации и существенно ограничивает размер батча. Согласно собственной документации vLLM по развёртыванию, PagedAttention эффективно управляет памятью KV-кэша, но аудиовизуальные модели с многокодовыми выходами Talker оказывают большее давление на KV-кэш, чем текстовые аналоги.

DashScope API vs. самостоятельное развёртывание: фреймворк принятия решений

Когда DashScope оправдан

Вам нужно выйти в продакшн за дни, а не за недели
Ежемесячный объём токенов — менее ~50М токенов (экономика единицы API ещё выгодна)
У вас нет GPU-инфраструктуры и нет желания её создавать
Важна функция клонирования голоса — она доступна только через API для Plus и Flash; открытые веса Light её не предоставляют
Вам нужна маршрутизация данных через регионы Сингапур или США с договорными гарантиями

Когда самостоятельное развёртывание оправдано

Ежемесячный объём стабильно превышает 50–100М токенов и цена за токен существенна
Требования к локализации данных, которые региональные конечные точки DashScope не удовлетворяют
Контроль задержки для целевых показателей ответа менее 200 мс, зависящих от совместного размещения
Вы запускаете нагрузки уровня Flash или Light, где оборудование вписывается в существующий парк
Пользовательская тонкая настройка или модификации модели (возможны только с открытыми весами — уровень Light)

Практическая точка перелома: при высоком объёме запуск Plus на выделенном H100 при стоимости облачных вычислений ~$2–3/час становится дешевле, чем тариф DashScope за вызов. Математика меняется в зависимости от утилизации — GPU, простаивающий 40% времени, существенно меняет расчёты.

Скрытые факторы стоимости

Накладные расходы на предобработку аудио/видео

Аудио, отправляемое в Qwen3.5-Omni, должно быть в правильном формате перед обращением к API. Библиотека qwen-omni-utils обрабатывает ресемплинг, нормализацию каналов и кодирование фрагментов — но эта предобработка добавляет задержку и вычислительные затраты на вашей стороне. Для видео задокументированная референсная частота — 1 кадр/с при 720p, но фактическое извлечение кадров из произвольных видеоформатов требует FFmpeg или аналога. Учтите это в вашем бюджете задержки на вызов.

Потоковый речевой вывод и стоимость вызова

Архитектура Thinker-Talker передаёт речевой вывод в реальном времени — первые аудиобайты поступают до завершения генерации полного ответа, что делает живой голосовой диалог естественным. Но потоковая передача добавляет накладные расходы на вызов: соединения остаются открытыми дольше, а аудиокодек (рендерер Code2Wav) генерирует последовательности с несколькими кодовыми книгами, что вносит вклад в количество выходных токенов. Если вы используете режим речевого вывода, эффективное количество выходных токенов выше, чем в текстовом режиме для того же базового ответа. Проверьте, тарифицирует ли DashScope токены речевого вывода по той же ставке, что и текстовые токены, — документация по биллингу разграничивает модальности в разделе мультимодального ценообразования.

Часто задаваемые вопросы

Есть ли бесплатный уровень для Qwen3.5-Omni на DashScope?

Да, для Международного региона (конечная точка в Сингапуре). Новые аккаунты получают 1М входных токенов и 1М выходных токенов бесплатно, действительные 90 дней с момента активации Model Studio. Режим развёртывания Global (US Virginia) бесплатной квоты не имеет.

Каковы ограничения скорости в API DashScope?

По состоянию на март 2026 года конкретные цифры QPS для Qwen3.5-Omni публично не задокументированы. При создании аккаунта применяются стандартные ограничения; свяжитесь со службой поддержки DashScope с указанием ожидаемой пропускной способности, чтобы запросить увеличение квоты перед выходом в продакшн.

Можно ли запустить Qwen3.5-Omni-Plus на одной A100?

В квантизации FP8 или INT8 — да: A100 80GB может запустить Plus с ограниченным запасом для KV-кэша. В BF16 при контексте 256К — нет. На одном GPU 80 ГБ стоит ожидать ограничения max-model-len на уровне примерно 32К–64К для поддержания стабильной пропускной способности.

Предыдущие статьи: