NVIDIA GPUでGPT-6.1 Sol Ultrafastは可能なのか

#

#

CerebrasでもGroqでもないGPUが超低レイテンシ推論へ入ってきた理由――MTP、投機的デコード、DeepSeek、AIによるGPU自己最適化を代数から考える

#

フロンティアAIの推論速度を考えるとき、これまで一つの分かりやすい構図があった。

#

低batch、特に1ユーザーに対して1 tokenずつ高速に生成するsingle-stream inferenceでは、GPUよりもCerebrasやGroqのような専用推論hardwareが強い。

#

理由は単純である。

#

巨大なLLMでは、毎tokenごとに大量のmodel weightを読み出す必要がある。

#

NVIDIA GPUではそのweightの多くがHBMに置かれている。一方、Cerebras WSE-3は44GBのSRAMを演算coreと同じwafer上に配置し、21PB/sのaggregate memory bandwidthを持つ。GroqChipも1 chipあたり230MBのSRAMと最大80TB/sのon-die bandwidthを持つ。

#

つまり、

#

\text{Memory} \rightarrow \text{Compute}

#

の距離を物理的に短くし、巨大なbandwidthでweightを演算器へ送り込む。

#

Cerebrasは2026年8月、GPT-5.6 Sol Ultrafastを最大750 output tokens/s、Standard比最大14倍で動かした。OpenAI自身もこのUltrafastがCerebrasを採用していることを公表している。

#

ならば低レイテンシ推論は、このような巨大SRAM machineの独壇場になるのだろうか。

#

ところが2026年10月1日、NVIDIAはGPT-6 Astra UltrafastがNVIDIA Blackwell GPU上で動作し、Standard modeに対して最大8倍高速なtoken generationを実現すると発表した。しかもOpenAIは、自社のモデルを使ってNVIDIA GPU上のinference softwareを継続的に改善しているという。

#

ここで非常に興味深い問題が生まれる。

#

SRAMを数十PB/sで動かすCerebrasでも、GroqのLPUでもない。HBMを使う普通のNVIDIA GPUで、なぜ超低レイテンシ推論をここまで高速化できるのか。

#

そして、同じ考え方をGPT-6.1 Solのようなモデルへ持ち込めば、将来的にSol級のモデルでもNVIDIA GPUによるUltrafast servingは可能なのだろうか。

#

本稿では、この問題をMTP、投機的デコード、GPU kernel、DeepSeek、そしてAIによるGPU software最適化という流れから考えていく。

#

最初に整理しておく――現在「最大8倍」が確認されているのはGPT-6 Astra

#

最初に事実と仮説を分けておきたい。

#

2026年10月2日時点で、OpenAIがUltrafast modeを広く提供しているのはGPT-6 Astraであり、公式documentationでもStandard比最大8倍とされている。GPT-5.6 Sol UltrafastはCerebras上でpreview提供されている。

#

GPT-6.1 Solは9月29日に公開され、OpenAI APIで利用できるが、現在公式に確認できるのはStandardやFastなどであり、「GPT-6.1 Sol UltrafastがNVIDIA GPU上で最大8倍」という公式発表はない。

#

また、Astra UltrafastについてもOpenAIやNVIDIAはMTPやspeculative decodingの採用を公表していない。

#

したがって以下でMTP／投機的デコードを扱う部分は、

#

「Astraが実際にこの方式で8倍になった」と断定するものではなく、NVIDIA GPUが低batch・低レイテンシ推論を高速化するうえで成立し得る有力な技術的可能性

#

として考える。

#

これは重要な区別である。

#

1．そもそも、なぜLLMのDecodeはGPUにとって難しいのか

#

Transformerでは大量の行列積が行われる。

#

最も単純な形にすると、

#

Y=XW

#

である。

#

X は入力、W は学習済みのweightである。

#

例えば入力token数を L、hidden dimensionを d、出力dimensionを m とすると、

#

X\in\mathbb{R}^{L\times d}

#

W\in\mathbb{R}^{d\times m}

#

なので、

#

Y\in\mathbb{R}^{L\times m}

#

となる。

#

ここでLLM推論には、大きくPrefillとDecodeという二つの段階がある。

#

Prefill――たくさんのtokenを一度に計算する

#

例えば4096 tokenのpromptなら、

#

X\in\mathbb{R}^{4096\times d}

#

である。

#

したがって、

#

[4096\times d] [d\times m]

#

という大きなmatrix multiplicationを行える。

