q3146dq4/Supertonic-3-LiteRT-Static-MultiPreset-GELU

Supertonic-3 LiteRT Static MultiPreset GELU

FP32 LiteRT conversion of [Supertone/supertonic-3](https://huggingface.co/Supertone/supertonic-3) optimized around multiple pre-specialized static text/latent shapes.

The original Supertonic-3 ONNX graphs use dynamic text (T) and latent (L) dimensions.

This release instead provides a set of static T/L presets and selects the smallest fitting signature at runtime. This keeps most of the practical flexibility of dynamic shapes while allowing LiteRT/XNNPACK to execute pre-specialized fixed-shape graphs.

An exact GELU pattern fusion is also applied during conversion.

[!IMPORTANT] This model was converted directly from the official Supertone/supertonic-3 ONNX release. It is not a modification, quantization, extraction, or redistribution of soniqo/Supertonic-3-LiteRT.

Design

Why static multi-preset?

A single large fixed-shape LiteRT graph is simple to optimize, but wastes computation on short utterances.

For example, always executing T128/L128 would make a short T32/L32 sentence pay for a much larger graph than necessary.

This model therefore provides:

Text presets:
T = 32, 48, 64, 80, 96, 112, 128

Latent presets:
L = 32, 48, 64, 80, 96, 112, 128

The engine selects the smallest preset that can contain the actual input.

Example:

token_count = 53
valid_L     = 44

Duration Predictor : T64
Text Encoder       : T64
Vector Estimator   : T64_L48
Vocoder            : L48

Signature layout

Duration Predictor

7 signatures:

T32
T48
T64
T80
T96
T112
T128

Text Encoder

7 signatures:

T32
T48
T64
T80
T96
T112
T128

Vector Estimator

49 signatures:

7 text presets × 7 latent presets

Examples:

T32_L32
T32_L48
...
T64_L64
...
T128_L128

Vocoder

7 signatures:

L32
L48
L64
L80
L96
L112
L128

Bucket selection

The intended runtime selection rule is:

T = smallest_text_preset >= token_count

valid_L = ceil(
    predicted_duration_seconds * 44100 / 3072
)

L = smallest_latent_preset >= valid_L

Then invoke:

duration_predictor -> T{T}
text_encoder       -> T{T}
vector_estimator   -> T{T}_L{L}
vocoder            -> L{L}

multi_preset_manifest.json contains the preset layout, signature information and model checksums.

Model files

Total: approximately 417 MiB.

This is an FP32 release. No INT8, INT4 or FP16 quantization is applied.

Conversion

Official Supertone/supertonic-3 ONNX
                |
                v
        Fixed T/L specialization
                |
                v
   ONNX Runtime ORT_ENABLE_BASIC
                |
                v
          optimized ONNX
                |
                v
            onnx2torch
                |
                v
       exact GELU pattern fusion
                |
                v
           litert-torch
                |
                v
   FP32 multi-signature LiteRT/TFLite

Conversion environment:

Python          3.12
PyTorch         2.13.0+cpu
litert-torch    0.9.4
ai-edge-litert  2.2.0
onnx            1.21.0
onnxruntime     1.29.0
onnx2torch      1.5.15

Numerical parity

Every generated LiteRT signature was checked against its corresponding specialized ONNX reference.

Worst observed numerical errors:

These are very small floating-point differences and indicate close numerical parity with the specialized ONNX references.

Full results:

parity_report.json

CPU benchmark

Methodology

Three implementations were compared:

1. 1.Official Supertonic-3 FP32 ONNX
2. 2.Soniqo Supertonic-3 LiteRT
3. 3.This Static MultiPreset GELU LiteRT model

Benchmark configuration:

CPU threads : 8
Voice       : F1
Speed       : 1.05

Flow steps:
4 / 8 / 16 / 32 / 64

For every model × sentence-length case × step count:
1 warm-up run excluded
5 measured runs
median reported

Model/session initialization and WAV file writes are excluded from inference timing.

Execution order and sentence order were rotated during the benchmark to reduce systematic order/thermal bias.

These are PC/WSL CPU results, not Android ARM benchmark results.

Sentence-length AutoBucket sweep

The benchmark generated real sentence-length cases using the actual tokenizer and duration predictor.

The resulting New-model buckets were:

This confirms that the AutoBucket selector traverses the complete preset range rather than always falling back to a large signature.

Speedup vs official dynamic ONNX

Values below are median end-to-end synthesis speedups.

Across all 35 tested bucket/step combinations, this model was faster than the official dynamic ONNX CPU path.

Observed speedup range:

1.869x – 2.873x

Speedup vs Soniqo LiteRT

For Soniqo comparisons, short cases fit directly into its fixed T128/L64 execution shape.

Longer cases do not fit into L64 as a single utterance. For those cases, the benchmark harness split the input into the minimum number of T128/L64-compatible chunks and summed the complete DP + Text Encoder + Vector Estimator + Vocoder time.

This chunking policy is part of the benchmark harness and should not be interpreted as an official Soniqo runtime implementation.

Soniqo chunk counts in this sweep:

Median speedup:

The T64/L64 case is effectively at parity with Soniqo for several step counts.

This is expected: both models execute an L64 graph in that region, so the major latent-length reduction advantage disappears.

The larger buckets become more favorable once Soniqo requires multiple L64 chunks.

Example absolute timings

8-step median

Vector Estimator scaling

The Vector Estimator is the dominant repeated stage.

At 64 steps, median per-step execution scaled approximately as:

The monotonic scaling across the preset range is useful evidence that the static signatures are behaving as intended.

Initialization

The same Python benchmark measured model/session initialization separately:

Official ONNX : 1.756 s
Soniqo LiteRT : 1.957 s
This model    : 10.234 s

The larger startup cost is associated with the large multi-signature LiteRT model and the Python LiteRT/XNNPACK initialization path.

This is not included in the steady-state synthesis benchmark above.

The 10.23 s result should also not be treated as a universal or intrinsic startup time for this model. Runtime implementation details can significantly affect multi-subgraph initialization.

For Android applications, a custom runtime can potentially reduce startup overhead by lazily preparing only the selected T/L signature instead of eagerly preparing unused subgraphs. Such a runtime optimization is separate from the model files in this repository and is not benchmarked here yet.

Maximum single-call size

The largest included preset is:

T128 / L128

With:

sample rate                = 44100 Hz
samples per latent frame   = 3072

L128 corresponds to approximately:

128 × 3072 / 44100 ≈ 8.92 seconds

of latent capacity.

Inputs exceeding T128 or L128 should be split by the application/engine.

Quality and parity notes

This release is FP32 and is intended to preserve the upstream model rather than reduce precision.

The graph-level parity results are the primary conversion-correctness check.

Do not interpret raw sample-by-sample waveform correlation between different T/L execution shapes as a direct speech-quality score.

Different static shapes can introduce very small floating-point differences into the iterative Vector Estimator trajectory, and those differences may accumulate over many flow steps even when the resulting speech remains perceptually equivalent.

For end-to-end evaluation:

1. 1.use parity_report.json for graph-level conversion correctness;
2. 2.listen to generated WAV output;
3. 3.use perceptually relevant/aligned spectral metrics if automated audio comparison is required.

Metadata files

Recommended to keep:

multi_preset_manifest.json
parity_report.json

multi_preset_manifest.json documents the available signatures and bucket-selection policy.

parity_report.json contains numerical conversion validation.

build_checkpoint_v7.json is only an exporter/resume artifact and is not required for runtime or distribution.

Supported languages

Language support is inherited from upstream Supertonic-3:

Limitations

• —FP32 only; this release is not designed primarily for model-size reduction.
• —Larger file size than a single-shape LiteRT export.
• —Higher eager initialization cost in the tested Python LiteRT runtime.
• —Maximum included text preset is T128.
• —Maximum included latent preset is L128.
• —Inputs beyond those limits require application-level chunking.
• —Some T/L combinations may provide only a small performance advantage over a well-optimized fixed-shape LiteRT graph.
• —CPU performance depends on LiteRT/XNNPACK version, thread count, CPU architecture, affinity, thermal state and runtime initialization policy.
• —The published benchmark is a PC/WSL CPU benchmark and is not a substitute for Android ARM device measurements.

Upstream model

This repository changes the deployment representation of Supertonic-3, not its training data or fundamental TTS capabilities.

For upstream model details, language support, voice styles and original usage documentation:

Supertone/supertonic-3

https://huggingface.co/Supertone/supertonic-3

License

The converted model is derived from Supertone/supertonic-3.

The upstream model is released under the OpenRAIL-M License.

Use and redistribution of this converted model are subject to the applicable upstream model license terms.

See the upstream LICENSE for complete terms.

Credits

• —Supertone Inc. — original Supertonic-3 model
• —Google AI Edge / LiteRT
• —XNNPACK
• —ONNX Runtime
• —onnx2torch

Static T/L specialization, multi-signature export, exact GELU fusion, parity validation, AutoBucket selection and the benchmark harness for this repository were implemented independently using the official Supertonic-3 ONNX release as the source.