MOSS-TTS-v1.5-GGUF

Self-contained GGUF packages of [OpenMOSS-Team/MOSS-TTS-v1.5](https://huggingface.co/OpenMOSS-Team/MOSS-TTS-v1.5), for [audio.cpp](https://github.com/0xShug0/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. 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. Measured on an RTX 3090 (24 GiB) with audio.cpp at [0xShug0/audio.cpp#674](https://github.com/0xShug0/audio.cpp/pull/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. 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. 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 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. `--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](https://huggingface.co/OpenMOSS-Team/MOSS-VoiceGenerator) is the model designed for it. 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. 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.