腾讯开源3秒同传，声音也能一起翻

腾讯把中英同传模型开源了

腾讯混元今天（10月26日）发布并开源同声传译模型 Hy-SimulMT，主打中英双向流式翻译、约3秒响应延迟，以及与实时音色克隆能力结合的语音到语音体验。

Hy-SimulMT 是一款面向中英双向实时翻译的流式模型，它不需要等整段讲话结束，而是在持续接收音频的同时生成译文。 腾讯已经在「Hy 翻译」App 中首发相关能力，普通用户可以免费体验；开发者则可以获取模型权重、流式推理服务与训练工具，自行搭建会议翻译、跨境直播或语音助手。

这次发布最值得关注的并不是“又一个中英翻译模型”，而是腾讯试图同时解决同传系统最难兼顾的三个指标：翻译质量、输出延迟和说话人声音保留。传统系统往往只能三选二——翻得准就要多等上下文，出声快就容易断句错误，保留原声则会进一步增加语音合成耗时。

Hy-SimulMT 给出的答案是约3秒翻译滞后。这个数字已经低于腾讯测试中专业同传译员平均4至5秒的延迟，但它并不意味着从录音到出声的所有环节都固定在3秒以内，更不代表每个字只需3秒即可翻译完成。

3秒是翻译滞后，不是首字延迟

StreamLAAL 是衡量流式翻译输出相对输入内容滞后程度的指标，数值越低，说明译文跟随说话人的速度越快。 腾讯在 RealSI 长音频评测集上报告，Hy-SimulMT 的 StreamLAAL 约为3秒，同时取得了对比开源模型中领先的翻译质量。

这个指标比常见的“首字延迟”更适合同传场景。首字延迟只统计系统多久开始说第一句话，却可能掩盖后续不断掉队的问题；StreamLAAL 会观察整段翻译过程中输入和输出的对齐状态，更接近听众真实感受到的字幕或译音滞后。

3秒也不是一个可以在所有设备和网络条件下复现的固定值。完整语音同传链路通常还会受到音频采集、语音活动检测、模型推理、语音合成、网络传输和播放缓冲影响，开发者自行部署后的端到端延迟可能高于基准结果。

目前相对可信的公开材料支持的是“RealSI 长音频约3秒”，而不是部分二手内容声称的“平均延迟低于380毫秒”。后一个数字没有出现在现有主要发布信息中，也与长音频 StreamLAAL 的定义不是一回事，不应混为同一项性能指标。

30B-A3B：参数不小，但每次不用全跑

Hy-SimulMT-30B-A3B 是一个总参数约304亿、单次推理激活约30亿参数的混合专家模型。 其中 A3B 的含义可以简单理解为：模型拥有约300亿参数的总体知识容量，但处理每个 token 时只调动约30亿参数，而不是让全部参数同时参与计算。

MoE 是通过路由机制按需激活部分专家网络的模型架构。 它的优势是可以在扩大总参数规模的同时控制单次计算量，代价则是显存占用、专家调度和多卡通信通常比同等激活参数的稠密模型更复杂。

这一设计让 Hy-SimulMT 更适合服务器侧实时部署，但它依然不是可以轻松塞进普通手机的“小模型”。即使存在 FP8 量化版本和 GGUF 格式，30B 级总参数对应的权重体积、内存带宽以及持续流式推理负载，仍然对消费级设备构成明显压力。

开发者更应该把 Hy-SimulMT 看成可私有化部署的实时翻译底座，而不是手机端离线翻译插件。企业会议、客服质检、跨境直播和教育课程是更现实的首批场景，因为这些应用可以接受工作站或服务器部署，也更重视数据留在本地。

“语音到语音”并不等于单模型包办全部环节

语音到语音翻译是把一种语言的输入语音转换为另一种语言的输出语音，并尽量保留语义、节奏和说话风格的系统能力。 从用户体验看，Hy-SimulMT 可以边听边译并输出带有原说话人特征的译音；从工程实现看，翻译模型与语音合成模块仍应分开理解。

公开部署信息显示，Hy-SimulMT 的核心职责是流式理解与生成译文，而语音输出和音色克隆需要另外配置 TTS 服务。换句话说，开源权重解决的是同传链路中最关键的翻译决策问题，但开发者若想复现「Hy 翻译」App 那种完整的语音到语音效果，还需要搭建语音合成、声纹条件控制和实时播放链路。

