NVIDIA Groq 3 LPX：分かっていること全て

by ディビヤンシュ・ジェイン on 2026 年 3 月 18 日

AI ◇ Enterprise

LPU（Language Processing Unit）は、Groq社が設計・製造したカスタムAI推論アクセラレータです。2016年に、TPUのオリジナル開発者の1人として知られる元Googleエンジニアのジョナサン・ロスによって設立されたGroq社は、長年にわたり、決定論的なソフトウェア定義プロセッサアーキテクチャをゼロから開発してきました。動的なハードウェアスケジューリングとマルチレベルキャッシュ階層に依存するGPUとは異なり、LPUは根本的に異なるアプローチを採用しています。すべてのリアクティブハードウェアコンポーネントを排除し、制御プレーン全体をコンパイラに配置することで、クロックサイクルまで完全に予測可能な実行を実現しています。

昨年12月、NVIDIAはGroqを買収し、LPUアーキテクチャをNVIDIA傘下に収めた。この買収は業界で非常に大きな注目を集め、NVIDIAがGroqの技術を自社のデータセンターエコシステムにどのように統合するのかについて、すぐに様々な憶測が飛び交った。これらの疑問は、GTC 2026でついに解消された。NVIDIAは、Vera Rubinプラットフォームの7番目のチップとしてGroq 3 LPXを発表し、ラック規模のシステムで256個のLPUアクセラレータをVera Rubin NVL72と組み合わせた。

CPXはどうなったのか？

昨年開催されたAIインフラサミットで、NVIDIAは長コンテキスト推論クエリの高速化を目的とした構成のCPXラックも発表しました。この発表に関する最初の報道後、CPXの実際の機能についていくつかの疑問が生じました。一見すると、興味深いアーキテクチャコンセプトではありましたが、CPXは、おそらくアテンション操作のさらなる高速化を除けば、Rubin GPU自体を超える実質的な機能は何も提供していないように見えました。その後、Groqの買収があり、NVIDIAがGroqのLPUテクノロジーをより広範なVera Rubinプラットフォームにどのように統合するのかについての憶測が飛び交いました。

NVIDIAはGTC 2026でLPXを発表し、その疑問を解消しました。発表内容から判断すると、CPXラックのコンセプトはGroq 3 LPXラックへと進化し、オリジナルのCPXのコンテキスト処理重視のアプローチは、Groqのシリコンをベースとした根本的に異なるデコードアクセラレーションアーキテクチャへと移行したようです。LPXラックは完全液冷式で、MGXインフラストラクチャ上に構築されており、Vera Rubinの広範な展開と同時期の2026年後半に発売予定です。NVIDIAはこの新製品により、メガワットあたりの推論スループットが最大35倍向上し、1兆パラメータモデルにおける収益機会が最大10倍増加すると主張しています。

しかし、さらに重要な点として、NVIDIAは、LPUがVeraおよびNVL72プラットフォーム上で動作する既存のCUDAスタック内のアクセラレータとして機能し、計算処理がトークン単位で透過的にオフロードされることを確認しました。GTCの質疑応答セッションで、NVIDIAはLPUを「デコードモデルブースター」と表現し、次世代のプレミアムモデルサービスを実現するために、数兆パラメータのモデルを展開するAIラボや最先端のモデルビルダーと緊密に連携していくと説明しました。

CPXに関する疑問が解決した今、当然の次の疑問は、NVIDIAがラック規模のシステム全体を構築する際に中心としているこのLPUとは一体何なのか、ということだ。

LPUとは何ですか？

LPUの中核は、非常に大規模なベクトルプロセッサです。演算と通信の基本単位は、INT8では320バイト、FP16では640バイトからなる320要素のベクトルです。チップ上のあらゆる操作（算術演算、メモリアクセス、データ整形、チップ間転送など）は、これらの固定サイズのベクトル上で実行されます。

出典: Nvidia

このアーキテクチャは、単一の基本構成要素、すなわち軽量命令ディスパッチユニットと組み合わせたSIMD機能ユニットから構築されています。Groqはこの基本クラスを、特定の操作カテゴリに最適化された4つの異なるタイプに特化して扱います。

マトリックス実行モジュール（MXM）： 行列ベクトル演算および行列行列演算のための高密度乗算累積機能を提供する、主要な演算処理の中核となるチップです。NVIDIAのLPXラックに搭載されている8個のGroq 3 LP30チップは、それぞれ1.2 PFLOPSのFP8演算能力を持ち、LPXトレイ全体で合計9.6 PLOPSのFP8演算能力を実現します。

