拆解网易有道翻译：LLM 时代的端云协同、推理加速与高并发工程化实践
在 LLM 进入翻译场景之后，翻译系统不再只是“输入句子、返回译文”的简单服务。以网易有道翻译为例，用户侧看到的是即时、稳定、多端一致的体验；工程侧要解决的是端云协同、推理加速和高并发调度。用户从有道翻译官网了解能力，完成有道翻译下载后，可能不会关心背后有多少 GPU 在跑，但系统必须保证每一次点击都有可预期的延迟与质量。
本文以网易有道翻译为观察对象，拆解 LLM 时代翻译系统的端云协同、推理加速与高并发工程化实践。文中提到的有道翻译，既包括移动端、桌面端和 Web 端，也包括 API、文档翻译、语音翻译等场景。
一、业务特征与核心挑战
翻译业务有几个典型特征：
- 流量峰谷明显。工作日早高峰、会议时段、考试周、跨境大促都会带来突发 QPS。
- 请求异构。短文本、长文档、语音流、图片 OCR、实时同传，对延迟和吞吐要求完全不同。
- 质量要求分层。免费用户、企业用户、专业译员对术语一致性、上下文连贯性、格式保留的要求不同。
- 成本敏感。LLM 推理成本远高于传统 NMT，必须通过缓存、路由、蒸馏和批处理摊薄成本。
- 多端一致。用户可能在手机、PC、浏览器插件之间切换，术语库、翻译记忆、偏好需要同步。
因此，网易有道翻译的系统目标可以概括为：端侧低延迟与隐私保护，云侧大模型质量与知识更新，中间通过智能路由和可观测体系连接。
二、端云协同：不是二选一，而是分层决策
端云协同的核心不是把所有翻译都放到端侧，也不是所有请求都上云，而是根据场景做分级决策。
2.1 端侧能力
端侧通常会部署轻量模型或规则模块，用于：
- 离线短句翻译、常用语翻译；
- 输入预处理、语言检测、拼写纠错；
- 敏感内容脱敏与本地缓存；
- 网络不稳定时的降级兜底；
- 个性化术语和用户偏好的本地索引。
端侧的优势是延迟低、隐私好、弱网可用。用户完成有道翻译下载后，即使在地铁、飞机或境外网络不稳定时，也能获得基础翻译能力。
2.2 云侧能力
云侧承载大模型、术语库、翻译记忆、上下文理解和质量评估。它适合：
- 长文档与复杂上下文；
- 多语言、多领域专业翻译；
- 实时更新的热词、新词、品牌词；
- 企业术语库和团队协作；
- 模型灰度、A/B 测试与持续优化。
有道翻译官网通常会提供多端入口和功能说明，而真正决定体验差异的，是端云之间的调度策略。
2.3 路由策略
一个可落地的路由策略可以抽象为：
def route_translate(request):
if request.offline or request.sensitive:
return on_device_translate(request)
if request.text_len < 20 and request.lang_pair in EDGE_SUPPORT:
return edge_translate(request)
if cache_hit(request):
return cache.get(request)
return cloud_llm_translate(request)
真实系统会更复杂，通常考虑：
- 语言对与领域；
- 文本长度与上下文窗口；
- 网络 RTT 与丢包率；
- 用户等级与 SLA；
- 数据合规与地域；
- 当前 GPU 队列水位；
- 端侧模型版本与电量。
路由层最好做成策略引擎，而不是硬编码 if-else。策略可以热更新，并支持灰度发布。
三、推理加速：从模型到引擎的系统优化
LLM 翻译的推理加速不能只靠换更快的 GPU，需要模型、引擎、缓存、调度协同。
3.1 模型层优化
常见手段包括：
- 知识蒸馏：用大模型指导小模型，保留翻译质量的同时降低参数量；
- 量化：INT8/INT4 量化，端侧可使用更激进的量化策略；
- LoRA/Adapter：按领域加载轻量适配器，避免全量微调；
- MoE：稀疏激活，在质量与吞吐之间取平衡；
- 投机解码：小模型草稿加目标模型验证，降低解码延迟；
- 结构剪枝：针对端侧 NPU 和移动 CPU 做通道剪枝。
对于有道翻译这类多语言场景，模型层还要考虑语言族共享、词表压缩和长文本分块。
3.2 引擎层优化
云侧常用推理引擎包括 vLLM、TensorRT-LLM、TGI 等，重点能力是：
- 连续批处理（continuous batching）；
- PagedAttention/KV Cache 管理；
- Chunked Prefill，降低长 prompt 对短请求的阻塞；
- 前缀缓存，复用系统提示词和术语库上下文；
- 多 GPU 张量并行与流水线并行；
- 动态批处理与优先级队列。
端侧则更多使用 MNN、NCNN、ONNX Runtime、Core ML 等，关注算子融合、内存复用、NPU 调度和线程亲和性。
3.3 缓存与记忆
翻译场景天然适合缓存：
- 完全匹配缓存：相同文本、语言对、领域直接返回；
- 语义缓存：相似句子复用候选译文；
- 前缀缓存：复用系统提示、术语表、用户背景；
- 翻译记忆：企业术语和已确认译文优先；
- KV Cache 复用：多轮对话或同文档翻译时减少重复计算。
缓存层需要处理版本、时效和一致性。术语更新后，相关缓存应失效或标记为低优先级。
四、高并发工程化：稳定性比峰值更重要
高并发不是单纯堆机器，而是让系统在峰值、故障和成本压力下仍然可控。
4.1 接入层
接入层通常包括：
- 全球加速与边缘节点；
- 限流、熔断、降级；
- 鉴权与租户隔离；
- 请求优先级队列；
- 灰度与 A/B 路由；
- 安全审计与内容合规。
对于实时翻译，限流要区分交互式请求和批处理请求。交互式请求优先，文档翻译可以异步排队。
4.2 调度层
GPU 资源调度建议：
- Kubernetes + 设备插件管理 GPU；
- 按模型、语言对、领域划分资源池；
- 拓扑感知调度，减少跨 NUMA 和跨机通信；
- HPA/KEDA 根据队列长度和 QPS 弹性伸缩；
- 抢占式实例承载离线批处理；
- 模型热备与快速冷启动。
4.3 可观测性
没有可观测性就没有高并发治理。关键指标包括：
- QPS、并发数、队列深度；
- P50/P95/P99 延迟；
- Token 吞吐与 GPU 利用率；
- 缓存命中率；
- 端侧成功率与云端回退率；
- 每百万 Token 成本；
- 翻译质量指标，如 BLEU、COMET、术语准确率。
Trace 需要贯穿端、边缘、网关、调度、推理和缓存，才能定位是网络慢、排队久，还是模型解码慢。
4.4 容灾与降级
降级策略可以分层：
- 云侧大模型不可用，降级到小模型；
- 小模型不可用，降级到传统 NMT；
- 在线服务不可用，端侧模型兜底；
- 端侧不可用，返回缓存或提示稍后重试。
多活部署、模型热备、配置中心和自动化回滚，是保证网易有道翻译稳定性的基础。
五、一个端云协同的推理链路
可以把一次翻译请求抽象为：
客户端 SDK/App
-> 本地语言检测与脱敏
-> 端侧缓存/端侧模型
-> 边缘网关
-> 策略路由
-> 云侧推理集群
-> 术语库/记忆库/质量评估
-> 返回译文并回写缓存
在这条链路中，有道翻译官网和有道翻译下载入口负责用户触达，而真正的技术壁垒在于：
- 端侧模型能否低功耗运行；
- 云侧推理能否高吞吐、低延迟；
- 路由能否在质量、成本和合规之间动态平衡；
- 系统能否在流量洪峰和故障中保持可用。
六、性能与成本权衡
一个实用的工程原则是：能用端侧解决的，不轻易上云；能命中缓存的，不重复推理；必须上云的，尽量批处理和复用 KV Cache。
典型目标可以设为：
| 场景 | 目标延迟 | 策略 |
|---|---|---|
| 短句离线 | < 50ms | 端侧小模型 |
| 在线短句 | < 300ms | 边缘缓存/小模型 |
| 普通文本 | < 800ms | 云侧 LLM + 批处理 |
| 长文档 | 异步 | 分块、队列、翻译记忆 |
| 实时同传 | 低延迟流式 | 流式解码 + 端云协同 |
这些数字不是固定标准，而是帮助团队做取舍的锚点。
七、未来演进
LLM 时代的翻译系统还会继续演进：
- 端侧 NPU 能力增强，更多小模型可离线运行；
- 云侧 MoE 和 speculative decoding 进一步降低成本；
- Agent 化翻译，结合搜索、术语库和用户反馈；
- 个性化翻译记忆，跨设备同步；
- 质量评估自动化，badcase 驱动持续训练。
对于用户来说，最直观的入口仍然是有道翻译官网，完成有道翻译下载后即可体验多端翻译；对于工程团队来说，网易有道翻译背后的端云协同、推理加速和高并发工程化，才是 LLM 时代真正值得拆解的部分。
八、总结
拆解网易有道翻译，可以看到一条清晰的工程主线：
- 端云协同决定体验边界；
- 推理加速决定成本与延迟；
- 高并发工程化决定稳定性与可扩展性；
- 可观测与数据闭环决定持续优化能力。
在 LLM 时代，翻译不再只是一个模型问题，而是端、边、云、数据、调度和成本共同作用的系统工程。谁能把这套系统做得更稳、更快、更省，谁就能在网易有道翻译这类产品中持续提供高质量体验。
