Strix Halo向けllama.cppフォーク検証記録：Vulkan vs ROCmと実測の注意点

きっかけ

Strix Halo 向けに最適化されているというフォーク「strix-llama.cpp（Vulkan）」の README を読みました。そこには、MoE モデルのプロンプト処理が「+89%」になると書かれていました。そこで、既存の公式 llama.cpp より本当に速くなるのかを確かめてみることにしました。あわせて、ROCm 版である「lemonade（llamacpp-rocm）」の最新状況についても調べてみました。

学んだこと

• strix-llama.cpp について
  • Releases が空だったため、ソースからビルドして検証しました。結果として、pp512（プロンプト処理）は公式 b11707 より 19% 遅く、tg128（トークン生成）は +1.5% という結果にとどまりました。
  • 遅くなった原因は、このフォークのベースが upstream の約900ビルド前と古いためだと考えています。
  • また、README で効果が大きいとされていた最適化（LDS pad、GGML_VK_DENSE_WAVE32）は、実は RADV（Linux）専用でした。Windows の AMD 公式ドライバーでは機能しないことを、ソースコードを読んで確認しました。
• lemonade b1318 について
  • これまで「安定版」として推奨していましたが、perplexity（モデルの予測性能の指標）を測ってみると正常値の約40倍に達しており、出力が壊れていることが判明しました。これは b1298 以降の gfx1151 で発生している既知の不具合（issue #123）に該当するようです。
• lemonade 最新の b1353 について
  • 出力自体は正常でした。しかし、速度面では Vulkan に及ばず、tg も回によって 39〜71 t/s と大きくブレる結果となりました。

自分なりの理解

ベンチマーク上の速度と、出力の正しさはまったくの別物として検証しなければならないと痛感しました。lemonade b1318 は速度のブレが小さかったため「安定している」としてしまっていましたが、実際には内部の計算が破綻していました。もしかすると、速く見えていたのは必要な同期処理を省いてしまっていたからかもしれません。

また、README に記載されている数値は、計測された環境（OS、ドライバー、比較対象）とセットで読まなければ、自分の環境で再現するとは限りません。「最適化版」や「最新版」という言葉だけで速くなると盲信せず、自分の環境で、同一条件の比較対象と並べて実測するまでは、すべて仮説として扱うべきだと学びました。

実践へのつなげ方

• 出力の正しさを必ず検証する
  新しいビルドやバックエンドを試す際は、速度計測だけでなく、llama-perplexity を使って基準（Vulkan）と同じ値が出ているかを必ず確認します。短いプロンプトで少し動かした程度では、出力の破損には気づけません。
• 前提条件をコードレベルで確認する
  外部ツールやフォークを採用する際は、README の主張がどの環境を前提にしているのかを確かめます。可能であればコードまで読み、自分の環境でその最適化が有効になる条件を満たしているかチェックします。
• あやふやなものは残さない
  正しさが確認できないビルドは「たぶん大丈夫だろう」と放置せず、誤用を防ぐために削除します。また、その判断に至った経緯をドキュメントに残し、後から自分や他の人が読んだとき（AI を含む）にも取り違えが起きないようにします。

次に試すこと

WSL2 / Linux（RADV）環境での再検証 Windows では動かなかった strix-llama.cpp の最適化（+89%）が、本領を発揮する Linux 環境で本当に再現するのかを検討します。