ハクソク

世界を動かす技術を、日本語で。

インテルの運命を左右する18Aプロセスノードがデータセンター向けに288コアのXeonと共に登場

45日前原文(www.tomshardware.com)

概要

  • **Intel Xeon 6+ 'Clearwater Forest'**は最大288コア搭載の新型データセンター向けCPU
  • **18Aプロセス（1.8nm級）**で製造、従来比で大幅な効率向上
  • 通信・クラウド・エッジAI向けに最適化された機能搭載
  • 大容量キャッシュと幅広いI/Oサポートによる高性能・省電力設計
  • 2024年後半よりシステム提供開始予定

Intel Xeon 6+ 'Clearwater Forest'の特徴

  • 最大288個のDarkmontコア搭載、単一サーバーで数百の仮想マシン運用可能
  • **18Aプロセス（1.8nm級）**を採用した初のデータセンター向けCPU
  • Advanced Matrix Extensions（AMX）、QuickAssist Technology（QAT）、Intel vRAN BoostといったAI・通信向け機能の搭載
  • 4コア単位のブロック構成、各ブロックで約4MBのL2キャッシュを共有
  • 合計1,152MB超のラストレベルキャッシュ搭載、データをコア近くに保持し外部メモリ帯域への依存度を低減
  • スカラー・ベクトル処理性能向上のため、実行ポート数増加やパイプラインの拡張
  • 12チャネルDDR5-8000対応メモリ、**96レーンPCIe 5.0（CXL 2.0対応64レーン含む）**のI/O拡張性
  • 現行Xeonサーバーソケット互換性維持、既存システムへの導入容易化

主な用途と市場ターゲット

  • 通信事業者の5G Advanced/6Gネットワーク向け仮想化RAN（vRAN）やエッジAI推論用途
  • クラウドサービスプロバイダーでの高効率な仮想化・AIワークロード処理
  • AIアクセラレータ不要で多様な処理を一台で実現、省電力・省スペース化
  • データセンター再設計不要、既存インフラとの親和性

技術的進化ポイント

  • Darkmontコアのマイクロアーキテクチャ刷新
    • 64KB L1命令キャッシュ
    • 拡張されたフェッチ・デコードパイプライン
    • 深化したアウトオブオーダーエンジン
  • 大容量キャッシュ設計
    • コア間でのデータ共有効率向上
    • メモリ帯域依存の低減によるパフォーマンス・省電力化
  • I/O・メモリの拡張性
    • DDR5-8000による高速メモリサポート
    • PCIe 5.0とCXL 2.0による広帯域I/O

今後の展開

  • 2024年後半よりシステム提供開始予定
  • サーバーメーカーやクラウドベンダーによる導入拡大見込み
  • AI・通信・クラウド分野での新たなワークロード対応力強化

Hackerたちの意見

