Laguna S 2.1 uvádí milion tokenů kontextu, vlastní GGUF od výrobce má 256 tisíc

Firma poolside vydala 21. července model Laguna S 2.1. Je to směs expertů (Mixture of Experts): ze 118 miliard parametrů se na každý token použije jen zhruba 8 miliard, protože směrovač vybere deset z 256 expertů a k nim jeden sdílený. Váhy jsou ke stažení na Hugging Face pod licencí OpenMDW 1.1.

V přehledu vlastností stojí na prvním místě kontextové okno 1 048 576 tokenů, tedy zhruba milion. Kdo si model chce pustit na vlastním stroji, sáhne po formátu GGUF, se kterým pracuje llama.cpp. A právě tam poolside uvádí jiné číslo.

V kartě modelu milion, v repozitáři s GGUF čtvrtina

Popis balíčků GGUF od téhož výrobce říká, že jsou nastavené na okno 262 144 tokenů, a dodává, že je to nastavení doporučené pro nejlepší kvalitu výstupu. Váhy samotné podle něj milion zvládají: trénink prý zahrnoval fázi prodlužování kontextu až na 1 048 576 tokenů.

Delší okno se dá zapnout, jen se musí při načtení přepsat nastavení rotačních pozic:

--ctx-size 1048576 --rope-scaling yarn --rope-scale 128 --yarn-orig-ctx 8192

K tomu poolside připojuje varování, že s milionovým nastavením se kvalita může zhoršit, a doporučuje k němu jiné hodnoty vzorkování. Rozpor tedy není mezi dvěma weby, ale uvnitř jednoho výrobce: na kartě modelu i na blogu je milion bez výhrady, v repozitáři s balíčky je výchozí čtvrtina a výhrada navíc.

Že to není překlep, ukazuje i cizí vydání. Skupina Unsloth, která k modelu vydala vlastní kvantizace, si 27. července opravila metadata právě na 256 tisíc a v popisu té změny se odvolala na konfiguraci od poolside. Balíčky přitom nahrála pět dní předtím.

Kolik paměti si vezme samotný kontext

Nároky na paměť nekončí u vah. Model si během běhu drží klíče a hodnoty pozornosti pro každý dosud zpracovaný token, takzvanou KV cache, a ta roste s délkou kontextu. Spočítat se dá ze souboru config.json, který výrobce zveřejnil spolu s váhami.

Model má 48 vrstev, 8 klíčových hlav a rozměr hlavy 128. Na jednu vrstvu a jeden token tedy připadá 8 × 128 čísel pro klíče a tolikéž pro hodnoty; v obvyklém šestnáctibitovém formátu to dělá 4 096 bajtů, tedy 4 KiB. Kdyby celý kontext držely všechny vrstvy, vyšla by cache při milionu tokenů na 192 GiB, což je víc než samotné váhy.

Tolik to není, protože Laguna střídá dva druhy vrstev. Celý kontext vidí jen dvanáct z nich; zbylých 36 pracuje s posuvným oknem 512 tokenů, takže si drží jen posledních pět set. Výsledek je tenhle:

• 12 vrstev s plným dosahem × 4 KiB × 1 048 576 tokenů = 48 GiB;
• 36 vrstev s oknem 512 tokenů = dohromady 72 MiB, tedy zaokrouhlovací chyba;
• při doporučených 262 144 tokenech vychází totéž na 12 GiB.

Poměr jedna ku třem mezi oběma druhy vrstev tedy není detail architektury, ale ten důvod, proč se milionové okno vejde do stroje, který by jinak potřeboval čtyřnásobek. Jde o pokračování téhož směru jako u sdílení klíčových hlav: obojí zmenšuje cache, ne model.

Váhy začínají na 31 GiB

Nekvantizované váhy mají 219 GiB, tedy 235 GB. Sám poolside k nim nabízí dvě zmenšené podoby: Q8_0 se 119,91 GiB a Q4_K_M s 89,44 GiB. Unsloth jde níž, jeho nejmenší jednobitová varianta má 31,45 GiB. Stejnou cestou vznikla i jednobitová podoba Kimi K3, jen ta zůstala i po zmenšení nad půl terabajtu. Podpora architektury je podle Unslothu v llama.cpp od vydání b10087.

Zaokrouhlené číslo v návodu Unslothu přitom nesedí: u varianty UD-Q4_K_XL slibuje ke stažení asi 40 GB ve třech souborech, jenže ty tři soubory mají 3,68 MB, 50 GB a 23,4 GB, dohromady 73,4 GB. Čtyřicítce odpovídá spíš dvoubitová UD-Q2_K_XL, která má 39,7 GB.

Pro toho, kdo počítá paměť dopředu, z toho plyne jedna praktická věc: obě položky se musí sečíst zvlášť a na té druhé záleží víc, než se zdá. Při plném milionovém okně je cache s 48 GiB větší než jednobitové váhy s 31,45 GiB. Snížit ji jde ještě jinak než zkrácením kontextu – llama.cpp umí cache samu ukládat v menším formátu –, jenže to je další zásah do přesnosti a my jsme ho neměřili.

Zdroje: oznámení poolside, karta modelu a repozitář s GGUF na Hugging Face, kvantizace od Unslothu. Velikosti souborů a údaje o architektuře pocházejí z rozhraní Hugging Face a ze souboru config.json; přepočet paměti je náš.