当翻译遇上 LLM：拆解网易有道翻译的高并发 API 架构与 Agent 化实践

一、从翻译 API 到翻译 Agent

传统机器翻译 API 的形态很清晰：输入一段文本，返回一段译文，延迟、吞吐、成本都可以用相对固定的模型服务来衡量。用户通过有道翻译官网、桌面端或移动端发起请求，背后通常是一个高并发的推理集群。随着 LLM 进入翻译场景，网易有道翻译 这类产品面对的问题不再只是“把一句话翻译出来”，而是要在上下文、术语、风格、格式、多轮交互和成本之间做动态权衡。

因此，现代翻译系统正在从单次 API 演进为翻译 Agent：它既保留高并发、低延迟的在线服务能力，也引入规划、工具调用、记忆与质量评估，让翻译结果更接近专业译者的工作流。用户在有道翻译下载 客户端中感受到的，可能只是一次点击，但服务端可能已经完成缓存查询、术语检索、模型路由、分段推理、一致性检查和流式回传。

二、总体架构：分层解耦与模型路由

一个面向高并发的网易有道翻译 API 架构，通常可以拆成五层：

1. 接入层：CDN、DNS 调度、WAF、四层与七层负载均衡，负责 TLS 卸载、连接复用和边缘加速。
2. 网关层：统一鉴权、配额、限流、路由、协议转换和请求审计。
3. 编排层：把翻译请求拆解为可执行任务，负责上下文管理、缓存、术语、模型选择和结果聚合。
4. 模型服务层：包含传统 NMT、LLM、语音识别、OCR、语言检测等能力，以容器或推理框架部署在 GPU 池中。
5. 数据与平台层：术语库、翻译记忆、质量评估、监控告警、A/B 实验和成本核算。

分层的价值在于：高并发压力尽量在接入层和缓存层消化，复杂推理交给模型服务层，业务逻辑收敛在编排层。这样，当 LLM 版本迭代或流量突增时，系统可以局部扩容，而不是整体重写。

三、高并发 API 的关键设计

3.1 无状态接入，有状态编排

接入层保持无状态，便于水平扩展。会话、上下文、术语偏好等状态则放入 Redis、分布式缓存或专用存储中，通过 request_id 和 session_id 关联。这样同一用户的连续请求可以被任意实例处理，同时保持多轮翻译的上下文一致性。

3.2 多级限流与配额

限流不能只看接口 QPS。更细的做法是：按租户、用户、IP、接口、模型和 token 消耗做多维限流。短窗口用滑动窗口或令牌桶处理突发流量，长窗口用配额控制成本。对于免费用户、企业用户和内部调用，设置不同优先级。当系统接近瓶颈时，优先保障交互式短文本，延迟或降级批量文档任务。

3.3 动态批处理与流式推理

LLM 推理的吞吐高度依赖 batch 组织。连续批处理（continuous batching）可以把不同请求的 token 生成过程动态合并，提高 GPU 利用率。对于长文档，编排层会先切分段落，再根据语义边界合并成合适 batch。对于实时翻译，则通过 SSE 或 WebSocket 流式返回首 token，降低用户感知延迟。这里的关键指标不只是总延迟，还包括首 token 延迟、token 间延迟和完成率。

3.4 多级缓存

缓存是高并发翻译系统的第一道护城河。精确缓存适合高频短句、术语和固定文案；语义缓存适合表达不同但含义相近的查询；翻译记忆则面向企业术语和历史语料。缓存命中后仍需做质量校验，避免把过期或低质量结果返回给用户。对有道翻译 这类高频产品，缓存命中率每提升一个百分点，都可能显著降低 GPU 成本。

3.5 降级与容灾

高并发系统必须假设组件会失败。LLM 服务超时或过载时，可以降级到传统 NMT；语音识别失败时，可以提示重试或转文本；非核心的润色、风格迁移可以暂时关闭。多活部署、跨机房流量调度、模型版本灰度，都是保证有道翻译官网 和客户端稳定可用的基础能力。

四、Agent 化实践：让翻译从单次推理变成工作流

翻译 Agent 的核心不是“更长的 prompt”，而是把翻译拆成可观测、可评测、可回滚的工作流。一个典型的 Agent 可以包含以下模块：

• Planner：判断请求类型，是短句、长文档、字幕、合同还是口语对话，并决定是否需要分段、检索或人工术语。
• Tool Layer：调用术语库、翻译记忆、词典、OCR、语音识别、格式解析、搜索和外部知识库。
• Memory：保存会话上下文、用户偏好、领域术语和历史修改，支持多轮翻译保持一致。
• Executor：调用不同模型完成初翻、润色、回译、术语约束和格式还原。
• Evaluator：用规则、模型评分和人工反馈评估质量，必要时触发重试或升级到更强模型。

例如，一份技术合同进入系统后，Planner 先识别领域和格式，Tool Layer 检索术语库与翻译记忆，Executor 分段初翻，Evaluator 检查术语一致性和数字格式，最后再由编排层合并输出。用户在有道翻译下载 的客户端中看到的是完整译文，背后却可能经历了多轮工具调用和质量控制。

五、典型请求链路

一次在线翻译请求大致会经过：

1. 客户端通过有道翻译官网、桌面端或 API 发起请求。
2. 接入层完成 TLS、WAF 和负载均衡。
3. 网关鉴权、限流、解析租户与配额。
4. 编排层查询精确缓存、语义缓存和翻译记忆。
5. 未命中时，根据语言对、文本长度、领域和优先级选择模型。
6. 模型服务执行推理，流式返回 token。
7. 编排层做术语校验、格式还原和质量评估。
8. 结果写入缓存与日志，返回客户端并记录指标。

这条链路中，任何一层都可以独立扩展。对于高并发场景，最重要的是把“必须实时做的事”和“可以异步做的事”分开。例如，质量评估可以异步采样，成本核算可以离线聚合，而首 token 返回必须尽量快。

六、可观测性与成本控制

没有可观测性，就谈不上高并发治理。建议至少覆盖：

• Trace：从网关到模型服务的全链路追踪，定位慢请求和失败点。
• Metric：QPS、P99、首 token 延迟、缓存命中率、GPU 利用率、token 消耗。
• Log：请求摘要、模型版本、错误码和降级原因，注意脱敏。
• Evaluation：离线评测集、在线 A/B、人工反馈和回归测试。

成本控制方面，可以通过模型路由、动态批处理、缓存、量化、GPU 池化和弹性调度降低单位翻译成本。简单句交给小模型，复杂段落交给 LLM，专业领域再叠加术语约束和人工审校。网易有道翻译 的工程实践，本质上是在质量、延迟和成本之间持续寻找最优解。

七、结语

当翻译遇上 LLM，翻译 API 不再只是模型推理接口，而是融合网关、缓存、编排、Agent 和评测体系的复杂在线系统。对于用户而言，无论是访问有道翻译官网，还是完成有道翻译下载，体验到的都是稳定、快速、自然的翻译结果；对于工程团队而言，真正的挑战在于让这套系统在高并发下保持可扩展、可观测、可降级，并让 Agent 化能力持续创造价值。未来，翻译系统的竞争力会更多体现在架构效率与工作流质量上，而网易有道翻译 这类产品的演进，正是这一趋势的典型样本。