Hy-MT2-30B-A3B: Can a 3B-Active Translator Beat Frontier Models?

If you translate with a general-purpose frontier model today, you are paying for a lot of capability you never use. The model that can refactor a repository and solve olympiad maths is also the one rendering your release notes into Thai. Hy-MT2-30B-A3B is Tencent's argument that a specialist with a fraction of the active parameters can do that one job as well or better.

It is the largest of the three Hy-MT2 translation models open-sourced on 21 May 2026, alongside Hy-MT2-7B and Hy-MT2-1.8B, all under Apache 2.0. This guide looks at the headline claim, the economics of a 3B-active MoE, and how to check whether it beats what you use now.

The claim, stated carefully

Tencent's technical report and model card say the 7B and 30B-A3B models outperform open-source models such as DeepSeek V4 Pro and Kimi K2.6 in fast-thinking mode. Read that sentence twice. It is a translation-quality claim, made by the vendor, on the vendor's evaluation suite, with the comparison run without extended reasoning.

It is plausible. General models are trained to be good at everything, and translation is a small slice of that. A model trained specifically on translation and translation instructions has a reasonable chance of being sharper on that slice. But the published results are in a chart rather than a table, the report covers general, business, domain-specific and instruction-following translation, and the average across 33 languages can hide a weak pair.

The question that matters is narrower: is it better than your current model on your language pairs and your kind of text? That is cheap to answer, and the last section shows how.

3B active, 30B resident

The name is the architecture. The model holds about 30B parameters and activates about 3B per token, so each generated token costs roughly what a 3B dense model would, while the full 30B has to sit in memory. Mixture of experts explained covers why that split exists.

For translation the trade is attractive. Output is long relative to the prompt, often as long as the input, so per-token generation speed matters more than in a chat that returns a short answer. A 3B-active forward pass keeps that fast.

The memory side is what limits self-hosting. Tencent's vLLM and SGLang examples run with tensor parallelism of one, meaning a single GPU, and there is an official FP8 build that roughly halves the weight footprint against BF16. Unlike the 7B and 1.8B, Tencent does not list an official GGUF for this size, so llama.cpp users are relying on community conversions.

Same hosted price as the 7B

On OpenRouter at the time of writing, Hy-MT2-30B-A3B and Hy-MT2-7B are listed at the same rate: $0.074 per million input tokens and $0.295 per million output. The 1.8B is listed at $0.044 and $0.177.

That makes the hosted decision unusually simple. If you are calling an API and both endpoints are available, there is no price reason to choose the 7B over the flagship. Pick the 30B-A3B by default, and only move down if your evaluation shows no difference and you want the option of self-hosting the smaller model later.

For a sense of scale: a million output tokens is several hundred thousand words of translated text. Work out your own monthly translation volume before treating price as the deciding factor; for many workloads the stronger argument for a specialist is quality and latency, not cost.

All Hy-MT2 sizes are listed with an 8,192-token context and 4,096 maximum output tokens, so long documents need to be chunked whichever size you choose.

Different defaults: use the right sampling settings

A detail that is easy to miss: the flagship's recommended sampling differs from its siblings. Tencent recommends temperature 0.7, top_p 1.0, top_k -1 (disabled) and repetition penalty 1.0 for the 30B-A3B, against top_p 0.6, top_k 20 and repetition penalty 1.05 for the 1.8B and 7B.

If you swap model names in a pipeline and keep the sampling block, you are running the 30B-A3B off its recommended configuration. If quality then disappoints, rule out the sampling block before blaming the model. Keep sampling settings per model, not per pipeline.

The 30B-A3B and 7B listings on OpenRouter also show JSON mode and structured outputs, which is useful when you are translating fields of a JSON document and need the response to parse. Tencent's structured-data template asks the model to translate only user-facing values and leave keys and placeholders alone.

How to test it against a general model

The comparison worth running is Hy-MT2-30B-A3B against whatever general model you translate with today. A practical version:

1. Collect 50 to 100 real segments per language pair you support, covering UI strings, long-form text and anything with placeholders or markup.
2. Translate with both models. Use the published Hy-MT2 template for Tencent's model and your existing prompt for the incumbent; you are testing the systems you would actually run.
3. Score automatically for placeholder and tag preservation and glossary adherence. These are pass or fail.
4. Have a fluent reviewer rank pairs of outputs blind, without knowing which model produced which.
5. Record latency and output tokens per segment alongside quality.

Building a 20-task eval covers the general method, and LLM translation covers the failure modes worth testing for.

If the specialist wins or ties, a sensible architecture is to route translation requests to it and keep the general model for everything else. If it loses on one pair, route that pair elsewhere. Translation is easy to split out by task type, which makes it one of the cleanest cases for model routing.