Hy-SimulMT 与 Hy-SimulMT-30B-A3B：同一个名称，六个文件，两种输出

把 Hy-SimulMT输入到 Hugging Face，你不会找到叫这个名字的仓库。你会发现六个，而且每一个都叫Hy-SimulMT-30B-A3B，并带有一个后缀。整个对比一句话就能说完。Hy-SimulMT 是腾讯混元在 2026 年 10 月 26 日公告中使用的名称——媒体报道称这款实时中英同传工具比说话人延迟约三秒。Hy-SimulMT-30B-A3B 则是你实际能下载到的产物上的名称。短名下没有更小的同系列模型，没有稠密变体，也没有藏在它后面的普通“base”模型。短名是一个项目；长名是一个由六个文件组成的家族。下面要讲的，是对比页面通常会埋没的决定：这六个里该运行哪一个，以及为什么对字幕叠加层和对只需要音频输出的会议流，答案会不同。

Tencent 发布了什么，以及它决定如何称呼它

腾讯自己的仓库将 Hy-SimulMT 视为项目名称：“一个由腾讯混元开发的实时同声传译模型。”模型卡将其归在同一个简短标签下。该合集的标题为“Hy Simultaneous Interpretation Model”。在这些材料中，没有任何地方定义了一个系列及其成员之间的层级关系——没有 Hy-SimulMT-Small，没有 Hy-SimulMT-Mini，也没有面向没有 80 GB 加速卡的人的稠密检查点。每一个已发布的权重都是相同的 30B 级混合专家架构。

因此，这个系列中的六个条目在任何实质意义上都不是六个不同的模型。它们是同一个模型的六种包装形式：

• Hy-SimulMT-30B-A3B — 仅翻译输出，全精度，safetensors。

• Hy-SimulMT-30B-A3B-Interleave — 源转写文本加译文，全精度，safetensors

• Hy-SimulMT-30B-A3B-FP8和Hy-SimulMT-30B-A3B-Interleave-FP8——同样是两种输出形态，采用面向单 GPU 推理的八位浮点构建版本。

• Hy-SimulMT-30B-A3B-GGUF和Hy-SimulMT-30B-A3B-Interleave-GGUF——同样是这两种输出形态，已针对 llama.cpp 量化，提供 Q4_K_M 和 Q8_0。

底层架构是一个 304 亿参数的稀疏模型，每个 token 大约有 30 亿参数处于激活状态：48 层，128 个专家，每个 token 路由 8 个专家并共享 1 个专家，还有一个 24 层音频编码器，以 30 秒窗口接收 16 kHz 音频。编码器的这种设计才是值得注意的部分。该模型被设计为在音频仍在到达时进行处理，而不是接收一个已完成的文件——这就是为什么延迟声明和基准测试声明衡量的是不同的事物，也是为什么它们都没有告诉你这六个文件中是哪一个产生了这个数字。

许可证为 Apache-2.0 且不设门槛，这是本次发布中最有力的单一事实。无需填写表单，没有可接受使用审核关卡，也没有非商业条款。商业使用、修改与再分发均被允许，而且腾讯在推理服务器之外还一同发布了训练工具包，因此持续训练是一项预期用途，而非不受支持的做法。

真正重要的选择是输出形状

在这两个全精度检查点之间，差别不在于质量，而在于模型被允许输出什么。基础检查点只输出译文，别的什么都不输出。Interleave 检查点则先输出识别出的源文本，再输出译文，并像音频流那样交错进行。

这听起来像是表面功夫，直到你看到这些系统被部署到哪里。驱动文本转语音的实时会议流需要基础检查点：转写内容是累赘，会消耗输出 token、给每个分块增加延迟，还会把源语言泄漏进一条唯一消费者是语音的流水线。字幕叠加层、合规记录、双语转写，或任何需要人工对照原话核对翻译的工作流，则需要 Interleave checkpoint，因为替代方案是在翻译器旁边另跑一个独立的语音识别器，并指望两者以相同方式切分音频。它们不会。

腾讯自家的一键部署示例默认采用 Interleave 变体：

• bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave

对于演示来说，这是一个合理的默认设置，因为显示源文本能证明系统正在倾听。但对于纯语音产品来说，这是一个错误的默认设置，而这正是大多数关于此次发布的报道所忽略的一个细节。如果你在评估模型的 token 成本或端到端延迟，那么根据你加载的检查点不同，你测量的其实是不同的系统。

