Field report2026-09-15, updated 2026-10-09AMD Instinct MI355X · gfx950 · ROCm 7.14.1 · PyTorch 2.12

World models on MI355X

We brought up the open real-time video models we work with on AMD Instinct MI355X cards on Daytona between 12 and 14 September. This is what ran, how fast it ran against the NVIDIA setups we used before, and every fix it took, with the pull requests that send those fixes back upstream.

By Windflow — realtime interactive AI video models, served on demand.

Four results

MiniMax H3 · FastH3 4-stepFour MI355X render a 14.375-second video-and-audio window at 960×544 in 9.30 s. Our four-H100 profile needed 12.98 to 14.4 s for the same window. Eight MI355X hold real time at the full 1344×768 frame: 11.81 s per window.
LingBot-World v2 · 14BOne MI355X runs the 704×384 production frame at 16.3 fps, which clears the model's 16 fps clock. On H100 that frame was served from two cards with context parallelism.
SANA-WM · streamingOne MI355X runs the 2.6B world model's streaming pipeline at 1280×704 at 23.6 fps steady state, 1.47× its 16 fps clock, with or without torch.compile. The published H100 figure is 0.93× with compile.
JoyAI-Video-EditOne MI355X edits a 1248×720 camera stream at 24 fps with 443 ms from camera frame to edited pixels at the median. An RTX PRO 6000 reached 15.8 fps and 1733 ms at the same size.

MiniMax H3: seconds of content per second of compute

Each bar is one 345-frame window, 14.375 seconds of video with audio, generated end to end: text encoding, four DiT forwards, video and audio decode and the file write. The ratio is content seconds divided by wall-clock seconds, so anything right of the 1.0 line keeps up with playback.

MI355X bars in color, NVIDIA reference points in grey. H100 is our own production profile, the midpoint of 12.98–14.4 s. B200 figures are FastVideo's published sm_100a sparse runs. MI355X rows use FastVideo's Triton sparse kernels (VSA 0.9, 64-token tiles) or dense SDPA with regional compile, whichever was faster at that size.

LingBot-World v2: native frames per second by card count

Measured with the camera held forward over 30 chunks. The MI355X rows use an incremental Ulysses KV exchange that swaps only the new frames' keys and values instead of the whole cache window on every attention call. It is bit-exact against the stock path over 757 attention calls, and it is what lets two cards beat one on MI355X links.

Model · frame	System	1 card	2 cards	4 cards	8 cards
14B · 704×384	MI355X	16.3	17.3	35.1	40.4
14B · 832×480	MI355X	10.6	12.9	25.5	35.6
14B · 832×480	H100, stock	5.2	8.59	16.15	26.8
1.3B · 832×480	MI355X	53.3	—	—	—
1.3B · 832×480	H100	29.3	—	—	—

JoyAI-Video-Edit: camera frame to edited pixels

A synthetic H.264 camera streams into the worker for 60 seconds with one instruction change at 30 seconds. Latency runs from a camera frame arriving at the worker to the edited frame existing, before network and browser playback. The ROCm build of JoyAI's FP8 and fused kernels comes from Aaryaman Vasishta's fork, jammm/JoyAI-Video-Edit.

Canvas · clock	Card	Delivered fps	Frame → pixels p50 / p90	First frame
1248×720 · 24	MI355X	24.0	443 / 578 ms	871 ms
1248×720 · 24	RTX PRO 6000	15.8	1733 / 1890 ms	2440 ms
1248×720 · 30	MI355X	28.1	428 / 532 ms	861 ms
840×480 · 24	MI355X	24.0	304 / 435 ms	586 ms
840×480 · 24	RTX PRO 6000	24.0	441 / 576 ms	1107 ms

ABot-World and Helios also moved to single MI355X cards on 14 September after passing the same release gates. Helios needed no code change beyond turning off a CUDA-only FlashAttention 3 hub kernel. ABot-World needed a scaled-dot-product fallback for its flash-attention calls, listed below.

What it took

Everything we changed or worked around to run these models on ROCm, and where each fix now lives.

