Fish Audio has released Drama 3, a text-to-speech model with open weights, 35 billion parameters and 3 billion active per token. The name is the specification: it is built for multi-character scenes and long-form narration rather than for single-voice utterances.
Most open TTS work still optimises the one-line case — give it a sentence and a reference clip, get back a plausible read. Drama 3’s design decisions are all about what happens after that, when the thing you are making is a scene with several people in it who have to sound like they are in the same room.
Speaker tags go inside the text
The headline feature is that one text can carry up to sixteen characters, marked with speaker tags written inline at the point where each one speaks. You are not making sixteen API calls and concatenating the results, and you are not managing sixteen separate voice sessions.
That distinction matters more than it sounds. Stitched-together per-line generation is how multi-character audio is usually assembled, and it is why the results so often have the texture of a telephone conference: each line is individually fine, and the scene does not cohere, because nothing generating line four knew how line three landed.
Paralinguistic events are also written into the text rather than configured around it. The model card’s example is a plain /v1/tts request carrying [sighs] Fine. If we miss it, it's on you. [laughs] Well, maybe that's fair. — the tags sit at the position where the event should land.
Editing as continuation
The second design decision is the one worth stealing. Drama 3 accepts previous_takes — the earlier versions of a line — alongside the new text, and treats the retake as a continuation of the model’s own prior output rather than a fresh generation.
The card’s worked example changes The quarterly report is due on Wednesday to due on Thursday, then chains a second edit turning by noon into by five, with both earlier takes in context. In a conventional pipeline, fixing one word in a finished read means regenerating the line and accepting that the delivery will drift — different pacing, different emphasis, an audible seam where the fix meets the surrounding audio. Passing the previous take back in is an attempt to make the correction inherit the performance.
Anyone who has had to change a single number in an otherwise-approved voiceover will recognise why this is on the feature list.
The architecture, briefly
- 35B MoE text backbone, 3B active per token, with hybrid attention — full and linear layers mixed
- Codebook-MTP audio decoder: ten codebooks decoded causally across the whole sequence
- FP8 MoE experts, remaining weights in bf16
- Long text is chunked automatically and can be streamed per chunk
- Voice cloning from a reference clip plus its transcript; the card’s English example is a 3.9-second reference
The language list in the card’s metadata runs past eighty entries, from Chinese, English, Japanese and Korean through to Welsh, Basque, Tibetan and Māori. Treat the long tail of that list with the scepticism any such list deserves until you have tested the language you need.
Published latency, and the configuration note underneath it
Fish Audio published streaming measurements on NVIDIA H200 hardware, each cell the mean of four runs. A single stream reaches first audio in under 100 ms. At concurrency 16, throughput is 927.6 frames per second with p50 time-to-first-audio at 210.1 ms — audio still being generated about 2.7× faster than it plays. At concurrency 64, mean real-time factor holds at 0.80.
The more useful table is the second one. Because SGLang-Omni treats the grouping and GPU placement of pipeline stages as deployment configuration rather than per-model code, the same model serves very differently depending on where you put the vocoder:
| Vocoder placement | Concurrency | Throughput (frames/s) | TTFA p50 | TTFA p95 |
|---|---|---|---|---|
| Engine’s GPU | 128 | 2,177 | 685 ms | 1,412 ms |
| Engine’s GPU | 256 | 2,422 | 3,403 ms | 4,255 ms |
| Second GPU | 128 | 3,692 | 401 ms | 995 ms |
| Second GPU | 256 | 4,160 | 2,146 ms | 2,469 ms |
At 256 streams with the vocoder sharing the engine’s GPU, the vocoder saturates and every new stream’s first audio queues behind it — p50 time-to-first-audio blows out to 3.4 seconds. Moving it to a second GPU gives roughly 72% more throughput and a 37% lower median TTFA at the same concurrency.
This is a deployment lesson disguised as a benchmark. The model is not slow at 256 streams; one stage of the pipeline is, and which stage that is only becomes visible when you measure placements separately. Fish Audio measured and published both, which is more than most model cards bother with.
The licence is the thing to read first
Drama 3 ships under the Fish Audio Research License, not an OSI-approved open-source licence. The weights are downloadable and the model is listed as license_name: fish-audio-research-license. If you are planning commercial character work, read the licence file before you plan anything else — “open weights” and “licensed for your use” are different claims, and the gap between them is where projects get expensive.
There is also a technical report on arXiv for the architecture details the card compresses.
Where this sits
For creative work the comparison is less with general TTS and more with the dialogue-focused tools: ElevenLabs v3, whose expressive-dialogue mode solves a similar problem behind an API. Drama 3’s pitch is the same capability with the weights on your own machine, which for client material means the audio never leaves it — the same argument that keeps turning up now that local models are good enough to make it.
Sources
- fishaudio/drama-3 — model card and published benchmarks
- Drama 3 technical report — arXiv
- Drama 3 cookbook — SGLang-Omni deployment and streaming API
- Fish Audio Releases Drama 3, a 35B Open-Weight MoE Text-to-Speech Model — MarkTechPost
- Fish Speech — GitHub
- Fish Audio Drama 3 is Here — Fish Audio on YouTube