Drama 3 接进短剧流水线：中文情感配音的一条龙实操

短剧是过去两年内容行业最凶猛的增量：从剧本到分镜到成片，全栈 AI 平台（huobao-drama、drama-workshop、Magic Drama 一类）已经把"剧本解析 → 角色/分镜生成 → 画面合成 → 视频合成"跑成了工业化流水线，海外投放榜单上 AI 剧也已进入真实投放主战场。但这条流水线上最"费力不讨好"的环节始终是配音：逐句调用 TTS、多角色音色漂移、情感全靠后期手调、台词时长与画面永远对不齐。

Fish Audio Drama 3 正是冲着这个环节来的。它是 Fish Audio 面向多角色场景与长内容设计的新一代 TTS：35B 参数、单 token 仅激活 3B，一段文本最多承载 16 个角色，还支持把 [sighs]、[laughs] 这类"表演指示"直接写进台词让模型照着演。社区消息显示其预览版曾登顶开放权重语音竞技场，并被官方称为"情感表现力最强的 TTS 模型"。本文基于仓库内的模型卡、配置文件与官方部署文档，从源码级证据出发，拆解把 Drama 3 接进短剧流水线的完整改造路径：部署起服务、角色注册、情感标签注入、多角色合成，再到混音收尾与版权合规。

短剧流水线的现状：配音环节为什么是瓶颈

先看社区里几类代表性的短剧流水线。huobao-drama 走的是"四段式"：剧本分镜生成、角色画面合成、AI 配音与口型对齐、时间线自动编排，其亮点在角色一致性（角色特征编码器 + SDXL cross-attention 注入）；drama-workshop 采用 Script-to-Asset-to-Video 的工业化工作流，用 React Flow 做可视化编排；Magic Drama 则把 LLM、文生图、文生视频与 TTS 串成端到端链路。行业共识是：AI 短剧的胜负手是"工业化流水线"而非单帧画质——而配音正是这条流水线里最依赖人工兜底的环节。

传统配音模块普遍有三类痛点：

• 多角色拼接成本高：一个场景四五个人物对骂，就得逐句调用 TTS 四五次，再手动拼接。角色之间音色漂移、语速不齐，对白节奏断裂是常态；
• 情感不可控：主流方案靠"选一个音色 + 后期拉音高/语速/音量"来模拟情绪，声音里的呼吸、气口、停顿这些"表演感"很难从文本直接驱动；
• 时长与对齐靠返工：台词长了要手动切片，短了要注水，口型对齐更是逐帧对表的体力活，一次导演改词，整段配音重来。

方言短剧领域还演化出 ASR → LLM 翻译润色 → TTS → FFmpeg 的变体链，本质也是把"文本到语音"当作可替换的一环。Drama 3 要做的，就是把这一环从"工具"升级成"演员"。

Drama 3 是什么：从仓库文件里读出的技术画像

这个仓库是 Drama 3 的模型发行仓库，没有工程源码，但配置文件本身就是最好的技术说明书。

README.md 给出了官方定位：面向多角色场景与长内容的新一代 TTS，支持多说话人生成、声音克隆与自然语言控制。关键特性有五条：

• 35B 参数、3B 激活：MoE 文本主干，混合 full + linear 注意力；
• Codebook-MTP 音频解码器：10 个 codebook 在整个序列上因果解码；
• FP8 MoE 专家，其余权重保持 bf16；
• 说话人标签 <|speaker:0|> … <|speaker:15|>，一段文本最多承载 16 个角色；
• 长文本自动分块，可按块流式输出。

这些声明都能在 config.json 里找到对应证据。text_config 显示主干为 40 层、hidden size 2048，layer_types 中 linear_attention 与 full_attention 按"3 线性 + 1 全注意力"交替排布——这就是"混合注意力"的字面来源；num_experts 为 256、num_experts_per_tok 为 8，并启用 shared expert，对应"3B active per token"的稀疏计算；max_position_embeddings 高达 262144，是长文本分块与长上下文的底子。audio_decoder_config 里 num_codebooks: 10、decoder_type: "codebook_mtp_shared"、mtp_spec 启用 full attention，正是"10 codebook 因果解码"的实现骨架。quantization_config 给出 bsgemm-moe 量化方法、128×128 的 weight block 与动态激活方案，对应 FP8 专家。

权重索引 model.safetensors.index.json 还能看到更多实现细节：每层 linear_attn 下挂着 conv1d.weight、A_log、dt_bias、in_proj_* 等状态空间模型（类 Mamba）风格的参数，mlp.experts.0~255 的 gate/up/down 三件套外加 weight_scale_inv 缩放因子（FP8 量化所需）逐层齐全。而 special_tokens_map.json 与 tokenizer_config.json 展示了完整的 token 体系：<|speaker:0|> 到 <|speaker:15|> 共 16 个说话人标签，<|semantic:0|> 起的长序列语义 token，以及 <|audio_start|>/<|audio_end|> 等音频边界 token。语言方面，README frontmatter 列出了 60+ 语言（含 zh、en、ja、ko），中文是其主战场语言之一。仓库还随附 codec.pth，即与 Drama 3 配套使用的音频编解码器。

