Qwen-MT Turbo: Alibaba's Dedicated Translation API Introduces extra_body Routing Parameters That Standard Proxies May Drop
Alibaba Cloud's new Qwen-MT turbo model arrives via OpenAI-compatible endpoints, but its translation controls live inside extra_body — a pattern that breaks any middleware that strips non-standard fields. Here's what routing teams need to watch.

The decision most AI engineering teams face when adding translation to a product is: use a general-purpose LLM with a system prompt, or wire in a dedicated translation model? Alibaba Cloud just made the second option meaningfully more attractive — while quietly introducing a routing wrinkle that infrastructure teams need to account for.
What happened
Alibaba Cloud's Model Studio has released qwen-mt-turbo, a new version of its Qwen-MT machine translation model. It is accessed through an OpenAI-compatible endpoint (dashscope-intl.aliyuncs.com/compatible-mode/v1) using the standard OpenAI Python SDK or any compatible client. The model supports 92 languages, outperforms comparably-sized general-purpose models like GPT-4.1-mini and Gemini-2.5-Flash on standard translation benchmarks, and prices at $0.5 per million output tokens — cheaper than most general-purpose frontier models.
The key technical departure from a plain chat model: translation controls are injected via extra_body, not via system prompt or standard request fields.
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"}]
}
}
)
The translation_options block unlocks three operator-relevant controls: terminology enforcement (inject a glossary so domain terms translate consistently), domain prompts (steer register — formal, legal, conversational), and translation memory (pre-supplied segment pairs to lock in preferred translations). These are useful for production workloads where brand terminology, legal phrasing, or technical jargon must be consistent across large batches.
Why it matters for AI engineering teams
For teams already running translation workloads through general-purpose models, this model offers a cost-performance trade worth evaluating. At $0.5/M output tokens with benchmark parity against GPT-4.1 on translation tasks, the price differential against larger frontier models is substantial.
More importantly, this is a specialized-model routing decision, not a drop-in swap. You are not just switching the model name — you are adding a new request shape. The extra_body mechanism is well-supported in the OpenAI Python SDK, but it is invisible at the HTTP level unless your gateway explicitly forwards unknown top-level JSON fields in the request body.
Translation is also a workload with high batch volume and latency sensitivity. The lightweight MoE architecture Alibaba used here keeps response times lower than dense models at similar quality, which matters when translating user-generated content at scale, processing documents in real time, or powering coding-agent workflows that need multi-language output.
The router/operator angle
The extra_body forwarding problem. Any middleware that deserializes and re-serializes the request body — including some API gateways, logging proxies, or schema-validating routers — may silently drop extra_body fields. If your routing layer only forwards recognized OpenAI request fields, translation_options will be stripped and the model will fall back to prompt-based inference without terminology or domain controls. Before routing production translation traffic through any proxy, verify that your gateway passes the full request body or explicitly supports extra_body forwarding.
Provider-level routing policy. Qwen-MT turbo lives at a DashScope endpoint, not the standard OpenAI base URL. Teams managing multi-provider routing need to handle this as a named provider entry with its own base_url and key. It is not a model you can route to by switching the model name on an existing OpenAI-keyed provider — it requires a separate provider configuration.
Fallback design. If Qwen-MT is unavailable or quota-exhausted, the natural fallback is a general-purpose model with a translation system prompt. The quality degradation is real but bounded — GPT-4.1 or Qwen3-235B handle translation well — but terminology enforcement will be lost unless you replicate the glossary in the system prompt. Plan your fallback prompt template now if translation consistency is a product requirement.
Cost routing. At $0.5/M output tokens, Qwen-MT turbo can significantly reduce translation costs versus general-purpose frontier models for high-volume workloads. But this only works if your billing layer can attribute cost accurately when you split translation vs. reasoning/generation traffic across different providers. If you're running a shared billing reconciliation system, verify that your provider-level cost attribution handles multi-provider routing correctly.
China/global endpoint split. Alibaba provides both dashscope.aliyuncs.com (domestic) and dashscope-intl.aliyuncs.com (international) base URLs. Your routing config should select the appropriate endpoint based on where your traffic originates to avoid latency penalties and potential compliance considerations.
What TheRouter users should watch or try
- Verify
extra_bodypass-through: Before routing Qwen-MT translation traffic through any proxy layer, send a test request withtranslation_optionsand confirm the model responds with the expected translation behavior (terminology respected, domain register applied). If the proxy stripsextra_body, you will get silent quality degradation with no error. - Configure Qwen-MT as a named provider: Add the DashScope endpoint as a distinct provider entry with model
qwen-mt-turbo, separate from any existing Qwen general-purpose provider config. Do not rely on model-name routing alone. - Plan fallback prompts: If your routing policy fails over to a general-purpose model, prepare a translation system prompt that includes your key terminology pairs, so quality degrades gracefully rather than silently.
- Benchmark before routing at scale: Qwen-MT's strength is on common language pairs (Chinese, English, Japanese, Korean, major European languages). For less common languages or highly specialized domain text, run your own benchmark against the actual terminology and register you need before committing production traffic.
- Track token costs per provider: Translation workloads are typically high-volume and output-heavy. Set up per-provider cost tracking to validate that the cheaper model is actually delivering lower effective cost at your quality bar.
Related
Latest AI News →
Qwen3.7-Max Launches with Top Agent Benchmarks: What Routing Teams Need to Know
Alibaba Cloud's Qwen3.7-Max claims the top spot on Terminal Bench 2.0, outperforms Claude Opus 4.6 on GPQA Diamond, and completes a 35-hour autonomous agent task on novel hardware. Here's the operator angle for teams routing Qwen traffic.

DeepSeek Now Speaks Anthropic: What the New Dual-Format API Means for Your Routing Layer
DeepSeek's API now accepts Anthropic SDK format at api.deepseek.com/anthropic — meaning Claude Code, the Anthropic Python/TS SDK, and any Anthropic-native client can now route requests to DeepSeek V4 models without an OpenAI wrapper.

Qwen-Image on DashScope: What the New Image Generation and Editing APIs Mean for Your Async Media Pipeline
Alibaba launched Qwen-Image and Qwen-Image-Edit on DashScope as qwen-image-2.0-pro. For routing teams, these introduce a non-DALL-E async job pattern and a new model namespace that standard OpenAI-compatible proxies may not handle correctly.