いつか、これみたいなCPU（それに見合ったRAMとストレージ付き）を自分のProxmoxクラスターに入れられるくらいリッチになりたいな。
└
> "それに見合ったRAMとストレージ" ここで調子に乗らないようにしようぜ。
└
eBayに出てるAMDの製品、結構手が届きそうな価格だよ！最近はRAMが高すぎるんだよね… 1TBのRAMを去年の10月に買わなかったこと、今でも後悔してる…
└
これは「これのBeowulfクラスターが必要だ」っていう2026年版だね。
└
しばらく待てば、これがeBayで安くなるよ。その頃には新しい1000コアのCPUが欲しくなってるだろうけどね。
└
7年前に何を夢見てたか覚えてる？1月にeBayでアンペアアルトラの80コアCPUが210€以下で売られてたんだよ。
└
ほんの数年待てば、今の価格のほんの一部で買えるようになるよ。その頃には「遅い」とか「電力を食う」って言われるようになるだろうし、なんで古いハードウェアを使ってるのか不思議がられるかもしれないけど、まだまだちゃんと動くからね。ここにある階段下のDL380 G7も、昔はすごく高かったけど、今は爪の先っぽで手に入れたようなもんだよ。
└
メモリのコストが高いのは置いといて、4世代目や5世代目のES CPUは、コア数に対してそんなに高くないよ。8480や8592はかなり手に入りやすいし、8480+ ESに192GBのメモリを8チャンネルで詰め込んだら、実際そんなに悪くないよ。
Intelについてはしばらく追ってなかったけど、目を引いたのはこれが全部Eコアってこと。つまり、ハイパースレッディングがないってことだよね。こういうのって、特定のアプリケーションで競争力があるの？それとも好まれるのかな？あと、AMDの192コアEpyc CPUとのベンチマークがあったか知ってる人いる？
└
トレードオフだね。ハイパースレッディングはダイ上のスペースと電力予算を取るから。Eコア自体については、ARMのやり方だね。
└
すべては正確なワークロード次第だけど、ベンチマークを見るまでは自信を持って言えないな。一般的には、Eコアで問題ない2つのスレッドがあるなら、1つのハイパースレッディングされたPコアよりも、2つのEコアに分けた方がいいよ。
└
詳しい理由はわからないけど、計算集約型のタスクの中にはハイパースレッディングの恩恵を受けないものもあるんだ。もしそのプロセッサがそういうタスク向けなら、そのシリコンを実際に役立つ何かに使った方がいいよ。 https://www.comsol.com/support/knowledgebase/1096
└
EコアとPコアは、表面的にはARMのbig.LITTLEアプローチのように見える、2つのデザインチームの内部的な権力闘争だね。
└
その理由の一部は、ダイのサイズだと思う。288のEコアに対して72のPコア。最近はハイパースレッディングの脆弱性がたくさんあって、ハイパースレッド化されたデータセンターボードでは無効にされているから、これでリスクが完全に減るんじゃないかな。
└
「こういうのは特定のアプリケーションで競争力があるのか、好まれるのか？」ってことだけど、リンクされた話の中で非常に具体的なユースケースが挙げられてるよね：仮想化されたRAN。これは、5G+セルネットワークの制御プレーンにCOTSハードウェアとソフトウェアを使っているんだ。大量の速くて低消費電力のコアは、ネットワークノードがほぼリアルタイムで調整されるようなアプリケーションには確かに合うよ。これがこのデバイスのキーとなるユースケースかもしれないね。5Gネットワークは大きな利益を生むし、インテグレーターは工場から出たばかりのこういうデバイスを大量にフルリテール価格で買うだろうし。
└
ハイパースレッディング（Eコア）がないと、タスク間のパフォーマンスが一貫して良くなるんだよね。クラウドプロバイダーはこれを好む。なぜなら、他の人が重い作業を始めても「vCPU」が変動しないから。
└
ビルドサーバーみたいなアプリケーションでは、実際に重要なのはドルとワットあたりの整数計算の合計だけ。例えばYoctoプロジェクトをコンパイルする時、1つのコアが1つのCファイルをミリ秒でコンパイルするか1分かなんて気にしない。全体のマシンが何十万ものソースファイルをどれだけ早くコンパイルできるかが大事なんだ。EコアがPコアよりもドルとワットあたりの計算能力が高いなら、Eコアが欲しい。もちろん、少ない速いコアを持つことにはRAMが少なくて済むという利点もあるけど… 以前は512GBや1TBのRAMがかなり安く手に入ったけど、最近は実際に重要になるかも？でも、もし2つのEコアが1つのハイパースレッディングPコアよりも強力なら、Eコアを使うことでRAMを節約できるかもね？ハイパースレッディングは、結局のところ、CPUスレッドごとにコンパイラプロセスを立ち上げる場合にしかメリットがないから。編集：なんでこの視点にダウンボートする人がいるんだろう？別に怒ってるわけじゃなくて、ただ混乱してる。
└
HPC、特に物理シミュレーションでは、そっちが好まれるね。ハイパースレッディングのメリットはほとんどないし、高いクロック周波数が好まれる。だけど、これらの高コア数のCPUはクロック周波数が低いんだよね。
└
これはAmpereのARMサーバーと競合するのかな？特に通信業界では、たくさんの弱いコアの使い道があると思うよ。
こういうコア密度の増加が、組織内でのクラウド議論で勝つ秘訣なんだ。* 1年間スケールしてないワークロードを特定する。ERP、HRIS、開発/ステージ/テスト環境、DB、Microsoftの環境、コアインフラなど。 （編集：zbentleyからの追記：データがクラウドからプライベート環境に戻るクロスシステム処理も特定して、エグレス料金で痛い目に遭わないように） * そのワークロードについて、AWS/Azure/GCPのリザーブドインスタンスのコスト分析を3年間分行う。 * これらの高コア「ピザボックス」についても同じことをして、7年間で償却する。 * "固定インフラ"をオンプレミスやコロケーションに戻すことで得られる節約を実感する。公的クラウドプロバイダーに留まるよりも、全く別の話だよ。10年前にフルラックや2Uデュアルソケットサーバーが必要だったものが、今では3つの2UボックスでHA/クラスタリングが可能なんだから、すごいよね。2010年代後半には、グローバルハイパーバイザーのハードウェアリフレッシュとそれに伴うVMwareライセンスが、AWSのインフラと比較してROIが2.5年になると主張したことがあるんだ（これはBroadcomの前の話；今ならNutanix、Virtuozzo、Apache Cloudstack、あるいはProxmoxも視野に入れるだろうけど、すでにMicrosoftのHyper-Vを使っている場合は別だけど） - さらに20%の余裕もあったし。今その議論で躊躇しているのは、現在のRAM/NAND不足だけど、これも（願わくば）一時的なものだし、長期的なタイムラインで構築した組織には影響しないと思う（VARを通じて利用できる3年の延長サポート契約のように）。顧客に請求できないもので、定期的にスケールしないなら、公共クラウドには置くべきじゃない。私の見解はそんな感じ。公的クラウド支出の「フリンジベネフィット」（ボックスシート、ジャンクets、カンファレンスチケットなど）に夢中な人たちには厳しいかもしれないけど、ファイナンスチームはこういう明確な数字が好きだよね。
└
確かに、場合によってはそれが正しい選択だよね。でも、クラウドにいる必要がある高いインターコネクトレートのシステムが出てくると、（クラウドの請求契約が固定されている機器とか、弾力的にスケールする必要があるコンピュート、DBのピザボックスと話すやつ、エッジ/CDN/キャッシュサービスなど、オンプレの真実のソースにたくさん落ちるもの）クラウドの帯域幅コストが痛くなってくるんだ。ビジネスプロセスマネジメントスタック（CRM、ADなど、君が挙げたような例）に限定してこのアプローチで成功したことがあるけど、データレートが「定期的な同期」や「メタデータのみ」を超えてクラウドとオンプレを橋渡しする必要が出てくると、思ったより早く痛みが出てくることが分かったよ。
└
クラウドは始めたばかりの時に正しい選択だね。インフラコストの問題じゃなくて、メンタルコストの問題。インフラを設定するのは、速度を落とすだけの余計なことなんだ。実際に負荷をかける時には、長期的な戦略について話し合う必要があるし、その点は正当なものだよ。
└
> こういうコア密度の増加が、組織内のクラウドの議論で勝つ方法なんだ。各コアが遅すぎて意味のある仕事ができないなら、コア密度なんて意味がない。現実には、Intelはパフォーマンス対消費電力比でAMD/TSMCに3倍遅れてる。人々は高周波モデル（9575Fみたいな9xx5Fモデル）を見た方がいい。これは初めて約5GHzに達して、32コア以上でそれを維持できたサーバーCPUの第一世代だった。
└
あなたの計算には、自分のインフラを維持するためのエネルギーコストや人件費も含まれてる？
└
オンプレミスの主なコストは、機材の価格じゃなくて、その機材を管理するための人材を確保するコストだよね。ほとんどの企業は、サーバーを適切に管理するためのスキルが社内にないし、面接の時に良いインフラエンジニアを雇えるかどうかも分からない。もしスキルがある企業なら、スケーリングの例は逆効果になるよ。今日、3つのサービスを1つに統合できるなら、そんな少数のサーバーを管理するためにフルタイムのインフラスタッフが必要なの？それに、24時間365日の監視や災害復旧のためのレプリケーションも必要だよね。ほとんどのビジネスはITインフラをコアスキルや差別化要因として持っていないから、外注したいと思ってるんだ。
└
ただし、これらはすべてEコアで、シングルスレッド性能が悪く、AVX512などもサポートしていないことに注意してね。これがパフォーマンステストに大きく影響すると思う。いくつかのワークロードは問題ないけど、実際にハードウェアを使っている多くのユーザーにとっては、これが問題になる可能性が高い。もしあなたがそうなら、以前に発売されたGraniteRapids APプラットフォームは、同じスレッド数（6980Pで256スレッド）を達成できるよ。ただし、いくつかの注意点があって、まず「物理コアは128個しかない」こと、VMを使っているなら物理コアをVM間で共有したくないだろうし、次に500WのTDPがあって、17000ドル以上で販売されていること。販売されているものを見つけるのも難しいかもしれない。全体的に、本当に同じ条件で比較し始めると、特に100GbE以上のネットワーキングを試みると、クラウドプロバイダーに勝つのがかなり難しくなるよ。確かにマージンは大きいけど、彼らはあなたが払うよりもずっと安くハードウェアを手に入れているからね。こういう意見を見かけると、大抵はその組織がほとんど負荷のかからないアプリケーション用に速い現代的なCPUを持っていて、マシンはほとんどアイドル状態で、ネットワークはマシンが処理できるトラフィックの1/100にも達していないことが多い。これを解決するのは、主に技術的な問題ではなく、「クラウドが悪い」という問題じゃないんだ。
└
人材がいるかどうか分からないな。うちの職場ではHyperVを使ってるけど、実際にHyperVを知ってる人を見つけるのは難しくて高いんだ。Ciscoのネットワーキングやストレージアプライアンスも加えると、99.99%の稼働率を確保するのは大変だよね。しかも、1人だけじゃなくて、スタッフのギャップを避けたいなら少なくとも2人、できれば3人は必要だし。それに、その運用にはクラウドの人たちも必要だよ。うちはこういうハイブリッドなセットアップをしていて、両方の良いところを少しずつ得ているけど、結局オンプレミスやコロケーションのインフラを管理するのは本当に面倒くさい。ビジネス環境のためにやってるだけなんだ。
└
クラウドについて驚いたのは、コアの価格がどんどん上がっていることなんだよね。でも市場の流れは逆で、昔は1/2や1/4の価格だったのが、今は1/256になってるし、しかも速くなってる。それなのにクラウドのコアの価格は上がり続けてる。彼らのビジネスプランは、オンプレミスの機械を維持していた人たちを排除して、どんどん安くなっているものに対して同じような価格を取り続けることだと思う。クラウドのハードディスクやSSDの価格には本当に驚かされるよ。サーバーのCPUの価格が小さいシステムでCPUを買う場合の2倍くらいなのに、ドライブスペースはローカルでやるのに比べて10倍から100倍の価格になってる。冗長性は少し高いけど、そのオーバーヘッドでデータを何度も繰り返すことができる。時間が経つにつれて、クラウドの取引条件は、ハードウェアがコア数を増やすにつれて悪化しているね。
└
288コアのボックスを使って、複数の並列ワークロードに分けるのに仮想化を使うのが唯一の良い方法なのかな？一度、GCPで384コアのAMD EPYCのベアメタルVMを借りたんだけど、ベアメタルLinuxだけでは並列化されたワークロードをスケールさせるのが全然できなかったんだ。CPU推論のジョブを並列で走らせたかったんだけど（それぞれ16コア使う予定だった）、スケーリングがひどくて、並列ジョブを増やせば増やすほど、全体が遅くなっちゃった。htopをチェックしたらCPUは全然使われてなくて、俺の理論ではONNX/torchでメモリのボトルネックが起きてるんじゃないかと思った（NUMAノードに関係してるのかな？）。結局、そこではproxmoxやvmwareを使ってCPUやメモリのリソースを分けるテストはできなかったから、代わりにコア数の少ないAMD Ryzen 1Uをたくさん買うことにしたんだ。そっちの方が俺の単純なアプローチにはずっとスケールが良かったよ。
Yoctoファンとして、クリーンなYoctoビルドにはどれくらいのリアルタイムが必要か気になるな。Yoctoはスレッドが重いから、288あればいい感じになるはず。
こういうパッケージ（たくさんのコア、多チップパッケージ、たくさんのメモリチャネル）だと、アーキテクチャはますますモノリシックなCPUではなく、パッケージ上の小さなクラスターになってきてるね。次のボトルネックはシリコンではなくソフトウェアのスケジューリングになるんじゃないかな。OSやランタイムは、数百のコアや複雑なインターコネクトトポロジーを考慮して設計されていなかったから。
└
Linuxは1024コアまでちゃんと扱えると思うよ。
└
ここには根本的なボトルネックはないと思う。1つのコアに100のプロセスがある時のスケジューリングオーバーヘッドは、100のコアに100のプロセスがある時よりも多いから。ボトルネックはほとんどハードウェア関連で、熱や電力、メモリ、他のI/Oに関係してる。だから、実際には「288コア」のパフォーマンスは得られないんだ。つまり、288コアでビットコインを単一コアと同じ速さで掘ることはできない。むしろ、288のタスクが断続的に作業をする時のコンテキストスイッチングオーバーヘッドが少なくなるってこと。これがほとんどのハードウェアの使われ方だしね。
└
確かにボトルネックはあるよね。いつも思うのはカーネルのネットワークスタックだな。独立したワークロードが何百もあるのに、カーネルのTCPスタックを使う意味がないよ。20年前にラックの上に外部TCPアプライアンスを置くのと同じくらい意味がない。ユーザースペースのプロトコルスタックが勝つよ。
└
> 次のボトルネックはシリコンではなくソフトウェアのスケジューリングになるのかな。 うん、スケジューリングはしばらく問題になってるね。数年前に、Linuxカーネルが偶然8コアにハードコーディングされていたっていう素晴らしい記事があったよ。多分ググれば見つかると思う。今一番興味深い問題はキャッシュだと思う。タスクがコアを移動するたびにキャッシュミスが発生するからね。数千のスレッドが数百のコアの間を数ミリ秒ごとに切り替えていると、CPUキャッシュを無駄にして再読み込みする時間が増えてきて、危険な状態に近づいているよ。
└
そうだね、スケジューリングの問題やNumaの問題など、ボックス型のクラスターによって引き起こされる問題があるよ。数年前に大きなパフォーマンスの問題があって、プロセスをNumaゾーンのトポロジーにマッピングすることで解決したんだ。そうしないと、ソフトウェアのデフォルト設計がすべてのメモリアクセスを同じNumaゾーンにルーティングしちゃって、パフォーマンスが落ちちゃうからね。
└
それはいいポイントだね。Linuxがio_uringを導入したけど、これでレイテンシをうまく隠すためのネイティブなプリミティブが得られると思う？でも、それはパズルの一部に過ぎないかな。
友達が難しいキャリアの選択をするのを手伝ったんだ（快適な仕事 vs 難しいけど新しいこと + 新しい街への引っ越し）。最終的にはそのプロジェクトに取り組むことになって、良かったなと思ってる。人が成長するのを見るのが大好きなんだ。
CPUをつなぎ合わせるためにたくさんの接着剤が使われてるみたいだね :)
└
チップレットの話を読んだ瞬間、これを思い出した！インテルもチップレットアーキテクチャが未来だって認めてるのが嬉しいね。
そうだね、これは彼らの勝負どころだよ。もしこれがダメなら、インテルはデフォルトするだろうね。信じてほしい。YouTuberからも聞いたことあるから、間違いないよ。
CPUビジネスにとって、今は本当に厳しいタイミングだね。RAMの価格が高いから、どんなに良いCPUでも、今は購入を控えるお客さんが多いと思うよ。
└
コアが十分にあれば、L1をまとめて即席のRAMにできるかもね！
└
新しいサーバーCPUって、置き換え用じゃないの？だから、データセンターは古いCPUを外して新しいのを入れて、既存のRAMの設定には手を加えずに、既存のRAMの範囲内でより良いパフォーマンスを発揮できるってことだよね。で、RAMの価格が下がったら（それにはちょっと時間がかかるかも）、その時に別にRAMをアップグレードすればいいんじゃない？
└
私の経験では、RAMのコストはサーバーを買うビジネスにはほとんど影響しないよ。購入のタイミングは契約や保証のサイクルでほぼ決まってるから。
みんなコア数に注目してるけど、パッケージの話の方がずっと面白いと思う。これ、12個のチップレットが18Aでスタックされて、Intel 3で作られたベースダイに接続されてるんだよね。I/OタイルはIntel 7に繋がってるし。一つのパッケージに3つの異なるプロセスノードがあって、大量生産されてるのはすごいよ。しかも、これは明らかにIFSの戦略でもある。Intelファウンドリーは証明が必要だからね。PDKをいくら公開しても、自社製品で288コアのサーバー部品を450Wで動かすのが一番信頼性を示せるよ。もしFoveros Directがここでうまくいけば、Intelにとって潜在的なファウンドリー顧客への最高の広告になる。チップレットのサイズが賢いのは、誰も言ってない理由がもう一つあって、それは歩留まり。18Aは新しいから、歩留まりは多分厳しいだろうけど、1ダイあたり24コアなら、悪い歩留まりでも十分な良いチップレットが得られるんだ。基本的にはAMDのZenのやり方だけど、3Dのひねりが加わってるね。それに、64のCXL 2.0レーンもあるし！ここでいくつかのコメントがDDR5の価格について不満を言ってるけど、それは正当だと思う。でも、ラック全体でのCXLメモリプールがその計算を完全に変える可能性があるよね。Intelは、実際の価値はコアではなく、データセンターで最高のCXLハブになることに賭けてるのかも。ARMの競争はまだまだ大きな問題だけど。「多くの効率的なコア」はARMがずっと得意としてきたことだし、ダークモントのIPCが17%向上したからって、そのギャップは埋まらないよ。