EP 112
AI半導体の中で起きていること KV cacheからrooflineまで
AIインフラへ移る価値獲得 0:00
ロ・ジョンソク 今日、収録をしているのは2026年8月30日日曜日の朝です。今日はHyperAccelのイ・ジンウォンCTOをお迎えしました。最近、私たちはニュースが本当に多いですよね。ところで、そのニュースを少し配置してみると、下のデータセンターからチップ、モデル、そしてその上のアプリケーションまでさまざまなレイヤーがありますが、最近感じるのは、モデル側の進化があまりにも急速に起きているため、いわゆる価値の捕捉というものですね。実際にお金を稼ぐ領域が下のインフラ側へ移ること、そして上のよりアプリケーション側へ移ること、この二つのトレンドを私たちは感じています。今日は非常に重要な話をお招きして講義として伺うことになります。下の方についての話です。私たちはいったい電力を投入してチップを構成し、その中にtrainingされたモデルを入れて顧客に膨大なinferenceを提供しているわけです。その中で何が起きているのか、そしてその中のベンチマークを読むためには何を理解すべきか、私たちはスンジュンさんと一緒にこの浅い知識を持って少し前にDwarkeshのroofline analysisをしながらinferenceの話を一度扱い、その後もinferenceの話を非常に頻繁にしています。頻繁にしている理由はそれが非常に重要だからでしょう。今日はその究極の講義エディションです。イ・ジンウォンCTOの講演をじっくりついてきていただければSemiAnalysisから新たに出てくる各種ベンチマーク、そしてNVIDIAが発表するもの、またチップ会社が発表するものを理解できるようになりますから。今日はお招きして、一度聞いてみましょう。CTO、お越しいただきありがとうございます。
イ・ジンウォン こんにちは。お会いできてうれしいです。久しぶりにまた出演しました。
ロ・ジョンソク 今日の内容は本当に深くて広範です。ですから、どれだけ時間がかかっても私たちにじっくり教えていただけたらと思います。よろしくお願いいたします。
チェ・スンジュン Dwarkeshの話をしたのは5月ではありませんでしたか？ もう
ロ・ジョンソク 3か月ほど経ちましたが、その間にもAI世界の3か月ですから、3年経ったと見なすべきでしょう。
終わりなきcompute不足と爆発するトークン需要 2:13
イ・ジンウォン 始めてみましょうか？今日私がお話しする内容はinference engineeringに関する話です。今、皆さんもAIを非常にたくさん使っていらっしゃると思いますが、いったい主に使われるGPUあるいは他のAI半導体でどんなことが起きているのかを難しい内容ではありますが、私ができるだけ分かりやすく今日ご説明します。私たちの会社に関する話をまず前半でしてから、本格的に始めてみましょう。これは今年4月にSam AltmanがOpenAI Forumで話していた内容を持ってきたものですが、ここを見るとcompute crunchといって、computeが非常に不足している世界に生きていますが、そこからいつ抜け出せるのか、こういう話をOpenAIの人たちと何年もしてきたが、今の考えではおそらくこれから私たちは永遠にこれを抜け出せないだろう。つまり私たちは常にcomputeが足りない世界に生きるだろうと話しています。それほどtrainingであれinferenceであれcomputeが不足している状況です。
それをよく示しているのが5月のGoogle I/Oで発表された内容ですが、自社のGCPでトークン使用量を調べたところ、月間使用量が12か月で50倍に増えたと発表しました。そして私は昨年9月にAI Infrastructure Summitというところへ行きましたが、その時Googleがまた出てきて発表したのは、そこから2か月で再び2倍に増え、14か月で100倍になったという話でした。そして今はどうなったのか？そこからまた大幅に増えて、最初の2024年と比べて約330倍となり、莫大な爆発的需要があるという話を続けています。モデルも皆さんよくご存じのとおり、成長し続けています。ここに出ているものには非公式な推定もあり、最近Fable 5が8Tパラメータ程度だという話も聞きましたが、しばらくモデルがあまり大きくならないように、数Tパラメータ以上には大きくならないように見えていましたが、Mythosは10Tパラメータだという話もあるほど、モデルのスケールも再び大きくなっています。
そしてこれを処理するために世界中でデータセンターを大量に建設しています。GWデータセンターといって、ここを見ると右側に2030年までデータセンターへ約6.7兆ドル程度、これをざっくり日本円で換算するとほぼ1,000兆円ほどになりそうですが。そして韓国も今、4大メガプロジェクトとして2035年までに18.4GW規模で韓国の土地にデータセンターを建設するとしています。このようになると、皆さんがよくおっしゃるとおり電力が問題です。電力をどう供給するのかという話を誰もがしています。ここを見ると、米国でデータセンターを建設してそこに電力が供給されるまでに平均で約5年かかるそうです。そして韓国の首都圏でデータセンターの電力審査をすると半数以上が審査に落ちるという話がずっと出ています。ですから電力が非常に大きな問題で、もう一つは、これもDwarkeshポッドキャストで出ていた話ですが、Anthropicは今、3年連続で売上を10倍ずつ成長させる企業になっていますが、このフロンティア・ラボではcompute、つまり演算を年間3倍ずつ増やしています。
売上とcomputeの格差が押し上げるinference単価 5:17
イ・ジンウォン そうすると年間3.3倍ずつ差が開くことになります。ではGPU computeは3倍ずつ増えているのに売上は10倍増えるこの差をどう解釈するかというと、三つの方法があります。一つ目はinferenceの際にマージンを上げて売上を増やす方法があるでしょう。しかし今すでにAnthropicのinferenceのマージンは70～80%だと知られており、その上限が90%だとすればほとんど上げる余地は残っていません。そして二つ目は、GPUを100個、100台持っているとするとそのうち今は70台をtrainingに使い30台をサービスに使っているなら、その比率を5対5にしてinferenceに使うGPUの比率を増やせばそこで売上が発生するので、同じcomputeで売上を上げる方法になるでしょう。しかし今はおおよそ5対5程度だと知られていて、これをさらに増やすのは難しいと多くの人が話しています。なぜならtrainingに使う比率を減らすということはモデル開発に注力しないということであり、そうなると今のこのフロンティア・ラボは生き残るのが難しい状況だからです。ですからこれも大きく増やすのは難しい状況です。では残るものは何かというと、結局computeの単価が上がることしかありません。ですから今neocloud企業やこうした企業でも非常に収益が出ており、短期で借りるなら長期賃貸より2倍以上高く払わなければならず、このように実質的にcomputeの単価も大きく上がっている傾向です。
HBMではなくLPDDRを選んだHyperAccel Berthaチップ 7:17
イ・ジンウォン ではなぜ先にこうした背景を説明したかというと、私たちが作るチップはBerthaというチップです。これは私たちにとって最初の、私たちの会社が作った最初のデータセンター向けAI半導体であり、私たちの製品の特徴は、皆が使っているHBMを使わず、LPDDRという低消費電力DDRメモリを使用していることです。そのため、これによって得られるのは消費電力もHBMを使うチップに比べて少なくできることです。そして何よりHBMは非常に高価で入手も難しいですが、私たちはDDRを使うため非常に低価格で供給できます。ですから皆さんが使うAIサービスのコストを画期的に下げられるそうした製品を企画して作りました。現在Samsung 4nmプロセスで製造しており、今年3月末にこのチップが出てきて私たちは今、一生懸命bring-upをしています。
bring-upとは、チップにソフトウェアを載せてサービス可能なレベルに仕上げる作業を指します。私たちは先週開催されたHot Chipsでデモを行いましたが、もう少し補完して1～2か月以内に市場へPoC目的で多く投入する計画です。ですから私たちのチップは非常に安価で低消費電力のチップだと覚えていただければと思います。
LPDDRで確保したbandwidthと目標価格5,000ドル 8:42
パク・ジョンヒョン LPDDRを使用したとおっしゃいましたが、HBMを多く使う理由はmemory bandwidthが重要で、memory bandwidthをLPDDRで増やすのが難しいからですよね。ではLPDDRを使ってもmemory bandwidthを増やせる何らかの方法が入っていたり、ほかに何かが適用されているのでしょうか？
イ・ジンウォン こちらのPCIeカードを見るとLPDDRメモリです。これが合計4個ずつ、8個付いているのが見えると思いますが、私たちはまず一つ目にDDRを非常に多く搭載しました。これほど多く搭載したチップは、世界にいくつもありません。NVIDIAや、以前Metaが作ったチップくらいです。ですからDDRを多く搭載してbandwidthをある程度確保しました。
もう一つ、最も重要なのは私たちの会社のアーキテクチャには、ここでbandwidthをほぼ90%以上活用できる内部アーキテクチャがあることです。つまり私たちのbandwidthは現在546GB/sとなっていますが、H100のようなGPUは3TB/s程度です。するとおよそ6分の1程度ですが、実際にはそれは理論上の数値であり、実際にあるAI workloadを載せて動かしたときこのbandwidthの実際の使用率がどれほどかをutilizationで測ってみると、まったく最適化しなければ約50%で、一生懸命最適化すれば70%まで上げられますが、私たちには90%以上出せるアーキテクチャがあるので、そこである程度克服できます。
ではどれほど安いのかというと、今私たちが目標としている価格は約5千ドルなのでGPU価格と比べてみると非常に安価だということが分かります。日本円で100万円に満たない価格です。そしてメモリ容量もDDRを使っているためチップ当たり192GBを搭載しており大きなモデルを少ないチップ数でservingできるという利点もあります。
ロ・ジョンソク 先ほども背景についてずっとお話ししましたが需要が絶えず増え続けているためこのような形のチップを作ることはこれからもしばらくは意義がありそうですね。
イ・ジンウォン 需要が増えていることもあってアプリケーションの要件も非常に多様なのでbandwidthは結局後ほどまたお話ししますが速度に直結するんです。bandwidthが低いと速度が少し遅くなることがありますが速度がそれほど重要ではないアプリケーションも非常に多くあるのでそういった市場にも、私たちはコストが安いためよく合うだろうと考えています。
ロ・ジョンソク 私たちがChatGPTと作業するときほとんどの時間は文章を読んで待つことに使われるのでそうした非効率がこのinference市場にそのまま積み重なるわけですよね。
LPUという名称の由来とOpenAI Jalapeño 11:29
チェ・スンジュン LPUとは何ですか？これは単独で使えるものですか？それとも、より大きなものの部品として組み込まれるものですか？
イ・ジンウォン 偶然にもNVIDIAが買収したGroqもLPUという名前を使っていて私たちもLPUという名前を使っていますが実は私たちのほうがLPUという名前をずっと先に使っていました。Groqはもともと最初はTSP、Tensor Streaming Processorという名前でしたが後にLPUという名前に変えました。ただ、GroqのLPUのほうが有名なのでよく質問されるのですが、LPUとは何か、また新しい種類のNPUのようなものなのかと尋ねられますが、これは単なる名前です。大きな意味では、すべて同じNPUの一つで私たちは単独で動作できます。GPUもPCIeカードの形で出ている製品があるでしょう。それと同じだと考えていただければいいです。
それで、最近のニュースを一つもう一つお話しすると、先ほど私が申し上げたHot ChipsというところでOpenAIがJalapeñoというとても面白い名前を付けたAI半導体、自社で製作したAI半導体を公開しました。HBM4も使っていました。今、HBM4を使うGPUもRubinになってようやくNVIDIAがHBM4を使っています。現在のBlackwellシリーズはすべてHBM3Eですが、そのため最先端のメモリ技術を使っていて少しユニークな点はOpenAIのJalapeñoアーキテクチャと私たちのBerthaという、先ほどご紹介した製品のアーキテクチャが非常によく似ています。
それで私たちがHot Chipsでデモをするとき多くの方が来られて君たちはOpenAIのアーキテクチャととても似ているようだ、という話をたくさんしてくださいました。私たちもそう強く感じました。少しご説明すると、このようにHBMがあり私たちも横にDDRがありますが、ここから来るデータをここに隣接しているcoreですぐ受け取って演算する構造になっていてその演算結果を中にあるcore同士でこのように共有する構造も私たちとJalapeñoは非常によく似ていて私もまったく別の場所で別の時期に開発したのですがこんなに似ることもあるのだなと、面白く思っています。
ロ・ジョンソク OpenAIから連絡が来るかもしれませんね。Hot Chipsは最近Stanfordで開催されたカンファレンスですよね？
イ・ジンウォン 毎年Stanfordで開催されます。面白いのは、カンファレンスというととても大きなコンベンションセンターのような場所でトラックも複数に分けて進行するでしょう。Hot Chipsは非常に歴史のある学会ですがちょうどStanford Universityの一棟、講堂のような一つの空間でトラックも分けずに2日間開催されます。AI半導体業界の有名な企業はすべて来ます。NVIDIAはもちろん、AMD、Intelを含めてOpenAIも今回参加しました。そのため非常に多くの企業が参加する学会です。
パク・ジョンヒョン 行って来られましたか？
イ・ジンウォン 私はbring-upで忙しくて行けず私たちの会社の代表とエンジニアたちが行って来ました。
パク・ジョンヒョン Xで見たのですが、Hot Chipsでgpt-oss2Tパラメータのモデルが流出したとそんな話を見ました。
イ・ジンウォン 私もそれはインターネットで見ただけで実際には確認できていません。
パク・ジョンヒョン ひとまずルーマーだということで理解しておきます。
LLM inferenceの2段階となるprefillとdecode 15:01
イ・ジンウォン では本格的に始めてみましょう。まず最初にLLM inferenceがどのように行われるかから簡単に見ていくと、ユーザーが入力するpromptですね。それが入力として入ると、例えば、ここで今”Is tomato a fruit?”と質問したとすると、このLLMが動作して一生懸命演算した後に”Yes”という最初のtokenを出力します。それでユーザーがこれを便宜上4つのtokenだとします。1つの単語をtokenに置き換えて4つのtokenを入力として与えたときその4つのtokenを一度に演算して最初の次のtokenである”Yes”を出力するまでのこの過程を prefill と呼びます。
その後は、これが autoregressive に繰り返し動作しながら次に “Yes” が入力として入ると再び LLM が一度計算して次の “it” という token を出力しその次には “it” が入って “is” が出て”is” が入って、もし end-of-sentence というEOS、文が終わったという token が出るとこの iteration は終了します。そこで、ここで赤く表示された、このように一つの token が入って次に一つの token が出る過程をdecode phase と呼びます。つまり、この LLM が inference する過程は prefill と decode、この二段階に分かれています。
ロ・ジョンソク Prefill はこれは4つの token とおっしゃいましたが実際にはそこに1,000個、2,000個の token が入ることもありますし私たちが本を一冊投入すればその本一冊をすべて見ることもできますが、実際これは GPU がたった一度の並列演算によって一度に計算できるものなのでGPU の利点を非常によく生かせるわけですよね。前にある一つの単語が処理されてから後ろの単語が出せる構造なのでそのときは本当に一文字ずつしか処理されないためこれは少し遅いんです。
イ・ジンウォン 今日話そうとしている核心の一つです。
ロ・ジョンソク Prefill と decode に分かれている。つまり prefill は複数の単語が一度に入ってGPU が一度に計算するものですが、後から一文字ずつ出すのはdecode の過程で、これは非常に sequential です。この二つの workload を最適化することがinference では重要ですが、それが一体なぜこのような形なのかをイ・ジンウォンCTOが私たちに一つ一つ教えてくださる予定です。気を引き締めて、今日の授業についていかなければなりません。
チェ・スンジュン 私にも質問が一つあります。ソクヒョン代表のときにも出てきましたが、TTFT、つまり time to first token が青色と赤色の間に
イ・ジンウォン ある、ということで合っています。この黒い入力が入って “Yes” が出るまでの時間が TTFT、time to first token です。その次に “Yes” が入って”it” が出る、この decode の一 iteration をTBT ともいい、time between tokens ともいいTPOT ともいいます。Time per output token ともいい、いくつかの用語が少しずつ異なります。意味はほんの少し違いますが混用しても大きな問題はありません。では LLM iteration の中に一体何があるのか見てみましょう。この中には Transformer というアルゴリズムがありますが、もう一度まとめると上から下へ進む方向です。最初に token が入ると最近は position embedding も内部で行いますが、RoPE を行います。それが attention の中に入っていますが、とにかく token が入ると重要なのは、私が色を付けた attention というものを行いその次に feed-forward network、FFN と呼ばれるものを通過して再びこれを繰り返した後一番最後に LM head というところへ行き次の token が何かを選定します。ところがここにはモデルの、たとえば私たちが 100B のモデルだとするとそのモデルの parameter が存在しますが、その parameter が attention と feed-forward network にどの程度の比率で存在するかを見るとattention が約20%、そして FFN が約80%です。つまり4対1程度でFFN のほうがより多くの parameter を持っているわけです。ただしこれは dense model、私たちが MoE と呼ぶ最近よく使われるモデルではない場合にそうであり、MoE モデルになるとこの比率は FFN 側がはるかに多くなります。つまり parameter は attention には思ったほど多くない。私たちが Transformer と聞くとattention が核心だと考えますが、核心であることは確かです。しかし Transformer で最も重要な演算はこの二つだと見ることができます。
Transformerの中核演算attentionとFFN 17:57
イ・ジンウォン そこでそれをもう少し見ていきますが、それを見る前に、一体私たちがこの Transformer に入力するものと出力されるものの次元を見る必要があります。次元は3次元です。一つ目の次元は batch、複数の request が来たとき、それを同時に処理する際のbatch です。次は token の数です。つまり先ほど私が “Is tomato a fruit?” と尋ねたとき4つの token がありましたよね。その4つの token、そして一つの token を何次元の vector で表現するか、それに対する3次元の入力が入り出力も実は3次元ですが、先ほどご覧になったように prefill ではユーザーが何語、何 token の入力を与えるか分かりません。最大100万 token まで与えられるようになっています。そのためこれは1より大きくなりますが結果として出るのは一つの token だけなのでここは1になります。そこでこの1を消して見ると実質的に2次元と見ることができます。そして decode では常に一つの token が入って一つの token が出る構造なのでbatch を考えない場合この prefill の出力と同じ形のデータが動き回っていると理解していただければよいと思います。
ロ・ジョンソク 私たちがPyTorchでいつも使っていたbatch、その次にnum_tokensがsequence lengthで、token dimensionがTransformer embeddingのdimensionなんですよね？
チェ・スンジュン そうです。これが少し混乱します。このtokenは最初はIDで、整数や自然数だったのに、これから話すとvectorなんですよね、ここでは？
イ・ジンウォン それがここでtoken dimensionのvectorに変わる、もともとここがscalarだったものがvectorに変わるんです。なのでattentionの中を見るとQuery、Key、Valueというものがあって、先ほど入力として入ってきたtoken一つごとにここで仮にembeddingの次元を10次元だとすると、10個の数字で単語一つを表現し、token一つを表現するわけです。そのtoken embedding vectorを持ってきて、ここにあるweight parameter、これがmodel parameterですね。それらをそれぞれ掛けて行列演算をするんです。それでQuery、Key、Valueを作ります。するとここで疑問が生じるのが、入力は3次元なのに、これは2次元なんです。これをどう掛けるのかと思われるかもしれませんが、簡単に言うとB×Sをただflattenして、例えばここでBが5で、sequenceが2、Dが10だとしたら、5×2×10を最初の二つを掛けて10、10×10の行列にしてから演算すると考えると分かりやすいと思います。それでこれを掛けてQKVを生成し、その次にQuery、Key、Value同士で演算します。まずQueryとKeyの内積を取ってから行列積を取り、softmaxというものを適用した後、もう一度Valueを掛けて演算するのですが、これをself-attentionと呼びます。
QKV演算とself-attention構造 20:50
イ・ジンウォン ところがこれを複数のheadに分けて、同じ演算を、つまりここで生成されたQKVをすべて切り分けて、headが16個なら16個に分けた後、その分けられたもの同士でself-attentionをして、後で再び一つにまとめるのですが、それをhead mergeといいます。なのでmergeするときは、この結果をすべてconcatenationしてつなげた後、またここにあるweight parameterを一度掛けて、結果を出すことになります。するとこの結果がその後のさまざまな演算、residual connectionのようなものを経て、FFNへ進みます。FFNは大まかに見ると、二つのlinear layerでできています。ただweightを二回掛けるわけです。もちろんここにはgateというものが最近では追加されて少し複雑になりましたが、二層のneural netがあると考えていただければよいと思います。つまりここには演算のためのparameterが多く入っているということです。
これを概念的に考えてみると、attentionというのはこれらをすべてQuery、Key、Valueにしてから、例えばこれのQueryと、これらのKey、これのKey、すべてのKeyとvector内積を取るんです。それが行列積として表されるわけで、なのでattentionはtoken同士の関係を学習するものだと考えればよく、FFNに入ると、先ほど私が一つのtokenをいくつの数字で表現するか、10個だとしたら10次元のvectorで表現すると言いましたよね。その10次元のvectorを構成する数字同士で演算するのがFFN側です。つまりtoken間の演算はattentionで、token一つの中でそのvectorの次元同士を演算するのがFFNだと考えていただければよいと思います。
これは偶然にも昔のCNNの時代を見ると、depthwise convolutionというものがありましたが、それもまったく同じ形になっています。一度は空間方向、横縦方向に演算して、一度はchannel方向だけで演算するようになっています。なのでそれと完全に同じ構造だと考えればよく、これがtransformerがよりgeneralなアーキテクチャを持っているといえる部分です。
CNNはdepthwise convolutionという似た概念ではありますが、空間方向を見るとき、このように3×3など決められた領域だけを見ていたのに対し、attentionは最初のtokenから最後のtokenまで、後ろ側は見ませんが、最後のtokenが最初のtokenまで全部見て、何かをするので、globalにすべて見るので、少しよりgeneralなモデルなんです。私のようなscalingistたちが信じている、よりgeneralなalgorithmでscaleを大きくすると性能が良くなることを示す代表的な事例ともいえるでしょう。
パク・ジョンヒョン これをご覧の方のために申し上げると、行列演算というのは次元が大きくなると、頭の中にすぐには入ってこないかもしれないので、3Blue1Brownチャンネルに行くと、これを3Dグラフィックでとてもきれいに描いてある動画があるんです。なので、もう少し深く今話したことを追いたい方は、そちらを参考にするととても役に立つと思います。
チェ・スンジュン gateだけ知らなくていいというわけではなく、これを全部知る必要はないですよね、実際？
イ・ジンウォン ただこういうものがあるんだと思っていただければいいです。
ロ・ジョンソク はい、実際これが一つのstepですよね。このtransformerの論文を理解して、この中のdimensionがどう動くのか、PyTorchコードまで一つ一つ理解してこそ、transformerがその後少し自然に腑に落ちるのですが、それ以前は、概念的にどれだけ詳しく見ても理解しにくいのは仕方のない事実です。ですから、その部分については概念的にattention blockがあり、FFN blockがあり、computeがどこで多く使われ、何がどういうものなのかという程度だけ知っていれば後に続く内容を十分についてこられます。
チェ・スンジュン 新しい部分があるようですね。channel-wiseということを忘れていました。
イ・ジンウォン ですから、先ほど前のほうでattentionの部分をよく見るとtoken embedding vectorがあるときそれでQueryも作り、Keyも作りValueも作ると申し上げましたが、そのように作られたものがあるとき演算過程を表したものです。QueryとKeyを掛けてsoftmaxというものを行った後再びValueと掛ける過程を経るのですが、これはprefillで先ほどお見せした例に出てきたもので、ここでこのoutputを使って最後にLM head演算をすると’yes’という単語tokenが出てきます。
decodeでKeyとValueを再利用するKV cache 26:32
イ・ジンウォン ではdecode phaseに来ると入力として’yes’が入ってくるでしょう。すると’yes’を使ってまたQuery、Key、Value、この水色の部分を作ることになります。そして演算するとき、KeyとValueは前にあったtokenたちのKey、Valueがすべて必要なんです。Queryは必要ありませんが、Key、Valueは必要になります。ですから、Key、Valueが概念的に前のcontext情報を含んでいると見るわけです。簡単に言うと、私がChatGPTと会話したとき、過去にした会話の記憶を持っているものがKey、Valueだと考えればよいのですが、これを処理する方法は二つあります。このとき、これらのtokenのKey、Valueを再び計算することもできますし、ここで一度計算したのでこれをメモリに保存しておいて呼び出せばいいと考えることもできます。そのため、ほとんどの場合はメモリに保存しておいて再び呼び出すほうが有利なので、Key、Valueは最初のprompt phaseのときに生成されたものを保存し、今この’yes’で、ここではlayer一つで次のtokenが出たとしたときその次のtokenが再び入力として入るときにまた’yes’が使われるため、ここに’yes’のKey、Valueもこのstepが終わったら保存しなければなりません。
ロ・ジョンソク そうです。これが私たちがいつも言っているKV cacheですね。先ほど私たちが別のところからニュース記事を持ってきて2千字のものを入れてprefillしたなら、KV cacheにはその前の2千字がすべて入っているわけです。
イ・ジンウォン それをすべて持ってこなければなりません。そのため、このKV cacheを保存するメモリ空間が多く必要になるでしょう。そこで、いったいKVを保存するのにtoken一つ当たりどれほどの容量が必要なのかを計算してみると、これはLlama 3.1の70Bモデルを使って計算したものです。ここで2はKeyとValueがあるため二つ必要なので2を掛けたもので、Nはlayerの数です。すべてのlayerごとにattentionを行う必要があるためlayerの数だけ必要で、その次にKey、Valueは先ほどの
1トークン当たり320KBに急増するKV cache容量とGQA 28:15
ロ・ジョンソク multi-head attention。
イ・ジンウォン multi-head attentionが基本ですが、transformerアルゴリズムでは、Llama 3.1ではgrouped-query attentionを使用します。Grouped-query attentionとは何かというと、ここではGQAと書かれていますが、これはheadごとに本来はQuery一つ、Key一つ、Value一つがあるべきなのですが、たとえばhead八つをまとめて八つごとにQueryは八つありますが、KeyとValueは一つずつ、八つ当たり一つずつだけ持たせるものだと考えればよいです。その次にheadの数を掛け、Key、Value一つ当たり何byteで保存するか、通常BF16やFP16で保存すれば2byteになります。そこでこれをずっと計算してみるとおよそ320KB、token当たり320KBになります。これをもし128K、12万8千tokenのcontextをKey、Valueとして保存するとすれば40GB程度の容量が必要です。H100一枚には80GBのメモリがあるので、その半分です。一人のユーザーがもし128K contextを使用すれば40GBのKey、Valueが必要です。しかも70Bモデルでそうなのです。もしこれが1Tモデルになればとてつもなく大きくなるでしょう。
そのため、思った以上にKey、Valueの容量が大きいことをお見せするために、さまざまなopen-sourceモデルでどのattentionを使用し、それに応じてtoken当たりのKey、Valueの容量がどうなりcontextが増えると容量がどれほど増えるかを表にまとめたものです。ここを見ると、最近出てくる中国製のopen-sourceモデルは少し小さくなっているのが分かります。ここにはattentionの種類が少し異なるものがありますよね。そのため、このようなattentionではKey、Valueが多く生成されるものを圧縮するためのさまざまな技法を使ってこれを大幅に減らそうとしています。減らさなければ、ここでご覧のモデルを保存する容量よりもKey、Valueを保存しなければならないメモリ容量のほうがより多くなる可能性があるからです。だから、こうしたものが生まれています。
そして、これを動かすために追加でGPUが何枚必要なのか、batchを32、つまり32人にサービスを提供し、contextが平均で128Kだとしたときどれだけ必要なのか、GPUの数をここにずっと書いてあるわけです。このようなH100の場合はLlama 3.1 405Bをservingするには27枚必要です。これはストレージ容量だけで割ったもので、実際には8の倍数で使わなければならないので32枚ほど必要になるでしょう。
チェ・スンジュン この部分で少し気になるのは、こういうことを知らずに使えば大丈夫ですが、ざっくりでも知った上で使っているとこのKV cacheは時間が経てば消えるはずでまだ自分の考えがまとまっておらずモデルに仕事は与えていないのにこれが時間が経つと消えるからそういうときはprefillをもう一度してまたコストがかかるだろう、ということを考えてしまいますがそこまで考える必要はないんですよね。
イ・ジンウォン そうですね。そこまで考えるなら
疲れる。そういうことはinference engineeringを行うエンジニアたちに任せて気楽に使えばいいです。
パク・ジョンヒョン フロンティアモデルはだから料金プランでsubscriptionではなくAPIに料金を払って使うとそのcacheをどれくらい維持していて自分が使っていたpromptがcache hitになると価格は10分の1くらいですか？ものすごく安くしてくれるじゃないですか。そういうのはすべて、そのKV cacheを保持しているから可能な価格政策なんです。一般ユーザーは気にしなくても単にcacheがすべて維持されていると考えてよいでしょう。
KV cacheを削減する量子化とMLA 32:12
イ・ジンウォン このような容量が問題になるのででは容量の問題を解決してみようということで出てくる方法のうち最も直感的なのはモデルを小さくすることでしょう。小さいモデルを使えば容量を少し減らせます。その次にquantization、量子化をすればよいです。そこで最近は8bitを超えて4bit MXFP4やNVFP4のようなfloating-pointの元の標準には登録されていないそうしたformatを人々が定義して使い始めています。その次に、先ほども申し上げましたがKVの構造を変更するのです。ですから先ほどのGrouped Query Attentionも元々はhead一つごとにKVが必要だったものをhead 8個ごとにKVを一つずつという形にしたならDeepSeekが行ったMLAのようなものはこれをすべてのqueryに対してKVを一つずつだけ与えるのですがそれすら圧縮してlatent vectorにしてメモリに保存する方式を使っています。
その次にsliding window attentionというものがありますがCNNと似た概念で自分が一番最初にあるtokenまですべてattentionするのではなく自分の周辺にあるものをいくつかまでwindow sizeを決めてattentionする方法です。ただ、これだけ使うと性能が少し悪くなることがあるため通常はhybridで多く使います。一度は全体をすべて見て一度はsliding windowで見るわけです。
その次にKVを保存する空間が不足するのでMooncakeのようなところから出ているものはこれをCPUにあるメモリへ移したりあるいはSSDへ下ろしておいて必要なときにまた取り出して使う方法を多く語っています。これはagentic AIが登場してKVが生成される量が、以前のreasoning modelとも比べものにならないほど、今はより多くのKVが生成されているのでとてもこれをすべてメモリに収めることはできず後でお話ししますが、人が指示しておいて別のことをしているうちにagentに時間がかかるので来て「もう全部終わったね」と言うじゃないですか。その期間、サーバーがこれを高価なHBMメモリにKVをずっと保持しておくことはできないのでこのように別のメモリに移しておく方法も多く使われています。
チェ・スンジュン inference専用chipで行う場合このようにKVを扱うアーキテクチャが変化し続けてもすでに製造済みの半導体ですべて対応できるのですか？
イ・ジンウォン それは状況によって異なることがあります。ですから通常は考慮されていない可能性がかなり高いです。なぜなら、このように空間があふれるということを以前はあまり考えられていなかったはずだからです。ただ、新しく出てくるものはそうしたものの活用を多く考慮して作ろうとしています。その次に容量の話を超えてCPUであれGPUであれだから私はXPUと呼んだのですがXPUの性能を決めるのは単純に見れば二つです。一つは、ある演算でAとBを足すとするとAもBも最初はメモリにあるでしょう。そこでAを読み込み、Bを読み込んだ後その結果を足して、それをCとするとそのCを再びメモリに保存するこのような単純な演算があるとしたときメモリからデータを読み込むこととその次に演算すること、この二つの演算がありますがこの二つのうちどちらがより速いかによって性能は片方でボトルネックを抱えることになります。なぜかというと、今私が例に挙げたのはAとBを読み込んで演算した後その結果をメモリに保存する直列化された演算として説明しましたが実際にはこうなるわけではなく、AとBを読み込んでA足すBをしている間に次に演算するCとDもまた読み込んでいるんです。そうしてこそこの演算が終わるやいなや次のCとDをまた足せるわけです。AIでは並列処理をしなければならず同じ演算を非常にたくさんしなければならないのでこういうことが自然に起きるのですがGPUであれNPUであれ、こうしたものが1秒にいくつ演算できるか、これと、メモリからデータをどれだけ速く供給できるか、この二つによってボトルネックが生じます。
演算ボトルネックとメモリボトルネックの区別 35:01
イ・ジンウォン 普通は読み込むデータに比べて演算をはるかに多くできるようになっています。たとえばH100のような場合を見るとBF16基準で、16bitデータ基準で1PFLOP/s程度演算できます。1,000TFLOP/s程度ですが、メモリから読み込むのは1秒に3.35TB読み込めます。するとこれが実際にBF16ならその半分だけデータ数になりますよね。なぜならデータ1個が2byteだからです。ではこの比率をおおよそ計算してみると単純に割ると300ですが、つまりこの二つがぴったり均衡する時点、演算とメモリのどちらも遅くも速くもなく均衡する時点を計算してみるとおおよそ300になるわけです。これをridge pointといいます。たとえばこれがもしこれはハードウェア上の数値で、自分があるAIモデルを動かすときそのモデルを動かすkernelというプログラムがメモリからデータを一度読み込んだときに演算を200回しかできないようになっている。するとこれはメモリ側にボトルネックが生じることになり、このモデルはデータを一度読み込むと演算を1,000回できる。するとデータを一度読み込んで1,000回演算しようとしているのに今は300回しか演算できない状況ですよね。だから演算器が少なくて、もっと速くできるのに演算器が足りない状況になるのでこのときはcompute-boundになります。
Arithmetic Intensityの定義とデータ再利用 37:48
イ・ジンウォン そこでこのAIというのはArtificial IntelligenceではなくArithmetic Intensity、算術強度というものですがメモリから1byteのデータを読み込んだときどれだけ多くの演算ができるか、それを指します。これは少し難しい概念かもしれませんが例を挙げて説明してみます。先ほど最初に例に挙げた、この4つの「トマトは果物なの？」と尋ねた4つのtokenがこのように4次元のvectorで表現されたとするとあるweightを掛けてこういう演算を多く行うことになります。queryを生成するときにもこういう演算を行うでしょうしFFNに行ってもこういう演算を行うことになりますがもちろんmatrixのサイズは少しずつ異なるでしょうが簡単に説明するために単に4×4 matrixで表してみました。するとこのweight parameterの立場から見るとこのW11が乗算に何回使われるかを見ると4回使われますよね。これとも掛けられるし、あれとも掛けられるし、なのでこのデータW11は一つ読み込んだとき演算を最大何回できるかというと4回できるわけです。それがArithmetic Intensityです。正確に言うとAI半導体やGPUでは乗算を1回すると加算を1回します。なぜならここでこのvectorとこのvectorの内積を取るのでこれらの結果をすべて足さなければならないからです。乗算と加算が必ず一組で同時に起こるため演算を2回として数えますが1回か2回かが重要なのではなく今、次数がそうなっているということです。
結局、このArithmetic Intensityが何の影響を受けるかを見ればtokenの数の影響を受けますよね。そしてこのtokenの数は、先ほど私が最初に元の入力は3次元ですが入力に入るときはbatch掛けるtoken sequencelengthを合わせて一つにすると言ったでしょう。ですからここに別のbatchのデータも下に積まれているなら、それも含まれるわけです。したがってbatch掛けるsequence length分のArithmetic Intensityを持つことになります。たとえばbatchが1だと簡単に仮定してtokenを100万個使ったとするとArithmetic Intensityは100万になります。逆にdecodeに来ると、これは一つですよね。したがってW11というものは1回しか使われません。なのでこのときはArithmetic Intensityが1です。そしてこのArithmetic Intensityというものは少し別の話ですが、半導体では非常に重要です。なぜならメモリからデータを一度読み込んで演算を多くするというのは多く活用するということですよね。逆に言えば同じ演算をしたときメモリから読み込む回数が減るという意味でしょう。
これがなぜ重要かというと、ここを見ると乗算1回と加算1回で消費するエネルギーに比べてこのSRAMはchipの中にあるメモリでさえありますがSRAMやHBMやDDRから読み込むとき消費するエネルギーを見ると桁がいくつ違うのでしょうか。圧倒的に違いますよね。4、5桁も違うほどエネルギーを多く消費するので私たちが低消費電力を語るとき最も重要なのはメモリからデータをどれだけ少なく読み、少なく書くか、これは非常に重要です。それはArithmetic Intensityとも関連しているわけです。少し別の話でしたが。そこでRooflineanalysisというものが出てくるのですが、これは有名なDavid Pattersonをはじめとする数名が2009年に論文として発表したもので、先ほどridge pointと呼んだこれはハードウェアが決まれば描かれる線です。あるモデルと関係する線ではなく、ハードウェアの性能を表してくれるグラフです。このridge pointは演算とメモリのどちらにもボトルネックがない状態です。
roofline analysisで読み解くcompute-boundとmemory-bound 40:58
イ・ジンウォン これを描く方法ですが、ここにあるこの水平な線は半導体が発揮できる最大の演算能力です。先ほどH100が約1PFLOPS程度の演算ができると話しましたが、それがここです。ここでy軸をたどるとy軸には1,000 TFLOPS程度が出てくるわけです。そしてこの傾きはログログスケールで描くと傾きが1ですが、ここでy切片に当たる、y軸と交わる点がまさにbandwidthになります。これは傾きが常に1なので、bandwidthが上がればこの斜面も上がるでしょう。そうするとridge pointは左へ移動するでしょう。データをより速く供給できるので、arithmetic intensityがより低い地点でridge pointが形成されるわけで、逆にbandwidthはそのままにしてcomputeを上げるとこの水平線が上へ移動するのでこのように上がっていきます。
そこでこのグラフを見ると何が分かるかというと、ridge pointより右側にあればcompute-boundということです。x軸がarithmetic intensityです。あるモデルを動かすとき、先ほど私が話したようにprefillでweightを読み込んできて、このweightで100万回演算できます。するとここが295なので、100万はかなり右側にあるでしょう。つまりここではデータを一度読んで100万回演算できるのに、演算器は300回しか演算してくれない。だからこれを300回ずつ何度も実行して、100万回になるまで待たなければならない状況なのでcompute-boundであり、逆に左へ行くと、先ほどdecodeのときはメモリからデータを読んで演算を一度しかできませんから。ところがメモリからデータが300分の1の遅い速度で来ているわけです。ですからその分だけ性能が大きく落ちることになります。
そのためprefillは私たちがそれでも演算器をさらに増やそうと思えば増やせますが、decodeは基本的にこの演算自体がこのような形になっているため、トークンが一つ入って一つ出てきて、したがって行列掛ける行列の演算ではなくベクトル掛ける行列の演算になるため、常にarithmetic intensityが非常に低い地点に位置せざるを得ません。だからこれを右へ送らなければならず、このグラフがy軸方向で交わる地点が結局性能を表すわけです。これを何とか右へ送ってみようという発想になるわけです。一番簡単なのはbatchを増やすことです。decodeするときも私が質問した答えの単語一つ、トークン一つ、二人目のユーザーに対する回答トークン一つ、三人目のユーザー、四人目のユーザー、このように複数のユーザーから出たoutput tokenを一つずつすべて集めて行列を掛ければ、その分arithmetic intensityが上がるでしょう。先ほど私が3次元の入力で、sequence lengthが1だと言いましたよね。decodeのときはbatchを大きくすると再び2次元にできるので、その分arithmetic intensityを上げられます。そのためdecodeのときはbatchingを最大限活用して処理しようとしています。
batchingで高めるdecode効率とattentionの限界 43:46
イ・ジンウォン しかしここで非常に深刻な問題が生じるのですが、attentionはbatchingを増やしてもarithmetic intensityが上がりません。なぜなら、私が質問したもののkey-valueと、他人が質問したもののkey-valueは異なるでしょう。そのためqueryとkeyを掛けるとき、queryはベクトルでkeyは行列でしたが、その行列を共有できないのです。batch同士で先にqueryを生成したり、keyを生成したりvalueを生成したりするときは、同じweightを掛けるので、異なるユーザーのトークンを集めて演算できましたが、これが私のoutput tokenのqueryだとすると、これがkey-valueの集合だとすると、他のユーザーはこのkey-valueを使ってはいけないでしょう。ですからここではarithmetic intensityを絶対に上げられません。ここは依然として1のままでなければならない状況です。そのためattentionでボトルネックが多く発生し、特に最近はコンテキスト長も長くなってきたため、この部分が非常に大きなボトルネックになっています。
ですから人々も黙ってはいないでしょう。attentionでもarithmetic intensityを上げてみようというのが、先ほど話したGQAのようなものを使うと、8個につきkey-valueが一つなのでqueryを8個集めてkey matrixと掛けるため、8倍のarithmetic intensityになるでしょう。元の1から8へ上がるわけで、MQAもmulti-query attentionといってqueryが16個あれば16個全体に対してkeyとvalueは一つずつだけ使うんです。MLAも同じですが、MLAはそのkey-valueさえ圧縮して使うんです。なのでこのような場合はいくつのqueryごとにkey-value一つを割り当てるかという分だけarithmetic intensityが上がることになります。次に私たちがプロンプトをChatGPTやClaudeに与えると私たちには見えませんがその前にsystem promptであるとかさまざまなtoolについての説明であるとか注意事項のようなものが入っていますよね。その前に入る部分は常に同じ内容なのでhidden promptに対するkey-valueをあらかじめ計算しておいてそれを共有して使おうというのがprefix cachingの方法です。こうするとその部分で少し得になりますよね。そしてkey-value自体のサイズを減らせば同じbandwidthでより多くのkey-valueを読み込めるのでそれも効果がありますよね。そこで使う方法がkey-valueを8ビットや4ビットに量子化して持ってくる方法で、このようなものをattentionでもarithmetic intensityを上げる方法として使っています。
パク・ジョンヒョン お聞きの皆さんに分かりやすいように私から一度かみ砕いて説明してみたいのですが、arithmetic intensityというのは私たちがメモリからデータを読み込んでそれを何回演算するか、できるだけ多く再利用すればするほどcompute-boundになるのでGPUのcomputing resource、CUDA coreと言いますよね。core数が多いのでそれを活用できてprefillの場合は持ってきたweightをすべてのトークンに対して一度にすべて演算するのでcompute-boundとなりそちらへ行ける一方で、decodeの場合は基本的にTransformerが一トークンずつ必ず演算しなければならないので再利用できずmemory-boundになるんです。そこでhardware自体の性能を上げるために、次のページにあるy切片を上げるためにmemory-bound workloadをより良く実行するためにそもそもmemory bandwidthが高いHBMのようなものを使ってその曲線を変えできるだけ効率よくできるようにする、というところまで理解しました。
イ・ジンウォン その通りです。これが左に行けば行くほどcompute-boundにより入りやすくなりますよね。なので性能をより引き出せるんです。
ロ・ジョンソク このridge point、この曲線自体はTransformerとはまったく関係なくhardwareが決まればcomputeとmemoryによって生まれる一種の最適な線で、その最適な線の中に私たちがTransformerを無理やり入れなければならないのですがTransformerにおけるprefillとdecodeの演算の性質があまりにも異なるためこれをどう最適化して組み込んでそのhardwareが持つ性能を最大限に引き出すかということが私たちがこれから話す最適化に関する内容なんですよね？
そしてここでもう一度皆さんを安心させてから進むと、これらが今すぐ頭にしっかり入らなくても大丈夫です。これらをすべて理解しなくても構いませんし、おおよそこうしたものがinferenceのeconomics、推論の経済学の中でこれらを解釈するために生まれる思考の枠組みでありengineeringの最前線だと受け止めていただければ大丈夫です。
イ・ジンウォン では次に話すのは、例えば私たちが何らかの量子化のようなものを適用してメモリ空間ももう少し効率よく使い同じbandwidthでより多くのデータを読みたいとしたとき何を量子化するのが効果的かを見るにはそもそも何のデータ量がより多いのかと関係せざるを得ません。もう一度先ほどの容量の話に戻らざるを得ないのですが、これも先ほどLlama 3.170B、BF16基準で見たとき重みが約141GB、weightがその程度あるのですがkey-valueのほうが多くなるのは43万1千トークンを使うとkey-valueのほうが多くなります。これはbatch 1のときの基準です。batchが増えれば増えるほどbatch掛けるsequence lengthが先ほどのarithmetic intensityに当たり、それだけkey-valueが生成されるためbatchが増えれば増えるほど当然key-valueの量がweightの量を上回る時点のトークン数はますます減っていくことになります。
そしてこれは128Kでkey-valueの容量がどれほどになるかを計算したものですが、見ていただくと512 batchでは約22TBです。つまり実質的に512人を同時に一つのサーバーあるいは一、二台のサーバーでservingすることは不可能だということをここで確認できると思います。なのでこれは量が多いということをお見せするためのものです。
ロ・ジョンソク ここでB掛けるS、これは prefill の arithmeticintensity を決めるとても重要な数値ではありますよね。でも、この batch はTransformer を学んでいる方々がよく混乱するのですが、Transformer を training する際の batch の概念とinference における batch の概念は少し違いますよね。training の際の batch は、私たちが同時に何文をここに投入するかという話ですが、inference の際の batch は sequence length があまりにもまちまちなので、この batch はユーザー数、ユーザーの人数だと考えるとぴったりです。この部分は混同してはいけないということをお伝えしたいと思います。
interactivityとthroughputのtrade-off 51:33
イ・ジンウォン その通りです。そして benchmark についての話を少ししてみようと思います。では一体、どの AI 半導体、あるいはどの GPU が良いのか。こういう話を私たちもよく聞かれます。「あなたたちのはどれくらい良いの？」と聞かれるのですが、これはたった一つの数値で「私たちはどこより何パーセント優れています」と言うのがとても難しいです。なぜなら条件があまりにも多様だからです。そこで代表的なのが、一人のユーザーがどれほど速くトークンを受け取れるか、ユーザー当たりの tokens per second です。1秒に何トークンのサービスを受けるか、これを interactivity と呼びます。そしてサーバーの立場からすると、今、複数人に serving しているとして、その複数人に serving するトークン全体の合計、1秒当たりの全トークン合計を GPU の数で割って、GPU 当たり1秒にどれほど多くのトークンを生成しているか、これがユーザー一人に届くのか、100人に届くのかに関係なく、すべてを合計したものをthroughput と呼びます。
今日の朝もこれを録画しようと会社に来る途中でお腹が空いたのでマクドナルドに行って朝マックを注文したのですが、中で作っているのが見えているのにしばらく待っても出てこないので見てみたら、複数人分のパンを一つずつ次々に置いて作っていたんです。それが throughput を増やすことで、私は一番最初に注文した人だったんです。だから私の interactivity はとても悪い状況になったわけです。そこで今お伝えしたいのは、throughput を上げていくとinteractivity をある程度犠牲にせざるを得ないということをお伝えしたくて、今日の朝、ふとそれを見たらまさにこのことを思い出したんです。
パク・ジョンヒョン これは前回のコ・ソクヒョン代表の回でお話しされていた一人当たりのトークン速度をずっと上げるためには他のものを犠牲にしなければならないと話していたその部分だったのだと思います。
イ・ジンウォン そして今、ほとんどのフロンティアラボがサービスする際に fast mode のようなものがありますよね。例えば Anthropic も2.5倍速くなる代わりに料金を6倍取るという話がありますが、それがここから来るのです。一人のユーザーにより速いサービスを提供しようとするとthroughput が下がるため、より多くの料金を取らなければならないのです。そこで、これは SemiAnalysis が作ったベンチマークグラフです。これは一つの数値で出るのではなく、グラフで出てくるのですが、x軸が interactivity で、右に行くほど速くなります。ユーザーが1秒により多くのトークンを受け取るということで、y軸が throughput です。そのため、これを非常に多様な状況に応じて指標をいくつに分けるのか、parallelism にも tensor parallel があり、expert parallel があり、pipeline parallel があり、data parallel など、さまざまな手法がありますが、そうしたものをすべて異なるオプションにしてbatch size がいくつの場合まで、すべて変えて点を一つずつ打っていくと、このように非常に多くの点が出てきます。この点のうち、少し濃く塗られている一番右上の点同士をつないでPareto curve を描くと、このようになりますが、これが InferenceX の核心グラフです。ですから、この曲線より上には絶対に行けず、右に行くほど batch size が小さくなり、同時にサービスする人数が少なくなることで速度が速くなり、左に行くほどサーバーの立場では、GPU の立場ではより多くのトークンを生成しますが、一人一人の速度は遅くなるのです。
SemiAnalysis InferenceX Pareto curveの読み方 54:26
イ・ジンウォン これを直感的に考えてみると、先ほど KV cache はユーザーが増えると増えた分だけずっと増えるとお話ししましたよね。ですから、ユーザー一人だけにサービスする時はその一人に対する KV cache だけを読み込めばよいですが、10人にサービスするとKV cache も10倍のデータを読み込まなければならず、それを使って attention を行い、10人分すべてを処理してから次の layer に進み、layer が100個なら、それを100回繰り返さなければなりませんが、KV cache を読み込む時間がユーザーが増える分だけ長くかかるため、そして KV cache の量は多いとお話ししましたよね。そのため、一人のユーザーが感じるには当然、速度が遅くならざるを得ないのです。ですから、概念的にはそのように考えればよいです。実際のグラフをお見せすると、このようになっています。右側を見ると、それぞれの GPU、NVIDIA と AMD の GPU があります。左側にあるものは throughput が高く、ユーザーの interactivity が低いということで、右側が速いと考えていただければ大丈夫です。
チェ・スンジュン 先ほどこのようにパレート・フロンティアのグラフを描いたときは1つの GPU を想定したもので、ここでは複数使うということですか？
ロ・ジョンソク 単に GPU ごとに curve がどうなるかを今描いたわけですね。
チェ・スンジュン つまり先ほどのものは1つを想定したもので、
イ・ジンウォン いいえ。複数を使っているのですが、ここでは GPU 数で割ります。ですから100個使っても100で割るのでここではすべて同じ軸で比較できます。
チェ・スンジュン 1つのブランド、つまり1つの製品を使ってplot をするのか、ということです。
イ・ジンウォン これらを集めたものがここにあるわけです。ですから実際、このグラフ1つが出るまでに非常に多くの実験が必要です。
ロ・ジョンソク つまりこれは実質的にどの hardware を使うかによって変わり、どのモデルを使うかによって変わり、また、どの inference orchestrationsoftware を使うかによって変わるもので、その基準がここに一度にすべて見えているわけですね。
イ・ジンウォン ですから実際にサイトへ行ってここにマウスを置いてみるとどの configuration なのか、software まで全部表示されるんです。ここにも大まかにはありますが、vLLM を使ったのか、SGLang のようなものを使ったのかによっても変わります。parallelism をどう取ったかによっても変わり、では、これをどう比較するのか？通常、あるサービスがあるとするとそのサービスでは requirement が決まっていて、私たちはユーザーが1秒当たり必ず100トークン以上受け取らなければならないとすると、ここで100トークンの地点に縦線を引いてthroughput を比較すれば、どれがより性能が良いのかをそこで確認できます。今このグラフでは、曲線のほとんどは交差していませんが、実際に描いてみると交差するケースもかなり多くあります。ですから throughput が良い領域、batch が多い領域では良くなかったものがbatch が小さい領域へ移るにつれてこのように上がっていくものも多く見られます。ですから状況によって変わりますが、たまたまこのグラフでは右側で良いものが左側でも常に良いですが、右側と左側の様相は hardware やsoftware の特性によって変わることもある、ということをお伝えしたいです。
チェ・スンジュン では、このグラフは誰にとって役立つグラフなんですか？
ロ・ジョンソク このグラフは実際にモデルを持ってきてserving するサービスを作らなければならない事業者の立場では、どの stack を選ぶかによって自分が利益を得られるか得られないかを決めるものですね。なぜなら、ここで抜けているのはユーザーからいくら受け取るのかという部分ですが、
イ・ジンウォン それも実はこの点の中の1つの configuration として含まれてはいます。disaggregation というものを後ほどお話ししますが、行うか行わないかによっても非常に大きな差が出ます。
パク・ジョンヒョン ユーザーの要件であるトークン数と interactivity が決まれば、自分がどの GPU を買ったときthroughput がどの程度出るので需要を満たすといくら稼げるか、投資回収を計算したりモデリングしたりするのにも十分使えると思います。
ロ・ジョンソク SemiAnalysis がこれをやる理由はまさにそれでしょう。ですから、例えば ChatGPT や Anthropic がどのような機械を買い、どのような cloud を作ってユーザーからいくら受け取っているのか、彼らが利益を出しているのか、損をしているのか、こうしたこともこのグラフを見るとおおよそすべて逆算できるでしょう。
イ・ジンウォン ですからこれを使って、その会社の売上も予測し、非常に多くのデータを利用してSemiAnalysis はそのような情報を販売して収益を生み出すビジネスをしています。
ロ・ジョンソク Anthropic のトークン利益率が70~80%にもなるということもこうした分析に基づいて逆算したのでしょう。
イ・ジンウォン そして今年の GTC もご覧になると、Jensen Huang が LPU のようなものを使ったときにどのように良くなるのかをすべてこのグラフで示しているんです。ここで右側に行ったとき、このように大きく下がらずずっと維持される。LPU を使うとbandwidth が非常に良いのでこのように batch が小さい側で良い性能を発揮できる。こうしたことを示しているものがありますが、これを概念的に「こういうことなんだな」という程度に理解しておけば、そのようなグラフが出てきても「これは何を言っているんだな」と理解できると思います。
チェ・スンジュン SemiAnalysis の地位がずいぶん変わったようですね。今ではあちこちで引用されていますから。
イ・ジンウォン はい、ずいぶん変わりました。
ロ・ジョンソク 会社はすでに非常に収益性が高く、投資も一度も受けていません。そして、このような report を、フロンティア・ラボの economics がどうなっていて、これらの会社が投資している額に対して2、3年以内にどのような形の curve に至るのか、こうしたものを世界中の会社にreport として売っていますが、知りたい人は非常に多いでしょう。私たちでさえこれほど気になるのですから、あの巨大企業はもっと気になるのではありませんか？ですから彼らが非常に多くのお金をきちんと払っていると聞いています。
イ・ジンウォン そのとき私たちが ICML に行った際に一度会って、私たちもその後オンラインで何度もミーティングしました。
ロ・ジョンソク 私たち AI Frontier と SemiAnalysis がこの7月の ICML 期間中にパーティーを開きましたね。Lablup でです。そのとき韓国にある多くのチップ会社と大企業、SemiAnalysisの間の交流を私たちが一度仲介したことがあります。
vLLMのcontinuous batchingとPagedAttention 60:51
イ・ジンウォン そしてservingするvLLMのfeatureについて少し説明しようと思うのですが、実際そうするとユーザーのrequestが随時入ってくるわけですよね。これがみんな一緒に集まって一度にどっと入ってくるのではなく、かなりランダムに入ってくるでしょうが、それをサーバーで、データセンターでどう受け取ってservingするかが非常に重要です。そのためvLLMやSGLangのようなserving frameworkが非常に有名になり、人々はそれをopen sourceであるにもかかわらず標準のように使っているわけです。
そこで昔は単純に考えて、requestが例えば4つ同時に入ってきたとすると、前の青色がprefillでこの赤色がdecodeだとすると、これをまとめてbatchingすることをstatic batchingといいますが、static batchingをするとこのbatchが完全にすべて終わるまで、4つがすべて終わるまで次のrequestが入れないようになっています。そうすると当然、最も長いものを全員が待つ状況になりますよね。
しかしこれではこの薄い部分が無駄になるので、これを防ぐためにvLLMで最初に始まったわけではありませんがここでOrcaというソウル大学チョン・ビョンゴン教授の研究室から出た論文があり、現在FriendliAIという会社も創業されましたが、そこで語られたのはこれをリクエスト単位ではなくiteration単位でやろうということです。どういうことかというと、tokenが1つ生成されるたびにschedulingをやり直そうということです。そのためprefillが終わった後に一度確認し、またdecodeで1 tokenを生成した後に確認し、これらはすべて同時に生成されるからです。そのためここまで生成したときにR2という2番目のリクエストが終わった。そうするとこれは次のiterationで次のqueueにある、ここではR6というこれを受け入れるわけです。そのためこれがprefillを行い、あるstepを見るとprefillとdecodeが混ざって入ることになるわけです。緑色がprefillだと考えてください。こうすれば隙間なく埋めて処理できます。
でもprefillとdecodeをどうやって一緒にするのか？こう思われるかもしれませんが、よく考えてみるとquery、key、valueを生成することもFFNも、すべて同じweightを掛けることなのでprefillとdecodeには何の違いもありません。ただ違いが出るのはattentionです。つまりbatchごとにattentionをすべて別々に行う必要があるため、それだけを別に分離できれば一緒に処理しても何の問題もなく、実際、このdecode stepでもこの4つのbatch、あるいはこのprefillでもこの4つのbatchの間ではattentionをすべて別々に行うため、ここでも別々にすることはそれほど問題になりません。ただ、異なる点があるとすれば、こちらはqueryが1つでこちらはqueryが、promptが1,000個なら1,000個で、このようになるわけです。
ここで時間間隔をもう1つだけ説明すると、時間間隔を同じように表示しましたが、このようにするとここでtoken数が多ければこれが少し長くなることがあります。これらのdecodeは少し早く終わり、このようになることもあり得ます。
ロ・ジョンソク この部分について視聴者の皆さんに背景説明をすると、私たちはChatGPTを使っていますが、私たちがどんなことを言うかをOpenAIには知る方法がないわけですよね。誰かは「こんにちは、元気だった？」というとても短い会話を断続的に続ける人もいて、誰かは来てClaude Codeを使ってコードを数千行、数千文字ずつ一度に入力する人もいて、どのような形のworkloadが来るかをサービス提供側は知る方法がありません。しかしそれを従来の方法で行うとこのリクエスト単位のstatic batchingでおっしゃったようにあるtokenは、つまりあるユーザーは完全に空いていてある人は埋まっていて、その間の空いたslotがChatGPTの立場から見るとすべてお金の無駄なので当然、こうしたいという欲求が出てきますよね。その空いた空間をすべて埋めよう。どう埋めるかによって非常に多くの最適化手法がありますが、そうした話をCTOがお話しくださっているとご理解いただければと思います。
チェ・スンジュン パターンはすべて一貫しているのではないですか？コンピュータ分野でいつもやる、amortizeを最大化するエンジニアリングです。
ロ・ジョンソク それです。そうですよね、最適化です。どうすれば空のバスが出発することを減らし、人をぎゅうぎゅうに乗せて送るか。マクドナルドのハンバーガーの例と高速バスターミナルのバスの例とKTXの乗客の例、こうしたものはすべて同じ最適化問題です。
イ・ジンウォン 次にPagedAttentionというものがあるのですが、これは何かというと私たちは先ほどKVをcachingすると言いましたよね。するとKVをメモリに保存しなければなりませんが、そもそもChatGPTやClaudeやGeminiが何token、何単語で答えるか私たちには分からない状態ですよね。何単語で答えるかが分かればそれだけのKVが出ると分かり、その分のメモリをあらかじめ割り当てておくでしょうが、それが分からないので、私が出せるworst case、最大限たくさん出したとき、答えを最大限長くしたときを基準にメモリ領域を確保しておかなければなりません。そのリクエストが終わるまでは。そうしているとメモリは実際には先ほどおっしゃったように短く、ただ「こんにちは」といった短い会話をする人たちは数単語、数 tokenで終わるでしょうから、残った領域はすべて無駄になります。そこで、その無駄を減らすアイデアとして、これも非常に単純なのですが動的にメモリを割り当てるのです。page tableの概念を持ち込むわけです。例えば最初の1つ目のoutput単語としてAlanという単語が出てきたとすると、そのAlanという単語のkeyとvalueを保存するためにメモリ領域を実際のphysical memoryのblock 7番に割り当てます。しかしこの領域はpageなので、例えば4単語まで保存できるのです。最初にAlanが出てきたらここにkeyとvalueを保存し、次にTuringが出てくると、その隣の枠が空いているので続けて保存するのです。aが出るまで保存してからcomputerという単語が出てくるとpageがいっぱいになりますよね。そうしたらそのとき、新しいpageを割り当てるのです。そこで、ここのblock 0番は今physical block 7番と接続されている。ここのblock 1番は実際のphysical block 1番と接続されていて、ここのblock 2番は3番と接続されていますが、ここのfilled slotは今1枠埋まっている。つまり、まだ3枠空いているという情報を教えてくれるのです。そこでこのように動的にその都度メモリにpageを新たに割り当てれば自分が必要な分だけメモリを使えるので効率的にメモリを使えてより多くのユーザーにサービスを提供できる、という概念なのです。
ただ、これも良いアイデアに見えますが単純ではないのは、worst caseで本当にまれではあるものの全員がworst caseで最大長のoutputを出すようになると問題が生じます。なぜなら、これはまるでこういうことだからです。銀行で人々が預金を引き出さないので預金準備率を低くするのと似ていて、メモリ領域は本来worst caseを想定してすべてその分だけサービスすべきなのにどうせ皆がそれだけ使うわけではないから追加でさらにユーザーを受け入れるわけです。ところが、そうしているうちに全ユーザーがみな最大のoutputを出すようになるとメモリ領域が足りなくなるでしょう。そうすると、そのときまたこのKVを外へ追い出して後で再び呼び戻すこうした作業をしなければならないためソフトウェア的には決して単純ではありません。しかし大半の場合はそういうことはあまり起こらないので有用に使えるのです。
ロ・ジョンソク そういう部分がエンジニアリングが深く入る部分で、私たちがNVIDIA GPUだけを使ってオープンソースモデルを載せれば誰でも商売できるんじゃないかと思うかもしれませんが、その中でどのように最適化をうまく行うかによって本当に金額の桁が何桁も上下するんです。私たちはその領域をorchestrationソフトウェアレイヤーと呼んでいますが、その中にはvLLMやSGLangなどKubernetesなど非常に多くのものが入っていて、その部分もハードウェアだけでなくこのインフラソフトウェアの領域も私たちが非常に注目して見なければならない産業領域だということもぜひ一度お伝えしたいです。
チェ・スンジュン やってくれているということですね。
パク・ジョンヒョン そのPagedAttentionは論文として発表されてそれがオープンソースになりvLLMになったものだと聞いていますが、おそらくほぼすべてのinference servingframeworkに適用されているはずです。今は。
ロ・ジョンソク 互いに互いを模倣して今ではすべて同じになっています。
イ・ジンウォン そしてprefix cachingもどんなリクエストが来ても皆で使うものなのでKVをあらかじめ計算して保存しておいてそのまま持ってきて読んで使おうということです。
chunked prefillとspeculative decoding 69:37
イ・ジンウォン 次にchunked prefillというものがあるのですが。途中でprefillが割り込むとこれによってdecodeが遅くなることがあります。本来これがなければ速くできるものがこれのせいで8,192 tokenのprefillが一度に入ってくると、この4つをまとめてバスに乗せるとこれのせいで遅くなるのです。先ほどridge pointが300しかなかったのでこれだけを処理するには非常に多くのiterationを回さなければならず、その分、これらはこれがないときに比べて遅くなります。
ではこれをどうするかというと、同じ大きさにすべて切ってしまうのです。これは本当にバスの概念なのですが、切り分けて、このprefillも分けて投入するのです。そしてこのchunked prefillを行う際には優先順位があり、通常の場合はdecodeに必ず優先権を与えます。decodeがあれば、decodeを先に乗せるのです。バスにです。その次はprefillのうち切り分けられて前のprefillは行ったのですがバスに乗れなかったprefillを乗せて、最後に新たに入ってきたもの、それでも空きがあれば新たに入ってきたものを乗せる、という優先順位があります。そうすることでサービス品質を最もよく満たせるので、普通はそうしています。
ですので、ここにあるようにTBTを下げて、TBTはdecodeに関係するものです。最初にこのAIモデルが答え始めて、うまく答えていたのに突然途中で止まったりする状況がこれによって起こるのですが、それを減らす代わりにprefillの最初のtokenが出るまでの時間は少し犠牲にしようということです。このようにしないと品質を一定に保てないため、この方法がよく使われています。
次に最後にspeculative decodingですが、これはこの前コ・ソクヒョン代表もよく話されていたことで、DeepSeekがDSparkという良い方法を出して速度を非常に上げる方法なのですが、アイデア自体はこれも非常に単純です。私たちがautoregressiveにdecode stepで一度に一つずつtokenを生成するそれを一度に複数のtokenを生成できないかと考えるわけです。
では、これはどういうことかというと、簡単に言えば、KV batchを増やしてdecodeでarithmetic intensityを高めたかったのですが、そうするとkey-valueも一緒に増えるのでattentionにはあまりメリットがなかったですよね。ところが、そのbatchを増やさずにarithmetic intensityを高める方法が一度に複数のtokenを生成することです。しかし、一度に複数のtokenを生成するのは簡単ではないですよね。なぜならすべてdependencyがあって、二つ目のtokenを生成する際に一つ目のtokenを見ずに生成すれば、当然精度は大幅に下がるでしょう。
そこで、最初にこの概念をどのように始めたかというと、そうせずに小さなモデルを持ってきておよそ100分の1の大きさの小さなモデルを持ってきて、これを高速に逐次実行するのですが、高速に実行して、これが例えばこのように8個のtokenを出すようにした後、この8個のtokenを大きなモデル、元のモデルに持っていって一度に検証するのです。
ではどうするかというと、これがそのままprompt prefill phaseに入ってきたかのように検証するのです。この前にはもちろん、さらに単語があった、tokenがあった可能性はありますが、それも含めて、もともとは一つだけで行っていたものをすべて持ってきて一度に行うのです。
するとprefillのようにすべて同じように行った後、最後に次のtokenを生成するとき、もとのprefillではこの最後の単語から次の単語を出すことだけをしていたのですが、そうするのではなく、これも次の単語を出し、これはこの2つを見て次の単語を出し、これはこの3つまでを見て次の単語を出し、これも次の単語を出し、次の単語を出して、the の次に cat が出るかを見るのです。これは the までは合っているとし、the cat までは合っているとし、その次に sat が出るかを見るのです。このように検証するのです。
つまり、すべては並列で進めて、最後にLM headだけを逐次処理すれば、これを非常に高速に一度にすべて見られるでしょう。ですから、the cat、sat on と進んでいて、ここは the ではなかった、いや、mat が間違っていたとすると、これがmatではなくbenchだったとすると、benchまでは合っていたのだとして、再びこの小さなモデル、これをdraft modelと呼ぶのですが、draft modelに送るのです。するとdraft modelは、そのbenchの次にまた8個の単語を続けて高速に出し、それを持ってきて大きなモデルが一度に検証し、これを繰り返せば、serving速度を非常に速くできるでしょう。これがspeculative decodingです。
これの欠点があるとすれば、モデルを2つ使わなければならないので、小さなモデルを一回、大きなモデルを一回このように行ったり来たりしながら実行しなければならない難しさがあって、同じモデルの中でdraft modelのように動作させ、その後に再び検証する、こうした研究もありました。
Metaにはこうした論文がありました。私たちはlayerが100個あるモデルですが、必ず100個のlayerまで行かなければ次のtokenを正確に予測できないのか、ある簡単な単語は10個のlayerだけでも予測できるのではないかと考え、それをすべて統計にしたのです。途中でこのnetworkを切り取った後、例えば100個のlayerのものを50個のlayerで切った後、そこにLM headを付けて予測し、どれだけ当たるかを検査してみたのです。
そこで実際の正解を何番目のlayerで初めて当てるかをすべて統計にした後、例えば70個のlayerまで行けばほとんどすべて当たるね。でも50個のlayerまででも70%は当たるね。それなら単に50個のlayerまでにして高速に予測してから一度検証し、こうすれば同じモデルの中で予測を高速にして検証も行い、このようにできるでしょう。このような形で行う方法もあります。
DSparkはまた少し異なる方法で行っていましたが、例えばdiffusion transformerのような形を使っていて、diffusion transformerはautoregressiveにtokenを生成するのではなく一度に複数のtokenをすべて出力できるんです。では、それをdraft modelとして使って検証は元のモデルで行うこうした方法も使えます。
チェ・スンジュン DSpark以外にEAGLE-3とは何ですか？ここにも出ていますが、時々見かけるんですよね。
イ・ジンウォン EAGLE-3も単にspeculativedecodingを行うモデルです。
ロ・ジョンソク 私たちのリスナーの立場からするとではいったいなぜこれをやるのかが重要なのですが、引き続きprefillとdecodeのバランスをどう取って単位電気代、単位GPU当たりに生成するtoken数を増やすかという問題を、今みんな解いているわけでこのspeculative decodingを行う理由はprefillがdecodeよりはるかに安いからです。だからdecodeにかかる労力が大きすぎるのでより安いモデルにdecodeを速く回させてそれが当てた解答をprefillに、大きなモデルのprefill phaseに入れて合っているかどうかを一度に検証してその間に利益を得ようとする試みだと理解していただければと思います。
チェ・スンジュン そして、今観測されているridge pointが300前後だとしても、それがさらに上がったとしてもこの仕組みは維持されるんですよね？
ロ・ジョンソク これは永遠にこのように進むでしょう。
パク・ジョンヒョン そして、私もこれを見て思うのは先ほどのPagedAttentionもそうですしspeculative decodingもそうですしある演算をcompute-boundとmemory-boundの間で切り替えるアルゴリズム上の方法もそうですが、すべて伝統的にCPUやOSのようなCS分野で使われていた方法がLLMとGPUに合わせて移ってきたような感じがするんです。最適化の本質のようなものは、継続して再利用されている。つまり、昔のものをよく知っていることが未来のものをよく知るうえでもすべて役立つのではないかと思いました。
イ・ジンウォン そして、私が一つ付け加えたいのはDSparkのようなものを見ると、DeepSeekの人たちがとても優れている点は、この検証も実はoverheadになり得るんです。なぜなら今はこの図で4つだけ正しくて4つが間違っているのですが後ろに行くほど間違う可能性がさらに高くなるでしょう。どうしても後ろにあるものを検証するために演算を使うのはもったいない。そして今、演算がぎりぎりで回っているのにこれが入ってきて不要な演算を行うのももったいないので現在のcompute resourceの状態を見ていくつまで検証するか、そもそもcomputeが厳しければたとえばこれが8つ生成しても後ろの2つを除いて6つだけ検証するとか、このように状況に合わせてtokenをいくつ検証するかを調整するものが実装されていて私は見ながらかなり驚いたように思います。「こんなところまで最適化するんだ」と。
パク・ジョンヒョン そして、そのtokenを予測して正しいかを検証するわけですが、実はtokenというのは確率的に出てくるものなのでこの閾値を決めれば、なぜならtokenとしてAが出ても、「こんにちは」が出ても「ごきげんよう」が出てもどちらも正しいと見なすこともできるでしょう。だから確率が最も高いtokenでなくてもかなり良い確率のtokenであれば単に正しいものとして通過させることもできるわけです。それも私たちが調整できるわけです。つまり品質を気づかれない範囲で犠牲にしながらtoken数を増やすことも十分可能だと思いますし実際にもすでに多く行われていると聞いています。
prefill poolとdecode poolを分離するPD disaggregation 78:53
イ・ジンウォン 次に進みます。disaggregationの話を少ししたいと思います。ですが、私たちはprefillとdecodeがあまりにも違うという話を続けてきましたし、arithmetic intensityがsequence length掛けるbatchの影響を受けdecodeはattentionを除けばbatchだけの影響を受ける、こう理解しています。そのためrooflineから非常に遠く離れていることが分かりました。ですので、先ほど申し上げたとおりchunked prefillを行うとしてもとにかくprefillが入ってくるとdecodeは性質が異なるためprefillが多く入ってくるとdecodeに影響し逆にdecodeだけを優先するとprefillのTTFTが悪くなるのでシンプルにこれを分けてやろうと。そうすれば要求されるSLOを満たすthroughput、これをgoodputと呼びますがgoodputを増やせるという考え方から始まったのです。
そこでprefill poolとdecode poolを置いて、これを分けて、つまりJensen HuangがTokenFactoryという話をよくするでしょう。私はそこにはこういう側面もあると思うのですがtokenを多く生成するという意味もあるでしょうがそれよりもコンベヤーベルトで自動車を作る際に、ある人は車輪を組み立てある人はドアを取り付けるこういうふうに一つ一つの工程に応じてそれだけを行うpoolを作るわけです。そこでprefillだけを行うprefill pool、decodeだけを行うdecode poolに分けてこれをPD、prefill-decodedisaggregationと呼びます。その代わり、このprefillで作られたすべてのkey-valueはdecode poolへ転送しなければなりません。したがってdisaggregationを行うとこの間のネットワーク速度も非常に重要です。これは、ある程度の規模がないとあまりメリットがありません。規模があるときにメリットがあるんです。
なので、先ほど申し上げたようにraw throughputの観点、つまりtokenをどれだけ生成するかという観点で見ると、上がりません。utilizationは同じです。これらがすべて100%で動いている。同じGPUを使うとしても通常、最初はMicrosoftから出たSplitwiseという論文で初めてdisaggregationに関する話が出てきたのですが、ここを見ると、同じH100 GPUを使ってprefillの数を変えています。とにかく数を変えてthroughputを合わせるのですが、これはある程度の規模になって初めてメリットがあります。次に、すべてが100%で動いているとすれば、GPU 100台をある程度の比率で分けたとすると、その100台がすべて動いていれば生成するtokenはすべて同じですし、必要な演算量は決まっているからです。
ただ、良くなるのはgoodputで、私たちが満たすべき、1秒当たり30 token以上出なければならないという条件を満たせるthroughput、つまりその条件を満たすthroughputが上がるわけです。これは非常に大きく上がります。なので最近は、皆これを非常に多く使っています。そこでdisaggregationの効果がいつ大きく、いつ小さいかを見ると、効果を大きくするには入力が長く出力が短いとprefillの比重が大きくなり、decodeが大きく影響を受けるのでそのときに使えます。次に、SLOが厳しくて非常にタイトで、私たちはこれを必ず絶対に守らなければならない、というものがあれば、使うとよく、結局は高帯域のinterconnectが必要で、規模が大きい場合は、要約するとこうなります。
効果が小さい場合、逆にやや小規模ではそのままchunked prefill方式を使うほうが実際にはよりメリットがあると言えます。そして特にinterconnectの影響を大きく受けます。なのでNVLinkのような非常に高速なネットワークを備えているため、NVIDIA GPUにはこれが非常によく合いますが、それよりはるかに遅いインターフェースを持つAI半導体があるとすれば、このdisaggregationのメリットは思ったほど大きくないかもしれない、ということをお伝えできます。ここまでinference engineeringについての話をすべてお伝えしました。もっとありますが、私が重要だと考えるものをご紹介しました。
ロ・ジョンソク ほぼinference engineeringで必須の部分は、今日すべて扱ってくださいました。そのrooflineでcomputeとmemoryの間にどのような最適点を作るべきかをお話しいただき、その後、interactivityとthroughputの間のtrade-offについてお話しいただき、その後、さまざまな手法、この中に含まれるさまざまな手法を一通り扱ってくださいましたが、お話しいただいたすべてが、今存在するproductionにすべて入っているわけですよね。
その通りです。そして今日も進化し続けていて、こうしたことをすべて理解してこそ、チップも作れる。
agentic AIが生み出す新たなinference workload 83:33
イ・ジンウォン なのでこの次は、ここは単にLLMをチャットボットのように使ったり、あるいはreasoning程度で使うときの話で、agentic AI、私もAI agentを非常に多く使っていますが、agentic AIが来ると少し変わる話があるので、概念的にはこういうふうに変わり得るんだなと。なので最近、AI agentのworkloadを分析した論文が急にたくさん出ています。最近では、ここ下を見ると、8月にCopilotの2026年6月の1か月間におけるtraceをすべて分析して出した論文もありますし、次にTraceLabというものもありますが、こうした論文を少し参照しました。
用語を少し整理するために、session、request、そしてstepと見ると、sessionとは何かというと、私たちがAI agentを開始してagentが完全に終了するまでをsessionだと考えていただければよく、requestはその中で人がpromptを与え、AI agentがloopを回すわけです。LLMもcallし、toolもcallしながらloopを回して結果を出すまでが1回のrequestです。すると人がそれを再び見てfeedbackを与え、また別の作業をさせるでしょう。次の作業がrequestになるわけです。なのでrequestの開始は常に人のpromptで始まるということ、そしてrequestの中でLLMも実行され、toolも実行され、このようにLLMやtoolを1回callすることをstepだと考えていただければよく、
統計を見ると、sessionは平均62.6分で、requestはsession一つ当たり約9.2個あります。request一つの中にはstepが約9回あるので、おおよそsession一つ当たりで計算すると約100回のstepが含まれていると考えていただければよいと思います。当然ですが、実際にLLMをcallするものの大部分、つまり約90%、この赤色の二つの90%はAIが呼び出していました。つまりAIを人よりAIのほうが多く使うわけです。人が promptを入力したときはそのとき一度だけ人によってLLMがcallされるので、agentがloopを回している間はagentがLLMを呼び出し続けるからです。
そしてこれは非常に多くのinteractionを経て、途中でreasoningする過程もあります。私たちがチャットボットとして使っていてreasoningへ進むにつれて考えるthinking tokenを非常に多く出すようになったじゃないですか。だから長さが長くなり、それだけ先ほど話したKV cacheの容量も大きくなりましたが、今ではreasoningするLLMの呼び出しがこのagentの先ほどの一回のstepに入ってしまうんです。そうするとそこでまた何倍にもなるでしょう。このLLMが実行されるときに見るとその前に積まれていたKV cacheを読み込むのがほとんどで、11万9千個のtokenはprefixから、つまり以前に計算したKV cacheを読み込むもので、新たに追加されたものは875個で、それによって出るoutput tokenは214個です。100分の1程度じゃないですか。だからその程度まで再び読み込むことが非常に重要になりました。
そしてもう一つ重要なのは、このすべてのworkloadがheavy-tailです。私たちが言うlong-tailですが、そのtailが非常に大きな影響を与えるheavy-tailなんです。だからworst caseを無視するとagentサービスは破綻します。だからworst caseを常に考慮しなければならず、それがよく分かるのが中央値と平均のskewがほぼ15倍も開くほどです。平日の利用と週末の利用のようなものも分析してありますが、平日は当然、利用量がはるかに多く、sessionのようなものの数も多いですが、週末はその数が少ない代わりに、session当たりのiterationがはるかに多く回ります。だから当然、人々がより複雑なjobを週末に走らせて家に帰ったりするからだと予想できますし、その一つのsessionの中を分析してみると
人間が生む待ち時間とKV cacheのゴールデンタイム 87:22
イ・ジンウォン requestとrequestの間に人が判断してAIが出した結果を理解し、再び次の要求を送るまでに時間があるでしょう。普段、私の場合もagentに仕事をさせておいて別のagentを使ったり別の仕事をしてから戻ってみると、もう終わっているなと思って確認するので、人がAIが続けていることを見続けているわけではないじゃないですか。ほとんどは別の仕事をしてから戻るのでその時間が多く無駄になり、だからsession全体の約92%を人が占めていて、toolがcallするのは4.8%、LLMは3.3%なので、ほぼ1対1と見れば、実際にこれらが使うのは8%で人が92%の時間を使っているんです。人がボトルネックということです。
でもこれは単に人がボトルネックだという意味だけではなく、そうするとこれらが先にtoolやLLMで作り出したKV cacheを、人がいつ戻ってくるか分からない状況でHBMという高価なmemoryにずっと保持しておかなければならないのか、という問題があります。だからsession内のrequestとrequestの間で人が待機する時間の中央値は25分です。25分間このKV cacheを保持していると非常に無駄なんです。そしてその間、居座ってその容量を占めているKV cache容量の中央値はおよそ40GB程度です。
だから大半は25分程度になると今はすべて追い出します。storageのような場所に送り、5分から10分がゴールデンタイムです。現在の分析では、その程度までは保持しておき、それ以上になるとこれをまた予測します。これは非常に軽量なmachine learningモデルを使ってこの人が10分以内に戻るか戻らないかを予測し、戻らなさそうなら早く追い出す方法も使いますが、精度は思ったより高いそうです。
チェ・スンジュン ユーザーごとに学習させるんですか？
イ・ジンウォン ユーザーごとにやるのか、単にどんな内容を見てやるのか。
パク・ジョンヒョン 簡単に想像してみると、寝る前にはものすごく長く走らせて寝に行き、朝起きるまでの時間がものすごく長いじゃないですか。だから何時に走らせたかも影響しそうですし、どんなタスクをさせたかも影響しそうですし、そういうものを軽く分類して行うだけでも精度はものすごく上がりそうではあります。
イ・ジンウォン その論文によると、何分後に戻ってくるかを予測するのは少し簡単ではないですが、早く戻るか早く戻らないかは、それでも予測がうまくいくほうです。
ロ・ジョンソク agent workloadはcompute-boundではなくとてつもなく全部memory-boundですね。boundという表現がむなしいほど、ただのmemory workですね。保持し続けるゲームですね。
イ・ジンウォン だから結局、再び読み込むのにもコストがかなりかかる。これをまた計算してみると、ここでcloudのサービスを借りて使うことを基準に計算してみると、60%がprefixを読む際に使うコストになる。次にこれを追い出したとき、ではこれを完全に削除した後、再びユーザーが戻ってきたときにKV cacheを再計算することもできるじゃないですか。あるいはCPUのDRAMやあるいはstorageに送った後、それを再び読み込む方法があるでしょう。その二つを比較したときどちらがより良いかというと、ほとんどの場合遠くにでも置いておいて読み込むほうが良いということです。再計算するには時間もかかりコストも高いのですが、これを読み込むのは少し時間がかかっても、それよりははるかに短いためこちらのほうが有利で、多くはこちらに向かっています。
再計算せずに再読み込みするKV cacheと階層型メモリ 90:10
イ・ジンウォン そしてこれを読み込んでいる間に何らかの演算ができればそれが完全に隠せるので、さらに良い、そういう話です。これからはmemoryもhierarchicalに使う必要があり、SRAM、HBM、DDR、SSDあるいはhigh-bandwidth flashのようなものも最近よく話題になっていますが、こうしたものまで役割をきちんと分けてKV cacheの中間成果物をどうschedulingして、いつどこへ送り、いつ再び持ってくるかをうまく行うことがagentic AIで新たに浮上している非常に重要なことです。そうすると、これをまたうまく処理してくれるopen-source、先ほどのvLLMやSGLangのようなソフトウェアが今後たくさん生まれてくるでしょう。そのためボトルネックはcomputeにあったりmemoryにあったりpowerになったりこのように絶えず行き来していて、そのたびに答えが変わり、人々は一方にボトルネックがあれば何らかの方法で解決しようとする、という話を今日お伝えしたかったのです。
ロ・ジョンソク 人々がものすごく大量の仕事をさせるのですが、その仕事の大部分はcloudの立場から見ると覚えているゲームであって、計算量は非常に少ないとおっしゃったので、そうすると、そこで私たちの今後のメモリ企業に対する需要はしばらくはさらに増えていくということですし、またその中でこれらの企業も最適化を多く行うためこのようなinference workを提供する企業のマージンは相当な部分で引き続き高く維持される可能性が高いと思います。
AnthropicとOpenAIは収益性が引き続き良くなりそうです。
チェ・スンジュン 例えばcontext agent workflowを行っていてcontextが圧縮されました。そうすると、圧縮された最終KVだけを持っておくということです。それ以前のものを残しておく理由はないわけです。
イ・ジンウォン 圧縮されたKVだけを持つことになります。それが圧縮されることで壊れてしまうものもあり得ます。そのため、そのときは再び計算をしなければならない場合も生じます。
ロ・ジョンソク しかしcompactingはモデルが定めた限界のためにどうしても起こるものですから、重要なのはcloudごとに提供するmax コンテキスト長が今は異なるでしょう。あるものはOpus 1M、1M、100万トークンをコンテキスト長として提供していますがあるものは27万トークンしか提供していないので、そういうものは完全に異なるfarmを使っているということなのでそれに応じてchargingする金額も完全に異なる形で設定されているでしょう。
パク・ジョンヒョン HyperAccelという会社の立場からどのような見通しや将来をどのように見ていらっしゃるのか気になります。なぜならHyperAccelもcompute、memory、powerというすべてのインフラに必要な新しいチップを作っていらっしゃり、チップとcomputing platformそのものを作っていらっしゃるからです。しかしHyperAccel以外にも、当然ながら非常に多くのチームがそうしたことをすべて解決しようとしているでしょう。そうするとinference hardwareという市場自体が今後も拡大し続け、NVIDIA GPUが現在もinference市場で最も多く使われていますが、結局はGroqを含めてGroqであれCerebrasであれTPUであれ、さまざまなチップがすべて入ってくることで多くの部分を代替していくと思います。最近聞いた話は何でしたっけ？GLM-5.3 Flash、それも完全に中国製チップでinferenceしたと聞いたのですが。そう発表していたと思います。今後その市場の地形がどのように変わっていくと思われるのか、気になります。
GPUとLPUが融合するheterogeneous computingの未来 94:21
イ・ジンウォン 非常に良い質問で、NVIDIAがGroqを買収した理由が先ほどのrooflineグラフを非常に多様なAI半導体やGPUを含めてハードウェアのグラフだと言ったので、描いてみたのですが。ここで私が濃くしておいたVera Rubinはこのような形で、Groqはこのような形です。先ほど下へ見ていくとこちらのほうがはるかにbandwidthが高いことが上に位置しているので分かるでしょう。そのため先ほど私がprefill-decode disaggregationについてお話ししましたが、このVera Rubinファミリーでは、それをLPXと呼びます。LPXが果たす役割はdisaggregationにおいてもprefillはすべてRubin GPUで行い、decodeもすべてRubin GPUで行いますがattentionまでは行い、FFNだけGroqのLPXで行うということです。しかしこちらはarithmetic intensityのridge pointがここでは8と出ていますね。一桁ということです。そのためこの青色よりもこの赤色のグラフが上にある、arithmetic intensityが相対的にそれほど高くない領域でGroqのLPUに利点があるのです。そのため先ほどのInferenceXも右側にその領域が配置されるわけです。
ただしGroqはSRAMだけを使っていて、500MB程度なのですが、今回、このRubinファミリーに入ったチップがでは500MBはものすごく小さいサイズですよね。なので、ここに先ほど話したようなKVをすべて入れることはできないでしょう。当然、入れようとすればものすごく多くのチップを使うことになります。そうするとFFNにはKVがないですよね。なので、そこに適しているという点が一つあり、もう一つは、それでもFFNは先ほどbatchを増やせばbatchを増やした分だけarithmetic intensityを高められる領域なのでそこには適していないのではないかとお考えになるかもしれませんが、MoEが登場するとexpertごとにbatchが分かれて入ることになりますよね。なのでexpert一つの立場から見ると相対的にbatch sizeが小さくなります。そのため、そこではarithmetic intensityが依然として低くなります。だから、そこに非常に適したsolutionになるわけです。互いにKVを渡す必要もなく、そのデータをGPUとLPUの間で転送する必要もほとんどなく、このトークンだけが行き来すればよいため非常に賢明なsolutionです。
したがって、明確に優れた特性があればそれがこのinference pipeline、serving pipelineの中に入ることができます。例えば、今後のagentic AIの特性に応じて私たちが外部メモリからデータを非常に速く読み込めるとか、外部に非常に大きなメモリがこのチップの近くに付いているとか、こうした特性があればKVをそちらに送って一種の一部の演算も行いながら保存領域として使うこともできるでしょう。そういう何らかの特性があってそれがこのpipelineにうまく合うとき非常にheterogeneousに動作するそういう世界が来るでしょう。homogeneousなcomputingはほぼ終わりつつあり、何であれ得意なものを見つけて組み込む作業が、今後行われるでしょう。そのため、私たちHyperAccelも最初の製品では価格と電力が非常に大きなボトルネックだと考え、そこに焦点を当てたとすれば、今、次の製品を準備しているところです。agentic AIの特性にうまく合う方向で準備しています。
AIが変える半導体設計と検証 97:54
チェ・スンジュン 私は今回のJalapeñoもそうですし、他のものにもそういうニュアンスがありますが、チップデザインにおけるRL タスクがverifiableな領域へ進んでいるのかが気になるんです。
イ・ジンウォン それも非常に興味深く、私も最も関心のある部分の一つです。なぜなら、私も口癖のようにあと3年ほど経てば私はこの仕事ができなくなる気がするという話をよくしているのですが、AIが私よりはるかにうまくやると信じているからです。その中で、ある程度幸いなのはFPGAで作って論文も出されたようですが、思った以上に非常にうまくいっています。verifiableな領域もかなり多くあります。全体が一度に入ってくるのは簡単ではありませんが、すでに設計の一部、そして特に検証すること、自分が設計したものが正しく動作するかを検証することは完全にsoftwareの領域です。しかし設計はhardwareを考慮してRTL、Verilogのようなlanguageでcodingすることですが、hardware-awareにcodingしなければならないため考慮すべきことはありますが、結果が良いのか、うまく作れたのか、うまく作れなかったのかも評価する基準が場合によって大きく変わり得るため難しい部分はありますが、とにかくmetricがないわけではないためverifiableだと考えています。私はこれは時間の問題だと思いますが、結局、設計だけをうまくやればよいのか、検証だけをうまくやればよいのかという領域ではなく、それを基にphysicallyにtransistor levelでlayout、P&R、placeand routeもうまく行わなければならず、非常に複雑な問題がたくさんあります。
ですから、そうしたものがすべて組み合わさって良い半導体が生まれ、正しく動作する半導体が生まれるので、少し時間はかかると思いますが、それほど先のことではないとも思います。なのでOpenAIを見てもsoftwareのようなもの、特にCUDAの話も多くしながらCUDAに関連するものを自分たちがCodexを使ってすぐにすべて作ったと言っていました。例えばMLAのようなものにはkernelがなかったのですが、自分たちがDeepSeekを載せるためにCodexがさっとすべて作った、という話もしていましたが、そういうものを見ると、そう遠くない気がします。
特殊用途AIチップの群雄割拠時代 100:08
パク・ジョンヒョン 私も話を聞いていて思うのですが、もともとhardwareを製造すること自体、一度作るとコストが非常に大きいため、tape-outする前にverificationするsimulation softwareなどが非常に整っていますよね。なのでAIがverificationを実行できるツールがsoftware上によく準備されていてそうしたものをうまく作り出せそうですし、ジンウォンさんが説明してくださったようにhardwareにはどのようなtrade-offがあるかによってGroqのように、あのような特別な目的のためのhardwareが次々と登場するようになり、LLMという一つのタスクの中でも分けてtrade-offに合わせて仕事を切り出してこれはGroqに、これはGPUに、これはCerebrasに、これは何らかのhardwareに、といったふうに分けられるのでhardwareもより早く登場し、多様なものがより早く登場することもでき、仕事も切り分けられるし、こういう春秋戦国時代と言うべきでしょうか？一つのGPUがすべての仕事をするのではなく、まるでCPUだけがあってGPUがゲームのために登場したことと似ていると思いますね。特殊目的のhardwareが次々と登場する時代になるのではないか、私も質問と回答を聞きながらとてもよく聞かせていただきました。
チェ・スンジュン はい、面白かったです。知っている範囲でも面白いことがあり、また新たに学ぶ
ロ・ジョンソク こともありました。そして教えていただいたこれらの要素が今日も絶えずフロンティアに向かって進んでいるわけですね。モデルだけがフロンティアに向かうのではなく、このインフラも絶えずフロンティアへ、フロンティアへ向かっていると見ればよいでしょう。
チェ・スンジュン 韓国企業であるHyperAccelを含めてこのような分野でも走り続けてくださるのがうれしく、良いニュースだと思います。
エンディングと加速するAIインフラの産業化 101:42
ロ・ジョンソク こうした内容は今後も新しいチップが登場したり、あるいはJensenも登場するたびにAI factoryの話をしながらその構成を絶えず変えていっていますよね。そしてNVIDIAが持っていた優位性が先ほどジンウォンさんがお話しくださったように要素ごとに数多くの企業がやって来てすべて攻め込んで切り取っていっているようなイメージもあるんです。ですから今後また1年でどう変わるのか本当に面白そうです。私たちがちょうど1年前を思い出してみてもこうしたinferenceの話ではなく、単に新しいモデルが出ました、という話をしていたんです。trainingはどうやったのだろう、これはどう作ったのだろう。推論モデルの話をしていたのはわずか1年半前です。ところが今はそういうことをすべて離れてこれが完全に産業化されたわけです。どうすれば利益の出るクラウドを作ってビジネスができるのか、という段階まで来ているのが隔世の感がありますし、この変化のスピードは月単位でさらに速くなるでしょうから気を引き締めてついていかなければならないと思います。
チェ・スンジュン 今週もいろいろなニュースがありましたがCursorとOpenAIが争うこともあり、NVIDIAとOpenAIが争うこともあり、さまざまなニュースがありました。ものすごい競争状況なんですね。
ロ・ジョンソク ところで私が最近しばしば受けている要望なのですが、researchやmodel engineeringをする目的ではなく単に投資目的だったり、あるいはこの変化をもっとよく理解したくて私たちが話しているTransformerや、あるいは今日ジンウォンCTOが教えてくださったinference token economicsなど、こうしたことについてもう少し深く学び、理解したいというそういう需要者の方々がいらっしゃいます。そこで、そういう需要者の方々がどれほどいるのか分からず、わずか数人のために私がそうしたイベントを作ることはできないので今日ここまでお聞きになった方の中で「私はもう少し深くこういうことを勉強してみたい」というそういう方がいらっしゃればコメントで意思表示をしていただけると幸いです。それでは、あらためて深く感謝いたします。
イ・ジンウォン お聞きいただき、ありがとうございます。
パク・ジョンヒョン とてもよく聞かせていただきました。
ロ・ジョンソク では今日はここで締めくくりたいと思います。ありがとうございます。
イ・ジンウォン はい、ありがとうございます。