萌えハッカーニュースリーダー

2025/10/17 18:51 Compiler optimizations for 5.8ms GPT-OSS-120B inference (not on GPUs)

出典: https://furiosa.ai/blog/serving-gpt-oss-120b-at-5-8-ms-tpot-with-two-rngd-cards-compiler-optimizations-in-practice
hakase
博士

やっほー、ロボ子! OpenAIとFuriosa AIが協業して、RNGDチップでgpt-oss-120bを動かしたらしいのじゃ!

roboko
ロボ子

それはすごいですね、博士! 1出力トークンあたり5.8msで、電力効率も180W未満とは驚きです。

hakase
博士

そうじゃろ! RNGDチップって、LLMとかエージェントAIの推論向けに作られたAIアクセラレータらしいぞ。独自のTCPアーキテクチャで、利用率を高めてデータ移動を最小限に抑えるのがミソらしい。

roboko
ロボ子

各カードに48GBのHBM3と256MBのSRAMが搭載されていて、512TFLOPSのFP8演算ができるんですね。スペックもすごい。

hakase
博士

しかも、gpt-oss-120bのMLPブロックで使われてるMXFP4っていう4ビット浮動小数点形式、RNGD設計時にはなかったから、ソフトウェアで頑張ってハードウェアパイプラインに繋げたらしいぞ。

roboko
ロボ子

FP4からFP8への変換にベクトル化されたテーブルルックアップを使って、FP8からFP32へのキャストにはハードウェアテンソルユニットのキャストパスを使うんですね。ビット単位の演算でスケールファクターを乗算するのも効率的そうです。

hakase
博士

そうそう! コンパイラの最適化もすごいんじゃ。小さなテンソルの効率的な転送のためにDRAMレイアウトを調整したり、データ移動なしでattention sinkみたいな演算子をサポートしたり。

roboko
ロボ子

MoEカーネル(gpt-fastスタイル)も使われているんですね。128の専門家を持つMoEモデルで、トークンごとに4つがアクティブってことは、選択された専門家のパラメータだけを高速にロードする必要があるんですね。

hakase
博士

その通り! 間接アクセスを最適化して、HBMパフォーマンスモデリングで動的アドレスに対してもハードウェアの最大有効バンド幅に近いMoE重みをロードするんじゃ。

roboko
ロボ子

データレイアウトの共同最適化も重要ですね。間接アクセスと行列乗算の両方にメリットがあるレイアウトを探索するんですね。

hakase
博士

gpt-oss-120bは、モデルパラメータとかKVキャッシュとかアクティベーションを考えると、少なくとも60GBのメモリが必要らしいから、2つのRNGDチップでTensor Parallelism(TP)を選んだのも納得じゃ。

roboko
ロボ子

TPはレイテンシを削減して、EPはスループットを向上させるんですね。デモではバッチが小さくて、トークンごとに4つの専門家がアクティブだから、TPに焦点を当てた最適化を優先したんですね。

hakase
博士

チップ間reduce-scatterの直前に、オンチップデータを緊密にパックして転送効率を上げたり、デコードでは計算とデータ移動をレイヤー境界を越えて融合してレイテンシの無駄を削減したり、工夫がいっぱいじゃ。

roboko
ロボ子

新しいフォーマット(MXFP4)を既存のハードウェアパイプラインにスムーズに統合して、データ移動の観点からMoEボトルネックに対処したんですね。コンパイラスタックの予測可能性、ハードウェアフレンドリーなコード生成、レイテンシ中心のスケジューリングでTPOTを大幅に削減した、と。

hakase
博士

つまり、Furiosa AIはOpenAIとの協業で、めっちゃ頑張ったってことじゃ!

roboko
ロボ子

そうですね! 博士、今日の解説もとても分かりやすかったです!

hakase
博士

褒められた! ところでロボ子、RNGDチップって、なんだか美味しそうな名前じゃない?

roboko
ロボ子

博士、それはちょっと… AIチップですよ! 食べられません!

⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。

Search