一、3 秒开口的同传模型，权重真的放出来了
10 月 26 日，腾讯混元在 GitHub 发布实时同声传译模型 Hy-SimulMT 并同步开放权重，官方 README 新闻栏的表述是「发布：Hy-SimulMT 发布，支持中英双向实时同声传译与实时音色克隆」；混元官网详情页同样把发布日期钉在 2026 年 10 月 26 日，定位写着「低延迟、高质量的实时同声传译模型」。仓库在这里：Hy-SimulMT。仓库地址：github.com/Tencent-Hunyuan/Hy-SimulMT。
先把热度数据交代清楚。按 2026 年 10 月 28 日的 GitHub API 快照，仓库创建于 10 月 22 日、最近一次推送在 10 月 27 日，149 stars、14 forks、2 个开放 issue——对一个上线不到一周的开源项目，这只是起步量级，社区集成与第三方实测都还在路上。权重同步放在三处：Hugging Face 的 tencent/hy-simulmt collection、ModelScope 同名 collection、GitHub 仓库本身；Hugging Face 侧模型卡的任务标签是 translation，截至采集日 downloads 131、likes 38。不想碰代码的用户也有入口：官方 Hy 翻译 App 免费体验，README 提供 Android 与 iOS 下载二维码。
分工声明先行。站内此前写过一张 4090 跑世界模型的 Hy-Nomas 深评——同属腾讯混元开源，但那是交互式世界生成模型，与翻译毫无关系；全双工语音六款横评管的是「实时对话」场景下的语音模型比选，而本篇管的是「翻译」场景：你讲中文、对方听英文，边听边译的那种。三个选题三条赛道，互不重复。
二、许可证：一句话讲清三层口径
许可证是开源项目最容易扯皮的地方，Hy-SimulMT 恰好提供了一个教科书案例——它的许可状态在三个地方长得不一样。
第一层，也是唯一起决定作用的一层：LICENSE-Hy-SimulMT.txt 原文写明「Hy-SimulMT is licensed under Apache-2.0, except for the third-party components listed below」，并附了一句关键保证——不施加超出各原许可的任何附加限制（原文为 does not impose any additional restrictions）。第三方组件清单只列一项：Qwen3-ASR-0.6B，本身同为 Apache-2.0。版权行为 Copyright (C) 2026 Tencent，Apache-2.0 的覆盖范围被明确限定于官方公开的推理代码、参数与权重。
第二层：GitHub 仓库页面的许可证栏显示 NOASSERTION。原因很朴素——腾讯用的是自定义文件名 LICENSE-Hy-SimulMT.txt，GitHub 的自动识别器认不出这份文本，于是标了「未识别」。这是展示层的识别问题，不是法律状态的变化。第三层：Hugging Face 模型卡标注 license:apache-2.0，与原文一致。
一句话总结：Apache-2.0，附第三方组件例外清单（仅 Qwen3-ASR-0.6B 一项），无附加商用限制；GitHub 的 NOASSERTION 系许可证文件命名导致的识别偏差。想商用，读原文即可，不必被仓库页面那个灰色字样吓退。
三、架构口径：名字里有什么，没什么
模型名叫 Hy-SimulMT-30B-A3B。按 MoE 命名惯例，30B 指总参数规模、A3B 指每 token 激活约 3B 参数——但这里要立一条纪律：官方 README 正文与官网详情页自始至终没有写过「总参数约 300 亿、激活约 30 亿」这句话，激活规模只隐含在模型名里。本篇采信的可核数字是 Hugging Face 权重口径：总参数约 30.39B，BF16 精度、17 个 safetensors 分片外加一个音频塔文件，存储约 60.85 GB；MoE 结构为 128 个专家、每 token 激活 8 个专家，架构类 HYV3SpeechForCausalLM。超出这个范围的参数表述，不替官方造句。
权重一共放了六个变体，按输出内容分两支：
| 变体 | 输出内容 | 格式 |
|---|---|---|
| Hy-SimulMT-30B-A3B | 仅译文 | BF16 |
| Hy-SimulMT-30B-A3B-FP8 | 仅译文 | FP8 |
| Hy-SimulMT-30B-A3B-GGUF | 仅译文 | GGUF |
| Hy-SimulMT-30B-A3B-Interleave | 原文转写加译文 | BF16 |
| Hy-SimulMT-30B-A3B-Interleave-FP8 | 原文转写加译文 | FP8 |
| Hy-SimulMT-30B-A3B-Interleave-GGUF | 原文转写加译文 | GGUF |
Interleave 变体的价值在于同时吐出源语言转写，做双语字幕、做对照校对的场景用得上。另有一处细节值得留意：Hugging Face 模型卡挂了 36 个语言标签（zh、en、fr、pt、es、ja、ko、ru、ar 等），但 README 正文只承诺中英双向同传——标签覆盖面大于正文承诺，实际能力以正文为准，想拿它做小语种同传，先想清楚这一点再立项。
四、关键纠偏：它不是端到端语音同传
这是本篇最想点破的一条，因为相当一部分媒体报道已经把它写偏了。
Hy-SimulMT 被广泛描述成「端到端语音到语音同传」，但官方 README 对底座 checkpoint 的能力边界写得明明白白：只输出译文文本，语音输出与音色克隆需要另接一个 TTS 服务。也就是说，你听到的「3 秒开口的译文语音」，实际链路是 Hy-SimulMT 先出译文文字，再由 TTS 合成并播报——官方部署方案里这个位置接的是 Qwen3-TTS，SimulInfer 子文档给出的是 Qwen3-TTS-12Hz-0.6B-Base，经 vLLM-Omni 部署；配置 tts_clone_source 为 true 后，系统自动克隆上传音频或麦克风里的音色，不必另传参考音频。
推论也很直接：README 里那个约 3 秒的延迟数字，度量的是翻译环节，不含 TTS 合成与播报的耗时。真要搭一套「说话人开口、听众听到译文语音」的完整系统，端到端体感延迟要在 3 秒上再加 TTS 那一截。这不是贬低模型——文本同传本来就是整条链路里难度最高的一段——而是选型时要把账算全。官方演示里英译中输入含三位说话人，输出分别呈现三种不同音色，让听众能区分谁在说话，这个效果就是「同传模型加 TTS 音色克隆」组合完成的。
五、成绩单：3 秒、85 到 86 分，和一次小样本人类对照
性能数字全部出自官方口径，逐条限定来源。
延迟侧：RealSI 长音频测试中 StreamLAAL 约为 3 秒，是官方对比图示中参评系统的最低值。两个限定词必须带上：其一，README 自己注明 StreamLAAL 不等同于首次开口延迟，它是学术圈衡量同传质量与延迟权衡的指标，不是「等几秒能听到译文」的体感值；其二，正文只写「约为 3 秒」，更细分的 3.1 秒、3.3 秒出自配图而非正文，本篇不引作正文数字。
质量侧：RealSI 长音频的 GEMBA 得分，按官方对比图示口径约为 85 到 86 分，打分模型为 GPT6.1-Sol——注意这个精确分值与打分模型名均出自配图，README 正文只给了结论性表述：GEMBA 高于所对比的开源模型，并超过五个商业 API 中的四个。短音频四套测试集的对比表更实一些，九个系统同表比拼、分数越高越好，Hy-SimulMT 的成绩是 FLEURS 90.3、CoVoST2 75.5、ACL6060 81.2、RealSI-Sentence 84.7；官方结论是其中三项高于表内其他开源模型，RealSI-Sentence 84.7 更是全表最高。也要如实说短板：CoVoST2 一项不是第一，榜首是 Qwen3.8-LiveTranslate 的 82.1。
人类对照是这批宣传里最抓眼球的部分，限定词也最多：测试用了 2026 年 9 月以后新出现于互联网的 18 段中英文音频、每段约 6 分钟，覆盖演讲、访谈、会议等场景与软件与人工智能、医学、制造与能源、自然科学、农业与食品、商务管理、法律、教育、文化文旅、体育生活十个领域；对照的六位译员全部持证，三位 CATTI 一级、三位 CATTI 二级，每个等级取三人中的最高分。官方结论的原话是「在这次小范围的能力定位测评中，Hy-SimulMT 在翻译的质量达到人类同传专家水平，不过速度往往更快（时延更低）」；配图给出的专家延迟为一级 4.5 秒、二级 4.7 秒，同样是图示口径。官网详情页的免责表述比 GitHub 版更严格，值得整句引述：以上结论仅适用于本次样本、参测译员及评测设置，不能据此推断模型在所有场景中全面超越专业译员，也不代表对播报音质、音色相似度等维度的综合评价。18 段录音、6 位译员，这是小样本评估——读到「超越人类同传」的转述时，记得这四个字。
竞品行情一句带过：字节 Seed-LiveInterpret 2.0 是商用 API、未开源，在腾讯这张对比表里 GEMBA 约 77；Qwen3.8-LiveTranslate 未见开源权重；Gemini3.5-LiveTranslate 拿下 FLEURS 单项第一（92.4）。需要提醒的是，这张表是腾讯侧自报，竞品方各自公布的指标体系不同、不可互相换算，横向结论只在这张表内成立。
六、先开口、后修补：策略与专家背书
同传的教科书难题是等不等：等久了延迟爆炸，不等就翻错。Hy-SimulMT 的路线是「先开口、后修补」——先给出当前把握下的译文，听到更多信息后再修正。广东外语外贸大学高级翻译学院副院长王巍巍的评语原话是：为控制延迟，系统先开口、后修补，修补的听感接近译员的自我修正；她同时判断，AI 同传正从辅助理解走向低风险场景的可用沟通。
第二位背书来自广东外语外贸大学原校长、中国翻译协会原常务副会长仲伟合教授：在语音识别稳定性、同传响应速度与译语播报质量上均展现出不俗的实力。官方在同一页收了尾：对于需要严格责任判断、专业审校或高风险决策的场景，专业译员的参与仍然重要。两位翻译教育界人士背书、再加一句自我设限，这套组合的潜台词很清楚——商务会谈、课堂、文旅讲解这类容错率较高的场景是主战场；法庭、医疗这类高风险同传，还轮不到模型独立顶上。
七、部署三件套：SimulInfer、SimulTrain 与一条 App 捷径
官方给的部署路径分三层，按动手意愿选。
第一层是 SimulInfer 推理服务栈，面向想把同传跑起来的开发者：底层要求 vLLM 不低于 0.31（需支持 HYV3ForCausalLM 架构），提供网页界面、音频文件上传、实时 WebSocket 接口与可选的 TTS 音色克隆；服务本体重不高，Python 3.11 以上即可，可单独部署在 CPU 机器上。一键部署命令如下：
# 一键部署（默认网页与 API 端口 8080，本机模型端口 8800）
bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave分块策略有两档：标准模式每块 1600 毫秒（默认推荐）；短分块模式首块必须 1600 毫秒、后续 800 毫秒，延迟换灵敏度。另有标准模式与抗噪模式可切换，远程麦克风需要 HTTPS。
第二层是运行时。官方 README 收录了 SGLang-Omni 的运行时支持，写明 BF16 权重约占用 57 GiB（不含 KV cache 与运行时开销），单张 H200 即可部署；H200、batch size 1 实测相比 Transformers 最高 6.5 倍加速。限制也写清楚了：只支持 BF16 仅译文 checkpoint，同样只返回文本。另有一条容易踩的坑：单请求音频上限 30 秒，超长音频会被直接拒绝而不是自动截断，另有一条路径在 30 秒后重建翻译上下文——长录音要自己动手切。
GGUF 路线的现状要单独交代。官方已向 llama.cpp 提交架构适配 PR #31198，截至 2026 年 10 月 28 日复查该 PR 仍未合并；当前可用 llama-mtmd-cli 跑 GGUF（示例权重为 Q8_0 量化档），llama-server 支持待后续适配，官方子文档的建议是等支持该模型的新版 llama.cpp 发布后再用。GGUF 量化后到底什么显卡能跑，官方 README、SimulInfer 文档与官网页均未公布最低配置，社区也没有公开验证——写成「一张 4090 就能跑」目前没有任何官方依据，这个口子不能替官方开。
第三层是 SimulTrain 训练工具：基于下载的 checkpoint 做领域继续训练，模型路径、数据、GPU 与输出目录都在 SimulTrain/.env 里配置，适合有自己领域语料、想定制术语与风格的团队；训练硬件细节在子目录文档里，主 README 未展开。
常见问题
Q1： 可以商用吗？
A1：可以。LICENSE 原文写明 Hy-SimulMT 以 Apache-2.0 授权，附第三方组件例外清单（仅 Qwen3-ASR-0.6B 一项，本身同为 Apache-2.0），且不施加附加限制。GitHub 页面显示 NOASSERTION 只是因为许可证文件用了自定义文件名导致识别失败，Hugging Face 模型卡标的就是 apache-2.0，以 LICENSE 原文为准。
Q2： 一张 4090 能跑吗？
A2：官方没说过，别信转述。官方明确给出的硬件锚点只有 SGLang-Omni 路径的 BF16 权重约 57 GiB、单张 H200 可部署；GGUF 量化后的最低显存配置官方未公布，社区亦无公开验证。等 llama.cpp 的 PR #31198 合并后再看消费级实测更稳妥。
Q3： 约 3 秒的延迟，是听众听到译文语音前的等待时间吗？
A3：不是。约 3 秒是 RealSI 长音频测试的 StreamLAAL 指标，官方自己注明它不等同于首次开口延迟；而且底座模型只输出译文文本，语音要另接 TTS（官方方案为 Qwen3-TTS）。完整语音链路的体感延迟，要在 3 秒上叠加合成与播报的耗时。
Q4： 支持哪些语言？
A4：以官方正文承诺为准：中英双向实时同声传译。Hugging Face 模型卡虽有 36 个语言标签，但那不是同传能力承诺，实际能力以 README 正文为准；做小语种之前，不要拿语言标签当立项依据。
Q5： 它真的超过人类同传译员了吗？
A5：官方口径比部分媒体转述克制得多：18 段约 6 分钟录音、6 位 CATTI 持证译员的小范围测评，官网免责声明写明结论仅适用于本次样本与评测设置，不能推断模型在所有场景全面超越专业译员。高风险场景仍然需要人。
延伸阅读
- 全双工语音六款横评：权重跑不起，能跑的太老：实时对话场景的开源语音模型比选，与同传是两条赛道
- 一张4090跑世界模型：腾讯混元Hy-Nomas开源深评：同为腾讯混元开源，做的是交互式世界生成
- 开源语音模型五连发：蚂蚁 MIT 协议四卡起步：蚂蚁五款语音模型的全栈接入实操