低ビット LLM の議論では、重みを何ビットまで小さくできたかが最初に注目される。16 ビットから 8 ビット、4 ビット、2 ビットへ下げれば、重み本体の保存容量を減らせる。推論時に重みを繰り返し読み出す処理では、メモリーから転送するデータ量も減るため、メモリー帯域が律速する条件では実行時間の短縮にもつながる。三値 LLM では、量子化後の重みを \(-1\)、\(0\)、\(+1\) の 3 状態へ制限することから、\(\log_2 3\approx1.585\) に対応する約 1.58 bit/weight という呼称が広く使われてきた。
ただし、「16 ビットから 1.58 ビットへ減った」という数字だけでは、その途中で何が失われ、何が保存され、どの処理が別の場所へ移ったのかを区別できない。既稿では、量子化を有限の表現能力へ収めるために元の空間に存在した区別の一部を捨てる操作として整理した[1]。高精度な重み \(x\) が量子化器 \(Q\) によって同じ代表値 \(q\) へ写されると、量子化後の \(q\) だけから元の \(x\) を一意に復元できない。多数の入力を少数の状態へ集約する多対一写像そのものが、保存量の削減と量子化誤差の両方を生む。
この違いによって、低ビット化の中に二つの異なる削減が見えてくる。第一の削減は量子化であり、入力空間に存在した区別そのものを減らす。第二の削減は可逆な符号化であり、残された記号列が持つ確率的な偏りや繰り返しを利用して、同じ情報をより短い表現へ配置し直す。前者では失われる情報量と精度が設計上の制約になり、後者では復号可能性と復号コストが制約になる。
可逆符号化によって保存側の冗長性を削ると、系全体から処理が消えるわけではない。固定幅で並んでいた記号をそのまま読み出せる状態から、圧縮形式を解釈して必要な記号を取り出す状態へ変わるためである。保存側ではビット数が減る一方、実行側では位置情報の解釈、符号の展開、ビット操作、専用命令などが増える。圧縮によって減った保存上の複雑さの一部を、復号器と演算カーネルが引き受ける構造になる。
この関係を、単純に「圧縮率と復号速度の交換関係」とだけ見ると、もう一段上にある構造を見落とす。どの保存形式が有利になるかは、圧縮方式だけで固定されない。量子化後の各状態がどの頻度で現れるかによって圧縮率が変わり、メモリー帯域と命令処理能力の比によって復号コストの重さも変わる。モデル側の分布とハードウェア側の条件の両方を観測して初めて、保存量と実行性能の損益分岐点を決められる。
ここで、既稿で扱ってきた構造振動モデルとの接続が生じる。構造振動モデルでは、最初に与えた構造を固定的な最終形とは見なさず、実際の運用から得られた頻度分布、衝突条件、利用経路などの観測結果によって構造を更新する。利用頻度の低い分岐を削り、頻繁に通る経路へ構造を寄せれば、運用に適した単純な構造へ移る。一方、環境条件が変わって新しい衝突や制約が現れれば、再び構造を増やす必要が生じる。
低ビット LLM の保存形式にも同じ読み方を適用できる。量子化によって \(-1\)、\(0\)、\(+1\) という状態集合を定めた時点では、三つの状態をどのような長さで保存するのが最適かまでは決まっていない。実モデルを観測して \(0\) が高い頻度で現れることが分かれば、その頻度分布へ保存形式を合わせる余地が生まれる。保存形式を変更すると転送量は減るが、新しい復号処理が必要になる。さらに CPU や GPU の帯域と命令性能が変われば、同じ保存形式でも有利な条件と不利な条件が入れ替わる。
この対応は、構造振動モデルが低ビット LLM の性能を予測するという意味ではない。構造振動モデルが与えるのは、観測前の構造を固定的な最適解とせず、利用分布と外部制約の観測によって構造を更新するという読み方である。BITCOS のような方式をこの座標へ置くと、「1.58 ビットより小さくできた」という結果を、数値だけの更新ではなく、分布観測によって保存構造が再編された事例として扱える。
本稿で追う対象は、この再編によって複雑さがどこへ移るかである。量子化では状態空間が縮小し、可逆符号化では保存上の冗長性が縮小する。符号化によって削った保存量は、復号器の処理として実行側へ現れる。最終的な損得は、モデルの重み分布とハードウェアの帯域・命令処理能力を同時に見たときに決まる。
低ビット表現の最適点は、この連鎖の途中にある一つの数字から決まるものではない。最小の bit/weight を実現する保存形式が、最小の実行時間を与えるとは限らない。モデルが持つ分布、符号化形式、復号方式、メモリー帯域、命令処理能力を合わせたときに成立する構造が、その環境における安定点になる。
1. 量子化で情報を捨てた後にも圧縮余地は残る
量子化後にも圧縮余地が残る理由を理解するには、既稿で分けた量子化と符号化の責任範囲をもう一度確認する必要がある。量子化は、入力空間のどの値を同一視するかを決める。符号化は、量子化によって残された状態をどのビット列として記録するかを決める[1]。両者は連続して実行されるためファイルサイズの削減という同じ結果に見えるが、変更している対象が異なる。
元の重みを \(x\)、量子化器を \(Q\)、量子化後の記号を \(q\) とする。三値量子化では、
\[
Q(x)\in\{-1,\ 0,\ +1\}
\]
となる。多数の異なる \(x\) が同じ \(q\) へ対応するため、\(Q\) は一般に多対一の写像になる。たとえば、
\[
Q(-0.73)=Q(-0.68)=Q(-0.61)=-1
\]
と量子化された場合、量子化後の \(-1\) から元の値が \(-0.73\)、\(-0.68\)、\(-0.61\) のどれであったかを特定できない。ここで削減されたのは保存形式の余白ではなく、入力空間に存在した区別そのものである。
この多対一構造には、利益と損失が同時に含まれる。区別する状態数を減らすから、少ないビット数で重みを記録できる。一方、同じ代表値へまとめた入力どうしの差を失うため、量子化前の値を完全には復元できない。既稿で整理したように、量子化による保存量削減と量子化誤差は、別々の現象ではなく同じ状態削減から生じる[1]。
量子化後の記号列に対する可逆符号化では、削減対象が変わる。量子化結果として、
\[
(+1,\ 0,\ -1,\ 0,\ 0,\ +1)
\]
という 6 個の記号が得られたとする。これらを固定長 2 ビットで保存するなら、たとえば \(-1\)、\(0\)、\(+1\) へそれぞれ 00、01、10 を割り当て、合計 12 ビットを使用できる。3 状態しか使わないため、2 ビットが表現できる 4 通りのうち 1 通りは未使用になる。
別の符号化方式で同じ三値列をより短いビット列へ変換し、復号器 \(D\) によって、
\[
D(E(q_1,q_2,\ldots,q_n))
=
(q_1,q_2,\ldots,q_n)
\]
を満たすなら、量子化後の情報は保存されている。\(E\) は三値列をビット列へ変換する符号化器、\(D\) はそのビット列から三値列を復元する復号器である。ここで必要なのは量子化前の \(x\) を戻すことではなく、量子化によって確定した \(q\) を一意に戻せることである。
量子化と可逆符号化の差は、この復元先を見ると明確になる。
| 操作 | 変換 | 失われる区別 | 逆方向に戻せる範囲 | 主な設計変数 |
|---|---|---|---|---|
| 量子化 | 高精度な入力を有限個の代表値へ対応させる。 | 同じ代表値へ入った入力どうしの区別が失われる。 | 量子化後の代表値までは再構成できるが、元の高精度値は一意に決まらない。 | 状態数、境界、代表値、尺度、誤差基準を選ぶ。 |
| 可逆符号化 | 量子化後の記号列を別のビット列へ対応させる。 | 量子化後の記号間の区別は維持する。 | 符号化前の量子化済み記号列を一意に復元できる。 | 記号分布、符号長、ブロック単位、復号方式を選ぶ。 |
この区別を入れると、「三値なのに 1.58 bit/weight より小さくできる」という現象も矛盾ではなくなる。三値という状態集合が決めるのは、取り得る記号の種類である。その記号がどの確率で現れるかは別の量であり、さらに、その確率分布をどの符号へ変換するかも別の設計対象になる。
三値が常に同じ頻度で現れるとは限らない。たとえば、\(0\) が半分、\(-1\) と \(+1\) がそれぞれ 4 分の 1 を占める列では、次の記号が \(0\) である確率が他の記号より高い。固定長表現は、この頻度差にかかわらず各記号へ同じ長さを割り当てる。頻度の偏りを符号長やデータ構造へ反映すれば、量子化済みの三値をすべて保持したまま平均保存量を減らせる。
ここで、量子化後にも圧縮余地が残る理由が二段階でつながる。まず、量子化は入力値の種類を有限個へ減らすが、その有限個の状態が実際に同じ頻度で使われることまでは保証しない。次に、使用頻度が偏っていれば、状態ごとに同じ保存資源を割り当てる固定幅表現には、実際の分布を反映していない冗長性が残る。この冗長性が、量子化後の可逆圧縮で削減できる対象になる。
2. 保存すべき状態より実際に使われる状態の偏りが重要になる
量子化によって状態数を減らした後、次に保存量を左右するのは、その状態が実際にどの割合で使われているかである。三値 LLM では、量子化後の重みが \(-1\)、\(0\)、\(+1\) の 3 種類に限定される。しかし、「3 種類の値を取る」という状態集合の定義だけでは、実際の重み列がどれだけの情報を持つかまでは決まらない。必要な平均情報量は、3 状態それぞれの出現確率によって変化する。
情報理論では、この違いをエントロピーによって表す。記号 \(x\) が確率 \(p(x)\) で現れる情報源のエントロピー \(H(X)\) は、次の式で定義される[2]。
\[
H(X)=-\sum_x p(x)\log_2 p(x)
\]
\(p(x)\) は各状態の出現確率、\(-\log_2 p(x)\) はその状態が現れたときの情報量を表す。頻繁に現れる状態は予測しやすいため 1 回当たりの情報量が小さく、まれに現れる状態は予測しにくいため情報量が大きい。\(H(X)\) は、それらを実際の出現確率で重み付けした 1 記号当たりの平均情報量になる。
三値 LLM で \(-1\)、\(0\)、\(+1\) がそれぞれ \(1/3\) の確率で現れる場合、エントロピーは、
\[
H(X)
=-3\times\frac{1}{3}\log_2\frac{1}{3}
=\log_2 3
\approx1.585
\]
bit/weight となる。3 状態の情報源では、この等確率分布でエントロピーが最大になる。どの状態も同じ頻度で現れるため、次の重みについて特定の状態を事前に有力視できず、平均情報量も最大になる。
一方、同じ 3 状態を使っていても、\(0\) が 50%、\(-1\) と \(+1\) がそれぞれ 25% なら、
\[
H(X)
=-0.5\log_2 0.5
-0.25\log_2 0.25
-0.25\log_2 0.25
=1.5
\]
bit/weight になる。量子化器が生成できる値は \(-1\)、\(0\)、\(+1\) のままであり、状態数は変化していない。それでも \(0\) が他の状態より高い確率で現れるため、重み列全体の予測可能性が上がり、平均情報量は約 1.585 bit/weight から 1.5 bit/weight へ下がる。
この差は、状態数と実分布が異なる設計変数であることを示している。状態数は「何が起こり得るか」を定める。確率分布は「実際には何がどの程度起きているか」を定める。三値化によって前者を 3 種類へ固定した後にも、後者にはモデルごとの差が残る。その差が、量子化後の追加圧縮に利用できる。
| 観点 | 状態集合だけを見る場合 | 実分布まで観測する場合 | 保存設計への帰結 |
|---|---|---|---|
| 状態数 | \(-1\)、\(0\)、\(+1\) の 3 種類を区別する。 | 状態集合そのものは同じ 3 種類のままである。 | 量子化後の表現能力は変化しない。 |
| 出現頻度 | 各状態がどの程度使われるかを保存形式へ反映しない。 | \(0\)、\(-1\)、\(+1\) の実際の出現率を測定する。 | 頻出状態と低頻度状態へ異なる保存資源を割り当てられる。 |
| 情報量 | 等確率三値の最大エントロピーである約 1.585 bit/weight が基準になる。 | 実際の確率分布から平均情報量を計算する。 | 分布が偏れば、同じ三値でも平均情報量は約 1.585 bit/weight を下回る。 |
| 符号化 | 固定レートの表現では出現頻度にかかわらず同じ保存量を割り当てる。 | 実分布の偏りを符号長やデータ構造へ反映する。 | 量子化済みの三値列を維持したまま平均保存量を減らせる。 |
固定レートの表現には、分布を知らなくても保存量を事前に決められる利点がある。たとえば各三値を 2 ビットで保存すれば、\(-1\)、\(0\)、\(+1\) がどの割合で現れても 1 重み当たりの保存量は変わらない。一方、この方式では \(0\) が重みの半分を占めるモデルでも、3 状態が均等に現れるモデルでも、同じ保存資源を使う。実分布が偏った後も状態を対称に扱い続けるため、その偏りを圧縮へ利用する余地が残る。
既稿「理解・設計・制度はなぜ単純化へ収束するのか」で扱ったのも、可能な経路と実際に利用される経路の差であった[3]。設計時には複数の分岐を用意する必要があっても、運用を続けると利用頻度が観測される。頻繁に通る経路、ほとんど利用されない経路、特定条件でだけ必要になる例外経路が分離されると、初期構造ですべての経路を同程度に扱っていた理由を再評価できる。
この構造を三値 LLM へ対応させると、量子化器が定める \(-1\)、\(0\)、\(+1\) は「利用可能な経路」に相当する。量子化直後の状態集合だけを見れば 3 状態は対称に見えるが、学習済みモデルの重みを観測すると、実際の利用頻度はモデルごとに異なる。そこで初めて、「3 状態を同じ保存量で扱う」という初期の表現と、「実際の頻度に合わせて保存量を配分する」という観測後の表現を比較できる。
ただし、既稿の構造をそのまま情報理論へ置き換えているわけではない。エントロピーは確率分布から数学的に定義される量であり、構造振動モデルは観測された利用状況によって構造を更新する過程を扱う。両者が接続するのは、「可能性の集合だけでは最終構造を決めず、実際に観測された頻度分布が次の構造を選ぶ根拠になる」という部分である。
この接続によって、圧縮の意味も一段変わる。圧縮前の保存形式が誤っていたから作り直すのではなく、観測前には使えなかった情報が観測後に利用可能になる。状態集合しか分からない段階では、分布に依存しない固定レート表現を選べる。学習済みモデルから実分布を取得した後は、その分布を利用する別の符号化方式を評価できる。構造更新を可能にする情報そのものが、運用または観測によって増えている。
この点は構造振動モデルにとっても重要である。構造の単純化を、時間の経過とともに無条件で枝を削る処理として捉えると、なぜ削ってよいのかを説明できない。観測によって頻度分布が得られ、低頻度部分を別形式へ移しても必要な機能や情報を維持できることが確認されて初めて、構造を再編する根拠が生まれる。三値 LLM では、その関係を状態数、確率分布、エントロピー、符号長という測定可能な量で追跡できる。
量子化後の圧縮余地は、三値という状態数の外側に新しい状態を削ることで生まれるのではない。同じ \(-1\)、\(0\)、\(+1\) を保持したまま、実際の使用頻度を保存構造へ反映することで生まれる。可能な状態の定義から実際の頻度分布へ観測対象を移すと、固定されていたように見えた保存構造が再び設計対象になる。
3. 構造は観測された頻度分布に応じて再編される
構造振動モデルでは、構造を固定された完成物としてではなく、環境条件と運用観測によって更新される状態として扱う。既稿では、設計時に安全側へ寄せて持たせた分岐や例外が、運用後の頻度分布や衝突条件の観測によって再評価され、利用実態に合わない部分が削られて別の安定構造へ移る過程を「複雑化と単純化の往復」として整理した[4]。
この過程では、単純化そのものを目的にしているわけではない。初期構造では未知の利用条件を吸収するために余分な分岐を持たせる必要がある。運用後に利用頻度や例外発生条件が観測されると、初期には区別できなかった「頻繁に必要な経路」と「ほとんど使われない経路」を分けられるようになる。その観測結果を使うことで、必要な機能を残したまま構造を再編できる。
数理モデル化した既稿では、この更新を概念的に次の式で表した[5]。
\[
S_{t+1}=M(S_t,\ C_t,\ O_t,\ U_t)
\]
\(S_t\) は時点 \(t\) の構造、\(C_t\) はその構造が置かれている環境条件、\(O_t\) は構造と環境から得られた観測、\(U_t\) は観測後に加える介入、\(M\) はそれらを受けて次の構造 \(S_{t+1}\) を生成する更新則である。式の中心にあるのは、構造だけから次の構造が決まるのではなく、環境と観測が更新条件へ入ることである。
この枠組みを低ビット LLM の保存形式へ対応させると、各変数を具体的な設計対象へ落とせる。現在の符号化形式を \(S_t\)、CPU や GPU の帯域・命令系を \(C_t\)、重み分布や実測性能を \(O_t\)、符号化形式や復号カーネルの変更を \(U_t\) とみなせば、保存形式の変更を「圧縮率を上げる操作」ではなく、「観測された条件に合わせて構造を更新する操作」として記述できる。
| 構造振動モデル | 低ビット LLM での対応 | 観測・変更できる値 | 構造更新へ与える影響 |
|---|---|---|---|
| \(S_t\) | 現在の重み表現と保存レイアウトに対応する。 | 固定 2 ビット、five-trit packing、BITCOS などを区別できる。 | 現在の保存量と復号方式の基準になる。 |
| \(C_t\) | 実行するハードウェアと推論条件に対応する。 | メモリー帯域、コア数、SIMD 命令、GPU の実行特性などを測定できる。 | 同じ圧縮形式でも復号コストと転送量削減の損益を変える。 |
| \(O_t\) | モデルと実行系から得られる観測に対応する。 | ゼロ率、符号分布、保存量、復号速度、行列演算性能、トークン生成速度などを測定できる。 | 現在の構造に残る冗長性と新たな律速条件を明らかにする。 |
| \(U_t\) | 符号化形式や復号カーネルの変更に対応する。 | 記号配置、ブロック構造、復号手順、専用カーネルを変更できる。 | 観測された分布やハードウェア条件を次の構造へ反映する。 |
| \(S_{t+1}\) | 観測と介入を反映した次の保存・実行構造に対応する。 | 異なる bit/weight、復号コスト、実行性能を持つ構造として評価できる。 | 次の観測対象となり、条件が変われば再び更新される。 |
この対応で中心になるのは、最小の保存量を持つ構造をあらかじめ決めることではなく、観測結果によって候補構造の優劣が変わる点である。たとえばゼロ率が低いモデルでは、\(0\) を特別扱いする符号化によって削減できる保存量が小さい。ゼロ率が高くなると、非ゼロ重みだけに追加情報を持たせる構造の利得が増える。モデル側の分布が変わることで、同じ符号化方式の圧縮効果が変化する。
さらに、同じ重み分布と同じ保存形式を固定しても、実行ハードウェアが変われば結果は一致しない。メモリー帯域が先に上限へ達する環境では、重みの転送量を減らす効果が大きい。一方、メモリー転送に余裕があり、圧縮形式を展開する命令が先に上限へ達する環境では、追加した復号処理が新しい律速条件になる。モデル側の観測だけでなく、実行環境の観測も次の構造を選ぶ条件になる。
この二つを分けると、保存構造がモデル固有の静的属性ではないことが分かる。第一段階では、ゼロ率や符号分布といったモデル側の観測が、どの符号化が保存量を減らせるかを決める。第二段階では、メモリー帯域や命令処理能力といった環境側の観測が、その保存量削減を実行性能へ変換できるかを決める。どちらか一方だけを見ても、次の構造を選ぶ根拠は揃わない。
構造振動モデルでいう安定構造は、ある構造の近傍に状態が留まり、大改修なしでも運用が継続できる状態を指す。低ビット LLM では、その安定性とは別に、ある時点の環境 \(C_t\) と観測 \(O_t\) の下で、保存量と実行コストの組み合わせを評価する必要がある。環境条件や利用分布が変われば、以前に安定していた \(S_t\) も再評価の対象になる。
低ビット LLM へ当てはめれば、あるモデルとハードウェアの組み合わせで BITCOS が有利だったとしても、その結果からすべての三値 LLM に同じ保存形式を適用すべきとは導けない。ゼロ率が変われば圧縮率が変わり、ハードウェアが変われば復号コストの相対的な重さが変わる。安定する保存形式は、モデル分布と実行環境の組み合わせに対して決まる。
構造振動モデルとの接続は、BITCOS が構造振動モデルを実証するという関係ではない。構造振動モデルは、観測によって次の構造を選択するための分析枠組みを与える。一方、低ビット LLM では、ゼロ率、保存量、メモリー帯域、復号速度といった具体的な値を実測できる。この二つを接続すると、「構造更新を駆動している観測は何か」「何を残して何を移動したのか」「更新後に新しくどの制約が現れたのか」を明示できる。
この読み方によって、圧縮率の改善だけを構造更新の成功条件に置く必要もなくなる。保存量を減らしても復号処理が律速すれば、実行系全体では別の構造が有利になる。逆に、多少の復号処理を増やしてもメモリー転送の削減幅が大きければ、圧縮構造へ移る利益が生じる。構造更新の評価対象は、単一の bit/weight ではなく、保存量と実行コストを合わせた結果になる。
4. 圧縮とは頻度分布を符号長へ移すことである
頻度分布を保存構造へ反映する発想自体は新しくない。Huffman 符号は、出現確率の高い記号へ短い符号語を、低い記号へ長い符号語を割り当て、平均符号長を小さくする方法を与えた[6]。記号ごとの長さを均等にする代わりに、頻度分布へ保存コストを合わせる。
算術符号では、個々の記号へ整数個のビットを割り当てる制約を緩め、記号列全体を一つの区間として表現することで平均符号長をエントロピーへ近づける[7]。さらに Asymmetric Numeral Systems は、圧縮率だけでなく実装時の復号速度も主要な設計対象になることを示している[8]。
ここから、圧縮率と復号コストの関係が見える。符号化を複雑にすれば理論的な平均符号長へ近づけやすくなる一方、復号時には状態更新、テーブル参照、ビット操作などが必要になる。符号化方式の評価対象は保存量だけでは完結せず、復号経路の処理量を含む。
| 方式 | 分布の利用方法 | 保存側の特徴 | 復号側の特徴 |
|---|---|---|---|
| 固定長符号 | 記号頻度を符号長へ反映しない。 | 記号ごとの長さが一定で、配置が単純になる。 | 復号が単純で、位置計算もしやすい。 |
| Huffman 符号 | 高頻度記号へ短い符号語を割り当てる。 | 平均符号長を削減できる。 | 可変長符号の境界を解釈する処理が必要になる。 |
| 算術符号 | 記号列全体の確率を区間へ写す。 | 平均符号長をエントロピーへ近づけやすい。 | 区間更新を継続する逐次処理が必要になる。 |
| ANS | 確率分布を状態遷移へ組み込む。 | 高い圧縮率と高速な復号の両立を狙える。 | 状態とテーブルを用いる専用の復号処理が必要になる。 |
この表が示すのは、圧縮によって複雑さが消えるのではなく、保存形式と復号器の間で配置が変わるということだ。固定長表現では冗長なビットを多く持つ代わりに、位置と値の対応が直接的になる。分布適応型の表現では保存量を減らせる代わりに、元の記号列を復元する規則が必要になる。
LLM の推論では、この交換関係が一般的なファイル圧縮より厳しくなる。モデル重みは一度だけ復号すればよいとは限らず、トークン生成のたびに大量の重みを読みながら行列演算を実行する。圧縮による転送量削減が利益になる一方、復号処理が毎トークンの経路へ入るため、そのコストも繰り返し支払う。
この条件下で、実モデルの三値分布を単純な復号構造へ反映した例が BITCOS である。
5. BITCOS は三値を減らさず保存構造だけを変える
BITCOS の研究者は、BitNet、Bonsai、CAT-Q、ParetoQ、TriLM、Maple、BitCPM-CANN の 7 系統、合計 29 個の三値 LLM を調べ、重み \(0\) の比率を測定した[9]。ゼロ率は 29.66% から 51.48% まで分布しており、同じ三値という状態集合を持ちながら、実際の状態利用率には大きな差があった。三値を均等に扱う保存形式だけを見ていると、このモデル間差は保存量へ反映されない。
前章までの議論を具体的な三値 LLM へ落とすと、BITCOS が変更している対象を正確に切り分けられる。BitNet b1.58 は、重みを \(-1\)、\(0\)、\(+1\) の 3 状態へ制限する三値モデルを 1.58-bit LLM と表現した[10]。この約 1.58 bit/weight は、三つの状態が等確率で現れる場合の \(\log_2 3\approx1.585\) という情報量に対応する。2025 年には BitNet b1.58 2B4T が公開され、20 億パラメーター規模を 4 兆トークンで学習したモデルによって、三値重みが実際のモデルと推論系を持つ設計対象として具体化された[11]。
ここまでで定まるのは、量子化後の状態集合である。各重みは \(-1\)、\(0\)、\(+1\) のいずれかを取り、それ以外の高精度な値は量子化段階ですでに失われている。その後の保存形式を変更しても、復号後に同じ三値列を再構成できる限り、量子化後の情報は変化しない。BITCOS が操作するのは、この三値列をメモリー上へどのように配置するかという後段の構造である。
BITCOS は、この観測結果から三値を二種類の情報へ分解する。第一は、各位置が \(0\) か非 \(0\) かを表す presence bitmap である。第二は、非 \(0\) の位置についてだけ \(+1\) と \(-1\) を区別する sign vector である[9]。三値のうち \(0\) だけを位置情報として分離し、正負の情報を非ゼロ重みに限定することで、ゼロ率を保存量へ直接反映する。
たとえば、8 個の重みが、
\[
(+1,\ 0,\ -1,\ 0,\ 0,\ +1,\ -1,\ 0)
\]
と並んでいるとする。非ゼロ位置を 1、ゼロ位置を 0 とすれば、presence bitmap は、
\[
(1,\ 0,\ 1,\ 0,\ 0,\ 1,\ 1,\ 0)
\]
となり、8 ビットを使う。非ゼロ重みは 4 個なので、その正負だけを sign vector に、
\[
(+1,\ -1,\ +1,\ -1)
\]
として保持すれば、正負を 1 ビットずつで表現して 4 ビットを使う。合計は 12 ビットであり、1 重み当たりでは 1.5 bit/weight になる。元の 8 個の三値はすべて再構成できるため、この 1.5 bit/weight は新たな量子化によって状態を削った結果ではない。
一般化すると、ゼロ率を \(z\) としたとき、presence bitmap は全重みに対して必要なので常に 1 bit/weight を使う。非ゼロ率は \(1-z\) だから、sign vector の平均保存量は \(1-z\) bit/weight になる。BITCOS の三値記号部分の保存量 \(B(z)\) は、
\[
B(z)
=1+(1-z)
=2-z
\]
bit/weight となる。ゼロが 1 個増えると presence bitmap の 1 ビットは残るが、その位置について正負を保存する 1 ビットが不要になる。この構造によって、観測されたゼロ率がそのまま保存量の差へ変換される。
| ゼロ率 \(z\) | presence bitmap | sign vector | BITCOS の記号部分 | 1.625 bit/weight との関係 |
|---|---|---|---|---|
| 29.66% | 1.000 bit/weight を使う。 | 0.7034 bit/weight を使う。 | 1.7034 bit/weight となる。 | BITCOS のほうが 0.0784 bit/weight 大きい。 |
| 37.5% | 1.000 bit/weight を使う。 | 0.6250 bit/weight を使う。 | 1.6250 bit/weight となる。 | 両者の保存量が一致する。 |
| 41.50% | 1.000 bit/weight を使う。 | 0.5850 bit/weight を使う。 | 1.5850 bit/weight となる。 | 等確率三値の約 1.585 bit/weight とほぼ一致する。 |
| 50% | 1.000 bit/weight を使う。 | 0.5000 bit/weight を使う。 | 1.5000 bit/weight となる。 | BITCOS のほうが 0.1250 bit/weight 小さい。 |
| 51.48% | 1.000 bit/weight を使う。 | 0.4852 bit/weight を使う。 | 1.4852 bit/weight となる。 | 調査対象で最小の BITCOS 保存量になる。 |
比較対象となる five-trit packing は、5 個の三値をまとめて 1 バイトへ格納する。5 個の三値が取り得る組み合わせは、
\[
3^5=243
\]
通りであり、1 バイトの 256 通りに収まる。そのため、5 個をちょうどまとめられるなら保存量は、
\[
\frac{8}{5}=1.6
\]
bit/weight になる。ただし、実モデルで使われる 128 重みなどのブロックへ適用すると、128 は 5 の倍数ではない。128 個の三値を格納するには 26 バイトが必要になるため、
\[
\frac{26\times8}{128}=1.625
\]
bit/weight となる[9]。five-trit packing は三値がどの割合で現れてもこの保存量が変化しない。BITCOS は \(2-z\) なので、両者の損益分岐点は、
\[
2-z<1.625
\]
を満たす条件、すなわち、
\[
z>0.375
\]
となる。ゼロ率が 37.5% を超えれば、BITCOS の三値記号部分は 128 重み単位の five-trit packing より小さくなる。実測した 29 モデルのうち 26 モデルがこの条件を満たしていた[9]。
ここには、前章までに述べた「観測によって構造更新の条件が決まる」という関係がそのまま現れている。BITCOS という保存形式だけを取り出しても、それが有利かどうかは決まらない。ゼロ率 29.66% の Bonsai 27B では \(2-0.2966=1.7034\) bit/weight となり、five-trit packing の 1.625 bit/weight より大きい。一方、ゼロ率 51.48% の CAT-Q Qwen3-1.7B では \(2-0.5148=1.4852\) bit/weight となり、大きく下回る[9]。同じ構造変更でも、観測された分布によって利益の符号そのものが逆転する。
さらに、1.625 bit/weight を下回る条件と、\(\log_2 3\approx1.585\) bit/weight を下回る条件は一致しない。後者について、
\[
2-z<\log_2 3
\]
を解くと、
\[
z>2-\log_2 3\approx0.415
\]
となる。約 41.5% を超えるゼロ率が必要である。37.5% と約 41.5% という二つの境界が現れるのは、比較対象が異なるためである。1.625 bit/weight は 128 重み単位の five-trit packing という実装上の保存量であり、約 1.585 bit/weight は三値が等確率で現れる場合の情報量である。
この違いは、「1.58 ビットの壁を破った」という表現を読むときにも必要になる。BITCOS は \(-1\)、\(0\)、\(+1\) という状態集合を 3 未満へ減らしたわけではない。実モデルでは三つの状態が等確率で使われていないという観測結果を利用し、その非一様な分布に合わせて保存構造を変更した。1.4852 bit/weight は、状態数が変わったことを示す数字ではなく、特定の分布に対して BITCOS が必要とする三値記号部分の保存量である。
同時に、BITCOS は Shannon エントロピーそのものを達成する一般的なエントロピー符号でもない。presence bitmap はゼロ率に関係なく各重みに 1 ビットを割り当てるため、「ゼロか非ゼロか」という二値分布に偏りがあっても、その偏りをさらに圧縮してはいない。非ゼロ重みについても \(+1\) と \(-1\) を 1 ビットで表すため、正負の分布に偏りがあっても符号長は変化しない。
BITCOS がこの圧縮余地を残す理由は、保存量だけを最小化することが目的ではないからである。presence bitmap と sign vector という単純な構造であれば、非ゼロ位置と正負をビット操作によって取り出し、CPU や GPU の演算カーネルから直接利用できる。より複雑なエントロピー符号によって保存量をさらに減らせても、逐次的な状態更新や可変長境界の解析によって復号処理が増えれば、LLM 推論では転送量削減の利益を失う可能性がある。
構造振動モデルの記述へ戻せば、29 モデルから得られたゼロ率は \(O_t\) に相当する観測であり、その観測を受けて five-trit packing から presence bitmap と sign vector へ保存構造を変更する操作が \(U_t\) に相当する。更新後の \(S_{t+1}\) はモデルごとに異なる bit/weight を持つ。ゼロ率が低いモデルでは旧構造のほうが小さく、ゼロ率が高いモデルでは BITCOS のほうが小さいため、観測値を抜きに「新しい方式のほうが優れている」とは決められない。
この事例が中心命題へ与える具体性は、圧縮によって複雑さが消えるのではなく、どこへ配置するかが変わる点にある。BITCOS は実分布を利用して保存するビット数を減らす。その代わり、推論時には presence bitmap と sign vector から元の三値を取り出す処理が必要になる。保存側で得た利益がシステム全体の利益になるかどうかは、この復号処理まで含めて評価する必要がある。
6. 圧縮で消えた複雑さは復号処理へ移る
BITCOS では、ゼロ率が高いほど三値記号部分の保存量が小さくなる。たとえばゼロ率 50% なら、presence bitmap の 1 bit/weight と sign vector の 0.5 bit/weight を合わせて 1.5 bit/weight になる。固定 2 ビット表現と比べれば、三値記号部分の読み出し量は 25% 少ない。しかし、保存形式が短くなったことと、演算器がその形式をそのまま利用できることは別の条件である。
固定 2 ビット表現なら、各重みは一定位置から直接読み出せる。BITCOS では、presence bitmap を読んで各位置がゼロか非ゼロかを判定し、非ゼロの場合だけ sign vector から対応する正負を取り出す必要がある。保存側では不要になった符号ビットが、実行側では「どの位置に符号ビットが存在するか」を解釈する処理へ置き換わる。
8 重みのうち 4 個が非ゼロなら、sign vector には 4 個分の符号しか存在しない。演算時には、presence bitmap の 1 ビットと sign vector の現在位置を対応させながら、
\[
0,\quad +1,\quad -1
\]
のどれを演算へ渡すかを決める必要がある。保存形式から見れば符号情報を必要な位置だけへ集約したことになるが、演算器から見れば固定位置に存在していた情報を動的に再配置する処理が加わったことになる。
この構造は BITCOS 固有のものではない。ニューラルネットワーク圧縮では、保存形式を小さくした後、その構造を実行系がどのように利用するかという問題が繰り返し現れてきた。Deep Compression は、枝刈り、量子化、Huffman 符号化を組み合わせ、接続数、重み表現、符号長のそれぞれから保存量を削減した[12]。一方、圧縮された重みを実行前に通常の密行列へ完全展開すれば、保存時に得た疎性や重み共有の構造を演算時には利用できない。
EIE は、この問題に対して Deep Compression で得られた疎行列と重み共有を直接処理する推論エンジンを提案した[13]。ゼロになった接続を読み出してから捨てるのではなく、圧縮されたインデックスから必要な非ゼロ要素だけを取得し、共有された重みを参照しながら演算する。保存形式が持つ疎性を実行経路へ維持することで、保存量の削減をメモリー転送量と演算量の削減へ接続している。
SCNN も、疎な重みと活性値を専用データフローで扱い、ゼロ値の保存、転送、乗算を避ける構造を採用した[14]。ここでも、ゼロを削除した疎表現だけで高速化が成立するわけではない。非ゼロ要素の位置を管理し、それらを正しい出力位置へ累積するためのデータフローと制御構造が必要になる。密行列では暗黙に決まっていた位置関係が、疎表現では明示的なインデックス処理へ移る。
この変換を整理すると、圧縮によって削除されたものと、その代わりに必要になるものが対応している。
| 方式 | 保存側で削減するもの | 固定表現では暗黙だった情報 | 実行側で必要になる構造 | 性能へ変換する条件 |
|---|---|---|---|---|
| Deep Compression | 接続数、重み表現、符号長を削減する。 | 密行列では要素位置と重み値を固定配置から取得できる。 | 疎インデックス、共有重み、圧縮符号を解釈する処理が必要になる。 | 圧縮構造を展開せず利用できる実行系が必要になる。 |
| EIE | ゼロ接続と重複する重み値の保存・転送を削減する。 | 密行列では行列位置から演算対象を直接決定できる。 | 非ゼロ要素のインデックス処理と共有重みの参照が必要になる。 | 疎性と重み共有を直接演算へ接続できる必要がある。 |
| SCNN | ゼロ重みとゼロ活性値の保存、転送、乗算を削減する。 | 密なデータフローでは演算位置と累積先が規則的に決まる。 | 非ゼロ要素の位置管理と疎データフローが必要になる。 | ゼロを実際に転送・演算経路から除外できる必要がある。 |
| bitnet.cpp | 三値重みの保存量とメモリー転送量を削減する。 | 高精度重みでは数値表現をそのまま一般的な演算器へ渡せる。 | 三値表現を展開しながら計算する専用カーネルが必要になる。 | 低ビット表現から直接演算できる実装が必要になる。 |
| BITCOS | ゼロ重みに対応する sign bit の保存を削減する。 | 固定長表現では各位置に値を復元するための全ビットが揃っている。 | presence bitmap と sign vector を対応させる復号処理が必要になる。 | 追加の復号処理よりメモリー転送量削減の利益が大きい必要がある。 |
三値 LLM でも同じ構造が現れる。bitnet.cpp は BitNet b1.58 の低ビット重みを CPU 上で直接扱う専用カーネルを実装している[15]。三値重みを毎回一般的な高精度形式へ完全展開してから既存の行列演算へ渡すのでは、低ビット表現によって減らしたメモリー転送量の一部を再び増やすことになる。保存形式と演算カーネルを接続することで、圧縮状態を維持したまま計算へ進める。
BITCOS も同様に、AVX-512、AVX2、Intel Xe2 GPU それぞれの実行特性に合わせた復号・演算カーネルを実装している[9]。presence bitmap と sign vector は保存量を減らすためのデータ構造であると同時に、推論カーネルが直接処理する入力形式でもある。保存形式だけを設計して後から汎用演算器へ接続するのではなく、どの命令で bitmap を処理し、どの単位で sign vector を展開し、どの時点で行列演算へ統合するかまでが方式の一部になる。
この関係から、圧縮に伴う「複雑さの移動」を具体的に定義できる。固定長表現では、要素位置と値の対応をメモリー配置そのものが保持している。圧縮形式では、その対応の一部をビット列から削り、より短い表現へ変換する。その代わり、削った対応関係を復元する規則をアルゴリズム、インデックス、状態、テーブル、専用命令などの形で実行系へ持たせる。
BITCOS なら、この移動は特に明確である。固定 2 ビット表現では、各位置に三値を区別するためのビットが常に存在する。BITCOS はゼロ位置から sign bit を削除するため、保存量は \(2-z\) bit/weight まで減る。その代わり、sign vector の何番目のビットが元の何番目の重みに対応するかは presence bitmap を解釈しなければ分からない。固定配置に埋め込まれていた位置対応が、復号処理へ移されたことになる。
この移動は、複雑さの量が常に一定に保存されるという意味ではない。圧縮前に 1 ビットとして存在した情報と、圧縮後に必要になる 1 命令を同じ単位で比較することはできない。CPU の命令セット、ベクトル幅、キャッシュ構造、GPU の実行モデル、復号アルゴリズムによって、同じ保存形式でも処理コストは変化する。「複雑さの移動」は保存量と計算量が一対一に変換される法則ではなく、圧縮によって系のどの構成要素が仕事を引き受けるかが変わるという構造上の記述である。
この限定を入れても、設計上の帰結は変わらない。bit/weight だけを最適化すると、保存形式を短くするために追加したインデックス処理、状態管理、復号命令、専用カーネルのコストが評価から抜ける。逆に復号処理だけを単純化して固定長表現へ戻せば、メモリー占有量と転送量が増える。低ビット推論では、保存側と実行側のどちらか一方を独立して最小化するのではなく、両者を一つの経路として評価する必要がある。
構造振動モデルの表現を使えば、この変化は構造を削った後に新しい制約が観測される過程として読める。重み分布 \(O_t\) を利用して保存構造 \(S_t\) を圧縮すると、メモリー転送量は減少する。一方、更新後の構造 \(S_{t+1}\) では復号命令という新しい処理が現れ、その実行時間が次の観測対象になる。保存側の冗長性を削った結果、以前は支配的でなかった復号処理が新しい律速条件になり得る。
圧縮によって複雑さが消えるというより、メモリー配置が担っていた仕事の一部を実行系が引き受ける。Deep Compression、EIE、SCNN、bitnet.cpp、BITCOS に共通するのは、保存量の削減を実際の性能へ変換するために、圧縮後の構造を直接扱う実行経路が必要になることである。低ビット設計の対象は重みの bit/weight だけではなく、保存表現と復号経路を合わせた一つの実行構造になる。
7. 最小 bit/weight が最小システムを意味するわけではない
保存形式の議論では、三値記号部分の bit/weight と、実際にモデルを再構成するための保存量を分ける必要がある。BITCOS で最小値を記録した CAT-Q Qwen3-1.7B は、ゼロ率 51.48% により記号部分が 1.4852 bit/weight になる[9]。
しかし、同モデルでは 128 重みごとに 16 ビットの尺度を保存する[9]。尺度だけで、
\[
\frac{16}{128}=0.125
\]
bit/weight が加わるため、尺度込みでは 1.6102 bit/weight になる。1.4852 bit/weight は三値記号部分の値であり、モデル全体の平均ビット幅ではない。
既稿の Bonsai 8B でも、公称される低ビット表現、尺度を含む主要重み領域、GGUF ファイル全体を分けて扱った[16]。同じ「モデルは何ビットか」という問いでも、どの領域を数えているかによって答えが変わる。
| 層 | 含むもの | CAT-Q Qwen3-1.7B の例 | 追加される構造 |
|---|---|---|---|
| 状態集合 | \(-1\)、\(0\)、\(+1\) の三値を含む。 | 三値という状態数自体は変わらない。 | 量子化規則が必要になる。 |
| 記号部分 | presence bitmap と sign vector を含む。 | 1.4852 bit/weight となる。 | BITCOS の復号規則が必要になる。 |
| 尺度込み重み | 記号部分と共有尺度を含む。 | 1.6102 bit/weight となる。 | 尺度の配置と適用処理が必要になる。 |
| モデル全体 | その他のテンソルやメタデータも含む。 | 1.4852 bit/weight だけからは決まらない。 | モデル形式全体の構造が加わる。 |
ここでも、圧縮が単純化と同義ではないことが分かる。記号部分を短くするほど、それを復元する規則、尺度、ブロック境界、メタデータといった別の構造が必要になる場合がある。
設計判断として重要なのは、最小の bit/weight を単独で選ぶことではなく、必要な付加情報と復号経路まで含めて対象範囲を揃えることである。記号部分だけを比べるなら 1.4852 と 1.625 を比較できる。実際の重み保存量を比べるなら尺度を加える。モデルファイルや常駐メモリーを比べるなら、さらに他の構成要素を含める。
8. 同じ圧縮形式でも実行環境によって損得が逆転する
保存量を減らした結果が実行時間の短縮になるかどうかは、圧縮された重みをどのハードウェアで処理するかによって変わる。LLM の自己回帰デコードでは、1 トークンを生成するたびに各層の重みを参照する。特に小さなバッチでは行列ベクトル積が中心になり、同じ重みを多数の入力へ再利用する余地が小さいため、演算器の最大計算性能より先にメモリーから重みを供給する速度が上限へ達しやすい。
この条件では、重み 1 個当たりの保存量を減らすことが、そのままメモリーから転送するデータ量の削減につながる。たとえば固定 2 bit/weight の重みを 1.5 bit/weight へ減らせば、記号部分だけを見た転送量は 25% 減る。同じ個数の重みを処理するなら、メモリー帯域が律速している環境では、この削減分だけデータ供給時間を短縮できる余地が生まれる。
一方、BITCOS ではデータ量を減らすために presence bitmap と sign vector へ保存形式を分解している。演算時には bitmap から非ゼロ位置を判定し、対応する sign bit を取り出し、三値として演算へ渡す必要がある。固定 2 ビット表現では不要だったビット操作や展開処理が実行経路へ追加されるため、圧縮によってメモリー側の仕事を減らしながら命令処理側の仕事を増やす構造になる。
この交換関係を整理するために使えるのが Roofline モデルである。Roofline は、実行性能の上限を、演算器そのものの性能上限と、メモリー帯域からデータを供給できる性能上限の小さいほうで捉える[17]。概念的には、
\[
P
=
\min\left(
P_{\mathrm{peak}},
\beta I
\right)
\]
と表せる。\(P\) は到達可能な性能、\(P_{\mathrm{peak}}\) は演算器側の性能上限、\(\beta\) はメモリー帯域、\(I\) は 1 バイトのデータ転送当たりに実行できる演算量を表す演算密度である。演算密度が低い領域では \(\beta I\) が小さいためメモリー帯域が性能を決め、演算密度が高くなると \(P_{\mathrm{peak}}\) が上限になる。
低ビット重みは、この式の \(I\) を実質的に押し上げる。同じ数の重みを使って同じ行列ベクトル積を行う場合、重み 1 個当たりの転送バイト数が減れば、1 バイト当たりに実行できる演算量は増える。そのため、メモリー帯域律速の領域では、重みを小さくすることで Roofline 上の性能上限を引き上げられる。
ただし、BITCOS の復号命令はこの単純な Roofline 上の改善だけでは表現しきれない。転送量を減らす一方で、bitmap 展開、符号抽出、並べ替えなどの命令が追加されるからである。圧縮前にはメモリー帯域が律速していた処理でも、転送量を十分に減らすとメモリー待ちが短くなり、今度は復号命令の処理時間が支配的になる場合がある。
この変化は、圧縮率が上がるほど性能も単調に上がるという関係を崩す。圧縮によって減らせる転送時間には下限がある一方、復号処理は圧縮形式を利用する限り残る。ある地点までは転送量削減の利益が追加命令を上回るが、メモリー側の待ち時間が十分に小さくなると、追加命令の占める割合が大きくなる。
BITCOS 論文の評価では、この境界が実際のハードウェア差として現れている。64 コアの Intel Xeon Platinum 8592+ では、実モデルで観測されたゼロ率の範囲において、2 ビット参照カーネルに対して約 1.14～1.28 倍の行列ベクトル積性能を示した[9]。多数のコアが同時に重みを要求するため、共有されるメモリー帯域の制約が大きく、重み転送量の削減が性能向上へ結びつきやすい。
24 コアの Intel Core Ultra 9 285K でも、BITCOS は約 1.13～1.27 倍の性能を示した[9]。ここでも行列ベクトル積の実行時間に占める重み転送の割合が大きいため、presence bitmap と sign vector を処理する追加命令を支払っても、メモリーから読むデータ量を減らす利益が上回った。
一方、8 コアの Intel Core Ultra 7 258V では関係が逆転した。評価されたゼロ率の範囲で、BITCOS は 2 ビット参照実装より遅くなった[9]。この環境では、少数の CPU コアに対して利用できるメモリー帯域が相対的に大きく、重み供給が先に詰まりにくい。そのため BITCOS が削減するメモリー転送時間より、presence bitmap と sign vector を展開する命令時間のほうが支配的になった。
| 実行環境 | 圧縮前に大きいコスト | BITCOS が減らすコスト | BITCOS が追加するコスト | 観測された帰結 |
|---|---|---|---|---|
| Xeon Platinum 8592+ | 多数コアが共有するメモリー帯域の制約が大きい。 | 三値重みの転送量をゼロ率に応じて削減する。 | bitmap 展開と符号復元の命令を追加する。 | 転送量削減の利益が追加命令を上回り、2 ビット参照実装より約 1.14～1.28 倍高速になる。 |
| Core Ultra 9 285K | 行列ベクトル積で重み転送の影響が大きい。 | 低い bit/weight によって必要帯域を減らす。 | presence bitmap と sign vector の復号処理を追加する。 | 転送量削減が優勢となり、約 1.13～1.27 倍の性能向上を示す。 |
| Core Ultra 7 258V | 少数コアに対してメモリー帯域に相対的な余裕がある。 | 転送量を減らすが、元からメモリー待ちの比率が小さい。 | 復号命令の処理時間が相対的に大きくなる。 | 命令処理側が律速し、2 ビット参照実装より低速になる。 |
この結果では、同じ BITCOS、同じゼロ率、同じ bit/weight でも、性能上の価値がハードウェアによって変わる。保存形式そのものは同じでも、削減されるコストと追加されるコストの比率が異なるためである。多数コアでメモリー帯域を奪い合う環境では 1 バイトの削減価値が高く、少数コアに十分な帯域が供給される環境では同じ 1 バイトの削減価値が小さくなる。
この関係は、圧縮形式の評価単位を bit/weight から実行時間へ広げる必要があることを示している。BITCOS の \(B(z)=2-z\) はモデル分布から保存量を計算できるが、その値だけから速度向上率は決まらない。同じ \(B(z)\) でも、メモリー帯域、コア数、命令セット、ベクトル幅、復号実装が違えば、削減した転送時間と追加した命令時間の比が変わる。
構造振動モデルの変数へ対応させると、この依存関係を明確に分離できる。ゼロ率や符号分布はモデルから得られる観測 \(O_t\) であり、メモリー帯域、コア数、利用可能な命令は環境 \(C_t\) に属する。BITCOS への変更を介入 \(U_t\) とすると、その結果として得られる保存・実行構造 \(S_{t+1}\) の評価には \(O_t\) と \(C_t\) の両方が必要になる。
このとき本稿で扱う設計上の最適点は、最小の bit/weight を持つ構造ではなく、現在のモデル分布と実行環境の下で保存量削減の利益と復号処理の負担を合わせて評価した結果として決まる。Xeon Platinum 8592+ では BITCOS 側へ構造を移す利益が観測され、Core Ultra 7 258V では同じ圧縮形式が不利になる。環境 \(C_t\) が変化すると、同じ圧縮形式でも評価が反転し得る。
構造振動モデルとの接続が最も明確になるのもこの点である。ある観測条件の下で構造を単純化すると、以前のボトルネックが緩和され、別の場所にあった制約が表面化する。BITCOS では重み転送量を削ることでメモリー帯域の制約を弱めるが、その結果として復号命令が新しい律速条件になり得る。構造更新は制約そのものを消すのではなく、どの制約が支配的になるかを変える。
低ビット推論の最適点が条件付きの安定構造になる理由はここにある。重み分布だけを観測して最小の保存形式を選んでも、実行環境がその形式を効率よく処理できなければシステム全体では不利になる。モデル側の分布とハードウェア側の制約を同時に観測し、その組み合わせに対して保存量と復号処理のどちらが支配的になるかを評価して初めて、圧縮構造の価値を決められる。
9. 複雑さの移動は BITCOS だけの現象ではない
BITCOS で見た「保存側を単純化すると、別の場所へ処理が移る」という構造は、低ビット LLM 全体にも現れる。量子化では、すべての値を同じ精度へ一律に押し込むほど設計が単純になるとは限らない。特定の外れ値、特定の次元、特定のテンソルだけが量子化誤差を支配する場合、その部分を例外として分離したほうが、系全体では低ビット化しやすくなる。
このとき設計対象になるのは、「難しい部分を取り除けるか」ではなく、「難しさをどこへ置けば全体の制約を満たせるか」である。BITCOS では、ゼロ率の偏りを利用するために三値列を presence bitmap と sign vector へ分解した。保存量は減るが、位置対応と符号復元の責務が復号側へ移る。同じように、他の低ビット方式でも、局所的な困難を別の計算経路や別のテンソルへ移すことで全体を成立させている。
LLM.int8() はその典型である。大規模 Transformer では、活性値の一部に大きな外れ値が現れ、それらまで一律に 8 ビットへ量子化すると誤差が大きくなる。LLM.int8() は、この外れ値を含む一部の次元だけを高精度経路へ分離し、大部分の行列積を 8 ビットで処理する[18]。
ここで高精度計算そのものが消えるわけではない。従来なら行列全体を高精度で処理していたところを、外れ値が存在する限定された次元へ高精度計算を集中させる。全体の処理を低ビット化する代わりに、例外部分だけを別経路として残す構造である。
この設計では、低ビット化の利益と例外処理のコストが同時に存在する。通常部分を 8 ビット化することでメモリー転送量と演算コストを減らせる一方、外れ値を検出し、高精度経路へ分岐し、その結果を統合する処理が加わる。複雑さが消えたのではなく、行列全体に広がっていた高精度処理を局所的な例外経路へ集約している。
SmoothQuant は、さらに異なる方向へ複雑さを移す。量子化時に問題になりやすいのは、重みよりも活性値側に大きな外れ値が現れることである。活性値の分布が広いと、1 つの量子化尺度で小さい値と大きい値を同時に表現することが難しくなり、8 ビット化したときの量子化誤差が増える。
SmoothQuant は、活性値と重みの積を保つ等価変換を使い、量子化の難しさを活性値側から重み側へ移す[19]。概念的には、活性値 \(X\) と重み \(W\) の積、
\[
Y=XW
\]
に対して、チャネルごとの尺度 \(s\) を導入し、
\[
Y
=
(X\,\mathrm{diag}(s)^{-1})
(\mathrm{diag}(s)W)
\]
と変形する。積としての結果は維持したまま、活性値側の大きな値を縮め、その分を重み側へ移す。活性値の量子化範囲が扱いやすくなる一方、重み側の分布は変化する。
この方式でも、量子化困難性そのものを消去しているわけではない。活性値側に集中していた大きな値の影響を、量子化しやすい重み側へ再配置している。重みは事前に固定されているため、推論前に変換や尺度調整を済ませやすい。時間ごとに変化する活性値から、事前処理可能な重みへ問題を移すことで、W8A8 推論を成立させる構造である。
BITCOS、LLM.int8()、SmoothQuant を並べると、移動している対象と移動先が異なることが分かる。
| 方式 | 元の制約 | 移動する対象 | 移動先 | 局所的に単純化される部分 | 新しく責務を負う部分 |
|---|---|---|---|---|---|
| BITCOS | 三値を均等に保存するとゼロ率の偏りを利用できない。 | ゼロ位置と正負情報の表現を分離する。 | presence bitmap と sign vector へ再配置する。 | 三値記号部分の平均保存量を減らせる。 | 復号カーネルが位置対応と符号復元を担う。 |
| LLM.int8() | 外れ値を含む全要素を一律に 8 ビット化すると誤差が大きくなる。 | 高精度計算を必要とする部分を分離する。 | 外れ値次元だけを処理する高精度経路へ集約する。 | 大部分の行列積を 8 ビットで処理できる。 | 例外経路が外れ値処理と結果統合を担う。 |
| SmoothQuant | 活性値の外れ値が 8 ビット量子化を難しくする。 | チャネルごとのスケール差を移す。 | 活性値側から重み側へ再配置する。 | 活性値の量子化範囲を狭められる。 | 重み側が移されたスケールを保持する。 |
三つの方式には、対象、数式、実装方式の違いがある。BITCOS は保存形式の問題を扱い、LLM.int8() は高精度例外経路を設け、SmoothQuant は等価変換によって量子化困難性を別テンソルへ移す。それでも設計構造には共通点がある。全要素を同じ条件で処理する対称な構造を維持するより、観測された困難の位置に応じて責務を分離したほうが、系全体の制約を満たしやすくなる。
ここで使っている「複雑さの移動」は、複雑さが一定量だけ保存されるという意味ではない。BITCOS の追加復号命令、LLM.int8() の高精度経路、SmoothQuant の尺度変換を共通の単位で測ることはできない。アルゴリズム、データ構造、実装、命令セットによって、それぞれのコストは異なる。
共通しているのは、局所的な単純化が、別の構成要素へ新しい責務を与えることで成立している点である。BITCOS は保存形式を単純化する代わりに復号器へ仕事を移す。LLM.int8() は大部分の行列積を低ビット化する代わりに外れ値処理を限定的な高精度経路へ移す。SmoothQuant は活性値を量子化しやすくする代わりに、そのスケール差を重み側へ移す。
この共通構造を使うと、低ビット設計の比較軸を bit/weight だけから拡張できる。どの表現が最小かを見るだけでは、何が例外化され、どの処理が別経路へ移り、どの構成要素が新しい責務を負ったかが見えない。低ビット化によって得られる利益は、削減された保存量や演算量と、それを成立させるために追加された構造の組み合わせとして評価する必要がある。
構造振動モデルの観点では、これらは「困難を削除する」より「観測された制約へ構造を適応させる」と表現したほうが近い。外れ値、ゼロ率、チャネルごとの分布差という観測結果に応じて、処理の配置を変更し、全体として別の安定構造へ移る。低ビット化は単一の数値を下げる操作ではなく、制約の位置を読み取り、それに合わせて責務を再配置する設計問題になる。
10. 低ビット表現の最適点はモデル分布と実行環境で変わる
ここまでの議論を一つの過程としてまとめると、低ビット LLM の設計は単純なビット幅削減ではなく、情報と処理責務の配置を段階的に更新する問題として読める。
\[
\text{高精度な状態}
\longrightarrow
\text{量子化された状態}
\longrightarrow
\text{実分布の観測}
\longrightarrow
\text{保存構造の再編}
\longrightarrow
\text{復号経路の追加}
\longrightarrow
\text{実行環境による再評価}
\]
最初の量子化では、高精度な重みが持っていた区別の一部を捨て、有限個の代表値へ写す。三値量子化なら、結果として残るのは \(-1\)、\(0\)、\(+1\) という状態集合である。この段階で失われるのは元の高精度値に関する情報であり、量子化誤差もここで生じる。
その後の圧縮では、量子化済みの状態集合を維持したまま、実際の出現頻度を観測する。三値が均等に使われていなければ、その偏りを保存形式へ反映できる。BITCOS は、\(0\) の出現率を観測し、各位置のゼロ・非ゼロを presence bitmap へ、非ゼロ値の正負だけを sign vector へ分離する。この再編によって、三値そのものを減らさずに平均保存量を下げる[9]。
保存量の削減は、それだけで系全体の単純化を意味しない。固定配置に埋め込まれていた位置対応や符号情報の一部を省けば、その対応を復元する規則が必要になる。BITCOS では presence bitmap と sign vector の対応を解釈する復号処理が加わる。量子化後の情報を維持したまま保存側を短くするほど、保存形式を解釈する責務が実行側へ移る。
この時点で、低ビット表現の評価軸は bit/weight だけでは足りなくなる。三値記号部分の保存量、尺度などの付加情報、復号命令、メモリー転送量、演算カーネル、ハードウェアの帯域と命令処理能力を同じ経路の中で評価する必要がある。ある階層で保存量を減らしても、別の階層で追加された処理が大きければ、システム全体の利益は小さくなる。
BITCOS の実測結果は、この依存関係を具体的に示す。ゼロ率 51.48% の CAT-Q Qwen3-1.7B では三値記号部分が 1.4852 bit/weight まで下がる一方、ゼロ率 29.66% の Bonsai 27B では 1.7034 bit/weight となり、128 重み単位の five-trit packing が持つ 1.625 bit/weight を上回る[9]。保存形式そのものが同じでも、モデル側の分布だけで損益が反転する。
さらに、重み分布を固定しても、ハードウェアを変えると評価が変わる。Xeon Platinum 8592+ や Core Ultra 9 285K では、重み転送量の削減が追加の復号命令を上回り、2 ビット参照実装より高い行列ベクトル積性能を示した。一方、Core Ultra 7 258V ではメモリー帯域に相対的な余裕があり、復号命令が先に律速して BITCOS が低速になった[9]。
モデル分布とハードウェア条件を合わせると、低ビット表現の選択は次のように整理できる。
| 観測条件 | 保存側で起きること | 実行側で起きること | 有利になりやすい構造 | 安定点を変える要因 |
|---|---|---|---|---|
| ゼロ率が低い | sign vector が長くなり、BITCOS の保存量削減が小さくなる。 | 復号処理は必要なまま残る。 | five-trit packing など単純な固定レート表現が有利になり得る。 | モデルの再学習や量子化方式によって重み分布が変化すると境界が動く。 |
| ゼロ率が高い | 非ゼロ重みが減り、BITCOS の三値記号部分が短くなる。 | presence bitmap と sign vector の復号処理が加わる。 | 分布適応型の BITCOS が有利になりやすい。 | 復号処理が支配的になると保存量削減の利益が頭打ちになる。 |
| メモリー帯域が律速 | 少ない bit/weight が直接転送量削減へつながる。 | 追加命令をメモリー待ち時間の削減で吸収しやすい。 | 高い圧縮率を持つ保存形式が性能向上へ結びつきやすい。 | 転送量を減らすほど復号命令の比率が高まり、律速点が移動する。 |
| 命令処理が律速 | 追加の圧縮による転送量削減の価値が小さくなる。 | bitmap 展開や符号復元が処理時間を支配する。 | 復号処理の少ない固定形式が有利になり得る。 | 命令セット、ベクトル幅、専用カーネルの改善によって境界が再び動く。 |
この表で扱うのは、構造振動モデルで定義した安定性そのものではなく、対象モデルの分布と対象ハードウェアの制約の下で、保存量と復号コストを合わせて評価した設計上の最適点である。構造振動モデルにおける安定構造は、大改修なしでも運用が継続できる状態として別に捉える。環境条件が変われば、その構造も再び評価対象になる。
構造振動モデルの変数へ対応させると、この関係を一つの更新則として読める。現在の保存・実行形式が \(S_t\)、メモリー帯域や命令セットが \(C_t\)、ゼロ率や実測性能が \(O_t\)、符号化形式や復号カーネルの変更が \(U_t\) に対応する。更新後の構造 \(S_{t+1}\) は、以前より保存量が小さいという理由だけで採用されるのではなく、観測された分布と環境の組み合わせに対して全体として有利かどうかで評価される。
この構造では、単純化の後に新しい制約が現れる。高精度な状態を量子化すると表現空間は縮小するが、量子化誤差が生じる。量子化後の分布を利用して保存構造を圧縮すると転送量は減るが、復号処理が生じる。復号処理を専用カーネルで高速化すると、別の命令資源やデータ配置が制約になる。ある場所の冗長性を削るたびに、以前は目立たなかった別の制約が相対的に大きくなる。
そのため、低ビット設計の評価順序も階層化する必要がある。最初に量子化後の状態集合を確認し、次に実際の頻度分布を測る。その分布から保存形式を選び、尺度やメタデータを含む実効保存量を計算する。さらに復号経路を実装し、対象ハードウェア上でメモリー転送と命令処理のどちらが律速するかを測定する。各段階の数値は次の段階への入力であり、一つの bit/weight だけで最終評価まで代替できない。
BITCOS が 1.58 bit/weight から 1.4852 bit/weight へ下げたこと自体は、この過程の一断面にすぎない。その差は約 0.10 bit/weight であるが、設計上の意味は数字の大きさより、その数字がどの観測から生まれたかにある。実モデルでゼロが均等分布より多いことを観測したため、三値を均等に扱う保存構造を維持する必要がなくなった。保存構造を変更すると新しい復号処理が生まれ、その処理を含めた性能評価によって、さらに適用可能なハードウェア条件が限定された。
この一連の変化を「圧縮」とだけ呼ぶと、保存量の減少だけが前面に出る。構造として見ると、量子化、分布観測、符号化、復号、実行環境の各層が相互に依存している。ある層を単純化すると、別の層が新しい責務を引き受け、その責務が次の観測対象になる。
量子化後の圧縮は、情報をさらに捨てる操作ではなく、観測された分布を使って保存上の冗長性を削り、その代わりに復号側へ処理責務を移す構造変換として理解できる。どの配置が有利になるかは、モデル分布、保存形式、付加情報、復号方式、メモリー帯域、命令処理能力の組み合わせによって変わる。低ビット LLM の最適点は最小の bit/weight という固定値ではなく、その条件下で保存と実行の両方を評価して決まる設計上の最適点である。
参考文献
- id774, 量子化について詳しく解説する（2026-08-07）. https://blog.id774.net/entry/2026/08/07/5472/
- Claude E. Shannon, A Mathematical Theory of Communication（1948-07）. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x
- id774, 理解・設計・制度はなぜ単純化へ収束するのか（2026-02-16）. https://blog.id774.net/entry/2026/02/16/3660/
- id774, 構造振動モデルとは何か（2026-02-17）. https://blog.id774.net/entry/2026/02/17/3666/
- id774, 構造振動モデルを数理モデルとして定義する（2026-04-05）. https://blog.id774.net/entry/2026/04/05/4318/
- David A. Huffman, A Method for the Construction of Minimum-Redundancy Codes（1952-09）. https://doi.org/10.1109/JRPROC.1952.273898
- Jorma Rissanen, Glen G. Langdon Jr., Arithmetic Coding（1979-03）. https://doi.org/10.1147/rd.232.0149
- Jarek Duda, Asymmetric numeral systems: entropy coding combining speed of Huffman coding with compression rate of arithmetic coding（2013-11-11）. https://arxiv.org/abs/1311.2540
- Evangelos Georganas, Alexander Heinecke, Pradeep Dubey, Breaking the 1.58-bit Barrier for Ternary LLMs（2026-09-14）. https://arxiv.org/abs/2609.16338
- Shuming Ma, Hongyu Wang, Lingxiao Ma, Lei Wang, Wenhui Wang, Shaohan Huang, Li Dong, Ruiping Wang, Jilong Xue, Furu Wei, The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits（2024-02-27）. https://arxiv.org/abs/2402.17764
- Shuming Ma, Hongyu Wang, Shaohan Huang, Xingxing Zhang, Ying Hu, Ting Song, Yan Xia, Furu Wei, BitNet b1.58 2B4T Technical Report（2025-04-16）. https://arxiv.org/abs/2504.12285
- Song Han, Huizi Mao, William J. Dally, Deep Compression: Compressing Deep Neural Networks with Pruning, Trained Quantization and Huffman Coding（2015-10-01）. https://arxiv.org/abs/1510.00149
- Song Han, Xingyu Liu, Huizi Mao, Jing Pu, Ardavan Pedram, Mark A. Horowitz, William J. Dally, EIE: Efficient Inference Engine on Compressed Deep Neural Network（2016-02-04）. https://arxiv.org/abs/1602.01528
- Angshuman Parashar, Minsoo Rhu, Anurag Mukkara, Antonio Puglielli, Rangharajan Venkatesan, Brucek Khailany, Joel Emer, Stephen W. Keckler, William J. Dally, SCNN: An Accelerator for Compressed-sparse Convolutional Neural Networks（2017-05-23）. https://arxiv.org/abs/1708.04485
- Jinheng Wang, Hansong Zhou, Ting Song, Shaoguang Mao, Shuming Ma, Hongyu Wang, Yan Xia, Furu Wei, 1-bit AI Infra: Part 1.1, Fast and Lossless BitNet b1.58 Inference on CPUs（2024-10-21）. https://arxiv.org/abs/2410.16144
- id774, Bonsai 8B でローカル LLM をミニマムから始める（2026-07-24）. https://blog.id774.net/entry/2026/07/24/5125/
- Samuel Williams, Andrew Waterman, David Patterson, Roofline: An Insightful Visual Performance Model for Multicore Architectures（2009-04）. https://doi.org/10.1145/1498765.1498785
- Tim Dettmers, Mike Lewis, Younes Belkada, Luke Zettlemoyer, LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale（2022-08-15）. https://arxiv.org/abs/2208.07339
- Guangxuan Xiao, Ji Lin, Mickael Seznec, Hao Wu, Julien Demouth, Song Han, SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models（2022-11-18）. https://arxiv.org/abs/2211.10438