Building Swahili Speech on Dia-1.6B
In June, we reached a conclusion.
Don't build on Dia-1.6B.
It wasn't a bad model. It just didn't look like the right foundation for Swahili.
Dia was English-only. There was no official fine-tuning pipeline, no adapter support, and no documented example of anyone successfully adapting it to a new language. The community experiments we found hadn't produced convincing results.
Our own experiments didn't help.
Our first fine-tuning run produced a character error rate (CER) of 2.331. The output wasn't usable.
So we stopped.
A few weeks later, we came back.
Not because Dia had changed.
Because our understanding of it had.
We rebuilt parts of the training pipeline. We changed how we prepared the data. We changed how we evaluated the model. Gradually, the results improved.
Today, we're releasing Sauti-Dia-SW, an open Swahili text-to-speech model built on Dia-1.6B.
The model was trained on 126 hours of Swahili speech drawn from a 500-hour corpus we assembled from 15 openly licensed public datasets. It generates natural Swahili speech, supports Swahili-English code-switching, and is released under the CC-BY-4.0 license.
Alongside the model, we're releasing the weights, training pipeline, evaluation harness, benchmark, model card, and a listening page so anyone can hear the generated speech. The technical report will follow soon.
The model achieves 0.060 CER in a single generation and 0.021 CER using an ASR-gated retry loop on 500 previously unseen Swahili news sentences. On our curated evaluation set, it reaches 0.011 CER.
Those numbers matter.
But they aren't the most interesting part of the project.
The most interesting part was discovering how often our own tools were misleading us.
At one point, our evaluation pipeline consistently ranked one checkpoint above another.
Later, we realized the evaluator itself couldn't correctly score Swahili-English code-switched speech. It treated embedded English words as transcription errors, even when the synthesized speech was correct.
Changing the evaluator changed the ranking.
We also built an artifact detector to identify clicks and other audio defects.
As the model improved, the detector reported that more and more clips contained artifacts.
It turned out the detector wasn't finding defects.
It was reacting to sharper plosive consonants.
The model had improved.
Our metric interpreted that improvement as a regression.
We found another surprise when comparing checkpoints.
Differences that looked meaningful disappeared once we tested for statistical significance.
Some of the rankings we thought reflected better models were simply noise.
Perhaps the biggest surprise came from the data itself.
Over the past year, we assembled a 500-hour Swahili corpus from 15 openly licensed public datasets.
Only 126 hours made it into training.
Dia's architecture limits each training example to roughly 17.8 seconds. Longer recordings become misaligned with their transcripts, so most of our corpus couldn't be used without re-segmentation.
That wasn't a data problem.
It was an architectural one.
Despite that limitation, 126 hours proved sufficient to produce a high-quality Swahili model.
Looking back, the biggest lesson wasn't that Dia could learn Swahili.
It was that engineering progress often comes from questioning your own assumptions.
We're releasing more than a model.
We're releasing the training pipeline, the evaluation framework, the benchmark, the listening page, and, soon, the technical report.
We hope they are as useful as the model itself.