ベクトル実行モジュール（VXM）： ポイントごとの算術演算、論理演算、型変換、および活性化関数を処理します。VXMにはALUの配列が含まれており、コンパイラはこれらを自動的に連結して、単一のパスで複合演算（例えば、還元、バイアス加算、活性化、型キャストなど）を形成します。

スイッチ実行モジュール（SXM）： ベクトルの順列、回転、分布、転置など、構造化データの移動を実行します。

メモリユニット（MEM）： キャッシュも階層構造もキャッシュミスの概念もない、フラットなSRAM優先メモリアーキテクチャを採用。Groq 3 LP30は、150 TB/sの帯域幅で500 MBのオンチップSRAMを提供します。コンパイラは物理バンクの位置を直接参照し、プログラム実行全体を通してすべてのデータの正確な位置を把握します。

各機能ユニットの種類ごとに、チップの水平方向に複数のコピーが刻印されている。命令は上下から中央に向かって流れ、データストリームは東から西に向かって流れ、機能ユニット間を交差して演算を実行する。

1次元相互接続、ストリームレジスタ、および決定論

ストリームレジスタと1Dインターコネクト

LPU上の機能ユニット間の通信は、意図的にシンプルな一次元相互接続であるストリームレジスタを介して行われます。通信経路は東向きと西向きの2つがあり、各ストリームレジスタは1ホップを表します。データはクロックサイクルごとに正確に1ホップ移動するため、コンパイラはチップレイアウト上の物理的な位置に基づいて単純な加算または減算を実行することで、任意の2つの機能ユニット間の移動時間を推論できます。

相互接続内にはキューも競合メカニズムも存在しない。これにより、複雑な2次元ビンパッキング問題であったスケジューリング問題が、はるかに扱いやすい1次元問題へと簡略化される。 Groqのチーフアーキテクトであるイゴール・アルソフスキは、次のように説明しています。最良の点は、コンパイラが10サイクル後のデータの位置を正確に把握できることです。なぜなら、そのデータは正確に10ホップ先にあるからです。曖昧さも、推測も、ハードウェアによる独立したルーティング決定も一切ありません。

決定論

LPUの決定的な特徴は決定性である。従来のプロセッサでは、動的なスケジューリング、キャッシュの動作、メモリへのアクセス競合によって実行時にばらつきが生じるが、LPUはばらつきゼロで実行され、すべての機能ユニットが同期して動作する。

この決定論的な動作は、ハードウェアインターロックなどの機能を排除し、すべての意思決定をコンパイラで行うことで実現されます。ハードウェアは、生成されたスケジュールを実行するだけです。このアプローチのその他の利点としては、すべての処理が全く同じレイテンシで動作し、消費電力もあらゆる時点で予測可能であることが挙げられます。

決定論は、GroqがTruePointテクノロジーと呼ぶものを通して数値領域にも及んでいます。このアーキテクチャでは、演算順序が保証されているため、320要素の融合ドット積と1回の丸め処理によって、FP16入力からFP32レベルの精度を実現できます。数値決定論がLLM推論にとってなぜ重要なのか、また非決定論的なハードウェアが実行ごとに微妙に異なる出力を生成する理由については、Thinking Labのホワイトペーパーで詳しく解説されています。「LLM推論における非決定論の克服」これは本稿の主題ではありませんが、数値精度への影響に関心のある読者は、末尾にリンクされているGroq社のTruePoint技術文書で関連する分析を見つけることができます。

LPUの接続方法：RealScale、組立ライン、ラック構成

組立ライン：データがどのように移動するか

最も単純なレベルでは、LPU間のデータ移動は組み立てラインのように機能します。システム用にモデルがコンパイルされると、コンパイラはそれをステージに分割し、各ステージをLPUチップのグループに空間的にマッピングします。各グループは、必要な重みパラメータをローカルのオンチップSRAMに格納します。推論中、チップグループ間を移動するデータは、前のステージからの中間活性化出力のみです。データは、コンベアベルトに沿って移動する製品のようにチップからチップへと流れ、各ステーションは割り当てられた計算を実行し、結果を次のステーションに渡します。これは、各計算ステージでオフチップのHBMメモリから重みセット全体を取得して結果を書き戻す必要があるGPUとは根本的に異なります。LPUでは、重みは各ステーションのSRAMに既に格納されているため、移動するのは活性化テンソルのみです。

