Nanbeige 4.2 se vejde do telefonu na 2,58 GB, kontext v něm spadl na 4 096 tokenů
Na Hugging Face přibyl převod čínského modelu Nanbeige 4.2 do formátu běhového prostředí LiteRT-LM: jediný soubor o velikosti 2,58 GB, čtyřbitové váhy a kontext 4 096 tokenů místo 262 144, které slibuje originál. Model má dvaadvacet vrstev a každý token jimi projde dvakrát, takže na procesoru telefonu dekóduje podle autora převodu tempem, jaké se čeká od osmimiliardového modelu.

Na Hugging Face přibyl 1. srpna repozitář litert-community/Nanbeige4.2-3B a v něm jediný podstatný soubor: model.litertlm o velikosti 2 579 277 808 bajtů. Je to převod čínského modelu Nanbeige 4.2 do formátu, kterému rozumí LiteRT-LM, otevřené běhové prostředí Googlu pro jazykové modely na koncových zařízeních. Repozitář založil jeden účet ve sdílené organizaci LiteRT Community, která má na Hugging Face 2 565 členů; vydání výrobce modelu to tedy není.
Jméno mluví o třech miliardách, soubor obsahuje čtyři
Originál Nanbeige/Nanbeige4.2-3B vyšel 21. července pod licencí Apache 2.0, technická zpráva k němu je na arXivu od 24. července a 27. července dostala druhou verzi. Číslo v názvu se týká parametrů bez vkládací vrstvy; sama karta modelu uvádí v tabulce 4 miliardy celkem a 3 miliardy bez vkládání.
Přepočítali jsme si to ze souborů. Váhy v bf16 mají 8 339 624 720 bajtů, tedy po dvou bajtech na parametr 4,17 miliardy parametrů. Slovník má 166 144 položek a skrytý rozměr je 3 072; vkládací a výstupní matice nejsou svázané (tie_word_embeddings: false), takže samy zaberou 1,02 miliardy. Zbývá 3,15 miliardy a údaj z tabulky sedí.
Dvaadvacet vrstev, ale čtyřiačtyřicet průchodů
Nanbeige 4.2 je „looped transformer“, tedy model se smyčkou: vrstvy se nepřidávají, jen se spouštějí opakovaně. V konfiguraci stojí num_hidden_layers: 22 a num_loops: 2, takže na každý token připadá čtyřiačtyřicet průchodů vrstvou. Váhy se ukládají jednou; zdvojuje se výpočet a paměť pozornosti, což je v převodu vidět na čtyřiačtyřiceti přihrádkách KV cache, jedné pro každou dvojici průchod a vrstva. Autor převodu z toho v kartě vyvozuje, že model na procesoru dekóduje tempem, jaké se čeká od osmimiliardového modelu.
Kontext klesl na čtyřiašedesátinu
Karta originálu slibuje kontext 262 144 tokenů. Převod pro zařízení má KV cache nastavenou na 4 096. Proč zrovna tolik, karta neuvádí; převodní nástroj hf-to-litertlm, kterým soubor vznikl, nastavuje u modelů s uvažováním právě tuhle hodnotu.
Váhy jsou v převodu čtyřbitové, po blocích o dvaatřiceti hodnotách a s ořezem OCTAV, vkládací vrstva zůstala osmibitová. Výsledek má 2,40 GiB, což karta zapsala jako „~2.4 GB“; v desítkových jednotkách je to 2,58 GB. Proti bf16 vahám originálu je soubor 3,2krát menší, ne čtyřikrát, a čísla to vysvětlují: 3,15 miliardy vah po čtyřech bitech dá 1,57 GB, 1,02 miliardy vkládacích po osmi bitech dalších 1,02 GB, dohromady 2,59 GB. Od skutečné velikosti souboru se ten odhad liší o necelé procento.
Co k běhu chce
Karta převodu jmenuje tři podmínky a všechny tři jsou omezující. Model se musí pouštět na procesoru, protože grafický delegát podle ní na rozvinutém grafu se čtyřiačtyřiceti vrstvami počítá špatně. Musí se vzorkovat: bez vzorkování, tedy při volbě nejpravděpodobnějšího tokenu, se model podle karty rozpadá a doporučené hodnoty jsou teplota 0,6, top_k 20 a top_p 0,95, přesně ty, které má výrobce v souboru generation_config.json. A šablona chatu otevírá blok <think> sama, takže model začíná uvnitř vlastní úvahy a viditelná odpověď přijde až za </think>.
Rychlost změřil autor převodu, ne nezávislá strana. Na iPhonu 17 Pro model podle karty dekóduje asi 3,2 tokenu za sekundu na procesoru, načte se za zhruba 4,4 s a špička paměti je 1,8 až 2,1 GB. Na Macu s čipem řady M vychází asi 10 tokenů za sekundu, opět na procesoru. Na Androidu se soubor podle karty importuje do aplikace Google AI Edge Gallery. Samo LiteRT-LM Google popisuje jako produkční prostředí pro Android, iOS, web, počítače i jednodeskové stroje typu Raspberry Pi a uvádí, že pohání funkce v Chrome, na Chromebooku Plus a v hodinkách Pixel Watch.
O kolik kvantizace ubrala
Karta uvádí jediné srovnání: test GSM8K, padesát otázek, bez příkladů v zadání. Verze v bf16 v knihovně transformers 4.51 dala 94,0 % (47 z 50), čtyřbitový převod v LiteRT-LM 90,0 % (45 z 50). Rozdíl jsou dvě odpovědi z padesáti a měřil je autor převodu; jako doklad o kvalitě kvantizace to nestačí a nikdo jiný měření nezopakoval.
Tabulka výrobce je ambicióznější. Tvrdí, že Nanbeige 4.2 překonává Qwen3.5-9B i Gemma4-12B napříč agentními testy. Poznámky pod ní ale přiznávají, že kancelářské a agentní úlohy se měřily vlastním prostředím výrobce a že jeden z testů si firma sama sestavila. Nezávislé zopakování k dispozici není.
Licence je Apache 2.0, soubor s ní chybí
Obě karty uvádějí Apache 2.0. Ani v jednom repozitáři ale soubor LICENSE není: jeho adresa vrací v obou případech 404 a licence zůstává jen položkou v hlavičce karty. Totéž, tedy Apache 2.0 v hlavičce a žádný soubor s jejím zněním, měl i model Inkling-Small. Žádná další pravidla užití tu nad rámec licence nejsou; místo nich má karta oddíl o omezeních, ve kterém se výrobce zříká odpovědnosti za šíření nevhodných výstupů.
Kdo nechce převod, ale plné váhy, narazí na jinou překážku: karta originálu posílá čtenáře na vlastní odnože tří projektů. SGLang se má klonovat z větve nbg42 a vLLM z větve nanbeige42 v repozitářích výrobce, u llama.cpp platí totéž. K LM Studiu karta dodává, že jeho vestavěný llama-server architekturu nanbeige zatím neumí a že se mu musí podstrčit vlastní sestavení.
Za běh v telefonu se tu platí dvakrát: dvojnásobným výpočtem na token a kontextem zkráceným na čtyřiašedesátinu. Podle nás je tvrdší to druhé. Dvojnásobný výpočet se dá přečkat, kontext ne: model se nabízí jako agentní a agent utratí kontext za výpisy nástrojů dřív než za text uživatele. Hodnotu 4 096 přitom nedrží model, ale proměnná v převodním skriptu. Jestli vyšší číslo projde a co udělá s pamětí telefonu, karta neříká a nikdo to zatím nezveřejnil.