<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Scaling-Laws — Inferownia</title><link>https://inferownia.pl/tags/scaling-laws/</link><description>Inferownia — polski hub wiedzy o lokalnym AI: uruchamianie modeli językowych na własnym sprzęcie, kwantyzacja, inferencja, małe modele, fine-tuning i RAG.</description><language>pl-PL</language><copyright>&#169; 2026 Inferownia</copyright><lastBuildDate>Mon, 13 Jul 2026 00:00:00 +0200</lastBuildDate><atom:link href="https://inferownia.pl/tags/scaling-laws/index.xml" rel="self" type="application/rss+xml"/><item><title>BitNet b1.58: era 1-bitowych LLM-ów</title><link>https://inferownia.pl/naukowy/bitnet-1bit/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0200</pubDate><author>Shuming Ma</author><author>Hongyu Wang</author><author>Lingxiao Ma</author><author>Lei Wang</author><author>Wenhui Wang</author><author>Shaohan Huang</author><author>Li Dong</author><author>Ruiping Wang</author><author>Jilong Xue</author><author>Furu Wei</author><category>kwantyzacja</category><guid>https://inferownia.pl/naukowy/bitnet-1bit/</guid><description>Miliardy wag modelu ściśnięte do trzech wartości: minus jeden, zero, plus jeden. Bez mnożeń, prawie bez pamięci — i, od pewnego rozmiaru, prawie bez straty jakości. Rozbieramy pracę, która ogłosiła erę 1-bitowych LLM-ów.</description><content:encoded><![CDATA[<p>Odchudzanie modelu to sport bez mety — zawsze znajdzie się ktoś, kto urwie jeszcze jeden bit.
Najpierw było szesnaście bitów na wagę i pliki, przy których dysk kwiczał. Potem przyszła kwantyzacja
po treningu i zeszliśmy na osiem, na cztery, gdzieś na dnie forum ktoś odpalał dwa. Za każdym
razem wracało to samo pytanie — „a da się jeszcze niżej?&quot; — i za każdym razem ktoś
mądrzejszy odpowiadał, że przy dwóch bitach model zaczyna gadać jak po trzech piwach. No i
w tym całym schodzeniu w dół pada w końcu pytanie, które brzmi jak żart: a gdyby tak jeden
bit? Gdyby waga mogła być tylko włączona albo wyłączona?</p>
<p>Okazuje się, że to nie żart. W lutym 2024 grupa z Microsoft Research położyła na arXiv pracę
o wdzięcznym tytule „The Era of 1-bit LLMs&quot; i pokazała coś, co na pierwszy rzut oka wygląda
na herezję: model, w którym każda waga przyjmuje jedną z trzech wartości — minus jeden, zero
albo plus jeden — a mimo to od pewnego rozmiaru dorównuje pełnoprecyzyjnej LLaMie.<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>
Nazwali go BitNet b1.58. I zanim złapiesz się na tym „1.58 bita&quot; jak na literówce — spokojnie,
to nie literówka. To rozłóżmy na części.</p>
<h2 id="skąd-te-158-bita--czyli-dlaczego-nie-okrągła-jedynka">Skąd te 1,58 bita — czyli dlaczego nie okrągła jedynka</h2>
<p>Najpierw sama nazwa, bo ona zdradza cały pomysł. Skoro waga może być tylko jedną z trzech
rzeczy — <code>-1</code>, <code>0</code> albo <code>+1</code> — to ile informacji trzeba, żeby taki stan zapisać? Logarytm
przy podstawie dwa z trzech. A <code>log2(3)</code> to jakieś 1,58.<sup id="fnref1:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> Stąd <code>b1.58</code>: nie dlatego,
że ktoś w pamięci trzyma ułamki bitów, tylko dlatego, że tyle wynosi teoretyczny koszt
informacyjny wyboru jednego z trzech wariantów.</p>
<p>I tu pierwsza pułapka, w którą łatwo wdepnąć: <strong>1,58 bita to nie jest dosłowna liczba bitów,
jaką waga zajmuje na dysku.</strong> To granica informacyjna, nie format zapisu. W praktycznych
implementacjach — kiedy ktoś pakuje taki model do GGUF-a — wartość ternarna i tak ląduje
zwykle na dwóch bitach plus trochę struktury dookoła. Więc jak zobaczysz „1.58-bit&quot; na karcie
modelu, czytaj to jako „trzy stany na wagę&quot;, a nie jako obietnicę, że plik jest fizycznie
pięciokrotnie mniejszy niż czterobitowy. To dwa różne piętra: ile <em>musisz</em> zapamiętać, a jak
<em>akurat</em> to zapakowałeś.</p>
<p>Dlaczego akurat ternarne, a nie czyste zero-jeden? Bo to zero pośrodku robi robotę. Waga
równa zeru to po ludzku „to połączenie mnie nie obchodzi&quot; — model dostaje wbudowaną możliwość
wycięcia neuronu z równania. Oryginalny BitNet, wcześniejsza praca tej samej ekipy z 2023
roku, jechał na czystych wagach binarnych, tylko <code>-1</code> i <code>+1</code>.<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup> Dorzucenie zera to
właśnie ten skok od BitNetu do BitNetu b1.58 — z pozoru drobny, a robi całą różnicę w jakości.</p>
<h2 id="trenowany-od-zera--i-czemu-to-nie-jest-zwykła-kwantyzacja">„Trenowany od zera&quot; — i czemu to nie jest zwykła kwantyzacja</h2>
<p>Teraz sedno, bo tu większość ludzi przy pierwszym czytaniu odruchowo myśli
o złym torze. Kiedy słyszysz „model na trzech wartościach&quot;, w głowie zapala się „aha, czyli
kolejna kwantyzacja&quot; — bierzemy gotową, wytrenowaną w FP16 sieć i po fakcie zaokrąglamy jej
wagi. Tak działa GGUF-owe <code>Q4_K_M</code>, tak działają GPTQ czy AWQ — rozgryzaliśmy te potreningowe
sztuczki <a href="/naukowy/gptq-awq/">tutaj</a>. Model istnieje najpierw w pełnej precyzji, a dopiero
potem go ściskasz i modlisz się, że nie zgłupieje.</p>
<p><strong>BitNet b1.58 działa dokładnie odwrotnie.</strong> Nikt tu niczego nie kwantyzuje po fakcie. Model
jest trenowany od zera z wagami zamkniętymi w tych trzech wartościach — sieć od pierwszego
kroku uczy się żyć w ternarnym świecie i sama układa sobie wagi tak, żeby jej to nie
przeszkadzało.<sup id="fnref2:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> To fundamentalna różnica: taki model <strong>nigdy nie istniał w FP16.</strong> Nie
ma oryginału, z którego zszedłeś w dół i coś po drodze zgubiłeś. Ternarność nie jest stratą
nałożoną na koniec — jest warunkiem brzegowym od startu.</p>
<table>
	<thead>
			<tr>
					<th></th>
					<th>Kwantyzacja po treningu (PTQ)</th>
					<th>BitNet b1.58</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Kiedy niska precyzja</td>
					<td>po treningu, na gotowej sieci</td>
					<td>od pierwszego kroku treningu</td>
			</tr>
			<tr>
					<td>Czy istnieje wersja FP16</td>
					<td>tak, to oryginał</td>
					<td>nie, nigdy nie istniała</td>
			</tr>
			<tr>
					<td>Wagi</td>
					<td>ściśnięte np. do 4 bitów</td>
					<td>ternarne <code>{-1, 0, +1}</code></td>
			</tr>
			<tr>
					<td>Aktywacje</td>
					<td>różnie</td>
					<td>8-bitowe (schemat W1.58A8)</td>
			</tr>
			<tr>
					<td>Typowe ryzyko</td>
					<td>jakość spada przy mocnym cięciu</td>
					<td>luka jakości znika dopiero od pewnego rozmiaru</td>
			</tr>
	</tbody>
