为 Hy-SimulMT-30B-A3B 制作的主视觉标题卡,副标题为“腾讯的 3 秒同传,未发新闻稿便上线”,画面展示蓝色音频波形流入一张卡片,卡片中有“源语音”行和“译文”行,二者由“交错”箭头连接;三个数据标签分别显示“总参数 30.4B / 激活约 3B”“StreamLAAL 约 3 秒”和“Apache-2.0”;日期徽标写着“权重于 2026 年 10 月 22 日上线”;右下角为 OrcaRouter 标志。
Guides & Insights

Tencent 打造了一款 3 秒口译器,并在没有新闻稿的情况下发布了它

作者

Gideon Frost

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

2026年10月22日,Hugging Face 上的 tencent 组织下出现了一个新模型系列中的六个仓库。本文要介绍的是Hy-SimulMT-30B-A3B-Interleave,这个变体会同时输出识别出的源文本和译文;它的同系列模型Hy-SimulMT-30B-A3B则只输出译文。两者均为 Apache-2.0,均为304亿参数,且都为一项腾讯此前任何翻译发布都无法完成的任务而构建:在中文或英文语音被说出的同时聆听,并在句子仍未结束时生成另一种语言。四天后,主仓库显示下载量为零、点赞数为两个。没有混元博客文章,没有新闻稿,没有 arXiv 论文,在整个月里持续报道腾讯翻译业务的中文报道中也没有任何一行提及。唯一的公告是模型卡 News 部分中一条标注日期的条目,添加于10月26日,内容为:已发布。

权重实际能做什么,与它们发布时有多高调,两者之间的落差才是关键。一个延迟约三秒、可按宽松许可证下载的同声传译模型,并不是一次常规发布——它让翻译应用从需要你一句我一句轮流使用的东西,变成了能在会议中佩戴使用的东西。这种沉默最可能的解释就在日程表上:腾讯于10月23日成为在深圳举行的亚太经合组织第三十三次领导人非正式会议的战略合作伙伴,而这一天正是权重上线后的第二天;其 Hy Translate 应用也被指定为服务于该活动的志愿者和工作人员的官方 AI 翻译工具,活动于11月18日至19日举行。这是根据公开日期作出的推断,并非腾讯的表态。下文将区分该仓库所证明的内容与它仅仅暗示的内容。

仓库里实际上有什么

该架构是一个语音输入、文本输出的因果语言模型,标记为 hy_v3,并以 HYV3SpeechForCausalLM 实例化。其配置明确给出了一个稀疏混合专家栈:48 层,隐藏大小为 2,048,128 个专家且专家隐藏维度为 768,每个 token 使用八个路由专家加一个共享专家,并在前端设有一个单一的密集层。safetensors 索引统计出 BF16 格式下有 30,394,788,480 个参数,另有 6,016 个参数以 F32 存储。Tencent 从未解释名称中的“A3B”,但算术结果与之相符:八个路由专家加一个共享专家,在那种专家宽度下,算下来每个 token 大约有 30 亿活跃参数。这是我们根据已发布配置做出的计算,而非厂商数字。

音频前端位于同一个配置文件中,而不是隐藏在流水线之后:128 个梅尔频带、一个宽度为 1,024 的 24 层编码器并投影到 2,048、16 kHz 采样,以及每个输入窗口最多 480,000 个采样点——即三十秒。生成默认使用温度 0.0 和 max_new_tokens 为 64,这正是你期望从一个被设计为输出一小段翻译文本然后等待更多音频的模型中得到的行为。最大位置嵌入列为 262,144;模型卡未公布可用的上下文长度,而对于流式音频,这个数字远不如三十秒窗口有意义。

一次性发布了六个检查点:基础版和 Interleave,各自都有一个 FP8 构建和一个 GGUF 构建。许可证文件为 Apache-2.0,并带有惯常的例外条款,即捆绑的第三方组件保留其自身条款。模型卡列出了十二位贡献者,链接到一个 GitHub 仓库,其中包含一个名为 SimulInfer 的推理服务和一个名为 SimulTrain 的训练工具包,并且引用的是腾讯产品页面而非论文。