Where	What happened on ROCm	Status
FastVideo platform detection	The `rocm/pytorch` images ship no `amdsmi` Python package, so FastVideo resolved the CPU platform on an AMD GPU. Installing the PyPI `amdsmi` wheel instead breaks `import torch`.	Merged FastVideo #1849
FastVideo sparse attention	Backend selection on ROCm crashed with a `TypeError` for both video sparse attention backends. With that fixed, FastVideo's Triton sparse kernels run on gfx950, match PyTorch references, and one MI355X renders a 1344×768 window in 62.9 s against 87.8 s dense.	Merged FastVideo #1851
fastvideo-kernel install	The Python and Triton parts of `fastvideo_kernel` import and run straight from the source tree, which is all the sparse path needs. Building its compiled extension with `build.sh --rocm` fails in the `rocm/pytorch` 7.14.1 image: CMake cannot enable the HIP language, because the pip-packaged ROCm SDK carries no `hip-lang` CMake package. Since FastVideo #1871 the build falls back to the Python and Triton package there.	Merged FastVideo #1871
FastVideo FP8 activation quantization	The dynamic FP8 activation quantization ran as four to five passes over each activation, about as long as the FP8 GEMM it feeds. Fused Triton kernels do it in one pass: 3× (tensorwise) and 4× (rowwise) faster on MI355X.	Merged FastVideo #1861
SANA GDN kernels	The fused Gated DeltaNet Triton kernels pass `input_precision="tf32"` to `tl.dot`, which Triton on ROCm rejects, so every SANA-WM and SANA-Streaming forward failed at the first kernel compile. One module constant resolves it per backend.	Pull request Sana #510
LightX2V recipe	LightX2V had no MiniMax-H3 configuration for ROCm. A single-GPU aiter-attention recipe with the 4-step Turbo LoRA renders a 15-second 1344×768 clip in 111.5 s on one MI355X.	Pull request LightX2V #1534
ABot-World attention	`flash_attention()` asserted a flash-attn build with no fallback, so the model crashed on machines without one. It now falls back to SDPA with the same variable-length semantics.	Merged ABot-World #14
PyTorch caching allocator	With `expandable_segments:True`, the ROCm 7.14.1 image stops allocating after 242 tensors of 84 MiB, or 2036 tensors of 1 MiB, with more than 260 GiB still free. The ROCm 10.1 nightly passes the same test, but we keep the setting off on both stacks.	Setting
RCCL	Multi-card runs need `HSA_NO_SCRATCH_RECLAIM=1`. With it, Ulysses sequence parallelism over two to eight cards ran without a hang.	Setting
FlashDreams runtime	LingBot's engine loads `libcudart` through ctypes at start-up, and PyTorch's cuDNN attention has no ROCm kernels, so we route it to the flash backend.	Carried patch
FlashDreams context parallel	Ulysses attention re-sends the whole KV window on every call, which made two MI355X slower than one. The incremental exchange above fixes it.	Carried patch
torchao FP8	torchao 0.17 limited FP8 to NVIDIA compute capability 8.9 and the MI300 family, which kept LingBot's FP8 path off gfx950.	Fixed upstream
TheRock nightly torchvision	The nightly torchvision wheels carry no gfx950 GPU kernels, so operators such as `nms` fail on the GPU.	Avoided

How we measured

Hardware

Daytona MI355X VF spot sandboxes, 308.9 GB of device memory per card, eight cards on one XGMI hop. NVIDIA reference points ran on H100 SXM, RTX PRO 6000 and B200.

Software

ROCm 7.14.1 and PyTorch 2.12.0 from the rocm/pytorch image. JoyAI used the TheRock nightly, ROCm 10.1 with PyTorch 2.13.

MiniMax H3

FastVideo main from 13 September with the ROCm changes listed above applied as runtime patches, one excluded warmup window, then the median of the measured windows at seed 1000. On 15 September the single-card runs were repeated on FastVideo 37d06a8 with the two pull requests applied.

LingBot and JoyAI

Our streaming worker on the box over loopback: native fps over 30 chunks for LingBot, a 60-second camera stream for JoyAI.