#

巨大なweight W をHBMから持ってきても、それを4096 tokenに対して利用できる。

#

GPUのTensor Coreは巨大な行列×行列演算を得意とするので、これは非常に都合がいい。

#

Decode――1 tokenずつ進む

#

ところが回答生成に入ると、新しいtokenは基本的に1個ずつ生成される。

#

すると、

#

X\in\mathbb{R}^{1\times d}

#

になり、

#

[1\times d] [d\times m]

#

となる。

#

巨大なweightを読み込んだにもかかわらず、1 token分しか計算しない。

#

次tokenでも、

#

[1\times d]W

#

その次でも、

#

[1\times d]W

#

を繰り返す。

#

イメージとしては、

#

巨大なweightをHBMから読む　　　　↓ 　　　1 token 　　　　↓ 巨大なweightをHBMから読む　　　　↓ 　　　1 token 　　　　↓ 　　　　…

#

となる。

#

Tensor Coreはさらに大量の掛け算を実行できるのに、weightが到着するまで待たされる。

#

これが低batch Decodeで問題になるMemory Wallである。

#

2．Attentionを代数で見るとPrefillとDecodeの差が分かる

#

Transformerでは、入力 X から、

#

Q=XW_Q

#

K=XW_K

#

V=XW_V

#

を作る。

#

そして、

#

A= \mathrm{Softmax} \left( \frac{QK^T}{\sqrt{d_h}} \right)

#

O=AV

#

を計算する。

#

Prefillでは、

#

Q\in\mathbb{R}^{L\times d_h}

#

K^T\in\mathbb{R}^{d_h\times L}

#

なので、

#

QK^T \in \mathbb{R}^{L\times L}

#

となる。

#

多数のtokenを一気に計算する。

#

一方Decodeでは、過去tokenのK、VをKV Cacheとして保存しておくので、新tokenについて必要なのは、

#

q_t\in\mathbb{R}^{1\times d_h}

#

だけである。

#

したがって、

#

q_tK_{\rm cache}^T

#

を計算する。

#

つまり非常に大まかには、

#

\boxed{ Prefill=\text{大量tokenを並列に計算} }

#

\boxed{ Decode=\text{新tokenを1個ずつ逐次計算} }

#

となる。

#

このためPrefillはGPUの演算能力を使いやすい一方、batchが小さいDecodeではmemory bandwidthが支配的になりやすい。

#

3．だからCerebrasやGroqは速い

#

Cerebrasはこの問題を非常に直接的に解決する。

#

WSE-3では44GBのSRAMを900,000 coreのすぐ近くに配置し、21PB/sのaggregate bandwidthを持つ。GPT-5.6 Solのように1 waferへ収まらないモデルではlayer単位で複数systemへ分割し、それぞれのweightを各waferのlocal SRAMへ置く。

#

Groqも発想は近い。

#

GroqChipは230MB SRAMと最大80TB/sのon-die memory bandwidthを持ち、外部HBMとの往復を減らす設計を取る。

#

NVIDIA Blackwell UltraのHBM帯域は1 GPUあたり約8TB/sである一方、FP4演算能力はdenseで約15 PFLOPS、最大20 PFLOPS級に達する。つまり演算能力が非常に巨大である。

#

ここに重要な非対称性がある。

#

GPUには非常に巨大な演算能力がある。

#

しかしlow-batch decodeでは、その演算能力へdataを十分供給できない。

#

ならば、

#

「memory bandwidthをCerebras並みにする」のではなく、「同じmemory bandwidthからもっと多くの仕事を取り出す」

#

という別の解決方法が考えられる。

#

ここでMTPとspeculative decodingが出てくる。

#

4．まずMTP――未来のtokenにも損失を与える

#

通常のLLMはNext Token Predictionで学習する。

#

文章を、

#

x_1,x_2,\dots,x_t

#

まで読んだとき、

#

x_{t+1}

#

を予測する。

#

モデルが正解tokenへ与えた確率を p とすると、Cross Entropy lossは簡単には、

#

L_1=-\log p(x_{t+1})

#

と書ける。

#

例えば正解tokenへ、

#

p=0.9

#

を与えればlossは小さい。

#

一方、

#

p=0.01

#

なら大きな罰を受ける。

#

これを大量のtokenについて繰り返して学習する。

#

MTPでは、その先も当てる

#

Multi-Token Predictionでは、次のtokenだけでなく、そのさらに先も予測対象にする。

#

