AIアクセラレーター「Gaudi 3」の性能は前世代の2～4倍　インテル CPUロードマップ

ASCII.jp / 2024年4月22日 12時0分

　前回に引き続きIntel Vision 2024の話題であるが、今回のお題はGaudi 3である。Gaudi 3は昨年12月のAI Everywhereイベントにおける基調講演の最後にGelsinger CEOによるチラ見せこそあったものの、詳細は不明なままだった。

Gaudi 3はGaudi 2比で2～4倍の性能だがダイあたりの性能はそれほど伸びていない

　今回Gaudi 3に関してホワイトペーパーまで含めて広範な情報が公開されたので、これをまとめて説明しよう。

Gaudi 3のOAM(OCP Accelerator Module)。2つのダイにそれぞれ4つのHBMが接続され、ダイ同士も接続されている構図がわかる。電源レギュレーターとパスコンの数がエグい

　まず基本的な情報から。Gaudi 3には64個のTensor Coreと8つのMME(Matrix Math Engine)、96MBの2次キャッシュと128GBのHBM、24×200GbEとPCIe Gen5 x16が搭載される。

ダイの内訳。これだと2種類のダイがあるように見えるが、実際には下の画像のように、両方のダイの端に12×200GbEとMedia Engine、PCIe I/Fが搭載されている。気になるのは2つのダイ同士を接続するPHYがないことで、実は2つのダイはPCIe経由で接続されているのか？　と思ったのだが、下の画像を見る限りにそれも違うようで、どこかに隠れている模様

てっきり両方のダイから出たPCIe Gen 5 x16を、カードに載ったPCIeスイッチ経由で接続してホストにもPCIe Gen5 x16で接続しているのかと思った(記事冒頭の画像左上のチップがいかにもそれっぽい)のだが、違うようだ。SRAM同士を相互接続しているのだろうか？

　Gaudi 2の概略は連載686回で説明したが、そのGaudi 2とGaudi 3の比較をホワイトペーパーから抜き出したのが下表である。

　ここでGaudi 3(1 Die)は筆者が作成したものだ。Gaudi 3はGaudi 2比で2～4倍の性能としているわけだが、ダイあたりで言うと実はそれほど性能は伸びていない。まずMMEの性能で言えば、MMEの数そのものは倍増しており、BF16では性能も倍増しているのだが、FP8で言えば微増(6%程度の向上)に留まっている。

　Gaudi 2ではFP8の性能がBF16の倍になっているのに、Gaudi 3ではFP8とBF16の性能が同じ、というのは要するに16bit幅のエンジンを8bit×2に分割する機能をGaudi 3では省き、この結果FP8であってもBF16をそのまま使う形になってのことと思われる。

　TPCの数は33%増えているのに、性能で言えば6%しか上がっていないというのは、性能消費電力比を改善するために、動作周波数を引き下げたのではないかと考えられる。動作周波数そのものは示されていないが、Gaudi 2のOAMのTDPが600Wに対し、Gaudi 3では900W。つまりダイ1つあたり450Wになっている。

　もちろんプロセスも微細化しているし、HBMもダイあたり6スタック→4スタックに減少しているとはいえ、これだけで150Wも減ったりはしない。おそらくは相当動作周波数を引き下げたものと考えられる。

　もう1つのポイントはHBMである。Gaudi 2では1.6GHz駆動のHBM2×6なのに対し、Gaudi 3では1.8GHz駆動のHBM2e×8という構成になっている。AMDはInstinct MI300でHBM3を、NVIDIAはB100/B200でHBM3eを利用していることを考えると、なぜHBM3を選ばなかったのか？　という疑問が当然湧く。

　これに関して、The RegisterのシステムエディターであるTobias Mann氏のポストによれば、「Gaudi 3の設計に当たっては、実際に動作するシリコンが存在するIPのみを使うというポリシーを貫いており、この結果設計段階で利用可能なHBM3のIPが存在しなかった」のが理由だとしている。

Official comment from Habana: "Our methodology was to use only IPs that were already proven in silicon before we tape out. At the time we taped out Gaudi3 there was simply no available physical layers that were validated to meet our standards," COO Eitan Medina told The Register
— Tobias Mann (@Tobias_Writes) April 9, 2024

　記事にはしていないが、2023年のDCAI Investor Webinarの際にGaudi 3がテープアウトしていることはすでにアナウンスされており、もうこの時点ではSilicon Proven(実際に製造して動作を確認した)なHBM3のI/F IPは存在しているが、ただこの決断はもっと前の話である。

　タイムラインで言えば2021年10月にSynopsysはHBM 3のI/F IPと検証用IPの提供を開始しており、Rambusはこれに先立ち2021年8月に8.4Gbpsまで利用可能なHBM3/HBM3EのI/F IPの提供を開始している。

　Silicon Provenか？　というと、これが実現したのは2021年末～2022年にかけて(TSMCでの5nmのサンプルが実際に出てきたのがこのあたり)で、使う/使わないの判断が行なわれたのはこれよりもっと前だったと考えられる。

