Qwen-MT Turbo: специализированный translation API от Alibaba и параметры extra_body, которые стандартные прокси могут терять

Новый qwen-mt-turbo от Alibaba Cloud приходит через OpenAI-совместимые endpoint, но его translation-контроли живут внутри extra_body — паттерн, который ломается на любом middleware, отрезающем нестандартные поля. Что нужно держать в голове routing-командам.

Опубликовано источник Qwen Blog

Архивный материал, подготовленный с помощью ИИ по указанному источнику и опубликованный без индивидуальной проверки. Ответственный редактор: Joe Werner.

Абстрактная диаграмма маршрутизации с многоязычными потоками текста, сходящимися через центральный gateway-узел
Машинный перевод с английского оригинала — читать оригинал

Главная развилка для большинства AI-инженерных команд при добавлении перевода в продукт: взять универсальный LLM с системным промптом или подключить специализированную translation-модель? Alibaba Cloud только что сделала второй вариант ощутимо привлекательнее — и попутно ввела небольшой routing-нюанс, который инфраструктурным командам стоит учесть.

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

Model Studio от Alibaba Cloud выкатил qwen-mt-turbo — новую версию модели машинного перевода Qwen-MT. Доступ идёт через OpenAI-совместимый endpoint (dashscope-intl.aliyuncs.com/compatible-mode/v1) стандартным OpenAI Python SDK или любым совместимым клиентом. Модель поддерживает 92 языка, обгоняет универсальные модели сопоставимого размера — GPT-4.1-mini и Gemini-2.5-Flash — на стандартных translation-бенчмарках и стоит $0.5 за миллион output-токенов, дешевле большинства универсальных frontier-моделей.

Ключевое техническое отличие от обычной chat-модели: translation-контроли передаются через extra_body, а не через system prompt или стандартные поля запроса.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DASHSCOPE_API_KEY",
    base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)

completion = client.chat.completions.create(
    model="qwen-mt-turbo",
    messages=[{"role": "user", "content": "第二个SELECT语句返回什么?"}],
    extra_body={
        "translation_options": {
            "source_lang": "Chinese",
            "target_lang": "English",
            "domains": "IT/software documentation; use technical register",
            "terms": [{"source": "语句", "target": "statement"}]
        }
    }
)

Блок translation_options открывает три важных для оператора рычага: принудительный глоссарий (внедрить терминологию, чтобы доменные термины переводились единообразно), домены/регистр (направить регистр — формальный, юридический, разговорный) и translation memory (заранее заданные пары сегментов, фиксирующие предпочтительные варианты перевода). Это пригождается для production-нагрузок, где фирменная терминология, юридические формулировки или технический жаргон должны быть консистентны на больших объёмах.

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

Командам, уже гоняющим translation-нагрузки через универсальные модели, эта модель предлагает достойный к оценке размен «цена/качество». При $0.5 за миллион output-токенов и паритете с GPT-4.1 на translation-задачах ценовой разрыв с крупными frontier-моделями ощутим.

Важнее, что это решение по маршрутизации к специализированной модели, а не drop-in замена. Вы не просто меняете имя модели — вы добавляете новую форму запроса. Механика extra_body хорошо поддержана в OpenAI Python SDK, но на уровне HTTP она невидима, пока ваш gateway явно не пробрасывает неизвестные top-level поля JSON в теле запроса.

Перевод — это ещё и нагрузка с большими батчами и чувствительностью к latency. Лёгкая MoE-архитектура, использованная Alibaba, удерживает response time ниже, чем у dense-моделей при сопоставимом качестве, — это критично, когда переводите user-generated контент в масштабе, обрабатываете документы в реальном времени или обслуживаете coding-агентов, которым нужен многоязычный вывод.

Угол router/operator

Проблема проброса extra_body. Любой middleware, который десериализует и пересобирает тело запроса — часть API-gateway, logging-прокси или routers со schema-валидацией — может тихо выкинуть поля extra_body. Если ваш routing-слой пробрасывает только распознанные поля OpenAI-запроса, translation_options будет срезан, и модель скатится к prompt-based inference без терминологического и доменного контроля. Прежде чем гнать production translation-трафик через любой прокси, проверьте, что gateway передаёт полное тело запроса или явно поддерживает проброс extra_body.

Политика маршрутизации на уровне провайдера. qwen-mt-turbo живёт на endpoint DashScope, а не на стандартном OpenAI base URL. Командам, управляющим multi-provider routing, придётся завести это как отдельную провайдерскую запись со своим base_url и ключом. Это не модель, к которой можно роутить просто переключением имени модели на существующем OpenAI-ключе — нужна отдельная конфигурация провайдера.