例えば、

#

x_{t+1}

#

だけでなく、

#

x_{t+2}

#

x_{t+3}

#

まで予測するなら、

#

L_1=-\log p(x_{t+1})

#

L_2=-\log p(x_{t+2})

#

L_3=-\log p(x_{t+3})

#

を作り、

#

\boxed{ L = L_1+\lambda_2L_2+\lambda_3L_3 }

のように学習できる。

つまり質問を、

「次は何ですか？」

だけではなく、

「その次は？」

「さらにその次は？」

まで増やす。

Gloeckleらは2024年、共有Transformer trunkに複数のfuture-token prediction headを加えるMTPを報告した。13BモデルではHumanEvalで比較対象より12%多く問題を解き、4-token predictionを使ったモデルでは推論を最大3倍高速化できたと報告している。

#

MTPには二つの意味がある。

#

一つは学習信号を増やすこと。

#

もう一つは、モデル自身に未来tokenを予測する能力を持たせ、それを高速推論へ使えることである。

#

5．投機的デコード――未来を「仮置き」してまとめて答え合わせする

#

Speculative Decodingの考え方は非常に単純である。

#

通常の生成では、

#

t_1 \rightarrow t_2 \rightarrow t_3 \rightarrow t_4

#

と、大きなTarget Modelを毎回実行する。

#

そこで、小さなDraft ModelやMTP headなどに、

#

\hat t_1,\hat t_2,\hat t_3,\hat t_4

#

という未来候補を先に作らせる。

#

そして大きなTarget Modelへ、

#

「この4 token、本当に正しいかまとめて調べて」

#

と渡す。

#

例えば、

#

候補1 ✓ 候補2 ✓ 候補3 ✓ 候補4 ✗

#

なら、最初の3 tokenを一気に進められる。

#

LeviathanらのSpeculative DecodingではT5-XXLで2～3倍、ChenらのSpeculative SamplingではChinchilla 70Bで2～2.5倍のdecode高速化が報告され、適切なaccept/reject処理を行うことでTarget Model本来の出力分布を保てることが示された。

#

6．なぜ投機的デコードがGPUに効くのか

#

ここが今回の問題の中心である。

#

通常Decodeでは、

#

[1\times d]W

#

を行っている。

#

一方、例えば8 tokenの候補をTarget Modelでまとめて検証できれば、

#

[8\times d]W

#

に近い形になる。

#

つまり、

#

1\text{ position}\times W

#

だったものを、

#

8\text{ positions}\times W

#

にできる。

#

巨大なweight W をHBMから読み出したとき、そのweightで行う計算量を増やせる。

#

これは、

#

Decodeを小さなPrefillへ近づける

#

と考えると分かりやすい。

#

7．Arithmetic Intensityから見る

#

これを中学・高校数学程度の式で表してみよう。

#

GPUが行った計算量を F、memoryから移動したdata量を B とする。

#

すると、

#

AI=\frac{F}{B}

#

という値を考えられる。

#

Arithmetic Intensityである。

#

要するに、

#

1 byteをmemoryから持ってくる間に、何回計算できたか

#

である。

#

GPU性能は単純化すると、

#

\boxed{ P= \min \left( P_{\rm peak}, BW\times AI \right) }

#

と考えられる。

#

ここで、

#

P_{\rm peak}

#

はGPUそのものの最大演算性能、

#

BW

#

はmemory bandwidthである。

#

低batch Decodeでは AI が小さい。

#

そのため、

#

BW\times AI < P_{\rm peak}

#

となる。

#

GPUにはもっと計算能力があるのに、memory側が先に限界へ到達する。

#

では8 tokenまとめると

#

非常に単純化して、

#

AI_0=\frac{F}{B}

#

だったとする。

#

同じようなweight読み出しで8 positionを処理できれば、

#

AI_1 \approx \frac{8F}{B} = 8AI_0

#

へ近づけられる可能性がある。

#

もちろん現実にはKV CacheやAttention、draft cost、追加memory trafficがあるため8倍そのままにはならない。

#

しかし方向としては、

#

AI\uparrow

#

する。

#

つまりNVIDIA GPUの高速化は、

#

8TB/s\rightarrow80TB/s

#

と物理memory bandwidthを増やしているのではない。

#

\boxed{ \text{同じ8TB/sから取り出す有効仕事量を増やす} }

#

方向である。

#

8．投機的デコードの速度を簡単な式にする

#

通常のTarget Model 1回のDecode時間を、

