anayak16/kokoro-coreml-int8

Kokoro-82M for Core ML, int8 weights

The mattmireles/kokoro-coreml staged export of hexgrad/Kokoro-82M, with its weights compressed from float16 to 8-bit. Same stages, same bucket layout, same inputs and outputs — only smaller.

	float16	this repo
distinct weight bytes	205 MB	110 MB
compiled on device	578 MB	326 MB

What changed

Post-training weight quantization with coremltools.optimize.coreml.linear_quantize_weights (coremltools 9.0, mode="linear_symmetric", dtype=int8, granularity="per_channel") applied to the published float16 .mlpackage files. No re-export from PyTorch, so the graphs are byte-for-byte the upstream ones apart from the weight encoding. Core ML expands the weights back to float16 when the model loads, so nothing about how you call these models changes.

Three groups of weights are deliberately left in float, selected by operation type and shape so that every bucket variant is treated identically:

• the generator's two conv_transpose upsamplers — no published 8-bit Kokoro quantizes these, because onnxruntime structurally cannot, so there is no evidence either way and they are cheap to keep;
• the generator's final convolution (conv_post, shape 22×128×7) — the one layer independent reports agree adds audible static when quantized, and it is about 20 KB;
• the prosody stage's LSTM weights, the only float32 tensors in the upstream export.

Bucket variants of a stage still share byte-identical weight files after quantization, so a consumer that de-duplicates identical weights keeps that saving.

Quality

Judged against the float16 export it was built from, not against PyTorch:

• prosody and decoder stages agree at cosine ≥ 0.9999;
• the duration model shifts about 1% of phonemes by one 12.5 ms frame — 0.025 s across 13.1 s of speech;
• in a blind A/B over the passages where spectral measurements showed the largest difference, a listener did not identify the quantized renders as worse, and picked one as "livelier".

The renders are not sample-identical to float16 and are not meant to be. Timing moves by tens of milliseconds on some phonemes.

Using it

The stages take phonemes, not text: bring your own G2P (misaki, or MisakiSwift on Apple platforms). runtime/kokoro-vocab.json maps phoneme characters to token ids and runtime/hnsf_weights.json carries the harmonic-source weights. The pipeline that drives these stages is mattmireles/kokoro-coreml's KokoroPipeline; the stage split, the buckets and the tensor contract are all upstream's.

manifest.json lists every file with its SHA-256 and byte count, for pinning.

Credits and licence

Apache-2.0, inherited. In order: hexgrad trained and released Kokoro-82M; yl4579 authored the StyleTTS 2 architecture it builds on; mattmireles did the Core ML conversion and the staged export this repo compresses; the voice files are hexgrad's, repacked by onnx-community. This repo adds the quantization and nothing else. Not affiliated with or endorsed by any of them, or by Apple.

Kokoro-82M was trained on permissive and non-copyrighted audio. Its card records these Creative Commons Attribution sources, reproduced here as its licence asks:

Source	Duration	Licence
Koniwa tnc	<1h	CC BY 3.0
SIWIS	<11h	CC BY 4.0