拆解网易有道翻译：大模型时代机器翻译的工程架构、低延迟推理与降本增效实战
1. 背景：从 NMT 到 LLM 的翻译系统演进
网易有道翻译长期服务于在线文本、文档、图片、语音等场景。用户既可以从有道翻译官网直接使用在线翻译，也可以通过有道翻译下载获取桌面端、移动端与浏览器插件。进入大模型时代后，翻译系统的工程目标没有变：准确、稳定、低延迟、低成本。但实现方式发生了明显变化。
传统 NMT 系统通常由分词、编码器-解码器、注意力机制、束搜索、后处理组成。它在中短句、通用领域上效率极高，适合高并发、低成本场景。大模型翻译则带来更强的上下文理解、术语一致性、风格控制和长文档处理能力，但推理成本、首 token 延迟、显存占用显著上升。因此，网易有道翻译这类产品通常不会简单用 LLM 替换 NMT，而是走向混合路由与分层服务。
2. 总体工程架构
一个面向生产的有道翻译系统，可以抽象为以下层次：
- 接入层：Web、App、API、浏览器插件、文档翻译任务入口。
- 网关层：鉴权、限流、熔断、配额、灰度、协议转换。
- 预处理层：语言识别、文本归一化、分段、占位符保护、术语匹配。
- 路由层：根据语种、领域、文本长度、质量要求、成本预算选择 NMT、LLM 或混合方案。
- 推理层：NMT 模型服务、LLM 推理服务、OCR、ASR、TTS 等能力编排。
- 后处理层：术语替换、格式恢复、标点修复、质量打分、敏感内容过滤。
- 数据与缓存层：翻译记忆库、术语库、向量检索、KV 缓存、结果缓存。
- 可观测层：日志、指标、Trace、成本归因、A/B 实验。
2.1 接入层与客户端
有道翻译官网是有道翻译在线能力的重要入口。用户提交文本后，系统需要在百毫秒级返回结果；文档翻译则更像异步任务，可接受更高延迟，但要求格式还原和长上下文一致性。有道翻译下载客户端的价值在于本地入口、快捷划词、截图 OCR、离线能力等，后端仍然需要稳定 API。
2.2 网关与调度
网关层可以基于 Envoy、Nginx、Spring Cloud Gateway 或自研网关实现。核心职责不是简单转发，而是：
- 按用户、IP、API Key 做限流。
- 对 LLM 长请求做排队与超时控制。
- 根据模型服务负载动态路由。
- 在 GPU 资源紧张时降级到小模型或 NMT。
- 记录每次请求的 token、延迟、成本和模型版本。
3. 大模型时代的翻译引擎设计
3.1 NMT 与 LLM 混合路由
网易有道翻译的典型策略可能是：短句、高频、通用领域走 NMT；长文本、专业术语、上下文依赖强的请求走 LLM；文档翻译采用分段 + 上下文记忆 + 术语库约束。路由层可以使用规则 + 轻量分类模型：
- 文本长度小于阈值：NMT。
- 检测到术语表命中：NMT + 术语后处理。
- 多轮对话、上下文指代：LLM。
- 用户选择“高质量/专业模式”：LLM 或 LLM 校验 NMT。
3.2 术语库、记忆库与 RAG
专业翻译的关键是术语一致性。工程上可维护术语库和翻译记忆库，利用向量检索召回相似句对，再通过提示词注入或约束解码影响 LLM。对于企业客户，术语库可版本化、灰度发布，并与翻译任务绑定。
3.3 质量评估与反馈闭环
生产系统不能只看 BLEU。可以组合：
- 轻量质量估计模型（QE）。
- 回译一致性。
- 术语命中率。
- 用户修改率、复制率、停留时长。
- 人工抽检。
这些信号反哺路由策略和模型微调。
4. 低延迟推理实战
低延迟是大模型翻译的核心挑战。首 token 延迟（TTFT）和每 token 延迟（TPOT）决定用户体验。常见优化包括：
4.1 推理引擎与批处理
使用 vLLM、TensorRT-LLM、TGI 或自研推理引擎，开启 continuous batching、PagedAttention、KV Cache 复用。对翻译场景，可以按语种和长度分桶，减少 padding 浪费。
4.2 量化与蒸馏
将 LLM 做 INT8/INT4 量化，或蒸馏到更小的翻译专用模型。线上采用“大模型离线增强 + 小模型在线服务”的组合：大模型生成高质量语料，小模型承担高并发推理。
4.3 投机解码与前缀缓存
投机解码用小模型草稿 + 大模型验证，可在不损失太多质量的情况下提升吞吐。前缀缓存适合系统提示词、术语库、固定模板等重复前缀，避免重复计算。
4.4 流式输出与分段
有道翻译在线场景可以采用流式返回，先出首句，再逐步补全。长文档则按语义分段，段间维护上下文摘要，避免一次性塞入超长上下文。
# 伪代码：翻译请求路由与降级
def translate(req):
lang = detect_lang(req.text)
if cache.has(req):
return cache.get(req)
route = router.select(req, lang)
try:
if route == 'llm':
return llm_infer(req, timeout=800)
return nmt_infer(req, timeout=200)
except TimeoutError:
return nmt_infer(req, timeout=300)
注意：实际生产还需要处理鉴权、脱敏、限流、重试、幂等和审计。
5. 降本增效工程
5.1 GPU 池化与弹性伸缩
将 GPU 资源池化，按模型、语种、优先级调度。在线服务保持最小副本，离线任务使用抢占式实例。Kubernetes + KEDA 可根据 QPS、队列长度、GPU 利用率扩缩容。
5.2 多级缓存
- L1：进程内 LRU，缓存高频短句。
- L2：Redis，缓存用户级、租户级结果。
- L3：翻译记忆库，缓存句对和文档片段。
- 语义缓存：对相似请求做向量召回，命中后复用或微调结果。
5.3 成本可观测
每次请求记录输入 token、输出 token、模型版本、GPU 时长、缓存命中、路由决策。按业务线、租户、接口维度出成本报表。没有成本可观测，就没有真正的降本。
5.4 分级服务
免费用户、普通用户、企业用户可采用不同模型和 SLA。对延迟不敏感的任务进入离线队列，利用夜间低价算力。对实时性要求高的请求走小模型或 NMT。
6. 稳定性与可观测性
网易有道翻译这类大规模服务需要：
- 全链路 Trace：从网关到推理引擎。
- 指标：QPS、P99、TTFT、TPOT、GPU 利用率、缓存命中率、错误率。
- 日志：脱敏后采样存储。
- 告警：模型服务异常、队列积压、成本突增。
- 混沌工程：模拟 GPU 故障、网络抖动、下游超时。
7. 总结
拆解网易有道翻译，可以看到大模型时代机器翻译的工程重点：用混合路由平衡质量与成本，用连续批处理、量化、缓存和投机解码压低延迟，用 GPU 池化和成本可观测实现降本增效。对用户而言，无论从有道翻译官网在线使用，还是通过有道翻译下载客户端获得划词、截图、文档翻译能力，背后都需要一套高可用、低延迟、可扩展的翻译基础设施。
未来，随着端侧模型、专用推理芯片和 Agent 工作流的发展，有道翻译可能会进一步走向“云端大模型 + 端侧小模型 + 个性化记忆”的协同架构。工程上的胜负手，仍然是对延迟、成本、质量和稳定性的持续平衡。
