The cost of an AI translation workflow is often reduced to a simple calculation: the number of input and output tokens multiplied by the price of the selected model.

This calculation is useful, but it captures only one part of the problem.

In practice, excessive token consumption is often a symptom of a translation workflow that has not been properly designed. Content is sent directly to a large language model using a generic prompt, regardless of the language pair, content type, risk level, available linguistic assets or expected quality.

This may work for a proof of concept. At scale, however, it can become expensive, inconsistent and difficult to control.

Reducing token costs therefore requires more than shortening prompts. The greatest savings usually come from designing a workflow that avoids using an LLM when it does not provide sufficient additional value.

The objective is not simply to consume fewer tokens. It is to reach the required translation quality at the lowest total cost.

The first question: does this content need an LLM?

Large language models can be highly effective translation tools. They are particularly useful when content requires broader context, interpretation of ambiguity, stylistic adaptation or rewriting for a specific audience.

However, not every sentence requires these capabilities.

Many organizations move directly from conventional machine translation to LLM-based translation without first determining which content genuinely benefits from an LLM. Large models are then used for repetitive product descriptions, standard support content, technical instructions and other predictable material that could often be translated more efficiently by a neural machine translation engine.

NMT systems such as DeepL and Google Cloud Translation can also apply glossaries to control domain-specific terminology, product names and preferred translations.

Their limitations tend to become more visible when content requires document-level interpretation, complex stylistic decisions or a nuanced understanding of the intended audience.

The most effective architecture is therefore rarely based entirely on either NMT or LLMs. It is usually a hybrid of both.

For example, repetitive product descriptions may be translated by an NMT engine using an approved glossary. Marketing headlines may be routed to an LLM because they require greater stylistic flexibility. Previously translated legal clauses may be retrieved from a translation memory. Ambiguous segments may be escalated from NMT to an LLM, while critical content may be sent for targeted human review.

Every segment handled successfully without a large LLM removes both input and output tokens from the LLM bill.

The first question should therefore be:

Does this content need to be sent to an LLM at all?

Select the best-fit engine for each requirement

Using the largest available model may appear to be the safest way to achieve good results. In reality, model size and translation quality are not perfectly correlated.

A larger model may perform better on average, but it will not necessarily produce the best translation for every language pair, domain or content type.

Performance can vary according to:

• The source and target languages

• The content domain

• The length and structure of the document

• The amount of relevant context available

• Terminology requirements

• The expected tone and style

• The required quality level

• The linguistic assets available

A smaller LLM may perform almost as well as a much larger model for a particular language pair. A conventional NMT engine may outperform both on repetitive or terminology-heavy technical content. A specialist model may work extremely well in one domain but poorly in another.

Engine selection should therefore be based on benchmarking rather than assumptions.

Representative datasets can be used to compare several NMT engines and LLMs for each language pair, domain and content type. The objective is to identify the least expensive engine that consistently reaches the required quality.

This is one of the most important principles of token optimization. Using a premium model for content that a smaller model or NMT engine can already translate correctly creates cost without necessarily creating additional value.

Reuse existing translations before generating new ones

The cheapest translation is often the one that does not need to be generated again.

Before sending content to an NMT engine or LLM, the workflow should identify anything that has already been translated or appears more than once.

This includes exact translation-memory matches, repeated sentences within the same document, duplicates across multiple files, recurring boilerplate and previously approved legal, technical or product content.

Deduplication should happen before generation.

When the same sentence appears hundreds of times across a collection of documents, it should normally be translated once and reused. Sending every occurrence to an LLM creates avoidable input and output costs and may even produce different translations for identical source content.

Translation memories remain highly valuable in an AI translation environment for exactly this reason. They allow approved translations to be retrieved and reused while maintaining consistency and reducing both generation and review work.

The same principle can be applied through result caching. If the same source content is submitted again with the same language pair, instructions, glossary and model configuration, the workflow may be able to return an existing approved translation rather than call the model again.

A reliable cache should account for more than the source sentence alone. Its key may include the source and target languages, content type, model version, prompt version, glossary version and style-guide version. This prevents an old translation from being reused after the underlying requirements have changed.

Fuzzy matches require a more selective strategy

Exact translation-memory matches are relatively straightforward. Fuzzy matches are more complex.

A fuzzy match may provide most of the required translation, with only a minor correction needed. In that situation, editing the existing translation may be more economical than generating a new one.

However, fuzzy matches can also contain hidden risks:

• A changed number

• A different product name

• An altered negation

• Outdated terminology

• An inappropriate sentence structure

• A superficially similar sentence with a materially different meaning

Sending every fuzzy match to an LLM as additional context is not automatically efficient. The match itself consumes input tokens, and a misleading reference may create more correction work than translating the segment from scratch.

