Kokoro-G2P-en-US

Kokoro G2P (en-US) — LiteRT (preview)

⚠️ Labeled preview — fixed-length [1, 96], FP32, CPU. Shared to complete the on-device Kokoro front-end per the LiteRT community direction ③.

A LiteRT (.tflite) conversion of DeepPhonemizer en_us_cmudict_forward (a small non-autoregressive forward Transformer), used as the neural grapheme-to-phoneme (G2P) front-end for on-device Kokoro-82M TTS. It gives Kokoro a phonemizer fallback so arbitrary free text — names, brands, numbers — synthesizes with zero dropped words when the dictionary phonemizer misses.

Files

Specs

How it was converted / why CPU

• Stock official converter (litert_torch), static-shape graph: the dynamic-length export hits the same symbolic-sequence-length wall as the TTS model (Shapes must be 1D sequences of concrete values…) — the dynamic-shape converter class. Worked around with a static [1, 96] graph + an in-graph padding mask; converts cleanly and is numerically correct.
• CPU-only: the attention's fused-QKV 5-D layout + the mask's EQUAL / SELECT_V2 keep it off the GPU delegate; decomposing the attention to ≤ 4-D would clear that.

Training data

DeepPhonemizer en_us_cmudict_forward is trained on the CMU Pronouncing Dictionary (CMUdict) — ~126k common English words paired with ARPABET pronunciations (a public pronunciation lexicon). It learns the grapheme→phoneme spelling-to-sound mapping only. This LiteRT artifact is a format conversion of the released checkpoint and introduces no additional training data.

PII

No personally identifiable information. CMUdict is a public dictionary of common English word pronunciations (no personal data); none is added during conversion.

Roadmap

• Variable-length + quantized + (ideally) GPU is gated on the dynamic-shape converter work and a ≤ 4-D attention re-author.

Status

Labeled preview — part of an on-device free-text Kokoro-82M LiteRT pipeline; the official litert-samples text_to_speech sample is in review at google-ai-edge/litert-samples #159.

Performance

Measured on an Apple M4 Max, CPU/XNNPACK at 8 threads, ai-edge-litert 2.1.6 — median of 15 warm runs per graph, with zero-filled inputs of each graph's declared static shape. Run-to-run spread stayed within 5%.

One call converts a padded 96-character window into per-position phoneme logits, so grapheme-to-phoneme conversion is a rounding error next to the acoustic model and vocoder it feeds.

Android (Pixel 8a)

Android figures use the standard TFLite benchmark_model on a Pixel 8a (Tensor G3, Android 16) — 5 warm-up runs then 20 timed runs, CPU at 4 threads.

1 of these graphs do not load on the OpenCL delegate at all, so the CPU column is the only Android number for them. Nothing here is faster on the GPU; run this pipeline on the CPU on Android.

Snapdragon NPU (Hexagon)

The GPU delegate declines this graph on the S26: LiteRtException: Failed to compile model. The NPU runs it at 2.03 ms. That makes the NPU the first Android accelerator to run this graph — the Pixel 8a rows above have it declining on the OpenCL delegate too.

Measured on a Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81, Android 16), LiteRT CompiledModel 2.2.0, one accelerator per process, 5 warm-up runs then N=50 timed runs, median reported. The run held thermal status NONE throughout. Headroom 0.68, where 1.0 is the throttling threshold.

The NPU rows here ran artifacts compiled ahead of time for SM8850 with QAIRT 2.47.0. LiteRT can also compile for the NPU on the device at first load, which is what lets you ship the published file unchanged — that path and the ten runtime libraries it needs are in the NPU recipe, and we did not measure it here. GPU wiring is in the GPU recipe.

Raspberry Pi 5 (CPU)

Measured on a Raspberry Pi 5 Model B Rev 1.1 (8 GB, Raspberry Pi OS 64-bit) with the LiteRT benchmark_model tool from litert-cli-nightly 0.2.0.dev20260805: CPU inference (XNNPACK, 4 threads), 3 invocations per file of 10 warm-up plus 50 timed runs (the tool caps a phase at 150 s, so very slow graphs run fewer — the Runs column is the actual timed total). The latency is the median across invocations; the spread is the min–max over all timed runs. No thermal throttling occurred during these runs (vcgencmd get_throttled stayed 0x0).

License

MIT. Full attribution to DeepPhonemizer and the en_us_cmudict_forward checkpoint.