企业官网建设流程全解析

Fish Audio Drama 3 是一款面向多角色对话与长内容的文本转语音（TTS）模型，核心特性是 35B 总参数、每 token 仅激活 3B 的MoE（专家混合）语音模型，原生支持声音克隆、16 路多说话人与自然语言控制。本文带你从配置文件出发，把它的 MoE 路由、混合注意力、Codebook-MTP 音频解码器与 FP8 量化一次拆解清楚，帮你在不看源码的情况下建立完整架构认知。

🎯 一分钟看懂 Drama 3 的定位

Drama 3 不是普通的"念稿"语音模型，而是专为剧本/有声书/多角色场景设计的生成引擎。它把"多角色、长文本、情感控制"作为一等公民，而不是事后拼接。

一句话概括：用大模型的"理解力"驱动语音，用 MoE 把推理成本压到可接受范围。

🧩 35B 总参数、3B 激活：MoE 专家路由机制

Drama 3 的语言主干（text_config）是一个40 层的 MoE Transformer，它的"省"就省在专家路由上。

• 每层 256 个专家（num_experts: 256）
• 每个 token 只激活 8 个（num_experts_per_tok: 8）
• 40 层全部是 MoE 层（mlp_layer_types全为moe）
• 额外配 1 个共享专家（shared_expert_gate: true），兜底通用能力

参数量是怎么凑到 35B 的？大致算一笔账：

而每个 token 实际参与计算的只有8/256 ≈ 3.1%的专家，外加注意力与前向公共部分，所以激活参数约 3B。

💡 这就是 MoE 的精髓："大容量"负责知识储备，"少激活"负责推理省钱。模型知道得多，但每次只叫醒需要的部分。

配置出处：config.json 中的num_experts与num_experts_per_tok，以及 config.json 中全 MoE 的mlp_layer_types。

⚡ 混合注意力：线性注意力 + 全注意力交替

Drama 3 没有一刀切用标准注意力，而是采用了线性注意力（linear_attention）与全注意力（full_attention）3:1 交替的混合结构。

在layer_types里能看到清晰的节奏：

linear → linear → linear → full linear → linear → linear → full ...（每 4 层一组，共 10 组）

• 30 层线性注意力：计算量随序列长度近似线性增长，长文本不爆炸
• 10 层全注意力：保留精确的全局建模能力
• 配合linear_conv_kernel_dim: 4、Mamba 风格 SSM（mamba_ssm_dtype: float32）

这套组合带来两个直接收益：

1. 256K 上下文（max_position_embeddings: 262144），长剧本一口气喂进去
2. 长文本可分块、可流式，边生成边出音频，而不是等整段算完

📌 对普通用户来说，你感知不到"线性注意力"这个词，但你会感觉到——长篇有声书不会越往后越卡。

完整层序定义见 config.json。

🎵 Codebook-MTP 音频解码器：10 个代码本如何还原声音

文本模型输出的不是声波，而是一串"声学 token"。真正的声音由Codebook-MTP 音频解码器渲染出来。

它的工作方式可以这样理解：

• 10 个代码本像 10 道"分辨率滤镜"，从粗到细，把抽象 token 逐层还原成可播放的声学帧
• 沿整段序列因果解码，保证声音是连贯推进的
• MTP（多 token 预测）让解码器一次预测多个时间步，显著提速

这也是 Drama 3 能做到"首帧音频 < 100ms"的关键之一。

🗜️ FP8 量化：为什么 35B 模型只有约 37GB

打开 model.safetensors.index.json，total_size为39594895616字节，约37 GiB。对 35B 参数而言，这个体积说明它做了混合精度量化。

配置在 config.json：

"quantization_config": { "quant_method": "bsgemm-moe", "weight_block_size": [128, 128], "activation_scheme": "dynamic" }

• MoE 专家权重用 FP8（1 字节/参数），bsgemm按 128×128 分块存储缩放因子
• 其余权重保持 bf16（2 字节/参数）

这笔账正好对上：

专家 32.3B × 1 字节 ≈ 32 GB 其余 约 2.6B × 2 字节 ≈ 5 GB ────────────────────────────── 总计 ≈ 37~39 GB ✓

✅收益很实际：显存占用大幅下降，单张高端卡（如 H200）就能起服务，部署门槛明显降低。

🎭 16 个说话人标签：多角色场景的秘密

Drama 3 之所以能演"剧本"，靠的是词表里预埋的结构化特殊 token。在 special_tokens_map.json 里能找到：

• 说话人标签：<|speaker:0|>到<|speaker:15|>，一段文本里切换标签即可让 16 个角色轮流开口
• 语义 token：<|semantic:N|>一族，标记语音语义边界
• 韵律/音素标记：<|phoneme_start|>、<|voice|>、<|interleave|>等
• 音频起止符：audio_bos_token/audio_eos_token

这些 token 配合对话模板 chat_template.jinja，让"谁在说、说什么、什么情绪"都能被模型显式理解，而不是靠隐式猜。

💬 对内容创作者而言：写剧本时把角色名和情绪写进文本，模型就能分声演绎——这是 Drama 3 区别于普通 TTS 的最大卖点。

🚀 上手部署：SGLang-Omni 一键启动

Drama 3 首发即接入SGLang-Omni推理框架。部署只需两步——安装运行时、拉起服务：

# 1. 安装 SGLang-Omni 的 fishaudio 支持 uv pip install -e ".[fishaudio]" # 2. 启动推理服务 sgl-omni serve --model-path fishaudio/drama-3 --port 8000

启动后即可调用标准/v1/tts接口，传入文本 + 参考音频，得到流式音频。

实测性能（单张 H200，英文流式请求）

📈 几个关键读数：单流首帧 < 100ms（几乎无感）；并发 16 时音频生成速度约为播放的2.7 倍；并发 64 时 RTF 仍 ≤ 0.8（实时性充足）。

官方还给出一个部署技巧：把音频解码器（vocoder）放到独立 GPU，256 路并发时吞吐提升约 72%、首帧延迟降低 37%。

完整压测数据与部署建议见 README.md。

📚 关键文件索引

✍️ 写在最后

Drama 3 的"炼成"并不神秘，而是三件事的叠加：

1. MoE 专家路由——用 35B 的知识容量，换 3B 的推理成本
2. 混合注意力——线性 + 全注意力交替，撑住 256K 长文本还能流式
3. Codebook-MTP + FP8——10 层码本高质量还声，FP8 把 35B 压进 37GB

它把"大模型的理解力"搬进了语音，让多角色、长内容、声音克隆从"拼接工程"变成了"一次生成"。如果你想动手，从 README.md 的启动命令开始，配合本文的架构认知，很快就能读懂它输出的每一帧声音。