#

T_{\rm target}

#

とする。

#

普通なら r token進むために、

#

rT_{\rm target}

#

程度必要になる。

#

投機的デコードでは、draft生成時間を、

#

T_{\rm draft}

#

複数tokenのまとめたverificationを、

#

T_{\rm verify}

#

平均して一度に採用されるtoken数を r とする。

#

すると非常に粗いspeedupは、

#

\boxed{ S \approx \frac{ rT_{\rm target} }{ T_{\rm draft}+T_{\rm verify} } }

#

と考えられる。

#

したがって重要なのは単に「未来をたくさん予測する」ことではない。

#

r

#

つまり平均何tokenが採用されるかが重要である。

#

32 token予測しても平均2 tokenしか採用されないなら、大量の無駄計算が発生する。

#

逆に、少ないcostで長い未来を高い確率で予測できれば非常に強い。

#

9．DeepSeek-V3はこの二つを実際につないだ

#

2024年末に発表されたDeepSeek-V3は671B total parameters、37B activated parametersのMoEモデルで、MTPをtraining objectiveとして採用した。

#

そしてDeepSeek-V3は、通常のnext tokenに加えてもう一つ先のtokenを予測し、その追加tokenのacceptance rateを85～90%と報告した。

#

これをspeculative decodingと組み合わせることで、

#

1.8\times

#

のtokens per secondを得たとしている。

#

ここでMTPが単なるtraining techniqueではなく、

#

\boxed{ MTP \rightarrow 未来候補 \rightarrow Speculative Decoding }

#

という推論高速化へ直接つながることが実証された。

#

10．Blackwellではさらに極端な結果も出始めている

#

2026年6月、NVIDIAはDFlashというspeculative decoding方式をBlackwell Ultra上で評価した。

#

DFlashではblock-diffusion drafterが複数候補tokenを1回で生成し、Target Modelが並列verificationする。

#

NVIDIAによればgpt-oss-120bでは、500～600 tokens/s/user程度のhigh-interactivity領域でautoregressive decodingに対し15倍超のthroughputを達成し、最も低いconcurrency、つまりbatch size 1でもinteractivityを2倍以上にした。

#

これは非常に重要である。

#

AstraがDFlashやMTPを使用していることを意味するわけではない。

#

しかし、

#

「HBMを使うNVIDIA GPUではsingle-stream高速推論は構造的に無理だ」

#

という単純な理解は、もはや正しくない。

#

アルゴリズム側から逐次Decodeを並列計算へ変換すれば、GPUの巨大なTensor Coreを再び利用できる。

#

11．ただし、これはAstra Ultrafastの公式説明ではない

#

ここで線を引く必要がある。

#

NVIDIAがGPT-6 Astra Ultrafastについて公式に説明しているのは、

#

Blackwell GPU上で動作していること、

#

Standard比最大8倍のtoken generation速度であること、

#

そしてOpenAIのモデルを使ってNVIDIA GPU上のinference softwareを改善していること、

#

である。

#

MTP、speculative decoding、具体的batch sizeは公開されていない。

#

したがって、

#

\text{Astra 8倍} = \text{MTP効果}

#

とは言えない。

#

ただし、DFlashやDeepSeek-V3などの結果を見る限り、

#

MTP／speculative decoding系の技術が、NVIDIA GPUの低batch推論性能を大きく引き上げ得る

#

こと自体はすでに示されている。

#

12．もう一つの鍵――GPU kernelそのものを改善する

#

そしてAstraの記事では、もう一つ極めて重要なことが書かれている。

#

OpenAIは自社の内部modelを利用して、

#

NVIDIA GPU上で動くinference softwareを最適化した

#

という。

#

OpenAI inference leadのPhilippe Tilletは、OpenAIのモデルがBlackwellやRubinをprogramする知識を持ち、その知識からhigh-performance kernelを生成できると説明している。

#

これはMTPとは別の高速化である。

#

13．Kernel optimizationとは何をしているのか

#

例えばTransformer内部に、

#

RMSNorm

#

Linear

#

RoPE

#

という処理が続いているとする。

#

単純な実装なら、

#

HBM → RMSNorm → HBM HBM → Linear → HBM HBM → RoPE → HBM

#

と中間結果を何度もHBMへ書き戻すことがある。

#

これを一つのkernelへ融合すれば、

#

HBM 　↓ RMSNorm 　↓ Linear 　↓ RoPE 　↓ HBM

#

にできる。

#

するとmemory trafficを B として、

#

B\downarrow

#

する。

#

Arithmetic Intensityは、

#

AI=\frac{F}{B}

#

だったので、

#

B\downarrow \Rightarrow AI\uparrow

#

である。

#

つまり投機的デコードは主に、

#

F/B

#

の分子側の有効仕事量を増やす。

#

Kernel fusionなどは、

#

F/B

#

の分母側、つまり不要なmemory movementを減らす。

#

両側から同じMemory Wallを攻撃できる。

#

14．これはAstraから突然始まった話ではない――DeepSeekから続く流れ

#

ここまで見ると、「AIがGPU softwareを改善する」という話がAstraで突然現れたように見える。

#

しかし実際にはその前史がある。

#

DeepSeek-V3では、モデルそのものだけでなく、NVIDIA H800上で効率よく学習するためのhardware-aware optimizationが徹底された。

#

DeepSeek-V3はFP8 training、DualPipeによるcomputation/communication overlap、MoE通信などを組み合わせ、full trainingを2.788M H800 GPU hoursで完了したと報告している。

#

ここで示されたのは、

#

\boxed{ \text{Model} \leftrightarrow \text{Hardware} }

#

を別々に設計するのではなく、一体として最適化する重要性だった。

#

2025年――今度はDeepSeek-R1自身にkernelを書かせた

#

そして2025年2月、NVIDIAはDeepSeek-R1を使ってGPU kernelを自動生成する実験を公開した。

#

構造は、

#

AI \rightarrow Kernel生成 \rightarrow H100で実行 \rightarrow Verifier \rightarrow AI

#

というclosed loopである。

#

NVIDIAによれば、このworkflowはKernelBenchでLevel 1の100%、Level 2の96%についてnumerically correctなkernelを生成した。

ここでDeepSeekは、

「GPU上で高速化されるAI」

から、

「GPUを高速化するcodeを書くAI」

#

へ役割を変えた。

#

2026年――AI kernel optimizationがさらに進む

#

2026年3月、PyTorchのKernelAgentは実GPUのperformance counterをfeedbackとして使い、

#

Profile \rightarrow Diagnose \rightarrow Optimize \rightarrow Benchmark

#

をmulti-agentで反復する仕組みを公開した。

#

100個のKernelBench L1 taskでは、以前の生成kernelよりgeometric meanで2.02倍、default torch.compile比で平均1.56倍高速化し、H100 hardware roofline efficiencyの89%へ到達した。

#

この流れを見ると、

#

\begin{array}{|l|l|l|}\text{時期}&\text{主体}&\text{何が起きたか}\cr\hline\text{2024–25}&\text{DeepSeek-V3 + 人間}&\text{model・precision・通信・GPU実装を一体最適化}\cr\hline\text{2025年2月}&\text{NVIDIA + DeepSeek-R1}&\text{AIがGPU kernelを生成し実GPUで検証}\cr\hline\text{2026年3月}&\text{KernelAgent}&\text{hardware counterをAIへfeedbackし継続最適化}\cr\hline\text{2026年6月}&\text{DFlash}&\text{Blackwell上でspeculative decodingを大幅高速化}\cr\hline\text{2026年10月}&\text{OpenAI + NVIDIA}&\text{OpenAI内部modelでproduction inference softwareを継続改善}\cr\hline\end{array}

#

つまりAstra Ultrafastは、

#

\boxed{ Human\ Optimization \rightarrow AI\text{-}Assisted\ Optimization \rightarrow AI\text{-}Driven\ Continuous\ Optimization }

#

という流れの延長線上に置くことができる。

#

ただしOpenAIがDeepSeek-R1やKernelAgentの具体的手法を採用したという意味ではない。

#

重要なのは、複数の研究が同じ方向へ収束していることである。

#

15．NVIDIA GPUには「眠っている性能」があるのか

#

ここで最初の問いへ戻る。

#

GPUにはまだ性能が残っているのだろうか。

#

答えは、

#

物理ピーク性能そのものが隠れているわけではないが、実ワークロードから取り出せていない性能は存在する

#

となる。

#

GPUのphysical peak performanceを、

#

P_{\rm hardware}

#

とする。

#

実際に利用できる割合を、

#

\eta

#

とすると、

#

\boxed{ P_{\rm effective} = P_{\rm hardware}\eta }

#

である。

#

例えば、

#

P_{\rm hardware}=100

#

でも、

#

\eta=0.4

#

なら、

#

P_{\rm effective}=40

#

しか使えていない。

#

AI kernel optimizationによって、

#

\eta=0.4 \rightarrow0.7

#

になれば、

#

\frac{0.7}{0.4} = 1.75

#

倍である。

#

GPUを1枚も追加していないのに、実効性能は75%増える。

#

16．実際には「効率の掛け算」より時間で考えた方がよい

#

推論時間を単純化すると、

#

T_{\rm total} \approx T_{\rm compute} + T_{\rm memory} + T_{\rm communication} + T_{\rm scheduling} + T_{\rm overhead}

#

となる。

#

ただしcomputeとcommunicationを重ねられる場合などがあるので、現実は単純な足し算ではない。

#

それでも考え方としては有用である。

#

AIによるkernel生成なら、

#

T_{\rm compute}\downarrow

#

kernel fusionなら、

#

T_{\rm memory}\downarrow

#

MoEの配置改善なら、

#

T_{\rm communication}\downarrow

#

Serving Agentなら、

#

T_{\rm scheduling}\downarrow

#

CUDA Graphやkernel fusionなら、

#

T_{\rm overhead}\downarrow

#

させられる。

#

性能は、

#

P = \frac{\text{Useful Work}} {T_{\rm total}}

#

なので、これらを少しずつ削るだけでも全体では大きな差になる。

#

17．さらに重要なのは「GPUの仕事そのものを消す」こと

#

software optimizationには二種類ある。

#

一つは、

#

\eta\uparrow

#

つまり同じ仕事をGPUに効率よくやらせること。

#

もう一つは、

#

F_{\rm required}\downarrow

#

つまり必要な計算そのものを減らすことである。

#

これはさらに強力である。

#

KV Cache reuse

#

例えばAgentが毎回ほぼ同じ100,000 tokenを入力するとする。

#

全部再Prefillするなら毎回、

#

F_{100k}

#

の仕事が必要になる。

#

しかし98,000 token分のKV Cacheをreuseできれば、新規2,000 tokenだけ処理すればよい。

#

reuse率を r とすれば、

#

F_{\rm new} \approx (1-r)F_{\rm old}

#

である。

#

例えば、

#

r=0.9

#

なら、

#

F_{\rm new}=0.1F_{\rm old}

となる。

GPUそのものは1%も速くなっていない。

しかしGPUへ与える仕事を90%消せた。

18．有効性能はこう書ける

#

この二つを一つにまとめると、

#

\boxed{ P_{\rm useful} \propto \frac{ P_{\rm hardware} \eta_{\rm software} }{ F_{\rm required} } }

#

と考えられる。

#

AIは、

#

\eta_{\rm software}\uparrow

#

させる。

#

同時に、

#

F_{\rm required}\downarrow

#

もできる。

#

このため、GPUそのもののphysical FLOPSの増加以上に、ユーザーから見たtask throughputが改善することがある。

#

19．「GPUの性能は固定」という考え方が変わる

#

従来ならGPUを購入した瞬間、

#

P_{\rm GPU} = constant

#

に近いものとして考えられた。

#

もちろんCUDAやdriver、TensorRTの改善は以前から存在した。

#

しかしAIがこの改善loopに入り始めると、

#

P_{\rm effective}(t)

#

として考える意味が大きくなる。

#

同じBlackwellでも、

#

P_{\rm effective}(2026) < P_{\rm effective}(2027)

#

となる可能性がある。

#

物理GPUを交換していないのにである。

#

20．AIがAI infrastructureを改善するfeedback loop

#

AIの最適化能力を、

#

A_t

#

GPUの実効性能を、

#

C_t

#

とする。

#

AIによってsoftwareが改善されるなら、

#

C_{t+1} = C_t+f(A_t)

#

と表せる。

#

そして増えたcomputeによりAI開発が加速するなら、

#

A_{t+1} = A_t+g(C_{t+1})

#

となる。

#

合わせると、

#

\boxed{ AI \rightarrow GPU Software改善 \rightarrow Effective Compute増加 \rightarrow より強いAI \rightarrow さらにSoftware改善 }

#

というfeedback loopになる。

#

これは「AIが突然自分自身を書き換える」といった意味での強い再帰的自己改善とは違う。

#

もっと現実的な、

#

AI infrastructure engineeringの自動化による反復改善

#

である。

#

21．ただし、永遠に速くなるわけではない

#

software efficiencyを、

#

\eta_t

#

とし、

#

0<\eta_t\le1

#

とする。

#

簡単なtoy modelとして、

#

\eta_{t+1} = \eta_t+ \alpha A_t(1-\eta_t)

#

と書ける。

#

ここで、

#

1-\eta_t

#

は「まだ引き出されていないhardware性能」である。

#

η が小さいうちは改善余地が大きい。

#

しかし、

#

\eta\rightarrow1

#

へ近づけば、

#

1-\eta\rightarrow0

#

なので、同じhardwareからさらに引き出す余地は減っていく。

#

HBM bandwidth、Tensor Core FLOPS、NVLink、電力、冷却という物理上限は消えない。

#

22．しかしAlgorithm側には別の改善軸が残る

#

ここが重要である。

#

hardware utilizationが、

#

\eta\rightarrow1

#

になっても、

#

F_{\rm required}

#

を減らすことはできる。

#

MTP。

#

Speculative Decoding。

Sparse Attention。

KV Cache reuse。

MoE。

Quantization。

Early Exit。

Cache。

これらは、

同じ答えを得るための計算量そのもの

#

を変える。

#

したがって将来的なAI性能を考えると、

#

\text{PFLOPS}

#

だけを見るのではなく、

#

\boxed{ \frac{ \text{Useful tokens / completed tasks} }{ \text{GPU-second} } }

#

を見る必要が出てくる。

#

23．これからNVIDIA GPUでさらに性能が引き出されそうな場所

#

次の改善余地はkernelだけではない。

#

まずMoEでは、tokenがどのExpertへ行くかによってGPU間通信量が変わる。

#

将来的なRouterは、

#

Score_i = Quality_i -\lambda_1Latency_i -\lambda_2Communication_i -\lambda_3Congestion_i

#

のように、意味的に最適なExpertだけでなく、network topologyや現在のGPU負荷まで考えてroutingする可能性がある。

#

Speculative decodingでもdraft lengthを固定する必要はない。

#

k^* = f( context, acceptance, GPUload, latency )

#

として、AIがその瞬間に最適な未来token数を選ぶことが考えられる。

#

KV Cacheについても、

#

P(\mathrm{reuse}\mid context)

#

を予測し、再利用されそうなKVはHBM、可能性が低いものはCPU memoryやSSDへ移動するAI memory managerへ進める。

#

さらにPrefillとDecodeは計算特性が異なるため、cluster schedulerが両者を別GPU poolへ配置する可能性もある。

#

最後には、

#

\text{Model Architecture} + \text{Precision} + \text{Kernel} + \text{GPU Placement} + \text{Serving}

#

全体を一つのoptimization problemとしてAIが探索することになる。

#

24．NVIDIAにとって「programmability」が以前より大きな武器になる

#

これはNVIDIAにとって非常に重要である。

#

CerebrasやGroqは、Memory Wallをhardware architectureそのもので解決する。

#

一方GPUはprogrammableである。

#

これまでそのprogrammabilityを引き出す主体は、人間のCUDA engineerだった。

#

これからAIがGPU programming能力を持つなら、

#

\boxed{ Programmable\ Hardware \times AI\ Programmer }

#

という組み合わせになる。

#

GPUが専用ASICより汎用的であることは、以前なら効率上の弱点でもあった。

#

しかしAI自身がworkloadごとにkernel、layout、precision、schedulingを作り直せるようになるなら、そのprogrammabilityが逆に大きな資産になる。

#

Astraの記事の重要性は、ここにある。

#

25．ではCerebrasやGroqの優位は消えるのか

#

そう単純ではない。

#

Cerebrasの21PB/s SRAM、Groqの80TB/s on-chip SRAMという物理的なbandwidth優位が消えたわけではない。

#

GPU softwareをどれだけ改善しても、

#

8TB/s

#

のHBMを、

#

21PB/s

#

の物理memoryへ変えることはできない。

#

したがってbatch=1、極端なlow latencyなどでは、専用architectureが依然として大きな構造的強みを持ち得る。

#

一方GPUは、training、post-training、RL、inferenceを同じprogrammable infrastructureで扱える。

#

NVIDIA自身もAstraの記事で、このflexibilityを強調している。

#

したがって競争は、

#

\text{SRAMによる物理的Memory Wall解決}

#

対、

#

\text{HBM GPU + algorithm + softwareによるMemory Wall迂回}

#

という構図に近い。

#

そして両方とも今後さらに進歩する。

#

