Hy-MT2 没有新版，但腾讯翻译开了条新线：Hy-SimulMT 的 3 秒同传与三种部署方式

资讯

先给结论，省得你翻半天：Hy-MT2 本身没有出新版。截至 2026 年 11 月 12 日，腾讯混元 Hy-MT2 仓库里的模型仍然只有 2026 年 5 月 21 日开源的那三个尺寸——1.8B、7B、30B-A3B，没有任何 v2.1、也没有 Hy-MT3。GitHub 上最后一次提交停在 8 月 26 日，改的还只是 README。

但如果只答"没有新版"就交差，等于没查。真正的情况是：腾讯把翻译这件事在 10 月往前推了一大步，只是没放在 Hy-MT2 这个名字下面。新东西叫 Hy-SimulMT，做的是实时同声传译；同时 Hy-MT2 的三个尺寸在 8 月悄悄上了托管 API；再叠加 11 月 18 日深圳 APEC 峰会前的落地，这条线其实比"发个新版"热闹得多。

下面把版本、能力、价格、部署门槛和官方自己承认的短板，一次讲清。

一、先把版本理清楚：Hy-MT 这条线三年走了四步

混元翻译不是只有一个 Hy-MT2，它是一条有明确代际关系的产品线。搞不清这条线，很容易把"API 更新"当成"模型更新"。

  • 2025 年 9 月 1 日：开源 Hunyuan-MT-7B 与 Hunyuan-MT-Chimera-7B。同年在 WMT2025 通用翻译赛道的 31 个语种里拿下 30 项第一，这是这条线最初的立足点。
  • 2025 年 12 月 30 日：开源 HY-MT1.5-1.8B 与 HY-MT1.5-7B，正式把"1.8B 小模型"作为端侧主力推出来。
  • 2026 年 4 月 29 日：开源 HY-MT1.5-1.8B 的 1.25-bit 极端量化版，体积压到约 440MB，可以在手机上离线跑。
  • 2026 年 5 月 21 日：开源 Hy-MT2 家族（1.8B / 7B / 30B-A3B），同时开源自建的翻译指令遵循评测集 IFMTBench。5 月 28 日补了 30B-A3B 的 FP8 量化版。
  • 2026 年 8 月 20 日：三个尺寸陆续出现在腾讯云的托管端点上，开始按 token 计费。
  • 2026 年 9 月 24 日：消费级产品"腾讯 Hy 翻译"App 在国内外应用商店上线。
  • 2026 年 10 月 26 日：Hy-SimulMT 发布并开源，同时以 APEC 志愿服务版的形式进 App。

看这条线就能明白一件事：腾讯在翻译上的节奏是"半年一个模型、季度一个形态"。模型侧 5 月刚打完一代，接下来几个月它把力气花在了"怎么让人用上"——先是 API，再是 App，最后是同传。

二、Hy-MT2 到底是什么：三个尺寸、两种用法

Hy-MT2 官方定位是"面向真实复杂场景的快思考多语言翻译模型家族"，支持 33 种语言互译，外加若干中国民族语言与方言。三个尺寸各有明确分工：

  • Hy-MT2-1.8B：端侧主力。靠 AngelSlim 的 1.25-bit 极端量化，只需要约 440MB 存储，能在苹果、高通、联发科的手机芯片上本地推理，速度比上一代快约 1.5 倍。官方称它在整体效果上超过微软、豆包这类主流商业翻译 API。
  • Hy-MT2-7B：稠密模型，质量与成本的平衡档。
  • Hy-MT2-30B-A3B：MoE 架构，总参 30B、每 token 激活约 3B，是这一代的旗舰。

比尺寸更值得注意的是它支持哪些"翻译指令"。Hy-MT2 不是只能做"整段换语言"，它内置了六类任务模板：默认翻译、术语表约束、风格迁移、个性化偏好、分隔符保真、结构化数据（HTML / JSON）翻译。其中结构化那一条写得很硬：禁止翻译代码标签、键名、{{var}}、%s 这类占位符，只翻用户可见文本。