C2Cリンクに関する注記：RealScaleのC2Cリンクではありません

トポロジーの詳細に入る前に、混乱を招く可能性のある点を明確にしておくことが重要です。LPXシステム全体で使用されているチップ間（C2C）リンクは、Groq社のRealScale C2Cインターコネクトです。これは、NVIDIAエコシステム内の他の場所で使用されているNVIDIAのC2Cテクノロジーとは異なります。この2つのテクノロジーは、アーキテクチャ的に全く異なるものです。

NVIDIA C2Cは、CPUとGPU間のリンクなど、密接に結合されたモジュール内で2種類の異なるチップを接続するために設計されたキャッシュコヒーレントな相互接続技術です。高速なSerDesを用いたコヒーレントプロトコルを採用し、単一のパッケージまたはモジュール内での異種チップ間通信を実現するように設計されています。
Groq RealScale C2Cは、ソフトウェアでスケジューリングされた、決定論的なポイントツーポイント相互接続です。ネットワークリンクはコンパイラによって明示的にフロー制御され、MXMやVXMの演算ユニットと同様に、第一級の機能ユニットとしてスケジューリングされます。ハードウェアによる調停や適応型ルーティングは行われず、パケットには送信元または宛先ヘッダーは含まれません。リンクは位相が揃っており、チップ間の高帯域幅で固定遅延のワイヤのように動作します。プレシオクロナスプロトコルは、チップ間の自然なクロックドリフトを決定論的に考慮し、ネットワーク全体でコンパイラに単一の共通時間領域を提供します。

LPXラック内のすべてのC2C接続（トレイ内、スパインを介したトレイ間、フロントパネルポートを介したラック間）は、RealScaleを使用しています。これは、Groqが初代GroqNode以来使用してきた基本的な相互接続技術と同じもので、リンク速度は（レーンあたり30Gbpsから112Gbpsに）向上していますが、アーキテクチャは変更されていません。

注：接続性を説明する次のセクションは、Groqのドキュメント（末尾にリンクあり）に基づいたアーキテクチャの理解に基づいています。 NVIDIAのブログ記事そして、GTCブースで提供されたラックの説明は以下のとおりです。

LPXラックユニットで使用されているC2CリンクはGroq独自の技術であり、NVIDIAの他のラックスケールシステムで使用されているC2Cリンクとは異なります。
LPXラックユニット前面にある4つのC2Cリンクは、同じレベルの隣接するラックユニットとの接続に使用されます。
ラック内では、LPU間で全対全通信が行われます。
LPXラックに搭載されているプロセッサはx86です。

トレイ内接続

Groqのネットワークトポロジーの基本的な構成要素は、初代GroqNodeからNVIDIA Groq 3 LPXまで変わっていません。各1Uコンピューティングトレイには、LP30チップが正確に8個搭載されており、完全なグラフ（オールツーオール）で密に相互接続されています。これにより、すべてのチップが他のすべてのチップと直接、同じ速度で通信できます。

出典: Nvidia

各 LP30 チップには 96 個の C2C リンクがあり、それぞれが 112 Gbps で動作し、チップあたり 2.5 TB/s の双方向帯域幅を提供します。8 個のチップの完全なグラフでは、各チップには 7 つの隣接チップがあります。トレイ内の固有のチップ間エッジの数は C(8,2) = 28 です。各チップの 96 個のリンクの一部は、これらのトレイ内全対全接続に使用され、残りのリンクはバックプレーン (ラックの背骨用) とフロントパネル (ラック間用) にルーティングされます。NVIDIA の公開仕様では、トレイあたり合計 20 TB/s のスケールアップ帯域幅が記載されており、これはトレイ内帯域幅と背骨帯域幅を合わせたものです。これを検証できます。各トレイには 8 個のチップ × 96 個のリンク = 合計 768 個のリンクがあります。フロントパネルのラック間レーン 32 個を差し引くと、スケールアップ用のリンクは 736 個になります。リンクあたり112Gbpsなので、736×112Gbps＝82,432Gbpsとなり、これは1方向あたり約10.3TB/sに相当し、双方向で約20.6TB/sとなります。これはNVIDIAが公表しているトレイあたり20TB/sという数値とよく一致しています。