</table>
<p>Skąd model wie, na którą z trzech wartości zaokrąglić daną wagę podczas treningu? Robi to
funkcja o ładnej nazwie <code>absmean</code>. Cała macierz wag jest najpierw skalowana przez swoją
średnią wartość bezwzględną, a potem każda liczba idzie do najbliższej całkowitej ze zbioru
<code>{-1, 0, +1}</code>.<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> Proste jak konstrukcja cepa i o to chodzi — im mniej fikuśne, tym
lepiej się liczy.</p>
<h2 id="mnożenie-jakie-mnożenie">Mnożenie? Jakie mnożenie</h2>
<p>Tu wchodzi część, dla której cały ten cyrk się opłaca. Serce każdego LLM-a to mnożenie
macierzy — miliardy mnożeń liczby przez liczbę, i to właśnie one zżerają prąd i czas. A teraz
policz na palcach, co się dzieje, kiedy jeden z czynników może być tylko <code>-1</code>, <code>0</code> albo <code>+1</code>.
Mnożenie przez <code>+1</code>? To po prostu dodaj tę drugą liczbę. Przez <code>-1</code>? Odejmij. Przez <code>0</code>?
Pomiń, nic nie rób.</p>
<p>I nagle znika mnożenie. Zostają same dodawania i odejmowania — a te są dla krzemu dużo
tańsze. Praca podaje twardą liczbę: dla samej operacji mnożenia macierzy to około <strong>71 razy
mniej energii</strong> na chipie 7nm w porównaniu z odpowiednikiem w FP16.<sup id="fnref1:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> Nie o kilka
procent — o rząd wielkości i to z hakiem. To nie jest „lepsza kompresja&quot;, to zmiana tego,
jaką operację w ogóle wykonuje procesor.</p>
<div class="callout">
  <span class="callout__label">Dlaczego to ważne dla lokalnego LLM</span>
