PaPoo
cover
technews
Author
technews
世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

AMDでもここまで速い。GLM-5.2を“安く速く”動かしたWaferの話

Waferの記事は、タイトルの通りかなりストレートです。要するに「1ドルあたりの性能、まだ伸ばせるし、しかも安くできる」という話です。対象はGLM-5.2というオープン系の大規模言語モデルで、これをAMD MI355X上でかなりうまく動かした、という内容でした。

image_0002.svg

まず数字が強いです。Waferは、20k input / 1k output、cache hit rate 60% という条件で、1ノードあたり2626 tok/sを記録したとしています。tok/s は tokens per second、つまり1秒あたりに何トークン処理できるかという性能指標です。LLM界隈では、ざっくり言えば「どれだけたくさん文章をさばけるか」の目安だと思えばよいです。さらに single stream では 213 tok/s を出しています。これもかなり速い部類です。

面白いのは、Waferがこの結果を「絶対性能の王者」ではなく、「性能/価格で勝った」と位置づけている点です。実際、記事ではAMD MI355XはNVIDIAのB300やB200系よりもかなり安い、という前提で話が進みます。GPUの世界はつい「最速はどれか」になりがちですが、実務では結局「いくらでどれだけ捌けるか」が大事です。そこを真正面から押しているのが、この投稿の気持ちよさでもあります。

image_0003.svg

ただし、AMDでフロンティア級モデルを回すのは、話ほど簡単ではありません。ここが重要です。NVIDIAはCUDAという強力なソフトウェア基盤があり、モデル公開と同時に“とりあえず動く”ことが多い。一方でAMDのROCm環境では、最新モデルへの day-0 support、つまり「出た日にそのまま動く」状態が揃っていないことがある。Waferもそこを認めていて、AMDはシリコン自体は強いのに、ソフトウェア面でつまずきやすい、と書いています。かなり率直ですし、たぶん現場感としてはかなり正直な指摘だと思います。

image_0004.svg

この話を支えたのが、quantization と inference framework の選定です。quantization は、モデルの重みを軽くして、メモリ使用量や計算量を減らす工夫です。雑に言うと「精度をなるべく落とさず、モデルを小さく速くする技術」です。WaferはGLM-5.2のbf16版を、AMD Quark を使って MXFP4 に量子化しています。bf16 は比較的高精度な形式、MXFP4 はかなり軽い4bit系の形式です。普通なら軽くすると精度が落ちるのでは、と思いますが、記事では GSM8K や GPQA-Diamond、tau2 でほぼ同等の結果だったとしています。これは素直にすごいです。軽くしても性能が保てるなら、まさに“おいしい”ところだけ取れますから。

ただ、量子化しただけでは終わりません。次にどの inference engine を使うか、つまりどの実行基盤で推論するかが効いてきます。Waferは vLLM、ATOM、sglang を比較し、最終的に sglang を選んでいます。理由は、vLLM では MXFP4 と GLM系の経路がうまく噛み合わず、ATOM は長いコンテキストで出力が悪化したから。こういう話は地味ですが、実務ではかなり本質的です。性能は「理論上の最強フレームワーク」ではなく、「そのモデルに対して、今うまく噛むもの」が勝つことが多いからです。

image_0005.svg

さらに面白いのが speculative decode です。これは、モデルが次に出す単語を“先回りして”仮に進めておくことで、生成を速くする仕組みです。人間でいうと、相手の言葉を聞き終える前に「たぶん次はこれだな」と先に下書きを進める感じです。Waferはこれを使おうとしたのですが、ROCm向けのイメージではそのまま動かなかった。そこで、MTP head の量子化指定のずれを修正したり、ROCm で必要なガードを足したりして、ようやく動かしたと書いています。修正内容はかなり細かいのですが、要は「小さな対応の積み重ねで3倍近い single stream throughput を取った」ということです。こういう地味な一手が、最終的にはとてつもなく効くんですよね。

image_0006.webp

もうひとつ印象的なのは、aggregate throughput と single stream の話を分けて見ていることです。単一リクエストを速く返すのと、複数リクエストをまとめて大量にさばくのは、実は別競技です。Waferの workload は prefill bound、つまり入力を読み込んで理解する前半部分がボトルネックだったので、decode 側の高速化だけでは足りなかった。そこで TP8 から TP4×DP2 に切り替え、さらに MoE kernel selection をチューニングして、2626 tok/s/node まで引き上げた、と説明しています。

ここで出てくる MoE は Mixture of Experts の略です。モデルの中に複数の“専門家”を持たせて、入力ごとに一部だけ使う仕組みです。うまく動くと効率が良いのですが、実装がややこしい。WaferはGLM-5.2のfp4 MoEが、ある場面で slow fallback に落ちていたのを見つけ、自前で最適化したようです。こういうのを見ると、「モデルの性能」って実は半分以上、実装と運用の芸術だなと思います。論文の数値だけでは終わらない世界です。

image_0007.webp

記事の締めくくりはわりと明快です。今回の成果は、カスタムkernelを新規に大量開発したというより、既存のフレームワークの穴を埋め、量子化と speculative decode をきちんと通し、MoE のパスを整えた結果だとしています。つまり、AMDでのSOTAは、もはや「ソフトウェアがまだ弱いから難しい」のではなく、「サポートと調整があればかなり戦える」段階に来ている、という見立てです。

image_0008.webp

個人的には、この記事はかなり示唆的だと思います。NVIDIA一強がすぐに崩れる、という話ではもちろんないのですが、少なくとも「高性能LLM = NVIDIAしか無理」という空気は、じわじわ薄れている。しかもその変化は、大げさなブレイクスルーより、こういう地道なROCm修正やフレームワーク選定の積み重ねで進んでいる。そこがいちばんリアルです。

Waferは以前からAMD推しを公言していますが、今回の投稿はその主張をかなり具体的に裏づけた形です。しかも「custom kernel を書かずにここまで来た」というのが地味に重い。つまり、必要なのは魔法ではなく、ちゃんと動くソフトウェアの層なのだ、ということです。GPUの勝負は、もうハードだけでは決まりません。どれだけ早く“使える形”にするか。そこに勝敗が移ってきているのだと思います。

image_0009.svg


image_0010.svg

参考: Performance per dollar is getting faster and cheaper | Wafer

同じ著者の記事