レガシーHBM GPUにおけるバックエンド依存の安定性

1

背景と動機

ROCm 7.2 の公式サポートマトリクスには gfx900 は記載されていないが、実際のシステムでは残存コードやアーティファクトのパスを通じて実行できる場合がある。

学生や小規模な研究室にとって重要な問いは、「実行できるのか、安定しているのか、再現できるのか」である。

同一の Vega デバイス上に、条件を揃えたデュアルバックエンドのテスト環境を構築し、サポートポリシー・バックエンド選択・ランタイム挙動を切り分けた。

目的：「非サポート」と「使えない」は同じ意味ではないことを、証拠に基づいて説明する。

2

問題設定

旧世代の Vega GPU は、現行の ROCm ワークロードには一律に不適切であると扱われがちである。

成功・失敗の境界は、ディストリビューションのプリセット、ビルドターゲット、初期化バリデーション、バックエンドマクロ、ランタイム計算パスなど、さまざまなレイヤで決まる可能性がある。

問い：不安定性の原因は Vega 自体にあるのか、それとも条件を揃えたうえでの特定のバックエンドパスにあるのか？

3

調査で確認された事実

A. gfx900 ゲートマトリクス

レイヤ	gfx900 の現在の扱い	結果
公式マトリクス（ROCm 7.2）	GPU ターゲットリストに gfx900 なし	ブロック（公式範囲）
CMake フィルタ（ollama）	デフォルト正規表現で gfx900 を除外、`AMDGPU_TARGETS` による手動オーバーライドは可	デフォルトはブロック / 手動で許可
rocBLAS アーティファクト	`Kernels.so-000-gfx900.hsaco` が `/usr/lib/ollama/rocblas/library/` に存在	許可
ランナー初期化バリデーション	ディープ初期化プローブ（`GGML_CUDA_INIT=1`）：gfx900 を有効なエージェントとして認識	許可
ソースマクロ（`hip.h`, `common.cuh`）	`__gfx900__` → GCN5 分類を保持、dp4a パスあり	許可
ランタイム実行	ROCm/HIP：全 num_gpu 値で OK。Vulkan：`num_gpu≥1` で SIGSEGV	バックエンド依存

B. num_gpu セマンティクストレース

段階	コード上の位置	意味
Python クライアント	`ollama-python/_types.py:109`	ロード時オプション
Ollama CLI	`cmd/interactive.go:112`	「GPUに送るレイヤ数」
サーバ割り当て	`llm/server.go:992,1063`	requestedLayers = NumGPU
ランナーブリッジ	`llama/llama.go:266`	cparams.n_gpu_layers
llama.cpp	`include/llama.h:289`	「VRAMに格納されるレイヤ」

結論：num_gpu は「オフロードされるレイヤ数」であり、GPU デバイス数ではない。num_gpu≥2 はマルチ GPU を意味しない。

C. 関連文献（引用、本リポジトリ内では再現せず）

LLNL 差分テスト（arXiv:2410.09172）：60万以上の自動生成カーネルで NVIDIA V100 と AMD MI250 間の FP32 乖離が約9%。原因はベンダ固有の数学ライブラリ、コンパイラフラグ、HIPIFY の副産物。本研究のバックエンド意識型検証アプローチの動機づけ。
gem5 Vega モデリング（ウィスコンシン大マディソン校）：GPUFS モードで実 Linux カーネル + 未改変 amdkfd ドライバを実行。物理 Vega 56 に対し平均6%の誤差で検証済み。Vega の学術的信頼性を確立。
ROCm SDMA ワークアラウンド（AMD ドキュメント + LUMI レポート）：HSA_ENABLE_SDMA=0 は欠陥のある DMA を Blit カーネルフォールバックでバイパス（帯域幅約80%）。HSA_OVERRIDE_GFX_VERSION は非サポート GPU の実行を可能にする — 本実験で使用したオーバーライド。

※ 上記は外部参考文献。本ポスターにおけるすべての主張は、リポジトリ内の証拠（セクション 3A, 3B, 6）のみに基づく。

4

エンジニアリング上の課題

gfx900 は公式マトリクスとデフォルトのビルドフィルタで除外されているが、残存コードとアーティファクトにはまだ gfx900 の処理が残っている。
num_gpu は GPU 数と誤読されやすいが、コードトレースにより「オフロードされるレイヤ数」を意味することを確認した。
同一の Vega GPU で、同じモデル・同じプロンプトであっても、ROCm/HIP では成功し Vulkan では失敗する。
診断は「レガシー GPU は駄目」と一括りにするのではなく、レイヤごとの証拠に基づかなければならない。

5

証拠優先の調査戦略

レイヤ	介入内容	効果
L1: ディストリビューション / ビルド	サポートマトリクス、プリセット、ターゲットフィルタ、インストール済みアーティファクトの調査	gfx900 がどこでブロック・許可・部分的に保持されているかを特定
L2: API セマンティクス	クライアント → サーバ → ランナー → llama.cpp を通じて num_gpu をトレース	解釈を修正：オフロードレイヤ数であり、GPU 数ではない
L3: ランタイム比較	条件を揃えた ROCm（:11435）と Vulkan（:11434）のテストを実行	同一ハードウェアでのバックエンド固有の故障モードを分離
L4: 証拠の記録	構造化されたワークログ、ジャーナルトレース、バックエンドプローブ、rocm-smi、ollama ps	クラッシュの局所化と主張の再現性確保