A screenshot of the Hugging Face model card for tencent/Hy-SimulMT-30B-A3B-Interleave, showing the title, the Translation, Transformers and Safetensors tags, a '36 languages' tag, the hy_v3 architecture tag, 'License: apache-2.0', a model size of 30B params in BF16 and F32, a blank 'Downloads last month' figure, and an inference-provider panel that reads 'This model isn't deployed by any Inference Provider'.

延迟数值,以及那条削弱了标题结论的基准测试行

对同传模型而言,真正重要的论断不是孤立的翻译质量,而是在给定延迟下的质量。腾讯在 RealSI 长篇音频上对此进行评估,并报告 StreamLAAL 约为三秒,称其在所比较的系统中最低;其 GEMBA 分数高于比较中的开源模型,以及五个商业 API 中的四个。StreamLAAL 衡量的是流式场景下源语言与目标语言 token 之间的平均延迟;它不是首音频时间,模型卡也明确说明了这一点。模型卡同样没有点名在 GEMBA 上胜过它的第五个商业 API。

简表信息量更大,因为它在某一列上不那么好看。在四个公开基准上,腾讯报告 Hy-SimulMT 在 FLEURS 上为 90.3,在 CoVoST2 上为 75.5,在 ACL6060 上为 81.2,在 RealSI-Sentence 上为 84.7。与之相对,Qwen3.8-LiveTranslate 分别为 88.4、82.1、80.5 和 84.4;Gemini3.5-LiveTranslate 分别为 92.4、74.4、82.6 和 82.2;Seed-LiveInterpret2.0 分别为 85.8、67.7、74.8 和 80.0。要读各列,而不是读总结:Hy-SimulMT 在开源系统中赢得 FLEURS、ACL6060 和 RealSI-Sentence,在 CoVoST2 上输给 Qwen 6.6 分,在 FLEURS 上输给 Gemini 2.1 分。卡片自己的那句话——在 FLEURS、ACL6060 和 RealSI-Sentence 上高于其他开源模型——措辞范围很谨慎,而缺失的那个基准正是它表现最差的那个。那张表里的每个数字都由腾讯产出。没有独立实验室运行过这个模型。

与人类的比较值得比标题所暗示的更仔细地审视

腾讯还委托开展了一项与专业口译员的匹配对比:18段中英文录音自2026年9月起在线发布,每段约六分钟,涵盖从软件、医学到法律、农业的十个领域,由六名专业人士进行口译——三人持有CATTI一级证书,三人持有二级证书。每个认证级别均以三名口译员中的最佳者作为对比基准。结论是,该模型达到与专家级人类同声传译员相当的质量,同时往往响应更快。

这是一个引人注目的结果,但它规模也很小,卡片在脚注中明确说明了这一点:这些发现仅适用于那些样本、那些口译员和那种场景,并不构成对语音质量或声音相似度的评估。有两个方法学细节值得记住。在每个层级使用得分最高的口译员,为质量设定了严格标准,却为延迟设定了不均衡的标准,因为比较对象是一个人,而不是职业口译员的中位数水平。而且该测试衡量的是信息传递和时序,而不是大多数听众在机器语音中首先注意到的东西,即它听起来是否像真人。

该仓库未回答的内容

买家最先会问的几个问题尚无公开答案。没有托管 API,也没有价格:与 Hy-MT2 系列不同——腾讯在腾讯云上以公开的按 token 计费费率列出该系列——Hy-SimulMT 仅提供权重外加一个移动应用,而 Hugging Face 的推理提供商面板将其列为未由任何提供商部署。没有技术报告,也没有腾讯自身评估之外的基准测试。模型卡指出,语音输出和声音克隆需要配置 TTS 服务,因此“语音到语音”的说法描述的是围绕该模型组装起来的系统,而不是一个能输出音频的检查点。llama.cpp 支持明确尚未合并到上游——尽管已发布 GGUF 构建,模型卡仍建议等待支持该模型的版本,并且示例环境变量引用了一个名为 hymt-A3b-tgt_only-1019-Q8_0.gguf 的检查点,该产物名称与公开模型 ID 不匹配。

