faster-whisper on AMD Strix Halo (Ryzen AI Max+ 395, gfx1151)

Drop-in recipe for Ubuntu 26.04 + ROCm 7.2.2 + CTranslate2 v4.7.1 official wheel — no source build, ~11.5x realtime English, ~6.56x realtime 30-minute Japanese long-form.

TL;DR

A working faster-whisper environment for Strix Halo is now reachable through apt install and pip install only, with no patches and no source build. CTranslate2's official v4.7.1 ROCm wheel ships gfx1151 kernels natively, and the AMD-distributed ROCm 7.2.2 apt packages cover the runtime side. HSA_OVERRIDE_GFX_VERSION is not needed.

In our testing on a GMKtec EVO-X2 (Ryzen AI Max+ 395, Radeon 8060S, 96 GB UMA VRAM) running Ubuntu 26.04 LTS:

• Whisper large-v3 (float16) transcribes JFK's 11-second clip at ~11.5x realtime, averaged over 10 runs
• A 30 minute 44 second Japanese seminar recording transcribes in 4 minutes 41 seconds (6.56x realtime)
• 573 segments processed without any memory fault or VRAM leak; engine usage peaked at 96%
• For non-English long-form audio, vad_filter=False and condition_on_previous_text=False produced both better quality and roughly 2x throughput compared to the library defaults

Quick Start

Assuming Ubuntu 26.04 LTS is already installed on a Strix Halo system and the user is in video and render groups:

# 1. Add AMD's noble-pocket repo for ROCm 7.2.2 and pin it
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
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
sudo tee /etc/apt/preferences.d/rocm-pin-600 <<'EOF'
Package: *
Pin: release o=repo.radeon.com
Pin-Priority: 600
EOF

# 2. Install ROCm
sudo apt update && sudo apt install -y rocm

# 3. Set up Python venv and install CTranslate2 from the official ROCm wheel
uv venv ~/whisper-env --python 3.12
source ~/whisper-env/bin/activate
curl -LO https://github.com/OpenNMT/CTranslate2/releases/download/v4.7.1/rocm-python-wheels-Linux.zip
unzip -j rocm-python-wheels-Linux.zip 'temp-linux/ctranslate2-4.7.1-cp312-*manylinux*x86_64.whl'
uv pip install ctranslate2-4.7.1-cp312-*manylinux*x86_64.whl faster-whisper hf-transfer

# 4. Download the model and run a smoke test
HF_HUB_ENABLE_HF_TRANSFER=1 hf download Systran/faster-whisper-large-v3 \
  --local-dir ~/whisper-large-v3
python scripts/run_jfk.py

For the rationale behind each step, longer-form benchmarks, and the Japanese-language recipe, read on. A more compact step-by-step is in QUICKSTART.md.

Why this exists

The AMD Strix Halo APU (Ryzen AI Max+ 395, Radeon 8060S, gfx1151) is an unusual piece of hardware: a 40-CU RDNA 3.5 integrated GPU sharing up to 96 GB of unified memory with a 16-core Zen 5 CPU, in a small-form-factor or mini-PC chassis at a price point well below comparable discrete-GPU systems. For local inference workloads that benefit from large memory but tolerate moderate bandwidth — MoE language models, long-form speech recognition, image generation — Strix Halo is competitive with much more expensive setups. Hardware deployments are widening: the GMKtec EVO-X2, Framework Desktop, HP ZBook Ultra G1a, and other Bosgame / Beelink / Geekom variants all use the same APU.

The ROCm software story has been the limiting factor. For most of 2025, gfx1151 was not on AMD's official ROCm support matrix, even though community ports had been working on it for months. Community guides have generally required some combination of building CTranslate2 from source, applying ROCm-version patches to forks, setting HSA_OVERRIDE_GFX_VERSION=11.0.0 to spoof gfx1151 as gfx1100, and pinning to specific kernel versions to avoid known regressions. None of this was difficult for an experienced builder, but it was very far from a "five minute setup".

Several pieces moved into place in early 2026 that change the picture:

• Ubuntu 26.04 LTS shipped on April 23, 2026, with a kernel new enough to run gfx1151 on the inbox amdgpu driver
• AMD started distributing ROCm 7.2.2 apt packages from their official repo, with rocBLAS Tensile kernels for gfx1151 included
• CTranslate2 v4.7.1 (released February 2026) attached a ROCm wheels archive to its GitHub release, with gfx1151 among the targets baked into the shared library

