Hy-SimulMT – 腾讯混元开源的实时同声传译模型，支持中英双向与音色克隆

Hy-SimulMT 是腾讯混元于 2026 年 10 月开源的实时同声传译大模型，用于中文与英文之间的语音到语音翻译，说话人可持续输入音频、模型边听边译并同步给出译文文字，配置 TTS 服务后可输出译文语音并保留原说话人音色，适用于会议、演讲、访谈的实时字幕与配音，以及需要私有化部署的跨语言录制场景。

Hy-SimulMT 的核心能力

先看表里几处决定落地方式的设置：中英双向划定了当前覆盖的语向，30B 总参数、3B 激活决定加载权重时的显存规模，纯译文与原文加译文交错两类变体对应不同的下游管线，8080 与 8800 两个端口把 Web 服务与模型服务分开。滞后一侧的数值写在 StreamLAAL 约 3 秒这一栏，它衡量流式翻译的滞后程度，不等于首字输出时间；质量侧的分数另见后文。

音频持续输入、边听边译

说话人的音频可以不间断输入，模型在语音流尚未结束时就开始组织译文，先给出译文文字，配置 TTS 后同时输出译文语音。这与「整段音频结束后再翻译」的批处理方式不同，不必等整段说完再开始；长音频里的上下文理解与系统负载仍会影响实际表现。

纯译文与原文加译文两类变体

同为 30B-A3B 结构，一类只输出译文，另一类同时输出源语言文本与译文，后者适合要保留双语对照的会议记录与字幕场景，排版与落盘格式由所用推理服务决定。两类各提供 BF16、FP8 与 GGUF 版本共六个权重，BF16 是基础版本，量化版降低显存占用但需核对译文质量。同团队的 Hy-MT2 走纯文本翻译路线，两条管线可串联使用。

实时克隆原说话人音色

生成目标语言语音时会沿用原说话人的音色特征，但这一步依赖另外接入的 TTS 服务：官方仓库明确说明语音输出与音色克隆都需要配置 TTS，只下载翻译权重并不能直接获得完整的语音生成能力。官方英文到中文的演示包含三位说话人，模型能分别呈现不同音色；演示为录制视频，其中的节奏不代表实时延迟。

长音频上的延迟与质量取舍

官方在开源 RealSI 长音频测试集上对比了多个开源同传模型与商业 API：StreamLAAL 约 3 秒，为图示参评系统中的最低值；GEMBA 一项超过同表全部开源模型，并高于五个商业 API 中的四个。官方同时说明该指标衡量流式翻译的滞后程度，不等于首字输出时间。

四个短音频测试集的成绩

四个公开测试集上，Hy-SimulMT 的 FLEURS、CoVoST2、ACL6060 与 RealSI-Sentence 分别为 90.3、75.5、81.2 与 84.7。RealSI-Sentence 为官方表格中所有参评系统的最高值；FLEURS 与 ACL6060 高于表中其他开源模型，但低于 Gemini3.5-LiveTranslate 的 92.4 与 82.6；CoVoST2 落后于 Qwen3.8-LiveTranslate 的 82.1 与 Confucius4 的 76.8，四项并不构成全面领先。

与专业译员的同场对照

官方收集 2026 年 9 月之后出现于互联网的 18 段中英文音频，每段约 6 分钟，覆盖演讲、访谈与会议等场景以及十个领域，并邀请六位有同传实战经验的译员对照，其中三位持 CATTI 一级口译证书、三位持二级，每个证书等级取三位译员中的最高成绩作为比较基准。官方明确结论仅适用于本次样本、参与译员与评测设置，不能推断模型在所有会议场景都达到或超过专业译员水平。

Hy-SimulMT 与同类同传系统的对比

下表整理自腾讯混元官方公布的四个短音频测试集结果，四个系统在同一张比较表内给出，因此只做同表内横向比较，不与其他来源的分数拼接；各家未披露完全一致的推理配置，这里比较的是公开成绩，不是控制变量的独立复测。

差异集中在两处。短句质量并非全面领先：FLEURS、ACL6060 与 RealSI-Sentence 三项居前，CoVoST2 一项落后于两个对比系统，说明不同数据分布下的表现并不一致。部署形态决定使用边界，官方表里只有 Hy-SimulMT 明确给出可下载权重与本地部署路径，其余系统以接口或未标注形态出现。