实时音色克隆是根据短时说话样本提取声纹与韵律特征，再让合成语音呈现相似音色的技术。 它比普通 TTS 多做了一件事：输出的不只是“正确的英文声音”或“正确的中文声音”，而是尽量听起来仍像原来的说话人。

音色克隆对跨语种会议有实际价值。传统同传把所有人的声音统一替换成一种播音腔，听众很难仅凭声音区分不同发言者；如果系统能保留每个人的音色、语速和部分情绪，远程会议中的身份辨识和交流连续性都会更自然。

音色克隆也带来了比文本翻译更直接的安全问题。企业在部署时至少需要加入用户授权、合成语音标识、声纹数据加密和滥用审计，不能因为模型开源，就默认任何采集到的声音都可以用于复刻。

跑分领先开源模型，但并非每项第一

RealSI 是面向真实长音频同声传译的评测集，重点考察模型在连续讲话中的翻译质量和延迟。 腾讯公布的结果显示，Hy-SimulMT 在较低延迟下取得了开源模型中的最佳质量表现，并超过参与比较的5个商业服务中的4个。

短音频测试则给出了更细的能力边界。Hy-SimulMT 在 FLEURS、ACL6060 和 RealSI-Sentence 上具备竞争力，但在 CoVoST2 上低于 Qwen3.8-LiveTranslate，在 FLEURS 与 ACL6060 上也没有超过 Gemini3.5-LiveTranslate。

| 短音频基准 | Hy-SimulMT | Qwen3.8-LiveTranslate | Gemini3.5-LiveTranslate | Seed-LiveInterpret 2.0 | |---|---:|---:|---:|---:| | FLEURS | 90.3 | 88.4 | 92.4 | 85.8 | | CoVoST2 | 75.5 | 82.1 | 74.4 | 67.7 | | ACL6060 | 81.2 | 80.5 | 82.6 | 74.8 | | RealSI-Sentence | 84.7 | 84.4 | 82.2 | 80.0 |

这组数据说明 Hy-SimulMT 的优势更像是“质量与延迟的综合平衡”，而不是在所有翻译测试上绝对领先。对同传系统而言，这种平衡通常比单项最高分更重要，因为一个需要等待十几秒才能输出的高分模型，并不能真正替代实时翻译。

| 对比维度 | Hy-SimulMT | 专业人类同传 | 常见开源级联方案 | |---|---|---|---| | 典型延迟 | 官方测试约3秒 | 腾讯测试平均约4—5秒 | 取决于 ASR、翻译和 TTS 缓冲策略 | | 输出方式 | 边听边译 | 边听边译 | 常见为识别后翻译，再进行合成 | | 中英双向 | 支持 | 取决于译员语言组合 | 取决于所选模型 | | 音色保留 | 可结合 TTS 实现实时克隆 | 由译员声音代替原声 | 通常使用固定合成音色 | | 私有化部署 | 开源权重，可自行部署 | 不适用 | 通常可部署，但集成成本较高 | | 长上下文纠错 | 依赖模型和流式策略 | 可利用语境主动修正 | 容易受前级识别错误累积影响 |

与专业译员的比较，样本仍然不算大

腾讯此次人机对比是一项覆盖10个领域、18段新近真实音频的小规模能力测试。 测试音频主要来自2026年9月以后出现的互联网内容，每段约6分钟，包含软件与 AI、医学、制造能源、自然科学、农业食品、商务管理、法律、教育、文化旅游和体育生活等领域。

参与对比的6位译员都拥有多年同传经验，其中3位持有 CATTI 一级口译证书，另外3位持有 CATTI 二级口译证书。腾讯给出的结论是，Hy-SimulMT 在这组样本上的翻译质量达到专业译员水平，评分更高，同时输出延迟更低。

这项结果可以证明模型已经进入“可与专业译员放在同一张表里比较”的阶段，但还不足以证明它普遍超过人类。18段、每段约6分钟的测试总量仍然有限，而且结果会受到音频难度、口音、术语密度、评分模型以及人类对照组选取方式影响。

自动评分本身也需要保留审慎态度。官方材料将长音频质量指标描述为由 GPT6.1-Sol 评分，这类模型裁判适合低成本扩大评测规模，却无法完全替代双语专家对漏译、误译、语气、文化含义和法律责任表述的逐句检查。

Hy-SimulMT 真正解决的是“什么时候开始翻”