The combined effect is that the entire setup can now be done with apt and pip only — no DKMS drivers, no CMake, no patches against forks. This README documents the recipe, what we observed when running it, and where the rough edges still are. It builds on excellent prior community contributions; see Acknowledgments for credits to the people whose earlier work made this much easier.

A note on tooling choice. Whisper has several inference paths on AMD hardware: whisper.cpp (with HIP, Vulkan, or ROCm backends), insanely-fast-whisper through Hugging Face transformers, the AMD Ryzen AI NPU path through ONNX Runtime, and faster-whisper through CTranslate2. We chose faster-whisper because it remains the most common Python integration target for production speech pipelines (Wyoming protocol stacks, WhisperX, FastAPI servers), it handles long-form audio with proper context window management, and the CTranslate2 inference engine has historically been competitive with native CUDA throughput on supported GPUs. The cost of this choice is that CTranslate2 needs a ROCm-aware build of its own, which is what historically made the setup difficult.

Hardware tested

Component	Value
System	GMKtec EVO-X2
APU	AMD Ryzen AI Max+ 395 (Strix Halo, RDNA 3.5)
GPU	Radeon 8060S Graphics, gfx1151, 40 CU
VRAM	96 GB (allocated from 128 GB unified memory via BIOS UMA Frame Buffer Size)
OS	Ubuntu 26.04 LTS Resolute Raccoon
Kernel	7.0.0-14-generic (inbox amdgpu)
ROCm	7.2.2.70202-86~24.04 (AMD official noble repo)
Python	3.12.13 (uv-managed venv)
CTranslate2	4.7.1 (official ROCm wheel)
faster-whisper	latest from PyPI
Model	Systran/faster-whisper-large-v3 (float16)

The same recipe should work on any system with a Ryzen AI Max+ series APU running Ubuntu 26.04 with equivalent kernel and ROCm versions. We have not tested it on Framework Desktop, HP ZBook Ultra G1a, or other Strix Halo platforms — feedback from those configurations would be welcome.

ROCm 7.2.2 from AMD's official noble repo

Selecting the apt repo

Ubuntu 26.04 ships a rocm package in universe, but at the time of writing it was still ROCm 7.1, which has weaker gfx1151 support than 7.2.x. AMD's own apt repo at https://repo.radeon.com/rocm/apt/7.2.2 only provides a noble pocket (the codename for Ubuntu 24.04), so to use it on Ubuntu 26.04 (resolute), we add it explicitly and pin all its packages above the universe alternatives.

