llama.cpp vypnul mapování modelu do paměti na části integrovaných grafik

Do 11. srpna 2026 načítal llama.cpp soubor s váhami pořád stejně: namapoval si ho do paměti a zbytek nechal na operačním systému. Sloučení návrhu #26081 toho dne přidalo k přepínači pro načítání šestou hodnotu auto a udělalo z ní výchozí nastavení. Auto mapuje, dokud některé ze zapojených zařízení neohlásí, že mapování nepodporuje. Hlásí to integrované grafiky pod CUDA, ROCm a Vulkanem, a k tomu bez výjimky celé backendy OpenCL a Hexagon.

Mapování do paměti, zkráceně mmap, je systémové volání, které soubor na disku propojí s adresním prostorem programu. Ten pak s váhami pracuje, jako by je měl celé v paměti, jenže ve skutečnosti se načítají po stránkách, teprve když na ně dojde. Systém je navíc smí z paměti kdykoli vyhodit, protože ví, odkud je vzít znovu.

Na integrované grafice leží model v paměti dvakrát

Integrovaná grafika vlastní paměť nemá a bere si ji ze systémové. Aby v ní mohla počítat, musí se váhy překopírovat do té části RAM, kterou vidí. U namapovaného souboru ale systém tytéž bajty drží ještě jednou jako stránky souboru. Autor návrhu to shrnuje tak, že model je během načítání v paměti dvakrát: dočasně to zdvojnásobí nároky a jakmile se přeteče, načítání se zpomalí.

O kolik, ukazuje hlášení #15018 z 1. srpna 2025. Jeho autor popisuje počítač HP Z2 Mini G1a s procesorem Ryzen AI MAX+ 395 (Strix Halo), 128 GB operační paměti a grafikou Radeon 8060S: každý model, který potřebuje víc než 64 GB, se začne načítat normálně a za hranicí 64 GB se načítání extrémně zpomalí. Přes Vulkan naběhl týž model bez potíží. Hlášení je z 1. srpna 2025, tedy víc než rok před touhle změnou.

Ještě konkrétnější čísla nese #26023, návrh, který se na totéž hlášení odvolává, sloučený ale nebyl a mířil na ně jinou cestou: nahrávání na grafiku vedl přes připnuté vyrovnávací paměti místo přímo z namapovaného souboru. Jeho autor na čipu gfx1151 zkoušel model o velikosti 82,36 GiB a s mapováním test vypršel po 600 sekundách na 34 %, kdežto jeho vlastní cesta model načetla za 40,54 sekundy. Je to měření jednoho člověka na jedné sestavě, ne nezávislý test.

Rozhoduje backend, ne to, jestli je paměť sdílená

Jestli se bude mapovat, neurčuje llama.cpp podle typu grafiky, ale podle nové vlastnosti mmap_support, kterou o sobě hlásí každý backend v souboru ggml-backend.h. Z patnácti backendů, které tu vlastnost v témž sloučení dostaly, jich jedenáct hlásí natvrdo, že mapování podporují: mimo jiné CPU, Metal, SYCL, OpenVINO, CANN a RPC. Dva ho natvrdo hlásí jako nepodporované, OpenCL a Hexagon. U zbylých dvou, tedy u CUDA a Vulkanu, závisí odpověď na tom, jestli je zařízení integrovaná grafika. Rozdělení jedenáct, dva a dva je vlastní součet z rozdílu toho sloučení.

V odůvodnění návrhu přitom stojí, že mapování bylo vypnuté jen u integrovaných grafik pod CUDA, ROCm a Vulkanem, protože ostatní backendy autor nezná dost dobře. OpenCL ani Hexagon tam zmíněné nejsou a mapování mají vypnuté u každého zařízení, integrovaného i samostatného.

Metal je opačný případ. Apple Silicon má paměť s procesorem také sdílenou, hlásí ale, že mapování podporuje, takže se na něm nemění nic. Pravidlo tedy nezní „sdílená paměť“, ale „co si o sobě backend napsal“.

Když je zařízení víc, rozhodne to první, které mapování odmítne: cyklus se na něm zastaví a vypne mapování pro celé načtení, i kdyby ostatní byly samostatné karty. Co nakonec vyšlo, se dá přečíst z výpisu při načítání. Od téhož sloučení do něj llama.cpp netiskne auto, ale rozhodnutý režim, tedy mmap, nebo none.

Ze čtyř přepínačů jeden se šesti hodnotami

Auto je poslední díl přestavby, která začala 23. července 2026 sloučením #20834. Přepínače --mmap, --no-mmap, --mlock a --direct-io nahradil jediný -lm, v delším tvaru --load-mode, který bere šest hodnot: auto, none, mmap, mlock, mmap+mlock a dio. Nastavit se dá i proměnnou prostředí LLAMA_ARG_LOAD_MODE. Důvodem bylo podle autora to, že se ty režimy navzájem vylučují a udržovat je odděleně začalo být složité. Sloučení sáhlo na 20 souborů, přidalo 315 řádků a 207 jich odebralo.

Staré přepínače fungují dál, jen každý při použití vypíše, že je zastaralý, a poradí náhradu. Sejde-li se starý a nový tvar na jedné příkazové řádce, llama.cpp upozorní, že se kombinovat nemají a že platí ten poslední. Kdy staré tvary zmizí docela, projekt neuvádí. V kódu u té kontroly stojí jen poznámka, že se má odstranit, až budou zrušené.

Zámek paměti znamená od konce července něco jiného

Jedna z těch náhrad totiž míří jinam, než mířil původní přepínač. Zámek paměti, tedy mlock, říká systému, že dané stránky nesmí odložit do odkládacího souboru ani je zkomprimovat. Do 23. července se --mlock přidával k mapování, které bylo ve výchozím stavu zapnuté, takže výsledkem bylo mapování a zámek zároveň. První sloučení tohle chování zachovalo a hodnota mlock znamenala totéž.

O čtyři dny později, 27. července, ji sloučení #26135 předefinovalo. Hodnota mlock od té doby zamyká váhy v paměti bez mapování a pro původní dvojkombinaci přibyla hodnota mmap+mlock. Zastaralý přepínač --mlock míří na tu novou, užší. Kdo ho má ve spouštěcím skriptu a chce staré chování, musí napsat --load-mode mmap+mlock.

Podnětem bylo hlášení #26110 z 25. července 2026. Jeho autor pouští model gpt-oss-120b ve formátu F16 o velikosti kolem 65 GB na sestavě s procesorem Ryzen 7 7700X a kartou GeForce RTX 5070 Ti se 16 GB paměti. Expertní tenzory směsi odborníků drží v operační paměti přepínačem --n-cpu-moe a potřebuje je zamknout, aby je systém pod dlouhou zátěží neodložil. Mapování zároveň nechce, protože soubor by v paměti ležel dvakrát. Po prvním sloučení se tahle kombinace nedala vyjádřit vůbec.

Dokumentace kód doháněla až 15. srpna, kdy sloučení #26934 přepsalo staré přepínače na --load-mode ve 21 souborech, od README serveru přes nápovědu nástrojů po skripty pro Snapdragon a SYCL. Kdo si llama.cpp staví ze zdrojů, pozná změnu nejdřív na řádku o načítání. Kdo ho dostává zabalený v jiném nástroji, nejspíš vůbec: podobně tiše přenastavila výchozí hodnotu Ollama u postihu za opakování.