Ollama 0.32.15 přestala číst metadata GGUF při každém dotazu
Server Ollamy otevíral soubor GGUF a četl z něj metadata při každém dotazu na chat i generování; autor změny odhaduje tu režii na 300 ms za volání. Verze 0.32.15 z 19. srpna 2026 si výsledek pamatuje, dokud se nezmění otisk manifestu. V přiloženém měření klesl medián čekání na první token z 551,72 na 283,88 ms.
Když pošlete Ollamě dotaz na chat, server si napřed musí zjistit, s čím pracuje: kde leží váhy, jakou má model šablonu chatu a co všechno umí. Dělal to pokaždé znovu. Verze 0.32.15 z 19. srpna 2026 si výsledek nechává v paměti a poznámky k vydání u toho slibují zkrácení čekání na první token zhruba na polovinu.
Tentýž soubor se otevíral dvakrát za dotaz
Práci obstarává funkce GetModel v souboru server/images.go. Rozebere manifest modelu, načte z blobu konfiguraci a u modelu ve formátu GGUF otevře i samotný soubor vah, aby si z jeho metadat přečetla dvě položky – šablonu chatu (tokenizer.chat_template) a typ sdružování (pooling_type).
Do minulého vydání volala tuhle funkci nejdřív obsluha dotazu na /api/chat nebo /api/generate a pak ještě jednou plánovač běhu scheduleRunner. Soubor vah se tak otevřel v jednom dotazu dvakrát. Autor návrhu změny #17752 tu režii odhaduje na zhruba 300 ms na každé volání; je to jeho vlastní údaj a nikdo jiný ho nezopakoval.
Nový soubor server/model_inference_cache.go má 121 řádků a drží hotová metadata pod klíčem složeným ze jména modelu a z nastavení proměnné pro šablonu. Čerstvost hlídá otisk manifestu: ten se čte při každém dotazu dál, protože je levný, ale soubor vah se už neotvírá. Komentář v kódu to shrnuje tak, že bloby jsou adresované obsahem, takže záznam platí, dokud se model nevytvoří znovu nebo nestáhne s jiným obsahem (přeloženo). Souběžné dotazy na dosud nenačtený model se slévají do jednoho načtení a každá obsluha dostane vlastní kopii, aby si záznam ve sdílené paměti nepřepsala.
Odkud je to číslo o polovině
Měřil ho sám autor změny; podle svého veřejného profilu na GitHubu pracuje na výkonu grafických karet v NVIDII. Použil nástroj aiperf a sadu SPEED-Bench, konkrétně její programátorskou část. Ta má podle dokumentace nástroje 80 zadání; měření z nich vzalo prvních deset a pouštělo je po jednom. Model byl qwen3.6:35b-a3b-mtp-q4_K_M a adresář s výsledky si autor pojmenoval speed-bench-smoke, tedy jako zkoušku.
Průměrné čekání na první token kleslo z 994,79 na 524,15 ms, tedy o 47,3 %. Poznámky k vydání z toho udělaly zaokrouhlených 995 a 524 ms.
Medián sedí s odhadem líp než průměr
V obou tabulkách je ale i medián a ten spadl z 551,72 na 283,88 ms, o 267,84 ms a 48,5 %. Polovina tedy vyjde tak i tak, což se u deseti dotazů dalo čekat těžko: směrodatná odchylka je 1 169 ms u prvního kola a 585 ms u druhého, v obou případech tedy větší než samotný rozdíl. Nejdelší čekání se zkrátilo ze 4 451 na 2 135 ms.
Zajímavější je jiná věc. Úspora měřená mediánem odpovídá odhadovaným 300 ms režie skoro přesně, kdežto průměrný rozdíl 470,64 ms je o polovinu větší. Vysvětlení stojí v tabulce o pár řádků níž: obě kola nedostala stejnou zátěž. Průměrná délka vstupu byla 1 337,90 tokenu v prvním kole a 832,30 ve druhém, průměrná délka odpovědi 4 273 a 3 584 tokenů. Kratší vstup znamená kratší přípravu, takže část průměrného rozdílu nedělá vyrovnávací paměť, ale zadání. Medián vstupu je přitom v obou kolech shodných 143 tokenů, a to je z té tabulky nejpoctivější dvojice čísel.
Co z toho má, kdo si model pouští doma
Úspora se projeví od druhého dotazu na tentýž model, ne u prvního. Načítání vah do paměti karty se změna netýká vůbec – to je ta pauza, kterou znáte po ollama run, a ta zůstává. Nejvíc z ní má ten, kdo posílá dotazy na běžící server často a po malých dávkách; medián vstupu byl v měření 143 tokenů, tedy krátké zadání, u kterého se čtvrt vteřiny navíc pozná.
Paměť samotná nemá v kódu žádný strop ani vypršení. Drží jeden záznam na jméno modelu po celou dobu běhu serveru a zahodí ho, teprve když se změní otisk manifestu, tedy po ollama pull nebo ollama create. Pro domácí instalaci s hrstkou modelů to nic neznamená: v záznamu jsou cesty, volby a text licence, ne váhy.
Zbytek vydání je drobnější. První spuštění desktopové aplikace provede úvodním nastavením, chat a generování se už nezaseknou po chybě rozboru uprostřed proudu, systémové zprávy Qwenu 3.8 se srovnávají na jeden tvar a vnitřní kopie llama.cpp a MLX se posunuly na novější verze. O rychlosti Ollamy jsme psali u spekulativního dekódování DFlash, kde se zrychlení lišilo podle druhu textu.
Zatím se měřilo jednou, jedním člověkem a na deseti dotazech. Kdo si chce ověřit, jestli se mu ta čtvrt vteřiny vrátí i na jeho modelu, najde postup i přesné parametry vypsané přímo v návrhu změny.