Interleave 存在一种二阶成本，卡片暗示了这一点，却没有量化。流式转录文本是可变的。随着更多音频到达，早期输出可能会被修订，因此，显示部分文本的客户端必须被构建为接受更正，而不是仅追加行。AlphaSignal 对该版本的文章直接指出了这一点，而正是这类集成细节，会把两天的原型变成三周的项目。

基准测试没有说明它们测量的是哪个变体。

腾讯公布了四项短文本得分和一项长文本延迟数据，但每一行都被标注为“Hy-SimulMT”——而不是 Hy-SimulMT-30B-A3B，更绝非 base 与 Interleave 之分。这正是这份发布中坦诚的空白，而它比其中任何一个单独的数字都更重要。

• FLEURS—— 90.3。Gemini3.5-LiveTranslate 得分为 92.4，因此这并非类别胜出。

• CoVoST2——75.5，落后于 Qwen3.8-LiveTranslate 的 82.1。这是表中差距最明显的一项，也是头条报道往往略过不提的一项。

• ACL6060 — 81.2。Gemini3.5-LiveTranslate 得分为 82.6。

• RealSI-Sentence — 84.7，在对比集中最高。

• RealSI 长文本延迟 — 约三秒的 StreamLAAL，据称是所比较系统中最低的。

所有这些都由厂商运行。没有任何一项经过独立复现，而且模型卡明确说明，StreamLAAL 与首次语音输出时间不是同一种测量。演示视频是离线回放，因此其播放时序也不是实时延迟读数。请把这张表看作构建该模型的实验室提出的一组主张：它们是在该实验室自行选择的测试装置上得出的，且未说明所用的是哪个变体。

最后那一项遗漏，任何有相应硬件的人都能在一个下午内解决：用同一段音频分别运行两个检查点，并公布差值。在有人这样做之前，合理的假设是：已公布的数字描述的是仅翻译路径，因为这是更干净的测量——Interleave 变体必须输出更多 token，而在流式解码器中，更多 token 就意味着更高延迟。但这只是假设，并非披露。

格式是第三个决定，而 GGUF 这条路有个坑

全精度检查点在 BF16 下约为 61 GB。这使得舒适部署的实际下限落在 80 GB 加速器上；如果你打算按模型发布时的原样来提供服务，这就是需要预留的预算数字。FP8 版本的存在正是为了把这一要求降到单张更小的卡上，Tencent 也正是这样定位它的。

GGUF 路线看起来成本仍然更低，而且文件大小也很明确。Interleave GGUF 仓库显示，Q4_K_M 为 19.7 GB，Q8_0 为 33.3 GB。对 300 亿参数模型进行 19.7 GB 量化，正是“需要数据中心级显卡”和“能装进工作站”之间的差别，而且这会是大多数人最先尝试的版本。

问题在于，llama.cpp 对该架构的支持尚未合并到上游仓库。腾讯提供了一个桥接层，它要求已经运行着具备音频能力的 llama.cpp 服务器，并带有 MODEL_TYPE 开关——target_only 用于仅翻译检查点，source_target 用于交错式检查点——文档建议等待官方发布。如今运行量化构建，意味着要在一个尚不了解此模型是什么的 llama.cpp 构建之上运行厂商桥接层。作为评估，这是合理的做法。对于产品而言，这是脆弱的基础，而失败模式是一个你无法脱离厂商补丁独立升级的依赖。

对于 vLLM 路径，要求版本为 0.31 或更新，并支持 HYV3ForCausalLM，此外还需要 simulst 包。多 GPU 部署可通过张量并行实现。一键安装程序会在 8080 端口启动 Web 和 API 服务，在 8800 端口启动模型服务器，并且它运行在隔离环境中——这意味着如果你将其指向现有技术栈，它可能会重新安装 SimulInfer 或更改依赖版本。正因如此，腾讯提供了分步操作指南。

要提供服务需要具备什么，以及该版本不包含哪些内容

语音输出和声音克隆并不是检查点的属性。模型生成的是文本。要把这些文本转换成以说话人声音呈现的语音，需要单独配置的 TTS 服务，而这句话的每一部分都伴随着成本：多一个要运行的服务、延迟预算中多一次网络跳转、多一份需要审阅的供应商条款，以及从麦克风到听者之间多一个故障点。模型卡对此说得很直接，而这也是演示与可部署的口译器之间最大的单项差距。