一句话概括：这是一台"一个 token 只花 3B 计算量、但能同时演 16 个角色、还认得表演指示"的语音生成引擎。

接入改造点：把配音模块从"逐句合成"换成"一场一镜"

第一步：部署与起服务

Drama 3 从发布日起就运行在 SGLang-Omni 上，部署只需两步：

uv pip install --prerelease=allow -v -e ".[fishaudio]"
sgl-omni serve --model-path fishaudio/drama-3 --port 8000

起服务后就是 OpenAI 兼容的 /v1/audio/speech 接口。最朴素的用法：

curl -X POST http://localhost:8000/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"input": "她推开门，雨声灌了进来。"}' \
  --output output.wav

性能基线值得先记住（官方在 H200 上以流式 Seed-TTS 英文 prompt 实测）：单流首包音频 p50 仅 88.9 ms、RTF 0.131；16 并发时吞吐 927.6 帧/秒、RTF 0.373，即音频生成速度仍约为播放速度的 2.7 倍；64 并发 RTF 才到 0.80。若把 vocoder 挪到第二张 GPU（--tts_engine.gpu 0 --vocoder.gpu 1），256 并发下吞吐还能再涨约 72%、首包时延中位数降 37%。对短剧这种"一场戏几十条对白批量生成"的场景，这个吞吐量意味着配音可以整场整场地并行产出，而不是一句一句等。

有两个部署侧硬限制要提前知道：参考音频单条最长 60 秒（超了直接 HTTP 400，错误信息形如 references.1: reference audio lasts 75.3 s, longer than the 60 s limit），可用 --preprocessing.factory.max_reference_audio_seconds 上调并同步调大 total_reserve_bytes；prompt 上限 8192 行，长参考音频按约 21.5 行/秒消耗（codec 把 44.1 kHz 音频切成 2048 采样一帧），超限用 --tts_engine.factory.max_prompt_rows 调整。另外注意力后端只支持 triton，启动时指定其他后端会被直接拒绝——排障时先记下这一条。

第二步：剧本解析与角色注册

接进流水线的第一件事，是把剧本转成 Drama 3 能消费的数据结构。做法是"场次 → 分镜 → 台词表"解析后，为每个角色做一次声音注册：

1. 从素材库（或已有参考音）为每个角色准备一条 3~10 秒的干净人声片段，记下转写文本；
2. 把角色映射到固定编号：<|speaker:0|>、<|speaker:1|>……；
3. 同一场戏的台词合并成一次请求，不同角色用标签区隔，参考音频按角色逐一放进 references 列表。

示例请求体：

{
  "text": "<|speaker:0|>林霜：你以为我会原谅你？<|speaker:1|>陈默：原谅？我从来不需要。",
  "references": [
    {"audio_path": "/voicebank/lin_shuang.wav", "text": "我对你，只剩下失望。"},
    {"audio_path": "/voicebank/chen_mo.wav", "text": "这盘棋，我下定了。"}
  ]
}

这正是 Drama 3 与传统多角色方案的关键分野：老方案是"每角色合成一段、再剪辑拼轨"，Drama 3 是把整个场景的对话作为一条连续语音流生成，角色切换时语速、气口、情绪衔接都由同一个解码过程完成，省掉了大量拼接对轨工作。

第三步：情感分配——把"表演指示"写进台词

Drama 3 的 point tags 允许在文本的任意位置插入事件标签，模型会在标签落点执行对应表演：

{
  "text": "[sighs] 算了。要是错过，责任在你。[laughs] 也许吧，那也算公平。",
  "references": [{"audio_path": "/voicebank/en0.wav", "text": "We asked over twenty different people, and they all said it was his."}]
}

接入流水线时，可以写一个极小的映射层：剧本里的舞台指示/动作描述（"叹气""冷笑""哽咽"）经 LLM 或规则归一化为 [sighs]、[laughs]、[sobs] 等标签，按事件落点插入台词文本。这样"情感分配"就从"后期调音高"前移到了"写文本的阶段"——分镜脚本写定，配音的情感骨架也就定稿了，且每句的情感强度由标签在句内的位置精确控制。

第四步：重录与局部修改——previous_takes 续写式编辑

短剧拍摄现场最贵的是"重来一次"，AI 流水线里也一样。Drama 3 的 editing-as-continuation 把"重录"做成了"续写"：把旧版本作为 previous_takes 放进上下文，只改想改的片段：

