10 月 26 日,腾讯混元把 Hy-SimulMT 挂上了 GitHub、Hugging Face 和 ModelScope:一个中英双向、语音进语音出的实时同传模型,许可 Apache-2.0,同时在自家 Hy 翻译 App 里免费开放体验。消息传开之后,关于它的说法分成了四种——官方说"StreamLAAL 约 3 秒",媒体说"压过人类译员",自媒体说"380 毫秒、iPhone 本地就能跑",开发者说"我这卡装不下"。
这四句话里有两句是错的。这篇不谈概念,只做四件事:把四个数字逐个对账,拆开 3 秒是怎么抠出来的,看跑分表里哪一项是真短板,再把显卡账单和三条上手路线算给你。
一、它到底是个什么东西:一条端到端的语音流水线
- 不绕文字。传统同传是"语音识别→机器翻译→语音合成"三段串起来,每一段都要等上一段出结果。Hy-SimulMT 是端到端:说话人的音频持续灌进去,模型边听边译,同步吐出译文文字和语音。省掉的不只是两个接口,是两次排队等待。
- 只有中英,只有语音。中文和英文互译,输入输出都是音频加文本。想要 33 个语种、方言、术语干预那种文本翻译,是同门的 Hy-MT2,不是这个模型。混着用会失望。
- 音色克隆要自己接 TTS。仓库给的是"听+译+说"的主体,译文语音和音色克隆依赖另外部署的 TTS 服务,文档里点名用的是 Qwen3-TTS-0.6B。换句话说,开箱只有文字,想听声音还得再加一个模型、再占一份显存。
- 两套权重 × 三种精度。target-only 只出译文;Interleave 原文和译文一起出,适合做双语字幕。每套再分 BF16、FP8、GGUF,一共六个仓库。这个设计很实在——会议字幕要 Interleave,纯播报用 target-only 更省。
- 规格从 config.json 里读。48 层 Transformer,hidden size 2048,128 个专家、每个 token 选 8 个外加 1 个共享专家,词表 120,832,位置编码上限 262,144,音频侧是 24 层编码器、16 kHz 采样、单个音频窗最长 30 秒。名字里的 30B-A3B 就是"30B 总参数、每 token 约 3B 激活"的 MoE——参数总量不小,算力开销按 3B 算,这是它能做实时推理的底子。
- 配套比模型更值钱。SimulInfer 是推理服务(网页、文件上传、WebSocket 三种入口都给了),SimulTrain 是继续训练工具,另外还有给 llama.cpp 和 SGLang-Omni 的适配。国内开源的同传项目里,愿意把训练、推理、评测口径一起交出来的并不多,这三件配套比榜单上的分数更值得看。
二、传闻与实锤:四个数字先分清
第一,“3 秒"是 StreamLAAL,不是首字延迟。 官方在图注里写得清楚:StreamLAAL 衡量流式翻译的滞后程度,单位是秒,不等同于首次开口延迟。它更像"平均落后说话人多少秒”,而不是"按下麦克风到听见第一个字"。这两个数经常被混用,差了不止一倍。
第二,“超过大部分商用 API"有精确边界。 官方原话是:在 RealSI 长音频集上,GEMBA 分数"高于所对比的开源模型,并超过五个商业 API 中的四个”。是四个,不是全部;是一个数据集,不是全场景。有媒体从图上读出约 86 分、延迟 3.1 秒,和官方口径对得上,但记住这是单集成绩。
第三,“压过人类译员"是小样本能力定位,不是认证。 对照实验是 18 段、每段约 6 分钟的新音频,覆盖演讲、访谈、会议,横跨软件 AI、医学、制造能源、农业食品、法律、教育等十个领域;六位译员里三位持 CATTI 一级、三位持 CATTI 二级,每个等级取三人中的最高分。官方结论只有一句"翻译质量达到人类同传专家水平,速度更快”。具体的 3.3 秒对 4.5 秒、4.7 秒,是媒体按对照图读出来的数字。18 段样本能说明方向,说明不了"AI 可以替代译员"。
第四,“380 毫秒、iPhone 本地跑、3 秒声纹克隆"在官方文档里都不存在。 StreamLAAL 以秒计,不可能出现 380 毫秒;推理要求 Linux、Python 3.12、NVIDIA GPU 和 vLLM ≥0.31(SGLang 路线更是点名单卡 H200);手机端能离线跑的,是 Hy-MT2 那个 440MB 的 1.8B 文本压缩版,和这个 30B 同传模型没关系。看到这三个数字凑在一篇里的文章,可以直接划走——那是把三个不同的产品缝在了一起。
三、延迟:3 秒是怎么抠出来的
- 分块是硬的,第一块 1600 毫秒。标准模式每 1600 ms 切一块音频;短分块模式能把后续块压到 800 ms,但第一块必须是 1600 ms。也就是说,再快也只能从第二句开始快,开口那一刻注定要等一块。
- 先开口、后修补。这是官方给的核心策略:按已经听到的半句先给译文,听到后半句再回头改。SGLang 那条路径的文档写得很直白——每个 partial 请求都会把此前的音频和译文带进上下文,最终假设会对整段重新翻译,可能修订此前的部分译文。听感上接近译员的自我修正,但听众确实会听到改口。
- 每 1.6 秒刷一次,30 秒切一段。实时 WebSocket 默认每 1.6 秒推一次译文假设;运行时在 30 秒处强制切段,切完之后翻译上下文重新开始。短句没问题,长句的跨段指代——“他刚才说的那个方案”——大概率会翻丢。
- 和人的差距是"少等一两秒”,不是"快一倍"。人类同传的滞后普遍在 4 到 5 秒,这个模型在 3 秒上下。真正决定体验的不是这个差值,而是断句准不准、改口频不频繁。会议里一句话被改三遍,听众的注意力就散了。
四、质量:三个第一,一个明显短板
官方在四个公开短音频集上做了横向对比,挑几个有代表性的摆在一起(分数越高越好):
| 系统 | FLEURS | CoVoST2 | ACL6060 | RealSI-Sentence |
|---|---|---|---|---|
| Hy-SimulMT | 90.3 | 75.5 | 81.2 | 84.7 |
| Qwen3.8-LiveTranslate | 88.4 | 82.1 | 80.5 | 84.4 |
| Gemini3.5-LiveTranslate | 92.4 | 74.4 | 82.6 | 82.2 |
| Confucius4 R2T2 → T3PO | 89.4 | 76.8 | 76.1 | 77.7 |
| Seed-LiveInterpret2.0 | 85.8 | 67.7 | 74.8 | 80.0 |
| GPT-Realtime-Translate | 77.7 | 50.8 | 76.4 | 76.7 |
| 讯飞同传 | 73.4 | 57.0 | 57.5 | 70.9 |
- 三个第一:FLEURS 90.3、ACL6060 之外的 RealSI-Sentence 84.7 都是表内最高;ACL6060 的 81.2 排第二,只输 Gemini 3.5 LiveTranslate 的 82.6 一个多点。
- 一个真短板:CoVoST2 只有 75.5,比 Qwen3.8-LiveTranslate 的 82.1 低 6.6 分,连 Confucius4 的 76.8 都没追上。这个集子偏朗读式、口音杂,说明在"非标准发音"上它还不稳——真拿去听印度口音或苏格兰口音的英文演讲,别指望表里那个 90 分。
- 别把 GEMBA 当人工评分。GEMBA 是 GPT-6.1-Sol 打分,大模型当裁判,对改口、口语重复、语气词的容忍度是未知的。分数可以横比(同一裁判、同一批样本),但不能当成"翻译质量等于人类"的证据。
- 音色克隆没有客观分。官方只给了演示视频:英译中那段有三位说话人,模型能分别保留各自音色,让听众分得清"谁在说话"。好听不好听、像不像,官方自己也没打分,只注明"不代表对播报音质、音色相似度等维度的综合评价"。
五、显卡与账单:三种精度,三档卡,三笔钱
权重体积是从 ModelScope 的文件列表里加出来的,不是估的:BF16 十七个分片加音频塔,合计 60.8 GB(约 57 GiB),和官方"BF16 权重约 57 GiB"一致;按半精度折算,FP8 版在 30 GB 上下;GGUF 两个文件,Q8_0 33.31 GB、Q4_K_M 19.75 GB。
| 精度 | 权重体积 | 能装的卡 | RunPod 公开时价 | 两小时会议成本 |
|---|---|---|---|---|
| BF16 | 60.8 GB | H200 141GB / A100 80GB | $5.29 / $1.79 每小时 | 约 76 元 / 约 26 元 |
| FP8 | 约 30 GB | L40S 48GB / RTX 6000 Ada 48GB | $1.09 / $0.99 每小时 | 约 16 元 / 约 14 元 |
| GGUF Q4_K_M | 19.75 GB | 24GB 消费卡理论可装 | 暂无可用路径 | 现在跑不了 |
- H200 是官方给的省心选项,SGLang 文档写明 BF16 权重占 57 GiB,单张 H200 就能起;要跑 vLLM 那条主路径,80GB 的 A100 也够。
- FP8 是性价比拐点。30 GB 权重落到 48GB 卡上,还剩十几个 GB 给 KV cache 和音频编码器,官方配置里的
--max-num-seqs 4、--gpu-memory-utilization 0.9就是按这个思路给的起点。两小时会议十六块钱,是这套方案最有说服力的地方——当然,这是独占一张卡的价格,并发压不满就不划算。 - 24GB 卡现在别买。Q4_K_M 只有 19.75 GB,看着像能塞进 4090,但 Hy-SimulMT 的 llama.cpp 适配还挂在 PR #31198,没合并进官方仓库,现在只有
llama-mtmd-cli能跑,llama-server要等后续适配。没有服务端,就没有 WebSocket,也就没有实时同传。 - 隐性成本别漏。60.8 GB 权重要下载、要占盘;冷启动加载要几分钟;会议前必须预热,否则第一句话就在等模型。共享实例按小时计费,会开完了记得停。
六、怎么用起来:三条路,按你手里的机器选
| 路线 | 适合谁 | 一条命令 | 坑 |
|---|---|---|---|
| vLLM + SimulInfer | 有 NVIDIA 卡、要完整网页/WS | bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave | 自动建环境,重跑会重装依赖 |
| 已有 vLLM 环境 | 不想被动升级 CUDA | pip install --no-deps simulst 后 deploy.sh --server-python ... | 需 vLLM ≥0.31、支持 HYV3ForCausalLM |
| SGLang-Omni | 单卡 H200、要 OpenAI 兼容接口 | sgl-omni serve --model-path tencent/Hy-SimulMT-30B-A3B --enable-realtime | 单请求 30 秒上限,超长直接拒 |
- 一键部署之后:模型服务在 8800,网页和 API 在 8080。上传一个文件试水:
curl -N http://127.0.0.1:8080/translate/stream -F direction=zh-en -F file=@audio.wav。 - 接进自己的系统:连
ws://host:8080/translate/ws,先发{"direction":"zh-en","input_format":"s16le","input_sample_rate":48000,"input_channels":1},收到ready后灌 PCM,结束发{"eof":true}。这段握手是硬约定,格式不对会直接静音。 - 现场嘈杂:用抗噪模式,
simulinfer --init-config noise.toml --profile noise_resistant,对应配置项audio_mode = "noise_resistant"。展厅、咖啡馆这种环境,标准模式的误识率会明显上去。 - SGLang 那条:
/v1/audio/translations接中文语音出英文,/v1/audio/transcriptions接英文语音出中文,注意language指的是源语言,这个 checkpoint 没有语种识别 token,漏了就默认中译英。 - 不想碰服务器:Hy 翻译 App 里已经能试,官方口径是"免费提供服务体验"。App 里没公开条款和额度,重度用之前先看清楚。
七、限制与风险:五条必须先知道
- 中英混说会翻车。模型只支持中英,又没有语种识别 token,一条音频里中英夹杂、或者开头是英文名字后面接中文,得靠调用方自己判源语言。
- 30 秒分段是硬切。SGLang 路径单请求上限 30 秒,超长拒绝而不是截断;SimulInfer 有 VAD 和恢复策略,但跨段的上下文一样会重来。长会议要么自己切,要么接受指代丢失。
- 音色克隆先解决授权。克隆别人的声音要拿到同意,这是常识也是法律;国内对 AI 生成合成内容有标识要求,拿它做课程二次分发、会议录音转发,谁听到、要不要标注,提前想清楚。
- 高风险场景官方自己划了线。README 里那句"需要严格责任判断、专业审校或高风险决策的场景,专业译员的参与仍然重要"不是客套——医疗、法律、合同谈判,机器只能当辅助,别让它背责任。
- 许可要看两层。主许可是 Apache-2.0,但仓库里另有第三方组件按各自条款,商用前把 LICENSE 文件读完;GitHub 仓库页标的是 NOASSERTION,只看徽章会误判。
八、我的判断:谁该上、谁再等等、谁别碰
该上。
- 做出海会议、直播、在线教育的团队:SaaS 里嵌一路同传,3 秒滞后对"听懂"够用,私有化部署能把按分钟计费的 API 账单换成按小时的 GPU 账单。
- 手上有 48GB 卡的实验室或中小企业:FP8 版 30 GB,一张 L40S 起一路,两小时十六块,试错成本极低。
- 研究流式语音翻译的开发者:训练代码、推理服务、评测脚本、对照数据口径全开源,这在同传这个方向上很少见,拿来做 baseline 比自己搭省几个月。
再等等。
- 只有 24GB 消费卡的个人玩家:等 llama.cpp 的 PR 合并,现在装了也只有命令行,没有服务端。
- 需要日韩、东南亚语种的:这个模型不做,回头用 Hy-MT2 的文本模型,别硬上。
- 想在手机上离线同传的:目前没有端侧版本,App 里的同传同样走云端,离线跑的是另一个 1.8B 文本模型。
别碰。
- 想用它替代译员去签合同、上法庭、进手术室的。3 秒的滞后加随时改口,在责任场景里是负债,不是效率。
- 想批量克隆客户或主播声音做内容的。授权和标识两关,过不去。
一句话判断:Hy-SimulMT 的价值不在"超过人类"这四个字,而在它把中英双向、语音到语音、3 秒级滞后做成了一套能自己部署的完整工程——模型、推理服务、训练工具、三档精度全给齐。它也不是"人人都能跑"的模型,而是一台需要 GPU 的基础设施。对普通读者,短期内最实际的动作是去 App 里试十分钟,重点听它改口的频率你能不能接受;对开发者,先去把 FP8 那版拉下来,拿一段自己的会议录音跑一遍,再决定要不要为它买卡。
本文由拾光札记编辑部整理,勘误请联系我们。