MOSS-TTS-v1.5 — GGUF for audio.cpp
Self-contained GGUF packages of OpenMOSS-Team/MOSS-TTS-v1.5, for audio.cpp. Each file carries the 8B delay-pattern backbone, the MOSS-Audio-Tokenizer v1 codec (both encoder and decoder, because cloning needs the encoder), the tokenizer and the model spec — nothing else to download.
| file | backbone | codec | size | transcript accuracy |
|---|---|---|---|---|
moss_tts_v15_bf16_codec_f16.gguf | bf16 | f16 | 20.5 GB | exact |
moss_tts_v15_q8_0_codec_f16.gguf | q8_0 | f16 | 13.2 GB | 4/4 takes exact, WER 0.000 |
moss_tts_v15_q4_k_codec_f16.gguf | q4_k | f16 | 9.3 GB | 3/4 takes exact, WER 0.021 |
On q4_k
q4_k is usable and clones as well as the others — but it is not lossless on the words. Across four takes of the same sentence at different seeds, one substituted an article ("the" for "this"); q8_0 was exact on all four. Two independent ASR models agree on that substitution, so it is the audio and not a transcription artifact.
Four takes of one sentence is a small sample and the true rate is not pinned down by it. Treat q4_k as the option for when 9.3 GB versus 13.2 GB decides whether the model runs at all, and prefer q8_0 when it fits.
All three clone the reference equally well — median F0 180.8, 194.4 and 185.1 Hz against the reference recording's 189.4 — so the loss shows up in wording, not in the voice.
The codec is left at f16 in every package: it is a small share of the total and it is what turns codes back into a waveform, so quantising it buys little and risks the part you actually hear.
Performance and VRAM
Measured on an RTX 3090 (24 GiB) with audio.cpp at 0xShug0/audio.cpp#674 or later. Peak VRAM is the process's own allocation. RTF is session time over output duration, so it leaves out the load. Loading a 9–20 GB package is seconds to tens of seconds of disk I/O, and that would swamp the actual work.
| package | peak VRAM, plain TTS | peak VRAM, cloning | RTF, cloning (CUDA) |
|---|---|---|---|
| q4_k | 7.3 GiB | 9.0 GiB | 0.30–0.37 |
| q8_0 | 10.9 GiB | 12.6 GiB | 0.39–0.40 |
| bf16 | 17.6 GiB | 19.3 GiB | 0.58–0.60 |
Every package clones on a 24 GiB card, bf16 included. As a rough guide, cloning fits in 12 GB with q4_k, in 16 GB with q8_0, and in 24 GB with bf16, with room left for a desktop. The RTF figures are a range over three or more runs on a desktop GPU that was in use at the time, so read them as a band rather than a single number.
Use a recent audio.cpp for bf16. Before #674, audio.cpp loaded the codec at
f32 on the GPU even though these packages store it at f16. That doubled its
footprint: 1.65 GiB more for plain TTS and 3.3 GiB more for cloning, because
cloning holds both the encoder and the decoder. On those builds, bf16 cloning
fails on a 24 GiB card while allocating moss.audio_tokenizer.encoder. Since #674
the codec runs at f16 on CUDA, Vulkan and Metal, and the KV cache is f16 as well.
Keep weight_type at its default (native). Forcing bf16 dequantises a
quantised package on load, so it costs as much memory as bf16 and the
quantisation buys nothing. For plain TTS, q4_k forced to bf16 peaks at 17.6 GiB,
exactly what the bf16 package peaks at, against 7.3 GiB left native.
On CPU the same work is roughly 25x slower than on CUDA and well short of real time, so a GPU is what makes this model practical.
Usage
# Voice cloning from a short reference recording
audiocpp_cli --family moss_tts_v15 --model <dir-containing-the-gguf> --task clon \
--voice-ref reference.wav \
--text "This sentence should be spoken in the voice from the reference recording." \
--out out.wav
# Plain TTS, voice chosen by the model
audiocpp_cli --family moss_tts_v15 --model <dir-containing-the-gguf> --task tts \
--text "The quick brown fox jumps over the lazy dog." --out out.wav
The reference recording is resampled and downmixed to the codec's 24 kHz mono automatically, so any sample rate and channel count will do.
--tokens <n> sets a duration budget in codec frames at 12.5 a second — the
model's own - Tokens: field, and it is honoured: 40 tokens produces about 3.2
seconds.
⚠ Voice-attribute instructions are not reliably followed
--instruct is accepted, but a description of the speaker is followed only
loosely. Four prompts differing only in the requested speaker, median F0 of the
result, measured on the reference implementation:
"A high-pitched young woman's voice, clearly female." -> 216.3 Hz plausible
"A woman speaking softly and warmly." -> 184.5 Hz borderline
"A man speaking in a low register." -> 187.8 Hz miss
"A very deep, low-pitched man's voice." -> 180.8 Hz clear miss
Five samples with median F0 as a proxy for perceived voice is not a rigorous evaluation, and one of the four was plausible — so read this as "unreliable", not "never works". But a "very deep, low-pitched man's voice" at 181 Hz is wrong by any measure.
Use a reference recording when the voice matters. Cloning does work: a clone of a 189.4 Hz reference came back at 184.0 Hz, where the same model without a reference produced 117.3 Hz. For a voice built from a written description rather than a recording, MOSS-VoiceGenerator is the model designed for it.
What works
Cloning, Chinese from an English instruction, long-form (20.4 s from four sentences, and the real-time factor improves with length as the fixed prompt cost is amortised), and the duration budget.
Provenance
Converted with audiocpp_gguf from the upstream safetensors:
audiocpp_gguf \
--input model_weights=<root>/model.safetensors.index.json \
--input audio_tokenizer_weights=<root>/audio_tokenizer/model.safetensors.index.json \
--output moss_tts_v15_<type>_codec_f16.gguf \
--type <type> --keep-type "audio_tokenizer_weights*=f16" \
--family moss_tts_v15 --root <root>
Each package was verified by synthesising from it and transcribing the result, not merely by loading it. Licensed Apache-2.0, following both upstream repositories.