一张48GB的RTX 6000 Ada，跑腾讯混元的开源同传模型Hy-SimulMT，服务稳定后只占38GB。看上去32GB卡也能凑合。启动那一刻会告诉你不行。
vLLM在接请求之前，会把一段假音频推过音频编码器，看看还剩多少显存。这一步在每次运行里都把整张卡填满，之后占用才回落。按作者给出的16,384批处理token配置，它分析了数千条假音频，打印出成千上万条显存不足警告，然后才恢复。
把--max-num-batched-tokens降到4,096，峰值没有消失。再用--gpu-memory-utilization 0.66把服务压到32GB、缩短上下文、只留一个会话，翻译还能保持实时节奏，但启动仍然冲到47.4 GiB。这个上限管不住启动峰值，所以像RTX 5090这样的真32GB卡，可能在开始服务之前就失败。按48GB来选卡。
如果再挂上阿里千问团队的语音克隆模型Qwen3-TTS-0.6B，占用会从38GB变成48GB。
这次跑的是FP8 Interleave版本。FP8指权重以8位数字存储，文件缩到32GB；Interleave指输出里同时带上原话的文字记录。四段朗读片段按正常语速输入，首批词在2.3到5.5秒之间返回。
SimulInfer是作者提供的小服务，把进来的音频切成1.6秒的块，再把分段输出拼起来。把它指向FP8仓库，第一个报错是中文的：无法识别所选模型的输出格式。它只按仓库名认识完整版本，缺一个export_manifest.json。自定义后端补上这个文件，服务就能起来。
语音部分要单独锁版本。vLLM-Omni 0.32.0和0.32.0rc1都在导入Qwen3TTSSpeakerEncoder时报错停下，0.31.0rc1配vLLM 0.31.0可用，于是语音跑在自己的环境里，和跑在vLLM 0.32.0上的翻译服务并排。
语言对要先确认。模型页标了40种语言，但SimulInfer对zh-en和en-zh之外的任何方向都抛ValueError。
“延迟”这个词混了两个数。首词时间取决于模型判断自己听够了没有；块延迟指每个1.6秒块的音频结束后，这块的输出还要多久到达。四段片段的中位块延迟在0.4到0.8秒之间，90分位超过1.5秒，最差的一块用了2.9秒。每次到达都打时间戳，否则最终文本会把这些藏起来。
质量看方向。用chrF（0到100分，统计共有的字符序列）和人工参考译文比对：译成英文，两段中文片段得60.6和51.7；译成中文，两段英文片段得42.2和23.4。
23.4那段是警告。六句话里有两句丢了，第三句意思反了：“couldn't have included”译成了“could include”。SimulInfer给那次运行标了complete=false，客户端要检查这个字段。丢输出容易发现，被反转的否定读起来像正常中文。英译中先拿自己的录音测。
不是有人实时在听，就整文件发。一段50到56秒的片段整文件送进去，大约26秒返回完整译文。实时场景则要按真实语速，把PCM音频（未压缩的原始采样）切成小包，走SimulInfer的WebSocket。
作者用他们的StreamLAAL指标报告，长演讲下延迟约3秒。这个数字和本次测得的延迟只是粗略近似，不可直接比较。作者的基准测试以及与人译员的对比没有复现，样本是四段FLEURS朗读片段，一次一个会话。
热门跟贴