Projekt llama.cpp přestal převádět pět vah Qwen3-TTS 0,6B na 16 bitů

Projekt llama.cpp dostal 2. září opravu dvou příčin, kvůli kterým menší Qwen3-TTS v převodu do GGUF nefungoval. První zastavila už načtení pomocného souboru mmproj. Program v něm povinně hledal vstupní projekci prediktoru kódů, jenže model o velikosti 0,6 miliardy parametrů ji vůbec nemá.

V oficiální implementaci Qwen3-TTS se projekční vrstva vytvoří jen tehdy, když má prediktor jinou skrytou velikost než hlavní část generátoru řeči. Jsou-li obě velikosti stejné, kód dosadí identitu, tedy vstup nechá beze změny. Chybějící váha proto není poškozený model. Načítací část llama.cpp ji od sestavení b10760 považuje za nepovinnou.

Mezivýsledek byl více než dvakrát nad limitem F16

Po odstranění první překážky se model zastavil hned při prvním zvukovém rámci. Autor opravy naměřil v prediktoru kódů špičku 145 109 v referenční implementaci a 145 396 ve výpočetním grafu llama.cpp. Nejvyšší konečná hodnota šestnáctibitového formátu F16 je 65 504. Větší z naměřených hodnot je tedy 2,22krát vyšší; jde o vlastní výpočet z čísel uvedených v návrhu změny.

Násobení v llama.cpp převádí vstup na stejný datový typ, jaký mají příslušné váhy. Když převodník uložil snižovací matice pěti bloků dopředné sítě ve F16, špička se změnila na nekonečno. Následující normalizace z ní udělala NaN, hodnotu „není číslo“, a výpočet nakonec sáhl mimo povolený rozsah.

Převodní skript proto pět matic s názvem končícím ffn_down.weight nově ponechá ve F32. Podle autora změny tím pomocný soubor naroste asi o 31 MB. Zkouška na procesoru a přes CUDA po úpravě dokončila krátké i delší ukázky pro varianty 0,6B a 1,7B. Větší model stejnou výjimku nepotřebuje: jeho mezivýsledky mají podle měření více než šestinásobnou rezervu pod stropem F16. Převodník přesto zachází s celou rodinou stejně, aby její soubory neměly dva odlišné formáty.

Aktualizace programu starý soubor neopraví

Část změny v načítání se projeví po instalaci nového sestavení llama.cpp. Přesnost pěti vah se ale určuje při převodu modelu. Kdo už má pomocný mmproj ve formátu GGUF vytvořený starším skriptem, musí jej vygenerovat znovu; jinak v něm zůstanou matice F16 a výpočet malého modelu se rozbije stejně jako před aktualizací.

Samotné váhy generátoru a pomocný soubor mají rozdílné úkoly. Hlavní GGUF nese jazykovou část, zatímco mmproj obsahuje generátor zvukových kódů a převod kódů na zvuk. Právě do druhého souboru patří opravených pět matic. Oficiální repozitář Qwen3-TTS uvádí modely 0,6B a 1,7B pro vlastní hlasy i klonování hlasu a doporučuje pro běžný lokální provoz vlastní balíček qwen-tts. Podpora v llama.cpp je jiná cesta, určená pro převedené soubory GGUF.

Vulkan čeká na druhou opravu

Sestavení b10760 řeší procesor a CUDA, nikoli samostatný pád přes Vulkan. Tam operace GET_ROWS odmítala index, který začínal několik bajtů od zarovnané hranice. První návrh obcházel omezení třemi kopiemi drobných tenzorů, správci jej však zavřeli bez sloučení: chtějí opravit obecnou podporu nezarovnaných pohledů přímo ve vrstvě Vulkanu.

Náhradní návrh číslo 28253 posune popisovač paměti na vhodnou hranici a zbytek předá shaderu. Zároveň doplňuje testy pro F32, F16, několik kvantizací a celočíselné indexy. Autor původní opravy jej 2. září vyzkoušel na obou velikostech Qwen3-TTS a schválil; výstup na procesoru a přes Vulkan byl podle něj shodný bit po bitu. V době psaní je ale návrh stále otevřený a do sestavení b10760 ani b10764 nepatří.

Praktický výsledek má tři podmínky: nové llama.cpp, znovu převedený pomocný soubor a prozatím procesor nebo CUDA. Kdo používá Vulkan, může sledovat druhý návrh, ale hotovou podporu z něj zatím dělat nelze.

Zdroje

• llama.cpp: oprava načítání a přetečení Qwen3-TTS 0,6B – sloučený návrh se změnou i měřením
• Oficiální repozitář Qwen3-TTS – popis řady, velikostí modelů a lokálního provozu
• Referenční implementace Qwen3-TTS – podmínka pro vytvoření vstupní projekce
• llama.cpp: obecná oprava nezarovnané operace GET_ROWS ve Vulkanu – otevřený navazující návrh