高并发翻译场景下的大模型工程：拆解网易有道翻译的 AI Infra、Agent 编排与成本优化
1. 背景：翻译为什么是高并发大模型场景
当用户在 有道翻译官网 输入一句话，或通过 有道翻译下载 的桌面端、移动端提交一份合同、论文、字幕文件，请求就会进入 网易有道翻译 的服务链路。翻译看似简单，工程上却是典型的高并发大模型场景：短文本请求高频且延迟敏感，长文档请求 token 量大且格式复杂，多语种导致模型能力不均衡，用户对术语、格式、语气又非常敏感。因此，翻译系统不能只靠“一个模型加一个接口”，而需要 AI Infra、Agent 编排和成本优化协同。
2. 总体架构
一个面向高并发的翻译平台通常分为六层：
- 接入网关：鉴权、限流、路由、灰度。
- 预处理：语言检测、分句、格式抽取、术语识别。
- Agent 编排：任务规划、模型选择、工具调用、质量校验。
- AI Infra：推理引擎、GPU 调度、批处理、缓存。
- 后处理：术语替换、格式恢复、标点与排版修正。
- 可观测与成本：Trace、指标、日志、账单与容量规划。
3. AI Infra：把推理做成基础设施
3.1 推理引擎
高并发下常使用 vLLM、TensorRT-LLM、SGLang 等推理引擎，关键能力包括连续批处理、PagedAttention、前缀缓存、投机解码、量化推理。对于 有道翻译 这类流量，单条请求可能只有几十 token，也可能有数万 token 的长文档，因此引擎必须支持动态 batch 和细粒度调度。
3.2 在线批处理
在线批处理不是简单攒批，而是基于延迟预算的调度。假设 P99 延迟要求 300ms，系统会维护一个微批窗口，将同一模型、同一语言的请求聚合。短文本优先走小 batch，长文本走大 batch 或异步队列，以避免长请求拖垮短请求。Prefill 与 Decode 分离也很重要：Prefill 计算密集，Decode 显存带宽密集，两者混部会互相干扰。
3.3 模型路由与分层
翻译模型不必全部用最大参数模型。可以按场景分层：
- 超短句、常见语种：小模型或蒸馏模型。
- 专业领域、低资源语种：大模型加术语库。
- 文档翻译：大模型加 Agent 流程。
- 实时字幕：流式小模型加增量解码。
这种路由由 Router Agent 完成，目标是质量、延迟、成本三者的帕累托最优。
3.4 KV Cache 与翻译记忆
翻译有大量重复前缀，例如系统提示、术语表、领域说明。Prefix Cache 可以显著降低 TTFT。翻译记忆库和术语库则把历史高质量译文变成检索增强的一部分。对于 网易有道翻译 这样的产品，缓存不仅要命中文本，还要考虑上下文、术语、用户偏好和格式。
3.5 量化与弹性
FP8、INT8、AWQ/GPTQ 等量化能降低显存和成本，但需要评测质量损失。GPU 弹性伸缩要结合队列深度、GPU 利用率、P99 延迟和成本预算。低峰期缩容，高峰期扩容，大促或考试季预留容量。
4. Agent 编排：翻译不是一次生成
翻译任务天然适合 Agent 编排。一个典型链路是：
- Language Agent：检测语种和脚本。
- Parser Agent：抽取段落、表格、公式、占位符。
- Terminology Agent：检索术语库与翻译记忆。
- Translation Agent：按分块调用模型，保持上下文。
- QA Agent：回译、术语一致性、数字与格式校验。
- Formatting Agent：恢复 Markdown、HTML、字幕时间轴。
- Router Agent：失败重试、降级模型、异步补偿。
编排层通常用 DAG 或状态机实现，每个节点有超时、重试、熔断和幂等要求。对于长文档，可以按语义分块并行翻译，再通过全局术语表做一致性收敛。对于 有道翻译官网 的网页请求，编排层要尽量轻量，避免过度 Agent 化增加延迟；对于 有道翻译下载 客户端的文档任务，则可以用更重的质量校验流程。
5. 成本优化：从 token 账本到 GPU 账本
5.1 成本可观测
先把成本拆成输入 token、输出 token、缓存命中、GPU 时长、网络与存储。每个请求带上 tenant、scene、model、cache_hit、latency_budget 等标签，才能做归因。
5.2 缓存策略
- 精确缓存：相同文本直接返回。
- 语义缓存：相似句复用译文，但需控制风险。
- 前缀缓存：复用系统提示和术语。
- 结果缓存：文档级分块缓存。
缓存命中率每提升 10%，可能带来显著的 GPU 节省。
5.3 模型与批处理
小模型分流、动态批处理、连续批处理、投机解码、量化、LoRA 合并，都是常见手段。关键指标是每百万 token 成本和每 GPU 吞吐。如果只看 QPS，容易忽略长文本对显存的占用。
5.4 异步与离线
实时翻译走在线集群，文档翻译可以走异步队列。离线任务利用低峰 GPU 或竞价实例，成本更低。对于 网易有道翻译 这种多产品矩阵，在线与离线混部需要严格隔离，避免离线任务影响在线 SLA。
6. 质量与评测
翻译质量不能只看 BLEU。工程上常用 COMET、人工评测、术语一致性、格式保真、回译相似度、用户采纳率。Agent 编排可以加入自检：数字是否一致、人名是否保留、Markdown 是否完整、字幕时间轴是否对齐。A/B 实验要同时看质量、延迟和成本，避免“质量提升但成本爆炸”。
7. 可观测性与稳定性
核心指标包括 TTFT、TPOT、P99、队列深度、批大小、GPU 利用率、显存、缓存命中率、重试率、降级率。日志要脱敏，Prompt 和译文不能明文暴露敏感信息。Trace 要能串起网关、Agent、推理、后处理。容量规划要按语种、场景、时段建模。
8. 实践清单
如果你要构建类似 有道翻译 的高并发翻译系统，可以按以下顺序推进：
- 先做网关、限流、缓存和可观测。
- 再引入连续批处理和模型路由。
- 用术语库和翻译记忆提升一致性。
- 用 Agent 编排处理长文档和复杂格式。
- 最后做量化、弹性伸缩和成本归因。
- 所有优化都要以离线评测和在线 A/B 为准。
9. 总结
高并发翻译场景下，大模型工程不是单一模型问题，而是 AI Infra、Agent 编排和成本优化的系统问题。网易有道翻译 的实践思路可以概括为：用分层模型路由匹配场景，用动态批处理和缓存提升吞吐，用 Agent 编排保证长文档质量，用成本可观测指导容量和优化。当用户从 有道翻译官网 发起请求，或通过 有道翻译下载 客户端提交任务时，背后需要一套稳定、弹性、可度量的翻译基础设施。对于 有道翻译 这类产品，真正的竞争力往往不在单次生成，而在高并发下持续交付可接受质量与可控成本。