# AMD repo GPG key
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 (we install noble's packages on resolute)
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

# Pin to prefer AMD repo over universe, preventing dependency resolution from pulling in 7.1
sudo tee /etc/apt/preferences.d/rocm-pin-600 <<'EOF'
Package: *
Pin: release o=repo.radeon.com
Pin-Priority: 600
EOF

Kernel and amdgpu driver

AMD's noble repo currently does not include an amdgpu-dkms package — DKMS drivers are provided for jammy (Ubuntu 22.04) only. Rather than installing the AMD driver outside apt management, we use Ubuntu 26.04's inbox amdgpu driver. On kernel 7.0.0-14-generic this is recent enough to expose /dev/kfd and /dev/dri/renderD128 correctly for gfx1151. Keeping the driver in inbox/apt management means future ROCm upgrades cannot fall out of sync with the kernel module, which we found gives a more stable operational surface than the DKMS path historically did.

Installation

# Add the user to video and render groups so /dev/kfd is reachable; requires re-login
sudo usermod -aG video,render "$USER"

# Install the ROCm meta-package (~15-20 GB of dependencies)
sudo apt update
sudo apt install -y rocm

After install, /opt/rocm is a symlink to /opt/rocm-7.2.2.

Sanity check

Three things to verify before moving on:

# 1. The ROCm runtime sees the GPU as gfx1151
rocminfo | grep -E 'Name:|Marketing Name:|gfx'

# 2. HIP version is 7.2.x
hipconfig --full | head -20

# 3. rocBLAS Tensile kernels for gfx1151 are present
ls /opt/rocm/lib/rocblas/library/ | grep gfx1151

The expected output:

• rocminfo reports Name: gfx1151 for one of the agents
• hipconfig reports HIP version: 7.2.x
• Kernels.so-000-gfx1151.hsaco is present under /opt/rocm/lib/rocblas/library/

If all three are present, the runtime supports gfx1151 natively in this build, and no HSA_OVERRIDE_GFX_VERSION=11.0.0 workaround is needed. Many older Strix Halo guides include the override; with ROCm 7.2.2 it is not necessary and we recommend not setting it.

CTranslate2 v4.7.1 ships gfx1151 kernels — the unexpected finding

What we expected

Going into this work, our assumption was that the official CTranslate2 v4.7.1 release wheels would target the Instinct datacenter GPUs (gfx906, gfx942, gfx950) and skip Strix Halo. The plan was to clone the sssshhhhhh/CTranslate2 PR #1989 ("Introduce AMD GPU support with ROCm HIP") branch and build from source against ROCm 7.2.2, iterating until the build passed.

What we found

Before starting that build, we inspected the official wheel archive to confirm the target list, on the principle that an unnecessary source build is the worst kind of work. The v4.7.1 release page has an asset named rocm-python-wheels-Linux.zip (~284 MB) containing wheels for Python 3.10 through 3.14. Extracting the cp312 wheel and running strings on the embedded shared library produced this list of GPU targets:

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

Coverage spans GCN3 through RDNA4. RDNA 3.5 (gfx1150 and gfx1151) and the entire RDNA4 generation are included. The assumption that gfx1151 was excluded was wrong, and the planned source build was no longer necessary — we could simply install the wheel.

This was the most useful five minutes of the project. Building CTranslate2 from source on ROCm takes 20-30 minutes if everything goes well and considerably longer if something needs to be patched. Discovering that the wheel was already correct meant skipping that entire phase.

How the wheel binds to system ROCm

Running ldd on the same shared library confirmed that it does not bundle its own ROCm runtime:

libamdhip64.so.7  => /opt/rocm/lib/libamdhip64.so.7
librocblas.so.5   => /opt/rocm/lib/librocblas.so.5
libhipblas.so.3   => /opt/rocm/lib/libhipblas.so.3
libhipblaslt.so.1 => /opt/rocm/lib/libhipblaslt.so.1

The wheel resolves dependencies through /opt/rocm/lib/ directly, requiring system ROCm to be installed and visible to the dynamic linker. This makes the install sequence linear: install ROCm via apt first (which provides the gfx1151 Tensile kernels in /opt/rocm/lib/rocblas/library/), then install the wheel. The wheel itself is small enough to be a thin Python binding that delegates all heavy work to the system ROCm libraries — which is the right design for a project that wants to ship across many ROCm versions without bundling them.

Installation

We use uv for the venv, which is fast and produces clean, reproducible environments. Python 3.12 is selected because the wheel archive ships cp310 through cp314, and 3.12 is the most recent version with broad library compatibility at the time of writing.

# Create a Python 3.12 venv
uv venv ~/whisper-env --python 3.12
source ~/whisper-env/bin/activate

# Standard build tools
uv pip install --upgrade pip wheel setuptools

# Install CTranslate2 from the extracted wheel
uv pip install ./ctranslate2-4.7.1-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl

Verify GPU detection:

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'))
"

Expected output:

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

CTranslate2 uses the 'cuda' device-name convention even on ROCm because the API surface mirrors CUDA. If the call returns a non-empty set of compute types, the binding has successfully reached the system ROCm and recognized the GPU.

Verifying with English (jfk.wav)

The standard smoke test for whisper-family models is samples/jfk.wav from the whisper.cpp repository — 11 seconds of John F. Kennedy's 1961 inaugural address. After downloading the Whisper large-v3 weights (in faster-whisper format from Systran/faster-whisper-large-v3), we ran transcription 10 times in succession with beam_size=5 and compute_type="float16".

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

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

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

# Float16 on the GPU; CTranslate2 calls this device='cuda' even on ROCm
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}")

Results:

Run	Wall (s)	Realtime
1 (kernel JIT included)	1.099	10.01x
2	0.947	11.62x
3-10 average	0.955	11.51x

Run 1 is slightly slower because GPU kernels are JIT-compiled and cached on first use. From run 2 onward, wall time is stable to within ±0.02 seconds. The transcribed text matches the source exactly, including punctuation, and the detected language probability is 1.000 for English.

To confirm the GPU was actually doing the work, we polled amd-smi metric -m and rocm-smi -u at 1-second intervals during the runs:

• VRAM moved from 29317 MB at idle to 32973 MB during inference and back to 29317 MB after — a delta of about 3.6 GB, consistent with the large-v3 float16 model size (~3 GB) plus inference buffers
• rocm-smi -u showed engine usage rising from 0% at idle to 96% peak during transcription

