x86はACEで対応できるか？

x86はACEで対応できるか？ Chester LamとAurora Nockert 2026年7月14日 CPU設計は変化するワークロードに対応するために進化する必要があります。時には、特定の種類の作業を効率的に表現するために命令セットを拡張することが進化に含まれます。IntelのAMX拡張機能はその一例です。AMXは、2次元タイルレジスタと設定レジスタを提供することで、機械学習ワークロードのための行列乗算を高速化します。プログラマーは、それらのタイルレジスタ内の行列データをターゲットとするために、特殊化された実行ユニット（「アクセラレータ」）を構成できます。AMXは最初にIntelのSapphire RapidsサーバーCPUにタイル行列乗算ユニット（TMUL）アクセラレータとして実装されました。現在、x86 Ecosystem Advisory GroupはACEのホワイトペーパーと仕様を作成しており、これは第2のアクセラレータタイプを導入するものです。ACEはTMULと並ぶAMXアクセラレータですが、TMULはAMXのローンチ時に存在した唯一のアクセラレータ実装であり、現在もハードウェアで利用可能な唯一のAMXアクセラレータであるため、私はそれらを「AMX」と「ACE」と呼びます。ドキュメントもそれらを「AMX」と「ACE」と呼ぶ傾向があります。 IntelのArchitecture Instruction Set Extensions Programming Referenceより、初期のアクセラレータタイプ（TMUL）と他のアクセラレータを追加するための規定を示しています。ACEは上記の「Accelerator 2」になります。 AMX TMULは、コードが各タイルレジスタの行列タイルパラメータを指定する、高度に設定可能なセットアップを提供しました。例えば、タイルレジスタtmm0は、16行と1行あたり64バイト（「colsb」）を指定することで、INT8値の16x64行列として設定できます。TDPBSSDのようなTMUL行列乗算命令は、タイル構成を考慮に入れ、指定されたタイル間の完全な行列乗算操作を実行しました。データ型としては、AMX TMULはINT8、FP16、BF16値で動作できました。Granite Rapids-D CPUに実装されたTMULの最新版は、FP16の実数部とFP16の虚数部を持つ複素数もサポートしています。 ACEはタイルレジスタの設定オプションを廃止し、常に64バイトx 16行として扱います。複素数はなくなりましたが、FP8が導入されました。計算側では、ACEはAMXが提供する内積命令ではなく、外積命令を提供します。 ArmのScalable Matrix Extension（SME）とそのSME2拡張機能は、比較対象として明白です。両方のISA拡張機能は、CPU ISAのフレームワーク内で行列乗算を高速化し、GPUのような統合度の低いアクセラレータに対する低レイテンシの代替手段を提供することを目指しています。しかし、2つのISA拡張機能はいくつかの点で異なります。ACEはAMX上に構築されており、行列値を保持するためにAMXの8KBタイルレジスタを引き続き使用します。 ArmのSMEは、SVEのベクトル長（VL）と同様に、可変の「ストリーミング」ベクトル長（SVL）を備えています。SVEとSMEのベクトル長は同じである必要はなく、しばしばそうではありません。SVEと同様に、SMEはベクトル長を128ビットから2048ビットまで、2のべき乗で増加させることができます。 ストリーミングベクトル長は、「ZA」ストレージ配列のサイズを定義します。これはSMEのAMXタイルレジスタに相当します。ZAストレージは2次元配列であり、各辺はSMEストリーミングベクトル長に一致します。したがって、ZAストレージ容量は、128ビットのストリーミングベクトル長を持つ256バイトから、最大2048ビットのベクトル長を持つ64KBまで変化します。 外積 AVX512-VNNIとAMXが内積を高速化するのに対し、ACEとSMEは外積を高速化します。 2つのベクトルaとbの内積（この特別なケースではドット積）は、 \(\mathbf a \cdot \mathbf b = \mathbf a^\mathsf{T} \mathbf b = \sum_{i=1}^n a_i b_i\) または、物理学者であれば、幾何学的な解釈を通じて学んだかもしれません。 \(\mathbf a \cdot \mathbf b = |\mathbf a| \,|\mathbf b| \cos \theta\) ここでθはベクトル間の角度です。一方、ベクトルaとbの外積（一般的にはテンソル積）は、次のようなランク1の行列Cを生成します。 \(\mathbf{a} \otimes \mathbf{b} = \mathbf a \mathbf b^\mathsf{T} = \mathbf C = \begin{bmatrix} a_1b_1 & a_1b_2 & \dots & a_1b_n \ a_2b_1 & a_2b_2 & \dots & a_2b_n \ \vdots & \vdots & \ddots & \vdots \ a_mb_1 & a_mb_2 & \dots & a_mb_n \end{bmatrix}\) Cの列はすべてaに比例しており、これがランク1行列である理由ですが、行列乗算が外積の合計にすぎないことも示しています。 \(\mathbf C = \mathbf AB = \sum_{i=1}^n \mathbf a_i^{\text{row}} \mathbf b_i^{\text{col}}\) 実際、線形代数の多くの操作は外積の線形結合として見ることができ、外積はプロセッサに実装する自然なプリミティブとなります。最も明白な例は行列の特異値分解です。 \(\mathbf M = \mathbf{U \Sigma V}^\mathsf{T}\) 内積として書くと理解するのは簡単ではありませんが、それはUとVの列の外積にそれぞれの特異値を掛けたものの合計にすぎません。 \(\text{sum}_{i=1}^{\text{rank}(A)} (\mathbf u_i \otimes \mathbf v_i) \sigma_i\) FFTのように明らかに外積の形式に変換できないアルゴリズムでさえ、SMEをアクセラレータとして利用するために外積の形で再定式化されています。Armは、それを実行する方法について以下の例を挙げましたが、論文を検索すれば、より効果的な方法がいくつか見つかります。 レジスタに保持する必要のある状態の量を減らすため、歴史的に内積を主に利用してきました。レジスタは貴重なリソースであり、最適化のために重要でした。 しかし、前述のように、ほぼすべての線形代数は両方のレンズを通して見ることができ、コードは内積と外積の間で簡単に変換できます。SMEはこれを利用して外積による行列乗算を行い、ACEも同様の目的を目指しています。 データ型変換/デ量子化 モデルの重みは、メモリ帯域幅と容量の圧力を軽減するために、非常に小さいビット幅に量子化されることがよくあります。ACEとSMEは、例えばNVIDIAのTensorCoreとは異なり、入力ベクトルをソフトウェアで事前に処理するため、限られた数の「ネイティブ」な形式だけでなく、事実上どのような形式でもサポートできます。 量子化された重みは、アクセラレータを利用するためにネイティブにサポートされているデータ型に変換されます。ACEは、AVX-512/AVX10の固定512ビットベクトル幅を利用して、この変換プロセスを高速化します。512ビットベクトルは、VPERMBを使用して最大6ビットのデータ型を8ビット出力にマッピングするルックアップテーブルを保持するのに十分な大きさであり、7ビット入力の場合、VPERMI2Bは2つの512ビットベクトルレジスタをルックアップテーブルとして一緒に使用できます。 ACE/AVX10.3で追加された新しいVUNPACKB命令は、2〜7ビットの要素をバイトアラインされた位置に抽出でき、その後、前述のベクトル置換命令がデータ型変換を実行できます。ACEは、これらの3つの命令だけで2〜7ビットの任意のデータ型を処理できるため、将来性のある機能を提供し、ソフトウェアで選択したほぼ任意のメソッドを実装できます。 x86-64 EAGは、この柔軟性により、ACEハードウェアがモデル重みのデ量子化以外のアプリケーション、例えばデータ圧縮用のコードブックにも適用されることを期待しています。 VUNPACKBとVPERM(2I)Bを使用したデータ変換は2段階のプロセスですが、柔軟性があり、2〜7ビットの任意の入力データ型を処理できます。 Armは、SVEが実装で128〜2048ビットのストリーミングベクトル長を定義できるため、データ変換用のルックアップテーブルとして機能するのに十分な幅のベクトルレジスタに依存できません。そのため、SME2は16x4Bルックアップテーブルとして機能するように特別に設計された512ビットZT0レジスタを追加します。LUTI2およびLUTI4命令は、ベクトルレジスタから2ビットまたは4ビットのインデックス値を解凍し、ZT0でそれらの値をルックアップし、宛先ベクトルレジスタに出力値を配置することによってデータ変換を実行します。 固定幅のZT0レジスタを追加することで、Armは可変ベクトル長SVE/SMEフレームワーク内でデータ変換を高速化できますが、ACEのVUNPACKB + 置換の組み合わせほど柔軟ではありません。2または4ビット以外の値に量子化されたモデルの重みは、SME2のルックアップテーブル高速化の恩恵を受けず、複数の異なるビット幅を扱うにはより複雑なコードブックアプローチが必要になります。