RyzenAI MAX+395 のボトルネックは演算能力か?それともメモリ帯域か? ～Radeon8060S (GFX1151)でLLMパフォーマンスを上げることは可能か?～
こんにちはRcatです。
今回はローカルLLMの話です。
こちらの記事で紹介しているように、モンスターAPUマシンでLLMを使っているのですが、バイブコーディングを試そうとしたらかなりギリギリな感じでした。
さて、少しでもパフォーマンスを改善できないか考えていきます。
はじめに
利用規約
情報や作品の活用時は事前に利用規約をご確認ください。
コメントについて
利用規約のガイドラインを確認の上コメントしてください。
則っていないコメントは削除します。
概要
ローカルLLMの限界
ローカルLLMにはいくつもの壁があります
VRAM
まずはこれが一番デカいですね。コンシューマー向け最上級のRTXですら32Gしかない。
コンテキスト分考えると20B前後が限界。処理能力
VRAMがないならCPUでやればいいじゃない♪
→処理能力が足りません。または帯域が足りません。モデルの賢さ
最近はかなり進歩しているものの、依然として複雑なタスクは10Bや30BのMoEではキツイ。
でも大きくしようとするとメモリの壁に引っかかる
で、私の環境だとどこまで行けるかですが、演算時10Bまでが快適の限界。これ以上パラメータが増えると遅くてストレス。自動処理ならいいけども、バイブコーディングなんかとてもじゃないけどやってられない。自分で書いた方が早い。
環境
iGPU: Radeon8060S
VRAM: 統合メモリ(DDR5 8000MHz 128GB)
OS: Ubuntu 24.04
推論: llama.cpp
バックエンド: ROCm7.2
例えば、Qwen3.5 122B-A10 Q4の場合、下記のような感じ。
RooCodeでコンテキスト圧縮が入ると10分待ち。
122Bモデルでも、A10のおかげで何とか使える。Qwen3.5のこのラインナップは個人勢でギリギリ運用可能な最上位モデルだと思う。マジ感謝しかない。
何がボトルネックなのか
さて、いろいろ調べたんですが、どうも計算能力がネックとは限らないようです。
具体的には、メモリの転送速度が大事な場合もあるようです。
メモリ帯域
LLMの膨大なパラメータと長文のコンテキストを評価するには、すべてのパラメータと今までの文脈を計算しないと次のトークンが出ません。
つまり、1文字出すのにGPUにモデル全読み込み+KVキャッシュロードが入ります。
なので、実は演算能力ではなく転送速度がネックになっている可能性がまだ残されています。
私の実機のEVO-X2はDDR5 8000MHzです。
演算能力
私の場合はいくらモンスターでもAPUなので、デカいヒートシンク積んだRTX5000シリーズ上位には敵いません。
なので、演算能力が不足しているという可能性ももちろんあります。
確認する
確認方法
これは簡単で、KVキャッシュを量子化して速度がどう変わるか見ます。
メモリ帯域不足の場合
転送量が減るのでパフォーマンスが向上します演算能力不足の場合
デクオンタイズのオーバーヘッドが追加で入るのでパフォーマンスがさらに落ちます。
Q4とかを計算する直前にF16とかに直すらしい。釣り合ってた場合
何も起きません
実証
現在使用している122B-A10を使い確認します。
ある程度長文を読ませてパフォーマンスを測定します。
使う長文Rcat999利用規約。それなりのトークン数になるはず。これを要約させます。具体的に半分くらいにといいましょうか。
初期状態(f16)
私の規約は1万トークン以上あるそうですw
事前評価142t/s 出力18t/s
KV量子化状態
llama.cppの起動オプションにこれを付けます。これでキャッシュがF16からINT4になりサイズは1/4です。
メモリがネックならこれで速くなり、演算がネックなら遅くなるはず。
--cache-type-k q4_0 --cache-type-v q4_0
結果
評価:138t/s 出力:15.5t/s
遅くなってる・・・
というわけで、EVO-X2でQwen3.5 122B-Q4を用いた場合、Radeon8060Sは処理能力がネックになっていることがわかりました。
ほかの量子化はどうか?
iq4_nl
なんだこのGPUのサボり具合は…話になりません!
q8_0
f16とほぼ同じ。
なんでかgeminiに聞いたところ、q4は8ビットに2データ入ってるので、取り出し計算が余計にいるからだそう。確かに納得。
デクオンタイズがq8のほうが楽なのか。でもちょっと遅いので、やはりメモリ帯域ではなく計算能力っぽいな。
評価141 出力17.3
この程度の速度低下でキャッシュサイズ半分なら受け入れられる。
まぁこれもGoogleが発表した1Bitキャッシュ実装までの短期だが。
あれは演算速度も上がるらしいのでかなり期待してる。
モデル自体で確認する
先ほどは同じモデルで、KV量子化状態で見てきましたが、次はより影響の大きいモデル本体で行きます。
さすがに大きすぎるので、Qwen3.6 27Bで見ます。
まずはQ4 KM。密モデルなので遅いですね。
次にQ8。出力速度が30%程度低下しました。
注目すべきは、プレフィル速度変わってないことですね。
これ、パラメータ数依存ということになりそうですね。
上記から言えることは、このクラスのモデルだとデコード時はメモリに支配されていると考えてよさそうです。
ちなみにサイズはこちら。1.7倍差ですね。
速度低下が30%程度にとどまったことはたぶんQ8とQ4の変換演算がQ4で足を引っ張っているのでしょう。完全にメモリならもっと早くなるはずです。
まとめ
EXO-X2環境でLLMをRadeon8060S(GFX1151)でllama.cppのROCmビルドで動かす場合、ボトルネックはどこを注目するかで変わりそうです。
初回の入力を秒で理解してほしいのであれば演算能力で、出力を重視するのであればメモリ帯域ですね。
また、量子化によるオーバーヘッドが無視できない程度には演算能力がネックになっていると感じました。
モデルの1bit量子化（Bonsai）とkvキャッシュ(TurboQuant)の1bit量子化の双方の技術が搭載された場合、出力は早くなるかもしれませんが、プレフィルは変わらないかもしれないですね。
リンク集
感想投稿フォーム
コメントは公開で恥ずかしい!! Rcatだけに送りたい人向け
