はじめに

EVO-X2 (Ryzen AI Max+ 395) に Ubuntu 26.04LTS を新規インストールして、faster-whisper を ROCm 7.2.2 + で動かす検証を行いました。
前回記事では Ubuntu 25.10 + ROCm 7.13a (TheRock nightly) で構築しました。当時 ROCm 7.x 系はまだ stable リリースが出ていなかったので、AMD のソース配布 (TheRock) を使い、さらに CTranslate2 を ROCm 7.x に対応させるために pigeek/CTranslate2-rocm フォークを起点にパッチを当ててソースビルドする流れでした。Claude Code でフォークのコードベース全体を読み込んでパッチを生成、なんとかビルドを通した、というのが前回までの状況です。

2026 年 4 月 23 日に Ubuntu 26.04 LTS が正式リリースされました。同じ時期に AMD 公式が ROCm 7.2.2 を apt 配布 (noble pocket 用) するようになり、CTranslate2 も v4.7.1 で ROCm wheel を公式リリースに同梱するようになっています。

タイミングが揃ったので、Ubuntu 26.04 LTS をクリーンインストールして faster-whisper 環境を組み直してみました。Claude Code に ROCm 7.2.2 のセットアップと CTranslate2 wheel の中身解析を進めてもらったところ、結果として apt と pip だけで完結、ソースビルド不要 で動きました。さらに今回はオンラインセミナー音源 (30 分の日本語) で長尺安定性と日本語品質も実機評価しています。

結論 ( TL;DR )

AMD 公式 noble repo から apt install rocm で ROCm 7.2.2 を入れる (Ubuntu 26.04 LTS で apt 一発)
CTranslate2 v4.7.1 公式リリースの ROCm wheel に gfx1151 が焼き込まれている ため、ソースビルド不要
HSA_OVERRIDE_GFX_VERSION も不要、gfx1151 ネイティブで動く
jfk.wav (11 秒英語、large-v3 float16) で realtime 11.5x、GPU peak 96%
日本語は VAD off + condition_on_previous_text=False が品質と速度の両方で鍵 (詳細は後述)
日本語セミナー音源 30 分 44 秒の全長 transcribe を 4 分 41 秒で完走、memory fault なし、realtime 6.56x
前回記事の構成 (自前ビルド + ROCm 7.13a + 約 7x realtime, 英語のみ) と比べて、構築コストも実行速度も改善

環境

項目	値
機材	GMKtec EVO-X2
APU	AMD Ryzen AI Max+ 395 (Strix Halo, RDNA 3.5)
GPU	Radeon 8060S Graphics, gfx1151, 40 CU
VRAM	96 GB (BIOS設定で128GB memory から割当, UMA)
OS	Ubuntu 26.04 LTS Resolute Raccoon
Kernel	7.0.0-14-generic (inbox amdgpu)
ROCm	7.2.2.70202-86~24.04 (AMD 公式 noble repo)
Python	3.12.13 (uv で venv)
CTranslate2	4.7.1 (公式 ROCm wheel)
faster-whisper	PyPI 最新
モデル	Systran/faster-whisper-large-v3 (float16)

ROCm 7.2.2 を Ubuntu 26.04 に入れる

apt repo の選び方

Ubuntu 26.04 universe にも rocm パッケージはあるのですが、こちらは 7.1 系で、Strix Halo (gfx1151) サポートが弱いままになっています。Strix Halo (RDNA 3.5) のネイティブサポートは ROCm 7.2.x 系から、という印象です。