Дизайн fallback. Если Qwen-MT недоступна или квота исчерпана, естественный fallback — универсальная модель с translation-промптом. Деградация качества реальна, но ограничена — GPT-4.1 или Qwen3-235B справляются с переводом хорошо — однако принудительный глоссарий потеряется, если вы не воспроизведёте его в system prompt. Если консистентность переводов — требование продукта, прорабатывайте шаблон fallback-промпта заранее.

Маршрутизация по стоимости. При $0.5 за миллион output-токенов qwen-mt-turbo способна заметно срезать затраты на перевод по сравнению с frontier-моделями общего назначения для высокообъёмных нагрузок. Но это работает только если ваш billing-слой умеет корректно атрибутировать стоимость, когда вы разделяете translation- и reasoning/generation-трафик между разными провайдерами. Если у вас общая система биллинг-сверки, проверьте, что провайдерская атрибуция стоимости корректно работает в multi-provider маршрутизации.

Сплит endpoint Китай/глобал. Alibaba предоставляет и dashscope.aliyuncs.com (домашний), и dashscope-intl.aliyuncs.com (международный) base URL. Конфигурация маршрутизации должна выбирать подходящий endpoint исходя из того, откуда приходит трафик, — иначе получите штраф по latency и потенциальные compliance-нюансы.

За чем стоит следить или попробовать пользователям TheRouter

  • Проверить проброс extra_body: прежде чем гнать Qwen-MT translation-трафик через любой прокси-слой, отправьте тестовый запрос с translation_options и убедитесь, что модель отвечает с ожидаемым переводческим поведением (глоссарий учитывается, доменный регистр применяется). Если прокси режет extra_body, получите тихую деградацию качества без ошибок.
  • Завести Qwen-MT как именованного провайдера: добавьте endpoint DashScope как отдельную провайдерскую запись с моделью qwen-mt-turbo, отдельно от любой имеющейся универсальной конфигурации Qwen. Не полагайтесь только на маршрутизацию по имени модели.
  • Подготовить fallback-промпты: если routing-политика переключается на универсальную модель, держите наготове translation-промпт с ключевыми терминологическими парами — тогда качество деградирует мягко, а не молча.
  • Бенчмаркать до раскатки: сильная сторона Qwen-MT — на распространённых языковых парах (китайский, английский, японский, корейский, основные европейские). Для редких языков или сильно специализированных доменов сначала прогоните свой бенчмарк по фактической терминологии и регистру, прежде чем направлять туда production-трафик.
  • Считать токены и стоимость по провайдерам: translation-нагрузки обычно объёмные и тяжёлые по output. Настройте отслеживание стоимости по провайдерам, чтобы убедиться, что более дешёвая модель действительно даёт ниже эффективную цену при вашей планке качества.
Чёткая редакционная визуализация диаграммы маршрутизации моделей с qwen3.8-max в качестве узла верхнего уровня, абстрактные линии на матовом тёмном фоне

Qwen3.8-Max — теперь топовая модель DashScope: что смена флагмана меняет в вашей routing-политике

qwen3.8-max появился на DashScope: 2.4T параметров, 1M контекст и режим размышлений — а qwen3.7-max переведён в legacy. Что меняется для команд, маршрутизирующих трафик на флагманский уровень Qwen.

источник Alibaba Cloud
Абстрактная редакционная иллюстрация с развилкой маршрутизации, символизирующей совместимость OpenAI Responses API с эндпоинтами DashScope Qwen

DashScope OpenAI Responses API — compatible-mode/v1 теперь поддерживает Qwen с сохранением контекста и встроенными инструментами

DashScope OpenAI Responses API запущен на compatible-mode/v1 для моделей Qwen3.7-max, qwen3.6-plus, qwen3-coder-plus и др. Состоятельный previous_response_id, встроенный веб-поиск и интерпретатор кода, управление глубиной reasoning.effort, четыре глобальных региона.

источник Alibaba Cloud Model Studio
Абстрактная тёмная визуализация нейронной сети с расходящимися потоками данных, сходящимися к центральному вычислительному ядру, символизирующая работу автономного AI-агента

Qwen3.7-Max benchmarks: Terminal Bench 69.7, SWE-Pro лидерство и T-Head ZW-M890 PPU — 35 часов автономного запуска

Qwen3.7-Max benchmarks: Terminal Bench 2.0 → 69.7 (лидер), GPQA Diamond → 92.4, SWE-Pro и SWE-Multilingual лучшие оценки, KernelBench GPU 1.98×. T-Head ZW-M890 PPU — 35 часов непрерывной автономной работы агента. Routing-импликации для команд.

источник Alibaba Cloud
Помощь и контакты