流式翻译最困难的问题不是翻译一句完整的话，而是在话还没说完时决定要不要开始输出。 中文和英文的语序差异会让这个问题尤其棘手，例如中文可能直到句尾才给出关键谓语或否定信息，模型若过早开口，就可能只能中途改口。

传统级联系统通常按照“语音识别、机器翻译、语音合成”三段运行。它的好处是每个模块都能单独替换和调试，坏处是错误会逐层放大：识别阶段漏掉一个否定词，翻译模块不会知道原始声音里说了什么，合成模块又会把错误结果流畅地读出来。

Hy-SimulMT 的关键价值在于把增量语音上下文与翻译决策放到统一的流式过程中处理。模型需要动态判断哪些内容已经足够确定、哪些内容还应等待后文，并在延迟和准确率之间持续做取舍，这比离线翻译完整句子更接近真正的同传工作方式。

不过，“边听边译”也意味着模型无法永远等到信息完全明确。遇到数字密集、长距离否定、缩写、专有名词或多人抢话时，系统仍可能出现前半句已经输出、后半句无法自然修正的问题，开发者需要通过术语表、上下文提示、回滚策略和字幕修订机制降低风险。

开源的意义大于免费体验

Hy-SimulMT 的直接竞争力来自 Apache 2.0 许可下的模型权重和部署工具，而不只是一个免费 App。 根据目前发布信息，腾讯同步提供 Hugging Face 与 ModelScope 权重，并在 GitHub 提供 SimulInfer 流式推理服务和 SimulTrain 训练工具。

SimulInfer 面向实时推理，覆盖网页体验、音频文件输入和实时 WebSocket 流式传输，部署环境要求 vLLM 0.31 或更高版本。SimulTrain 则让团队可以围绕行业术语、特定口音和会议场景继续训练，而不是只能接受通用模型的默认表现。

FP8 量化版和 GGUF 版本降低了尝试门槛，但不会自动解决生产部署问题。真正上线还需要处理并发会话、首包等待、音频抖动、GPU 显存规划、TTS 排队、敏感信息过滤以及长时间运行后的延迟漂移。

腾讯目前没有把官方托管接口作为这次发布的重点，因此开发者面对的是一套可控制、但也需要自己负责运维的开源方案。对于不想部署基础设施的普通用户，「Hy 翻译」App 更合适；对于有隐私、成本或定制需求的团队，开放权重才是这次发布的核心价值。

哪些场景值得用，哪些场景仍应谨慎

Hy-SimulMT 最适合内容可以容忍少量修正、同时又高度重视实时性的场景。 跨国视频会议、开发者大会字幕、跨境直播、在线课程和内部培训都具备这一特征，3秒左右的滞后不会明显打断交流，音色保留反而能提升观看体验。

医疗会诊、法律谈判和高风险商务签约仍不适合完全无人值守。模型即使平均质量达到专业译员水平，也可能在低频术语、数字单位、责任边界和否定结构上产生关键错误，而这些错误的代价远高于普通会议中的措辞不够自然。

企业采购时也不应只比较一个质量分数。更有效的测试方式是准备自己的真实录音，分别测量首段输出时间、平均 StreamLAAL、术语准确率、数字错误率、多人声分离能力以及连续运行30分钟后的稳定性。

结论：这是一套能落地的同传底座，不是译员终结者

Hy-SimulMT 把开源同传系统推进到了可用区间，但“超越人类译员”仍然只适用于腾讯公布的特定测试。 约3秒长音频滞后、30B-A3B 的 MoE 架构、可私有化部署以及实时音色克隆，使它比单纯的字幕翻译模型更接近完整产品。

它当前最有价值的地方，是让开发者不用从 ASR、机器翻译和 TTS 三套系统开始拼装，也能快速获得一套质量与延迟相对平衡的流式翻译底座。至于能否取代专业译员，答案仍取决于场景：普通会议和内容消费已经可以大量自动化，高风险沟通则仍需要人工复核。

参考来源

• IT之家：腾讯混元同声传译大模型 Hy-SimulMT 开源——包含约3秒延迟、RealSI 评测、人类同传对比和「Hy 翻译」App 等发布信息。
• Tencent Hunyuan GitHub 组织主页——腾讯混元开源项目、推理工具与后续代码更新入口。
• 腾讯 Hugging Face 主页——腾讯开源模型权重、模型卡和量化版本的发布入口。