这才是它跟"拿个通用大模型写提示词翻译"的真正区别——能塞进工程流水线，不用每次都跟模型斗智斗勇。做过站点本地化的人应该懂，键名被翻掉的痛，比翻译质量差一点点严重得多。

三、第一个"新版"其实是 API，而且价格比想象中低

很多人问"有没有新版"，其实想问的是"有没有更方便的用法"。8 月 20 日，Hy-MT2 的三个尺寸上了托管端点，这件事几乎没怎么宣传，但它的意义不比发模型小。

在这之前，想用 Hy-MT2 只有两条路：自己把 Apache-2.0 权重拉下来，用 transformers / vLLM / SGLang / llama.cpp 搭一套；或者装腾讯的消费级 App。前者要占 GPU，后者没法编程接入。托管 API 补上了中间那条。

按 OpenRouter 等聚合平台的公开定价（服务提供方标注为 Tencent Cloud），三个尺寸的价格是：

  • Hy-MT2-1.8B：输入 $0.044 / 百万 token，输出 $0.177 / 百万 token
  • Hy-MT2-7B：输入 $0.074 / 百万 token，输出 $0.295 / 百万 token
  • Hy-MT2-30B-A3B：输入 $0.074 / 百万 token，输出 $0.295 / 百万 token

规格是 8,192 token 上下文、最长 4,096 token 输出，不支持函数调用，但可以通过 response_format 里的 JSON schema 拿结构化输出。

翻译是少数"输出几乎占全部成本"的负载，所以输出单价才是决定一条流水线能不能跑量生产的关键数字。7B 和 30B-A3B 同价、输出都不到每千 token 0.3 美分，这个定价策略很直白：让你没理由为了省钱去用小模型。

⚠️ 这里有个容易踩的口径坑，必须说清楚：腾讯云官方文档里的翻译 API 至今仍是老的 hunyuan-translation，2025 年 10 月更新的那一版，上下文只有 4K 输入 / 4K 输出，支持 33 种语言加 5 种民族语言互译，那是 WMT25 时代的模型。Hy-MT2 的开源权重、聚合平台上的 tencent/hy-mt2-*、云上这个 hunyuan-translation，是三个不同的东西，不要看名字像就往一起凑。真要下单，以控制台实际列出的模型 ID 和报价为准。

四、真正的"新版"：Hy-SimulMT 把"等说完再翻"改成"边听边译"

10 月 26 日发布并开源的 Hy-SimulMT，是同一条翻译线上完全不同的产品形态：中英双向、语音进语音出的实时同声传译，还带实时音色克隆。

它要解决的矛盾

同传的难点从来不是"能不能翻"，而是"什么时候开口"。多等两句，语义更完整，但听众得多等；早点开口，就得承担译错再改的风险。Hy-SimulMT 走的是后者，官方把这套策略叫"先开口、后修补"——先输出一个译文，随着语境推进再回头修正。

广东外语外贸大学高翻学院副院长王巍巍在官方测评里给了个挺有意思的评价：修补的听感接近译员自己的自我修正。这比单纯报一个延迟数字更能说明它在实际场合听起来是什么样。

硬参数

  • 架构：30B-A3B MoE，总参数约 30.39B，每 token 激活约 3B
  • 模型类型：hy_v3，配套推理后端需要支持 HYV3ForCausalLM
  • 单次音频上限：30 秒。超长音频是直接拒绝，不是自动截断
  • 权重版本：6 个。按输出模式分"只出译文"和"原文+译文同出"两组，每组各有 BF16 / FP8 / GGUF 三种精度
  • 许可证：Apache-2.0

关于许可证这里插一句：GitHub 接口对这两个仓库返回的 spdx_id 都是 NOASSERTION，看着像"许可不明"，别被吓到。打开 LICENSE 原文就会发现，腾讯只是在标准 Apache-2.0 正文前面加了一段自己的版权声明和第三方组件说明，主体就是 Apache-2.0。Hy-SimulMT 那份还特意写明：Apache-2.0 只覆盖腾讯公开的推理代码、参数和权重，第三方组件仍按各自原许可走。

