We released TontaubeV1, a character-level TTS model for long-form generation [P]

Hey everyone,

My brother and I just released TontaubeV1, a 2.9B-parameter open-weight TTS model focused on expressive speech, long-form generation/narration, and low-latency local inference. It is primarily aimed at English and German and supports zero-shot voice cloning from up to one minute of reference audio. It builds on DualCodec, a multi-codebook discrete audio codec. It was trained on 7 languages and ~200k hours of audio (mostly tested in English and German).

I wanted to make a post to highlight two choices that worked well for us and seem less common in current TTS models:

1. Character-level tokenization

We start from a Qwen3-1.7B checkpoint for our semantic codebook model. Many modern, and especially LLM-based, TTS models use the tokenizer from the backbone model, add special/audio tokens, and train the model on predicting the next token. We experimented early on with character-level tokenization and found that it generally worked better than using the original BPE tokenizer from Qwen.

We still use the tokens emitted by the Qwen tokenizer, but force it to tokenize spoken text as a sequence of individual characters. When experimenting with forcing Qwen to predict text in this mode, we found that it was still able to answer questions correctly, which suggested to us that language understanding was retained even with this unusual representation.

We did this because a) context length usually is not as much of an issue for TTS as it is for regular LLMs, since we do not require huge reasoning budgets and use chunking, and b) it makes the character-to-sound mapping much simpler internally. Speech is a lot about syllables and short character sequences.

When using the regular BPE tokenizer, we found that the model went out of distribution more often and was more likely to encounter a sequence of tokens that was rare or absent from the TTS training data. Complex sequences of special characters can be particularly confusing because they may tokenize into combinations that the TTS model has barely seen. This is amplified by the fact that TTS training covers far fewer text-token combinations than the full pretraining of an LLM.

2. Chunking and position scheme

The important part here is not just that we split long text into chunks. The chunk boundaries are part of the token layout and position scheme used during training.

The model processes several rows in one flat sequence: text, semantic audio, and the completed lower acoustic codebooks. If we simply used normal sequential position IDs, tokens representing the same moment in the audio would end up far apart because the rows are serialized one after another. Instead, the physical sequence order determines which tokens the model can see, while we assign separate logical position IDs. Codec tokens for the same audio frame share a position across codebooks, and text and audio are placed on the same approximate timeline.

Text advances by one position per character, while audio advances at 12.5 frames per second. These rates are fairly close for normal speech, but not identical, so the two streams usually need slight realignment after every chunk. We use paired text and audio split markers that share the same position. We also reserve an additional 25 character positions at each boundary. This prevents the generated audio positions from leaking into the next chunk’s text positions, while keeping the position IDs monotonic and approximately linear across the passage.

For every chunk, the semantic model sees the previous text and audio chunk, the current text, and a short lookahead into the next text. Once a chunk is finished, the oldest text-audio pair is discarded and the window moves forward. This keeps the model context bounded even for very long passages, while still retaining nearby text and audio context. The higher acoustic codebook models work on one chunk at a time and do not carry acoustic state between chunks.

DualCodec’s decoder is forward-looking, which makes directly decoding and joining separate chunks problematic. For streaming, we therefore decode overlapping DualCodec windows, re-encode them into the VibeVoice acoustic space, keep the stable middle sections, and decode them with a shared causal VibeVoice decoder state. This reduces audible seams between chunks and lets us emit audio before the full passage has been generated.

Here is figure 1 from our technical report:

https://preview.redd.it/dq70r0hwiwmh1.png?width=1552&format=png&auto=webp&s=6a4b6afa2dd5d1d562564ecac01b2279c10098b2

The current release requires a GPU with at least 24 GB of VRAM for the low-VRAM and balanced profiles, or 32 GB for the high-throughput profile. A substantial part of the current VRAM requirement comes from vLLM’s KV-cache reservation and our multi-engine serving setup, which are designed for high concurrency and low latency. We plan to release quantized versions aimed at much smaller memory capacities and on-device use, as well as fine-tuning support.

We also ran a 400-passage LLM-as-a-judge audiobook benchmark. On prosody, TontaubeV1 scored 50.1% against ElevenLabs Flash v2.5 and was preferred over Fish Audio S2 Pro, Gradium, and Cartesia Sonic 3. The methodology, caveats, and confidence intervals are described in the report.

Human listening tests remain the gold standard, so take these results with a grain of salt. We were not able to conduct a large-scale human study before release, but we plan to submit TontaubeV1 to TTS Arena V2 and the Artificial Analysis Text to Speech Arena.

Links:

- HF model page: https://huggingface.co/TontaubeAI/TontaubeV1

- HF demo: https://huggingface.co/spaces/TontaubeAI/tontaube-v1-tts-demo

- Inference code: https://github.com/craitech/tontaube

- Technical report: https://tontaube.ai/papers/tontaube-v1-technical-report.pdf

Let me know if you have any questions!