拆解网易有道翻译：一名软件工程师眼中的LLM落地、性能优化与架构演进

一、背景：翻译系统的工程约束

作为软件工程师，看网易有道翻译，第一反应不是“模型多大”，而是“链路多长”。用户从有道翻译官网进入网页翻译，或通过有道翻译下载安装桌面/移动客户端，再到 API、文档翻译、拍照翻译，背后是一条从接入、预处理、路由、模型推理、后处理到质量评估的完整系统。网易有道翻译要在延迟、成本、质量、可用性之间做取舍，这也是 LLM 落地最真实的一课。

翻译场景的约束很硬：

• 延迟敏感：交互式翻译要求首 token 在数百毫秒级，整句在秒级返回。
• 流量潮汐：学习、办公、出行场景有明显高峰，弹性扩缩容重要。
• 质量分层：日常文本、专业术语、长文档、口语 ASR 后翻译，要求不同。
• 成本可控：大模型不能无差别全量跑，必须有路由和降级。

二、架构演进：从 SMT/NMT 到 LLM 增强

有道翻译的架构演进大致可以拆成几个阶段。

1. 统计机器翻译阶段

早期以短语、规则、语言模型组合为主。工程重点是特征抽取、解码器、语言模型缓存。缺点是对长距离依赖和语序差异处理有限。

2. 神经机器翻译阶段

Transformer 成为主力。编码器-解码器、注意力机制、BPE/子词、批处理推理。服务化上，模型被封装为推理服务，通过网关调用，配合术语库、翻译记忆库、后编辑。

3. LLM 增强阶段

LLM 不是简单替代 NMT，而是形成混合系统：

• 路由层根据文本长度、领域、语言对、用户等级选择 NMT、LLM 或级联。
• LLM 负责长文本、上下文理解、风格改写、术语一致性、低资源语言。
• NMT/小模型负责高并发、低延迟、成本敏感请求。
• 术语库、记忆库通过 RAG/提示注入参与生成。 这种“大模型 + 小模型 + 规则/记忆”的架构，比单一模型更接近生产可用。

三、LLM 落地：关键工程问题

1. 提示与上下文

翻译 LLM 的提示通常包含：系统指令、语言对、领域、术语表、上下文段落、输出格式。长文档翻译需要滑窗、段落对齐、上下文缓存。提示压缩和缓存复用可显著降低 token 成本。

2. 领域适配

通用 LLM 在医学、法律、IT 术语上容易漂移。做法包括：

• SFT 指令微调，构造高质量平行语料和纠错样本；
• DPO/偏好优化，让模型更符合人工译后编辑偏好；
• 术语约束解码或后处理替换；
• RAG 检索术语库与翻译记忆库。

3. 质量与安全

线上系统必须有质量门禁：COMET/BLEU/人工抽检、敏感内容过滤、数据脱敏、租户隔离。网易有道翻译这类产品还要处理用户隐私和合规要求，日志中不能明文保存敏感原文。

四、性能优化：把 LLM 推理压进生产 SLA

LLM 落地最痛的是推理性能。以下是从软件工程师视角最常用的优化手段。

1. 推理引擎

• vLLM：PagedAttention、连续批处理，适合高并发 API。
• TensorRT-LLM：图优化、kernel 融合，适合英伟达 GPU 深度优化。
• FasterTransformer/自研引擎：针对特定模型结构裁剪。 选型要看模型、硬件、并发模式和团队维护成本。

2. 量化与蒸馏

• FP16/BF16 是基线；INT8/INT4 可降显存和带宽。
• GPTQ/AWQ/SmoothQuant 等量化方案需评估质量损失。
• 蒸馏小模型用于高频语言对和端侧场景，配合有道翻译下载客户端做离线/弱网翻译。

3. KV Cache 与批处理

• KV Cache 复用多轮/长文档上下文。
• PagedAttention 减少显存碎片。
• 连续批处理让不同长度请求动态合并，提高 GPU 利用率。
• 投机采样、Medusa、EAGLE 等加速解码，但要看接受率。

4. 缓存与路由

• 句级/段级缓存：相同或相似请求直接命中。
• 语义缓存：向量检索近似请求，设置相似度阈值。
• 术语缓存：固定术语直接替换，减少模型不确定性。
• 分级路由：短句走 NMT，长文/专业文本走 LLM，失败降级。

5. 流式与端侧

交互式翻译要流式输出。首 token 延迟、增量解码、前端渲染都要优化。有道翻译下载的桌面端和移动端可以做端侧小模型、规则引擎、缓存预取，弱网时先本地出草稿，联网后再精修。

6. 成本与弹性

GPU 利用率、批大小、排队策略、弹性伸缩、混部、Spot 实例都会影响单位翻译成本。生产上常用 token 预算、超时熔断、按用户等级限流。

五、可观测性与稳定性

没有可观测性，LLM 系统无法上线。需要：

• Trace：请求 ID 贯穿网关、预处理、路由、模型、后处理。
• Metrics：QPS、P50/P95/P99、首 token 延迟、TPOT、GPU 利用率、缓存命中率、质量分。
• Logging：模型版本、提示模板、参数、路由决策、错误码。
• 灰度与回滚：模型版本、提示版本、术语库版本都可灰度。
• 降级：LLM 超时切 NMT，NMT 故障切缓存/规则。
• 多机房容灾与限流熔断。

六、数据飞轮与评测

LLM 翻译的长期竞争力来自数据飞轮：

1. 线上采样与用户反馈；
2. 人工译后编辑与标注；
3. 质量评测与 bad case 归因；
4. 微调/偏好优化/提示迭代；
5. A/B 实验验证后全量。 评测不能只看 BLEU，还要看 COMET、术语准确率、格式保持、延迟和成本。网易有道翻译在有道翻译官网、客户端、API 等不同入口的流量特征不同，评测也要分场景。

七、给开发者的启示

1. LLM 落地不是模型替换，而是系统重构。
2. 混合架构通常优于单一大模型：路由、缓存、小模型、LLM 各司其职。
3. 性能优化要围绕首 token 延迟、吞吐、显存、成本四个指标。
4. 质量、安全、可观测性必须从第一天设计。
5. 用户入口很分散：有道翻译官网、有道翻译下载、API、浏览器插件等，需要统一模型服务与差异化体验。

八、结语

拆解网易有道翻译，可以看到一个成熟翻译产品的工程方法论：用架构演进承接模型红利，用 LLM 落地解决复杂语言问题，用性能优化守住体验和成本，用可观测性和数据飞轮持续迭代。对于正在做 AI 应用的软件工程师来说，有道翻译不是“一个模型”，而是一套在真实流量下不断权衡的系统。无论用户从有道翻译官网访问，还是通过有道翻译下载客户端使用，背后都是同一件事：把不确定的模型能力，变成稳定、快速、可负担的翻译服务。