<p>Dla ciebie, człowieka z jedną kartą pod biurkiem, znaczenie jest dwustronne. Z jednej strony
mniej pamięci i mniej prądu na token to marzenie każdego, kto liczył, ile VRAM-u zeżre
<a href="/poradniki/kv-cache-vram/">KV-cache przy długim kontekście</a>. Z drugiej — mnożenie zamienione
na dodawanie najlepiej opłaca się na sprzęcie, który to rozumie. Autorzy wprost sugerują, że
era 1-bitowych modeli woła o nowy, dedykowany krzem projektowany pod ternarną arytmetykę.<sup id="fnref2:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup>
Dzisiejsze GPU są zbudowane pod mnożenie zmiennoprzecinkowe — więc pełnię tej obietnicy
zobaczymy dopiero, gdy hardware nadgoni pomysł.</p>
</div>
<h2 id="haczyk-to-działa-dopiero-od-pewnego-rozmiaru">Haczyk: to działa dopiero od pewnego rozmiaru</h2>
<p>Zanim pobiegniesz ogłaszać koniec FP16, jedna trzeźwa uwaga — i to taka, którą sami autorzy
kładą na stół, bez chowania pod dywan. Ta cudowna „jakość jak w pełnej precyzji&quot; <strong>nie pojawia
się na małych modelach.</strong> Przy 700M czy 1,3B parametrów między BitNetem b1.58 a pełną LLaMą
wciąż widać zauważalną lukę — ternarny model gada wyraźnie gorzej.<sup id="fnref3:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup></p>
<p>Magia zaczyna się gdzieś od 3 miliardów parametrów w górę. Dopiero od tego progu BitNet b1.58
dogania pełnoprecyzyjną LLaMę zarówno pod względem perplexity (miary tego, jak model „dziwi się&quot;
tekstowi), jak i na zadaniach końcowych.<sup id="fnref4:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> Model 3,9B potrafi już przebić 3B LLaMę — i to
przy mniejszym zużyciu pamięci oraz niższej latencji.<sup id="fnref5:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> Reszta liczb z pracy jest w tym
samym duchu: redukcja pamięci 2,6–3,55×, przyspieszenie generacji 1,23–4,1× (rośnie z
rozmiarem), a dla modelu 70B przepustowość wyższa 8,9× przy jedenastokrotnie większym
batchu.<sup id="fnref6:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup></p>
<p>Stąd bierze się najciekawszy wniosek pracy — nowe „prawo skalowania&quot;. Autorzy pokazują, że
13-miliardowy BitNet b1.58 potrafi być bardziej efektywny — pamięciowo, energetycznie i
czasowo — niż zwykły model 3B w FP16.<sup id="fnref7:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup> Innymi słowy: przestań patrzeć na samą liczbę
parametrów. Przy ternarnych wagach większy model może być lżejszy w użyciu od mniejszego
pełnoprecyzyjnego. To wywraca do góry nogami intuicję, którą wszyscy nosimy — że więcej
parametrów zawsze znaczy cięższy plik.</p>
<h2 id="zrób-to-sam--microsoft-wypuścił-konkretny-model">Zrób to sam — Microsoft wypuścił konkretny model</h2>
<p>To nie zostało teorią na papierze. Microsoft wydał gotowy, produkcyjny model:
<code>microsoft/bitnet-b1.58-2B-4T</code> — około 2 miliardów parametrów, wytrenowany na 4 bilionach
tokenów, na licencji MIT.<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> Pod maską to transformer z warstwami BitLinear (to w nich
siedzą te ternarne wagi), z RoPE, z aktywacją squared ReLU w FFN, normalizacją subln i bez
biasów.<sup id="fnref1:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> Schemat, który już znasz z tego wpisu: W1.58A8 — wagi 1,58-bitowe, aktywacje
ośmiobitowe.</p>
<p>I teraz najważniejsza pułapka praktyczna, bo tu połowa ludzi się nabiera. <strong>Jeśli odpalisz
ten model przez zwykłą bibliotekę <code>transformers</code> z Hugging Face — nie zobaczysz żadnych
oszczędności.</strong> Karta modelu mówi to wprost: efektywność pamięci i energii ujawnia się
wyłącznie z dedykowaną implementacją.<sup id="fnref2:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> <code>transformers</code> policzy ci ten model jak każdy
inny, gęsto i drogo — bo nie umie skorzystać z tego, że mnożenia są zbędne. To trochę jak
kupić samochód na prąd i tankować go benzyną z kanistra.</p>
<p>Tą dedykowaną implementacją jest <code>bitnet.cpp</code> — framework inferencyjny z repozytorium
<code>microsoft/BitNet</code> na GitHubie.<sup id="fnref:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup> I tu druga pułapka, tym razem dla porządkowych: to
<strong>nie</strong> jest część <code>ggml-org</code>, mimo że stoi na llama.cpp i pachnie tym samym ekosystemem.
To osobny projekt utrzymywany przez Microsoft, opisany we własnej pracy na arXiv.<sup id="fnref:6"><a href="#fn:6" class="footnote-ref" role="doc-noteref">6</a></sup>
Dostarcza dedykowane kernele — <code>I2_S</code> na x86 i ARM, <code>TL1</code> na ARM, <code>TL2</code> na x86 — i to one
robią tę robotę z zamianą mnożeń na dodawania.<sup id="fnref1:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup></p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">git clone --recursive https://github.com/microsoft/BitNet.git
</span></span><span class="line"><span class="cl"><span class="nb">cd</span> BitNet
</span></span><span class="line"><span class="cl"><span class="c1"># dokładne kroki (setup_env.py, wybór kernela, pobranie GGUF-a)</span>
</span></span><span class="line"><span class="cl"><span class="c1"># są w README repozytorium — trzymaj się ich, bo się zmieniają</span>
</span></span></code></pre></div><p>Liczby z <code>bitnet.cpp</code> są równie soczyste jak z papieru: na ARM-owym CPU przyspieszenia
1,37–5,07× i redukcja energii 55–70%, na x86 przyspieszenia 2,37–6,17× i redukcja energii
72–82%.<sup id="fnref2:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup> Wisienka na torcie: framework pozwala uruchomić model klasy 100B na pojedynczym
CPU z prędkością rzędu 5–7 tokenów na sekundę.<sup id="fnref3:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup> Sto miliardów parametrów. Na procesorze.
Bez karty. Przeczytaj to zdanie jeszcze raz i przypomnij sobie, ile kosztuje GPU zdolne
udźwignąć taki model po staremu.</p>
<p>Cała droga lokalnego LLM-owca to jedno długie schodzenie po drabinie precyzji. Szesnaście
bitów, osiem, cztery — i za każdym razem ktoś na forum wróżył, że niżej już się nie da, że
na dole tej drabiny model rozpłynie się w bełkocie. BitNet b1.58 nie tyle zszedł o kolejny
szczebel, co zauważył, że drabina od początku stała nie tam. Zamiast ściskać gotowe liczby
coraz mocniej — nauczył sieć od urodzenia myśleć trzema stanami i wyrzucił mnożenie za burtę.</p>
<p>Czy to już koniec ery zmiennoprzecinkowej? Nie dziś — dopóki krzem pod biurkiem woli mnożyć
niż dodawać, pełnia tej obietnicy leży zapakowana i czeka na sprzęt, który ją rozpakuje. Ale
kierunek jest wytyczony, model do ściągnięcia leży na Hugging Face, a <code>bitnet.cpp</code> już liczy.
Czasem nie zmieniasz odpowiedzi na stare pytanie — zmieniasz pytanie. Nie „ile bitów damy
radę utrzymać&quot;, tylko „po co nam w ogóle mnożenie&quot;.</p>
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>Ma, Wang, Ma i in., <em>The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits</em>, arXiv:2402.17764, <a href="https://arxiv.org/abs/2402.17764">arxiv.org/abs/2402.17764</a> — tytuł, autorzy, data zgłoszenia (27 lutego 2024), definicja wag ternarnych <code>{-1, 0, +1}</code>, <code>log2(3) ≈ 1,58 bita</code> i trening od zera.&#160;<a href="#fnref:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref1:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref2:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:2">
<p>Wang i in., <em>BitNet: Scaling 1-bit Transformers for Large Language Models</em>, arXiv:2310.11453, <a href="https://arxiv.org/abs/2310.11453">arxiv.org/abs/2310.11453</a> — poprzednik b1.58 z wagami binarnymi <code>{-1, +1}</code>.&#160;<a href="#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:3">
<p><em>The Era of 1-bit LLMs</em> — pełny tekst, <a href="https://arxiv.org/html/2402.17764v1">arxiv.org/html/2402.17764v1</a> — funkcja <code>absmean</code>, próg ~3B dla dopasowania do FP16, luka na 700M/1.3B, model 3.9B kontra 3B LLaMA, liczby dot. pamięci/latencji/przepustowości, ~71× mniej energii na matmul (7nm), nowe prawo skalowania i wniosek o dedykowanym sprzęcie.&#160;<a href="#fnref:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref1:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref2:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref3:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref4:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref5:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref6:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref7:3" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:4">
<p>Karta modelu <code>microsoft/bitnet-b1.58-2B-4T</code>, <a href="https://huggingface.co/microsoft/bitnet-b1.58-2B-4T">huggingface.co/microsoft/bitnet-b1.58-2B-4T</a> — 2B parametrów, 4T tokenów, schemat W1.58A8, warstwy BitLinear, RoPE, squared ReLU, subln, brak biasów, licencja MIT oraz zastrzeżenie o braku zysków wydajności przez <code>transformers</code>.&#160;<a href="#fnref:4" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref1:4" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref2:4" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:5">
<p><code>microsoft/BitNet</code> — oficjalne repozytorium <code>bitnet.cpp</code>, <a href="https://github.com/microsoft/BitNet">github.com/microsoft/BitNet</a> — kernele <code>I2_S</code>/<code>TL1</code>/<code>TL2</code>, zamiana mnożeń na dodawania/odejmowania, przyspieszenia i redukcja energii na ARM/x86, uruchomienie modelu 100B na pojedynczym CPU (~5–7 tok/s).&#160;<a href="#fnref:5" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref1:5" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref2:5" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a>&#160;<a href="#fnref3:5" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:6">
<p>Wang i in., <em>Bitnet.cpp: Efficient Edge Inference for Ternary LLMs</em>, arXiv:2502.11880, <a href="https://arxiv.org/pdf/2502.11880">arxiv.org/pdf/2502.11880</a> — osobna praca opisująca framework inferencyjny dla modeli ternarnych.&#160;<a href="#fnref:6" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
</ol>
</div>
]]></content:encoded></item></channel></rss>