A note on Strix Halo and amd-smi: because the GPU is integrated into the APU rather than being a discrete card, amd-smi metric -p (power), -t (temperature), -c (clocks), and -u (engine usage) return N/A. The sysfs paths used by amd-smi for these metrics differ on APUs from those on dGPUs and the APU paths are not yet wired up. Memory information (-m) and process information (amd-smi process) work normally. For engine usage, rocm-smi -u polling is the workable substitute.

Japanese long-form recipe: VAD off + condition_on_previous_text=False

With English working, we wanted to evaluate the same setup for the actual workload of interest: transcribing recorded Japanese-language seminars and meetings for archival use.

The test material was a 30-minute 44-second recording from a recent online seminar (Japanese, single-speaker presentation format, mixed technical content including English-loaned terms like "Claude Code"). The audio is 16 kHz mono PCM 16-bit. We cut two 3-minute samples from it for short-form testing — the first 3 minutes (introduction with formulaic phrasing, useful for surfacing misrecognitions) and 3 minutes from the 14-minute mark (mid-presentation with topic-specific terminology).

The default configuration produced surprising results

faster-whisper's transcribe() defaults to vad_filter=True (Silero VAD pre-filtering) and condition_on_previous_text=True. We started there:

File	Wall (s)	Realtime
intro 3min (180.03 s)	57.91	3.11x
middle 3min (180.03 s)	53.76	3.35x

Compared to the 11.5x we measured on English JFK, throughput dropped to about a third. The output text also showed two recurring issues: hallucinated phrases not present in the source audio (the model fabricating filler content during silence regions or transitions), and dropped or truncated segments at chunk boundaries, occasionally including the Unicode replacement character U+FFFD.

Switching VAD off and disabling previous-text conditioning

Our hypothesis was that VAD pre-segmentation was breaking up the input into chunks too small to provide adequate context to Whisper's 30-second receptive window. Japanese spontaneous speech has features that Silero VAD seems to react to in unhelpful ways — backchannels, breath pauses between clauses, sentence-final particles trailing off — and these were producing many short segments where the model was operating on context-poor input. The condition_on_previous_text flag is also a well-known source of repetitive hallucinations in long-form transcription, where an early misrecognition cascades through subsequent windows.

Disabling both:

segments, info = model.transcribe(
    str(wav_path),
    language="ja",
    beam_size=5,
    vad_filter=False,                  # was True (default)
    condition_on_previous_text=False,  # was True (default)
)

Both speed and quality improved substantially:

File	Wall (s)	Realtime
intro 3min (180.03 s)	28.54	6.31x
middle 3min (180.03 s)	25.85	6.96x

Throughput roughly doubled. The hallucinations and dropped segments disappeared. Specifically, the introduction passage now read coherently from start to finish, with proper Japanese sentence boundaries, appropriate use of formal language register, and no fabricated content. The middle passage similarly stayed on-topic and accurate to the source audio.

A small number of misrecognitions remained — homophones (口座 vs 講座, both pronounced kōza), katakana words with ambiguous tail vowels (マルウェア maruwea vs マルウェイ maruwei), and one case of phonetic-but-not-orthographic kanji conversion (身代金 ↔ 身のしろ金, both readable as minoshirokin). These appear amenable to dictionary-based postprocessing if the use case requires fully clean output, and we did not consider them blocking for our archival workflow.

Generality of the recipe

We have not systematically tested this on languages other than English and Japanese. The underlying mechanics suggest that vad_filter=False and condition_on_previous_text=False should be a useful starting point for any language with spontaneous-speech features similar to Japanese — relatively continuous prosody, soft sentence-final cues, frequent short backchannels. Mandarin, Korean, and conversational Spanish are plausible candidates. If you find faster-whisper's default settings producing hallucinations or dropped output on a specific language, this is a low-cost first thing to try before reaching for more invasive changes.

Long-form stability: 30 minutes without memory fault

The README of paralin/ctranslate2-rocm (a community ROCm fork of CTranslate2) documents that long audio files have caused Memory access fault by GPU node-1 errors on at least some configurations. The reports we found referred to gfx1101 (RX 7600 family). Whether this would reproduce on gfx1151 with ROCm 7.2.2 and the official v4.7.1 wheel was the open question — the answer matters because business workloads (meeting transcription, interview transcription, lecture transcription) routinely involve 30 minutes to several hours of continuous audio.

We ran the full 30-minute 44-second recording with the VAD-off configuration described above, polling VRAM and GPU usage from a separate terminal at 1 Hz throughout the run.

