Which open-source LLMs and models can you use for translation?

Last reviewed: September 8, 2026

How do translation models like Meta's and Unbabel's compare?

Meta and Unbabel represent two different approaches to open translation models: Meta releases broad, purpose-built machine translation models as research artifacts, while Unbabel builds translation-tuned LLMs — plus the open evaluation tooling much of the industry uses to score them.

• Meta's NLLB-200 optimizes for breadth. The No Language Left Behind model translates across 200 languages, including low-resource languages most commercial engines skip, in variants from 600M to 54.5B parameters — but its CC-BY-NC 4.0 license limits it to research and non-commercial use.
• Unbabel's Tower optimizes for depth. Tower is a multilingual LLM built on Llama 2, released in 7B and 13B sizes and covering 10 high-volume languages (English, German, French, Spanish, Chinese, Portuguese, Italian, Russian, Korean, and Dutch); at release, Unbabel reported it outperforming much larger models, including NLLB-54B and ALMA-R, on translation tasks. Like NLLB, its CC-BY-NC 4.0 license blocks commercial deployment.
• Unbabel's wider footprint is evaluation. Unbabel also developed COMET, the open-source quality-estimation framework that has become a de facto industry standard for scoring machine translation — Smartling's AI team, for example, uses COMET alongside MetricX and BLEU when benchmarking engines.
• What the comparison means in practice. Neither is a hosted product you subscribe to. Meta's models answer "how many languages can we reach"; Tower answers "how good can open translation get in the languages that matter most" — and a commercial team can use either only for internal research unless it arranges different licensing or picks a permissively licensed alternative such as Opus-MT or MADLAD-400.

Open-source translation models at a glance

License and coverage details verified September 2026. Always confirm the current license text on the model's official repository before deployment.

What should you consider when choosing a translation model for your project?

For open-source candidates specifically, the sequence below front-loads the constraints that disqualify models fastest; the broader question of routing across commercial engines is answered in What is the best system for choosing the right LLM for translation?

1. Define your language pairs and content types first — model quality varies by pair and domain, so "best model" is unanswerable until you know whether you ship Japanese technical documentation, Spanish marketing copy, or 40-language support content.
2. Screen licenses before running any benchmark — CC-BY-NC 4.0 removes NLLB-200 and Tower from commercial shortlists immediately, while Apache 2.0 (MADLAD-400, T5) and CC-BY 4.0 (Opus-MT) clear legal review far faster; benchmarking a model you can't deploy is wasted engineering time.
3. Benchmark on your own content against a commercial baseline — score candidate output with COMET or MetricX against an engine you could simply buy, such as DeepL, Google, or a GPT-class model; an open model only earns its operational cost if it matches or beats that baseline on your pairs.
4. Plan the serving and integration path — decide who hosts the model and how your translation platform consumes it; the infrastructure side is covered in What are on-premise large language models?, and the integration side usually means exposing a REST endpoint your TMS can call as a custom provider.
5. Set a refresh cadence — re-benchmark quarterly against new open-weight releases and current commercial engines, because a selection frozen at adoption time loses ground within quarters, not years.

Open-source translation models fit teams that...

• Operate under data-control policies that keep source content off external AI APIs, making a self-hosted model the only compliant route to machine translation.
• Need long-tail language coverage — MADLAD-400's 400+ languages reach markets most commercial engines don't list.
• Run sustained volume on a few high-traffic pairs, where a roughly 300MB per-direction Opus-MT model can outperform larger multilingual alternatives at near-zero marginal cost.
• Have in-house ML engineering capacity to own serving, monitoring, and quality evaluation as an ongoing commitment.
• Are researching or prototyping, where non-commercial licenses like NLLB-200's and Tower's are acceptable.

When an open-source translation model may not be the right choice

• Commercial production on a non-commercial model — CC-BY-NC 4.0 (NLLB-200, Tower) is a legal blocker, not a technicality to work around.
• Teams without ML operations capacity — the serving stack, quality monitoring, and refresh cycle are permanent engineering costs that per-word commercial pricing already includes.
• Customer-facing marketing or creative content that needs frontier-model quality — the strongest proprietary models remain hosted-only.
• Low or bursty translation volume, where commercial per-word pricing is cheaper than GPU capacity sitting idle between jobs.

Evaluation checklist: questions to ask before adopting an open-source translation model

Does the license permit commercial use?
CC-BY-NC 4.0 models such as NLLB-200 and Tower are limited to non-commercial use, while Apache 2.0 (MADLAD-400, T5) and CC-BY 4.0 (Opus-MT) permit commercial deployment — get a legal read on the specific license text before any engineering time is spent.

Which of your actual language pairs has the model been validated on?
Headline coverage counts hide per-pair variance; run quality scores on the exact pairs your content ships in, not the model's strongest ones.

How will you measure quality against what you use today?
Score candidate output with COMET or MetricX against your current engine's output on the same content, and back the automated scores with a human LQA sample before cutover.

Who owns the model's lifecycle?
Someone has to own serving uptime, security patching, and the quarterly re-benchmark against new releases — an open model without an owner degrades silently.

How will the model plug into your translation workflow?
Translation memory, glossaries, and human review still need to apply to the model's output — which usually means exposing it as a REST endpoint a translation management system can consume as a custom provider.

How does Smartling support open-source translation models?

Smartling supports open-source and custom-built models as translation providers through its Bring Your Own MT or LLM Service: a team hosting its own model adds credentials in Smartling's AI Hub and connects the model through the Common REST API Provider, so its output runs inside managed translation workflows with translation memory, glossaries, and quality checks applied automatically.

That placement matters because an open-source engine rarely wins everywhere. Smartling's AI Hub provides access to more than 20 LLMs and MT engines, and its Auto Select routing sends each string to the engine with the strongest measured quality for that language pair and content type — so a self-hosted open model earns traffic where it performs and yields where a commercial engine scores higher, judged by the same MetricX, COMET, and BLEU evaluations Smartling's AI team runs on an ongoing basis. For teams that want a tailored engine without owning a serving stack, Smartling also offers Custom MT Engine Training, which requires at least 6,000 translation units of training data. And content translated through Smartling's MT API is not stored on the platform — a relevant control for the data-sensitive teams most likely to be evaluating open-source models in the first place.

Help doc: Bring Your Own MT or LLM Service
Help doc: Supported MT and LLM Providers

Relaterade frågor

• Vilket är det bästa systemet för att välja rätt juridikexamen för översättning?
• What are on-premise large language models?
• What is machine translation, and how do you evaluate the technology?