　Habana Labsがインテルに買収されたのは2019年12月で、もうこの時点でGaudi 2の開発は始まっていた。Mann氏は「おそらくGaudi 3の開発もインテルの買収前に始まっていただろう」と推察しているが、昨今の5nmプロセスの製造には巨大な初期投資が必要で、買収前のHabana Labsでこれをまかなえたかはやや疑問である。

　筆者は企画そのものは買収前にスタートしており、実際に開発が始まったのはインテルの買収後ではないかと考える。ただそれはインテルの買収により、5nmプロセスを利用するのに必要な初期投資がまかなえる目途が立ったので"Go"を出した、という感じでそれほど買収から間がない時期だったであろう。

　であえば、HBM3のIPがないからHBM2で、という選択は理解できるが、結果としてこれはGaudi 3のスペックをやや見劣りするものにしてしまったことは否めない。実のところ、FP8とBF16の性能が同じ(FP8が倍増しない)理由は、このメモリー帯域がボトルネックになることが見えていたためではないか？　と考える。

プロセスを微細化してもSRAM容量が増えない

　Gaudi 3がインテルによる買収直後くらいに開発をスタートしたと考えるもう1つの理由は、オンダイSRAM容量が変わらないことである。これまで連載で何度か説明したが、7nmあたりを境にプロセスを微細化してもSRAM容量が増えなくなりつつある。

　理由はSRAM密度はトランジスタの寸法よりも配線の寸法に依存しつつある(以前はトランジスタの寸法が支配的だったが、トランジスタが小型化したことで今は配線寸法が支配的になっている)ことで、5nmだろうが7nmだろうが同一容量のSRAMのエリアサイズはほとんど変わらず、一方5nmにすることでエリアサイズあたりのコストは1.5倍くらいになっている。要するに、大容量のSRAMを搭載するのはコスト的に割に合わなくなっているということだ。

　回避策はあって、SRAMは7～6nmあたりで製造し、これを2Dあるいは3D的にチップレットで接続するというものだ。インテルで言えばPonte Vecchioがこれに相当する。Ponte Vecchioは、コンピュートタイルはTSMC N5で製造されるが、Rambo CacheはIntel 7での製造で、大容量キャッシュを相対的に低価格で利用可能にしている。

　Raja Koduri氏が2017年11月にインテルに入社、そこからPonte Vecchioの開発をスタートしたことを考えると、Gaudi 3がもしインテルによる買収後に企画がスタートしたとすれば、当然2次キャッシュはチップレットの形を想定すると思われる。それをしていないあたり、企画そのものはやはりインテルの買収前だったのだろう。

Gaudi 3は3種類の構成で提供

　性能の話をする前に、システム構成について補足する。Gaudi 3はOAMモジュールとそれを8枚まとめたシステム、それとPCIeのアドオンカードの3種類の構成で提供される。

PCIeカードが提供されるのがInstinct MI300XやB100/B200との違い。もっともNVIDIAはB40というPCIeカードの提供を予定しているようだ

HLB-325の横でOAMを持って踊る(本当に踊っていた)Gelsinger CEO(Youtube動画の1時間24分11秒あたりから)

　このHLB-325の内部結線がその下の画像だ。まずイーサネットであるが、各OAMから24本の200GbEが出てくる。これを3本づつ束ね、7対はHLB-325上でのOAM同士の相互接続に利用、残り1対を外部の相互接続に使う形になっている。

HLB-325。PCIeのReTimerがけっこうエグいほど並んでいる。ベースボードへは54V供給となっている

内部結線図だが、図が少し間違っている。下半分のOAMに関しては中央の相互接続につながるのが21×200G RoCE、OSFPコネクターにつながるのが3×200G RoCEとなる(上半分は正しい)

　ちなみにPCIeカードタイプのHL-338に関しては、21本の200G PHYを搭載しており、うち18本を6本づつ束ねてHL-338同士の相互接続に利用。残りの6本を外部接続に回すという形になる。

HLB-325ではOAMを600Gbpsで相互接続しているが、HL-338では1.2Gbpsで相互接続する形となる

　このイーサネットであるが、今回インテルはUEC(Ultra Ethernet Consortium)への対応を改めて表明した。UECは昨年7月に設立された業界団体で、そもそも創設メンバーにインテルも入っているから対応しない策はないのだが、UECは既存のイーサネットの物理層の上に独自プロトコルを実装し、クラスター・インターコネクトを構築することを目的としている。

　ほかにもいろいろあるが、当初から目的の1つにAI/ML optimized APIを提供することが掲げられているので、とりあえずイーサネットベースのAI/MLアクセラレーター用の相互接続に使えることは間違いない。

　ただもちろんまだ団体ができただけでスペックも出ていないわけだが、インテルは「将来のAI Networking」でUECを利用することを表明した。ただ、少なくともGelsinger CEOの説明からすると、UECが実装されるのはGaudi 3の次以降ということになりそうで、Gaudi 3は独自プロトコルのまま終わりそうである。

