1GB 显存即可部署：腾讯 HY-MT1.5 的模型蒸馏与量化策略解析

随着大语言模型（LLM）的爆发，机器翻译（MT）领域正经历着从传统的 Transformer 架构向生成式 LLM 架构的范式转移。然而，如何在保持 LLM 高质量翻译的同时，解决端侧部署的资源瓶颈，始终是业界难题。

近日，腾讯混元团队（Tencent Hunyuan）发布了 HY-MT1.5 多语言机器翻译模型家族。该系列包含 1.8B 和 7B 两个版本，通过统一的训练配方（Training Recipe），在云端和移动端之间实现了性能与效率的平衡。本文将基于其技术报告，深入剖析 HY-MT1.5 的全链路训练框架、蒸馏策略以及在生产环境中的工程特性。

1. 模型概览：双端布局与核心定位

HY-MT1.5 系列并非单一模型，而是针对不同计算场景的组合拳：

• HY-MT1.5-7B（云端主力）：基于 WMT25 冠军系统 Hunyuan-MT-7B 的升级版。它专为服务器和高端边缘设备设计，能够处理混合语言场景、解释性翻译，并原生支持术语干预。其设计权衡是：在约 0.45秒 的延迟下提供极致的翻译质量。
• HY-MT1.5-1.8B（端侧先锋）：这是本文关注的重点。作为 7B 模型的“紧凑型”变体，其参数量不到前者的三分之一，但在基准测试中表现相当。经过量化后，该模型可运行于仅有 1GB 内存 的边缘设备上，处理 50 个 Token 的中文输入平均响应时间仅为 0.18秒。

这一布局显示了腾讯的策略：用大模型攻克长尾与复杂翻译，用小模型覆盖高频、低延迟的实时交互场景。

2. 核心技术：全链路机器翻译训练框架

与通用的 Chat LLM 不同，HY-MT1.5 采用了一套专为机器翻译定制的五阶段训练流水线。这种“专才”培养模式，是其在特定任务上超越通用大模型的关键。

2.1 预训练与微调 (Pre-training & SFT)

• **通用预训练 (General Pre-training)**：在海量多语言文本上构建共享的语言表征。
• **MT 导向预训练 (MT Oriented Pre-training)**：这是与通用 LLM 的分水岭。模型接触平行语料库和翻译导向的目标函数，将生成分布强行对齐到翻译任务，而非开放式文本生成。
• **监督微调 (SFT)**：利用高质量的句子级和文档级平行数据，进一步打磨字面准确性、领域覆盖率及翻译方向性（如 ZH -> EN 与 EN -> ZH 的差异）。

2.2 关键突破：在线策略蒸馏 (On-policy Distillation)

如何让 1.8B 模型拥有 7B 模型的智能？HY-MT1.5 采用了 在线策略蒸馏 技术，而非简单的 Logits 模仿。

1. Teacher-Student 架构：HY-MT1.5-7B 作为教师模型，HY-MT1.5-1.8B 作为学生模型。
2. 数据构建：收集覆盖 33 种语言的约 100 万个单语 Prompt。
3. **逆 KL 散度 (Reverse Kullback-Leibler Divergence)**：通过运行教师模型生成分布，利用逆 KL 散度强制学生模型的 Rollouts（生成路径）匹配教师的分布。

这种方法使得 1.8B 模型能够以极低的推理成本，继承 7B 模型的大部分翻译行为特质。

2.3 基于细粒度标准的强化学习 (RL with Rubrics)

在最后阶段，团队引入了基于规则的奖励模型（Rubrics based Reward Model）和类 Group Relative Policy Optimization 算法。

• 多维评分：不同于笼统的“好/坏”反馈，人工审核员从 准确性 (Accuracy)、流畅度 (Fluency)、地道程度 (Idiomaticity) 和 文化适宜性 (Cultural Appropriateness) 多个维度打分。
• 策略更新：奖励模型蒸馏这些细粒度评分，指导策略更新。这直接解决了传统 MT 模型“翻译准确但语气生硬”的痛点。

3. 性能基准：超越商业竞品与通用大模型

报告在 Flores 200、WMT25 及普通话-少数民族语言基准上进行了评估，使用 XCOMET-XXL 和 CometKiwi 作为核心指标。

3.1 核心数据对比

注：Minority 指普通话到少数民族语言的翻译对。

在人工评估（0-4分制，中英互译）中，HY-MT1.5-1.8B 获得了 2.74 的平均分，在同等协议下优于百度、Google、Microsoft 等主流商业翻译系统。这一数据证明了小参数模型在特定任务经过极致优化后，完全具备挑战“大厂 API”的能力。

4. 工程实践：面向生产环境的特性

对于开发者而言，模型不仅要“准”，还要“好用”。HY-MT1.5 通过 Prompt 模板原生支持了三项关键的工程能力，无需修改模型架构即可调用。

4.1 术语干预 (Terminology Intervention)

在法律、医疗或品牌出海场景中，特定词汇必须固定翻译。

• 问题：传统模型容易将专有名词（如游戏道具名）进行意译或音译，导致歧义。
• 方案：通过 Prompt 注入映射关系，例如 “混元珠 → Chaos Pearl”。
• 效果：模型强制执行领域特定的术语一致性，而非输出模糊的直译。

4.2 上下文感知 (Context Aware Translation)

• 案例：单词 “pilot” 在无语境下常被译为“飞行员”。
• 方案：通过模板输入一段关于电视剧的上下文背景。
• 结果：模型能够准确地将 “pilot” 翻译为“试播集”（Episode），消除了多义词歧义。

4.3 格式保持 (Format Preserving Translation)

这是 Web 开发和文档本地化中最头疼的问题——翻译破坏了 HTML/XML 标签。

• 机制：使用 <source> 和 <sn> 标签包裹源文本。
• 指令：强制模型在 <target> 输出中保留标签结构。
• 价值：使得 HTML 页面或带有代码片段的 XML 文档在翻译后仍能被程序正确解析，极大降低了后期人工修复成本。

5. 部署策略：量化与边缘计算

针对端侧部署，腾讯提供了 FP8 和 Int4 (GPTQ) 的量化版本。

• FP8 量化：几乎无损。在 Flores 200 (ZH -> XX) 上，得分为 0.8379，与全精度模型的 0.8361 几乎持平（甚至微弱波动优势）。
• Int4 量化：虽然在 Flores 200 上有明显的质量下降，但它换来的是极致的压缩率。
• 硬件门槛：量化后的 1.8B 模型可运行于 1GB 显存/内存 环境。

这意味着，即便是中低端的手机或嵌入式设备，也能运行超越主流商业 API 质量的离线翻译服务。目前，FP8、Int4 (GPTQ) 及 GGUF 格式均已在 Hugging Face 开源，适配标准的 LLM 推理栈。

结语

腾讯 HY-MT1.5 的发布，为技术社区提供了一个极具价值的范本：在特定领域任务中，通过高质量的数据管道、知识蒸馏和细粒度 RLHF，小模型完全可以战胜通用大模型。