两点口径需注意：表外系统的音色克隆与获取方式官方未标注，按「未标注」照录；分数取自官方同一张表格，各系统的实现与评测配置未必一致，不宜据此推断其他语向或真实会议场景的表现。站内另有两篇对照可参考：Qwen3.8-LiveTranslate 记录了阿里这条同传路线，Confucius4 转 T3PO 则是把文本翻译模型接到语音链路上的做法。

如果更关心「语音进来、语音出去」这条链路怎么搭，站内的 T3PO 记录了一套语音到语音的串联方案，与同传模型的差别在于它不是为流式输入设计的。

Hy-SimulMT 的应用场景与适用人群

它的价值出现在「说的是中文、听的是英文，而且不能等」的场合；只需要把录好的音频转成文字稿的，用常规转写工具更省事：

• 线上会议与研讨会：中英双向实时输出译文文字，接入 TTS 后同步输出译文语音，减少逐句等待。
• 访谈与直播：多人对话下按说话人保留音色，听众能分辨谁在发言。
• 跨语言录制与配音：译文语音沿用原说话人音色，便于后期剪辑时与原声对照。
• 私有化部署：权重可下载，在推理服务与 TTS 都不出网的条件下，音频可以留在局域网内。

适用人群：适合需要中英双向实时字幕与语音、对音频出网有要求的企业与团队，也适合做跨国会议服务的技术供应商；官方明确高风险与需严格责任判断的场景仍需专业译员参与，个人临时体验可用 Hy 翻译 App。

Hy-SimulMT 的使用方法

官方给了三条路径：在 Hy 翻译 App 中体验、自行部署推理服务、在自有数据上继续训练。准备成本依次升高，可控程度也依次提升。推理后端不止一种：SimulInfer 配 vLLM 是主路径，SGLang-Omni 当前只覆盖 BF16 纯译文版本且返回译文文本，语音输出仍需另接 TTS。

先用 App 验证效果

1. 在 Hy 翻译 App 中选择同声传译功能，按官方说明选定中英方向。
2. 用一段真实会议或访谈音频试听，重点看译文语音的音色是否可辨。
3. 记录延迟与漏译情况，再判断是否值得投入部署成本。

本地部署推理服务

1. 从 代码仓库 克隆项目并进入推理目录。
2. 运行 deploy.sh --install-server --model 指定权重，脚本会先起 vLLM 再起 Web 与 API 服务。
3. 等待 Ready 提示后访问 8080 端口，选定翻译方向即可开始流式翻译。

在自有数据上继续训练

1. 按仓库说明准备 SimulTrain 训练环境与音频标注数据。
2. 以已发布的权重为起点继续训练，先在少量样本上验证损失下降。
3. 训练完成后导出权重，回到 SimulInfer 重新加载并复测延迟。

四点需留意：官方 SGLang-Omni 说明中的 BF16 权重约占 57 GiB，不含 KV Cache 与运行时分配，也不能据此推算 FP8 与 GGUF 的占用；llama.cpp 适配尚未并入上游主线，当前只支持 llama-mtmd-cli，走 GGUF 需自行编译对应分支；SimulInfer 默认占用 8080 与 8800，SGLang-Omni 的 Web 与 API 端口是 8000，同机部署前先对齐；部署脚本重复执行会重装依赖，生产环境建议固定版本后改用配置文件启动。想对照现成的会议同传服务，站内记录了 百度AI同传助手 的产品形态。

Hy-SimulMT 的项目地址

• 项目仓库：https://github.com/Tencent-Hunyuan/Hy-SimulMT
• 模型权重：https://huggingface.co/tencent/Hy-SimulMT-30B-A3B
• 官方模型页：https://hy.tencent.com/model/open-source-model/detail?id=hy-simulmt

Hy-SimulMT 的价格与开源情况

权重以 Apache-2.0 协议开源，可在 Hugging Face 与魔搭社区免费下载，商用与二次分发按该协议条款执行，第三方组件另按其原始许可。官方未公布按次或按分钟的调用计费方案，成本主要落在自有推理的算力上。

不想自建的话，官方给出的入口是 Hy 翻译 App，适合先验证效果。企业侧更常见的是把权重放进内网：只有推理服务与 TTS 都不经过外部网络时，音频才真正留在局域网内，也没有按量计费支出，代价是自己维护推理服务与显存。

Hy-SimulMT 的常见问题