Can AI translation achieve real-time translation? How low must latency be to make it usable?

Can AI translation achieve real-time translation? The answer is yes, but there is a complete set of engineering challenges between “being able to run” and “being usable in business.” Model generation speed is only one part of the equation. Speech capture, endpoint detection, speech recognition, text translation, speech synthesis, network round trips, and frontend playback buffering all add up to the waiting time users actually experience. For technical evaluators, the first step should be to define the scenario: meeting captions, customer service calls, live-stream interactions, or instant inquiries on multilingual websites? Different scenarios have different requirements for latency, accuracy, and fault tolerance.

Real-time translation is not a single metric, but an end-to-end chain

Many solutions demonstrate that “as soon as a sentence is spoken, the translation appears immediately,” making them seem close to real time. However, technical acceptance should not focus solely on the response time of the translation API. Taking speech-to-speech translation as an example, the system must first determine when the user has finished speaking. This step is called endpoint detection. Cutting off too early may omit words, while waiting too long can noticeably slow down the conversation. Speech recognition must then handle accents, environmental noise, technical terminology, and numbers. If the translated output needs to be spoken aloud, it must also go through speech synthesis and client-side buffering.

Therefore, procurement or integration should distinguish among three types of latency: first-word latency, meaning how long after the user begins speaking the first caption segment appears; stable translation latency, meaning the time required before the key meaning of a sentence no longer changes significantly; and turn latency, meaning the time before the other party can hear a complete and understandable translation. The first two affect the sense of real-time following, while the last determines whether people frequently talk over one another. Simply asking, “How many milliseconds is the API latency?” will usually not provide an answer sufficient to assess usability.

How low must latency be before users consider it usable?

There is no universal threshold in the industry that applies to every business, but internal acceptance criteria can be established based on interaction intensity. In general, text chat has the highest tolerance: if users receive a natural and complete translation within a few seconds after sending a message, it can often meet the needs of cross-border inquiry handling. Meeting captions place greater emphasis on continuity, allowing translations to lag slightly behind the original speech, but not to the point where the next speaker has already begun. Telephone calls, video negotiations, and live-stream call-ins are the most sensitive. Once latency accumulates to the point where both parties must pause and wait, the communication rhythm quickly becomes a fragmented “one sentence from you, one sentence from me” pattern.

In practice, low latency does not mean blindly pursuing shorter audio segments. If segments are cut too short, speech recognition cannot obtain sufficient context, and translation may mishandle negatives, quantities, model numbers, and sentence subjects. If segments are too long, accuracy may be more stable, but conversational fluency is sacrificed. In foreign trade negotiations, the risk caused by a single mistranslation of information such as “tax excluded,” “delivery time,” “minimum order quantity,” or “material grade” is often greater than waiting a little longer. Usability requires trade-offs between speed and semantic completeness.

What determines the experience is often not the translation model itself

Network conditions are easily overlooked. In cross-border business, visitors may come from North America, Europe, the Middle East, Southeast Asia, or Latin America. If audio streams, translation services, and the business frontend are deployed in regions far apart from one another, network round-trip time can directly consume the gains from model-side optimization. Technical evaluations should not be limited to stress testing on office networks. They should simulate access paths in target markets and record performance under weak networks, packet loss, and network switching.

A second common issue is repeated revision after streaming output. Some systems first provide a provisional translation and then revise it as more context becomes available. For captions, this capability can reduce the wait for the first word. However, in customer quotation communications, if amounts, dates, or product parameters are revised one after another, users may remember only the incorrect version. A more mature approach is to distinguish provisional results from confirmed results in both the interface and business logic, while adding extra verification or manual confirmation options for numbers, currencies, model numbers, and proper nouns.

The third issue is differences between language pairs. Language combinations with relatively abundant resources, such as English and Chinese, are generally more likely to achieve stable results. Low-resource languages, mixed accents, and expressions containing industry abbreviations often require longer context or terminology intervention. Do not use the results of a general English demonstration to infer the actual experience in Russian, Arabic, Japanese, or less commonly used language markets. In particular, frontend presentation also requires separate testing for right-to-left text display, honorific expressions, and unit and date formats.

Website and marketing scenarios may not require “full-time simultaneous interpretation”

For multilingual websites, the value of real-time translation is mainly concentrated in interactive elements rather than replacing all page content. Product pages, brand introductions, technical documentation, compliance statements, and long-term advertising landing pages should still prioritize reviewed localized content. The reason is simple: these pages affect user trust and also carry search engine indexing, advertising quality, and conversion paths. Even if dynamic translation reads smoothly, it may not accurately convey the purchasing context.

A more reasonable combination is usually this: fixed pages use a multilingual website-building system to maintain structured content; online chat and initial form screening use instant translation; and sales personnel review the original text when entering critical stages such as quotations, contracts, and specification confirmations. Eyb has long served foreign trade companies, manufacturing factories, cross-border e-commerce sellers, and overseas brand expansion projects. Its cloud intelligent website-building, cross-border e-commerce mall, and overseas marketing services cover multilingual official websites, advertising landing pages, social media traffic generation, and other stages. Viewed within this type of chain, AI translation should not be deployed in isolation. It is necessary to consider whether lead sources, page languages, customer service responses, CRM records, and subsequent content accumulation are coherent.

During technical acceptance, do not test only “Hello, may I ask the price?”

Before evaluating a solution, it is recommended to prepare real but anonymized corpora: product model numbers, materials, dimensions, packaging methods, trade terms, delivery cycles, payment terms, and the question formats commonly used by customers in target markets. Testing should cover at least continuous speech, multiple speakers interrupting each other, background noise, network fluctuations, and mixed Chinese and English. If the system provides a terminology glossary or custom dictionary, it is also necessary to verify whether it takes effect before recognition, during translation, or only for final replacement; the three have different impacts on real-time performance and accuracy.

It is also necessary to clarify what happens in the event of failure. After an API timeout, should the original text be displayed, should users be prompted to retry, or should a sentence be silently lost? Does the model mark low-confidence results when it is uncertain? Do conversation audio and text need to be retained, and how should the storage location, permissions, and retention period be configured? These questions may be less eye-catching than “How many languages are supported?” but they directly determine whether a cross-border business can remain online in the long term.

Therefore, AI translation can certainly achieve real-time translation, but there is no business-independent standard answer for latency that is “low enough to be usable.” Customer service scenarios can allow a little more time for accuracy, meeting captions need to control cumulative latency, and real-time interpreting must include network conditions, streaming processing, and interaction design in the acceptance process. Testing the complete chain before deciding on the model and deployment method is usually closer to real-world results than focusing on a single millisecond figure.