大原雄介の半導体業界こぼれ話
IntelとAMD主導のx86向けAI拡張命令「ACE」、その詳細が判明
2026年5月18日 06:07
IntelやAMDからなるThe x86 Ecosystem Advisory Group(EAG)は4月27日(米国時間)、The AI Compute Extensions (ACE) for x86に関するホワイトペーパーをリリースしたことを発表した。
今回はあくまでホワイトペーパーであって、まだ具体的な命令の仕様が公開されたわけではない。ただInstinctの形でコード例が示されているので、概略を理解するには十分である。今月はこの話をご紹介したい。
EAG設立の経緯は2024年10月の記事でご紹介した通りなので割愛する。強いて言えばメンバー企業に、新たにAdobeおよびNutanixが加わって12社+アドバイザー2人という構成になっている程度の差である。
EAG設立後の命令をおさらい
さてこのEAG、設立後1年となる2025年の10月13日に「Standardizing x86 features」という最初の標準化案をリリースしている。ここではFREDとAVX10、ChkTag、ACE(Advanced Matrix Extensions for Matrix Multiplication)という4つを将来のx86が搭載する標準的な命令群として定めたことを発表した。
このうちFREDは2023年12月の記事で紹介している通りだ。
AVX10に関しては名前だけは過去に紹介したが、要するにAVX512はあまりに種類が多すぎて、一体どのプロセッサがどのAVX512をサポートしているのか分かりにくい(というか覚えきれない)のでまとめよう、という話である(図1)。
さらに言えば、AVX512は名前の通り512bit命令であるが、たとえばAVX512_VNNIは後で256bitにBackportされたAVX2_VNNI(AVX512_VNNIの256bit版)が存在するなど、512bitを必須にすると、そこから漏れる命令がボロボロ出てくるようになった。この辺をまとめて、改めてAVX10という形でまとめるという形になったわけだ。
ちなみにそのAVX10、現状では10.1と10.2が定義されている。10.1は要するに既存のAVX512の集大成(?)で、AVX10.2はこれに加えて
- 新データ型：E5M2/E4M3 FP8(OCPに定めるOFP8:OCP 8-bit Floating Point Specificationに準拠する)のサポート
- 新メディア命令(VMPSADBW:既存のMPSADBWを512bit拡張。また16bit VNNIはすべての符号の組み合わせをサポートするように拡張)。
- IEEE754-2019のNaN(Not a Number)の挙動をサポートするmin/max命令の導入
- 飽和変換
- ゼロ拡張ベクトルコピー：既存のMove命令と挙動を整合させる。
- 浮動小数点演算におけるスカラー比較
といった命令群が追加されることが既に公開されている。EAGが言及しているのがAVX 10.1なのか10.2なのかは不明だが、おそらくまずは10.1の実装で足並みをそろえ、次に10.2に移るものと思われる。
ChkTagはIntelが2025年10月13日に公開した仕組みである。要するにMemory Taggingで、同種のものはたとえばArmのMTE(Memory Tagging Extension)などでも見ることができる。こちら、詳細な仕様は2025年後半に公開予定とあるのだが、現時点ではまだ仕様が公開されていないようだ。
今回新たに説明されたACE
さて、FRED/AVX10/ChkTagはそれなりに細かい説明が2025年10月時点で明かされていたのだが、唯一詳細が明らかではなかったのがACEである。
実際リリースでは「Accepted and implemented across the stack, ACE standardizes matrix multiplication capabilities, enabling seamless developer experiences across devices ranging from laptops to data center servers.」(ACEは行列演算を標準化し、ノートPCからデータセンターサーバーまで、あらゆるデバイスにおいてシームレスな開発環境を実現する)とだけあって、詳細は不明なままだったからだ。
ということで、いよいよ本題のホワイトペーパーの内容について紹介しよう。
ACEは基本的にZMMレジスタ(AVX512用に拡張された512bitレジスタ)を利用して行列演算、もっと正確に言えば外積(Outer Product)を計算する仕組みを提供する。
一般に行列演算ユニットの場合、積和演算をサポートするものが大多数である。これはGEMM(General Matrix Multiply)が積和演算をベースにしているので、GEMMの高速化には積和演算だけにしておくのが一番穏当だからだ。回路的にもコンパクトに済むし、またCNNで利用される畳み込み演算にもそのまま使える。少なくとも1次元のSIMD演算を繰り返すよりは圧倒的に高速である。NVIDIAのGPUに搭載されているTensor CoreやIntelのAMX、ArmのSME/SME2などもみな積和演算である。
ただ、外積のアクセラレータの例がないわけではなく、具体的にはIBMのPOWER10に搭載されたMMA(Matrix Math Assist)は、規模こそ小さいが外積の計算を行なう仕組みであった。積和演算ユニットを使って外積なり畳み込みを行なうよりも、高速にこれらの処理を行なうことが可能である(積和演算ユニットを利用する場合、まずは積和演算を行なった後に、その結果を使って畳み込みなり外積なりを求めることになるから、余分に処理が入る)。通常の積和演算ユニットを搭載するよりももう一歩、ACEは演算の高速化に踏み込んだと言えるだろう。
逆に言うと、ただの積和演算だけが欲しい場合には、現行のACEが使えないことになるが、現時点ではACEに積和演算を無効化するオプションがあるかどうか、仕様が公開されていないので判断ができない。多分何かあるんじゃないかという気はするが。
ACEの話を戻すと、ACEではZMMレジスタに16×4という形で64個の8bit、ないし8×4で32個の16bitの入力値を保持する。これを利用して、2つの入力値の外積を計算し(ここは内部的には32bitで行なう)、その結果をおそらく16bitで保持する形になる(図4)。
たとえば、8bitであればZMMレジスタはそれぞれ16組ずつの値を保持できるから、合計256個の外積演算が発生する。1回の外積には、4つの乗算と全体の加算が入るので、厳密に言えば演算回数は256×(4+1)=1,280回になるわけだが、加算は計算に入れていないようで、1,024回とされる(図5)。
ところで図4で緑の部分、つまり外積の結果を保持するサブタイルレジスタ(Sub Tile Register)だが、これはACEで新たに追加される形になる(図6)。1回の演算で64個×16bit=1,024bit分の結果が出てくるわけだが、これを格納するために512bit×16行のタイルレジスタが新たに追加されている。正確に言えば512bitレジスタ2つで1回分の結果の格納を行なう形であり、このセットが8組用意されるのでトータル16個というわけだ。
サンプルコードとして、たとえばAVX10のVNNIとACEの外積をそれぞれ実行する場合の記述は図7のように示されている。ここで外積の側の書き込み先(出力先)、つまりタイルレジスタの宣言は「__tile1024i」なる型である。普通に考えるとこれはInt型の1,024bit幅の意味であり、つまり実態は512bitレジスタ×2だが、プログラムからは1,024bitレジスタと見える格好になっている(つまり2つの512bitレジスタとしては扱えない、ということだ)。
タイルレジスタが8組用意されている理由として、ホワイトペーパーでは「仮想的にもっと大きな行列を一気に処理できる」と説明している。1つのタイルレジスタで16×16の計算結果を格納できるわけだが、8つのタイルレジスタを全部使えば、64×32のような計算が行なえる(もちろんこの場合演算は8サイクル必要になる)。ところがデータロードを煩雑に行なう必要がないから、その分実効性能を引き上げられる。たとえば16×16のケースでは演算あたりのロードが2回必要なのに対し、64×32のケースでは0.75回に減らせるとしており、よりピークに近い性能を引き出せる、というわけだ。
ACEのユニットをどうやって実装するのか
次の話は、この行列計算ユニットがどういう形で実装されているか？である。現実問題として実装は2種類あり、
(1) CPUコアと完全に分離した形でレジスタおよび行列計算ユニットを設け、アクセラレータとして呼び出す
IntelのAMXがこの実装である(図8)。CPUコア(IA Host)とは物理的に離れた場所に、レジスタ(TILECFG)とTMULユニットが配されており、CPUコアとレジスタの間のデータ交換はTiles and Accelerator Commandsブロックが担当する。実際サンプルコードは、
となっているが、ここでTILELOADDはタイルレジスタに値を詰める作業だし、逆にTILESTOREDはタイルレジスタから値を取り出す作業になる。演算そのものはTDPBUSD命令で行なうが、これは当然ながらCPU内部の命令パイプラインを通るわけではなく、HostからTiles and Accelerator Commandsブロックに渡され、ここが実際にTMULユニットを動かして積和演算を行なう形になる。
一応、ここで言うTILELOADD/TILESTORED/TDPBUSDという命令はIntel AMX Instruction Setとして定義されており、AMXをサポートしたプロセッサで解釈できる(つまりCPUパイプラインのデコーダで認識される)が、処理そのものはCPUパイプラインからオフロードされる形で処理されるわけだ。
このサンプルコードを見る限り、TDPBUSD命令は発行するとそのまま待機状態となり、TMULユニットが処理を終わらせて、Tiles and Accelerator Commandsブロックから完了(or異常終了)が届くまで待機状態が続く実装になっているようだ。Intelの場合、AMXはPコアのみのサポートとなっており、現時点ではPコア1個についてAMXユニットが1個配される形になる。
この実装の変型版がArmのSME2である。こちらは複数個のC1コアとSME2ユニットで、1つのDynamIQクラスタを構成するという実装である。すべてのC1コアはSME2用の命令をデコードできるが、実際の処理はSME2ユニットが行なって結果をそれぞれのC1コアに返す。問題はコアの数とSME2ユニットの数が1:1になっていない(図9)ことで、実際昨年(2025年)9月に発表された第1世代のLumex CSSはDynamIQクラスタあたり1つのSME2ユニットとなっているが、次世代のLumex CSSはSME2ユニットを2つに増やすとされている。
(2)CPUコアの中に行列演算ユニットを統合する
現在のAVX512とかと同じ方式だ。これを実装しているのがIBMのPOWER10以降で、Photo10のMatrix SIMDというのが行列演算ユニットであるが、CPUコアに統合される形で配されているのが分かる。
実のところ、あれこれコアの外とのデータの移動とかを考える必要がないこの方式が、プログラミングは一番楽である。ちなみにこのMatrix SIMD(というかMMA)は図3にもあったように、1サイクルあたり4×4の行列の外積を4つ行なえるので、演算能力としては256Ops/サイクル。これが4つ搭載されるのでトータル1,024Ops/サイクルとなり、一応ACEとピーク性能的には同じ(4つに分散したのは、POWERが4wayないし8wayのSMT動作なので、1ないし2スレッドで1つのMMAを利用するといった使い方を考慮しているかと思われる)だが、こんな力業が許されるのはサーバー向けだから、という話でもある。
という感じである。ではACEはどちらの方法で実装されるだろうか？これに関しては、ホワイトペーパーにSimple LPGEMM Kernelというサンプルコードが示されているのだが、それはこんな感じである。
「_mm512_load_si512」はZMMレジスタへのデータの格納、「_mm512_store_si512」はZMMレジスタからのデータの取り出し、そして「__tile_moverow」はタイルレジスタの内容の一部をZMMレジスタにコピーする命令、「__tile_top4bssd」が実際の外積の計算と思われる。
どうもこのタイルレジスタをプログラムから直接扱う方法は提供されておらず、なのでタイルレジスタを初期化する「__tile_zero」なんて命令まで追加されていたりする。つまりプログラミングとしては限りなく(1)の構成を前提にしているように考えられる。
実際のところ、すべてのコアにACEを実装するという(2)の方式では、コアのエリアサイズが巨大になりすぎる。データセンター向けのサーバーCPUはともかく、デスクトップ/モバイル向けの省サイズ/省電力のCPUにはこの方式は適さない。
よって、現状見る限り、(1)の方法が一番可能性が高そうだ。IntelならPコアクラスタごとに1つとかEコアクラスタ(4コア)毎に1つとかという感じになりそうだし、AMDならCCXごとに1つとか2つとか、そんな感じではないだろうか？
そうなると、「んじゃACEとAMXと何が違うんだ？」という話になるわけだが、1つ目はZMMレジスタを入力にそのまま利用できる(AMXはタイルレジスタにコピーして渡す必要があった)、2つ目は必ずしもコアの数とACEの数が一致しない(AMXはPコアあたり一つ搭載されていた)可能性が高い、3つ目がOCPのMXフォーマットをサポートすることだ。
浮動小数点の場合、仮数部と指数部に分けて値が保持される(符号は仮数部に含まれる)。ただ16bitとかならまだしも、8bitとか6/4bitとかデータサイズが小さくなると、十分な仮数部と指数部のサイズを確保できない。
そこでOCPが標準化したのがMX(Microscaling)というフォーマット(図11)である。
要するに、指数部と仮数部を分離し、別々に保持する仕組みだ。これは値が1個だけだとむしろ効率が悪いのだが、複数の値を全部分離し、各々は仮数部だけを保持。指数部はまとめて1つで表現する、というやり方だ。たとえば
A: 123.4
B: 154.3
C: 90.7
という3つの値があったとして、これをMXフォーマットで扱うと
A: 1.234
B: 1.543
C: 0.97
共通の指数: 2(10E2)
という形になる。これにより、データサイズが小さくなってもそれなりに精度を確保できる仕組みだ。ちなみに仕様ではこんな感じになっている。ACEは基本BF16とINT8のサポートというか、8bitならINT8を利用しての演算になるのだが、MXFP8/MXFP6/MXFP4を利用しての演算も可能である。
このMXフォーマットを使う際に利用されるのが、先ほど図6のところで出てきた「Block Scale Register」である(図13)。今回演算ユニットを4bit精度に落とす(=その分1cycleに処理できる演算数が増える)ことは見送られたが、演算性能はINT8の場合と同じながらMXFP4をそのまま扱えるようになったのは大きなポイントだろう。
気になる性能であるが、ホワイトペーパーでは図5に示すように、1サイクルあたりの演算性能は16倍になるとしている。ただ問題はこのACEがどれだけ搭載されるか？である。
AMX、あるいはIBMのMMAのように、1コアあたり1つのACEが搭載されているケースでは、ピーク性能は単純に16倍になる(Xeon Scalableとかは2つのAVX512ユニットを搭載しているので、これと比較する場合は8倍だ)。ただ、上で書いたように実際そこまでの数のACEが搭載されるか？というと甚だ疑問であり、たとえばAMDの例で言えば、8コアのCCXに1つAMXが搭載される、というケースを考えると、AVX512比で2倍にしかならない計算だ。
このあたりは、製品SKUによって差が出ると思うのだが、少なくともGPUあるいはNPUに伍するほどの性能が確保できるか？と言えばそこまでの性能は出ないだろう。それでも、従来に比べると大分高速になるのは事実だが、従来が遅すぎるという話でもあるわけで、あまり過度の期待をしない方が良いとは思う。
ところで冒頭で、元々ACEはAdvanced Matrix Extensions for Matrix Multiplicationとされていたのが、最終的にAI Compute Extensionsに名前が変わったとちょっと触れた。なんとなくこれ、理由が分かる。おそらく当初はもう少し汎用的に使えることを考慮していたのだろう。ただ実装に必要な要件と想定される回路規模などを詰めていく中で、汎用にするには厳しいと判断されたのだろう。
INT8とBF16のみのサポートというのは、科学技術計算などにはかなり厳しい。外積の計算は本来FFTなどにも応用できるのだが、このデータ型だと音声処理のデジタルフィルタなどに使うのはかなりしんどい(不可能ではないとは思うが、音質が大分劣化しそうだ)。それもあって、明確にAI向けと示したのではないか、と筆者は邪推する。
最後に余談を1つ。このホワイトペーパー、AMDから8人、Intelから3人が筆者として加わったと記されているが、その中にMichael Clark氏(Zenシリーズのアーキテクト)とPradeep Dubey氏(PowerPCのAltiVecとか386/486/Pentium/Xeonの設計に携わったアーキテクト)の二人の名前が並んでいるのは非常に感慨深いものがある。いやほかの面々もなかなか錚々たるもので、Brian Thompto氏(ARM9E-Sのリードアーキテクト)やThomas Fox氏(POWERやBlue Gene/Qの設計)など、相当なメンバーが集まっているという意味でも、非常に印象的な文書である。こんなことも起き得るんだな、という深い感慨を受けたホワイトペーパーであった。