この8チップからなるオールツーオールグループは、トンボ型ネットワークトポロジーの「ローカルグループ」を構成します。初代GroqChip 1は、カードあたり11個のC2Cリンクを備え、各リンクはレーンあたり30Gbps（リンクあたり4レーン）で、カードあたり合計330GB/sの帯域幅を実現していました。Groq 3 LP30は、112Gbpsのリンクを96個備え、同じトポロジー構造を維持しながら、チップあたりのI/O帯域幅を大幅に向上させています。

ラック内接続

単一のLPXラック内には、32個のコンピュートトレイ（合計256個のチップ）が、バックプレーン内の4つのETLスパインを介して相互接続されています。これらのスパインは、トレイ間でRealScale C2Cトラフィックを伝送し、ラック規模のスケールアップドメインを構築します。ラック全体のスケールアップ帯域幅は合計640 TB/s（32トレイ×1トレイあたり20 TB/s）です。4つのスパインに分配され、各スパインは約160 TB/sの双方向帯域幅を伝送します。

ラック間接続

各1Uコンピューティングトレイの前面パネルには4つのQSFP C2Cポートが露出しており、ラック間通信用に合計32レーン（ポートあたり8レーン）が提供されます。これらのポートは対称的なパターンで隣接するラックに接続されます。2つのポート（16レーン）は左側の隣接ラックに、2つのポート（16レーン）は右側の隣接ラックに接続されます。各U位置は、隣接するラックの対応するU位置に接続されます（ラックAの最初のUはラックBの最初のUに、2番目のUは2番目のUに、といった具合です）。

出典: Nvidia

1レーンあたり112Gbpsで、各トレイの32本のラック間レーンは、32×112Gbps＝3,584Gbps、つまり1トレイあたり約448GB/sのラック間帯域幅を提供します。ラック全体では、32個のトレイが32×32＝1,024本のラック間レーンを提供します。これは1,024×112Gbps＝114,688Gbps、つまり隣接する各ラックへの方向あたり約14.3TB/sに相当します（均等に分割：左隣ラックへ約7.2TB/s、右隣ラックへ約7.2TB/s）。

このラック間帯域幅は、設計上、ラック内帯域幅よりも疎になっています。ラック内では、640 TB/s のスケールアップドメインにより、スパインを介して高密度な全対全接続が可能になります。ラック間では、フロントパネルリンクにより、トンボ型トポロジーの疎なグローバル接続が実現されます。これは、チップあたり 4 つの外部 C2C リンクがローカルグループ (ノード) を接続し、ネットワーク直径の小さい (264 チップ構成で最大 3 ホップ) マルチラックシステムを形成する、オリジナルの GroqRack と同じアーキテクチャパターンです。

まとめ：同じ構造、密度は4倍

当初の4ラック構成のGroqRackには、264個のGroqChipプロセッサが搭載されていました。1つのLPXラックには、256個のLP30チップが1つのMGX ETLラックに詰め込まれており、チップ密度は約4倍になり、液冷とケーブルレスバックプレーンを備えた1ラックのフォームファクタに収まっています。8チップによるオールツーオールのローカルグループ、ドラゴンフライトポロジー、ソフトウェアスケジューリングによるルーティングパラダイムはすべてそのまま引き継がれています。Groqの基本的なネットワーク技術は変わっていません。拡張されただけです。

単一ラックのSRAM容量（256チップで合計128GB）を超えるモデルの場合、フロントパネルのC2Cポートを介して複数のLPXラックまたはラック列を相互接続することで、組立ラインをさらに拡張できます。実際のモデルサイズにおけるこの仕組みについては、次のセクションで詳しく説明します。

FFNレイヤーとは？NVIDIAがオフロードしているものを理解する

Decodeのサービス提供が難しくなっている理由

NVIDIAがLPXにオフロードしている内容とその理由の詳細に入る前に、NVIDIAが指摘するように、このアーキテクチャ上の決定が必要となるより広範な傾向を理解しておくことが役立ちます。AI推論は、単一の均一なワークロードではありません。単一のリクエスト内でも、プリフィルフェーズ（プロンプトを取り込んでKVキャッシュを構築する）とデコードフェーズ（トークンを1つずつ生成する）では、ハードウェアに対する要求が大きく異なり、これらの要求はバッチサイズ、コンテキスト長、モデル構造によって変化します。