AMD 公式 repo (https://repo.radeon.com/rocm/apt/7.2.2) は noble pocket のみ提供しているので、Ubuntu 26.04 (resolute) で使うには pin で優先順位を上げて入れます。

# AMD repo の GPG key を /etc/apt/keyrings に配置
sudo install -d /etc/apt/keyrings
wget -qO- https://repo.radeon.com/rocm/rocm.gpg.key \
  | gpg --dearmor \
  | sudo tee /etc/apt/keyrings/rocm.gpg > /dev/null

# AMD ROCm 7.2.2 noble pocket repo を追加 (resolute に noble 用を入れる)
echo 'deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] \
  https://repo.radeon.com/rocm/apt/7.2.2 noble main' \
  | sudo tee /etc/apt/sources.list.d/rocm.list

# universe 側 rocm 7.1 が依存解決で混入しないように pin で AMD repo 優先
sudo tee /etc/apt/preferences.d/rocm-pin-600 <<'EOF'
Package: *
Pin: release o=repo.radeon.com
Pin-Priority: 600
EOF

kernel inbox amdgpu を採用

AMD 公式 repo の noble pocket には amdgpu-dkms パッケージが置かれていません (jammy 用 22.04 向けには提供あり)。そこで AMD のドライバを DKMS で別途入れる経路は採らず、Ubuntu 26.04 inbox の amdgpu (kernel 7.0.0-14-generic) をそのまま使います。

/dev/kfd /dev/dri/renderD128 が認識できていれば inbox の amdgpu で十分動きます。AMD ドライバを apt 管理から外さないので、後の ROCm アップデートでバージョン整合が崩れにくく、運用上の安定感もこちらの方が良いように思います。

インストール

# /dev/kfd を叩くために video, render groups に入れる (要再ログイン)
sudo usermod -aG video,render "$USER"

# ROCm 一式 (~15-20 GB)
sudo apt update
sudo apt install -y rocm

/opt/rocm は /opt/rocm-7.2.2 への symlink になります。

動作確認

# gfx1151 が見えるか
rocminfo | grep -E 'Name:|Marketing Name:|gfx'

# HIP の構成情報
hipconfig --full | head -20

# rocBLAS の Tensile カーネルに gfx1151 用が同梱されているか
ls /opt/rocm/lib/rocblas/library/ | grep gfx1151

Name: gfx1151 が見える
Tensile カーネル Kernels.so-000-gfx1151.hsaco が /opt/rocm/lib/rocblas/library/ 配下に存在する

この 2 点が確認できれば、rocBLAS が gfx1151 用にビルドされたカーネルを同梱している状態で、HSA_OVERRIDE_GFX_VERSION=11.0.0 (gfx1100 偽装) のような迂回が要らないことになります。

CTranslate2 公式 ROCm wheel が gfx1151 を含んでいた件

事前の想定

事前計画では、CTranslate2 公式 v4.7.1 の ROCm wheel は gfx906/gfx942 など Instinct シリーズ中心で、Strix Halo の gfx1151 は含まれていないとしていました。sssshhhhhh/CTranslate2 の PR #1989 (Introduce AMD GPU support with ROCm HIP) ブランチを起点にソースビルドするのが本命、というシナリオで Claude Code に作業を始めさせています。

Claude Code で wheel を解析

PR #1989 のソースビルドに進む前に、まず公式 wheel の中身を Claude Code で確認しました。v4.7.1 リリースに rocm-python-wheels-Linux.zip (284MB) がアセットとして添付されているので、これを取得します。

# v4.7.1 release page の rocm-python-wheels-Linux.zip を取得
mkdir -p ~/whisper-rocm722/cache
cd ~/whisper-rocm722/cache
curl -L -o rocm-python-wheels-Linux.zip \
  https://github.com/OpenNMT/CTranslate2/releases/download/v4.7.1/rocm-python-wheels-Linux.zip

# ZIP の中を確認 (Python 3.10 〜 3.14 用 wheel が同梱されている)
unzip -l rocm-python-wheels-Linux.zip

ZIP の中には Python 3.10 〜 3.14 用の wheel が同梱されていました。Python 3.12 用の wheel を取り出して、.so の gfx ターゲット文字列を strings で見ます。

# cp312 用 wheel を抽出 (Python 3.12 が現時点で安定実績ある最新)
unzip -j rocm-python-wheels-Linux.zip \
  'temp-linux/ctranslate2-4.7.1-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl' \
  -d ~/whisper-rocm722/cache/

# wheel 内 .so の gfx ターゲット (焼き込み済みカーネル) を列挙
unzip -p ~/whisper-rocm722/cache/ctranslate2-*.whl '*libctranslate2*.so' \
  | strings | grep -oE 'gfx[0-9]+' | sort -u

gfx803 gfx900 gfx906 gfx908 gfx90a gfx942 gfx950
gfx1030 gfx1100 gfx1101 gfx1102 gfx1150 gfx1151 gfx1200 gfx1201

GCN3 (gfx803) から RDNA4 (gfx1200/1201) までフルカバー
RDNA 3.5 の gfx1150 と Strix Halo の gfx1151 もネイティブで含まれている
CTranslate2 公式リリースが gfx1151 を出してくれている というのは予想外
PR #1989 のソースビルドに進む必要が消えた瞬間

ldd で libctranslate2-*.so の動的依存も確認します。

# ldd で動的依存を見る (system ROCm を見ているか, 同梱 lib があるか)
unzip -p ~/whisper-rocm722/cache/ctranslate2-*.whl '*libctranslate2*.so' > /tmp/ct2.so
ldd /tmp/ct2.so | grep -E 'rocm|hip|amdhip|rocblas'

wheel 同梱の .so ではなく /opt/rocm/lib/ の system ROCm を参照
libamdhip64.so.7, librocblas.so.5, libhipblas.so.3, libhipblaslt.so.1 などが解決対象
すなわち wheel は ROCm ランタイムを別途インストールしてある前提の薄いラッパ
gfx1151 のカーネル本体は前段の apt install rocm で入る /opt/rocm/lib/rocblas/library/ の Tensile カーネルが効く

インストール

uv で venv を切って wheel を入れます。Python 3.12 を選ぶのは、CTranslate2 wheel が cp310-cp314 を出していて、3.12 が現時点で安定実績がある中では一番新しいから、という理由です。

# uv で Python 3.12 ベースの venv を切る (流儀: prefix なし命名)
uv venv ~/rocm722-whisper --python 3.12
source ~/rocm722-whisper/bin/activate

# 基本パッケージ
uv pip install --upgrade pip wheel setuptools

# CTranslate2 ROCm wheel を install
uv pip install ~/whisper-rocm722/cache/ctranslate2-4.7.1-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl

CTranslate2 が GPU を認識しているか確認します。

python -c "
import ctranslate2
print('CTranslate2:', ctranslate2.__version__)
print('CUDA devices:', ctranslate2.get_cuda_device_count())
print('Compute types:', ctranslate2.get_supported_compute_types('cuda'))
"

期待する出力:

CTranslate2: 4.7.1
CUDA devices: 1
Compute types: {'int8_float16', 'bfloat16', 'float16', 'int8', 'int8_float32', 'float32', 'int8_bfloat16'}

get_supported_compute_types('cuda') (ROCm でも CUDA API として返る) が int8/float16/float32/bfloat16 等のセットを返してくれば認識成功です。

faster-whisper で動作確認 (英語 jfk)

faster-whisper 本体と HuggingFace ダウンロード高速化用の hf-transfer を入れて、Whisper large-v3 を取得します。

# faster-whisper と hf ダウンロード高速化
uv pip install faster-whisper hf-transfer

# Whisper large-v3 (float16) を hf コマンドで取得
mkdir -p ~/whisper-rocm722/models/whisper
HF_HUB_ENABLE_HF_TRANSFER=1 hf download Systran/faster-whisper-large-v3 \
  --local-dir ~/whisper-rocm722/models/whisper/large-v3

モデル取得は hf コマンド (廃止される huggingface-cli ではない、新しい方の CLI) を使っています。

JFK 1961 年大統領就任演説の有名なフレーズを含む jfk.wav (11 秒、英語) で transcribe します。faster-whisper が同梱しているサンプルではないので、whisper.cpp リポジトリから samples/jfk.wav を取ってきました。

import time, wave
from pathlib import Path
from faster_whisper import WhisperModel

WAV   = Path.home() / "whisper-rocm722/scripts/jfk.wav"
MODEL = Path.home() / "whisper-rocm722/models/whisper/large-v3"

with wave.open(str(WAV), "rb") as w:
    audio_s = w.getnframes() / w.getframerate()

# float16 で large-v3 をロード, ROCm 経由でも device='cuda' を指定
model = WhisperModel(str(MODEL), device="cuda", compute_type="float16")

t0 = time.perf_counter()
segments, info = model.transcribe(str(WAV), language="en", beam_size=5)
text = " ".join(s.text.strip() for s in segments)
wall = time.perf_counter() - t0

print(f"{wall:.3f}s ({audio_s/wall:.2f}x): {text}")

10 連続で transcribe した結果。

run	wall (s)	realtime ratio
1 (kernel JIT 含む)	1.099	10.01x
2	0.947	11.62x
3-10 平均	0.955	11.51x

run 1 が少し遅いのは GPU カーネル JIT/cache のウォームアップ
run 2 以降は ±0.02 s 以内で安定
出力テキストは原文 (And so, my fellow Americans, ...) を句読点・語数とも正確に再現
info.language_probability = 1.000 (en)

GPU が確かに動いているかは、amd-smi metric -m (VRAM) と rocm-smi -u (engine usage) を 1 秒間隔でポーリングして確認しました。

amd-smi metric -m: 推論前 29317 MB → 推論中 32973 MB → 推論後 29317 MB と +3.6 GB の増減 (large-v3 float16 約 3 GB + 中間バッファに整合)
rocm-smi -u: idle 0% から推論中は最大 96% まで上昇するサンプルが取れた

なお、Strix Halo の APU 統合 GPU は amd-smi metric の -p (power) -t (temperature) -c (clock) -u (engine usage) の値が N/A になります。dGPU と sysfs 経路が違うのが理由とみられます。GPU 使用率は rocm-smi -u のポーリングで代替可能です。

日本語実機評価 — VAD off と `condition_on_previous_text=False` が鍵

英語が動いたところで、本題の日本語評価です。素材として GAIS (一般社団法人生成ＡＩ協会) のオンラインセミナー録音 (30 分 44 秒、16kHz / mono / PCM 16-bit、講演形式) を使用しました。
ffmpeg で冒頭 3 分と中盤 3 分を切り出して、まずは短尺で挙動を見ました。

# 冒頭 3 分 (司会挨拶、登壇者紹介、定型句が多く誤認識を見つけやすい)
ffmpeg -i GAIS-20260424-1.wav \
  -ss 00:00:00 -t 00:03:00 -c copy \
  ~/whisper-rocm722/audio-samples/ja/GAIS-20260424-1_intro-3min.wav

# 中盤 3 分 (本題の専門用語が出る区間)
ffmpeg -i GAIS-20260424-1.wav \
  -ss 00:14:00 -t 00:03:00 -c copy \
  ~/whisper-rocm722/audio-samples/ja/GAIS-20260424-1_middle-3min.wav

VAD on (faster-whisper の default) で起きた問題

faster-whisper の transcribe() は vad_filter=True (Silero VAD) と condition_on_previous_text=True が default です。まずこの default で 3 分版 2 本を流したところ、速度・品質ともに想定外の挙動が出ました。

ファイル	wall (s)	realtime ratio
intro-3min (180.03 s)	57.91	3.11x
middle-3min (180.03 s)	53.76	3.35x

英語 jfk の 11.5x に対して 3.1-3.4x まで落ちています。さらに出力テキストに元音声には存在しない hallucination パターンが含まれ、whisper がここで context を取り違えています。

VAD off + condition off に切り替えた

VAD は CPU 側処理で発話区間を pre-segment してから whisper に渡す機能ですが、日本語の自然な発話 (相槌、間、語尾の弱化、息継ぎ) と相性が悪く、segment が細切れになって whisper の 30 秒コンテキストウィンドウを十分使えなくなる、というのが起きていそうな現象でした。condition_on_previous_text も hallucination の連鎖を生む典型なので、両方 OFF にして再実行しました。

segments, info = model.transcribe(
    str(wav_path),
    language="ja",
    beam_size=5,
    vad_filter=False,                 # ← True から False に
    condition_on_previous_text=False, # ← True から False に
)

ファイル	wall (s)	realtime ratio
intro-3min (180.03 s)	28.54	6.31x
middle-3min (180.03 s)	25.85	6.96x

速度は約 2 倍に改善、品質も同時に大幅改善しました。文字起こし結果も脱落・文字化けが消えて自然な日本語になりました。

VAD off + condition off は日本語以外の言語にも基本的に効きそうです。faster-whisper の default 設定は英語前提で、日本語のような連続発話言語ではこの 2 つを OFF にするのが業務用途では現実解というのが確認できました。

長尺安定性 — 30 分音声で memory fault が出るか

paralin/ctranslate2-rocm の README には、長尺音声で Memory access fault by GPU node-1 が起きるという既知問題のメモがあります (gfx1101 で確認された件)。これが gfx1151 + ROCm 7.2.2 + 公式 wheel でも起きるかは、faster-whisper を業務に投入できるかの分かれ目になるので、セミナー音声の全長 (30 分 44 秒) で確認しました。

# VAD off + condition off は default 化しておく (Phase 5 確定設定)
python ~/whisper-rocm722/scripts/run_ja.py \
  /home/data/backup-pre-26.04/home-nabe/test/GAIS-20260424-1.wav \
  2>&1 | tee ~/whisper-rocm722/notes/phase5-japanese-fullrun.log

並行して別端末で rocm-smi --showmeminfo vram --json と rocm-smi -u --json を 1 秒間隔でポーリングし、VRAM と GPU 使用率の推移を CSV に記録しました。

結果:

項目	値
音声長	1844.10 s (30 分 44 秒)
wall time	281.31 s (4 分 41 秒)
realtime ratio	6.56x
segments	573
memory fault	観測されず
VRAM baseline	29317 MB
VRAM 推論中 max	35213 MB (delta +5.9 GB)
VRAM 推論中 avg	34373 MB
完了後 VRAM	baseline 復帰

average が max にほぼ張り付いている = 推論中 steady state でリーク無し
3 分版の +3.6 GB から 30 分版で +5.9 GB に増えている分は活性化キャッシュの累積範囲、想定の動き
30 分を乗り切れば 1 時間でも 2 時間でも問題なく走る性質に見える
1 時間会議の文字起こしなら 9 分強で終わる計算

固有名詞の認識は途中で context drift が起きる傾向があります。冒頭ではちゃんと認識されていた「クロードコード」が、終盤では「クロードフォード」に化ける箇所がありました。これは whisper の 30 秒 chunk を跨ぐと前文脈がリセットされる仕様によるもので、initial_prompt に語彙ヒントを与える戦略で対策可能と思われます (次回検討予定)。

前回記事との比較

観点	旧構成 (前回記事)	新構成 (本記事)
OS	Ubuntu 25.10	Ubuntu 26.04 LTS
ROCm	7.13a (TheRock nightly, alpha)	7.2.2 stable
ドライバ	当時の手当て	inbox amdgpu (kernel 7.0.0-14)
CTranslate2	自前ビルド (pigeek/nabe2030 系列の fork に ROCm 7.x patch)	公式 v4.7.1 wheel そのまま
起動条件	`HSA_OVERRIDE_GFX_VERSION` で偽装	不要 (gfx1151 ネイティブ)
動作確認手間	コードベース全体に ROCm patch を当ててビルド成功させるまで多段階	apt install + uv pip install で完結
realtime ratio (英語 jfk 11s)	約 7x	約 11.5x
realtime ratio (日本語 30 分)	未測定	6.56x
長尺安定性 (30 分)	未確認	memory fault なし、VRAM steady state

差の根源は ROCm 7.2.2 が stable リリースとして gfx1151 を正面サポートしたことと、CTranslate2 4.7.1 が公式リリースの ROCm wheel に gfx1151 を含めたこと、にありそうです。これによりユーザー側は HSA override も自前ビルドも不要になり、「Linux + Strix Halo + Whisper」が apt と pip だけで成立する状態に到達したように思います。日本語業務用途まで考えても、業務投入できるレベルに乗ったという感触です。

Claude Code に任せた作業

実作業はおおむね Claude Code に依頼しています。

AMD apt repo の追加から rocminfo で gfx1151 認識まで
v4.7.1 リリースから ROCm wheel ZIP を取得、cp312 用 wheel を抽出
strings で wheel 内 .so の gfx ターゲットを列挙、gfx1151 焼き込みを確認
ldd で system ROCm への依存解析
jfk.wav 推論スクリプトの作成、ベンチマーク実行
ffmpeg で GAIS セミナー音声を切り出し、3 分版 × 2 と 30 分全長で transcribe
VRAM 推移と GPU 使用率の同時計測

ワーキングディレクトリは ~/whisper-rocm722/ に切って、Claude Code のスコープをそこに限定しています。確認事項のあるたびに承認待ちで止まる流れにすると、勝手な sed パッチで誤魔化されたりせず、判断を確実にこちらで握れる感覚があります。

PR #1989 のコードベース解析自体は今回不要で済みました。事前に「公式 wheel に gfx1151 が含まれていなければ PR #1989 のソースビルドに進む」と分岐を決めて作業に入っていたのですが、wheel の strings で gfx1151 が出た時点で公式 wheel ルートに確定しています。

おわりに

前回記事 (Ubuntu 25.10 + ROCm 7.13a + 自前ビルド) の苦労が嘘のように、Ubuntu 26.04 LTS + ROCm 7.2.2 + CTranslate2 公式 wheel の組み合わせは apt と pip だけでセットアップが完結しました。Strix Halo + Linux で文字起こし環境を組む選択肢としては、現時点で最もシンプルな経路になっているように思います。
日本語業務用途でも、VAD off + condition_on_previous_text=False という設定さえ押さえれば、30 分の会議が 4 分半で文字起こしできて品質も実用域、という水準まで来ました。

参考リンク

前回記事 (Ubuntu 25.10 + ROCm 7.13a 時代): https://qiita.com/nabe2030/items/74b435820043eef7d351
CTranslate2 v4.7.1 release (ROCm wheel ZIP 添付): https://github.com/OpenNMT/CTranslate2/releases/tag/v4.7.1
CTranslate2 PR #1989 (HIP support): https://github.com/OpenNMT/CTranslate2/pull/1989
AMD ROCm 7.2.2 docs: https://rocm.docs.amd.com/en/docs-7.2.2/
AMD ROCm Issue #5750 (Strix Halo 低電力スタック): https://github.com/ROCm/ROCm/issues/5750
paralin fork (gfx1101 動作実績): https://github.com/paralin/ctranslate2-rocm
arlo-phoenix fork (gfx1030 動作実績): https://github.com/arlo-phoenix/CTranslate2-rocm