Griot Edge: Smaller Speech Models, Better Questions

Could we take what we learned from Griot Nano 1, use about 60% fewer parameters, and transcribe speech as it arrives?

Griot Edge is our answer so far: a 60.9-million-parameter Conformer CTC model for Akan, Dagbani, Dagaare, Ewe, Fante, Ghanaian English, and Ga. For streaming, it lets applications choose how much future audio to wait for, using the same checkpoint whether they need a quicker response or more context.

Three results shaped this release:

• A smaller streaming model is viable. Edge has 60.9M parameters against Nano 1’s roughly 153M, with selectable lookahead.
• Decoding matters. On Edge’s internal test, KenLM brings default-tier WER from 34.94% to 26.93%.
• The aggregate hides a large Akan gap. Human-transcribed sources score 19.15% WER against machine-transcript sources score 49.98%. That deserves investigation before we decide what to train next.

What did we gain over Nano?

The size reduction is clear. The accuracy comparison needs more care.

Model	Parameters	Test utterances	Decoding	CER ↓	WER ↓
Griot Nano 1	~153M	99,547	Greedy	13.66%	29.19%
Griot Edge	60.9M	109,008	Greedy	15.04%	34.94%
Griot Edge	60.9M	109,008	KenLM beam	14.59%	26.93%

These are published results on different test populations. Edge’s beam row also adds a language model. The lower WER in that row does not establish that Edge is more accurate than Nano. We need both models on the same held-out audio, with the same normalization and decoding, to answer that properly.

What Edge delivers today is a smaller model with a streaming context control. Nano’s model card and Edge’s evaluation notes give the score definitions and caveats.

One checkpoint, several amounts of context

Edge uses 17 Conformer blocks, a 384-dimensional representation, six attention heads, and a convolutional frontend that reduces the time resolution by four. Its 151-character vocabulary retains case, punctuation, and orthographic vowels.

The useful control is lookahead_frames: how many future encoder steps attention may see. Set it to 0 for causal attention or 13 for the release default. More lookahead allows more context, but also asks an application to wait for it.

A correction to the original post: the released runtime has a 10 ms feature hop and 4× subsampling, so an encoder step represents 40 ms, not 25 ms. Thirteen steps correspond to 520 ms of attention right context. That is not total user-visible latency: buffering, feature extraction, inference, and decoding also take time.

On the existing 2,000-utterance sweep, extra context helped only a little:

Future encoder frames	Attention right context	CER ↓
0	0 ms	17.35%
13	520 ms	17.17%
26	1,040 ms	17.18%
51	2,040 ms	17.55%
Full context	Entire input	21.75%

This subset is separate from the full test results below. The wider settings were undertrained; giving this checkpoint more future audio did not reliably improve it. We use the default or causal tier as the main reference points, with 6- and 26-frame settings available. The 51-frame and full-context modes are outside the validated release tiers.

Training it to handle the choice

We built Edge in three stages:

Stage	Audio processed	Purpose
Pretraining	44,000 hours	Learn multilingual speech representations from the raw MMS stream
Post-training	12,000 hours	Mix in Ghanaian speech and no-speech examples
Release fine-tuning	10,000 hours	Train with intermediate CTC and variable lookahead

These are audio-hours processed, not a claim of 66,000 unique recorded hours.

The final stage adds CTC supervision at two intermediate encoder layers and samples lookahead from 0, 6, 13, 26, 51, full, favouring short settings. We ramped in the mix over 2,000 audio-hours alongside learning-rate warmup. The auxiliary heads supply training signals inside the encoder and are removed for inference.

The intent was to make one set of weights useful across context budgets. This run does not isolate the contribution of intermediate CTC from variable lookahead; that would need an ablation.

What KenLM adds

On the 109,008-utterance internal test set, the decoder makes a larger WER difference than moving from causal to the default lookahead.

Same Edge test population. Default = 13 future encoder frames. The chart starts at zero; labels show absolute WER.

At the default tier, KenLM reduces WER by 8.01 percentage points, from 34.94% to 26.93%. With KenLM fixed, moving from causal to the default changes WER from 28.86% to 26.93%, a 1.93-point reduction. CER at those two beam settings is 15.81% and 14.59% respectively.

Scores normalize references and predictions using NFC, lowercase, and tone-mark removal. The beam uses the bundled multilingual 3-gram KenLM, width 25, alpha 0.5, and beta 1.0. Release metrics record all four configurations.

The LM also has limits. On the broader Ghana benchmark—28,990 utterances across 45 ISO codes—beam decoding improves overall WER from 67.22% to 59.29%, while CER worsens from 30.79% to 34.91%. Many evaluated languages are outside training coverage. Reporting both measures makes that trade-off visible; choosing only the better metric would hide it.

The Akan gap worth investigating

This is the result I most want to follow up:

Default lookahead with KenLM. Human-transcribed: 19,791 utterances. Machine-transcript: 3,581 utterances. Both axes start at zero and use the same scale.

The machine-transcript group’s WER is 30.83 percentage points higher. That gives the earlier phrase “substantially worse” a concrete meaning.

It does not tell us how much of the gap comes from label errors. The groups also differ in source, domain, and potentially recording conditions. Nor does it tell us how much retraining on corrected labels would recover. These are reported source-group results, not a controlled experiment.

The next useful step is to listen to samples from both groups, check the references, and classify the failures: transcription mistakes, spelling conventions, segmentation, or genuinely difficult audio. Then we can correct a measured subset and test whether the changes help. Counts, CER/WER, and source notes are available with the release.

From checkpoint to something you can run

Edge now includes file inference, a batch engine, and an optional persistent HTTP server. Long recordings are split into 30-second windows with 5-second overlap. Chunks from one or many inputs share acoustic batches; overlapping output frames are trimmed before decoding each recording.

The server waits up to 20 ms to collect requests when a worker becomes available, or starts sooner at eight requests. It processes a partial group when the timer expires. This collection delay is separate from the model’s lookahead and from queueing behind ongoing work.

We also tried native Flashlight decoding. In a matched capacity test of 128 thirty-second inputs—64 minutes of audio, batch 128—it reduced total compute time:

BF16 acoustic hardware / CPU decoder host	pyctcdecode	Flashlight	Speedup
Apple M5 Pro GPU / M5 Pro CPU, 6 Torch threads	10.524 s	5.056 s	2.08×
NVIDIA L4 / Modal host CPU, 4 allocated cores	26.127 s	13.321 s	1.96×

These are repeated synthetic English inputs, median of three warm runs, including preprocessing and decoding but excluding loading and file/HTTP I/O. They measure capacity, not accuracy. Flashlight uses a closed lexicon and changes transcripts; the accuracy scores above do not validate that faster preset. Host CPUs also differ, so compare decoders within each row.

Batch 8 was a better starting point for throughput in our sweeps than simply using the largest batch that fit. The full CPU/GPU/L4 sweeps and Flashlight report include the details, including batch-dependent CUDA BF16 transcripts.

Try it, then tell us where it fails

Start with the model card and quick start. The repository includes weights, the matching KenLM, batch inference, Docker setup, and source attributions. The release license is CC BY-NC-SA 4.0.