Metric	Value
Audio duration	1844.10 s (30 min 44 s)
Wall time	281.31 s (4 min 41 s)
Realtime ratio	6.56x
Segments produced	573
Memory faults observed	0
VRAM at baseline	29317 MB
VRAM peak during inference	35213 MB
VRAM average during inference	34373 MB
VRAM after completion	29317 MB (returned to baseline)

A few observations:

• The peak-vs-average VRAM gap is small (840 MB), indicating steady-state operation rather than a slowly leaking working set
• The +5.9 GB delta versus the +3.6 GB seen on the 3-minute samples is consistent with cached activation buffers growing modestly with longer transcription history
• VRAM returns cleanly to baseline after the run, suggesting no resident leak across runs
• Throughput on this longer file (6.56x) is slightly below the 3-minute middle sample (6.96x) — a small effect we have not investigated in detail

We did observe one recurring quality issue worth flagging: long-form context drift on proper nouns. The phrase "Claude Code" was transcribed correctly in early segments but drifted to "Claude Ford" toward the end of the recording. This appears to be a consequence of Whisper's 30-second receptive window — once the original mention falls out of context, the model has no anchor for unusual proper nouns and may interpolate to phonetically plausible alternatives. The standard mitigation is to provide an initial_prompt containing the expected vocabulary, which we have not yet tested in this setup but plan to investigate next.

Comparison with prior work

For someone setting up faster-whisper on Strix Halo today, the most directly comparable existing guide is davidguttman/whisper-rocm, which documented an earlier path on ROCm 6.4.3 with CTranslate2 v3.23.0 built from source.

Aspect	davidguttman recipe (Oct 2025)	This recipe (Apr 2026)
ROCm version	6.4.3	7.2.2 (stable)
CTranslate2 source	v3.23.0 built from source	v4.7.1 official ROCm wheel
HSA_OVERRIDE_GFX_VERSION	not used	not used
gfx1151 kernel source	local CMake build with -DCMAKE_HIP_ARCHITECTURES=gfx1151	shipped in the wheel
Build complexity	15-20 minute helper script + ROCm dev libraries	none
Reported throughput (large-v3, JFK 11s)	~9x realtime	~11.5x realtime
Long-form Japanese data	not in published benchmarks	6.56x on 30 min, 0 memory faults

The improvement is upstream rather than recipe-side: ROCm 7.2.2 stabilizing gfx1151 support, CTranslate2 shipping built kernels in the release wheels, and Ubuntu 26.04 having a recent enough kernel to run the inbox amdgpu driver. davidguttman's earlier work was excellent for what was available at the time, predating these improvements by about six months. If you are reading this and you came here from that repository, thank you for the context — it materially helped us understand the problem.

