はじめに
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