从 NMT 到 LLM：构建高可用的混合翻译引擎——分布式架构设计与工程实践-平芜编程栈

从 NMT 到 LLM：构建高可用的混合翻译引擎——分布式架构设计与工程实践

这不是一篇“调用几个模型 API 做翻译”的入门文，而是一篇面向生产环境的系统设计说明。我们要解决的核心问题是：当企业同时面对海量请求、严格延迟指标、复杂领域术语、成本压力和多区域高可用要求时，如何把传统 NMT 与 LLM 组合成一套真正可落地、可扩展、可治理的混合翻译平台。

一、为什么这个问题值得认真做

在跨境电商、国际化 SaaS、全球客服、跨语种内容审核等场景里，翻译系统已经不是一个“附属能力”，而是直接影响转化率、合规性和用户体验的核心基础设施。

一个真实的企业级翻译平台，往往同时承受以下约束：

请求规模大：日均千万级甚至上亿字符翻译，峰值 QPS 波动明显。
SLA 严格：实时评论、聊天消息、商品卡片翻译通常要求 P99 < 300ms。
质量分层明显：营销标题、合同条款、客服敏感话术、技术文档的质量要求完全不同。
成本不能失控：如果所有请求都走大模型，单位成本会迅速突破预算。
系统必须高可用：任一模型集群、可用区、第三方 LLM API 波动都不能拖垮整体服务。

也正因为此，纯 NMT 和纯 LLM 在生产上都不是最优解。

1.1 纯 NMT 的问题

神经机器翻译模型在高频短文本、固定语言对、结构化表达场景中表现很好，优势是：

推理快
单位成本低
易于部署在私有 GPU 集群
对高并发批处理更友好

但它的短板同样明显：

长文本上下文一致性弱
复杂句式、隐喻、俚语、文化语境理解不足
术语约束能力有限
面对多轮上下文或业务规则时适应性较差

1.2 纯 LLM 的问题

大语言模型在翻译上的优势不是“逐词翻译”，而是更强的语义重构、上下文理解和约束遵循能力：

能处理复杂上下文和指代消解
更适合术语表、风格指南、禁用词等软约束
支持摘要式翻译、解释式翻译、审校式翻译

但如果所有流量直接打到 LLM，会立刻遇到几个工程问题：

延迟高且抖动大
成本远高于 NMT
上下文越长，吞吐越差
第三方模型 API 有速率限制与供应商风险

因此，真正成熟的解法不是“选边站”，而是构建一套可自适应路由的混合翻译引擎。

二、核心理念：混合翻译不是双引擎，而是分层决策系统

混合翻译的本质，不是简单地在 NMT 失败后再调一下 LLM，而是建立一套以质量、时延、成本、可用性为目标函数的多阶段决策系统。

一个成熟的翻译请求在进入平台后，至少会经历四层判断：

是否可以直接命中缓存或记忆库。
是否适合走低成本快速路径，例如 NMT 或短路径专用模型。
是否需要进入审校、术语增强、上下文增强或 LLM 精修链路。
当主路径异常时，如何做降级、兜底与结果一致性保障。

换句话说，系统需要回答的不是“用哪个模型”，而是：

当前请求是否值得为质量付出更高成本？
当前请求是否值得为质量牺牲更多延迟？
当前请求是否存在法律、品牌、术语等硬约束？
当前集群在当前时刻是否承受得起该决策？

这就决定了路由器必须是一个策略系统，而不是一个简单的 if/else。

2.1 四种典型执行模式

模式	适用场景	目标	典型代价
`FAST_NMT`	短文本、常见语言对、弱质量约束	极低时延、低成本	质量上限有限
`DIRECT_LLM`	高价值文本、复杂上下文、敏感表达	质量优先	成本高、延迟高
`NMT_PLUS_REFINE`	中等复杂度文本、部分高质量需求	平衡质量与成本	链路更长
`ASYNC_DOCUMENT`	长文本、文档、批量任务	吞吐优先、异步交付	非实时

2.2 决策输入维度

路由器至少要使用以下特征：