For a non-ROCm reference point: on Apple Silicon (M2 Pro Mac mini class hardware, comparable test conditions), whisper.cpp with the Metal backend has been reported to be fast for English long-form audio. We have not run a head-to-head comparison and the ML stacks are different (whisper.cpp's ggml backend versus CTranslate2 on ROCm), so the comparison should be taken as illustrative rather than definitive. The faster-whisper / CTranslate2 stack tends to be the more common production speech pipeline target on Linux, which is one reason we focused on it; for purely-personal English transcription on existing Mac hardware, whisper.cpp may well be the more direct path.

This README is also a follow-up to a Japanese-language article by the same author covering Ubuntu 25.10 + ROCm 7.13a (TheRock nightly) + CTranslate2 source build with patches. That earlier setup required building CTranslate2 from a community ROCm fork and applying a patch series for ROCm 7.x compatibility. The current recipe replaces all of that with apt install and pip install. The trajectory of construction effort over time is steeply down, and we expect it to continue downward as PR #1989 lands in CTranslate2 main and as ROCm 8.0 brings additional gfx1151 stabilization.

Known limitations and things not yet tested

A list of things this README explicitly does not cover, so future readers know what to verify themselves:

• 1+ hour audio files: only 30 minutes verified. The 30-minute steady-state behavior suggests longer should work, but we have not tested it
• Word Error Rate measurement on Japanese: subjective evaluation only. No formal WER on a labeled dataset
• Other languages besides English and Japanese: we expect the VAD-off recipe to generalize to other spontaneous-speech languages, but have not tested
• initial_prompt strategy for proper noun stabilization: identified as a likely fix for the "Claude Code" → "Claude Ford" drift, but not yet tested
• Speaker diarization: faster-whisper does not provide it; WhisperX or pyannote integration is a separate topic
• APU sensors via amd-smi: power, temperature, clocks, and engine usage return N/A on Strix Halo. Use rocm-smi -u for engine usage
• BIOS configuration: assumes UMA Frame Buffer Size set to 96 GB in BIOS. The default 64 GB is sufficient for Whisper large-v3 alone but limits headroom for concurrent workloads (e.g. running an LLM and a transcription pipeline simultaneously)
• Other Strix Halo platforms: tested only on GMKtec EVO-X2. Framework Desktop, HP ZBook Ultra G1a, and other Ryzen AI Max+ devices should behave similarly but feedback would be welcome
• Concurrent inference workloads: not tested; we run faster-whisper alone in this configuration

Reproducing locally

The scripts/ directory contains the Python and shell scripts used for the measurements above:

• run_jfk.py — single transcription of jfk.wav with timing and language probability
• run_jfk_repeat.py — 10 sequential runs with min/max/mean output for warmup characterization
• run_ja.py — Japanese transcription with VAD off and condition_on_previous_text=False as defaults; takes a wav path as an argument
• inspect_wheel.sh — extracts the cp312 wheel and dumps the gfx targets baked into the shared library

The benchmarks/ directory has the raw CSV output from the runs documented in this README, in case anyone wants to compare or check our numbers against their own.

To reproduce end to end on a fresh machine:

1. Install Ubuntu 26.04 LTS on Strix Halo hardware
2. Run the apt steps in Quick Start to set up ROCm 7.2.2
3. Set up the venv and install the wheel as shown above
4. Download the model: hf download Systran/faster-whisper-large-v3 --local-dir ~/whisper-large-v3
5. python scripts/run_jfk.py to verify the English path
6. Provide a Japanese audio file and run python scripts/run_ja.py path/to/audio.wav to verify the Japanese path

If your numbers differ substantially from ours, please open an issue. The most likely causes are (a) different VRAM/GART configuration in BIOS, (b) a different kernel version with relevant regressions, (c) thermal throttling under different platform cooling.

Acknowledgments and prior art

This recipe rests on several years of community work on ROCm and Strix Halo, much of it conducted outside official AMD support channels.

David Guttman's whisper-rocm repository established the basic shape of "faster-whisper transcription on Strix Halo" in late 2025, working through the CTranslate2 source build patterns and the early ROCm 6.4.x environment. Many of the design decisions in this recipe — using float16 for large-v3, validating with the JFK sample, watching for the Conv1D cuDNN error path — trace back to that repository. paralin's ctranslate2-rocm fork was an even earlier ROCm-on-CTranslate2 effort and continues to host useful operational notes for users on hardware not yet covered by the official wheels; the long-form memory-fault notes in that README were the reason we ran our 30-minute test, and we hope our null result is useful data. arlo-phoenix's parallel fork covering gfx1030 helped surface some of the GPU-target conventions that the official wheel later adopted.

On the broader Strix Halo platform side, kyuz0's amd-strix-halo-toolboxes, lhl's strix-halo-testing repository, and the related work tracked at llm-tracker.info were essential references for understanding which kernel versions, ROCm versions, and library combinations are stable on this hardware. The Framework community forum thread on Strix Halo benchmarks (community.frame.work/t/72521) remains one of the most thorough public sources for what to expect from this APU on real ML workloads. ndom91's ha-voice-strix-halo showed a Wyoming-protocol integration pattern for speech services on the same chip and helped us isolate which faster-whisper behaviors are platform-related versus library-related.

On the upstream side, the OpenNMT/CTranslate2 maintainers and the contributor working on PR #1989 deserve credit for getting ROCm support into a state where it ships in the official release wheels. Once that PR merges into main, the standalone wheel archive may become unnecessary, which would simplify this recipe further. The AMD ROCm team's work on rocBLAS, hipBLASLt, and the Tensile kernel libraries is what makes gfx1151 actually fast rather than nominally functional — the Tensile gfx1151 kernels in /opt/rocm/lib/rocblas/library/ are the unsung hero of this entire pipeline.

The Anthropic Claude Code tool was used during the construction of this environment for inspecting wheel contents, generating benchmark scripts, and capturing measurement logs in a reproducible form. The original Japanese-language version of this content, with additional context on the project history, is at qiita.com/nabe2030/items/d49173174c58e25b785a. An earlier Japanese article in the same series documents the previous attempt at the same problem under Ubuntu 25.10 + ROCm 7.13a (TheRock nightly), which required CTranslate2 source builds: qiita.com/nabe2030/items/74b435820043eef7d351.

License

MIT. See LICENSE.