同样没有托管 API，也没有公布价格。腾讯面向消费者的入口是 Hy Translate 应用，它在 Android 和 iOS 上提供免费套餐——这是听听该模型效果的最便宜方式，但作为生产依赖毫无用处。其余所有部分都需要你自行托管，这意味着成本在于加速器、运维时间和 TTS 账单，而不是可以填进电子表格的按 token 计费单价。

语言覆盖范围也值得同样严格的审视。说明文字记录的是中英双向。Hugging Face 元数据标签将该检查点标为 36 种语言。并未公布其余 34 种语言的列表，而且仓库自带的示例全都是 en-zh 或 zh-en。在腾讯另行说明之前，应将该标签视为继承而来的元数据，不要仅凭一个标签就规划 36 种语言的上线。

需要第二来源的说法

与人类口译员的比较是该发布内容中被引用最多、却最缺乏依据的一项说法。腾讯报告称，其质量“与资深人类同声传译员相当，且往往响应更快”，依据是18段新收集的录音，每段约六分钟，取自十个领域，并由六名经验丰富的口译员评估——其中三名持有CATTI一级证书，三名持有CATTI二级证书。每个等级均采用三名口译员中的最高分。

最后这个细节很关键。用三次运行中的最佳结果对比单次模型运行，是一种偏宽松的构造，而且模型卡没有公布置信区间或分领域细分。它也没有公布声音克隆的客观说话人相似度分数，而这一功能最可能决定部署在在场人员看来是否可接受。模型卡自身列出的局限性——该发现受其样本、参与者和设置限制，并非全面评估——才是正确解读。医疗、法律和嘈杂对话音频正是口译员比较需要分领域数字的地方，而这些数字恰恰缺失。

专业口译员仍然是正确选择，只要涉及问责、专家审阅或高风险决策。这是 Tencent 的表述，而不是批评者的表述；这一点值得重复，因为本次发布的标题版本并没有这样做。

如果你自托管它，就在它后面放点东西

这两个检查点都不在 OrcaRouter 的目录中，因此我们并不是通往其中任何一个的路由，本文也不会假装不是这样。但这并不意味着路由器与自托管口译器无关——它只是把路由器推到了边缘。实时翻译路径是一条长链：音频采集、模型服务器、可选的 TTS 服务以及客户端。每一环都可能卡住，而在会议中卡住，比翻译稍差一点更糟。把托管文本模型放在同一端点后面，作为转录路径（而非音频路径）的备用方案，意味着即使模型服务器宕机，也会降级为可读的转录文本，而不是一片寂静。

OrcaRouter 是一个位于 200 多个托管模型之前的 API，加价 0%，按提供商目录价原样传递、不额外加收任何费用，并且路由 DSL 就是表达回退规则的方式，无需再做第二次集成。自动故障转移才是这里的关键：规则会在上游故障时触发，而不是等人发现字幕停了才反应过来。

那么，是哪个文件呢

一旦你明白这些名称指的是什么，这种“对决”式的框架就会消解，剩下的只是一个有三种诚实答案的包装决策。

如果你正在构建语音产品——会议口译、呼叫中心浮层，或任何输出为音频的场景——请采用Hy-SimulMT-30B-A3B；如果受限于单张 80 GB 显卡，则采用其 FP8 构建版本。你不需要转写文本，也不想花钱生成它，而基础检查点是延迟更优的路径。

如果人类会阅读输出，请采用Hy-SimulMT-30B-A3B-Interleave。字幕、双语会议纪要、合规采集与审核工作流都需要源文本，而另跑一个识别器与翻译器并行，最终就会得到两份对句子结束位置各执一词的转写文本。

如果你是在评估而不是部署，请选择Hy-SimulMT-30B-A3B-Interleave-GGUF 的 Q4_K_M 版本，接受 19.7 GB 的文件和未合并的 llama.cpp 依赖，并把它当作在已有硬件上听听该模型表现的一种方式。只有当你认定其质量值得这张显卡时，才升级到 FP8 vLLM 路径。

真正悬而未决的问题，并不是哪个文件更好，而是已公布的分数描述的是不是你选中的那个文件。腾讯有足够的算力在一天之内回答这个问题；在它给出答案之前，任何引用 90.3 或 84.7 的人，都应当说明自己认为这个分数出自六个检查点中的哪一个。