このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
世界のインターネット人口の95%から50ミリ秒以内で推論を実行できるということは、GPUメモリでとてつもなく効率的であることを意味します。昨年、弊社はRustベースの推論エンジンであるInfireを使用してメモリ使用率を改善し、モデルスケジューリングプラットフォームであるOmniを使用してコールドスタートを排除しました。そして今、推論プラットフォームの次の大きなボトルネックである「モデルの重み」に取り組んでいます。
LLMから単一のトークンを生成するには、GPUメモリからすべてのモデルの重みを読み取る必要があります。当社の多くのデータセンターで使用しているNVIDIA H100 GPUでは、テンソルコアは、メモリが配信できる速度よりも600倍近く速くデータを処理できるため、計算能力ではなく、メモリ帯域幅のボトルネックになります。メモリバスをまたぐバイトはすべて、重みが小さいなら回避できたバイトです。
この問題を解決するために、私たちはUnweightを構築しました。これは、特別なハードウェアに依存することなく、ビット単位で正確な出力を維持しながら、モデルの重みを最大15～22%削減できる可逆圧縮システムです。ここでのコアブレークスルーは、高速なオンチップメモリで重みを解凍し、それを直接テンソルコアに送り込むことで、遅いメインメモリを介した余分なラウンドトリップを回避できることです。ワークロードに応じて、Unweightのランタイムは複数の実行戦略（単純化を優先するもの、メモリトラフィックを最小化するもの）から選択し、オートチューニングは重みマトリックスとバッチサイズごとに最適なものを選びます。
この記事では、Unweightの仕組みについて掘り下げていきますが、透明性を高め、急速に発展するこの分野におけるイノベーションを促進するという精神で、当社は技術文書を発行し、GPUカーネルをオープンソース化することもしています。
Llama-3.1-8Bに関する初期結果多層パーセプトロン（MLP）の重みだけで約30％圧縮していることを示しています。Un weight、デコーディングのパラメーターに選択的に動作するため、モデルのサイズが15～22%縮小し、最大3GBのVRAMを節約することができます。下の図に示すように、これにより、GPUをより多く活用できるため、より多くの場所でより多くのモデルを実行でき、Cloudflareのネットワーク上でより安価で高速な推論が可能になります。
Unもし、より多くのモデルを単一のGPUに適合させることができるのです。
推論を高速化したり、より小さなGPUで実行したりするために、創造的な方法でモデルの重みを圧縮する方法を探る研究は増加しています。最も一般的なのは量子化で、これは32ビットまたは16ビットの大きな浮動小数点を8または4ビットの整数に変換することによって、モデルの重みとアクティブ化のサイズを縮小する技術です。これは非可逆圧縮の形態です。異なる16ビットの浮動小数点の値は、同じ4ビットの整数に変換できます。この精度の低下は、予測不可能な形で応答の質に影響を与えます。多様なユースケースに対応する本番推論には、正確なモデルの動作を維持するロスレスなものが必要であると考えました。
最近のいくつかのシステム（Huff-LLM、ZipNN、およびZipServ）は、LLMの重みを大幅に圧縮できることを示していますが、これらのアプローチは私たちのものとは異なる問題を対象としています。ZipNNは、配信と格納のために重みを圧縮し、CPU上で解凍を行います。HUff-LLMは、デコーディング用のカスタムFGPAハードウェアを提案しています。また、ZipServerはGPU推論と一体化していますが、コンシューマーグレードのGPUを対象としているため、H100 GPUでは動作しません。これらはいずれも、私たちが求めていたものではありませんでした。Rustベースの推論エンジンと統合できる、Hopper GPU上でのロスレスな推論時デコンプレッションです。
中核となる課題は、普通の圧縮ではありません。BF16の重みの指数関数バイトは高度に冗長化されているため、エントロピーコーディングがうまく機能します。課題は、推論を遅くしない程度の速さで解凍することです。H100では、テンソルコアはほとんどの場合、メモリをアイドル状態にしています。しかし、そのアイドル状態の容量を解凍するために再利用することはできません。各GPUコンピューティングユニットは、減圧縮カーネルまたは行列乗算カーネルのいずれかを同時に実行できますが、両方を同時に実行することはできません。これは、共有メモリの制約のためです。行列の乗算と完全に重複しないデコードの遅延は、トークンの遅延に直接追加されます。Un weightの答えは、高速なオンチップ共有メモリで重みを解凍し、結果を直接テンソルコアにフィードすることですが、それをさまざまなバッチサイズやウェイト形で効率的に機能させることが、真のエンジニアリングの得意分野です。
AIモデルのすべての数値は、16ビットの「身代金フロート」（BF16）として保存されます。各BF16の値は3つの部分があります：
これらの重みについて、詳しくは次のように示します：
署名とマン不正は、重みによって予測不可能な変化を示します。ランダムデータのように見え、意味を持って圧縮することはできません。しかし、指数関数は異なる状況を伝えています。
これまでの研究では、訓練済みLLM全体では、256の指数値のうち、わずかな数が支配的であることが確認されています。最も一般的な上位16の指数関数は、通常のレイヤーの全ウェイトの99%以上をカバーしています。情報理論では、この分布を表現するのに必要なビット数は最高2.6ビットだとされていますが、割り当てられた8ビットよりもはるかに少ないものです。典型的なLLMレイヤーの指数関数値の分布を見ると、上位16の指数関数がモデル全体の重みの99%を占めていることがわかります。
典型的なLLMレイヤーにおける指数関数的な値の分布
これがUn weightが利用する冗長性を悪用するものです。記号と仮数部はそのままにして、指数バイトのみをハフマン符号化を使用して圧縮します。これは、共通の値には短いコードを、まれな値には長いコードを割り当てる古典的な手法です。指数関数的な分布は非常に偏っているため、これにより指数関数的なストリームで約30％の圧縮が実現されます。これは、モデルのパラメータの約3分の2を占め、トークン生成中のメモリトラフィックを支配するMLPの重み行列（ゲート、アップ、ダウン予測）に選択的に適用されます。注意の重み、埋め込み、レイヤー規範は圧縮されていません。当社の技術レポートで詳しく説明しているように、最適化によって多層パーセプトロン（MLP）全体のウェイトサイズが約20%削減されます。
稀な指数を持つ少数の重みは、別々に処理されます。64行の重みが上位16のパレットの外に指数関数を持つ場合、行全体が逐語的に保存されます。このアプローチにより、ホットパスにおける要素ごとの分岐が排除されます。エッジケースのすべての重みをチェックするのではなく、行ごとに1つの決定を前もって行います。
NVIDIA H100 GPUには、次の2つの関連する種類のメモリがあります：
推論時に、各トークンを生成するには、HBMからすべての重み行列を読み取る必要があります。HBMとSMEM間のメモリバスは、数学自体ではなく、パフォーマンスのボトルネックです。バス全体のバイト数が少ない = トークン生成が速い
推論時、各トークンを生成するには、HBMからメモリバスを介してすべての重み行列を読み取る必要があり、これがボトルネックとなります。H100のテンソルコアは、HBMがデータをフィードするよりもはるかに速く数値を高速化することができます。圧縮は、バスを通過する必要があるバイト数が少ないため、役に立ちます。しかし、落とし穴があります。GPUは圧縮されたデータでは数学ができないのです。まず、重みを解凍する必要があります。
これまでのほとんどの作業では、重み行列全体をHBMに解凍し、標準的な行列乗算を実行しました。これはストレージ容量には役立ちますが、すべてのトークンについてHBMから完全な非圧縮マトリックスを読み込む必要があるため、帯域幅には役立ちません。
推論の際に圧縮された重みを使う最適な方法はひとつだけではありません。適切な方法は、ワークロード（バッチサイズ、重み行列の形状、解凍にどれだけのGPU時間が使えるか）によって異なります。Unweightコンテンツを使用して、4つの圧縮された実行パイプラインを提供しますが、それぞれ、解凍作業と計算の複雑さのバランスが異なります。完全なハフマンデコード、指数関数のみのデコード、パレットトランスコード、または前処理の完全なスキップです。
4つの異なる実行パイプライン
4つのパイプラインでSpectrumを形成しています。最後に、完全なデコードはオリジナルのBF16の重みを完全に再構築し、NVIDIAのcuBLASライブラリに渡して、標準的な行列乗算を行います。これは、通常のデータ上でcuBLASがフルスピードで実行されている最も単純な経路ですが、前処理のステップがメインメモリに最も多くのバイトを書き返します。これは、行列の乗算が小さく、カスタムカーネルオーバーヘッドが大半を占めるような、小さなバッチサイズでうまく機能します。反対側では、ダイレクトパレットは前処理を完全にスキップします。重みはモデルの読み込み時にコンパクトな4ビット形式に事前トランスコードされ、行列乗算カーネルはこれらのインデックスからBF16値をオンザフライで再構築します。前処理コストはゼロだが、カーネルは要素ごとにより多くの作業を行う。
その間に、2つの独立したパスが位置します。1つは、指数関数バイトだけをデコードするもの（前処理のトラフィックを半減）、もう1つは実行時に4ビットのパレットインデックスにトランスコードする（4分の1）ことです。どちらも、再構築行列の乗算を使用しています。これは、圧縮されたデータを読み込み、高速共有メモリ内でBF16を再構築し、メインメモリを経由することなく、テンソルコアに直接フィードするカスタムカーネルです。
前処理が少ないとHBMに書き込まれるデータが少なくなり、メモリバスをより早く解放することができます。しかし、それはより多くの再構築作業をMattulカーネルに移行することになります。トレードオフが成功するかどうかは、状況によります。
バッチサイズが小さい（つまり、1-64トークンなど）、Mamatulは小さいため、オーバーラップする計算はあまりなく、カスタムカーネルの固定コストが大半を占めています。フルデコード＋cuBLASが勝る場合が多いのは、単にcuBLASのオーバーヘッドが低いからです。バッチサイズが大きい（つまり、256以上のトークンなど）でも、Matmulは余分な再構築作業を吸収するのに十分な長さを持つ必要があります。軽量な前処理はより速く終了し、解放されたバス帯域幅とコンピューティングのオーバーラップが効果を発揮します。パレットや指数関数的なパイプラインが先行しています。同じレイヤー内にある異なる重み行列は、異なるパイプラインを優先することができます。「ゲート」と「アップ」プロジェクションは、「ダウン」プロジェクションとは異なる次元を持ち、mamul内で実行される操作の順序を変えるもので、異なるパフォーマンスのトレードオフが必要になります。
スループットとパイプラインの戦略
これが、Unweightが単一の戦略をハードコードしない理由なのです。ランタイムは、ターゲットハードウェアの実際のエンドツーエンドのスループットを測定する自動調整プロセスによって情報に基づいて、各バッチサイズで各重み行列に最適なパイプラインを選びます（詳細は後述）。
4つのパイプラインのうち3つは、解凍と計算を融合したカスタム行列乗算カーネルを使用しています。このカーネルは、HBMから圧縮されたデータを読み込み、共有メモリ上のオリジナルのBF16値を再構築し、テンソルコアに直接フィードします。これはすべて一度の操作で実現します。再構築された重みは、メインメモリには存在しません。
従来の解凍と軽量化の比較
Unもし、MLPの重み行列のメモリバスを通過するバイト数が最大30%減少します
このカーネル内部では、GPUのスレッドグループは次の2つの役割に分かれています。
生産者グループは、専用のメモリコピーハードウェア（TMA）を使って、HBMから圧縮されたインプットを共有メモリにロードします。署名+mantissaバイト、指数関数データ（またはパレット記号）、および、稀な指数を持つ行では、逐語の指数関数行をステージングします。コンシューマーよりも先に実行され、循環バッファを満たします。データが必要になる前に準備できるようにします。
コンシューマーグループは、指数関数とsign+mantissaバイトを組み合わせることでBF16値を再構築し、その結果をHopperのWGMMAテンソルコア命令にすぐにフィードします。再構築された重みは、共有メモリを離れることなく、アセンブリから計算まで直接進みます。
再構築行列には複数のバリアントがあり、各コンピューティングユニットが扱う出力タイルの数と、循環バッファが実行される深さが異なります。幅広い出力タイルにより、大きなバッチサイズでデータの再利用が向上します。より深いバッファは、小さなバッチサイズでメモリ遅延を隠します。オートチューニングは、ワークロードごとに最適なバリアントを選択します。
2つの融合したパイプラインでは、別の前処理カーネル（ハフマンデコーダーまたはパレットトランスコーダー）が再構築Mathulと同時に実行されます。しかし、これらのカーネルはGPUリソースを取り合います。
Hopperでは、各コンピューティングユニット（SM）が228KBの共有メモリがあります。再構築行列は、パイプラインバッファとアキュムレータタイルのために最大227KBを必要とします。デコードカーネルは、ハフマンルックアップテーブルのために最大16KBを必要とします。227 + 16 > 228なので、これら2つのカーネルは同じ計算単位を共有できません。デコーディングに割り当てられたSMごとに、Mattulに使えるSMが1つ減ります。
これにより、バランスを取ることができます。デコードSMが多いと、前処理は速くなりますが、行列の乗算は遅くなり、その逆も同様です。最適なスプリットは、もう1つの調整可能なパラメーターであり、オートチュナーがヒューリスティックに依存するのではなく、実際のスループットを測定するもう一つの理由でもあります。
SM分割の制約があっても、Unweightはトランスフォーマーモデルの構造を悪用することで、解凍コストの多くを隠します。
すべてのレイヤーが実行時にハフマンデコーディングを必要とするわけではありません。Unweight、Webレイヤーを「ハード」（ハフマンの前処理が必要）または「簡単」（mamulが直接利用できる事前トランスコードされたパレットデータを使用）に分類します。ランタイムは、それらの間で交互に発生します。
デコードは、ブートストラップ、Attention、および簡単なMLPコンピューティング中に別々のCUDAストリーム上で実行されます。ハードレイヤーのMLPが実行される時点で、事前処理された重みはすでに待機しており、
GPUは前処理を必要としない簡単なレイヤーを計算しますが、別のCUDAストリームのセットがバックグラウンドで次のハードレイヤーの重みをデコードします。簡単な層が終了し、難しい層の順番が到着するまでに、その前処理済みのデータはすでに待機しています。ダブルバッファリングされた前処理スロットは、1つのハードレイヤーからのデコード出力が消費されている間に上書きされないようにします。
下図は、このオーバーラップから最も恩恵を受けます。MLPシーケンスの最後（Gate、アクティベーション、アップ後）で消費されるため、そのデコードが完了するまでのランウェイが最長となるのです。
4つのパイプライン、複数のMattulカーネルバリアント、デコーディングと計算間の調整可能なSM分割を持ち、設定スペースは大きなものです。Un weightは、単一の戦略をハードコーディングするのではなく、ターゲットハードウェアで実際のエンドツーエンドの推論スループットを測定するオートチューニングツールを使用します。ゲートプロジェクションの構成の候補構成を上に上げたり下げたりするのを固定し、その後、上に上げたり下げたりし、改善が見つからないまで繰り返します。その結果、各バッチサイズで各プロジェクトにどのパイプライン、Mattulバリアント、SM割り当てを使用するかを正確に伝えるモデルごとの設定ファイルができ、これらはすべてヒューリスティックではなく、測定されたパフォーマンスによって実現されます。
エンコーディング形式、実行パイプライン、スケジューリングは、独立した選択です。同じハフマン圧縮モデルバンドルは、分散と推論の両方に役立ちます。
単一のモデルバンドルは、パッケージ化時に1つの戦略にコミットする必要はありません。ランタイムは、プロジェクトごと、バッチサイズごとに最適な実行パスをその場で選択します。
Llama 3.1 8B（プライマリテスト環境）上で、Unweightは以下を実現します：
推論バンドルではモデルフットプリントが最大13%削減（ゲート/アップMLP予測のみを圧縮）、分散バンドルでは最大22%（ダウンを含むすべてのMLP予測を圧縮）。すべての圧縮は100%ビット正確なロスレスです。Llama 70Bに換算すると、設定にもよりますが約18～28GBの節約が可能です。
現在の最適化レベルで30～40%のスループットオーバーヘッド（H100 SXM5でエンドツーエンドを測定）。オーバーヘッドはバッチサイズ1で最大（～41%）、バッチ1024で減少（～30%）します。既知の3つのソース（小規模バッチ固定費、冗長ウェイトタイル再構築、除外ダウン予測）が積極的に最適化されています。
これらは、単一のモデルの中間結果です。圧縮比は他のSwiGLUアーキテクチャで一般化される必要があります（指数関数的な統計はモデルスケール全体で一貫しています）が、スループットの数値は現在のカーネル実装に固有のものであり、最適化が続くにつれて変化します。注意の重み、埋め込み、レイヤー規範をまだ圧縮しておらず、全体的な削減率に影響します。
GPUは、カード自体のコスト、必要な高帯域幅メモリ、膨大な電力消費量など、複数の側面で高価です。
これに対抗するため、複数の研究者はフルモデルで圧縮率30%という有望な結果を示していますが、これらは生産規模では機能しない消費者向けGPUや研究フレームワークを対象としています。Un weightの開発に関する重要なインサイトは、多層パーセプトロン（MLP）がモデルの重みの大半を占め、推論ワークロード時の計算コストのかなりの部分を占めているということです。MLPの重みだけを圧縮し（圧縮の効果がわずかなレイヤーでのオーバーヘッドを回避）、緊密にバランスの取れたコンピューティングとメモリを備えたデータセンターH100 GPU向けに特別に設計されており、単一のアプローチではなくバッチサイズに適応する4つの実行パイプラインが実現しています.
ただし、明確にしておきたいのは、「アンウェイト」は無料の昼食ではありません。オンチップ再構築は、圧縮されていない重みでは存在しない計算作業を追加します。Llama 3.1 8Bでは、推論構成は、一般的なバッチサイズで、スループットコスト約30%でモデルメモリ全体の約13%を節約します。このギャップは、（前処理のオーバーラップが改善される）バッチでより狭くなると予想されます。特に、各MLPレイヤーで下図をまだ圧縮していません（圧縮可能な重みの約3分の1）。いくつかのカーネル改善がアクティブ開発中です。
Cloudflareのネットワークにとって、Unweightはより優れた容量をもたらします。インスタンスあたりのGPUメモリが少ない最先端のモデルに対応できるため、コスト削減につながり、より多くの場所により多くのモデルをデプロイできるようになります。モデルの配布では、大幅な削減が見られます。ハフマン圧縮されたバンドルは約22%小さく、モデルを世界中のエッジロケーションに送信する際の転送時間が短縮されます。
今後、当社の効率向上に役立つと考えられる具体的な研究の方向性は3つあります。
ダウンロード圧縮。現在、MLP予測はゲートとアップのGatewayを圧縮していますが、ダウンプロジェクションは圧縮可能な重みの約3分の1を占めています。これには、その次元が移動するため、異なるカーネルバリアントが必要ですが、これにより、モデルの合計サイズは22％以上縮小することが期待されます。
カーネルの最適化現在、30～40%のスループットオーバーヘッドには、大規模なバッチサイズでの冗長なウェイト再構築、そして見落とされたダウン予測の3つの原因があります。それぞれに既知の軽減経路があり、弊社の技術文書で概説しています。
さらに多くのモデル。私たちの結果はLlama 3.1 8Bですが、根本的な指数統計はSwiGLUアーキテクチャであらゆる規模で一貫しています。弊社は、Workers AIを通じて提供する大規模なモデルにUnweightを導入することに取り組んでいます。
長期的には、UnweightクラウドのアーキテクチャがMixture-of-Expertsモデルにとって何を意味するかについて調査中です。コールドエキスパートがオンデマンドで取得されなければならず、ストレージを減らしればさらにコストを削減できるでしょう。
これは動きの速い分野なので、私たちの仕事をここでオープンソース化し、圧縮とGPU効率に関する研究の成長に貢献できることを嬉しく思います。無重みはパズルのひとつですが、他の研究者がこれを基盤とする有用なパラダイムと判断してくれることを願っています。