A more intelligent workflow applies different treatments according to match quality, content risk and expected usefulness.

Very high matches may be reused with limited verification. Strong matches may be corrected by a small model. Relevant matches may be provided as references to an NMT engine or LLM. Weak or potentially misleading matches may be ignored, while sensitive changes may be routed to a human reviewer.

The important question is not whether a fuzzy match exists. It is whether using that match is likely to reduce the total cost of producing an accepted translation.

Linguistic assets improve both cost and quality

Translation memories, glossaries and style guides are often presented primarily as quality-control resources.

In a well-designed AI translation workflow, they are also cost-optimization tools.

A reliable translation memory reduces the amount of new content requiring generation. A glossary lowers the risk of terminology errors. A clear style guide prevents repeated rewriting. Approved examples may allow a smaller or less expensive model to reach the required standard without escalating the content to a larger one.

Cost and quality are not necessarily opposing objectives. In many cases, the same linguistic assets that improve quality also make a less expensive workflow possible.

However, simply adding more assets does not automatically improve the result.

An outdated translation memory can introduce obsolete terminology. A poorly maintained glossary can enforce incorrect translations. Contradictory style-guide instructions can confuse both models and linguists. Irrelevant examples can consume context without providing useful guidance.

Asset governance is therefore essential. Translation memories, glossaries and style guides should be cleaned, validated, versioned and associated with the correct language pair, client, domain and content type.

The objective is not to send every available linguistic asset to the model. It is to provide the smallest set of trusted assets that is relevant to the content being translated.

Retrieve only the context that is needed

One of the easiest ways to increase token costs is to attach an entire glossary, style guide or set of reference documents to every translation request.

A company may have thousands of glossary entries, hundreds of pages of style instructions and millions of translation-memory segments. Sending all of this information to an LLM is both expensive and unnecessary.

Instead, the workflow should retrieve only the assets relevant to the current translation.

A segment about payment terms does not require guidance about social-media hashtags. A technical manual does not need the complete marketing tone-of-voice guide. A product description for clothing does not require terminology relating to electronics.

This targeted retrieval reduces input tokens while making it easier for the model to identify and apply the most important instructions.

More context is not always better context. Relevant, reliable and properly structured context is more useful than a large quantity of loosely related information.

The lesson is not that every translation needs a long sequence of prompts. It is that context should become part of the workflow architecture and be activated selectively according to the content.

Optimize the level at which instructions are applied

Translation prompts frequently contain language instructions, output-format requirements, terminology rules, style guidance and examples.

Applying the complete set of instructions to every sentence creates considerable duplication. But placing everything into a single document-level prompt can also create problems. Important rules may be missed, particularly in long documents, and the model may lose track of instructions provided much earlier in the context.

There is therefore a trade-off between instruction repetition and instruction adherence.

The most efficient solution is often to apply instructions at several levels:

Workflow-level instructions contain stable rules that apply to the complete client or project.

Document-level instructions describe the audience, purpose, subject and overall writing style.

Section-level context contains information relevant to a chapter, product category or group of related segments.

Segment-level instructions include only the terminology, exceptions or formatting rules required for the current passage.

This reduces the need to repeat the complete style guide or glossary with every request while still giving the model the information it needs.

The correct granularity will vary. A configuration that works well for English-to-French marketing content may not be appropriate for German-to-Japanese technical documentation. Some models handle large document contexts well, while others perform more reliably on smaller sections.

The optimal approach should therefore be tested by language pair, model, domain and document type rather than treated as a universal setting.

Avoid repeated full-document processing

Another major source of token consumption is repeatedly sending the complete source and translation through several models.

A poorly optimized workflow may:

1. Generate a complete translation.

2. Send the entire result to an LLM for quality assurance.

3. Regenerate the complete translation.

4. Run another full-document style review.

5. Regenerate the content again.

Each stage processes large quantities of repeated content.

A more efficient workflow uses automated checks and targeted intervention.

Terminology checkers, formatting validation, numerical comparisons and deterministic rules can identify many common issues without requiring a premium model. Smaller models can classify risk or detect likely errors. Only the affected segments need to be escalated for deeper review or correction.

Automated controls may identify:

• Terminology violations

• Missing or added content

• Incorrect numbers

• Formatting problems

• Untranslated text

• Unusual length differences

• Inconsistent translations

• Content types known to be difficult for the selected engine

When a five-word terminology correction is needed, the workflow should avoid regenerating an entire page unless the broader context is genuinely required.

Use smaller models and deterministic tools for supporting tasks

Premium LLMs are sometimes used for every part of the workflow, including tasks that do not require advanced generation capabilities.

The same model may classify the content, identify the domain, select the translation engine, check terminology, evaluate quality and generate corrections.

Many of these tasks can be handled by smaller models, conventional algorithms or deterministic rules.

A lightweight classifier may be sufficient to identify whether content is legal, technical or marketing. A terminology checker can detect glossary violations without sending the full document to a large model. A rules-based process can compare numbers, tags and formatting between the source and target. Language detection can often be performed without an LLM call.

The more expensive model should be reserved for tasks where its additional capabilities create measurable value.

A well-designed routing layer may therefore decide:

• Whether the content requires translation at all

• Whether a translation-memory match can be reused

• Which NMT or LLM engine should be selected

• Which linguistic assets should be retrieved

• Whether additional context is necessary

• Which quality checks should be activated

• Whether human review is required

This is why token optimization is ultimately an orchestration problem rather than merely a prompt-engineering exercise.

Self-hosting can change the cost model, but not remove costs

For organizations with large and predictable translation volumes, custom NMT models or open-source and open-weight LLMs may also be hosted on internal infrastructure. Open-source toolkits such as OpenNMT support the training and deployment of custom machine translation models.

Self-hosting removes the external provider’s direct per-token invoice and can provide greater control over data sovereignty, model selection and server utilization. However, token costs are replaced by hardware, electricity, maintenance, engineering and infrastructure costs. It is therefore most relevant when volumes are sufficiently high, sovereignty is important or generic models consistently underperform in a specialized domain.

It is one possible optimization, not the starting point for most translation workflows.

Measure the total cost of an accepted translation

The model with the lowest token price is not necessarily the least expensive solution.

A cheap model may require extensive human correction. A larger model may reduce post-editing but cost more than necessary for straightforward content. An NMT engine may perform extremely well for one language pair and inadequately for another.

The most useful metric is therefore not simply the cost per million tokens.

It is the total cost of producing an accepted translation.

This can include:

• NMT and LLM usage

• Input and output tokens

• Translation-memory leverage

• Prompt and translation cache hit rates

• Failed requests and retries

• Automated quality assurance

• Human post-editing and post-editing distance

• Engineering and maintenance

• Infrastructure costs

• Processing time

• Quality incidents and rework

These measurements should be separated by language pair, domain and content type.

A global average can hide significant differences. A workflow that is highly efficient for French product descriptions may perform poorly for Japanese marketing copy or German legal documentation.

The workflow should therefore be monitored continuously. Models evolve, prices change, linguistic assets improve and new content types appear. An engine selected during an initial benchmark should not automatically remain the best option forever.

Cost and quality are not always directly correlated

The objective of token optimization is not to reduce context, model size or processing steps at any cost.

Removing useful context may produce inconsistent translations. Reusing low-quality linguistic assets may introduce errors. Using the cheapest model may increase post-editing. Processing batches that are too large may cause omissions or formatting failures.

At the same time, a more expensive workflow does not automatically produce better results.

A large LLM may add little value when an NMT engine and a well-maintained glossary already meet the quality requirement. A long prompt may be less effective than a shorter prompt containing only relevant instructions. Multiple AI review passes may generate more noise than useful correction.

Cost and quality must therefore be optimized together.

The correct question is not:

How can we produce the cheapest possible translation?

It is:

What is the least expensive workflow that consistently reaches the required quality level?

Token optimization is a workflow-design problem

Reducing token costs in AI translation is not primarily about writing shorter prompts.

It is about designing a workflow that continuously asks:

• Has this content already been translated?

• Is it duplicated elsewhere?

• Can an exact match be reused?

• Is a fuzzy match genuinely useful?

• Can an NMT engine handle the content?

• Does the segment require an LLM?

• Would a smaller model be sufficient?

• Which linguistic assets are relevant?

• How much context does the model actually need?

• Can stable instructions be cached?

• Can the content be processed in a coherent batch?

• Does the full output need correction, or only selected segments?

• Is the selected engine still the best option for this language pair and domain?

The most efficient translation architecture will usually be hybrid. It will combine translation memories, specialized NMT engines, small and large language models, targeted asset retrieval, caching, automated quality controls, intelligent routing and human expertise.

‍

At Powerling, this is the purpose of the best-fit agnostic approach: benchmarking technologies for specific language pairs and domains. But our role goes far beyond selecting the best-fit engine.

We help organizations design, build, integrate, manage and continuously improve complete AI translation pipelines. This includes connecting and governing linguistic assets, defining content-routing rules, orchestrating NMT, LLM and human workflows, and implementing the quality controls required at each stage.

Because these environments are constantly evolving, the pipeline cannot remain static. Models change, prices move, content requirements develop and linguistic assets grow. We continuously adapt this modular architecture to ensure that each type of content is processed by the most appropriate combination of technology, data and human expertise.

‍