今年3月には新たに45ものメンバー企業を迎え、かなり大規模な団体になっている。現在少なくとも８つ(Physical Layer/Link Layer/Transport Layer/Software Stack/Storage/Mamagement/Compliance/Performance Debug)のワークグループが標準化作業を行なっている

4096 OAMがGaudi 3の最大構成に近い

　話を戻すと、イーサネットを利用して大規模システムを構築する場合の構成例も示された。

HLB-325を16枚(Gaudi 3 OAMを128枚)が1つのサブクラスターという扱いになる。リーフスイッチはToR(Top of Rack)に収めるのは収容量的に難しいかもしれない

4枚のHLB-325で1ラックが構成される。ということは、HLB-325を格納するシャーシは6Uでも足りず、8Uかそのくらいの高さになるのかもしれない。7200Wを空冷でなんとかするつもりなら、そのくらいの高さのシャーシが必要になるだろう

サブクラスター同士をスパインスイッチで接続することで、最大32クラスターを構成したケース。ただここまでくると、800GbE×2でも帯域が足りるのか疑問だ

　おそらくはこの直上の画像にある512ノードが現実的には上限に近く、これ以上になるとスパインの上にもう1つコアスイッチを入れないと収まらないようにも思える。さすがにそうなるとレイテンシーが無視できないところであって、4096 OAMがGaudi 3の最大構成に近いと考えて良さそうだ。

メモリー容量が最大のネック

　さて、ここからは性能の話。Gaudi 3はNVIDIAのH100/H200をターゲットとしており、性能もH100/H200との比較という格好になる。まずH100とのトレーニングの性能比較では、1.4～1.7倍高速となっている。平均1.5倍といったところか。

こちらがもう少し詳細な数字。LLAMA2では8や16個のOAMで済むが、さすがにGPT-3のトレーニングでは最大8192になる。あとH100は実測値だが、Gaudi 3は推定値なことにも注意

　これが推論におけるH200との比較になると、だいぶ旗色が悪くなる。H100はHBMが80GBだったので、トータルで128GBを実装するGaudi 3にアドバンテージがあるが、141GBを搭載するH200には、メモリー量で押し負けるといったあたりだろうか？

LLAMAだと良くてタイ、70Bだと明らかにメモリー不足である。Falcon 180BだともうH200でもメモリー不足になるので、そうなると地力の性能がでるということだろう。しかしこの結果で平均1.3倍高速というのは無理がある

見ると全般的にGaudi 3の方がバッチサイズを大きめに取っており、あるいはFalcon-180Bで性能が良いのもこれが理由かもしれない

　実際H100との推論での比較では、だいぶいい勝負になっているあたりは、やはりメモリー容量が最大のネックということだろう。

それでもLLAMA-70Bでだいぶ性能が改善しているから、1.2倍くらいとしてもいいようには思うが、1.5倍はないだろう(Falcon-180Bの数字は入れない方が妥当な気がする)

ちなみにFalcon-180Bの数字を入れない場合のAverage Speed upは14%ほど。これが実情に近い気がする

　もう1つGaudi 3の特徴としては電力効率の良さをアピールしたいようだが、結果を見ると「確かに高効率なものもあるが、そうでないケースも多い」という感じで、もうなにをどう実行するかで変わってくる感じで、そのあたりの見極めが大変そうである。

アウトプットサイズが大きい場合には効率が良いのだが、小さいとむしろH100の方が効率が良い結果になっている

消費電力の絶対値そのものはGaudi 3の方が大きいので、効率はともかく絶対的な消費電力(電力コスト)を抑えるという観点からするとやや使いにくい感じもある

Gaudi 3の後継はFalcon Shores

　最後に今後のロードマップについて。Gaudi 3の後継としてGaudi 4的なものは特に考慮されていないようで、次はFalcon Shoresになることが改めて明らかにされた。

時期的に言えば、B100対抗という形の実装になるのだろうが、その頃にはNVIDIAはX100を、AMDはInstinct MI350あるいはMI400をリリースする頃であり、これらと戦えるのか少し疑問である。そろそろAMD/NVIDIAの最新製品をキャッチアップできないとまずいだろう

　Falcon Shoresは連載710回で説明したが、Ponte Vecchioの後継となるAPUである。要するにx86コアとXeベースのGPUから構成され、しかもユニファイド・メモリーが実装される構成である。

　X^eコアベースのGPUと発表されていることから、GaudiのTPCやMMEが実装されるかどうかはかなり怪しい(普通に考えると実装されない)ことになる。もともとHabana Labsの製品はインテルのoneAPIとソフトウェアの互換性がなく、独自のSynapseAI SDKを利用してアプリケーションを構築することになっており、これはGaudi 3でも同じである。

　インテルとしてはGaudiをoneAPIに統合するより、Gaudiのアーキテクチャーを廃してX^eベースでAIを処理する方向に舵を切った、と考えるのだが妥当だろう。要するにGaudiは、あくまでX^eベースのAIトレーニング向け製品が出るまでのピンチヒッターという役割だったことが、今回の発表で図らずしも明らかになった格好である。