アプローチ：楽観的な一度きりの成功ではなく、反証可能な診断と再現性を優先する。

6

実験結果

テスト環境

構成要素	仕様
GPU	AMD Radeon RX Vega 56（gfx900）、8 GB HBM2
OS / カーネル	EndeavourOS、カーネル 6.18.16-1-lts
ROCm パス	Ollama 0.17.5（:11435 経由）、library=ROCm、libggml-hip.so
Vulkan パス	Ollama 0.17.4（:11434 経由）、library=Vulkan、同一モデル・プロンプト
オーバーライド	`HSA_OVERRIDE_GFX_VERSION=9.0.0`（ROCm サービスのみ）

※ Vulkan=0.17.4 vs ROCm=0.17.5：バージョン差はデュアルインストール構成に起因。いずれもインストールされた状態のままテスト。

条件を揃えた比較結果（qwen3.5:2b、NUM_PREDICT=512）

num_gpu	ROCm（:11435）	Vulkan（:11434）
0（CPU のみ）	OK（46.7s、eval_count=512）	OK
1	OK（48.7s、eval_count=512）	FAIL（HTTP 500、SIGSEGV）
2	OK（47.7s、eval_count=512）	FAIL（HTTP 500、SIGSEGV）
-1（全レイヤ）	OK（44.3s、eval_count=512）	FAIL（HTTP 500、SIGSEGV）

Vulkan は num_gpu=0（GPU オフロードなし）で成功。失敗は num_gpu≥1（GPU 計算パスがアクティブ）の場合にのみ発生。
ROCm の結果は本テスト範囲内（単一モデル、短い固定実行）のもの。より広範なワークロードでは異なる結果となる可能性がある。
モデル依存性を確認：tinyllama は以前のテストで Vulkan でも成功（20/20 OK）、qwen3.5:2b は SIGSEGV を発生。

クラッシュの局所化

Vulkan の SIGSEGV は ggml_backend_sched_graph_compute_async → computeBatch で発生。モデルのロード完了後、ランナーの起動後であることから、計算フェーズの故障であり、初期化の失敗ではない。

故障仮説の検証

仮説	期待される証拠	観測結果
Vega は全般的に使用不能	同一 GPU で両バックエンドとも失敗	反証：ROCm/HIP は成功した
num_gpu は GPU 数を意味する	失敗がマルチ GPU エントリを示唆	反証：コードトレースでオフロードレイヤ数を確認
Vulkan 計算パスの不安定性	ロードは OK、ランナー起動後の計算スタックでクラッシュ	一致

gfx900 がまだ動作する理由

ROCm の変更履歴には「デフォルトではビルドされなくなった」と記載されているが、「禁止された」とは書かれていない。ローカルインストールで gfx900 の hsaco アーティファクトと libggml-hip.so 内の文字列が存在することを確認した。

解釈：「非サポート」＝保証なし・未テスト、であって「不可能」ではない。

制限事項と今後の課題

制限事項：条件を揃えた比較は短い固定実行（1エポック、512トークン）で単一モデル（qwen3.5:2b）のみ。Vulkan と ROCm の Ollama バージョンが異なる（0.17.4 vs 0.17.5）。tinyllama は Vulkan で qwen3.5 と異なる挙動を示し、モデル依存の故障条件が存在する。本テスト範囲を超えた一般化は、追加検証なしには行うべきでない。

今後の課題：マルチエポックストレステスト、追加モデル（llm-jp、phi-3）、ROCm バージョン比較（6.x vs 7.x）、GGML_CUDA_NO_PEER_COPY 実験によるオフロードパス故障メカニズムの分離。再現性インフラ（15件の文書化されたワークアラウンドマトリクス）をリポジトリで公開中。

7

まとめと主要メッセージ

✅

サポート状況 ≠ 実行可能性
公式の除外は、不可能を意味しない。ゲートマトリクスでは6層中5層が gfx900 の実行を許可。残存コードパスと出荷済みアーティファクトにより、部分的な実行が可能。

💡

バックエンドの選択が支配的
qwen3.5:2b を用いた同一 Vega デバイスで、ROCm/HIP はテスト範囲内の全 num_gpu 条件で成功。Vulkan は num_gpu≥1（GPU オフロードがアクティブ）で失敗。故障はバックエンド固有であり、アーキテクチャ全体の問題ではない。モデル依存性（tinyllama vs qwen）も存在する。

🔬

主張の前に再現性
すべての主張は、特定の run_id とコードトレースに裏付けられている。ゲートマトリクスとワークアラウンドマトリクス（15件）をリポジトリで公開。

非サポート ≠ 不可能｜レガシー ≠ 劣等｜バックエンドの選択が重要