モデルがより長い推論出力と多段階の思考連鎖を生成するにつれて、各リクエストのより大きな割合がシーケンシャルなデコードフェーズに移行します。同時に、プレフィックスキャッシュなどの技術は、リクエスト間で共有プロンプト状態を再利用することでプリフィルのコストを削減しますが、これはデコードの相対的なコストをより顕著にするだけです。コンテキストウィンドウも数十万トークンにまで拡大しており、アテンション計算中のメモリ帯域幅にますます大きな負荷がかかっています。また、エージェントワークフローでは、多くのモデル呼び出し、ツールとのやり取り、検証ループにわたってレイテンシが累積します。累積的な影響として、デコードレイテンシがユーザーが感じるボトルネックになりつつあり、集約スループットの最大化のみを目的としたハードウェアは、個々のリクエストごとに高速で予測可能なトークン生成を必要とするワークロードには必ずしも最適ではありません。

さらに、アントロピックの高速モードリリース、低遅延、高トークン処理能力は確かに収益増加につながり、Anthropicの高速推論サービスは通常のリクエストの6倍のコストがかかる。

今回のLPXの発表から、NVIDIAが最大のデコードボトルネックであるフィードフォワードネットワーク（FFN）層の負荷をLPUに分散させたいと考えていることが分かります。FFNがなぜターゲットなのか、そしてそれがもたらす影響の大きさを理解するために、現在最も普及しているオープンソースモデルのFFNパラメータ数を分析しました。

FFNレイヤーとは何か、そしてなぜFFNレイヤーが主流なのか？

Transformer層はそれぞれ、アテンションブロックとフィードフォワード（FFN）ブロックという2つの主要なブロックで構成されています。アテンションブロックは、トークンがシーケンス内の他のトークンからの情報を参照し、それらを組み合わせることを可能にします。FFNブロックは各トークンに対して独立して動作します。トークンの表現を高次元空間に投影し、非線形性を適用した後、再び低次元空間に投影します。これは、事実関係や学習された変換が格納される、モデルの知識ストアのようなものと考えることができます。

MoE（Mixture of Experts）アーキテクチャは、DeepSeek R1、Kimi K2、Qwen3-235B、GLM-5、MiniMax M2.5、OpenAIのGPT-OSS 120Bなど、今日の主要なオープンソース大規模言語モデルの中で、支配的なアーキテクチャとして台頭してきました。

これらのMoEモデルでは、FFNブロックが数百個の独立した小さなコピー（エキスパートと呼ばれる）に複製され、アテンションは共有されたままになります。軽量な学習済みルーティング関数が、トークンごとにアクティブ化するエキスパートの小さなサブセットを動的に選択します。その結果、膨大な数のパラメータを格納しながらも、トークンごとにアクティブ化するのはごく一部に過ぎないモデルが実現し、比例した計算コストをかけずに、規模のメリットによる品質向上を実現できます。

しかし、お気づきのとおり、これには別の課題があります。FFN層がモデルの重みの大部分を占めているのです。特にMoEモデルの場合、これはモデルの重みの最大90%にも達することがあります。

DeepSeek R1の内部構造：実践例

例として、DeepSeek R1 を詳しく見てみましょう。このモデルは、隠れ次元 (H) が 7,168 の 61 個の Transformer 層で構成されています。最初の 3 層は標準的な高密度 FFN を使用し、残りの 58 層は MoE を使用します (さらに、独自のエキスパートを持つ追加の MTP 層が 1 つあり、合計で 59 個の MoE 層になります)。最新の LLM では、2 個ではなく 3 個の重み行列を持つ SwiGLU と呼ばれるバリアントを使用します。順方向パスでは、w2(SiLU(w1(x)) ⊙ w3(x)) を計算します。ここで、w1 (ゲート射影) と w3 (上方向射影) は隠れ次元を H から中間サイズ I に拡張し、w2 (下方向射影) はそれを圧縮します。⊙ は、ゲート付きパスとゲートなしパス間の要素ごとの乗算です。これらの行列にはバイアス項がないため、各 SwiGLU FFN ブロックには正確に 3 × H × I 個のパラメータが含まれます。

出典：セバスチャン・ラシュカ

DeepSeek R1 の密な層 (最初の 3 つ) の場合、中間次元は 18,432 であり、1 層あたり 3 × 7,168 × 18,432 = 3億9,640 万個のパラメータがあります。MoE 層の場合、256 個のルーティングされたエキスパートはそれぞれ完全な SwiGLU ブロックであり、中間次元は 2,048 と小さいため、各エキスパートは 3 × 7,168 × 2,048 = 4,400 万個のパラメータを持ちます。256 個のエキスパートを掛けると、ルーティングされたエキスパートだけで 1 層あたり 112億7,000 万個のパラメータになります。さらに、各 MoE 層には、1 つの共有エキスパート (同じ 4,400 万個のパラメータを持つ SwiGLU ブロックで、すべてのトークンに対して常にアクティブ化されます)、ルーターゲート (形状 [256, 7168] = 180 万個のパラメータの線形射影)、およびルーティング中の負荷分散に使用される 256 個の FP32 値の小さなバイアスベクトルがあります。

完全なFFNには約669.1億個のパラメータがあります。FP8 E4M3形式（重み1つあたり1バイト）では、FFNデータは約623.1GBになります。これは、モデルのディスク上の推定総サイズの97.7%に相当します。残りの約2.3%は、アテンション重み、埋め込み、出力ヘッド、レイヤーノルム、およびFP8スケールメタデータです。

分解の解読

NVIDIAは現在、デコードフェーズを単一の操作としてではなく、トークンごとに繰り返されるループとして捉えており、各部分で異なるハードウェアのボトルネックに負荷がかかるように設計している。プリフィルフェーズは、大量の入力を取り込み、KVキャッシュを構築する処理が中心であり、このワークロードは高密度な並列演算と大容量メモリによって効率化される。Vera Rubin NVL72は、特にプロンプトが膨大で変動が大きいロングコンテキストワークロードにおいて、この処理を効率的にこなす。

出典: Nvidia

デコードは異なります。新しいトークンごとに、システムは蓄積されたKVキャッシュ全体に対してアテンションを実行し、アテンション出力に対してFFN/MoE計算を実行する必要があります。NVIDIAのAttention-FFN Disaggregation（AFD）アーキテクチャでは、これら2つのステップは2つのエンジンに分割されています。Rubin GPUはデコードアテンションを処理します。HBMからKVキャッシュを読み取り、アテンションスコアを計算し、中間アクティベーションを生成します。このアクティベーションテンソル（NVIDIAが「中間テンソル状態」と呼ぶもの）はLPXに渡され、LPXはFFNまたはMoEエキスパート計算を極めて低い帯域幅と決定論的なレイテンシで実行し、結果をGPUに返してトークン生成を続行します。

このハンドオフは、トークンごとに発生します。GPUとLPU間で交換される活性化テンソルは、重みデータに比べて小さいため、LPUのほぼゼロオーバーヘッドのネットワーク機能が真価を発揮します。この分割は、各プロセッサの基本的な強みを活かしています。GPUは、大規模なKVキャッシュ上で可変長の注意に必要なHBM容量と柔軟な実行機能を提供し、LPUは、帯域幅が制限された静的にスケジューリング可能なFFN重みに必要なSRAM帯域幅と決定論的なスケジューリング機能を提供します。

出典: Nvidia

ここで、微妙ながらも重要なスケーリング特性について触れておく価値があります。コンテキストの長さが長くなるにつれて、アテンション操作の計算量とメモリ要件もそれに合わせて増加します。KVキャッシュはコンテキストのトークンが1つ増えるごとに線形に拡張され、新しいデコードステップでは蓄積されたキャッシュ全体に注意を払う必要があります。しかし、FFNはコンテキストの長さに応じて全く増加しません。FFNの重み行列（SwiGLUではw1、w2、w3）は、モデルアーキテクチャの固定定数です。コンテキストが1,000トークンでも1,000,000トークンでも同じサイズであり、各トークンは独立してそれらを通過します。つまり、AFDアーキテクチャでは、コンテキストウィンドウが拡大し続けるにつれて、GPU側がコストの増加（KVキャッシュ用のHBMの増加、アテンションのための計算量の増加）を吸収する一方、LPX側は完全に静的なままです。モデルのFFNを処理するために必要なLPXラックの数は、処理構成のコンテキストの長さではなく、モデルのアーキテクチャによって完全に決定されます。これは、SRAMのみのアクセラレータにとって歴史的に最大の課題の一つであった、増大するコンテキスト要求が最終的に固定オンチップメモリ容量を上回ってしまうという問題を巧みに解決します。AFD分割では、コンテキスト依存の処理は拡張可能なHBMを備えたハードウェア上に残り、LPUは固定SRAMに自然に収まるコンテキスト非依存の処理のみを処理します。

NVIDIA Dynamoにより、異種デコードが実用化される