文本长度：字符数、token 数、句子数
语言对：常见语言对、低资源语言对、方向性差异
领域标签：电商、法律、医疗、客服、技术文档
业务优先级：高价值商品、VIP 客户、敏感工单
术语强约束：品牌词、人名、SKU、法律条款
历史质量反馈：相似文本此前翻译是否被人工纠正
当前系统负载：GPU 队列深度、第三方 API 配额、成本预算

这意味着翻译路由不只是模型问题，更是一个在线调度问题。

三、从算法到系统：NMT 与 LLM 在架构中的角色分工

3.1 NMT 负责“规模化吞吐”

NMT 在生产环境中的价值主要体现在高吞吐和可控成本上。对于大量模式稳定、语义结构相对简单的文本，NMT 仍然是主力引擎。

它适合承担：

商品标题、标签、短评论
UI 固定文案
高频重复内容
批量离线翻译

从系统角度看，NMT 更像是“主通道”。

3.2 LLM 负责“质量补偿与复杂约束”

LLM 最适合做的不是替代所有 NMT，而是处理 NMT 难以稳定覆盖的部分：

长上下文一致性修正
术语表约束注入
风格统一
多义词消歧
文化语义重写
审校与解释

因此在工程上，LLM 更像是“高价值补偿通道”和“复杂请求处理通道”。

3.3 质量闭环比模型选择更重要

很多团队上线混合翻译后，最大的问题不是路由逻辑写不出来，而是缺乏闭环：

不知道哪些请求路由错了
不知道哪些精修其实没有增益
不知道哪些语言对的 NMT 质量已经足够好
不知道 LLM 成本花在了哪里

所以从第一天起就要把质量反馈纳入架构：

在线反馈：点赞、差评、人工改写
离线评估：BLEU、COMET、TER、人工抽检
策略反馈：将质量结果反哺到路由器阈值和分类模型

没有闭环，混合架构最终只会演变成“更多模型，更多成本，更多不确定性”。

四、生产级总体架构

下面是一套适用于中大型企业翻译平台的推荐架构。

graph TB Client[业务调用方] --> Gateway[Translation Gateway] Gateway --> Auth[鉴权 限流 配额] Auth --> Cache{Redis / 本地缓存} Cache -->|命中| Response[返回结果] Cache -->|未命中| Router[Routing Orchestrator] Router --> Feature[Feature Extractor] Router --> Policy[Policy Engine] Router --> Budget[Cost Budget Guard] Router --> Circuit[Degradation Controller] Policy --> NMT[NMT Cluster] Policy --> LLM[LLM Cluster] Policy --> Refine[Refinement Service] Policy --> Async[Async Document Pipeline] NMT --> Glossary[Terminology Service] LLM --> Glossary Refine --> Quality[Quality Evaluator] Async --> MQ[(Kafka)] MQ --> Worker[Document Workers] Worker --> NMT Worker --> LLM Worker --> Merge[Chunk Merge / Review] NMT --> Obs[Metrics Traces Logs] LLM --> Obs Refine --> Obs Quality --> Feedback[Feedback Store] Feedback --> Router Merge --> Callback[Callback / Result Pull API]

4.1 分层职责

建议把平台拆成下面几个核心服务，而不是把所有逻辑堆在一个翻译接口里。

模块	核心职责	工程关注点
`Gateway`	鉴权、配额、幂等、限流、协议统一	SLA、防刷、租户隔离
`Routing Orchestrator`	特征提取、策略计算、执行编排	决策可解释、动态配置
`NMT Service`	多模型推理、批处理、缓存	GPU 利用率、吞吐
`LLM Service`	Prompt 约束、模型切换、供应商路由	成本、稳定性、延迟
`Refinement Service`	NMT 结果审校、风格修正、术语增强	增益评估、低温采样
`Quality Evaluator`	离线/在线质量打分	策略反馈、A/B 评估
`Document Pipeline`	长文本切块、异步翻译、结果合并	顺序一致性、失败重试
`Glossary Service`	术语表、品牌词、禁译词、样式规则	多租户隔离、热更新