从网易有道翻译看大模型应用工程化：高并发、低延迟与降本增效的实战拆解
在大模型应用落地的讨论中，翻译是一个极具代表性的场景：输入输出相对明确、质量可量化、用户对延迟极其敏感，同时调用量可能非常大。网易有道翻译作为国内高频翻译产品，背后不只是“调用一个大模型”那么简单，而是接入、调度、推理、缓存、评测和成本控制共同组成的工程体系。本文尝试从这类产品出发，拆解大模型应用工程化中的高并发、低延迟与降本增效问题。
一、翻译场景的工程约束
翻译场景有几个典型约束：
- 低延迟：用户期望输入后立刻看到结果，首字延迟尤其关键。
- 高并发：热点事件、学习高峰、API 客户调用会带来突发流量。
- 多端一致：Web、移动端、浏览器插件、API 都需要稳定服务。用户可能从有道翻译官网进入，也可能通过有道翻译下载安装客户端。
- 成本敏感：大模型推理贵，若每请求都走最大模型，毛利会被迅速吞噬。
- 质量分层：日常短句、专业术语、长文档、低资源语种，对模型能力要求不同。
因此，大模型翻译的工程目标不是单纯追求最高 BLEU/COMET，而是在质量、延迟、吞吐和成本之间找 Pareto 最优点。
二、总体架构：把模型藏进服务体系
一个典型的大模型翻译服务可以拆成以下几层：
- 接入层：CDN、API Gateway、鉴权、限流、WAF、协议转换。移动端和有道翻译下载客户端通常在这里完成就近接入。
- 预处理层：文本清洗、语言识别、分句、术语匹配、敏感信息脱敏。
- 路由层：根据语种、长度、用户等级、模型健康度选择小模型、大模型或缓存。
- 推理层：GPU 池、推理引擎、动态批处理、KV Cache 管理。
- 缓存层：精确缓存、语义缓存、前缀缓存、术语库缓存。
- 后处理层：术语一致性校正、格式恢复、标点修复、质量打分。
- 可观测与评测层：Trace、Metrics、Log、A/B 实验、人工反馈。
这里的关键思想是：模型只是其中一个组件。真正决定线上体验的，是模型之外的调度、缓存和降级。
三、高并发：从“单请求最快”转向“系统吞吐最大”
高并发场景下，如果只优化单条请求延迟，可能会牺牲整体吞吐。工程上常用手段包括：
1. 动态批处理
推理引擎如 vLLM、TensorRT-LLM、TGI 等支持 continuous batching。请求不必等固定 batch 满，而是持续加入、持续输出。对于翻译这种输入长度差异较大的场景，需要设置合理的 max batch tokens，避免长文本拖垮短文本。
2. 请求分级与隔离
- 交互式请求：优先低延迟，走小 batch、短队列。
- 批处理请求：优先吞吐，允许排队，走大 batch。
- 高价值 API：独立资源池，避免被免费流量挤占。
3. 背压与限流
接入层需要令牌桶、漏桶、并发连接数限制。队列满时快速失败或降级到缓存/小模型，而不是无限堆积导致雪崩。
4. 多级缓存
- 精确缓存：相同文本、相同语种、相同术语库直接返回。
- 语义缓存：相似句子复用译文，但要谨慎处理否定、数字、实体。
- 前缀缓存：系统提示词、术语表、few-shot 示例可复用 KV Cache。
缓存命中率每提升 10%，都可能显著降低 GPU 压力和单位成本。
四、低延迟：首 token 与流式体验
翻译场景的低延迟要拆成两个指标：
- TTFT：Time To First Token，首 token 延迟。
- TPOT：Time Per Output Token，后续 token 间隔。
用户感知最明显的是 TTFT。优化手段包括：
- 流式输出：SSE 或 WebSocket 逐段返回，让用户先看到部分译文。
- 分句并行：长文档切句后并行翻译，再按顺序拼接。
- 模型量化：FP16 到 INT8/FP8，减少显存带宽压力。
- 投机采样：小模型草稿加大模型验证，提升解码速度。
- 前缀缓存：复用系统提示和术语表计算。
- 边缘接入：CDN 和就近网关降低网络 RTT。
需要注意的是，流式输出对前端和协议有要求。若中途失败，要有断点重试或整段回退策略。
五、降本增效：不是一味压缩，而是精细运营
大模型成本通常来自 GPU 利用率和 token 消耗。降本可以从几个方向入手：
1. 模型分层路由
- 短句、日常用语：小模型或蒸馏模型。
- 长文、专业领域：大模型加术语库。
- 低资源语种：专用模型或级联方案。
路由策略可以基于语言对、文本长度、历史质量反馈动态调整。
2. 提升 GPU 利用率
- 动态 batching 提高吞吐。
- 多模型混部，削峰填谷。
- 弹性伸缩，低峰释放实例。
- 使用 Spot 实例跑离线任务。
3. 缓存与复用
缓存不仅降低延迟，也直接减少 token 计费。对于高频短语、产品术语、帮助文档，缓存收益极高。
4. 成本指标化
建议跟踪：
- 每千 token 成本
- 每千次请求成本
- GPU 利用率
- 缓存命中率
- P95/P99 延迟
- 降级率与失败率
只有把成本拆到请求级，才能知道优化是否真的有效。
六、实战拆解：一次翻译请求的生命周期
假设用户在客户端发起一次中译英请求：
- 用户从有道翻译官网或已安装的有道翻译下载客户端输入文本。若未安装，也可能通过网页版直接使用。
- 请求到达边缘节点，完成鉴权、限流、语言识别。
- 预处理模块分句、匹配术语库，并计算缓存 key。
- 缓存命中则直接返回；未命中则进入路由层。
- 路由层根据文本长度、语种、用户等级选择模型。
- 推理层将请求加入 continuous batching 队列，复用前缀 KV Cache。
- 生成结果通过 SSE 流式返回，前端逐字渲染。
- 后处理校正术语和格式，异步写入缓存。
- 采样质量数据进入评测与反馈闭环。
这套链路中，任何一环出问题都会影响体验。因此可观测性必须覆盖全链路 Trace，而不是只看 GPU 利用率。
七、常见工程坑
- 只迷信大模型：忽略缓存、术语库和路由，成本高且延迟差。
- 只优化平均延迟：忽略 P99，导致少量用户极慢。
- 不做降级：模型或 GPU 异常时直接失败。
- 缓存不区分上下文：同一句子在不同领域含义不同，直接复用会出错。
- 缺少离线评测：线上 A/B 有风险，需先离线对比 BLEU、COMET 和人工评分。
- 日志泄露隐私：翻译内容可能包含敏感信息，必须脱敏和加密。
八、总结
从网易有道翻译这类产品看，大模型应用工程化的核心不是“模型越大越好”，而是围绕业务 SLA 构建一整套系统工程：用动态批处理提升吞吐，用流式输出和量化降低延迟，用缓存、路由和弹性资源控制成本，再用可观测性和评测闭环保证质量。高并发、低延迟、降本增效三者天然存在张力，工程团队要做的，是在具体场景中找到可度量、可迭代、可回滚的平衡点。
对于开发者而言，理解有道翻译官网公开能力、体验有道翻译下载客户端，并观察其交互细节，有助于反推背后的工程取舍。真正可复用的经验，是把模型放进服务体系中，让每一次翻译请求都尽可能快、稳、省。