成绩单：赢的地方和输的地方

长音频评测集 RealSI 上，Hy-SimulMT 的 StreamLAAL 约 3 秒（这个指标衡量译文相对输入的流式滞后，越低越好），是官方图示里所有参评系统中最低的；GEMBA 翻译质量分高于所有对比的开源模型，也超过 5 个商业 API 中的 4 个。

四个短音频测试集的分数（越高越好）更能看出边界：

  • FLEURS：Hy-SimulMT 90.3，Gemini3.5-LiveTranslate 92.4，Qwen3.8-LiveTranslate 88.4
  • CoVoST2：Hy-SimulMT 75.5，Qwen3.8-LiveTranslate 82.1，Confucius4 76.8
  • ACL6060：Hy-SimulMT 81.2，Gemini3.5-LiveTranslate 82.6，Qwen3.8-LiveTranslate 80.5
  • RealSI-Sentence：Hy-SimulMT 84.7，全表最高

换句话说：在开源同传模型里它是最强的一档，但放到所有参评系统里，FLEURS 和 ACL6060 还是输给 Gemini3.5，CoVoST2 输给 Qwen3.8，而且 75.5 对 82.1 是差距最大的一处。这三处官方自己在 README 里就摆出来了，没藏。

另外他们还做了一个挺费劲的对照：收集 2026 年 9 月以后新出现在网上的 18 段中英文音频，每段约 6 分钟，覆盖软件与 AI、医学、制造能源、自然科学、农业食品、商务管理、法律、教育、文化文旅、体育生活十个领域，然后请 6 位持证同传译员（3 位 CATTI 一级、3 位 CATTI 二级）同场做同传。结果是延迟 3.3 秒对一级 4.5 秒、二级 4.7 秒，翻译质量达到专家组水平。

不过官方紧跟着加了一句限定：结论只适用于本次样本、参测译员和评测设置，不代表对播报音质、音色相似度这些维度的综合评价。这种主动划边界的写法，比堆一堆"全面领先"要可信。

三条部署路线，硬件门槛差很多

仓库给了三种跑法，选错了会很痛苦：

  • vLLM + SimulInfer（官方主推，全部 6 个权重都能用）：要求 Linux、Python 3.12+、NVIDIA GPU，vLLM 版本 ≥ 0.31 且支持 HYV3ForCausalLM。网页/API 默认 8080，模型服务 8800。语音输出和音色克隆需要另外接 TTS 服务，仓库本身不带。
  • llama.cpp（轻量，只支持 GGUF）：对架构的支持提交在 PR #31198，目前尚未合入官方仓库，暂时只能走 llama-mtmd-cli，llama-server 支持还要等。桥接端口 8094，模型端口 8080。
  • SGLang-Omni（服务化，限制最多）：只支持 BF16 的"仅译文"权重，FP8、GGUF 和原文+译文版本都不在支持范围。BF16 权重约占 57 GiB（不含 KV cache），单张 H200 可以跑。端口 8000，实时通道默认每 1.6 秒刷新一次翻译假设，30 秒后重置上下文。

官方还提醒了一个容易被误读的点：StreamLAAL 衡量的是整体流式滞后，不等于"首次开口延迟"。所以"3 秒响应"要理解成"译文跟着说话人的节奏走"，不是按了按钮等 3 秒才出第一个字。仓库里那两段演示视频是离线回放，播放节奏也不能当实时延迟来测。

五、APEC 那一周：翻译 App 才是它真正的落地形态

模型开源是一回事，普通人能不能用上是另一回事。这块腾讯的动作其实比模型更值得看。

9 月 24 日，"腾讯 Hy 翻译"App 在国内外应用商店上线，支持 33 种语言互译，覆盖 5 种中国少数民族语言及方言，提供语音、对话、拍照、文本四种基础能力，还有风格切换和翻译记忆库。