{
  "text": "季度报告周四要交，请在中午前完成。",
  "references": [{"audio_path": "/voicebank/en0.wav", "text": "We asked over twenty different people, and they all said it was his."}],
  "previous_takes": ["季度报告周三要交，请在中午前完成。"]
}

官方示例甚至演示了链式二次修改：把 by noon 改成 by five 时，把前两版 take 都放进上下文。放在短剧流水线里，这意味着导演改一句台词，不需要重录整场——只把该句的旧版本回填上下文，音色、语速、情绪基线都会延续，这是传统逐句 TTS 完全做不到的。

第五步：流式与长文本

短剧台词往往整段整段地长。Drama 3 对长文本自动分块，且支持流式输出：

{
  "input": "（长达数百字的独白……）",
  "stream": true,
  "response_format": "pcm"
}

流式 PCM 的意义在于：配音可以和剪辑流水线并行——第一块音频落地就进时间线，后面的边合成边补位，不再等整段生成完毕。对"每日批量出片"的产能型流水线，这一条直接决定了吞吐上限。

多角色情感分配与混音收尾

情感分配策略

多角色场景下最容易犯的错误是"全员高情绪"——每个角色都打满 [shouts]，听感立刻变油。实操上建议两层分配：

• 角色语气基线靠参考音频给：注册角色时选择能代表其性格的样本，基线情绪（冷峻/温吞/泼辣）由克隆参考锚定，文本层面不必重复标注；
• 标签只标"偏离基线"的时刻：一场戏 30 句对白，情绪标签控制在 5~10 个点，标在情绪真正翻转的位置（破防、冷笑、哽咽）。标签越克制，戏剧张力越强。

另外要注意情感标签与语速的配合：[laughs]、[sighs] 这类"事件型"标签在句内落点不同，节奏感差异很大，建议在剧本映射层保留原舞台指示的位置信息，而不是统一塞到句首。

对齐与混音

混音前先理解 Drama 3 的时长预算：codec 把 44.1 kHz 音频切为 2048 采样一帧，约 21.5 帧/秒——即每秒语音消耗约 21.5 行 prompt 预算。实际对齐可按三条路线组合：

1. 时长粗对齐：合成完成即拿到音频时长，与分镜时长比对。短了用时间拉伸（TSM）微调或补气口停顿，长了重新生成或删句，避免整段变速导致的"播音腔"；
2. 响度与定位：对白轨按角色做响度归一（建议以 LUFS 为基准）与轻微 EQ 区隔（主角靠前、配角靠后），再混入 BGM 与 SFX，最后统一限幅；
3. 口型粗同步：Drama 3 输出的是"整段自然语音"，对需要逐字口型对齐的项目，可把合成 PCM 按句子时间戳（依据文本长度与语速估算）切分，喂给下游口型驱动模块，做粗对齐即可——对短剧的竖屏快剪节奏，粗对齐通常已足够。

合规与版权：商用前先读 LICENSE

最后，也是很多团队最容易忽略的：LICENSE（Fish Audio Community License v1.0）有几条硬约束：

• 年营收低于 50 万美元（含关联方合计）可免费商用，达到阈值后需在 30 天内书面通知 Fish Audio，超出部分需另签授权；
• 托管服务（Hosted Service）——即向第三方提供"输入文本/声音、输出语音"的自助式 API 或站点——无论营收多少都必须单独签授权；但"你自己生成内容、交付成品音频"的代理/工作室/自由职业模式不在此列；
• 克隆真人声音必须取得本人同意（未成年人需监护人同意，已故人士需权利方同意），并禁止用于欺诈、骚扰、robocall；
• 不得移除输出中的水印/溯源信号；不得用输出训练、蒸馏任何生成式基础模型（仅限检测合成音频、水印验证等防御性用途除外）；
• 分发模型或衍生作品需附本协议文本，并显著展示 "Built with Fish Audio" 署名；输出音频的所有权归使用者。

对短剧工作室而言，"代理制作成片交付"是许可协议明确允许的路径，但自建配音 API 对外售卖则直接触碰 Hosted Service 红线——接入前把这条读清楚，能省下后患。

结语

把 Drama 3 接进短剧流水线，本质是完成一次"配音模块"的范式替换：从"逐句合成的工具"升级为"一场一镜的演员"。改造路径清晰且可复制——SGLang-Omni 一条命令起服务，剧本解析后按角色注册声音、用 speaker tag 整场合成为一条语音流、用 point tags 把舞台指示写进台词、用 previous_takes 实现低成本重录、用流式 PCM 边合成边上时间线，最后按帧率预算对齐混音。配合 16 角色上限、60+ 语言（含中文）与 60 秒参考音频额度，这套方案足以支撑"剧本 → 分镜 → 配音 → 混音"的中文短剧量产闭环。剩下的，就是给每个角色找到那 10 秒最贴戏的参考人声了。