AI のモデルを小さくする際には、すべての重みを同じ精度で保存する必要はない。大規模言語モデルには、入力された情報を変換する計算用の重みと、入力に応じて必要な値を取り出す参照テーブルが含まれる場合がある。前者を低ビット化して保存容量を削減し、後者を元の数値精度で保持すれば、モデル全体の容量を抑えながら、一部の情報については量子化による数値の変化を避けられる。ただし、参照テーブルを正確に保存できたことと、その情報を利用したモデルが元と同じ回答を生成することは、異なる条件によって成立する。
たとえば、辞書の内容を一字一句変えずに保存しても、辞書を参照するプログラムが語の選択方法を変更すれば、同じ質問に対して異なる答えが返される場合がある。辞書の内容が正しいことは、語の検索結果が元と一致するための条件の一つになる。しかし、検索した語をどのような文脈で採用し、複数の候補から何を選び、最終的にどのような文章を構成するかは、辞書を利用する側の処理によって決まる。保存された情報と、その情報から生成される結果の間には、参照、変換、選択という複数の処理が存在する。
大規模言語モデルでは、この関係が数値計算として現れる。参照テーブルから取得した値が元モデルと完全に一致していても、その値を受け取るニューラルネットワークの重みが量子化されていれば、途中の計算結果は変化し得る。その変化が後続の層へ伝わると、次に生成する単語や文字の候補に割り当てられる確率も変わる。最も確率が高い候補が入れ替われば、出力される文章そのものが変化する。一方、途中の数値が変化しても、最終的な候補の順位や回答品質が維持される場合もある。数値の一致、出力の一致、回答品質の維持は、それぞれ別の評価対象である。
この構造を具体的に示すのが、DeepSeek-V4.1-Flash-1017 の派生モデルである。このモデルでは、主な計算を担う Backbone に低ビット量子化を適用し、入力に応じて記憶テーブルを参照する Engram には元の MXFP8 精度の値を組み合わせている。公開された派生版には、Backbone の拒否関連表現を変更したものも含まれる。つまり、元モデルから変更された部分と元の値を維持した部分が混在し、モデル全体の出力には複数の変更が関係する構成になっている。
公開者は、Engram の値を元モデルからバイト単位で引き継いだことを検証し、変換処理の正常終了と簡単な推論の動作確認を記録している。バイト一致は、比較対象となった保存値が元の値と一致することを示す。推論の動作確認は、指定された実行環境と入力条件で生成処理が成立したことを示す。これらの結果にはそれぞれ明確な意味があるが、数学的推論、知識問題、長文読解、多言語応答などで元モデルと同じ品質が維持されたかどうかは、対象となる能力を測定する追加の比較が必要になる。
モデルの一部を元の精度で保存できたことは、回答品質が維持されたことを意味しない。保存内容の一致、推論処理の成立、回答品質の維持を分け、それぞれの検証結果がどの性質を直接示しているかを確認する必要がある。特に、低ビット化された Backbone と高精度の Engram を組み合わせた構成では、保存した値の正確性と、その値を利用する計算の正確性を区別することが、モデル全体の性能を判断する条件になる。
1. 情報を正確に保存しても結果が一致するとは限らない
二つのプログラムが同じ数値データを読み込む場合を考える。元のデータと読み込んだデータのバイト列が完全に一致すれば、比較対象となった範囲については、保存値が変更されていないことを確認できる。たとえば、同じ浮動小数点数を読み込み、一方のプログラムは元の精度で計算し、もう一方は途中の演算を低精度で処理する場合、入力データが一致していても最終結果には差が生じ得る。最初のデータが同一であることは、後続の演算が同一であることまで保証する条件ではない。
この差が生じる直接的な原因は、数値演算の途中で扱える値の範囲や精度が変化することである。浮動小数点演算では、計算結果を有限個の表現可能な数値へ丸めるため、同じ入力から出発しても、演算精度や計算順序が異なれば中間結果が変化する場合がある。さらに、その中間結果を後続の計算へ渡すと、数値の差が累積したり、条件分岐や候補選択の結果を変えたりする可能性がある。最終的な出力の違いは、保存データの変化だけでなく、保存後に実行される計算経路からも生じる。
大規模言語モデルでは、入力された文章が複数の処理を通じて出力へ変換される。最初に入力文をトークンと呼ばれる処理単位へ分割し、それぞれを数値表現へ変換する。その数値表現がニューラルネットワークの層を通過し、各層で重みとの演算や非線形変換を受ける。最後に、次に生成するトークンの候補ごとにスコアが計算され、そのスコアをもとに出力が選択される。モデルの一部に参照テーブルが存在する場合、取り出された値もこの計算経路に組み込まれる。
参照テーブルから取り出した値が完全に一致している場合でも、その値を受け取る後続の計算が変更されていれば、最終的なスコアが一致するとは限らない。たとえば、参照テーブルから得た数値が同一でも、その数値と組み合わせる Backbone の重みが量子化によって変化していれば、層の出力に差が生じる。さらに、次の層がその差を受け取ることで、後続の演算結果も変化し得る。参照値の保存精度と、その値を利用した計算結果の精度が分かれるのは、このように参照処理と演算処理が異なる構成要素によって実行されるためである。
この関係を数式で表すため、参照テーブルに保存された値を \(D\)、演算に用いる Backbone の重みを \(W\)、入力を \(x\)、推論時の実行条件を \(c\) とする。実行条件には、数値演算の方法、トークンの選択方法などが含まれる。モデルの出力を \(y\)、入力とモデルの構成要素から出力を生成する処理を \(F\) とすれば、次のように表せる。
\[
y=F(x;D,W,c)
\]
この式は、モデルの出力が参照テーブルの値だけで決まるのではなく、入力、Backbone の重み、実行条件にも依存することを表している。\(D\) が元モデルと一致していても、\(W\) や \(c\) が異なれば、出力 \(y\) には変化が生じ得る。ここでの \(F\) は、ニューラルネットワークの演算だけでなく、参照した情報の統合や最終的なトークンの選択までを含む処理として定義している。
元モデルの参照テーブルと Backbone の重みを \(D_0\)、\(W_0\)、変更後の値を \(D_1\)、\(W_1\) とする。参照テーブルのバイト一致によって \(D_0=D_1\) が確認され、入力と実行条件も同一であったとしても、Backbone の重みが \(W_0\) から \(W_1\) へ変更されていれば、次の出力の一致は追加の検証を必要とする。
\[
F(x;D_0,W_0,c)
\overset{?}{=}
F(x;D_1,W_1,c)
\]
この等式の左辺は元モデルの出力、右辺は変更後のモデルの出力を表す。等号の上の疑問符は、両者の一致が未確認であることを意味する。参照テーブルの値が等しいという条件は、両辺に含まれる一つの変数についての一致を示す。しかし、Backbone の重みまで一致しているとは限らないため、二つの出力の関係はそれぞれの計算結果を調べて判断する必要がある。
数値のわずかな変化が出力に影響する場合を、次トークンの選択で考える。ある入力に対して候補 A と候補 B のスコアがそれぞれ 2.001 と 2.000 であれば、最大スコアを選ぶ方式では候補 A が選択される。ここで Backbone の演算結果が変化し、候補 A のスコアだけが 1.999 になれば、候補 B が選択される。この数値は仕組みを説明するための仮定であり、特定のモデルで測定された値ではない。参照テーブルの内容を一切変更しなくても、後続の演算によって候補の順位が逆転する可能性を示している。
一方、演算結果に差が生じても、候補の順位が変わらなければ同じトークンが選択される場合がある。候補 A のスコアが 2.001 から 2.0005 へ変化しても、候補 B のスコアが 2.000 のままであれば、最大スコアを選択する結果は変わらない。数値の差が生じたことと、実際に出力が変化したことは区別できる。さらに、トークンの選択が確率的に行われる場合には、同じ候補分布から異なるトークンが選ばれることもある。出力差をモデルの改変による影響として評価するには、入力、計算精度、選択方式、乱数の条件を揃える必要がある。
出力された文字列の一致と回答品質の維持にも違いがある。たとえば、ある地理的な質問に対して二つのモデルがともに正しい都市名を返した場合、その質問について正答が得られたことは確認できる。しかし、同じ文字列が出力されたという事実だけでは、両モデルの内部計算が同一だったことや、別の質問でも正答率が一致することまでは分からない。反対に、二つのモデルが異なる言い回しで同じ正しい内容を回答した場合、文字列が異なっていても回答品質が維持されている可能性がある。出力の一致率と回答の正確性は、異なる指標として評価する必要がある。
保存値、計算処理、出力、回答品質の関係を整理すると、それぞれの検証に対応する証拠の範囲が明確になる。
| 検証対象 | 確認する内容 | 検証によって直接言えること | 追加で必要な確認 |
|---|---|---|---|
| 保存値の一致 | 元の重みと保存後の重みをバイト単位で比較する。 | 比較対象となった重みの値が一致している。 | 参照処理と後続の演算が元モデルと同じ結果を生成するか確認する必要がある。 |
| 推論処理の成立 | モデルを読み込み、指定した入力に対して生成処理を実行する。 | 指定した実行環境と入力条件で推論処理が完了した。 | 異なる入力や文脈長でも正常に動作し、期待する結果が得られるか確認する必要がある。 |
| 出力の一致 | 入力と実行条件を揃え、元モデルと変更後のモデルの出力を比較する。 | 比較した条件における出力の一致または差異が確認できる。 | 異なる表現でも同等の正確性を持つ場合を含め、回答内容を評価する必要がある。 |
| 回答品質の維持 | 知識問題、推論問題、コード生成などについて同一条件で評価する。 | 評価した課題と指標について、元モデルとの性能差を測定できる。 | 評価対象外の能力、入力分布、実行環境へ結果を適用できる範囲を確認する必要がある。 |
表の各行は、同じモデルに対して実施できる検証であっても、直接評価する対象が異なることを示している。保存値の比較は、データの変化を調べるための検証である。推論処理の実行は、読み込みから生成までの経路が指定条件で成立することを調べる。出力の比較は、処理結果として何が変化したかを測定する。回答品質の評価では、正答率や問題解決の成功率など、内容に対応する指標を用いて元モデルとの差を判断する。この区別によって、ある検証の成功を別の性質の証明として扱うことを避けられる。
特に、モデルの一部分だけを高精度で保持した場合には、検証の対象範囲を明示する必要がある。Engram の参照テーブルが元モデルとバイト単位で一致していても、その事実が直接保証するのは比較対象となった Engram の保存値である。Backbone の量子化によって変化した数値や、両者を組み合わせた演算結果は、その比較の対象に含まれない。高精度の参照テーブルを利用する設計は、参照テーブル自体に量子化誤差を導入しないという利点を持つが、モデル全体でどのような誤差が残るかは後続の計算によって決まる。
また、元モデルと同じ回答が得られた場合にも、変更後のモデルがあらゆる入力で同等の能力を持つという結論には追加の証拠が必要になる。たとえば、短い事実質問への回答が一致したとしても、複数の情報を組み合わせる推論では、途中の数値差が判断結果へ影響する可能性がある。長文脈では参照される情報や演算の回数が変わり、コード生成では一つのトークンの違いが構文や実行結果を変える場合がある。どの能力が維持されているかを判断するには、入力の種類と評価指標を対応させた比較が必要である。
情報を正確に保存することには、明確な技術的意義がある。元の値を保持することで、その部分の量子化に由来する数値誤差を回避でき、変更後のモデルを評価する際にも、参照テーブルの値が変化した可能性を検討対象から除外できる。ただし、残る演算部分が変更されている場合、最終出力に差が生じる可能性は残る。低ビット化した Backbone と高精度の Engram を組み合わせる構成では、保存値の一致によって固定された条件と、計算結果の比較によって初めて確定する条件を分離することが、モデル全体の能力を検証する出発点となる。
2. 量子化によって何が変わるのか
大規模言語モデルの重みは、学習を通じて調整された多数の数値であり、入力された情報をどのように変換するかを決めている。一般的な浮動小数点表現では、それぞれの重みに一定のビット数を使用する。量子化は、この数値表現をより少ないビット数へ変換し、限られた種類の代表値によって重みを保存する技術である。重みを保存するために必要な容量を削減できる一方、元の値を表現できる範囲や精度が変化するため、後続の計算にも影響が生じ得る。
量子化によって失われる情報は、元の数値どうしを区別するために必要な精度である。たとえば、0.49 と 0.51 という二つの重みがあっても、量子化後に使用できる代表値が 0 と 1 だけであれば、最も近い値へ丸める方式では、それぞれ 0 と 1 に対応する。この場合、元の二つの値の差は 0.02 であったのに対し、量子化後の値の差は 1 になる。逆に、異なる値が同じ代表値へ対応し、元の差が失われる場合もある。既稿では、量子化によって失われる情報を、元の値どうしの区別という観点から整理した[1]。
代表値の選び方によって、保存される値と元の値の差は変化する。たとえば、同じ 2 ビットで保存する場合でも、四つの代表値を一定間隔に配置する方法と、元の重みの分布に合わせて配置する方法では、量子化誤差が異なる。重みが特定の範囲へ集中していれば、その範囲を細かく表現することで平均的な誤差を減らせる可能性がある。一方、広い範囲に分布する重みや、少数の極端な値を含む重みでは、同じ代表値の配置が適切とは限らない。量子化後の数値精度は、使用するビット数に加え、代表値の配置と元の重みの分布によって決まる。
元の重みを \(W\)、量子化した値を演算に使える形へ戻した重みを \(\widehat{W}\)、両者の差を \(\Delta W\) とすると、次の関係になる。
\[
\widehat{W}=W+\Delta W
\]
ここで \(W\) は元モデルの重み、\(\widehat{W}\) は量子化後に再構成された重み、\(\Delta W\) はその差を表す。重みが行列として表現される場合、\(\Delta W\) も同じ大きさの行列となり、それぞれの要素に量子化による数値の変化が記録される。この式は、量子化を元の重みに対する数値的な変更として表したものである。量子化後の値が元の値へ近いほど、重みそのものの近似誤差は小さくなる。
ただし、重みの近似誤差と、その重みを利用した計算結果の誤差は異なる。たとえば、入力ベクトルを \(x\)、重み行列との積によって得られる値を \(z\) とすると、元の計算は \(z=Wx\) で表される。量子化後の重みを使い、同じ入力に対して同じ行列積を計算する場合、元の結果との差は次のようになる。
\[
\Delta z=\widehat{W}x-Wx=\Delta W x
\]
\(\Delta z\) は行列積の出力に生じる差である。この式では、量子化誤差 \(\Delta W\) が入力 \(x\) と組み合わされて初めて、計算結果への影響が決まる。同じ重みの誤差であっても、入力の値が変われば、出力の差も変化する。ある入力では誤差の影響が相殺され、別の入力では複数の誤差が同じ方向へ加算される場合がある。重みの近似精度を評価するだけでは、実際の入力に対する出力誤差を一意に決められない理由は、この入力依存性にある。
大規模言語モデルでは、行列積の結果がさらに別の層へ渡され、注意機構や非線形変換などを通じて処理される。ある層で生じた数値の差は、後続の層で縮小する場合もあれば、別の方向へ変換されて最終的なトークンの選択へ影響する場合もある。特に、複数の候補のスコアが近いときには、小さな数値差によって候補の順位が変化する可能性がある。既稿では、同じ大きさの量子化誤差であっても、誤差が生じる位置、後続の計算で影響が残る期間、誤差の方向によって最終出力への影響が異なることを検討した[2]。
この性質を考慮すると、量子化の設計には少なくとも二つの異なる最適化問題がある。一つは、限られたビット数の中で、それぞれの重みをどの代表値へ対応させるかという問題である。もう一つは、モデル全体で使用できる保存容量が決まっているとき、どの重み群へ何ビットを割り当てるかという問題である。前者は固定された数値表現の中で近似精度を改善する操作であり、後者は異なる数値表現の組み合わせを選択する操作である。
2.1 代表値の選択を最適化する GSQ
GSQ（Gumbel-Softmax Quantization）は、低ビットのスカラー量子化において、各重みをどの量子化値へ対応させるかを最適化する手法である。通常の丸め処理では、あらかじめ決めた代表値の中から近い値を選択する。これに対して GSQ は、Gumbel-Softmax と呼ばれる連続的な近似を利用し、離散的な候補の選択を勾配に基づく最適化で扱えるようにする。さらに、重みをグループに分け、それぞれのグループで使用するスケールも最適化する[3]。
スケールは、量子化で使用する数値の間隔や範囲を調整するための値である。たとえば、同じ整数の代表値を使用しても、スケールを変更すれば、元の浮動小数点数として表現できる値の範囲が変わる。各グループの重みの分布に合わせてスケールを選択すれば、広い範囲に分布する重みと狭い範囲に集中する重みを、同じ固定間隔で扱う場合より適切に近似できる可能性がある。GSQ では、このスケールの調整と、各重みをどの候補へ割り当てるかという選択を組み合わせて最適化する。
GSQ の特徴は、量子化後の値を通常のスカラー量子化として表現できる点にもある。複数の重みをまとめて複雑な符号へ変換する方式では、復号や演算のために専用の実装が必要になる場合がある。GSQ は、既存のスカラー量子化の形式に対応させながら精度を改善することを目指している。論文では、2 ビットおよび 3 ビットの量子化、既存の GGUF 形式の重みへの適用、大規模な専門家混合モデルへの適用などが報告されている[3]。
この方法で調整されるのは、限られた代表値によって元の重みをどのように近似するかである。数値表現の制約内で近似を改善することには意味があるが、その効果が最終的な回答品質へどの程度反映されるかは、量子化後のモデルを実際に評価することで判断する必要がある。
2.2 精度の配分を最適化する RCO
RCO（Riemannian Constrained Optimization）は、総容量の制約を満たしながら、重み群ごとに異なる圧縮方法を割り当てるための最適化手法である。ある重み群では 2 ビットの量子化を採用し、別の重み群では 3 ビットや 4 ビットを使用するような組み合わせを考える。すべての重みを高精度で保存すれば容量が増加する一方、すべてを一律に低ビット化すれば、数値誤差に敏感な部分まで同じ精度で処理することになる。容量の上限がある場合には、どの部分へ追加のビット数を割り当てるかが設計上の選択になる。
この問題を数式で表すため、モデルの重みを \(n\) 個のグループへ分割し、グループ \(i\) に割り当てる量子化形式を \(q_i\) とする。各形式を採用した場合の保存容量を \(s_i(q_i)\)、モデル全体の損失を \(L(q_1,\ldots,q_n)\)、使用できる総容量の上限を \(B\) と置く。最適化の目的は、次のように表せる。
\[
\min_{q_1,\ldots,q_n} L(q_1,\ldots,q_n)
\quad
\text{subject to}
\quad
\sum_{i=1}^{n}s_i(q_i)\leq B
\]
左側は、各重み群への量子化形式の割り当てを変えながら、モデル全体の損失を小さくする目的を表す。右側は、それぞれの重み群が使用する容量の合計を、上限 \(B\) 以下に収める制約である。ここでの損失 \(L\) は、個々の重みの数値差を単純に合計したものとは限らない。あるグループの量子化誤差が別のグループの演算と組み合わされて出力へ影響するため、モデル全体の損失は各グループへの割り当てに依存する。
たとえば、二つの重み群 A と B があり、片方だけを高精度で保存できる容量が与えられているとする。A の数値誤差が比較的大きくても、最終出力への影響が小さい場合がある。一方、B の数値誤差が小さくても、その誤差が後続の演算で増幅され、モデルの損失を増加させる場合がある。この条件では、重みの数値誤差だけを比較して A へ追加のビット数を割り当てると、モデル全体の損失を最小化できない可能性がある。精度配分では、個々の重み群の近似誤差だけでなく、重み群どうしの関係を含む損失を考慮する必要がある。
RCO は、この割り当て問題を連続的な最適化として扱い、容量制約を保ちながら損失を改善する方向を探索する。論文では、制約を満たす連続的な割り当ての探索と、最終的に離散的な選択へ変換する処理を組み合わせている。連続的な探索では期待容量の制約を維持し、離散的な選択についても容量制約を満たすように処理する[4]。これにより、容量の超過を後から調整する方法とは異なり、容量制約を最適化の内部へ組み込める。
GSQ と RCO の関係を整理すると、両者が異なる選択を最適化していることが分かる。
| 比較項目 | GSQ | RCO |
|---|---|---|
| 主な最適化対象 | 各重みの量子化値への割り当てと、グループごとのスケールを最適化する。 | 重み群ごとの圧縮形式の割り当てを、総容量の制約下で最適化する。 |
| 与えられる制約 | 採用する量子化形式で表現できる候補値の数や配置に制約がある。 | 選択する圧縮形式の組み合わせによって、モデル全体の保存容量が変化する。 |
| 最適化の方法 | 離散的な候補の選択を Gumbel-Softmax によって近似し、勾配を利用して割り当てとスケールを調整する。 | 容量制約を満たす連続的な探索と、実行可能な離散的割り当てへの変換を組み合わせる。 |
| 改善を目指す性質 | 低ビットのスカラー量子化において、元の重みを近似する精度を改善する。 | 限られた総容量の中で、モデル全体の損失を小さくする圧縮形式の組み合わせを求める。 |
| 追加で必要な検証 | 量子化後のモデルで、対象となる入力や課題に対する品質が維持されるかを測定する必要がある。 | 求めた割り当てが容量制約を満たし、実際のモデル性能をどの程度維持できるかを測定する必要がある。 |
この二つの手法は、同じ量子化という操作の中で異なる役割を担っている。GSQ は、ある数値表現を採用すると決めた範囲で、元の重みをどのように近似するかを調整する。RCO は、モデル全体の容量制約の下で、どの重み群へどの圧縮形式を割り当てるかを調整する。前者によって各量子化形式の近似精度を改善し、後者によって精度の配分を最適化することで、限られた容量を異なる重み群へ割り当てる設計が成立する。
ただし、両者を組み合わせて得られる最適化結果は、採用した損失関数、評価に使用するデータ、量子化形式の候補、容量制約に依存する。ある入力分布で損失を小さくする割り当てが見つかっても、別の入力分布や課題で同じ性能が維持されるとは限らない。たとえば、一般的な文章を中心としたデータで量子化を最適化した場合、その結果が数学的推論やコード生成の性能を同じ割合で維持することまで保証するわけではない。圧縮時に使用した評価条件と、実際に能力を判定する条件を対応させる必要がある。
低ビット量子化の成果を評価する際には、保存容量の削減、量子化後の重みの近似精度、モデル全体の回答品質を分けて確認できる。保存容量はファイル形式や各量子化形式の割り当てから計算できる。重みの近似精度は、元の値との差を測定することで評価できる。回答品質については、量子化後のモデルへ実際に入力を与え、元モデルとの正答率や課題の成功率を比較する必要がある。容量制約を満たすことと、モデルの能力を維持することは、同じ圧縮手法の評価であっても別の証拠によって確認される。
この区別は、モデル内の一部の重みを低ビット化し、別の部分を元の精度で保持する構成にも適用される。高精度で残した部分には、その部分の量子化による数値誤差が生じない。一方、低ビット化した部分には元の重みとの差が残り、その差が入力や後続の演算と組み合わされて出力へ影響する。どの部分へ精度を割り当てるかという設計上の判断と、実際にどの能力が維持されたかという評価上の判断を分離することで、圧縮後のモデルについて根拠のある結論を導ける。
3. 計算する重みと参照する重みは役割が異なる
大規模言語モデルには、入力された情報を変換するための重みと、入力に対応する情報を取り出すための重みが存在する。前者は行列演算などに使用され、後者は参照テーブルから必要な値を選択する処理に使用される。両者は同じモデルのパラメータであっても、実行時に必要となる演算量やメモリーアクセスの性質が異なる。この違いは、どの重みを高精度で保存するかという設計だけでなく、どの記憶装置へ配置し、どのタイミングで読み出すかという実装条件にも関係する。
たとえば、行列演算では入力ベクトルと多数の重みを組み合わせて結果を計算する。使用する重みを低ビット化すれば、保存容量に加えて、演算時に転送するデータ量を削減できる可能性がある。一方、参照テーブルでは、入力から決まる位置を指定し、その位置に保存された値を取得する。テーブル全体の容量が大きくても、各入力で参照する項目が限られていれば、読み出すデータ量はテーブル全体の容量より小さくなる。ただし、参照する位置が分散している場合には、連続したデータを読み出す処理とは異なるメモリーアクセスの負担が生じる。
既稿では、計算量や数値精度などの資源を、性能への寄与が大きい部分に選択的に残す設計を論じた[5]。また、三値 LLM を題材に、保存形式を圧縮しても復号や実行に必要な処理が残り、その処理をどこで実行するかによって性能が変化することを整理した[6]。参照テーブルを分離する構成にも、保存容量と実行時の処理を区別する考え方が適用できる。ただし、ここでの違いは圧縮データを復号する場所だけでなく、モデルのパラメータを行列演算に利用するのか、入力から決まる位置の参照に利用するのかという処理方式そのものにある。
3.1 行列演算と参照テーブルではデータの使い方が異なる
一般的なニューラルネットワークの線形変換では、入力ベクトルと重み行列の積を計算する。入力が変われば演算結果も変わるが、同じ層の計算では多数の重みが繰り返し利用される。こうした処理では、GPU の演算性能と、重みを演算装置へ供給するメモリー帯域が実行時間を左右する。重みの保存容量が大きい場合、必要なデータを演算に間に合う速度で転送することが制約になる。
専門家混合モデル（Mixture of Experts、MoE）では、この構造に条件付きの計算が加わる。MoE は複数の専門家ネットワークを持ち、入力に応じて一部の専門家を選択する。すべての専門家を各トークンで同時に実行する代わりに、選択された専門家の重みを使用するため、モデル全体のパラメータ数と、個々のトークンの処理で実際に使用されるパラメータ数を分離できる。ただし、どの専門家を使用するかはモデル内部の状態によって決まり、選択された専門家については通常の行列演算が必要になる。
参照テーブルでは、データの取得方法が異なる。入力から参照位置を計算し、その位置に対応する行を取り出すため、テーブル全体を行列演算へ投入する必要がない。たとえば、1 億行の参照テーブルが存在しても、ある入力で取得する行が数十行に限られるなら、その入力に対する参照処理は指定された行の取得を中心に構成できる。もちろん、実際の読み出し量には行の長さ、キャッシュの状態、データの配置などが関係するが、全行を一度に演算へ使用する方法とは異なる。
この違いによって、モデルのパラメータ数を増やすことと、各トークンの計算量を増やすことの関係が変わる。行列演算用の重みを追加すれば、追加した重みを利用する計算やデータ転送が必要になる。一方、参照テーブルの行数を増やしても、各入力で参照する行数を一定に保てるなら、参照対象全体の容量と一回の参照で取得するデータ量を分離できる。参照テーブルを利用する設計は、この性質によって大規模な情報の保存と選択的な利用を両立させる。
3.2 Engram は入力の一部から参照位置を決定する
Engram は、大規模言語モデルに条件付きの記憶参照を組み込む仕組みである。入力されたトークン列から n-gram と呼ばれる連続したトークンの組み合わせを取り出し、その組み合わせに対応する埋め込みベクトルを参照テーブルから取得する。埋め込みベクトルとは、入力された情報を後続の数値計算で扱えるように表現した数値の列である。Engram の元研究では、こうした参照機構を Transformer の計算処理と組み合わせることで、記憶容量を増やす方法が提案されている[7]。
n-gram は、連続する n 個のトークンを一つの組み合わせとして扱う方法である。たとえば、入力が A、B、C、D という四つのトークンから構成される場合、2-gram には A-B、B-C、C-D が含まれ、3-gram には A-B-C、B-C-D が含まれる。ここでのトークンは、必ずしも自然言語の単語と一致するわけではない。モデルのトークン分割方式によっては、単語の一部分や記号もトークンとなる。Engram は、このようなトークンの並びを参照位置を決めるための手掛かりとして利用する。
ただし、可能な n-gram の組み合わせをすべて個別の行として保存すると、トークンの種類が増えるにつれて必要なテーブルの規模が急速に拡大する。Engram では、この問題に対してハッシュ関数を利用する。ハッシュ関数は、入力されたトークンの組み合わせから、一定の範囲に収まる整数値を計算する仕組みである。計算された整数値を参照位置として使用すれば、可能な組み合わせの数を直接テーブルの行数へ対応させずに済む。
たとえば、ある 2-gram から参照位置 120 が計算されれば、対応するテーブルの 120 番目の行を取得する。別の 2-gram から位置 850 が計算されれば、その行を取得する。ここでは、どの位置を参照するかが入力のトークン列によって決まるため、参照対象を決定するためにニューラルネットワーク全体の演算結果を待つ必要がない。Engram の元研究では、参照位置を決定できる性質を利用し、必要な埋め込みベクトルを事前に読み出す方法も検討されている[7]。
ハッシュ関数には、異なる入力が同じ参照位置へ対応する衝突という性質がある。たとえば、異なる二つの n-gram が同じ整数値へ変換されれば、同じテーブルの行を参照する可能性がある。Engram では、複数のハッシュ計算を組み合わせることで、この衝突が情報表現へ与える影響を抑える設計を採用している。また、トークン表記の正規化によって、表記上の違いを持つトークンを共通の識別子へ対応させ、参照テーブルを利用する際の重複を減らしている。
この仕組みで取得される値は、入力の n-gram から決まる参照結果である。同じ正規化規則とハッシュ関数を使用し、同じトークン列を入力すれば、同じ参照位置が得られる。一方、取得された埋め込みベクトルが、最終的な回答でどのように利用されるかは別の処理で決まる。Engram には、取得した情報をそのまま出力へ変換するのではなく、モデル内部の状態と組み合わせて利用する機構が含まれている。
3.3 参照した情報はモデル内部の状態と組み合わされる
Engram が参照テーブルから取り出す埋め込みベクトルは、入力の局所的な並びに基づく情報である。同じ n-gram から同じ参照位置が得られる場合、その参照位置に保存された値も同じになる。しかし、同じ文字列や単語の並びであっても、周囲の文脈によって意味や役割が変わる場合がある。参照テーブルの値だけで最終的な意味を決定すると、文脈による違いを十分に反映できない可能性がある。
このため、Engram では参照した埋め込みベクトルを、Transformer が計算した現在の内部状態と組み合わせる。元研究では、文脈に応じて参照情報の寄与を調整するゲート機構が採用されている。ゲートは、取得した情報を後続の計算へどの程度反映するかを決める数値的な調整機構である。入力の文脈と参照した情報の対応が適切であれば、その情報を計算へ反映し、対応が小さい場合には寄与を抑える方向に働く。
参照テーブルから取得したベクトルを \(e\)、文脈に基づいて計算されたゲートの値を \(\alpha\)、参照したベクトルを変換する重み行列を \(W_V\) とすると、ゲートを通過した情報の一部は次のように表せる。
\[
u=\alpha W_V e
\]
ここで \(e\) は参照テーブルに保存された情報、\(W_V e\) はその情報を後続の計算で利用できる形へ変換した値、\(\alpha\) は文脈に応じて寄与を調整する係数である。この式は Engram のゲート処理を単純化して表したものであり、実際の実装には正規化や追加の変換処理も含まれる。参照テーブルの値が同一でも、変換に使う \(W_V\) やゲートの値 \(\alpha\) が変化すれば、後続の計算へ渡される \(u\) は変化する。
たとえば、元モデルと量子化モデルで参照テーブルの値 \(e\) が完全に一致している場合を考える。Backbone の重みが量子化されていれば、文脈を表す内部状態やゲートの計算結果が変化する可能性がある。さらに、参照ベクトルを変換する重みに量子化誤差が含まれていれば、同じ \(e\) を入力しても変換後の値に差が生じ得る。この差は後続の層へ渡され、注意機構や専門家ネットワークの演算を経て、最終的なトークンの候補スコアへ影響する可能性がある。
Engram の元研究では、ゲート機構に加えて、短い範囲のトークン間の関係を処理する畳み込み演算も組み込まれている。取得した情報を文脈に応じて調整し、後続のニューラルネットワークへ統合することで、参照テーブルを単独の検索結果として利用するのではなく、モデル内部の計算に参加させる構成になっている。この接続によって、参照テーブルの保存精度と、モデル全体の出力精度を分けて評価する必要が生じる。
DeepSeek-V4.1-Flash は、このような Engram の参照機構を取り入れたモデル系列である。技術報告では、大規模な専門家混合モデルの構成に加え、記憶参照と計算処理を組み合わせる設計が示されている[8]。1017 更新版の公開モデルでは、基盤となる重みと Engram の構成を確認できる[9]。さらに、公開された Engram の実装には、トークン識別子の正規化、ハッシュ計算、参照位置の決定に必要な処理が含まれている[10]。
3.4 参照位置を事前に決められることがメモリー配置を変える
Engram の参照処理には、実行時のメモリー配置にも関係する特徴がある。参照位置が入力トークン列から決まるため、必要な行をモデル内部の演算がその位置へ到達する前に取得できる場合がある。たとえば、ある層で Engram の参照結果が必要になることが分かっていれば、それ以前の層が計算を実行している間に、参照テーブルから該当する行を読み出す処理を開始できる。計算とデータ転送を時間的に重ねることで、参照待ちによる停止時間を減らす設計が可能になる。
この性質は、GPU の高速なメモリーへすべての参照テーブルを配置する場合と、必要な行だけを CPU 側のメモリーから転送する場合の違いにつながる。GPU のメモリーに全体を保持すれば、参照に必要なデータを高速に取得できる可能性がある一方、大規模な Engram テーブルが演算用の重みとメモリー容量を奪い合う。CPU 側のメモリーへ配置すれば GPU のメモリー使用量を抑えられるが、必要な行を PCIe などの接続経路を通じて転送する必要がある。転送量と転送時間が計算処理に間に合うかどうかが、実行性能を左右する。
Engram の元研究では、推論時に CPU 側のメモリーへ参照テーブルを配置し、必要な埋め込みベクトルを事前に取得して GPU へ転送する方法が検討されている[7]。参照位置が入力から確定するため、後続の層で必要となるデータを前もって準備できる。一方、モデル内の早い層へ Engram を配置すると、参照結果を利用するまでに実行できる計算が少なくなり、転送時間を隠す余地も小さくなる。参照情報を早い段階で利用したいというモデル側の条件と、データ転送を計算と重ねたいという実行環境側の条件が、配置位置の選択に影響する。
さらに、参照頻度によって保存場所を変える方法も考えられる。自然言語のトークンの組み合わせには、頻繁に出現するものと、まれにしか出現しないものがある。頻繁に参照される行を GPU のメモリーや CPU 側のメモリーへ保持し、参照頻度が低い行を SSD などの大容量ストレージへ配置すれば、高速なメモリーの使用量を削減できる可能性がある。ただし、SSD から読み出す場合には、アクセス遅延や読み出し単位、キャッシュの命中率が性能に影響する。元研究で示された CPU 側メモリーからの事前転送と、SSD を含む多段階の保存構成は、必要となる実行条件を区別して評価する必要がある。
同じ参照テーブルでも、どの場所へ保存するかによって、必要なメモリー容量、データ転送量、参照待ち時間が変化する。参照テーブルを高精度で保持すると保存容量は増加するが、毎回参照する行が限定される構造であれば、テーブル全体の容量がそのまま一回の推論で転送する容量になるわけではない。一方、必要な行を取得する処理が遅ければ、演算用の重みを低ビット化しても、参照待ちによってモデル全体の処理時間が増加する場合がある。
計算用の重みと参照テーブルの違いを、保存と実行の両面から整理すると次のようになる。
| 比較項目 | 演算用の重み | Engram の参照テーブル | 設計・評価への影響 |
|---|---|---|---|
| 主な用途 | 入力された数値と重みを組み合わせ、行列演算などによって内部状態を変換する。 | 入力トークン列から決まる参照位置に対応した埋め込みベクトルを取得する。 | 同じパラメータ数でも、計算量とデータ取得の方法が異なる。 |
| 使用する重みの範囲 | 通常の線形変換では多数の重みを利用し、MoE では選択された専門家の重みを利用する。 | 入力から決定された参照位置に対応する一部の行を利用する。 | モデル全体の容量と、一回の入力で使用するデータ量を区別する必要がある。 |
| 参照対象の決定方法 | 計算する層や、MoE の場合はモデル内部の状態に基づく専門家選択によって決まる。 | 入力トークン列の正規化と n-gram のハッシュ計算によって決まる。 | Engram では参照位置を事前に計算し、読み出しと演算を重ねられる場合がある。 |
| 高精度で保持する効果 | 重みの量子化に由来する数値差を避けられるが、保存容量や転送量が増加する。 | 参照テーブルの値に量子化誤差を導入せずに保存できるが、テーブル全体の容量が増加する。 | どの部分の誤差を回避するかと、増加する資源要求を対応させて判断する必要がある。 |
| 実行時の制約 | 演算性能、メモリー帯域、重みの配置、低ビット演算への対応などに依存する。 | 参照位置の分布、キャッシュの命中率、読み出し遅延、データ転送量などに依存する。 | 保存容量の削減率だけでは推論速度を判断できない。 |
| 出力への影響 | 重みの変更が内部状態の計算結果を変え、後続の層やトークン選択へ影響する場合がある。 | 取得した埋め込みベクトルが内部状態と統合され、後続の演算へ影響する。 | 参照値の一致と最終出力の一致を、それぞれ独立した条件で検証する必要がある。 |
この比較から、モデル全体の保存容量を削減する方法と、実行時に必要な資源を削減する方法が必ずしも一致しないことが分かる。演算用の重みを低ビット化すれば、数値表現の変更による誤差と引き換えに、保存容量や転送量を削減できる。参照テーブルを高精度で保持する場合には、その部分の量子化誤差を避けられるが、保存容量の増加と必要な行を読み出す処理を引き受けることになる。両者の組み合わせによって、保存精度、メモリー配置、転送量、演算結果が異なる条件で決まる構成が成立する。
ここで、参照テーブルの値を元の精度で保持したという事実が保証する範囲を考える。元モデルと変更後のモデルで、Engram のテーブルが同じ値を保持し、同じ入力から同じ参照位置を計算できれば、取得される埋め込みベクトルの値も一致する。しかし、そのベクトルを内部状態へ組み込む際には、変換用の重みやゲート機構などの演算が加わる。Backbone の重みが低ビット化されていれば、その部分の計算結果には元モデルとの差が生じる可能性がある。参照テーブルの一致は、モデル全体の計算経路のうち、保存値と対応する参照処理についての一致を確認する条件になる。
また、参照テーブルに量子化誤差が生じないことは、その情報が必ず正しい回答へ寄与することと同義ではない。参照位置がハッシュ計算によって決まるため、異なる n-gram が同じ行へ対応する可能性があり、取得した情報を利用する際には文脈に応じた調整も行われる。元のテーブルを正確に保存すれば、テーブルの数値表現を変更した影響は除外できる。一方、ハッシュによる参照の性質や、文脈に応じた情報の統合は、そのまま残る。保存精度を維持した部分と、引き続きモデル全体の出力へ影響する部分を区別する必要がある。
演算用の Backbone を低ビット化し、Engram の参照テーブルだけを元の精度で保持する設計は、パラメータの利用方法が異なることを利用している。参照テーブル全体を毎回の行列演算へ使用する必要がないため、高精度の値を残すことと、すべての演算用重みを高精度で保持することには異なる資源要求が生じる。しかし、参照した値は最終的に Backbone の計算経路へ組み込まれる。高精度で保存された情報が、その後の低ビット演算を経てどのような結果になるかは、元モデルとの出力比較によって確認する必要がある。
このように、Engram の保存値が一致していることは、モデルの一部分について元の数値情報が保持されているという明確な証拠になる。一方、その情報が最終的な回答へ与える影響は、参照位置の決定、文脈に応じた統合、後続の演算、トークン選択という処理の結果として現れる。保存精度を高くする設計の意味は、参照テーブルの量子化誤差を回避できる点にある。その設計がモデル全体の能力をどの程度維持するかは、同じ Backbone に異なる精度の Engram を組み合わせた比較など、変更要因を分離した実測によって判断できる。
4. 高精度の Engram を組み合わせたモデルの構成
DeepSeek-V4.1-Flash-1017 の派生モデルには、演算用の Backbone を低ビット化した構成と、その Backbone に元の精度の Engram を組み合わせた構成が存在する。両者の違いを調べることで、参照テーブルの数値精度を変更した場合に、保存容量とモデルの動作がどのように変化するかを検討できる。ただし、今回の派生モデルには、量子化と Engram の精度変更に加えて、応答拒否に関係する内部表現の変更も含まれている。モデルの性能を比較する際には、どの変更がどの段階で加えられたかを特定する必要がある。
元モデルの DeepSeek-V4.1-Flash-1017 は、約 7632 億のパラメータを持つ大規模な専門家混合モデルである。モデル全体には Transformer の演算用の重みと Engram の参照テーブルが含まれ、それぞれ異なる数値表現で保存されている。ISTA-DASLab は、この構成を利用して Backbone を GSQ-RCO によって量子化し、Engram を別の共有ファイルとして保持する GGUF 形式のモデルを公開した[11]。GGUF は、モデルの重みや構成情報を推論エンジンが読み込める形で保存するファイル形式であり、複数の量子化形式を組み合わせた重みも格納できる。
4.1 ISTA-DASLab による Backbone の低ビット量子化
ISTA-DASLab の公開モデルでは、GSQ と RCO を組み合わせ、重みごとの量子化形式を総容量の制約下で割り当てている。GSQ は各量子化形式で元の重みを近似する方法を最適化し、RCO はどの重みへどの形式を割り当てるかを最適化する。このため、モデル名に IQ2_XXS と含まれていても、すべての重みが一律に 2 ビットで保存されているわけではない。IQ2_XXS の構成では、Transformer の重みについて、平均的な保存ビット数が重み当たり 2.00 ビットとなるように、複数の量子化形式が組み合わされている。
この平均値は、モデル全体のすべてのパラメータに適用される数値ではない。ISTA-DASLab の説明では、量子化形式の割り当てを最適化する対象は、約 5519 億の Transformer の重みである。一方、Engram の参照テーブルには約 1966 億のパラメータがあり、IQ4_NL という固定された量子化形式で保存される。IQ4_NL は、公称上の 4 ビット量子化に関連する形式だが、保存に必要な補助情報を含めた平均ビット数は重み当たり 4.50 ビットである。したがって、Backbone の平均ビット数と Engram の保存精度を区別して容量を評価する必要がある。
ISTA-DASLab が公開した IQ2_XXS の構成では、Backbone の保存容量は 138.24 GB、Engram の共有ファイルは 110.60 GB、合計は 248.84 GB である[11]。この GB は 10 億バイトを単位とする十進表記であり、1024 の累乗で計算する GiB とは異なる。また、この合計は対象となる GGUF ファイルの保存容量であり、推論時に必要な RAM や VRAM の総量を直接示すものではない。実行時には、重みの配置、作業領域、キャッシュ、推論エンジンの実装によってメモリー使用量が変化する。
Backbone と Engram を分離していることには、保存と実行の両面で意味がある。Backbone は多数の重みを演算へ供給するため、量子化によって容量と転送量を削減する効果が期待できる。一方、Engram は入力から決まる参照位置に対応した行を読み出すため、テーブル全体を各トークンの行列演算へ投入する必要がない。ISTA-DASLab は、この違いを利用し、すべての量子化構成で共通の IQ4_NL Engram ファイルを使用している。Backbone の量子化形式を変更しても、Engram の保存形式を変えずに比較できる構成である。
ISTA-DASLab が公開した評価結果では、IQ2_XXS の構成が AIME25、GPQA-Diamond、LiveCodeBench v6 の三つのベンチマークについて、掲載された元モデルと同じスコアを記録している[11]。これは同研究室が採用した評価条件で、両モデルの集計得点が一致したことを示す。ただし、この評価は IQ4_NL Engram を使用した構成に対する結果である。Engram を別の数値形式へ置き換えた場合の性能については、その変更後のモデルを対象とした比較が必要になる。
4.2 Abiray による拒否関連表現の変更
Abiray は、ISTA-DASLab の IQ2_XXS 構成を基に、応答拒否に関係する内部表現を変更した派生版を公開している[12]。具体的には、AtomicChat が公開した英語・ロシア語の拒否方向を利用し、GSQ-RCO 量子化済み Backbone の重みを変更している。この変更には Abliteration と呼ばれる手法が利用されている。Abliteration は、モデルの内部状態において応答拒否と関係する方向を特定し、その方向への寄与を抑えることで、特定の入力に対する拒否挙動を変更する方法である。元モデルの量子化精度を調整する操作とは異なり、モデルがどのような応答を選びやすいかという内部表現へ介入する。
大規模言語モデルでは、内部状態が多数の数値からなるベクトルとして表現される。そのベクトルの特定方向が応答拒否と関係していれば、その方向の成分を変更することで、モデルの応答傾向が変化する可能性がある。たとえば、ある入力に対して通常は拒否する応答を生成するモデルでも、拒否に関係する内部表現を抑制すると、回答を生成する方向へ挙動が変わる場合がある。ただし、内部表現は複数の機能に利用されるため、特定方向の操作が拒否挙動だけに影響するとは限らない。
Abiray のモデルカードによれば、この派生版では英語とロシア語に関係する拒否方向を利用し、86 個の重みテンソルに変更を加えている。その内訳は、密な演算部分に関係する 80 個のテンソルと、専門家ネットワークに関係する 6 個のテンソルである。一方、特定の 1 ビット量子化済み専門家の重み群や、Engram の参照情報を変換する一部の重みは変更せずに維持している。Abiray は、変更した重みを GGUF ファイルへ直接組み込んでいるため、推論時に追加の LoRA アダプターを読み込む必要がない構成として公開している[12]。
変更後の Backbone の保存容量は約 138.58 GB であり、ISTA-DASLab の 138.24 GB から約 0.34 GB 増加している。容量の増加は Backbone 全体の約 0.25% に相当する。元の IQ4_NL Engram を組み合わせた場合、モデルの保存容量は約 249.18 GB になる。この増加量は、拒否関連表現の変更に伴う保存形式と重みの構成の差を示すものであり、拒否挙動の変化量や回答品質の変化量を表す数値ではない。
Abiray は、変更後の重みについて整合性を確認するとともに、通常の入力に対する出力分布の変化も報告している。モデルカードには、変更前後の出力分布の KL ダイバージェンスの平均値が 0.000002 nat、最も高いスコアを持つトークンの一致率が 97.0%、上位 5 候補の一致率が 100.0% と記載されている[12]。KL ダイバージェンスは二つの確率分布の違いを測る指標であり、この値が小さいことは、評価した入力条件で出力分布の変化が小さかったことを示す。ただし、分布の近さは、あらゆる入力に対する回答品質の一致を保証するものではない。
たとえば、通常の事実質問に対して出力分布がほぼ一致していても、拒否挙動を引き起こす入力では変更の効果が大きくなる可能性がある。また、最初のトークンの候補が一致していても、複数トークンを生成した後の文章全体が一致するとは限らない。最初に選ばれたトークンが同じでも、その後の内部状態や候補分布に差が蓄積する場合がある。Abiray の報告値は、公開者が実施した評価条件における変更前後の近さを示す証拠として扱う必要がある。
この派生版の評価では、量子化済みモデルの能力がどの程度維持されたかという問題と、応答拒否がどの程度変化したかという問題が分かれる。前者では数学的推論、知識問題、コード生成などの能力を比較する。後者では、拒否が期待される入力や、通常の回答が期待される入力を用いて、拒否率や応答内容を測定する。拒否率が変化しても、通常の能力が同じ割合で変化するとは限らず、両者の評価には異なる入力と指標が必要になる。
4.3 Starw1 による Engram の高精度化
Starw1 は、Abiray が公開した拒否関連表現の変更済み Backbone を維持し、Engram の参照テーブルを元モデル由来の MXFP8 形式へ差し替えた派生版を公開している[13]。変更の対象は Engram の保存精度であり、Abiray の Backbone に対して追加の量子化や拒否方向の変更を行う構成としては説明されていない。このため、Abiray 版と Starw1 版は、同じ変更済み Backbone を使用しながら、Engram の数値表現が異なる組み合わせになる。
MXFP8 は、8 ビットの浮動小数点値と、複数の値で共有するスケールを組み合わせる数値表現である。Starw1 のモデルカードでは、元モデルの FP8 E4M3 形式の値と、32 個の値ごとに共有される E8M0 形式のスケールを引き継いだと説明している。E4M3 は指数部 4 ビットと仮数部 3 ビットを持つ浮動小数点形式であり、E8M0 はスケールの指数を表現するための形式である。元の数値表現を維持するには、8 ビットの値だけでなく、それらの値を解釈するためのスケールも正しく保存する必要がある。
Starw1 は、元モデルの Engram の値とスケールを、GGUF の MXFP8 形式へコピーしたと報告している。公開された説明によれば、対象となる約 7 億 6800 万行について、元の値とのバイト単位の一致を確認している[13]。この比較が成功していれば、対象とした参照テーブルの保存値が元モデル由来の値と一致することを確認できる。ここでのバイト一致は、モデル全体のファイルが同一であるという意味ではなく、元モデルから取り出した Engram の値とスケールについて、比較対象となったデータが一致するという意味である。
元の数値表現を保持した結果、Engram のファイル容量は約 202.8 GB になっている。ISTA-DASLab が公開した IQ4_NL Engram は 110.60 GB であるため、Starw1 の MXFP8 Engram は約 92.2 GB 大きい。容量比では約 1.83 倍となる。この増加は、参照テーブルの各値を低ビットの代表値へ変換する代わりに、元の浮動小数点表現とスケールを維持することで生じる保存上の負担である。
一方、Starw1 の Backbone は Abiray 版と同じ約 138.58 GB である。これに MXFP8 Engram の約 202.8 GB を組み合わせると、モデル全体の保存容量は約 341.4 GB になる。Abiray 版に IQ4_NL Engram を組み合わせた約 249.18 GB の構成と比較すると、差は約 92.2 GB であり、Engram の保存形式の変更による容量増加と一致する。Backbone の保存容量を固定しているため、この二つの構成の容量差を Engram の変更へ対応させることができる。
ただし、保存容量が約 92.2 GB 増えたことは、推論時に常時使用する GPU メモリーが同じだけ増えることを意味しない。Engram は入力に応じて必要な行を参照する構造であり、参照テーブルを CPU 側のメモリーやストレージへ配置する実装も考えられる。実際のメモリー要求と処理時間は、参照する行の数、キャッシュの状態、データ転送の方法、推論エンジンが MXFP8 をどのように処理するかによって変化する。保存容量の増加と実行時の資源要求は、別々に測定する必要がある。
4.4 三つの公開構成で変更された部分を比較する
ISTA-DASLab、Abiray、Starw1 の三つの構成を比較すると、変更された対象と維持された対象を区別できる。ISTA-DASLab は量子化済みモデルを公開し、Abiray はその Backbone の拒否関連表現を変更した。Starw1 は Abiray の Backbone を使用し、Engram の保存精度を元の MXFP8 へ変更している。これらは一つのモデルに対して異なる種類の変更を順番に適用した構成であり、各変更が最終結果へ与える影響を考えるための比較対象になる。
| 構成 | Backbone | Engram | 比較で読み取れること |
|---|---|---|---|
| ISTA-DASLab IQ2_XXS | GSQ-RCO による低ビット量子化済み。保存容量は 138.24 GB。 | IQ4_NL、110.60 GB。 | 量子化済み Backbone と IQ4_NL Engram を組み合わせた基準構成であり、合計容量は 248.84 GB である。 |
| Abiray 派生版 | ISTA-DASLab の量子化済み Backbone を基に、拒否関連表現を変更した重みを含む。保存容量は約 138.58 GB。 | ISTA-DASLab の IQ4_NL 版を利用する。 | Engram の保存形式を維持し、Backbone の拒否関連表現の変更が追加された条件である。 |
| Starw1 派生版 | Abiray の変更済み Backbone を維持する。保存容量は約 138.58 GB。 | 元モデル由来の MXFP8、約 202.8 GB。 | 同じ変更済み Backbone に対して Engram の精度が異なる条件であり、合計容量は約 341.4 GB である。 |
ISTA-DASLab と Abiray を比較すると、Engram の保存形式を固定したまま、Backbone の一部が変更された条件を考えられる。この比較で出力が変化した場合、モデルの構成上の差は Backbone に存在する。ただし、量子化済み重みへ拒否関連表現の変更を加えているため、観測される変化が拒否挙動に限定されるかどうかは実測によって判断する必要がある。通常の質問に対する回答精度、出力分布、拒否が期待される入力での挙動を分けて比較することで、変更の影響範囲を調べられる。
Abiray と Starw1 を比較する場合には、同じ拒否変更済み Backbone を使用しながら、Engram の保存形式だけが IQ4_NL と MXFP8 で異なる。この条件では、同じ入力、同じ推論エンジン、同じトークン選択方式を使用すれば、Engram の数値精度の違いが最終出力へどのように影響するかを調べられる。たとえば、元の IQ4_NL Engram では誤答した質問が MXFP8 Engram で正答になる場合、その質問について高精度化による改善が観測されたことになる。反対に、回答が変化しない場合や、MXFP8 版で誤答が増える場合も、同じ比較の結果として評価する必要がある。
さらに、元モデルと Starw1 版を直接比較する場合には、変更要因が複数存在する。元モデルからの主な変更は、Backbone の低ビット量子化と拒否関連表現の変更である。Engram は GGUF 形式へ格納されているが、元モデル由来の値とスケールを維持している。このため、二つのモデルの回答が一致した場合も、差が生じた場合も、その結果だけから Engram の高精度化の効果を独立に特定することは難しい。
高精度 Engram の寄与を調べるには、Backbone を固定した比較が必要になる。拒否関連表現の変更の寄与を調べるには、Engram の精度を固定した比較が必要になる。両者の変更が互いに影響する可能性まで検討する場合には、通常の Backbone と変更済み Backbone のそれぞれに、IQ4_NL と MXFP8 の Engram を組み合わせた条件を用意することで、変更要因を分離した評価を設計できる。
ここで注意すべきなのは、公開されている構成の違いを整理することと、その違いによる性能変化を実測したことは別であるという点である。三つの公開モデルの容量や重みの構成を確認すれば、どの部分が変更されたかを特定できる。一方、モデルの能力がどの程度維持されたかを判断するには、比較対象を固定したうえで、同じ課題と評価条件に基づく測定結果が必要になる。モデルカードに記載された別々の評価結果を比較する場合も、入力、実行条件、評価方法が一致しているかを確認する必要がある。
4.5 拒否関連表現の変更と能力維持の関係
Abiray が採用した Abliteration の考え方には、Arditi らが発表した拒否方向の研究が関係している。Arditi らは、最大 72B パラメータの 13 種類の公開チャットモデルを対象に、応答拒否が特定の一次元方向と関係していることを実験的に示した[14]。この研究では、内部状態から拒否に関係する方向を取り除くと有害な依頼への拒否が抑制され、反対にその方向を加えると通常の依頼でも拒否が生じやすくなることが報告されている。
この結果は、モデル内部の特定方向を操作することで、応答方針に関係する挙動を変更できる可能性を示している。ただし、元研究の対象は特定のモデル群であり、DeepSeek-V4.1-Flash-1017 のような約 7632 億パラメータの専門家混合モデルを直接評価したものではない。また、拒否に関係する方向を変更する操作が、すべての入力でほかの能力へ影響しないという保証も含まれていない。Abiray の実装がどの範囲で拒否挙動を変更し、通常の回答品質へどの程度影響したかは、その派生版に対する評価結果によって判断する必要がある。
たとえば、拒否が期待される入力に対して回答する割合が増加した場合、拒否挙動の変更が生じたことは確認できる。しかし、その回答が正確であるか、内容に誤りが増えたか、通常の質問に対する正答率が維持されたかは、別の指標で評価する必要がある。拒否率はモデルが回答を避ける頻度を測る指標であり、回答品質は生成された内容の正確性や課題達成度を測る指標である。両者の値が変化する原因も一致するとは限らない。
Starw1 の派生版では、この拒否関連表現の変更を含む Backbone がそのまま使用されている。したがって、Engram を MXFP8 に変更した効果を調べる場合には、拒否関連表現の変更が共通して含まれる Abiray 版を比較対象とすることに意味がある。両者の Backbone が同一であるという条件を維持すれば、拒否関連表現の変更による差を固定した状態で Engram の精度を比較できる。
ただし、Backbone が同一でも、Engram の精度変更によって内部状態が変化すれば、拒否に関係する方向への寄与まで変わる可能性がある。Engram から取得した情報は Backbone の計算へ統合されるため、参照値の差が後続の内部状態へ影響する場合がある。この意味で、保存形式の変更と応答挙動の変更を構成上の操作として分離できても、それぞれが最終出力へ与える影響が完全に独立しているとは限らない。個々の変更の効果と、変更を組み合わせた場合の効果を区別して評価する必要がある。
また、モデルの名称に含まれる Uncensored という表現は、公開者が意図した応答挙動を示す名称である。実際の拒否率は、入力の言語、依頼内容、推論時の指示、実行条件によって変化し得る。拒否関連表現を変更したという実装上の事実と、あらゆる入力で拒否が発生しなくなるという性質は、異なる主張として扱う必要がある。後者を確認するには、対象とする入力分布を定義し、変更前後の拒否率と応答内容を測定する必要がある。
ここまでの構成を整理すると、ISTA-DASLab が行った量子化、Abiray が行った拒否関連表現の変更、Starw1 が行った Engram の高精度化は、それぞれ異なる対象へ作用する操作である。量子化は保存する数値表現を変更し、拒否関連表現の変更は Backbone の内部表現へ介入し、Engram の高精度化は参照テーブルの元の値を保持する。これらの操作は同じモデルへ組み込まれているが、実装上の目的と検証すべき性質は一致しない。
Starw1 の構成について直接確認できるのは、公開された説明と検証記録に基づく Backbone の由来、Engram の保存形式、ファイル容量、元の参照テーブルとの一致である。約 92.2 GB の容量を追加して Engram の元の精度を維持する設計には、参照テーブル自体の量子化誤差を回避するという明確な意味がある。一方、その追加容量によって回答品質がどれだけ改善するか、推論速度やメモリー使用量がどの程度変化するかは、対象となるモデルを同じ条件で実行した比較結果によって判断される。
モデルの一部分を高精度で保持したことは、その部分の数値情報が元の状態で保存されていることを示す。しかし、最終的な回答は、参照した情報を量子化済み Backbone の演算へ組み込み、複数の層を経て生成される。さらに、この派生版では拒否関連表現にも変更が加えられている。保存された Engram の一致、Backbone の変更内容、推論時の計算結果をそれぞれ分離することで、公開されたモデルの構成から直接確認できる事実と、実測によって確かめるべき性能上の性質を区別できる。
5. バイト一致と推論成功は何を証明するのか
モデルの重みを別の保存形式へ変換した場合、その変換が正しく行われたかを確認する方法はいくつかある。元のデータと変換後のデータを比較する方法、変換されたファイルを読み込めるか確認する方法、実際に推論を実行して出力が得られるか確認する方法である。これらは一連の検証として実施できるが、それぞれが直接確認する対象は異なる。元の値を正確に保存できたこと、推論エンジンがファイルを処理できたこと、モデルが期待する回答を生成したことは、異なる条件によって成立する。
Starw1 が公開した verification.log には、DeepSeek-V4.1-Flash-1017 の Engram を元の MXFP8 精度で保持するために実施した検証結果が記録されている。ログには、元モデルの値と変換後の値の比較、二つの Engram 層の対応確認、Strata によるパッキング処理、CPU の参照実装を使用した生成試験が含まれる[15]。この記録によって、重みの保存から実際の生成処理までの各段階について、公開者が何を確認したかを具体的に調べられる。
検証を行った対象は、約 7632 億パラメータを持つ元モデル全体ではなく、量子化済み Backbone と組み合わせる Engram の保存値および指定された実行経路である。元の Engram を保持するという目的に対しては、参照テーブルの値が変化していないことが直接の検証対象になる。一方、モデル全体の能力について判断する場合には、量子化された Backbone の演算結果や、Engram から取得した値が後続の計算へ与える影響も評価対象に含まれる。
5.1 バイト単位の一致が確認する保存内容
バイト単位の一致とは、比較する二つのデータについて、対応するバイト列が同一であることを確認する検証である。たとえば、ある浮動小数点数が保存されている場合、その数値を表現するビット列が元のデータと一致していれば、比較対象の範囲について数値表現が維持されたことを確認できる。数値を別の形式へ変換してから再構成する方法では、元の数値に近い値が得られても、バイト列まで一致するとは限らない。バイト一致は、この近似による一致と、元の表現をそのまま保持することを区別するために利用できる。
Starw1 の Engram では、元モデルに含まれる FP8 E4M3 形式の値と、32 個の値ごとに共有される E8M0 形式のスケールが、MXFP8 の保存形式へ引き継がれている。FP8 E4M3 は 8 ビットの浮動小数点値を表し、E8M0 は複数の値を共通の倍率で扱うためのスケールを表す。実際に利用される数値は、保存された値と対応するスケールの組み合わせによって決まるため、元の数値表現を維持するには両方の情報を正しく保持する必要がある。
たとえば、同じ FP8 のビット列を保存しても、対応するスケールが変化すれば、後続の演算で解釈される値は変わる。反対に、スケールが一致していても、FP8 の値が異なれば、参照テーブルから得られる数値が変化する。元の Engram を正確に保持するという条件は、個々の値だけでなく、その値を解釈するためのスケールを含めて成立する。このため、単に変換後のファイルが指定された容量で生成されたことと、元の数値情報が正確に保存されたことは、異なる確認事項になる。
公開された検証ログでは、元の値とのバイト比較が成功し、不一致と判定された行は 0 件であった。また、二つの Engram 層について、対応する値が正しく配置されていることを確認した記録が残されている[15]。Starw1 のモデルカードでは、約 7 億 6800 万行を対象にバイト単位の一致を検証したと説明している。この結果は、比較処理が対象とした Engram の保存値について、元モデル由来の値が維持されていることを支持する。
ただし、バイト一致によって確認されるのは、比較処理で指定された対応関係におけるデータの同一性である。たとえば、元の参照テーブルと変換後の参照テーブルの値が一致していても、推論時に使用するハッシュ関数や参照位置の計算が異なれば、同じ入力から別の行を読み出す可能性がある。また、取得した値を内部状態へ組み込む処理が異なれば、同じ埋め込みベクトルから異なる演算結果が生じ得る。保存値の一致は、参照位置の計算や後続の演算の一致まで自動的に保証するものではない。
この関係は、保存データとデータを利用する処理を分けると明確になる。元の Engram と変換後の Engram で対応する行の値が一致していても、どの行を取得するかは入力に基づく参照処理で決まり、取得された値がどのような出力へ変換されるかは Backbone の演算によって決まる。今回のバイト一致検証は、この一連の処理のうち、参照テーブルに保存された値についての証拠である。元の保存値が維持されたことを確認できれば、後続の出力差を調べる際に、Engram の保存値そのものが変更されたという要因を切り分けられる。
5.2 パッキング処理の正常終了が確認すること
元の Engram の値を GGUF 形式へ保存する場合には、数値そのもののコピーに加えて、推論エンジンが読み込めるデータ配置へ変換する処理が必要になる。GGUF は、モデルの重みや構成情報をまとめるファイル形式であり、保存する数値の種類やテンソルの配置に関する情報も含む。元の値を正しく保持していても、ファイル内の配置や形式の指定が実行側の期待と一致していなければ、推論処理で利用できるとは限らない。
たとえば、参照テーブルの行が元の順序から入れ替わっている場合、ファイルを読み込めても、同じ参照位置から異なる値が取得される可能性がある。また、数値の値とスケールの対応関係が誤っていれば、保存されたバイト列の一部が元と一致していても、読み出した数値を正しく解釈できない。モデルの変換では、保存値の正確性に加えて、参照位置と保存領域の対応、数値形式の指定、実行時の読み出し方法が整合していることが必要になる。
Starw1 の検証ログには、Strata のパッキング処理が終了コード 0 で完了したことが記録されている[15]。終了コード 0 は、通常、実行したプログラムが正常終了を報告したことを意味する。この記録は、指定された入力ファイルと処理条件に対して、パッキング処理がエラー終了せずに完了したことを示している。
検証ログには、engram_token_map.weight、engram_primes.weight、engram_offsets.weight、engram_multipliers.weight の 4 種が、重みではないデータとしてパッキング対象から除外されたことも記録されている[15]。これらはトークンの対応関係や参照位置を決めるハッシュ計算に関係する情報である[10]。この除外は当該パッキング工程での扱いであり、推論時に参照位置の計算が省略されることを示さない。Engram の値とスケールが一致していても、参照位置の計算に必要な情報が推論時に正しく利用されることは別に確認する必要がある。
パッキング処理が正常終了したことと、生成されたファイルがあらゆる推論環境で正しく動作することは、検証範囲が異なる。たとえば、ある実装で正常に変換できたファイルでも、別の推論エンジンがその数値形式に対応していなければ読み込めない場合がある。また、ファイルの読み込みに成功しても、参照処理や数値演算の実装が異なれば、最終的な計算結果に差が生じる可能性がある。正常終了は変換処理の実行結果を示し、推論時の正確性は実行側の処理によって確認する必要がある。
Strata は、モデルの重みを異なるメモリー領域へ配置し、必要なデータを読み出しながら推論を実行するための実装を公開している。DeepSeek-V4.1-Flash-1017 のような大規模モデルについても、GPU のメモリーに収まらない重みを RAM や SSD から扱う構成を提供している[16]。この実装では、保存されたモデルの形式だけでなく、重みの配置、データ転送、参照処理などが実行時の条件になる。
今回のパッキング処理は、Starw1 の Engram を Strata の処理経路で扱うための確認に位置づけられる。元の値とのバイト一致が保存内容を検証するのに対し、パッキング処理の正常終了は指定されたファイル変換処理が完了したことを確認する。さらに、変換後のモデルを読み込んで推論を実行することで、実際の読み出しと計算が成立するかを調べられる。この三つの段階では、同じ Engram を対象としていても、検証している性質が異なる。
5.3 CPU の参照実装による生成試験
保存値とファイル形式の整合性を確認した後、実際に推論を実行することで、モデルを読み込み、入力を処理し、出力を生成するまでの経路を確認できる。推論の動作確認では、重みの読み込み、入力の処理、参照テーブルからの値の取得、Backbone の演算、次トークンの選択という複数の処理が関係する。最終的に出力が得られれば、少なくともその入力と実行条件において、生成に必要な処理が完了したことを確認できる。
Starw1 の検証ログには、CPU の参照実装を使用し、フランスの首都を都市名だけで答えるよう求める入力を与えた試験が記録されている。通常の Backbone と拒否関連表現を変更した Backbone の両方で、生成結果は Paris であった[15]。この結果は、指定された構成が簡単な事実質問に対して次のトークンを計算し、期待される都市名を出力できたことを示している。
この試験が持つ意味を考えるには、正しい文字列が出力されたという結果と、その文字列を生成するために実行された処理を区別する必要がある。Paris が生成されたことは、その入力に対して適切な候補が選択されたことを示す。同時に、入力を処理して候補を計算するまでの経路が、指定された参照実装で完了したことも確認できる。ただし、テーブルのすべての行が実際に参照されたわけではなく、モデルが取り得るすべての計算経路が実行されたわけでもない。生成試験で確認できる範囲は、その入力で通過した処理に限定される。
たとえば、短い地理的な質問では、参照されるトークンの組み合わせや、必要となる文脈の長さが限られている。長い文章を入力した場合には、異なる n-gram が参照され、より多くの情報が内部状態へ組み込まれる可能性がある。また、複数の条件を組み合わせる質問では、最初のトークンが正しく生成されても、後続の生成で誤った判断が生じる場合がある。単一の生成試験は、基本的な実行経路の確認には利用できるが、多様な入力に対する回答品質を評価するには、別の試験条件が必要になる。
さらに、ログには通常の Backbone と拒否変更後の Backbone が同じ Paris を最上位候補としながら、ほかの候補の値には差があることも記録されている[15]。これは、最終的に選択されたトークンが一致していても、出力候補に割り当てられたスコアや確率分布まで一致するとは限らないことを示している。たとえば、Paris が最も高いスコアを持つ状態が維持されていれば、ほかの候補のスコアが変化しても、最大スコアを選ぶ方式では同じ文字列が出力される。
候補のスコアに差が存在する場合、その差は後続の生成に影響する可能性がある。確率的な方法でトークンを選択する場合、候補の確率分布が変化すれば、同じ候補が最上位であっても選択されるトークンの確率は変わる。また、複数のトークンを生成する際には、直前に生成されたトークンが次の入力条件の一部となるため、一度選択が分かれると後続の文章にも差が広がり得る。同じ一語を生成したという結果と、モデルの出力分布や長文生成の挙動が一致することは、別々に確認する必要がある。
5.4 動作確認に要した時間と実用的な推論速度
CPU の参照実装による生成試験では、計算が完了したことに加えて、処理に要した時間も記録されている。公開ログに記載された生成ステップの時間は、通常の Backbone が 7424 秒、拒否変更後の Backbone が 4286 秒である[15]。それぞれ約 2 時間 4 分、約 1 時間 11 分に相当する。この時間は、公開された参照実装での実行結果を示すものであり、GPU を利用した通常の推論環境における生成速度を表す数値ではない。
参照実装は、処理の正確性や実装の整合性を確認するために使用される場合がある。たとえば、CPU で数値演算を順番に実行する構成では、GPU の並列演算や高速なメモリー転送を利用する構成と比べて、処理時間が長くなる可能性がある。また、低ビット量子化された重みを演算に利用するには、保存形式に応じた数値の復号や専用の演算処理が必要になる。参照実装がそれらの処理を単純な方法で実行する場合、同じモデルであっても最適化された推論エンジンとは異なる処理時間になる。
今回の記録から、通常の Backbone と拒否変更後の Backbone の実用的な速度差を判断することもできない。二つの試験で時間が異なるという観測結果は存在するが、その原因を重みの変更へ帰属させるには、使用した計算資源、実行順序、キャッシュの状態、測定の繰り返しなどを確認する必要がある。単一の実行時間には、モデルの計算そのものに加えて、データの読み込みや実行環境の状態による影響が含まれる可能性がある。
また、推論速度を評価する際には、入力を処理して最初のトークンを生成するまでの時間と、その後に連続してトークンを生成する速度を区別する必要がある。最初のトークンを生成する際には、モデルの初期化や入力の処理、必要な重みの読み込みなどが関係する。一方、連続生成では、既に計算した状態を利用しながら次のトークンを計算するため、参照テーブルの読み出しやキャッシュの利用状況が変化する。単一の生成ステップに要した時間だけでは、長い文章を生成する際の平均的な処理速度を判断できない。
特に、Starw1 の構成では約 202.8 GB の Engram を保持しているため、参照テーブルをどこに配置するかが実行性能へ関係する。必要な行を高速なメモリーから取得できる場合と、SSD から読み出す場合では、参照待ち時間が異なる。さらに、同じ行が繰り返し参照される場合にはキャッシュによって読み出しを減らせる可能性がある一方、参照する行が広い範囲へ分散する場合には、ストレージへのアクセスが増える可能性がある。保存容量が大きいことと、各トークンの生成で必要となるデータ転送量が大きいことは、同じ条件ではない。
Strata は、RAM や SSD を利用して大規模モデルの推論を実行する機能を公開している[16]。しかし、参照実装の動作確認から、Starw1 の MXFP8 Engram を使用した構成が、特定の GPU やメモリー容量でどの程度の速度を実現するかまでは確定しない。実用的な性能を判断するには、使用する計算機の構成、重みの配置、入力の長さ、生成トークン数を明示したうえで、初回生成までの時間と連続生成の速度を測定する必要がある。
5.5 公開された検証結果と保証できる範囲
Starw1 の公開記録に含まれる検証を整理すると、保存内容の一致、ファイル変換の完了、特定入力での推論成功という三つの段階を確認できる。さらに、推論時の出力候補の違いや処理時間の記録から、生成された文字列の一致と内部の計算結果の一致を区別する必要があることも分かる。これらの事実を一つの成功判定へまとめると、どの性質が実際に検証されたかが不明確になる。
| 検証対象 | 公開記録で確認できる内容 | 直接支持される結論 | 追加の検証が必要な性質 |
|---|---|---|---|
| Engram の保存内容 | 元の値とのバイト一致が PASS となり、不一致行は 0 件と記録されている。 | 比較対象となった Engram の値が元モデル由来の値と一致している。 | 参照位置の計算や後続の演算によって、元モデルと同じ結果が得られるかを確認する必要がある。 |
| Engram 層の対応 | 二つの Engram 層について、元のデータと変換後のデータの対応を確認している。 | 検証対象となった層の保存値と配置の対応が確認されている。 | 実際の推論で各層が正しい参照位置を使用し、取得した値を適切に統合するかを確認する必要がある。 |
| モデルの変換 | Strata のパッキング処理は終了コード 0 で完了した。 | 指定された実装と入力条件でファイル変換処理が正常終了した。 | 生成されたファイルの動作や、異なる推論エンジンとの互換性は、それぞれの環境で確認する必要がある。 |
| 簡単な文章生成 | 通常の Backbone と拒否変更後の Backbone が、フランスの首都を答える入力に対して Paris を生成した。 | 指定した入力と参照実装で推論処理が完了し、期待する都市名を出力した。 | 多様な質問、長文、コード生成、日本語などの品質は、対応する課題によって測定する必要がある。 |
| 出力候補の比較 | 最上位候補は一致したが、ほかの候補の値には差が記録されている。 | 同じトークンが選択されても、出力候補の計算結果が異なる場合がある。 | 複数トークンの生成や確率的な選択を含む条件で、出力分布と回答内容を比較する必要がある。 |
| 実行性能 | CPU の参照実装で、7424 秒と 4286 秒の生成ステップ時間が記録されている。 | それぞれの試験が指定された参照実装で完了し、実行時間が測定されている。 | GPU 利用時の速度、メモリー使用量、SSD 参照時の遅延、連続生成の性能は別途測定する必要がある。 |
表の前半は、元の Engram の数値を正確に保持できたかという問題に対応する。バイト一致と層の対応確認によって、元の参照テーブルを引き継ぐという変換目的に対する証拠が得られている。パッキング処理の正常終了は、その保存値を指定された実装が扱うためのファイル変換が完了したことを示す。さらに、簡単な生成試験によって、変換後の構成を利用した推論処理が特定条件で成立したことが確認されている。
一方、表の後半では、モデル全体の振る舞いを評価するために必要な条件が残されている。生成された Paris という文字列が一致していても、ほかの候補に割り当てられた値には差がある。これは、元の参照テーブルを保持したモデルでも、Backbone の変更によって出力候補の計算結果が変化し得ることを具体的に示している。保存値の一致によって参照テーブルの数値情報を固定できても、後続の演算まで同一になるわけではない。
また、記録された実行時間が数千秒であることは、今回の CPU 参照実装が主に動作確認のために使用されたことを理解するうえで意味がある。生成処理を最後まで実行できたという事実は、ファイル変換と推論経路の整合性を確認する証拠になる。しかし、実用的な推論速度の評価には、最適化された実行エンジンと具体的なハードウェア条件による測定が必要である。正常に動作することと、実用的な時間で処理できることを分けて評価する必要がある。
Starw1 の公開ログは、元の Engram を高精度で保持するという実装上の目的について、保存値の一致から簡単な推論の成立までを確認した記録である。この検証には、元の値を正確に引き継いだことを示す意味がある。同時に、元モデルとの回答品質の比較や、高精度 Engram による性能改善の測定については、別の証拠が必要であることも明確になる。
元の Engram をバイト単位で維持したことにより、参照テーブルの量子化誤差という一つの変更要因を除外できる。パッキングと生成試験によって、保存したデータを指定された処理経路で利用できたことも確認されている。しかし、モデル全体の出力は、参照した値と量子化済み Backbone の演算が組み合わされた結果として生成される。保存値の一致から回答品質の維持へ結論を進めるには、この計算結果を元モデルや比較対象の量子化モデルと同じ条件で測定し、実際の性能差を確認する必要がある。
6. 回答品質の維持にはどのような検証が必要か
元の精度で Engram を保存できたことと、その Engram を利用したモデルの回答品質が維持されたことを結びつけるには、比較対象と評価条件を明確にする必要がある。Starw1 の派生版では、Backbone を低ビット化したうえで、Engram の参照テーブルを元の MXFP8 精度で保持している。この構成により、Engram 自体の量子化誤差を回避できる。一方、最終的な回答は、参照した値を Backbone の演算へ組み込み、複数の層を通じて生成されるため、Engram の精度を変更した効果を確認するには、実際の出力を比較する必要がある。
さらに、今回の派生モデルには、拒否関連表現を変更した Backbone が使用されている。元モデルと Starw1 版を直接比較すると、Backbone の量子化、拒否関連表現の変更、Engram の精度という複数の条件が異なる。観測された回答の差を Engram の精度変更へ帰属させるには、少なくとも Backbone の条件を固定し、Engram の保存形式だけを変更した比較が必要になる。保存容量や実行速度についても、同じ構成で測定した数値を用いなければ、精度を維持することによる利点と負担を対応させられない。
6.1 保存容量の増加と実行性能への影響
Engram を高精度で保持すると、量子化された参照テーブルよりも保存容量が増加する。ISTA-DASLab の IQ4_NL Engram は 110.60 GB であるのに対し、Starw1 の MXFP8 Engram は約 202.8 GB であり、差は約 92.2 GB となる。この増加分は、モデルの保存や配布に必要な容量へ直接反映される。一方、実行時のメモリー使用量と処理時間は、保存したデータをどのように配置し、どの範囲を読み出すかによって決まる。
Engram は、入力されたトークン列から決まる参照位置に対応した行を取得する構造である。たとえば、約 202.8 GB のテーブルを保持していても、ある入力で必要となる行が限られていれば、毎回テーブル全体を読み出す必要はない。必要な行を GPU のメモリーへ事前に配置する方法、CPU 側のメモリーから転送する方法、SSD 上のファイルを必要に応じて読み出す方法では、それぞれ異なる資源要求が生じる。保存容量が同じでも、メモリーへの配置と読み出し方法によって実行性能が変化する理由は、データ転送と演算の実行時間が異なるためである。
演算用の重みでは、必要なデータを演算装置へ供給する速度が性能上の制約になる場合がある。GPU が高速に行列演算を処理できても、次の演算に必要な重みがメモリーから届かなければ、演算装置はデータを待つことになる。逆に、必要な重みを十分な速度で供給できる場合には、演算装置自体の計算能力が処理速度の上限になる。この関係を整理する考え方として、Roofline モデルが知られている[17]。
Roofline モデルでは、ある計算処理が達成できる演算性能の上限を、演算装置の最大性能とメモリー帯域の双方から評価する。演算装置が 1 秒間に処理できる最大演算回数を \(P_{\mathrm{peak}}\)、メモリーが 1 秒間に転送できるデータ量を \(B_{\mathrm{mem}}\)、メモリーから読み出した 1 バイト当たりの演算回数を \(I\) とすると、達成可能な演算性能 \(P\) の上限は次のように表される。
\[
P \leq \min\left(P_{\mathrm{peak}}, B_{\mathrm{mem}}I\right)
\]
右辺の第一項 \(P_{\mathrm{peak}}\) は、演算装置自体の最大性能である。第二項 \(B_{\mathrm{mem}}I\) は、メモリーから供給できるデータ量によって制限される演算性能を表す。たとえば、演算装置の能力が十分に大きくても、メモリー帯域とデータ利用効率の積が小さければ、処理性能はメモリーからのデータ供給によって制約される。反対に、データ供給が十分であれば、演算装置の最大性能が上限になる。この式は性能の上限を示すものであり、実際の処理時間をそのまま計算できるわけではない。
Engram のような参照テーブルでは、さらに読み出し遅延とアクセスの局所性が関係する。局所性とは、短い時間に同じ場所や近接した場所のデータを繰り返し利用する性質である。頻繁に参照される行がキャッシュに保持されていれば、毎回 SSD へアクセスする必要がなくなる。一方、参照位置が広い範囲に分散し、必要な行がキャッシュに存在しなければ、ストレージからの読み出しが増加する。少量のデータを離れた位置から繰り返し取得する場合には、総転送量が小さくても、一回ごとの読み出し遅延が処理時間へ影響する可能性がある。
元の Roofline モデルは、主に演算性能とメモリー帯域から計算処理の上限を評価するものである。SSD からの不規則な読み出しや、CPU と GPU の間のデータ転送に伴う待ち時間は、その式だけでは直接評価できない。Engram の実行性能を調べる場合には、演算用 Backbone の処理時間に加えて、参照位置の計算、必要な行の読み出し、キャッシュの命中状況、転送待ち時間を確認する必要がある。
また、MXFP8 Engram を使用する場合には、推論エンジンが保存された値をどの数値精度で演算へ渡すかも確認対象になる。保存ファイルに元の MXFP8 の値が含まれていても、実行時に別の数値形式へ変換して演算する場合には、その変換処理と演算精度が結果に影響する可能性がある。保存値のバイト一致は、保存形式に関する検証である。実行時に参照された値がどのように解釈され、どの精度で後続の演算へ渡されたかは、推論エンジンの実装によって決まる。
こうした違いを含めて評価するには、モデルのファイル容量だけでなく、GPU のメモリー使用量、CPU 側のメモリー使用量、SSD の読み出し量、最初のトークンを生成するまでの時間、連続生成時のトークン数当たりの処理時間を測定する必要がある。Engram の高精度化によって保存容量が約 92.2 GB 増加することは確認できるが、その増加が実行速度へ与える影響は、参照方式と実行環境の条件を揃えた測定によって判断される。
6.2 Engram の精度と Backbone の変更を分離する
高精度 Engram が回答品質へ与える影響を測定するには、比較する二つのモデルの間で、どの条件が異なるかを特定する必要がある。元モデルと Starw1 版を比較するだけでは、Backbone の量子化と拒否関連表現の変更も含まれるため、出力差の原因を Engram の精度へ限定できない。Engram の数値表現を変更した効果を識別するには、同じ Backbone に対して IQ4_NL と MXFP8 の Engram を組み合わせ、それ以外の条件を揃える方法が考えられる。
さらに、拒否関連表現の変更が Engram の精度による影響とどのように関係するかを調べる場合には、Backbone の種類も比較条件として扱うことができる。通常の GSQ-RCO Backbone と、拒否関連表現を変更した Backbone のそれぞれに、二種類の Engram を組み合わせると、次の四条件になる。
| Backbone | IQ4_NL Engram | MXFP8 Engram |
|---|---|---|
| 通常の GSQ-RCO Backbone | 条件 A。量子化済み Engram を使用する基準構成であり、ISTA-DASLab の IQ2_XXS に対応する。 | 条件 B。通常の Backbone を固定したまま、Engram の保存精度を MXFP8 に変更する構成である。 |
| 拒否関連表現を変更した Backbone | 条件 C。Abiray の変更済み Backbone と IQ4_NL Engram を組み合わせた構成である。 | 条件 D。Abiray の変更済み Backbone と MXFP8 Engram を組み合わせた Starw1 の公開構成に対応する。 |
比較する Backbone には同じ重みの版を使用し、モデルのリビジョン、GGUF のファイル構造、推論エンジンの対応版を記録する必要がある。ISTA-DASLab は 2026 年 10 月 27 日に GGUF の配置を更新しており、同じモデル名でも取得時点によってファイル構造が異なる場合がある[11]。形式の変換が必要な場合は、変換前後で比較対象の重みが一致していることを確認し、Engram の精度以外の差を実験へ持ち込まないようにする。
この四条件は、Engram の精度と拒否関連表現の変更をそれぞれ独立した比較要因として配置したものである。条件 A と B を比較すると、通常の Backbone を固定した状態で、Engram の精度変更による差を測定できる。条件 C と D を比較すると、拒否関連表現を変更した Backbone を固定した状態で、同じく Engram の精度変更による差を測定できる。いずれの場合も、Backbone を同一に保つことで、量子化済みの演算用重みや拒否関連表現の違いを比較から取り除ける。
一方、条件 A と C を比較すると、IQ4_NL Engram を固定した状態で、拒否関連表現の変更による差を測定できる。同じ方法で条件 B と D を比較すると、MXFP8 Engram を固定した状態で、拒否関連表現の変更による差を調べられる。これらの比較では、Engram の保存形式を統一しているため、観測された差を Backbone の変更と対応させやすくなる。
ただし、二つの変更がモデル内部で独立に作用するとは限らない。Engram から取得した埋め込みベクトルは Backbone の演算へ組み込まれるため、Engram の値が変わると、拒否関連表現の変更を加えた部分へ入力される内部状態も変化し得る。たとえば、通常の Backbone では Engram の精度変更による回答差が小さくても、拒否変更済み Backbone では同じ精度変更によって候補の順位が変わる場合が考えられる。この場合、Engram の精度変更による効果が Backbone の状態に依存していることになる。
この相互作用を調べるには、条件 A と B の差と、条件 C と D の差を比較する。ある評価指標について、四条件の得点をそれぞれ \(Q_A\)、\(Q_B\)、\(Q_C\)、\(Q_D\) とすると、Engram の精度変更による差が Backbone の種類によってどの程度変わるかは、次のように表せる。
\[
\Delta_{\mathrm{interaction}}=(Q_D-Q_C)-(Q_B-Q_A)
\]
第一項 \(Q_D-Q_C\) は、拒否変更済み Backbone における Engram の精度変更による得点差である。第二項 \(Q_B-Q_A\) は、通常の Backbone における同じ精度変更による得点差を表す。両者の差 \(\Delta_{\mathrm{interaction}}\) が 0 から離れていれば、Engram の精度変更による効果が Backbone の種類によって異なる可能性がある。ただし、観測された差が測定上の変動によるものかを判断するには、評価データ数や繰り返し測定に基づく不確実性も確認する必要がある。
この式は比較条件の関係を示すものであり、四条件すべてについて実測結果が存在することを意味しない。ISTA-DASLab、Abiray、Starw1 の公開資料から確認できる構成と、実験のために追加で用意する構成を区別する必要がある。特に、条件 B は通常の GSQ-RCO Backbone に MXFP8 Engram を組み合わせる対照条件として設計したものであり、今回確認した公開モデルの一覧から、その条件のベンチマーク結果まで得られているわけではない。
また、異なる Engram 形式を比較する場合には、同じ推論エンジンを使用するだけでなく、それぞれの数値形式が正しく読み込まれることを確認する必要がある。たとえば、IQ4_NL の値を復元する処理と、MXFP8 の値を解釈する処理が異なる場合、最終的な差には保存精度だけでなく、その数値形式に固有の実行処理も関係する。比較の目的が実用的なモデル構成の評価であれば、その差を含めて測定する。一方、保存精度そのものの効果を詳しく調べる場合には、演算へ渡される値や内部状態も比較し、どの段階で差が生じたかを確認する方法が有効である。
6.3 公開されたベンチマークは何を示しているか
ISTA-DASLab のモデルカードには、元の DeepSeek-V4.1-Flash-1017 と、GSQ-RCO で量子化した複数のモデルの比較結果が掲載されている。評価には AIME25、GPQA-Diamond、LiveCodeBench v6 が使用されている。AIME25 は数学的な問題解決、GPQA-Diamond は専門的な知識と推論を必要とする問題、LiveCodeBench はプログラム生成などの能力を評価する課題である。いずれもモデルの能力を測定するための指標だが、評価する課題の性質は異なる。
公開された結果では、元モデルと GSQ-RCO IQ2_XXS が、AIME25 で 100.00、GPQA-Diamond で 90.91、LiveCodeBench v6 で 89.71 という同じスコアを記録している[11]。三つの指標を単純平均した得点も、両モデルとも 93.54 である。ISTA-DASLab は、この結果を元モデルに対する平均得点の維持率 100.0% として報告している。評価時の推論努力設定は 50 であり、モデルに与えられる推論の条件を揃えて測定された数値である。
この結果は、ISTA-DASLab が実施した三つの課題の評価で、量子化済みモデルと元モデルの集計得点が一致したことを示している。特に、約 5519 億の Transformer の重みを平均 2.00 ビットで保存する構成でも、掲載された評価条件では元モデルの得点を維持したことに意味がある。ただし、同じスコアになったことは、個々の問題で同じ回答を生成したことや、内部の出力確率分布が一致したことを直接示すものではない。
たとえば、100 問の評価で二つのモデルがともに 90 問正解した場合、正答率は同じ 90% になる。しかし、二つのモデルが同じ 90 問を正解したとは限らない。一方のモデルだけが正解した問題と、もう一方のモデルだけが正解した問題が存在していても、合計の正答数が同じであれば得点は一致する。さらに、正答した問題でも、解答に至る途中の文章や計算過程が異なる場合がある。集計後のスコアが一致することと、各入力に対する振る舞いが一致することは異なる。
AIME25 の 100.00 という値についても、評価対象となった問題で満点を記録したことを意味する。これは高い正答率を示すが、別の数学問題や入力形式に対して常に正答するという意味ではない。また、満点に達した指標では、それ以上の改善が得点に現れない。二つのモデルが同じ満点を記録した場合、その評価だけでは、正答までに必要な計算量や、別の難易度の問題での差を識別できない。
さらに、このベンチマークで使用された Engram は、ISTA-DASLab が公開した IQ4_NL 形式である[11]。Starw1 の MXFP8 Engram を使用した構成ではないため、元モデルと IQ2_XXS の得点が一致したという結果から、MXFP8 Engram の優位性を導くことはできない。むしろ、IQ4_NL Engram を使用した構成が既に三つの課題で元モデルと同じ得点を得ているため、Engram の高精度化による差を検出するには、評価対象や採点方法を慎重に選ぶ必要がある。
たとえば、IQ4_NL 版と MXFP8 版が同じ問題で同じ正答率を記録した場合、その評価では高精度化による改善を確認できなかったことになる。一方、参照した情報の違いが解答へ影響しやすい問題で差が生じれば、その入力条件における精度変更の影響を測定できる。特定の課題で差が生じなかったという結果も、差が生じたという結果も、評価対象の範囲と合わせて解釈する必要がある。
Engram の精度変更を調べる場合には、単に一般的なベンチマークの平均得点を比較するだけでなく、元の IQ4_NL と MXFP8 の参照値にどの程度の差が生じるか、その差が実際に参照される入力でどのように現れるかも調べられる。参照値の差が大きい入力と小さい入力を区別し、それぞれについて内部状態や最終出力を比較すれば、Engram の量子化誤差が後続の計算へどのように伝わるかを詳しく評価できる。ただし、参照値の数値差が大きいことだけで回答品質の低下が決まるわけではなく、最終的な正答や課題達成への影響を別途測定する必要がある。
6.4 評価条件の再現性と測定上の不確実性
言語モデルの評価結果を比較する場合には、同じ問題を使用していても、入力の提示方法や生成時の設定によって結果が変化する可能性がある。たとえば、質問文を単独で与える場合と、問題を解く手順まで指示する場合では、モデルが生成する文章や正答率が異なることがある。また、複数の選択肢から答えを選ぶ問題でも、選択肢の順序や採点時の文字列処理によって結果が変わる場合がある。評価対象のモデルを固定しただけでは、測定条件が同一になったことにはならない。
言語モデル評価の再現性を扱う研究では、入力形式、評価方法、実装上の取り扱いの違いによって、モデルの比較結果が変化する問題が指摘されている[18]。評価に使用したデータセットの名称だけでなく、実際の入力文、生成設定、出力の抽出方法、採点処理を記録することが、結果の再現性に関係する。異なるモデルを比較する場合には、こうした条件を揃えたうえで、それぞれの出力を同じ基準で採点する必要がある。
DeepSeek-V4.1-Flash-1017 の派生モデルを比較する場合には、推論努力設定も確認対象になる。ISTA-DASLab の公開ベンチマークは、推論努力設定 50 の条件で測定されている。この設定が異なれば、モデルが推論に利用する処理量や生成内容が変化する可能性がある。たとえば、一方のモデルだけが多くの推論処理を実行する条件になっていれば、得点差がモデルの重みの違いによるものか、推論条件の違いによるものかを識別しにくくなる。
また、確率的なトークン選択を使用する場合には、同じモデルと入力を使用しても生成結果が変化することがある。温度設定は、候補のスコアから計算される選択確率の分布を調整する値であり、温度が高いほど低順位の候補も選択されやすくなる場合がある。乱数の種を固定すれば、実装によっては同じ結果を再現しやすくなるが、演算順序やハードウェアの違いによる数値差まで完全に取り除けるとは限らない。確率的な生成を評価する場合には、複数回の測定によって結果の変動を確認する方法が考えられる。
回答品質の差については、測定された得点差の大きさと、その得点差の不確実性も区別する必要がある。たとえば、100 問の評価で二つのモデルの正答数が 90 問と 91 問になった場合、観測された差は 1 ポイントである。しかし、問題の選び方や生成時の変動によって、別の評価集合では差の方向が変わる可能性もある。差が 1 ポイント観測されたという事実と、対象とする問題分布全体で一方のモデルが優れているという判断は、同じ意味ではない。
同じ問題集合で二つのモデルを評価する場合には、各問題について正答と誤答の組み合わせを記録すれば、どの問題で結果が変化したかを確認できる。全体の正答率だけを比較する方法より、精度変更によって正答から誤答へ変わった問題と、誤答から正答へ変わった問題を区別できる。さらに、必要に応じて対応のある比較に適した統計的な方法を用いれば、観測された差がどの程度の不確実性を持つかを評価できる。
複数の評価指標を使用する必要性については、言語モデルを総合的に評価する HELM の研究でも論じられている[19]。HELM は、正答率に加えて、頑健性、公平性、バイアス、有害性、効率などの異なる指標を組み合わせ、モデルの性質を複数の側面から測定する枠組みである。ある課題での正答率が高いことと、入力条件の変化に対する安定性や実行効率が高いことは、同じ性質ではない。モデルの変更によって何が改善し、何が変化しなかったかを判断するには、目的に対応する指標を選ぶ必要がある。
今回の派生モデルでは、Engram の精度変更と拒否関連表現の変更が共存しているため、能力評価と拒否挙動の評価も分離する必要がある。拒否を期待する入力に対して回答する割合が増えた場合、拒否挙動が変化したことは確認できる。しかし、その回答が正確かどうかは別の問題である。また、通常の知識問題で正答率が維持されていても、拒否関連表現の変更が特定の入力で別の応答を引き起こす可能性がある。回答の正確性、拒否率、生成内容の適切性を、それぞれ異なる指標として扱う必要がある。
6.5 モデルの変更目的に対応した評価項目
Engram の高精度化による影響を調べる際には、保存容量、参照処理、回答品質、拒否挙動を異なる評価項目として整理できる。保存容量は公開されたファイルの大きさから比較できる。参照処理については、同じ入力から取得した Engram の値と、後続の演算へ渡される内部状態を比較する。回答品質については、同じ課題に対する正答率や成功率を測定する。実行性能については、メモリー使用量や生成速度を測定する。
評価項目と固定すべき条件を対応させると、次のようになる。
| 評価対象 | 測定する指標 | 固定・記録する条件 | 判断できること |
|---|---|---|---|
| 保存容量 | Backbone、Engram、モデル全体のファイル容量を比較する。 | 保存形式、対象ファイル、容量の単位を統一する。 | 高精度 Engram を保持するために追加で必要となる保存容量を確認できる。 |
| 参照値の精度 | IQ4_NL と MXFP8 の参照値を元の値と比較し、数値誤差を測定する。 | 参照位置、比較対象の行、スケールの解釈方法を統一する。 | Engram の保存形式によって生じる数値差を確認できる。 |
| 内部状態の変化 | Engram の統合前後や後続の層における数値の差を比較する。 | 入力、Backbone、推論エンジン、演算精度を可能な範囲で揃える。 | 参照値の違いが後続の計算へどのように伝わるかを確認できる。 |
| 知識問題の正答率 | 同じ問題集合に対する正答数と、正誤が変化した問題を記録する。 | 問題集合、入力形式、採点基準、生成設定を統一する。 | 評価した知識問題における回答品質の変化を確認できる。 |
| 数学的推論とコード生成 | 数学問題の正答率や、生成したコードのテスト成功率を測定する。 | 問題の難易度、推論努力、実行環境、採点方法を統一する。 | 複数段階の計算やプログラム生成における能力の変化を確認できる。 |
| 日本語と長文脈 | 日本語の質問への正答率、長文からの情報抽出、複数情報の統合結果を比較する。 | 入力言語、文脈長、問題集合、出力条件を統一する。 | 言語や入力長の違いによって、精度変更の影響が変化するかを確認できる。 |
| 拒否挙動 | 入力の分類ごとに拒否率と応答内容を測定する。 | Engram の形式、入力集合、推論設定を固定して Backbone を比較する。 | 拒否関連表現の変更による挙動の差を確認できる。 |
| 実行性能 | 初回トークン生成時間、連続生成速度、RAM・VRAM 使用量、SSD 読み出し量を測定する。 | ハードウェア、推論エンジン、モデル配置、入力長、キャッシュの状態を記録する。 | 保存精度の変更が実用的な資源要求と処理時間へ与える影響を確認できる。 |
この評価では、すべての指標を一つの数値へまとめる必要はない。たとえば、MXFP8 Engram に変更して知識問題の正答率が改善しても、保存容量や読み出し時間が増加する可能性がある。逆に、IQ4_NL Engram で同じ正答率が得られる場合には、少なくともその評価条件では、追加の保存容量に対応する品質改善を確認できなかったことになる。どちらの構成が適切かは、評価対象の能力と実行環境の制約によって変わる。
また、回答品質の変化が確認された場合には、その変化がどの入力で生じたかを調べることが有効である。たとえば、特定の n-gram を含む質問でのみ IQ4_NL と MXFP8 の回答に差が生じるなら、その n-gram から参照される Engram の値と、後続の計算結果を比較できる。参照値の差が出力候補の順位へ影響したことを確認できれば、保存精度と回答の変化を具体的な計算経路で結びつけられる。一方、参照値に差があっても最終出力が変化しない場合には、その入力条件では後続の計算が差を吸収した可能性がある。
このような比較は、単に二つのモデルの正答率を並べる方法より、精度変更による影響が生じる条件を詳しく説明できる。ただし、内部状態の数値差と最終的な回答品質の関係は、モデルの演算と入力によって変化する。特定の問題で観測された関係を、すべての入力へ直接適用することはできない。複数の問題や文脈長で同じ傾向が観測されるかを確認することで、精度変更の影響がどの範囲で再現するかを評価できる。
実行性能についても、測定条件を区別する必要がある。たとえば、同じ質問を繰り返す試験では、参照した Engram の行がキャッシュに残り、二回目以降の読み出し時間が短くなる可能性がある。一方、異なる質問を連続して処理する試験では、参照位置が分散し、SSD へのアクセスが増える場合がある。キャッシュが十分に利用できる条件と、初回読み出しが多い条件を分けて測定すれば、参照テーブルを高精度で保持したことによる実行時の負担を具体的に評価できる。
GPU のメモリー容量についても、モデルを起動できたことと、期待する速度で推論できたことは異なる。Strata のように RAM や SSD を利用する実装では、GPU のメモリーへモデル全体を配置しなくても推論処理を実行できる可能性がある。しかし、処理に必要な重みや参照値を適切なタイミングで読み出せなければ、データ転送の待ち時間が増加する。実用性を判断するには、起動可能な最小 VRAM だけでなく、RAM の容量、SSD の性能、入力長、生成速度を組み合わせて評価する必要がある。
6.6 高精度化の効果をどこまで結論できるか
Engram の高精度化には、元の参照値を保持するという明確な技術的目的がある。IQ4_NL では、元の数値を限られた代表値へ変換することで保存容量を削減するため、参照テーブルの値に量子化誤差が生じ得る。MXFP8 では、元モデル由来の値とスケールを維持することで、その部分の量子化誤差を回避できる。Starw1 のバイト一致検証は、この保存上の目的に対応した証拠である。
ただし、参照テーブルの量子化誤差を回避できたことから、回答品質の改善量を直接計算することはできない。Engram の値がどの入力で参照されるか、その値が Backbone の演算へどの程度反映されるか、量子化済み Backbone の重みが後続の計算へどのような影響を与えるかによって、最終的な出力差が決まる。元の値を保持するという操作の効果は局所的に明確であっても、モデル全体の回答品質への寄与は入力と計算経路に依存する。
ISTA-DASLab の IQ2_XXS 構成が三つのベンチマークで元モデルと同じ得点を記録していることは、公開者が設定した課題と条件で集計得点が維持されたことを示している。この結果と Starw1 の保存値の検証結果を組み合わせても、MXFP8 Engram の優位性が実証されたことにはならない。前者は IQ4_NL Engram を使用したモデルの回答品質を測定した結果であり、後者は MXFP8 Engram の保存値を確認した結果だからである。
高精度 Engram の寄与を直接評価するには、同じ Backbone に IQ4_NL と MXFP8 の Engram を組み合わせ、同じ入力集合と推論条件で回答を比較する必要がある。さらに、得点差が生じた問題について参照値や内部状態を調べれば、その差がどの計算経路で発生したかを検討できる。精度変更による性能差を数値で示すことと、その性能差が発生した原因を説明することは、異なる段階の検証である。
また、品質面で改善が確認された場合にも、約 92.2 GB の追加保存容量と実行時の資源要求を考慮する必要がある。高精度化によって特定の能力が改善しても、その改善が必要とされる用途と、利用可能な RAM、VRAM、SSD の条件によって実用上の評価は変わる。反対に、低ビットの Engram で必要な品質を満たせる場合には、保存容量を削減する構成が適する可能性もある。どの構成を選択するかは、品質と資源要求を同じ実行条件で測定した結果に基づいて判断される。
今回の派生モデルについて、公開資料から確認できるのは、Engram の元の数値表現が維持されていること、指定された実装で変換と簡単な推論が成立したこと、そして別の量子化済み構成について特定のベンチマーク結果が報告されていることである。これらは、それぞれ異なる検証対象について得られた証拠である。高精度 Engram を組み合わせたモデル全体の回答品質や実行性能については、同一条件による対照比較が必要になる。
7. 情報の保存精度とモデルの性能を分けて判断する
DeepSeek-V4.1-Flash-1017 の派生モデルは、低ビット化した Backbone と元の MXFP8 精度の Engram を組み合わせ、重みの用途によって保存精度を変える構成である。Abiray の変更済み Backbone と IQ4_NL Engram の組み合わせは約 249.18 GB、Starw1 の MXFP8 Engram を使用した構成は約 341.4 GB となる。約 92.2 GB の増加分は Engram の保存形式の違いに対応し、その追加容量による回答品質の変化は別途測定する必要がある。
Starw1 の公開記録では、元モデル由来の Engram の値とスケールについてバイト一致が確認され、パッキング処理の正常終了と CPU の参照実装による Paris の生成も記録されている。これは比較対象となった保存値の一致と、指定された実行条件での生成処理の成立を示す。一方、検証ログでは参照位置の計算に関係する非重みデータがパッキング対象から除外されており、保存値の一致だけで参照処理の全条件が確定するわけではない。
Engram の参照値が一致していても、その値はゲートによる調整と Backbone の演算を経て出力へ反映される。元モデルに対して低ビット化や拒否関連表現の変更が加われば、後続の内部状態や出力候補のスコアに差が生じ得る。実際に公開ログでは、通常の Backbone と拒否変更後の Backbone がともに Paris を生成した一方、ほかの候補の値には違いが記録されている。保存値、選択されたトークン、候補分布は、それぞれ異なる対象である。
ISTA-DASLab の IQ2_XXS 版は、公開者が実施した AIME25、GPQA-Diamond、LiveCodeBench v6 の評価で元モデルと同じ集計得点を記録している。ただし、この評価は IQ4_NL Engram を使用した構成に対するものであり、Starw1 版の測定結果ではない。MXFP8 Engram の寄与を特定するには、同じ版の Backbone と推論条件を固定し、IQ4_NL と MXFP8 を切り替えて各問題の正誤や出力を比較する必要がある。拒否関連表現の変更は、さらに別の比較要因として管理する。
実用上の評価には、約 92.2 GB の追加容量に加え、RAM や VRAM の使用量、参照テーブルの読み出し遅延、連続生成速度が関係する。Engram は必要な行を選択して取得するため、保存容量の増加がそのまま各トークンの転送量になるわけではない。しかし、SSD や CPU 側メモリーからの読み出しが演算に間に合わない場合には、生成速度へ影響する。品質と資源要求は、同じ実行環境で対応づけて測定する必要がある。
この構成で元の Engram をバイト単位で保持した意義は、参照テーブル自体の量子化誤差を除外し、比較実験の一つの条件を固定できる点にある。そこからモデル全体の能力維持を判断するには、参照位置の計算、値の統合、低ビット化された Backbone の演算、最終的な回答品質を区別して検証する必要がある。この区別を保つことで、Starw1 のバイト一致を Engram の保存精度の実証として位置付け、モデル全体の能力維持については対照実験の結果から判断できる。
参考文献
- id774, 量子化について詳しく解説する（2026-08-07）. https://blog.id774.net/entry/2026/08/07/5472/
- id774, 低ビット量子化では誤差の発生時刻と寿命と方向へ精度を配る（2026-10-24）. https://blog.id774.net/entry/2026/10/24/5746/
- Alireza Dadgarnia et al., “GSQ: Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling” (2026-04-20). https://arxiv.org/abs/2604.18556
- Michael Helcig and Dan Alistarh, “Model Compression with Exact Budget Constraints via Riemannian Manifolds” (2026-05-01). https://arxiv.org/abs/2605.00649
- id774, AI の性能を守りながら資源を減らすには残す場所を選ぶ（2026-10-18）. https://blog.id774.net/entry/2026/10/18/5729/
- id774, 三値 LLM の圧縮は保存量と復号処理の配置問題になる（2026-09-25）. https://blog.id774.net/entry/2026/09/25/5710/
- Xin Cheng et al., “Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models” (2026-01-12). https://arxiv.org/abs/2601.07372
- DeepSeek-AI et al., “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression” (2026-09-17). https://arxiv.org/abs/2609.19969
- deepseek-ai, DeepSeek-V4.1-Flash-1017. https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017
- deepseek-ai, inference/engram.py, DeepSeek-V4.1-Flash-1017. https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017/blob/main/inference/engram.py
- ISTA-DASLab, DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF. https://huggingface.co/ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF
- Abiray, DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-GGUF. https://huggingface.co/Abiray/DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-GGUF
- Starw1, DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-MXFP8-Engram-GGUF. https://huggingface.co/Starw1/DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-MXFP8-Engram-GGUF
- Andy Arditi et al., “Refusal in Language Models Is Mediated by a Single Direction” (2024-06-17). https://arxiv.org/abs/2406.11717
- Starw1, verification.log, DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-MXFP8-Engram-GGUF. https://huggingface.co/Starw1/DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-MXFP8-Engram-GGUF/blob/main/verification.log
- Niko1221, Strata. https://github.com/Niko1221/Strata
- Samuel Williams, Andrew Waterman and David A. Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures” (2009-04). https://doi.org/10.1145/1498765.1498785
- Stella Biderman et al., “Lessons from the Trenches on Reproducible Evaluation of Language Models” (2024-05-23). https://arxiv.org/abs/2405.14782
- Percy Liang et al., “Holistic Evaluation of Language Models” (2022-11-16). https://arxiv.org/abs/2211.09110