10 月 26 日，也就是 Hy-SimulMT 开源同一天，APEC 志愿服务版上线。这一版有几个细节很实在：

  • 在深圳市外办支持下，由腾讯"星"青年志愿服务队基于 Hy-MT2 打造
  • 与深圳市外办共建专业术语库，收了万余条深圳本地生活用语，世界之窗、大梅沙、陈皮、牛肉这类地名和餐饮词都能准确翻
  • 针对东南亚多元口音和非标准英语，补了大量带口音、带噪音的训练数据；还加了人声检测，在志愿服务站的嘈杂环境里过滤无效杂音
  • 搭载 1GB 端侧翻译模型，提前下载就能完全离线用，专门对付会场人流密集、网络拥堵
  • 目前无广告、全功能免费，已在 12 个国家和地区上架，包括美国、日本、韩国、新加坡、马来西亚、泰国、越南、缅甸，以及中国港澳台地区

注意这里的 1GB 和前面说的 440MB 不是一回事：440MB 是 1.8B 模型的 1.25-bit 量化体积，App 里这个 1GB 的端侧包还带了语音识别等组件。看到"1GB 离线模型"别直接对上"440MB 那个"。

2026 年 APEC 领导人非正式会议就在 11 月 18 日至 19 日的深圳。一个翻译模型赶在峰会前两周进入官方志愿服务体系，这件事本身就是最好的产品验证。

六、你现在该怎么用

按投入从低到高排：

  1. 只想用起来：装"腾讯 Hy 翻译"App，免费、无广告，支持离线。中英同传、拍照翻译、对话翻译都有。
  2. 要在自己的程序里调：走托管 API。Hy-MT2 三个尺寸在聚合平台上是 OpenAI 兼容接口，换个 base URL 和 model 名就能跑，8K 上下文对句子和段落级翻译够用，但要处理长文档得自己切块。
  3. 要在本地或私有环境跑：拉 Apache-2.0 权重自己部署。翻译文本用 Hy-MT2 的 1.8B 起步（440MB 就能跑），要质量上 7B 或 30B-A3B；要做同传才需要 Hy-SimulMT，那至少得有一张能扛住 30B 的卡，最轻的路线是 GGUF 走 llama.cpp，但要等 PR #31198 合入。

如果只是想把跨语言会议的字幕跑起来，还有一条更现实的思路：先用 Hy-MT2 做离线/半实时的文本翻译，把同传当成"锦上添花"而不是刚需。Hy-SimulMT 目前只覆盖中英双向，其他语种它接不了。

七、官方自己承认的边界

这一节的内容全部来自官方文档，不是我的判断。写在这里，是因为它们直接决定你能不能落地：

  • Hy-SimulMT 只支持中英双向，不是 33 种语言。多语种同传它做不了。
  • 语音输出和音色克隆需要另外配 TTS 服务，仓库不自带。
  • llama.cpp 的架构支持尚未合入官方仓库，SGLang-Omni 只支持 BF16 仅译文权重。
  • 单次音频上限 30 秒，超长直接拒绝而不是截断——这是那种"看起来能用、一上量就报错"的坑。
  • Hy-MT2 的托管 API 不支持函数调用，只有 8K 上下文。
  • 与人同传的对照结论只适用于那 18 段样本和 6 位译员，官方明确说不构成对音质、音色相似度的全面评价。
  • 官方自己也写了：AI 同传的定位是辅助工具，高风险场景仍然需要专业译员。

一句话总结

Hy-MT2 没出新版，但腾讯在翻译上今年的三步棋是"8 月上云、9 月进 App、10 月开同传"——模型没换，能用的形态换了三次。要文本翻译，Hy-MT2 三个尺寸现在都能直接调，1.8B 的 440MB 端侧版是这条线里最实用的一档；要实时同传，Hy-SimulMT 在开源阵营里确实领先，但它只做中英、需要 GPU、还得自己接 TTS。至于下一个 Hy-MT3，从这条线的节奏看，大概率要等明年上半年。

参考来源

说明：本文为版本梳理与产品解读，事实取自官方仓库、官方文档与公开报道；除特别注明外，未做独立实测。模型效果数据均为腾讯官方自评口径，第三方复现结果可能不同。

腾讯云精选福利

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

腾讯云精选福利