Unweight: 品質を犠牲にせずLLMを22%圧縮した方法

世界中のインターネット接続人口の95%に対して50ms以内で推論（inference）を実行するには、GPUメモリを徹底的に効率的に扱う必要があります。昨年、Rustベースの推論エンジンであるInfireでメモリ利用率を向上させ、モデルスケジューリングプラットフォームであるOmniでコールドスタート（cold-starts）を解消しました。現在、私たちは推論プラットフォームにおける次の大きなボトルネックであるモデルウェイト（model weights）に取り組んでいます。 LLMから単一のトークンを生成するには、GPUメモリからすべてのモデルウェイトを読み取る必要があります。多くのデータセンターで使用するNVIDIA H100 GPUでは、テンソルコア（tensor cores）がデータを処理する速度はメモリが配信できる速度の約600倍に達し、計算能力ではなくメモリ帯域幅（memory bandwidth）がボトルネックとなります。メモリバスを横断するすべてのバイトは、ウェイトが小さければ回避できた潜在的な無駄です。 この問題解決のため、Unweightを開発しました。これは特殊なハードウェアに依存せず、モデルウェイトを最大15〜22%小さくしながらビット完全な出力（bit-exact outputs）を保持する、損失なし圧縮システムです。ここでの核心的な突破口は、高速なオンチップメモリ（on-chip memory）でウェイトを解凍し、テンソルコアに直接供給することで、低速なメインメモリへの不要な往復を回避できる点にあります。ワークロードに応じて、Unweightのランタイムは複数の実行戦略から選択します（単純さを優先するものもあれば、メモリトラフィックを最小限に抑えるものもあります）、そしてオートチューナー（autotuner）がウェイト行列とバッチサイズごとに最適な戦略を自動で選択します。 本記事ではUnweightの動作原理に深く迫りますが、より高い透明性と急速に進化するこの分野でのイノベーションを促進する精神に基づき、技術論文の公開とGPUカーネル（GPU kernels）のオープンソース化も実施します。 Llama-3.1-8Bでの初期結果では、マルチレイヤーパーセプトロン（Multi-Layer Perceptron, MLP）のウェイトのみで約30%の圧縮率を示しています。Unweightはデコード用のパラメータに対して選択的に動作するため、これによりモデルサイズが15〜22%縮小し、VRAMを約3GB節約できます。以下の図に示す通り、これによりGPUからより多くの性能を引き出し、より多くの場所でより多くのモデルを実行可能になります。これによりCloudflareネットワーク上での推論コストを削減し、速度を向上させます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4aOVSF1i241gGUwrPrhLfC/21a4f5984b89e56b1ec637f8dbe3c794/1.png) Unweightのおかげで、単一のGPUにより多くのモデルを収容できるようになりました Why compression is harder than it sounds 推論を高速化したり、より小さなGPUで実行するために、創造的な方法でモデルウェイトを圧縮する方法を探る研究が徐々に増えています。最も一般的なのは量子化（quantization）で、32ビットまたは16ビットの浮動小数点数を8ビットまたは4ビットの整数に変換することで、モデルウェイトと活性化値（activations）のサイズを削減する技術です。これは損失あり圧縮（lossy compression）の一種であり、異なる16ビット浮動小数点数が同じ4ビット整数に変換される場合があります。この精度の低下は、回答の品質に予測不能な影響を及ぼします。多様なユースケースに対応する本番環境の推論では、モデルの動作を完全に保持する損失なし圧縮（lossless compression）が必要であることは明らかでした。 最近のいくつかのシステム（Huff-LLM、ZipNN、ZipServ）は、大規模言語モデル（Large Language Model, LLM）の重みを大幅に圧縮できることを示したが、これらのアプローチは我々の対象とする問題とは異なる。ZipNNは配布と保存のための重み圧縮を扱い、デコンプレッションはCPU上で行われる。HUff-LLMは復号化のためのカスタムFGPA（Field-Programmable Gate Array）ハードウェアを提案している。またZipServはデコンプレッションとGPU推論を融合させるが、対象とするのは消費者向けグレードのGPUであり、これは当社のH100 GPUでは動作しない。これらのいずれもが我々が求めているもの、つまりHopper GPU上で推論時にロスレス（無損失）なデコンプレッションを行い、Rustベースの推論エンジンと統合できるソリューションを提供しなかった。 中核となる課題は単なる標準的な圧縮ではない——BF16重みの指数部バイトは冗長性が高いため、エントロピー符号化（entropy coding）が非常に効果的に機能する。真の課題は、推論速度を低下させないほど十分に高速にデコンプレッションを行うことである。H100上では、テンソルコア（tensor cores）はメモリの読み込みを待つ間、大半の時間をアイドル状態にしている——しかし、そのアイドル状態の容量を単にデコンプレッション用に再利用することはできない。シェアドメモリ制約（shared memory constraints）のため、各GPUの計算ユニットはデコンプレッションカーネルと行列乗算カーネル（matrix multiplication kernel）のどちらか一方しか同時に実行できず、両方を並行して動かすことはできない。行列乗算と完全にオーバーラップしないデコードレイテンシ（decode latency）は、トークン生成レイテンシ（token latency）に直接加算されてしまう。Unweightの解決策は、高速なオンチップ・シェアドメモリ（on-chip shared memory）内で重みをデコンプレッションし、その結果を直接テンソルコアに供給することである——しかし、異なるバッチサイズ（batch sizes）や重みの形状 across でこれを効率的に動作させることが、真のエンジニアリングの要所となる。 モデル重みの効果的な圧縮方法 AIモデル内のすべての数値は、16ビットの「ブレインフロート（brain float）」（BF16）として保存される。各BF16値は3つの部分で構成される： 符号部（Sign）（1ビット）：正負の区別 指数部（Exponent）（8ビット）：数値の大きさ 仮数部（Mantissa）（7ビット）：その大きさにおける精密な値 これらの重みの内の1つがどのように分解されるかを示す： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7vTyA6tepWaOJ8leVIhqqO/79b7469c7ef383f3f9ad6c688d6edc0f/2.png) 符号部と仮数部は重み across で予測不可能に変動する——ランダムなデータのように見え、意味のある圧縮はできない。しかし指数部は異なる物語を語っている。 指数部の驚くべき予測可能性 先行研究により、訓練済みLLM across で、256個の可能な指数値のうち、わずか数種類が支配的であることが確立されている。最も一般的な上位16個の指数値は、典型的なレイヤー内の全重みの99％以上をカバーする。情報理論（information theory）によれば、この分布を表すために必要なビット数は約2.6ビットであり、割り当てられた8ビットよりもはるかに少ない。典型的なLLMレイヤーにおける指数値の分布を見れば、上位16個の指数値が全モデル重みの99％を占めていることがわかる。 典型的なLLMレイヤーにおける指数値の分布 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/ejPYP6ALeUkkta8hfA3fA/aab913f50afb38fdb9110b6e4daa3d25/3.png) これがUnweightが活用する冗長性です。符号部と仮数部はそのままにしておき、指数部バイト（exponent byte）のみをハフマン符号化（Huffman coding）で圧縮します。これは一般的な技術で、頻出する値には短い符号を、稀な値には長い符号を割り当てます。指数部の分布がこれほど偏っているため、指数ストリームに対して約30%の圧縮率を実現します。この手法はMLP重み行列（MLP weight matrices）（ゲート、アップ、ダウン射影（gate, up, and down projections））に選択的に適用しており、これらはモデルパラメータの約3分の2を占め、トークン生成時のメモリトラフィックを支配しています。Attention weights、embeddings、layer normsは圧縮対象外です。総合的に、これらの最適化により多層パーセプトロン（multilayer perceptron, MLP）の重みサイズ全体が約20%削減されます。詳細は技術レポートで解説しています。 稀な指数を持つ少数の重みは別途処理されます：64要素の行の中に、トップ16パレット（top-16 palette）から外れる指数を持つ重みが一つでもあれば、その行全体をそのままの形式で保存します。このアプローチによりホットパス（hot path）における要素ごとの分岐を排除しています。すべての重みを個別に境界ケースとしてチェックするのではなく、行ごとに事前に1回の判断を行うだけです。 The GPU memory bottleneck An NVIDIA H100 GPUには、関連する2種類のメモリがあります： High Bandwidth Memory (HBM)：容量は大きいものの、アクセス速度は比較的遅いです。モデルの重みがここに格納されます。 Shared memory (SMEM)：容量は非常に小さいものの、極めて高速です。GPUが計算を実行する直前にデータをステージング（準備）する場所です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2H57YtBN941gTST60fH7su/b66ed530c29a9c5ea20fae86467a7ca7/4.png) 推論（inference）中にトークンを生成するには、HBMから重み行列全体を読み取る必要があります。HBMとSMEM間のメモリバス（memory bus）がパフォーマンスのボトルネックとなります——演算そのものではありません。バスを通過するバイト数が少なければ少ないほど、トークン生成は高速になります。 推論中にトークンを生成するには、メモリバスを介してHBMから重み行列全体を読み取る必要があります——これがボトルネックです。H100のtensor coresは、HBMがデータを供給する速度よりもはるかに高速に数値演算を実行できます。圧縮は、バスを通過するバイト数を減らせるため有効です。ただし注意点があります：GPUは圧縮されたデータに対して直接演算を実行できないことです。まず重みを解凍（デコンプレス）する必要があります。 従来の多くの手法は、重み行列全体をHBMに解凍してから標準的な行列乗算を実行します。これはストレージ容量の節約には役立ちますが、bandwidthの向上にはつながりません。なぜなら、トークン生成ごとにHBMから完全な非圧縮行列を読み取る必要があるためです。 Four ways to use compressed weights 推論（inference）中に圧縮された重み（weights）を使用する最適な方法は一つではありません。適切なアプローチはワークロード、つまりバッチサイズ（batch size）、重み行列（weight matrix）の形状、および復元（decompression）に割り当てられるGPU時間の量によって異なります。Unweightは4つの圧縮実行パイプライン（execution pipelines）を提供しており、それぞれ復元処理の負荷と計算複雑さの間で異なるバランスを取っています。これらは、完全なHuffmanデコード（full Huffman decode）、指数部のみデコード（exponent-only decode）、パレットトランスコード（palette transcode）、または前処理（pre-processing）を完全にスキップするものです。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/12UwJkO7buPrdzTOQOupUA/2f0bd7b3bc97f04c8958472f904d5682/5.png) 4つの異なる実行パイプライン（execution pipelines） 4つのパイプラインはスペクトル（spectrum）を形成しています。一端では、完全デコード（full decode）が元のBF16重み（BF16 weights）を完全に再構築し、標準的な行列乗算（matrix multiplication）のためにNVIDIAのcuBLASライブラリに渡します。これは、通常のデータ上でcuBLASが全速力で動作する最もシンプルなパスですが、前処理ステップ（preprocess step）はメインメモリ（main memory）へ最も多くのバイトを書き込みます。行列乗算が微小でカスタムカーネル（custom kernel）のオーバーヘッドが支配的な小さなバッチサイズにおいて、これはよく機能します。他端では、直接パレット（direct palette）は前処理を完全にスキップします。重みはモデルロード時にコンパクトな4ビット形式（4-bit format）に事前にトランスコードされており、行列乗算カーネルはこれらのインデックスからBF16値をその場で再構築します。前処理コストはゼロですが、カーネルは要素ごとに多くの処理を行います。 その中間には2つの独立したパスがあります。1つは指数部（exponent）のバイトのみをデコードするもの（前処理トラフィックを半減）、もう1つは実行時（runtime）に4ビットのパレットインデックスへトランスコードするものです（前処理トラフィックを4分の1に）。両方とも、再構築型行列乗算（reconstructive matrix multiplication）を使用します。これは圧縮データを読み込み、高速な共有メモリ（shared memory）内でBF16を再構築し、メインメモリへの往復を経由せずに直接テンソルコア（tensor cores）に供給するカスタムカーネルです。 単一のパイプラインが勝者にならない理由 前処理（preprocessing）が少ないということは、HBM（High Bandwidth Memory）へ書き込まれるデータ量が少なくなることを意味し、メモリバス（memory bus）をより早く解放します。ただし、それは行列乗算カーネル（matmul kernel）への再構築作業の負荷を増やすことになります。このトレードオフが利益をもたらすかどうかは、状況によります。 小さなバッチサイズ（i.e. 1-64トークン）の場合、行列乗算は微小であるため、重なる計算がほとんどなく、カスタムカーネルの固定コストが支配的になります。cuBLASのオーバーヘッドが低いため、完全デコード＋cuBLASがよく勝者となります。大きなバッチサイズ（i.e. 256+トークン）の場合、行列乗算は追加の再構築作業を吸収するのに十分な長さ実行されます。軽量な前処理はより速く完了し、解放されたバス帯域幅と計算のオーバーラップが利益をもたらします。パレットまたは指数パイプラインが先頭を走ります。同じレイヤー内の異なる重み行列は、異なるパイプラインを有利に働かせます。「gate（ゲート）」および「up」射影は、「down」射影とは異なる次元を持ち、行列乗算内で実行される演算の順序を変更するため、異なるパフォーマンスのトレードオフを要求します。 スループット（throughput）とパイプライン戦略 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3jthcdROyaeOdjDxuqG3ZD/29220083376fb26580a44f8f2d8057c8/6.png) これがUnweightが単一の戦略をハードコードしない理由です。ランタイムは、ターゲットハードウェアでの実際のエンドツーエンドのスループットを測定するオートチューニング（autotuning）プロセスによって判断され、各バッチサイズ（batch size）における各ウェイト行列（weight matrix）に対して最適なパイプラインを選択します（詳細は後述）。 How the reconstructive matmul works -> 再構成型行列乗算（reconstructive matmul）の動作原理 4つのパイプラインのうち3つは、デコードと演算を融合したカスタム行列乗算カーネル（matrix multiplication kernel）を使用しています。このカーネルは、HBM（High Bandwidth Memory）から圧縮データをロードし、共有メモリ（shared memory）内で元のBF16値を再構成して、テンスコア（tensor cores）に直接供給します。これらはすべて1つの操作で完結し、再構成された重みはメインメモリに存在することはありません。 Traditional decompression vs Unweight -> 従来のデコードとUnweightの比較 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2OqxSbLVN2V90aTof0IKyb/322f45956be83ecfcbd484558a5dd7e1/7.png) Unweightを使用すると、MLP（Multi-Layer Perceptron）のウェイト行列を伝送するメモリーバス（memory bus）のデータ量が約30%削減されます このカーネル内部では、GPUのスレッドグループ（thread groups）は2つの役割に分割されます： プロデューサーグループ（producer group）は、専用のメモリコピーハードウェア（TMA：Tensor Memory Accelerator）を使用して、HBMから圧縮入力を共有メモリにロードします。符号付き仮数（sign+mantissa）バイト、指数データ（exponent data）（またはパレットインデックス（palette indices））、そして稀な指数を持つ行の場合はそのままの指数行をステージングします。コンシューマーより先に実行し、データが必要になる前に準備が完了するよう円形バッファ（circular buffer）を埋めます。 コンシューマーグループ（Consumer groups）は、指数と符号付き仮数バイトを結合してBF16値を再構成し、その結果をすぐにHopperアーキテクチャのWGMMA（Warped Group Matrix Multiply-Accumulate）テンスコア命令に供給します。再構成された重みは、共有メモリから出ることなく、アセンブリから直接演算へと渡されます。 再構成型行列乗算には複数のバリエーションがあり、各コンピュートユニット（compute unit）が処理する出力タイルの数と円形バッファの深さが異なります。広い出力タイルはバッチサイズが大きい場合のデータ再利用を向上させ、深いバッファはバッチサイズが小さい場合のメモリレイテンシを隠蔽します。オートチューナー（autotuner）が各ワークロードに対して最適なバリエーションを選択します。 Sharing the GPU between decoding and computation -> デコードと演算の間のGPU共有 2つの融合パイプラインでは、別個のプリプロセスカーネル（Huffman decoderまたはpalette transcoder）が再構成型行列乗算と並行して実行されます。しかし、これらのカーネルはGPUリソースを競合します。 Hopperアーキテクチャでは、各コンピュートユニット（SM：Streaming Multiprocessor）に228 KBの共有メモリが搭載されています。再構成型行列乗算にはパイプラインバッファとアキュムレータタイル（accumulator tiles）用に約227 KBが必要です。デコードカーネルにはハフマン探索テーブル（Huffman lookup table）用に約16 KBが必要です。227 + 16 > 228 となるため、これら2つのカーネルは同じコンピュートユニットを共有できません。デコードに割り当てられるSMが1つ増えるごとに、行列乗算で使用可能なSMは1つ減ります。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2JiEsj6QS7ntozWQJz8YH9/f207e0f863191ac245bd0f55839635c3/8.png) これはバランス調整を生み出します：デコード用のSM（ストリーミングマルチプロセッサ）を増やすと前処理は高速化しますが行列乗算（matmul）が遅くなり、その逆も同様です。最適な分割比率はもう一つの調整可能なパラメータであり、これが自動チューナー（autotuner）がヒューリスティックに頼るのではなく実際のスループットを測定する理由の1つでもあります。 Pipelining across layers SM（ストリーミングマルチプロセッサ）の分割制約があっても、UnweightはTransformerモデルの構造を活用することで、復号化コストの大部分を隠蔽しています。 実行時にすべてのレイヤーがHuffman復号化を必要とするわけではありません。Unweightはレイヤーを「ハード」（Huffman前処理が必要）と「イージー」（行列乗算（matmul）が直接消費できる事前トランスコード済みパレットデータを使用）に分類します。ランタイムはこれらを交互に実行します： ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4j8l78Iivhl6paLMudctu6/6b34b6f4726d7a00bc45acd0d206ed0f/9.png) 復号化は、ブートストラップ、アテンション（注意機構）、イージーなMLP（多層パーセプトロン）計算中に別々のCUDAストリーム上で実行されます。ハードレイヤーのMLPが実行される頃には、その前処理済み重みはすでに待機しています GPUが前処理を必要としないイージーレイヤーの計算を行っている間、別セットのCUDAストリームがバックグラウンドで次のハードレイヤーの重みを復号化しています。イージーレイヤーが完了してハードレイヤーの番が回ってくる頃には、その前処理済みデータはすでに待機しています。ダブルバッファリングされた前処理スロットにより、1つのハードレイヤーからの復号化出力がまだ消費されている間に上書きされないことが保証されます。 下向き投影（down projection）はこのオーバーラップから最大の恩恵を受けます：MLPシーケンスの最後（ゲート、活性化関数、上向き投影（up）の後）に消費されるため、復号化が完了するまでの最長のタイムロス（ランウェイ）を確保できます。 自動チューニング 4つのパイプライン、複数の行列乗算（matmul）カーネルのバリエーション、そして復号化と計算の間で調整可能なSM分割があるため、設定空間は広大です。単一の戦略をハードコードするのではなく、Unweightはターゲットハードウェアでの実際のエンドツーエンド推論スループットを測定する自動チューナー（autotuner）を使用します。ゲート投影については上向きと下向きの設定を固定したまま候補設定を探索し、次に上向き、そして下向きを探索し、これ以上改善が見られないまでこれを繰り返します。その結果、各バッチサイズにおける各投影に対して、どのパイプライン、行列乗算のバリエーション、SM割り当てを使用するかをランタイムに指示するモデルごとの設定ファイルが生成されます。これらはすべて、ヒューリスティックではなく測定されたパフォーマンスによって駆動されています。 1つの圧縮フォーマット、複数の用途 エンコーディングフォーマット、実行パイプライン、スケジューリング（スケジューラ）は独立した選択です。同じHuffman圧縮モデルバンドルが、配布と推論の両方に使用できます： 配布においては、Huffmanエンコーディングが圧縮率を最大化し（モデル全体のサイズを約22%削減）、ネットワーク全体でモデルを送信する際の転送時間を短縮します。 推論（inference）時、Huffman符号化された射影行列はモデルロード時にパレット中間形式にトランスコード可能であり、配布フォーマットを制限することなく、最も効率的なランタイム実行を実現します。 単一のモデルバンドルは、パッケージング時に一つの戦略に縛られる必要はありません。ランタイムは、射影行列ごと、バッチサイズごとに最適な実行パスをその場で選択します。 \n 結果 \n \n \n Llama 3.1 8B（主要なテストベッド）において、Unweightは以下の成果を達成します：\n 推論用バンドルではモデルフットプリントが約13%削減（ゲート/アップMLP射影のみを圧縮）、配布用バンドルでは約22%削減（ダウンを含むすべてのMLP射影を圧縮）。すべての圧縮は100%ビット完全な可逆圧縮です。Llama 70Bに外挿すると、構成によっては約18〜28 GBの節約につながります。 現在の最適化レベルにおけるスループットオーバーヘッドは30〜40%（H100 SXM5でのエンドツーエンド測定）。このオーバーヘッドはバッチサイズ1で最大（約41%）となり、バッチ1024では縮小（約30%）します。既知の3つの要因——小バッチの固定コスト、冗長なウェイトタイル再構築、除外されたダウン射影——は現在積極的に最適化中です。 これらは単一モデルにおける中間結果です。圧縮率は他のSwiGLUアーキテクチャにも一般化するはずです（指数統計はモデル規模全体で一貫しています）、ただしスループット数値は現在のカーネル実装に固有のものであり、最適化の進行とともに変化します。また、現時点ではアテンション重み（attention weights）、埋め込み表現（embeddings）、レイヤー正規化（layer norms）は圧縮対象としておらず、これらが全体の削減率を薄めています。 \n なぜこれが重要なのか \n \n \n GPUは複数の次元で高価です：カード自体のコスト、要求される高帯域幅メモリ（high-bandwidth memory）、そして大きな電力消費。\n これに対処するため、複数の研究者が完全モデルに対して約30%の圧縮率という有望な結果を示すシステムを発表していますが、これらはコンシューマー向けGPUやプロダクションスケールで動作しない研究用フレームワークを対象としています。Unweightの開発における鍵となる洞察は、マルチレイヤーパーセプトロン（MLPs）がモデル重みの大部分を占め、推論ワークロードにおける計算コストの大きな部分を構成しているという点です。UnweightはMLP重みだけを圧縮し（圧縮の恩恵が限定的なレイヤーでのオーバーヘッドを回避）、計算とメモリがきめ細かくバランスされたデータセンター向けH100 GPUのために特別に設計されており、単一のアプローチではなくバッチサイズに適応する4つの実行パイプラインを備えています。 ただし、明確にしておきたい点があります。Unweightはタダで手に入るもの（free lunch）ではありません。オンチップでの再構築は、非圧縮重みでは発生しない計算作業を追加します。Llama 3.1 8Bにおいて、推論設定は典型的なサービングバッチサイズで約30%のスループットコストを払うことで、モデルメモリ全体の約13%を節約します。このギャップはより大きなバッチ（プリプロセスのオーバーラップが改善される）で縮小し、最適化が進むにつれてさらに縮小すると予想されます——特に、

Unweight: 品質を犠牲にせずLLMを22%圧縮した方法

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト