大原雄介の半導体業界こぼれ話

クロック3.3GHzなのに爆速?NVIDIA自社製CPU「Vera」の謎と実力を読み解く

 NVIDIAが7月21日(米国時間)、Technical BlogでVera CPUの概略を公開した。

 もっともこの際、いろいろ意味不明な説明もあるので、8月23日(ちなみに初日は日曜日だが、チュートリアルセッションが行なわれている)からスタートしたHot Chipsの発表で詳しい説明があるだろう……と思ったら資料がほぼ同じでちょっと頭を抱えたのは事実。とはいえ、きちんと説明が行なわれたことなどもあるので、Veraの詳細を読み解いていきたいと思う。

独自アーキテクチャでは2世代目となるVera

 Veraは、NVIDIAのサーバー向けCPUとしては第2世代のカスタムCPUとなる。初代のGraceはNeoverse V2ベースであったが、今回は独自開発のOlympusコアを利用した構成である。ちなみに実は独自CPUアーキテクチャとしても2世代目にあたる。

 というのも、2011年にProject Denverという独自アーキテクチャCPUを開発するプロジェクトがあり、これに基づき「Tegra K1」のT132とか「Tegra X2」のT186といったプロセッサが実際に出荷されたからだ。この最後のシリーズが2018年にリリースされたCarmelで、これを搭載した「Tegra Xavier」(T194)がある。そういう意味で、NVIDIAにとってカスタムCPU開発の経験がなかったわけではない。

 そんなOlympusコアのターゲットが図1。高スループットと高シングルスレッド性能の両立である。コアの詳細は後で見るとして、Veraの2ソケットカードの仕様がこちら(図2)。まぁこのスペックはそれほど新しいものではない。

【図1】AMDならZen 4/5/6ベースのEPYCだし、IntelならP-CoreベースのXeonのシリーズに該当する
【図2】SCF(Scalable Coherency Fabric)はチップ内のコアと周辺回路の接続用のもの。Grace世代は確かArmのCMN-700を採用していた

 チップの構造はコンピュートダイ+メモリコントローラダイ×4+システムI/Oダイの合計6ダイ構成である。ここでコンピュートダイをモノリシックにしているあたりが、強いていえば昨今のトレンドからちょっと外れている部分だが、あるいはSCFの制約とかがあるのかもしれない。

【図3】LPDDR5Xのコントローラを外に出したのはまぁ分からなくもない。ほとんどがPHYで示されるからだろう。これはI/Oダイも同じだ

謎が残る内部構造

 ちょっと良く分からないのが内部構造(図4)。4つのCSN(Cache Switch Nodes)が相互接続され、ここにコアとSLC(System Level Cache)、それとMSN(Memory Switch Nodes)/Bridge(NVLink Bridge)が接続される形で、これだけみると4つのノードがあるように見えなくもない。

【図4】図の下に「Fabric mesh simplified for illustrative purposes」とあるように、あくまでも簡単化した構図と思われる

 問題はコアとSLCのサイズである。コア数は88、SLCは164MBと発表されているわけだが、Veraの画像(図5)の中央部を拡大したのがこちら(図6)。これをみるとコアの数もSLCのブロックも13×7列で91個ずつに見える。コアの方は91コアのうち3つが代替用で88コアというのは良くある話だが、SLCの数が辻褄が合わない。

【図5】これはNVIDIAのサイトから
【図6】あくまでもレイアウトを判断するためのもので、縦横比は正確かどうか不明である

 あと図6をよく見ると、SLCの間にちょっと幅の広い領域があるのが分かる。ちょっと先の図4に話を戻すと、そもそもCSNが4つしかないとすると、1つのCSNに22個のCPUコアと41MBのSLCがぶら下がる計算になるのだが、その場合CSNの大型化は免れないように思われる。

 これは筆者の推定だが、この太い部分がCSNであり、1つのCSNには基本2つのコアと2つのSLCブロックが接続される。で、CSNは全部で7×7の49個あり、最下段のCSNのみコア×1つとSLCブロック×1の接続になっている、という構造だと思われる。要するに下のような構図だ。

 この図で正しいとしても、SLCの164MBはやはりちょっと謎である。おそらくはSLCブロックは1個2MBで、これを82個で164MBという容量になっているものと思われるのだが、残りは冗長ブロック扱いにするにしても、ちょっと冗長ブロックが多すぎる気がしなくもない。あるいは、余ったSLCはNVLinkでの接続時のディレクトリキャッシュに使う、という可能性もゼロではないが、確率的にはかなり低そうだ。

256bitのSVE2移行は見送り

 さて次がコアの内部構造である(図7)。フェッチが最大16命令/サイクル、デコードが最大10命令/サイクル、イシューからの命令発行ポートが合計18というのは、それなりに重厚な構成ではあるものの、一番大きいというほどでもない。昨今のArmコアとしては常識的な範疇に入る。

【図7】ただSVE2が6つ同時に稼働するとすると、Storeユニットが3つあっても不思議ではない(というか、3つないのはなぜ?)という話で、あるいはSVE2は6ユニットあっても何かしら制限があって、同時に稼働できるのは4つまでなのかもしれない(か、実はロード/ストアユニットの幅が256bitではなく384bit以上なのか、どちらだろう?)

 たとえばQualcommのOryonコアは第1世代(2023年に発表されたSnapdragon X Elite向け)のものでもフェッチが最大16命令/サイクル、デコードが8命令/サイクル、発行ポートが合計14だったし、ArmのNeoverse V2(AGI CPUに搭載されるNeoverse V3の前世代)でもデコードが6命令/サイクル(Micro-Op換算では8命令/サイクル)、発行ポートは15あった。x86でいえばZen 5が8命令/サイクル(4命令/サイクル×2)、発行ポートが16といったところである。

 ただALUでいえばどれも×8構成であり、Olympusが妙に発行ポートが多いのは、SVE2の発行ポートが6つもある(2×3構成)ことと、ロード/ストアユニットが合計4つあることに起因している

 ちなみにSVE2は128bit幅の構成である。質疑応答の中でSVE2が6ポートである理由について「256bit SVE2への移行を見送ったのは、現在存在するソフトウェアエコシステムの大部分がNEONベースであるため、エコシステムを引き継ぐという多大な労力を要することになるからだ」とした。

 「その代わり、スカラー・ベクトル処理をより効率的に行なうことでパフォーマンスを向上させると同時に、マシンの総FLOPSを増加させるため、ベクターユニットの増設を選択した」という返答もあった。

 一方、ロード/ストアが4つもあるのは、SVE2がフルに動くと当然それだけ大量のメモリのロード/ストアが発生するから当然であり、逆に言えばSVE2を抜くとそれほど大きくは既存のコアと変わらないように思える。

 ただこれだけの規模のイシューなので、同時にインフライトに持ち込める命令数はかなりのものに達すると想像される。今回直接インフライトできる命令数を確認したものの、返答はなかった。

 その代わりといっては何だが、リオーダーバッファのエントリ数は「1,000以上」とのことで、これは相当の量である。少なく見積もっても500以上、実際には600位の命令をインフライト状態で保持できることになる。

 ただしそのためには相当な数のレジスタファイルを保持する必要があるはずで、そうしたことまで考えると相当に重厚なコアと言える。確かにシングルコアスレッドを追求した構成「っぽく見える」ことは事実だ。

 なんで「っぽく見える」かというと、重厚なコアを構成した結果としてIPCは上がっても動作周波数が下がってしまったら結局性能は出ないわけで、通常このあたりのPPA(Power, Performance and Area)のバランスをどのあたりに見出すかが腕の見せ所なわけだ。

空間的マルチスレッディング

 これに絡んでもう1つ面白いのがSpatial Multi-Threading(空間的マルチスレッディング、図8)である。要するにNVIDIAは、インオーダーで動くフロント部に関しては、2つのスレッドをそれぞれ別々に扱えるようにすることで、フロントエンドにおけるほかのスレッドの影響を排除し、スレッドの性能を高めるという仕組みを主張しているわけだ。

【図8】根本的な話として、だったらSMTを辞めたらいいのでは?と思わなくもないのだが、コア数の不足を補うためにはSMTを無効化できないのかもしれない

 16命令/サイクルのフェッチとか10命令/サイクルのデコードを、実際には8命令/サイクルのフェッチと5命令/サイクルのデコード×2に分解し、それぞれ独立に動作するようにすることで、片方のスレッドの影響(たとえば一時的にデコーダを占有してしまうとか)を受けないようにする、という仕組みである。

 つまり、フロントエンドがスレッドごとに分離しているという話だが、図8を見ると分岐予測まで分離しているように見える。これはもう分岐予測が2スレッドの分岐予測をそれぞれ独立に保持可能な構造になっていると思うしかない。

 図8の中央の図が、SPECint 2K17を片方のスレッドで実行しながら、もう片方のスレッドで別の処理を行なった場合の影響を示したもの。たとえば従来のCPUは1スレッドで10くらいの性能が出るが、もう片方でNOPを実行すると性能が8.0に、GB_SRなどを動かすと6.5位、Streamを動かすと5.0を切るが、Veraではこうした影響を受けにくい、というわけだ。

 言いたいことは分かるし、スレッドが全く異なるメモリ空間で異なる処理をしてるのならこれはその通りである。ただ、そもそもSMTは、同じメモリ空間のプログラムを並行動作させるような場合に性能が出やすい仕組み(逆に全く異なるメモリ空間のプログラムを同時に走らせると性能が落ちやすい)だから、SMTを使うことそのものの是非をちょっと問いたくなる前提ではある。

 あと、フロントエンドが2組でバックエンドが共通、という特徴は何というかAMDのBulldozerそのものでは?という気もしなくはない。まぁ実装はだいぶ違うが。「コアは単一スレッドで駆動できますか?リソースは均等に分割されますか、それとも分割を変更できますか?」という質問に対し「はい、コアはシングルスレッドで稼働できます。その場合、スレッドはコアのすべてのリソースを占有します」との答えがあった。つまり、SMTを無効にした場合はコアのすべてのリソースを1スレッドで利用できるわけだ。

(当たり前だが)既存プロセッサを上回る性能。ただ、実際の競争相手ではない

 ちなみに上述の発表ページにはこんな図(図9)が示されている(Hot Chipsでの発表では省かれている)。正直言って何を言いたいのかよく分からない。NVIDIA的には、従来のx86プロセッサは2ソケット構成で最大32NUMAドメインになるが、Veraは2ソケットで2NUMAドメインのみである。なので、多分x86ではNUMA同士のアクセスのレイテンシが大きくなると言いたいのだろう。

【図9】思うにこの図、講演で示したら質疑応答で突っ込まれるのが明白だからHot Chipsでは省いたのではなかろうか?

 たとえば初代のEPYCなんかは確かにそうだった。各ダイにメモリコントローラが搭載されていたから、全体で1つのNUMAを構成するとしても異なるダイの先のメモリのアクセスには相応の遅延が掛かった。

 ところが今のEPYCも、今回Hot Chipsで発表されたDiamond Rapidsもそうだが、もうメモリコントローラはコンピュートダイには搭載されていない。AMDならIOD、IntelならFabric Hubにメモリコントローラが搭載されており、ソケット間のインターコネクトもこのIODなりFabric Hubに搭載されているから、NVIDIAの言うようなNUMAドメイン間のレイテンシが大きくなるような状況には陥らない。まぁこういう不思議な主張が時々混じるのがVeraの紹介の特徴である。

 話を戻すが、ベンチマークについて。紹介ページではSPEC CPU 2026の4つほどのテスト結果が示されていたが、Hot Chipsではもうすこしちゃんと示された(図10)。比較対象はVera 88C vs EPYC 9755で、Veraの方が1.2~1.8倍高速という結果が示されているが、EPYC 9755がDDR5-6400×12チャネルでメモリ帯域は614.4GB/s。一方VeraはSOCAMM2×16チャネルでメモリ帯域は1.2TB/s。

【図10】ちなみにNVIDIAの紹介ページには、「細かい結果はVera CPU whitepaperに掲載」とあるが、そのリンク先が原稿執筆時点では404エラーになっている

 実はこのメモリ帯域そのものが性能にかなり影響を及ぼしていると考えられる(逆にそこまで含めてCPU性能だと言い張れば、それはまぁその通りなのだが)。

 ほかに、Headless Browserでの処理性能比較(図11)とかコンパイル時間の比較(図12)、それとDeepinfraが実施したエージェンティックAIのベンチマーク結果(図13)なども示された。

【図11】こちらの比較対象はEPYC 9655Pだそうだ
【図12】上がx86_64バイナリ、下がAArch64バイナリのコンパイル時間から導出したスコア。言うほど変わらないというべきか
【図13】こちらはVeraとZen 5、Granite Rapids、Sapphire Rapidsの4つを使ってOrchestration work-step latencyを測定して、その結果を示している。詳細は当該ページにある

 当たり前といえば当たり前なのだが、後から出てきた製品が前世代製品に負けてたら話にならないわけで、それもあって優秀な結果だが、たとえばSPECintに関していえば、AMDは先日開催されたAI Advancingにおいてこんなスライドを示している(図14)わけで、単純にVeraが市場で最速の座を勝ち取れるかどうかはまだ何とも言い難い(とりあえずZen 5世代よりはやや上っぽい気はするが)。

【図14】全部推定値な事に注意。といってもEstimateというのはSPECに公式に登録されている数字ではないというだけで、実機を使った結果ではあると思う

 最後に消費電力について。図2にあるように個々のVeraの消費電力は250W~450W(可変)とされるが、利用できるコアの数でどう変わるのか、が示されている(図15)。ちなみに質疑応答の中で動作周波数を問われ、3.3GHzでの動作は確認できたとしている。実際図15でも3.3GHzあたりが上限になっているのが見て取れる。

【図15】このグラフを見ると、8/16/32/48/64/80/88coreのSKUがあるように見えるが、単に有効コア数を制限しただけの可能性もある

 全体として、Intel/AMDなどのx86系サーバーCPUを見慣れた目からするとバランスがちょっと変、という感じは否めない。IPC向上にリソースを振りすぎて(=構造が複雑になりすぎて)、動作周波数を低めに抑えているというよりも上げられない感がある。TSMCのN3を使っていれば、4GHzぐらいは無理なく出せそうだからだ(特にコア数を減らした場合)。それでも3.3GHzに抑えているというのは、そのあたりが動作できる最大限の可能性はある。

 それでもSOCAMM2×16チャネルの威力は凄まじく、Turinを上回る性能を発揮しているのは間違いなさそうだが、Veraが本当に競争する相手であるVeniceやDiamond Rapidsはこの辺のアドバンテージがなくなる訳で、そこでもまだ性能的に優位か、というのは怪しいところだ。この辺、早く実機でのベンチ結果が見たいものである。