26．今回の「最大8倍」で本当に重要なこと

#

GPT-6 Astra Ultrafastの最大8倍という数字だけを見ると、

「Blackwellが8倍速い」

ように見えるかもしれない。

しかし実際にはそうではない。

NVIDIAの説明は、

\boxed{ Hardware \times Model \times Kernel \times Inference\ Software }

#

というsystem-level optimizationの話である。

#

そしてOpenAI公式のUltrafast API guidanceでは、agentic workloadではWebSocket接続まで推奨している。

#

モデル生成が高速になると、今度はHTTP接続などのnetwork overheadすら相対的に大きくなってくるからである。

#

つまり性能改善はGPU kernelだけでは終わらない。

#

一つのbottleneckを除くと、次のbottleneckが現れる。

#

AIにとっては、そこが新たなoptimization targetになる。

#

27．結論――GPUはCerebrasになったのではない。GPUの使い方そのものが変わり始めた

#

NVIDIA GPUが突然Cerebrasになったわけではない。

#

巨大SRAMが追加されたわけでもない。

#

HBM bandwidthが数十倍になったわけでもない。

変わり始めているのは、

GPUへ仕事を与える方法

である。

通常のDecodeでは、

[1\times d]W

#

だった。

#

Speculative Decodingなら、

#

[k\times d]W

#

へ近づけられる。

#

Kernel fusionなら、

#

B_{\rm memory}\downarrow

#

できる。

#

KV reuseなら、

#

F_{\rm required}\downarrow

#

できる。

#

AI kernel optimizerなら、

#

\eta_{\rm hardware}\uparrow

#

できる。

#

そしてAI schedulerなら、GPU cluster全体のidle timeやcommunicationを減らせる。

#

最終的には、

#

\boxed{ P_{\rm useful} \propto \frac{ P_{\rm hardware} \cdot \eta_{\rm software} \cdot \eta_{\rm system} }{ F_{\rm required} } }

#

という構造になる。

#

これまでAI infrastructureのスケーリングというと、

#

GPU\text{台数}\uparrow

#

あるいは、

#

GPU\text{世代}\uparrow

#

が中心だった。

#

これからはそこへ、

#

Software\ Efficiency\uparrow

#

Algorithmic\ Efficiency\uparrow

#

が加わる。

#

しかも、その改善主体にもAI自身が入る。

#

DeepSeek-V3で、人間がNVIDIA GPUの低レイヤーまで掘り下げて性能を引き出した。

#

DeepSeek-R1では、そのkernel探索の一部をAI自身が行った。

#

KernelAgentでは、実GPUのhardware counterを見ながらAIが反復的に性能を改善するようになった。

#

DFlashでは、GPUが不得意だった逐次Decodeそのものを並列化し、Blackwellの眠っていた演算能力を使える可能性が示された。

#

そしてAstra Ultrafastでは、OpenAIのfrontier modelがproduction inference softwareの改善に利用され始めている。

#

この流れを見ると、今回の最大8倍という数字以上に重要なのは、

#

\boxed{ AIがAIを実行する計算基盤そのものを改善し始めた }

#

ということなのかもしれない。

#

これまでGPUは、製造された瞬間にその性能がおおむね決まるhardwareだった。

#

これからは同じBlackwellでも、

#

P_{\rm effective}(2026) < P_{\rm effective}(2027)

#

となる可能性がある。

#

新しいGPUを追加していないにもかかわらずである。

#

そう考えると、NVIDIA GPUに「隠された謎の性能」が存在するというよりも、

#

理論性能と、現実のAI workloadから人間が引き出せていた性能との間に、まだ大きな未利用領域が残っていた

#

と表現する方が正確だろう。

#

そして現在、その領域を探索する主体が人間だけではなくなりつつある。

AIがkernelを書く。

AIがprofileを見る。

AIがmemoryを配置する。

AIが投機長を決める。

AIがMoE Expertを配置する。

AIがclusterをscheduleする。

#

そしていずれ、

#

次のAIが最も効率よく動くmodel architectureそのものを、AIがhardwareと一緒に設計する。

#

GPUの次の性能向上は、必ずしも次のGPU世代を待って起こるとは限らない。

#

すでに設置されているGPUの中から、AI自身がまだ使われていなかった性能を掘り出していく。

#

GPT-6 Astra Ultrafastは、その変化が研究室の実験ではなく、実際のfrontier AI servingへ入り始めた一つの象徴として見ることができる。

#