A faithful decoder can still be the slower pipeline
The complete community 6-bit MLX route had a 1.359-second warm median and RTF 0.225. The ordinary CoreML/ONNX Python adapter measured 4.974 seconds and RTF 0.749. Their payloads were 0.524 and 3.331 GiB respectively, with process RSS peaks of 1.181 and 4.963…
Key finding
The community MLX pipeline was faster in this Python comparison; a controlled decoder diagnostic favored the other acoustic route.
Edited finding from the pinned experiment record. The report and figure metadata preserve the original workload and limits.
The boundary
Apple M5, three sentences, one voice. This is a Python CoreML/ONNX adapter comparison, not a native Swift or proven ANE benchmark.
Data
Reviewed aggregate results with explicit units, sources and qualification limits. Different cohorts remain separate.
The complete Python adapter was slower
M5 · battery · three sentences · same reported comparison
- Community 6-bit MLX1.359
- CoreML/ONNX adapter4.974
warm median seconds
Not a native Swift or proven ANE result. Controlled-noise decoder diagnostics are a separate cohort.
View data & source
| Configuration | Value |
|---|---|
| Community 6-bit MLX | 1.359 |
| CoreML/ONNX adapter | 4.974 |
Origin: reviewed report table. Revision 7e6fdbe3b1d1.
Write-ups
Report chatterbox-fidelity/community6-vs-coreml-2026-10-10/README.md
Two different questions
The complete community 6-bit MLX route had a 1.359-second warm median and RTF 0.225. The ordinary CoreML/ONNX Python adapter measured 4.974 seconds and RTF 0.749. Their payloads were 0.524 and 3.331 GiB respectively, with process RSS peaks of 1.181 and 4.963 GiB.
The diagnostic did not rank the application
In a separate controlled-noise experiment, the alternative decoder stayed much closer to the original waveform: log-mel difference around 0.141 dB versus 1.308, and waveform cosine 0.997428 versus 0.795194. That diagnostic altered randomness in four outputs; it is not a shipping whole-pipeline result.
Complete-generation voice cosine was nearly tied around 0.966 and 0.965. Small ASR counts, an imperfect evaluator and three sentences cannot settle perceived quality.
What comes next
Keep MLX for the tested speed requirement, then test the proposed decoder swap directly. Published headline speedups on another machine and another token budget cannot be compared as if they measured this workload.
Evidence and publication boundary
This is an edited account of the recorded experiment. The linked archive is private; the methods, aggregate findings and limits are included above. Reference recordings, raw conversations, authentication material and workstation configuration are excluded.
More in Speech & codecs
MOSS on a 3090: Q2 failed, AWQ4 stayed closer
Every profile began with the pinned BF16 generator. The comparison reused fixed reference codes and an FP32 decoder for the main quality measurements, keeping codec changes separate from generator quantization.
AWQ4 stayed close to the BF16 reference on WavLM and character errors; the sensitivity Q2 candidate was rejected.
Drama3: BF16 decoded the same codes about three times faster
The experiment replayed saved Spanish and English codes representing 21.5481 and 15.8824 seconds of audio. It compared FP32, BF16, mixed BF16 and two INT8 decoder variants on one RTX 3090.
BF16 reduced median decoder time from 390.07 to 129.54 ms in Spanish and from 292.42 to 96.88 ms in English.
Keeping FP32 and moving Supertonic to Triton
Rather than reduce the CPU graph precision again, this follow-up used NVIDIA Triton’s ONNX backend with CUDA execution and the unchanged FP32 graphs. The paired comparison retained both speed and acoustic checks.
The paired GPU test cut median first-audio time to about 0.35 seconds while preserving the measured ASR results.