TL;DR: open source performs better and is cheaper but slower
Commercially viable open-source LLMs achieve better translations than stock services offered by hyperscalers.
These LLMs are small. Running them on GPUs costs a fraction of the service fees, even if you rent the GPUs from the same hyperscaler.
As of today there is just one technical reason to stick to "classic" hyperscaler translation: speed. If you need the fastest possible answer (and your traffic is unpredictable or low), matching their speed is not affordable.
2026 commoditised translations
Commercial translation services are now losing ground to new, better competitors. A few years ago free consumer translation services (the most famous being Google Translate) were beaten by specialised services (e.g. DeepL). Today everyone can see how they're humiliated by free LLMs, whose linguistic abilities encompass style and tone, beyond pure lexical competence. Recently, the same is happening to translation services you can purchase from hyperscalers.
One year ago, the proceedings of the Conference on Machine Translation showed that the best translators are LLMs. At WMT25 Conference, the reference human evaluation for machine translation, the three commercial online services were beaten by LLMs in all language pairs. The winning system under 20B parameters was a 7B open-weight LLM, and Google itself now publishes TranslateGemma, a 4B to 27B open family covering 55 languages, without ever benchmarking it against its own Translate API, which is quite telling.
At WMT26, in late October, Google Translate was the only commercial service still included as a baseline, and it ranked in the bottom half in most language pairs. Even the open-weight Gemma 4 31B, which you can run on your own hardware, outranked it on average.
Better quality off the bat
In a benchmark I performed mid-2026 on translations to multiple languages, I validated these findings on production data in real use cases. And the news is, more than one LLM qualified for the job, leaving room to take into account HW and SW support for the final choice.
Even more accurate results through customised prompts
On your custom-built translation service, you can tune the translation on the go. You control the prompt so you control:
- grounding: you induce the translator to stick to facts about the content (e.g. conversations improve by providing previous turns),
- tone: is this a legal document, a customer-service response or a customer review? Good translations sound very different when given a different tone.
Cost advantage
Drivers:
- Cloud translations are priced per character. At volume these costs justify developing your own service.
- Owned translations have a fixed infrastructure cost. Saturating capacity is the goal to minimise unit cost.
Price lists change fast in 2026 both for services and hardware, so take the following number (taken from a real use case) with a grain of salt.
Data point from a recent deployment: a rented 24GB GPU paid for itself with a GPU average load of 16%.
This leaves room for huge savings, provided we keep the service busy. The common adoption path is
- setting up the service on one GPU,
- routing all translations to the service, keeping the legacy cloud translation to hand off work during traffic peaks.
- moving deferrable jobs to low-traffic moments.
Every step optimises unit cost and allows pushing the load on the service minimising fallback calls to legacy suppliers.
If/when the service saturates further steps may be
- renting extra GPU boxes, that you can switch on and off if you can predict load,
- hosting the service on your own machine(s), which lowers costs further (and turns them into CAPEX)
Throughput, concurrency, trade-offs
Compute is the scarce resource in LLM-based translation.
Therefore given a fixed compute capacity, if you want to:
optimise latency:
- use a smaller LLM: faster execution at the expense of quality
- use a shorter prompt
- reduce concurrency
optimise concurrency:
- serve a higher number of parallel tasks, at the expense of latency
optimise quality:
- use a more capable, bigger LLM, at the expense of latency
- refine your prompt at the expense of latency
NOTE: LLMs get different levels of support from engines (vLLM, SGLang, Ollama,...). Therefore, model choice may steer engine adoption as much as traffic shape. I'm keeping engine comparison out of this post, but there are important considerations to be made on top of that choice.
Usual advantages over third-party services
As with on-prem speech synthesis, controlling the service has benefits beyond quality and cost.
Privacy by design
With a self-hosted translation service, the text being processed never leaves your infrastructure.
No API call to OpenAI, Google, or AWS. No terms-of-service clause about training data with your customers' info. No audit trail at a third party. For businesses handling sensitive documents, customer communications, legal content, or regulated data, this removes an entire category of risk.
Reliability and control
No rate limits, no upstream outages, no deprecation notices. The model you deploy is the model you keep.
Suitable for regulated and air-gapped environments
Once model weights are downloaded, the system has no external dependencies. Suitable for finance, healthcare, defence, or any context where data cannot leave a controlled environment.
In short
Machine translation is no longer a service you have to rent. Open-weight LLMs that run on a single GPU now match or beat the translation APIs sold by hyperscalers, and they let you tune tone and context through the prompt. The economics favour self-hosting as soon as you can keep a GPU busy, and your data stays in-house. Speed is the one remaining reason to stay with the cloud, and a hybrid setup with cloud fallback for traffic peaks covers it.