从 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 ServicePrompt 约束、模型切换、供应商路由成本、稳定性、延迟Refinement ServiceNMT 结果审校、风格修正、术语增强增益评估、低温采样Quality Evaluator离线/在线质量打分策略反馈、A/B 评估Document Pipeline长文本切块、异步翻译、结果合并顺序一致性、失败重试Glossary Service术语表、品牌词、禁译词、样式规则多租户隔离、热更新4.2 为什么路由器应该是编排器在小系统里，路由逻辑可以内嵌在接口实现中；但在生产环境里，路由器应该成为编排层，原因有三点：它不仅决定“走哪个模型”，还决定“是否需要缓存、术语注入、预处理、精修、回写、异步化”。它是成本与质量策略最集中的位置，天然适合做动态规则下发。它需要观察下游可用性和预算状态，做在线降级。因此更准确的命名应该是Routing Orchestrator，而不是简单的Router。五、高可用设计：不能把翻译引擎当成普通 RPC 服务翻译系统最大的误区之一，是把模型调用当成普通微服务调用处理。实际上，模型推理服务具有明显不同的特性：资源瓶颈更偏向 GPU、显存和队列长度