高并发翻译场景下的大模型工程：拆解网易有道翻译的 AI Infra、Agent 编排与成本优化

关键词：有道翻译、网易有道翻译、有道翻译官网、有道翻译下载、AI Infra、Agent 编排、成本优化

1. 背景：翻译为什么是高并发大模型场景

当用户在 有道翻译官网 输入一句话，或通过 有道翻译下载 的桌面端、移动端提交一份合同、论文、字幕文件，请求就会进入 网易有道翻译 的服务链路。翻译看似简单，工程上却是典型的高并发大模型场景：短文本请求高频且延迟敏感，长文档请求 token 量大且格式复杂，多语种导致模型能力不均衡，用户对术语、格式、语气又非常敏感。因此，翻译系统不能只靠“一个模型加一个接口”，而需要 AI Infra、Agent 编排和成本优化协同。

2. 总体架构

一个面向高并发的翻译平台通常分为六层：

1. 接入网关：鉴权、限流、路由、灰度。
2. 预处理：语言检测、分句、格式抽取、术语识别。
3. Agent 编排：任务规划、模型选择、工具调用、质量校验。
4. AI Infra：推理引擎、GPU 调度、批处理、缓存。
5. 后处理：术语替换、格式恢复、标点与排版修正。
6. 可观测与成本：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 编排。一个典型链路是：

1. Language Agent：检测语种和脚本。
2. Parser Agent：抽取段落、表格、公式、占位符。
3. Terminology Agent：检索术语库与翻译记忆。
4. Translation Agent：按分块调用模型，保持上下文。
5. QA Agent：回译、术语一致性、数字与格式校验。
6. Formatting Agent：恢复 Markdown、HTML、字幕时间轴。
7. 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. 实践清单

如果你要构建类似 有道翻译 的高并发翻译系统，可以按以下顺序推进：

1. 先做网关、限流、缓存和可观测。
2. 再引入连续批处理和模型路由。
3. 用术语库和翻译记忆提升一致性。
4. 用 Agent 编排处理长文档和复杂格式。
5. 最后做量化、弹性伸缩和成本归因。
6. 所有优化都要以离线评测和在线 A/B 为准。

9. 总结

高并发翻译场景下，大模型工程不是单一模型问题，而是 AI Infra、Agent 编排和成本优化的系统问题。网易有道翻译 的实践思路可以概括为：用分层模型路由匹配场景，用动态批处理和缓存提升吞吐，用 Agent 编排保证长文档质量，用成本可观测指导容量和优化。当用户从 有道翻译官网 发起请求，或通过 有道翻译下载 客户端提交任务时，背后需要一套稳定、弹性、可度量的翻译基础设施。对于 有道翻译 这类产品，真正的竞争力往往不在单次生成，而在高并发下持续交付可接受质量与可控成本。