この2つのエンジンによるループを実運用環境で機能させるには、ハードウェアだけでは不十分です。NVIDIAのDynamoオーケストレーションレイヤーこそが、異種デコードを実用化する鍵となります。Dynamoは、GPUとLPUバックエンドに分散されたサービス提供を調整し、AFDに必要なトークンごとの分類、ルーティング、およびアクティベーション転送を処理します。

出典: Nvidia

実際には、DynamoはプリフィルをGPUワーカーにルーティングして入力を処理し、KVキャッシュを構築します。デコード中は、DynamoがAFDループをオーケストレーションします。GPUは蓄積されたKVキャッシュに対してアテンションを実行し、中間アクティベーションはFFN/MoE実行のためにLPUに渡され、出力はトークン生成を継続するためにGPUに戻ります。その結果、2つの独立したシステムではなく、単一の一貫性のあるサービングパスが実現します。

Dynamoは、KV対応ルーティング（リクエストが関連するKVキャッシュを既に保持しているワーカーにルーティングされるようにする）、レイテンシ目標に基づいたスケジューリング（対話型セッションが長いキューに滞留しないようにする）、および低オーバーヘッドの転送管理も提供します。これらの機能は、コンテキスト長が変動し、リクエストの種類が混在し、同時実行が急増する実際の運用トラフィックにおいて、オーケストレーションレイヤーがテールレイテンシを安定させ、テナント間のジッターによるユーザーエクスペリエンスの低下を防ぐため、重要です。

主要なオープンソースモデルすべてにおけるFFNサイズとLPXサイズ

LPXの仕組みと、それが解決しようとしている問題が理解できたところで、ハードウェア要件の観点から見ていきましょう。

よく使われるモデルについて、パラメータ数とディスク上のFFNサイズを計算しました。 config.json (NAIST) と model.safetensors.index.json Huggingfaceで入手可能です。

モデル	FFNパラメータ	FFNサイズ（ディスク上）	FFN %	Dタイプ	エキスパート
DeepSeek R1 および DeepSeek V3.2	669.1B	623.1 GB	97.7%	FP8	256
キミK2	1.02T	948.0 GB	98.9%	FP8	384
キミK2.5	1.02T	474.0 GB	98.5%	INT4	384
ミニマックスM2.5	224.7B	209.3 GB	97.7%	FP8	256
OpenAI GPT-OSS 120B	114.7B	53.4 GB	95.4%	MXFP4	128
GLM5	738.1B	1,374.8 GB	98.0%	BF16	256
Qwen3 235B-A22B	227.2B	423.1 GB	96.6%	BF16	128

このパターンは、以前に調査した内容を裏付けています。この分析のすべてのモデルにおいて、FFN パラメータがディスク上のモデル全体のサイズの 95% ～ 99% を占めています。Kimi K2 は最も極端なケースで、レイヤーごとに 384 個のルーティングされたエキスパートがあり、FFN パラメータが 1 兆を超え、全体の 99% 近くを占めています。このセットの中で最小のモデルである OpenAI の GPT-OSS 120B (MXFP4 に格納された 128 個のエキスパート) でさえ、FFN が全体の 95.4% を占めています。ディスク上のサイズは、GPT-OSS 120B (4 ビット量子化のおかげで) の控えめな 53 GB から、GLM 5 (量子化なしで BF16 に格納) の約 1.4 TB まで幅広くあります。

これらの数値は、LPX のサイズを理解するのに役立ちます。単一の LPX ラックには、256 個のチップで合計 128 GB の SRAM が搭載されています。OpenAI の GPT-OSS 120B (FFN 53 GB) のようなモデルの場合、FFN ウェイトは余裕を持って単一のラックに収まります。DeepSeek R1 (623 GB) にはおよそ 5 つの LPX ラックが必要となり、GLM 5 (BF16 で 1.4 TB) には 10 個以上が必要になります (ただし、FP8 に量子化すれば、その量はほぼ半分になります)。まさにこれが、ラック間のフロントパネル C2C ポートが必要な理由です。これにより、複数の LPX ラックを連結して、より大きなモデルに対応できるように組み立てラインを拡張できます。

LPXによる投機的デコードの高速化

NVIDIAは、AFDデコードループ以外にも、LPXの2つ目の主要な用途として、投機的デコードにおけるドラフト生成エンジンとしての役割を挙げている。