语言元数据是最令人困惑的部分。仓库标注了 36 种语言,从中文和英语到法语、阿拉伯语、高棉语、藏语、哈萨克语和维吾尔语。正文仅记录了中文和英语之间的双向语音翻译。如果这些额外语言属于从 Hy-MT2 继承的文本主干,而不是语音路径,那么这两种说法都可能成立,但模型卡并未说明这一点;任何计划部署日语或阿拉伯语的人,在 Tencent 给出文档说明之前,都应将其视为未确认。

A six-row scoreboard for Hy-SimulMT-30B-A3B reading 'Total parameters: 30.4B', 'Active parameters: ~3B (config arithmetic)', 'Latency: approx. 3 s StreamLAAL', 'Speech languages: Chinese and English', 'Licence: Apache-2.0' and 'Hosted API: none published', with a footer reading 'All figures from Tencent's own model card; no independent evaluation.'

自行运行,以及这在硬件上的花费

有文档记载的路径是 vLLM 0.31 或更高版本并支持 HYV3ForCausalLM,再加上 simulst 软件包。一条命令即可配置环境,并分别在 8800 和 8080 端口启动模型服务器和 Web/API 前端;该前端接受音频上传、麦克风或 WebSocket 流,并在配置 TTS 后将翻译后的音频写入磁盘。还有一个 llama.cpp 桥接器,可在 8094 端口运行 Web 层,对接 8080 端口上现有的 llama.cpp 服务器,并通过 MODEL_TYPE 开关在仅翻译与源文本加翻译检查点之间切换。内存是实际门槛:304 亿参数在 BF16 下约为 61 GB 权重,尚未计入 KV cache 和激活,因此单张 80 GB 加速卡是现实下限,而 FP8 构建才让更小的卡变得可行。这些是我们根据参数数量得出的数字,而非腾讯的最低规格,因为该说明卡并未注明这一规格。

对于会议处理流水线不止于翻译的团队——还要总结转录文本、提取行动项、起草后续跟进——口译环节只是若干阶段之一,而后面的阶段无非是普通 API 调用,向当月恰好最合适的供应商发起即可。这正是 OrcaRouter 所覆盖的层面:一个 API 接入 200+ 个模型,供应商目录价原样透传,0% 加价,供应商出现故障时自动故障转移,并提供用于编排各阶段的路由 DSL。Hy-SimulMT 本身不在我们的目录中,我们也不托管它;关键在于,周边工作无需为每个供应商单独签约。

什么会改变这一评估?

有三件事值得关注,按它们能厘清问题的程度排序。一是独立评测——IWSLT 评测活动每年都会公布开放系统的 StreamLAAL 数值,而用这些权重提交的结果,将是首个并非由模型所有者给出的数字。二是带定价的托管端点,它能说明腾讯是把它当作基础设施,还是当作自家应用的一项功能。三是 llama.cpp 的合并,它决定 GGUF 构建版本是真正的本地选项,还是占位符。在那之前,诚实的总结是:腾讯发布了我们见过的最强大的开放同声语音翻译系统,厂商给出的数字很强,许可证宽松,但外界对这一切都没有确认——而发布时间恰在 APEC 合作公告前一天,这表明腾讯真正在意的确认,是深圳某位拿着手机的志愿者,而不是基准测试排行榜。

A screenshot of the GitHub repository Tencent-Hunyuan/Hy-SimulMT showing the English README header with the Tencent Hy and Hy-SimulMT marks, '4 stars', '0 forks', 'No description, website, or topics provided', a commit list that includes 'Clarify pending upstream llama.cpp support in deployment guide', 'No releases published' in the sidebar, and three contributors.