AREX Feed Article
vLLM-Omni 宣布支持 Fish Audio Drama 3：单张 H200 报告 128 路并发流、中位首音频延迟 255 毫秒
北京时间 10 月 15 日 16 时 39 分，vLLM 项目官方 X 账号 发帖宣布，vLLM-Omni 现已支持 Fish Audio 的 Drama 3 语音生成模型：通过 OpenAI 兼容的 /v1/audio/speech 端点提供音色克隆、说话人标签与富有表现力的语音输出，并以 44.1 kHz 流式音频返回。模型总参数 35B，每个 token 激活 3B。
帖文引用的性能数字出自一笔已合并的优化 PR：单张 H200 承载 128 路并发流，中位首音频延迟（time to first audio，从发出请求到收到第一段音频的时间）255 毫秒，每秒生成 222.2 秒音频，两阶段共享同一块 GPU。帖文没有附第三方验证，不过这一支持当前已经可以上手：按 vLLM-Omni 仓库的，在当前上游执行 vllm serve fishaudio/drama-3 --omni 即可启动服务；配方文档把该命令列为 1 张 H200 141GB 环境下的验证配置。
图为 给出的 TTS 服务管线：前段是逐 token 的自回归 Talker，后段是并行解码的波形解码器，中间靠分块流式 connector 衔接。Drama 3 的两阶段结构与这张图一致。
先支持、再换运行时：10 月 14 日的三笔合并
Drama 3 的支持与优化在 10 月 14 日一天之内先后进入 vllm-omni 仓库：模型支持 PR 先合并，性能优化 PR 随后合并，同日还有一笔修复单帧请求在 codec（音频编解码器）交接处挂起的 。#8933 由 Sy0307 提交，其说明写道：#8900 的实现「服务正确，但过早饱和」——单张 H200 跑到 64 路并发时每秒只生成 30.2 秒音频，RTF（real-time factor，从请求发出到最后一包音频的时间除以返回音频时长）为 2.29，生成速度不及播放速度，而且每一路流都会断音。#8933 保留了 #8900 的模型模块、配置、提示词布局与服务接口，把底下的运行时整体替换。
按该 PR 自报的结果，优化后在 64 / 128 路并发下分别达到约 162 与 222.2 秒音频每秒，RTF 降至 0.375 / 0.515，中位首音频延迟 198 / 255 毫秒，没有一路流断音，WER（word error rate，词错误率）持平。帖文末尾致谢了 Fish Audio 与 vLLM-Omni 的贡献者。
测试口径：五轮、每轮 1,088 条英文请求，预编码音色参考
这组数字的测试口径在 PR 和配方页都写得很具体：单张 H200 141GB，Linux，Python 3.12，vLLM 0.31.0；请求取自英文评测集 Seed-TTS-Eval，每轮 1,088 条，每条克隆各自的音色参考；参考音频以预编码码本索引加转写文本（ref_audio_codes）随请求发送，服务端不再抓取或编码参考；流式调用 /v1/audio/speech，返回原始 PCM；采样参数为 temperature 1.0、top_p 0.9、top_k 30、max_new_tokens 500；每档并发用全新服务测，剔除 8 条预热请求，128 路并发的结果取 5 轮平均，64 路取 3 轮。吞吐按「每秒生成多少秒音频」计，数值大于 1 即快于实时。
#8933 还把这组数字与 Fish Audio 模型卡上的实测数据做了对照：128 路并发下，列出 2,177 帧/秒的吞吐（该口径下 1 秒音频折 21.5 帧）与 685 毫秒的中位首音频延迟，PR 报告 4,835 帧/秒与 255 毫秒，即约 2.22 倍吞吐、-63% 延迟。不过模型卡同一张表里还有另一种布局——把 vocoder（声码器，即第二阶段的波形解码器）放到第二张 GPU 上，128 路下为 3,692 帧/秒、401 毫秒，与 PR 的单卡配置不属同一部署。配方页当前的表格则列出 64 路下 163.8 秒每秒、195 毫秒，128 路下 232.5 秒每秒、252 毫秒，与帖文引用的 222.2 秒每秒、255 毫秒略有出入；两套数字均为项目自报。
两阶段共享一张卡：每帧一次前向，带状态的流式解码
vLLM-Omni 从全模态模型支持起步，此后扩展到多个 TTS 系统，6 月的工程博客已覆盖 Qwen3-TTS、VoxCPM2、Fish Speech S2 Pro 与 Higgs Audio V3。按配方文档，Drama 3 在其中拆成两个 stage：stage 0 是自回归阶段，35B 总参 / 3B 激活的 Qwen3.5 MoE（mixture-of-experts，混合专家）主干——混合 gated-delta-net 与全注意力，路由专家用 block-FP8——采样每帧的主 token，13 层 codebook 塔在同一次前向里采出其余 9 个码本，凑成每帧 10 个码本；stage 1 的 Fish DAC 解码器（与 Fish Speech S2 Pro 共用同一个 codec）把码本还原成 44.1 kHz 单声道音频。两个 stage 通过一个私有 MPS（Multi-Process Service，NVIDIA 的 GPU 多进程共享机制）守护进程共享同一块 GPU，默认部署给 stage 0 分配 0.78 的 GPU 份额（其权重占 36.9 GiB）、给 codec 阶段分配 0.1。
#8933 的改动集中在这里：把原来「每帧多次前向加每请求的主机侧工作」改成每帧一次前向，主干与 codebook 塔在同一次前向里处理整批请求；纯解码步整步回放为一张 FULL CUDA graph，带 prompt 行的步用 PIECEWISE 图；codebook 塔挂到 vLLM 的分页注意力上，与主干共享块表；top-k / top-p 采样用 Triton 融合内核完成，步骤之间不做主机同步；gated-delta-net 的混合步用打包解码内核加 FlashInfer 分块 prefill（对输入提示的一次前向计算），状态默认从 checkpoint 的 float32 降到 bf16，在 64 / 128 路下分别多出 7% / 13% 的音频吞吐而 WER 不变。stage 1 的 DAC 解码器改为 channels-last 卷积与按形状分桶的 CUDA graph，并为每路流保留卷积左上下文与窗口 transformer 的 KV，每个窗口只解码新帧，流式拼接出的音频与整句解码一致。调度侧加了 prefill 准入：在跑请求不少于 32 条时，新请求要等队列攒到 6 条或最老的已等 100 毫秒，才合并进下一个 prefill 步，这一项把 128 路下的 RTF 从 0.578 降到 0.513。
PR 附带的性能剖析显示，128 路并发下 GPU 有 97.9% 的时间在忙：stage 0 的内核时间里 MoE 约占 43%，稠密 GEMM 约 12%，gated-delta-net 约 9.9%；codec 占墙钟时间的 58.6%，它与 stage 0 的 MPS 重叠会把解码图拖慢约 28.5%。PR 自己把 codec 内核再融合与 MoE 内核列为下一批优化杠杆。
Drama 3 本体：多角色、可改写的语音生成模型
Drama 3 是 Fish Audio 于 10 月 13 日发布并开源的语音生成模型，把它定位成「把文本变成可指导的表演」：下一轮给一句备注就重录一条 take（一次录音成品）的多轮改写、最多 16 个角色的场景配音、按 infilling 编辑已有语音、流式文本输入，都是这一代新增的能力。模型卡列出的架构是 35B 总参 / 3B 激活的 MoE 主干（混合全注意力与线性注意力）、在整段序列上因果预测每帧 10 个码本的 codebook-MTP 音频解码器、FP8 专家权重加 bf16 其余权重；长文本自动分块、可按块流式输出。权重以 Fish Audio Community License 发布在 GitHub 与 Hugging Face，模型卡显示它在发布当天即可跑在 SGLang-Omni 上。
报告还给出 Fish Audio 自家引擎的单流速度：一张 H200 上解码 271 帧/秒，上一代 Fish Audio S2 为 177 帧/秒，而 Drama 3 的参数量是后者的七倍多。训练上，模型经三阶段预训练、指令微调与大规模强化学习，RL 的唯一奖励信号是一个单一的人类偏好学习模型。
能跑通的命令，和文档写明的边界
配方文档的验证环境是 1 张 H200 141GB，--omni 参数必填，默认部署配置 fish_omni.yaml 自动加载。音色克隆请求向 /v1/audio/speech 发 POST：带 input（要合成的文本）、ref_audio（参考音频）与 ref_text（参考转写）即返回 wav，也可以改用 ref_audio_codes 发预编码参考，请求链路上不再有抓取和编码。情绪与事件标签直接写进正文，如 [sighs]、[laughs]、[whisper]、[pause]，文档说明没有固定标签表，任何简短自然语言描述都接受；<|speaker:0|>～<|speaker:15|> 是仅有的特殊控制 token，不带说话人标签的文本由 speaker 0 读出。融合采样内核默认把 top_k 封顶在 64，需要更高时可用 fish_omni_max_top_k 调到 32～4096 之间的 2 的幂。
配方页「已知限制」一节写明了当前的边界：部署只支持一个 tensor 与 pipeline rank；prefix caching 关闭，因为 prompt 行里每音频行携带 10 个码本索引，token-id 哈希看不到它们；多轮改写（previous_takes）与长文本分块尚未通过 speech API 暴露，也就是说模型卡宣传的编辑类能力暂时接不到这个端点上。直接触及生产使用的是一条被标注为「模型行为」的问题：部分 take 读出第一个词或第一个事件后便只剩静音，直到 max_tokens 才结束；行首是标签或填充词、参考音频停顿偏多时更容易发生，句中标签更可靠。