投機的デコーディングは、LLM推論におけるレイテンシを削減するための重要な手法としてますます注目されています。その仕組みは単純明快です。より小さく高速なドラフトモデルが複数の候補トークンを事前に生成し、より大規模なターゲットモデルがそれらを並行して検証・承認します。ドラフトモデルの予測が正しければ（定型テキストでは多くの場合正しい）、単一の検証ステップで複数のトークンを一度にコミットできます。その結果、1秒あたりの実効トークン数が大幅に増加し、エンドユーザーが感じるレイテンシも低減されます。

出典: Nvidia

課題は、投機的復号ではドラフトモデルが極めて高速に動作する必要がある点です。ドラフトモデルが候補を生成するのに費やす1ミリ秒は、検証者が待機する1ミリ秒に相当します。従来のGPUのみの構成では、ドラフトモデルとターゲットモデルが同じハードウェアリソースを競合し、ドラフトモデルの速度は他のすべてに影響を与えるHBM帯域幅の制約によって制限されます。

LPXはこの役割に最適です。決定論的な実行モデルとLP30の極めて広いオンチップSRAM帯域幅により、非常に高速で予測可能なドラフトトークン生成が可能です。より小さなドラフトモデルは、単一のLPXトレイまたは少数のトレイのSRAMに余裕を持って収まり、決定論的なスケジューリングにより、検証装置とのパイプライン処理を困難にするようなばらつきがなく、ドラフト生成が常に安定した予測可能な速度で実行されることが保証されます。

この構成では、システムは2つのプロセッサを相補的な役割に割り当てます。LPXは低遅延アーキテクチャを使用してドラフトトークンを高速に生成し、Rubin GPUは高スループットの計算能力と大容量のHBMを使用してトークンを効率的に検証および確定します。この分離により、投機的デコード処理を異種プロセッサ間で実行できるため、両方のモデルが単一のGPUを共有する必要がなくなり、同種構成と比較してドラフト速度と検証スループットが向上する可能性があります。

NVIDIAは、AFDと並んで投機的デコードをLPXの重要なワークロードとして挙げており、これをシステムの価値提案の重要な部分と捉えていることを示唆している。最先端モデルが成長し、推論チェーンが長くなるにつれて、専用ハードウェア上でトークンを並列に生成および検証する能力は、インタラクティブな応答性を維持するための重要な手段となる可能性がある。

最終的な考察：究極のハードウェア/ソフトウェア協調設計

Vera RubinプラットフォームとLPXにおけるNVIDIAのアプローチで際立っている点の1つは、各コンポーネントが非常に的確にターゲットを絞っていることです。コンシューマー向け製品では、顧客のニーズを深く理解していない企業が、実際には誰も抱えていない問題を解決しようとする製品をよく見かけます。NVIDIAの戦略はこれとは全く対照的です。彼らは推論パイプラインの問題を極めて詳細なレベルで理解しており、顧客がハードウェアから最大限のリターンを得られるよう、パイプラインのあらゆる部分を最適化していることは明白です。

アテンション/FFNの分離は、マーケティングコンセプトではありません。これは、数兆パラメータのMoEモデル処理におけるボトルネックプロファイルの測定結果に対する直接的な対応です。FFN（アテンションではなく）をオフロードし、CPXラックをLPXラックへと進化させるという決定は、どの操作が帯域幅制約型で、どの操作が容量制約型なのか、どの操作が静的にスケジューリング可能で、どの操作が動的に変化するのか、そしてどのプロセッサアーキテクチャがそれぞれに最適なのかを正確に理解していることを反映しています。Dynamoオーケストレーションレイヤー、透過的なCUDA統合、そしてケーブルレスのMGXラック設計はすべて、エンジニアリング組織が展開ライフサイクル全体を熟考していることを示しています。

LPXとNVIDIAの新たな最先端製品には、まだ多くの不明点があります。私たちにとって大きな疑問の一つは、「ファブリック拡張ロジックとDRAM」の目的は何なのか、どのようなシリコンが使われているのかということです。また、多くの人がすでにx86ソケットに気づいており、昨年のIntelへの投資やヒートシンクの保持設計から、Intel製プロセッサである可能性が高いものの、どの部品が使われているのかは依然として大きな謎です。

LPXの導入は当初、広範な提供よりもモデル構築者とサービスプロバイダーに重点を置きます。また、可変コンテキスト長、多様なリクエストタイプ、バースト的な同時実行性といった本番環境のトラフィックパターンにおける実際のパフォーマンスと電力効率については、別途検証が必要です。これらのシステムにアクセスして独立したテストを実施できることを楽しみにしています。