TADA: a speech language model that speaks one text token at a time

One speech vector for every text token

TADA is described as a unified speech language model that synchronizes speech and text into a single, cohesive stream via 1:1 alignment, and the whole design follows from that phrase. The tokenization schema is the core: for every word or subword token there is exactly one corresponding speech vector, so the tokenizer encodes audio into a sequence of vectors whose length matches the number of text tokens exactly. That gives the model an explicit, learnable relationship between the words it is producing and the sound it is producing, and the README argues that it lets the model understand the precise timing of speech relative to text. The generation scheme is different from the usual text to speech pipeline, where the model produces a fixed number of frames per second of audio, for example fifty frames per second. In TADA each autoregressive step covers one text token, and the model dynamically determines the duration and prosody for that specific token. The claimed consequences are a more natural flow and the elimination of transcript hallucination, the failure mode where a model emits audio that drifts out of sync with the words it is supposedly saying. The repository also carries the paper on arXiv and a Hugging Face demo space, so the claims are documented in a form you can read and inspect.

Dual stream generation keeps the context length the same as text

The third key feature, dual stream generation, is what makes the per token scheme workable. The model generates a text token and the speech for the preceding token simultaneously, and the README says this maintains the same context length as text only generation. That is the engineering trick worth understanding, because it is the difference between a model that can speak a long passage and one that drifts. In a conventional autoregressive text model the context grows by one token per step, and a speech model built the same way would need a context that grows with the audio as well. By producing the acoustic payload one step behind the text, the model keeps the sequence lengths the same, so the cost of a step does not depend on how much audio has been produced. The result is what the README calls superior expressiveness and natural flow while significantly reducing computational cost, and it is the reason the project claims high fidelity synthesis with a fraction of the computational overhead of traditional models. The framing in the README is careful that this is about the tokenizer and the architecture rather than about a smaller model.

Two model sizes, one shared encoder, and a weight licence to accept

The models are built on Meta Llama 3.2, and the README is explicit that this is a prerequisite rather than a detail: you must request access to the Llama models before using TADA, which means visiting the Llama 3.2 1B or Llama 3.2 3B model pages and accepting the licence agreement. Two checkpoints are published. TADA-1B is based on Llama 3.2 1B and is on the Hub as `HumeAI/tada-1b`, and TADA-3B-ML is based on Llama 3.2 3B and is `HumeAI/tada-3b-ml`. Both use the same encoder, `HumeAI/tada-codec`, and can be loaded through the same API. The licence situation has two layers and the repository makes both visible. The package metadata declares the project as MIT, the README badge says MIT, and the front matter of the model card names the licence as llama3.2, with the repository holding a `LICENSE` and a separate `LICENSE_CODE` file. In other words the code you install from PyPI and the weights you download are governed differently, and the code and the model weights should be treated as two separate decisions. The `tada/` package is the Python library, the `inference.ipynb` notebook holds the end to end example, and the `apple/` directory is part of the tree for a platform that the README does not otherwise explain.

Installing and running the first synthesis

The package is on PyPI as `hume-tada`, and the source build is a clone and an editable install.

pip install hume-tada

git clone https://github.com/HumeAI/tada.git
cd tada
pip install -e .

The inference pattern in the README is the part to copy. The encoder is loaded separately from the model, the prompt audio is loaded with torchaudio, the encoder is called with the audio and the prompt text, and the model then generates from that prompt and a new text string:

import torch
import torchaudio

from tada.modules.encoder import Encoder, EncoderOutput
from tada.modules.tada import TadaForCausalLM

device = "cuda"

# Encoder is loaded separately (not inside the model)
encoder = Encoder.from_pretrained("HumeAI/tada-codec", subfolder="encoder").to(device)
model = TadaForCausalLM.from_pretrained("HumeAI/tada-3b-ml", torch_dtype=torch.bfloat16).to(device)

The `subfolder="encoder"` argument tells you that the codec repository holds the encoder as a subfolder, and the `torch_dtype=torch.bfloat16` argument is one of the March 2026 additions. The example also shows the prompt caching hooks, `EncoderOutput.save()` and `EncoderOutput.load()`, with a commented `prompt.save("prompt_cache.pt")` and a matching load, so an application that reuses the same voice prompt does not pay the encoding cost on every run.

Multilingual synthesis needs a transcript and the right aligner

TADA supports multilingual speech synthesis through language specific aligners, and the encoder takes a `language` parameter to select one, for example `language="ja"` when loading the encoder for Japanese. The second half of the requirement is less obvious and is stated in a comment in the README's own example. For non English prompts you have to provide the transcript so that the encoder uses forced alignment, instead of the built in ASR, which is English only. The example loads a reference clip in the target language, passes the transcript text along with the audio, and then generates Japanese text. The reason is architectural rather than an oversight: the 1:1 alignment depends on knowing the text, and the automatic transcription that would supply it only exists in one language, so for every other language the alignment has to be forced from a transcript you supply. The README lists the supported languages, so check your target language against that list before you plan around it.

The March 2026 round of work, and what the numbers mean

The Updates section of the README is a list of engineering changes with figures attached, and it is the most useful thing to read before sizing a deployment. The encoder is no longer loaded inside `TadaForCausalLM`, which the README says saves roughly 2.5 GB of VRAM, and it should be loaded separately only when encoding new prompts. `EncoderOutput.save()` and `EncoderOutput.load()` were added for prompt caching, so you can encode once and reuse without the encoder. The default number of flow matching steps was reduced from 20 to 10, which the README describes as having no perceptible quality loss and being about 1.3 times faster. bfloat16 inference is supported through `torch_dtype=torch.bfloat16`, halving model memory, with about 9 GB quoted for the 3B model, and `model.compile()` is supported for torch.compile optimization, quoted at about 0.12x real time factor on an H100 with cached prompts. These are the project's own claims from its release notes, not measurements from an independent test, so treat them as a starting point for capacity planning rather than as a benchmark.

Practical limits and what state the project is in

A few constraints are visible in the packaging. The dependency set is narrow and pinned: `transformers>=4.57.1,<5`, `torch>=2.7.0,<2.8.0`, torchaudio, torchvision and `descript-audio-codec>=1.0.0`, which means an existing environment on a different torch minor version will need a separate environment, and the torch upper bound will eventually need attention. Python 3.10 or later is required, the build backend is setuptools, and the development tooling comes from uv with ipykernel, mypy, pytest and ruff, with a line length of 120 and the isort rules enabled. The evaluation section of the README is a set of charts, covering character error rate, real time factor, naturalness MOS and speaker similarity, which is the right way to publish a research comparison, but it means the numbers live in the figures rather than in the text. On maintenance, the repository publishes no GitHub releases, the last push was on 2026-05-11, and the README describes the model in the present tense of a project in progress. The `inference.ipynb` notebook and the Hugging Face collection are where you will find out what changed.

Editorial conclusion

Adopt TADA if you need speech generation with a text prompt and a voice prompt in the same model, if you can accept a dependency on Meta's Llama 3.2 weights and their licence, and if your hardware can hold a 3B model. Do not adopt it as a drop in replacement for a conventional text to speech engine, because the model is a research release with a pinned dependency set and no tagged releases. Before you build, request access to the Llama 3.2 model you intend to use and accept its licence, since the weights are not included, and read the two licence files in the repository, because the code and the model weights are licensed differently. Also plan for the encoder being a separate object, since loading it separately saves about 2.5 GB of VRAM and lets you cache prompts. The code is MIT, the weights follow llama3.2, and the last push was on 2026-05-11.

Frequently asked questions

Official sources

1. HumeAI/tada on GitHub
2. Issues
3. Project website
4. README