AMD MIGraphX: what you get from a graph inference engine tied to ROCm

The problem MIGraphX is aimed at

Inference on a GPU is not the same workload as training. A trained model arrives as a fixed graph, and the runtime's job is to execute that graph with as little overhead per operator as possible. MIGraphX is AMD's answer to that job: the README describes it as "AMD's graph inference engine, which accelerates machine learning model inference." The repository's topics list confirms the same framing: inference, gpu-acceleration, deep-learning, rocm.

The intended user is someone running models on AMD hardware who wants the graph compiled and optimized rather than interpreted operator by operator. That is a narrower audience than a general deep learning framework serves. If your model runs fine through a framework's own eager execution on ROCm, MIGraphX is not obviously for you. It becomes relevant when you want a standalone inference path, when you are deploying a model rather than experimenting with it, and when you are willing to accept ROCm as a hard prerequisite. The README states that prerequisite plainly: you must install ROCm before installing MIGraphX.

What the dependency list reveals about the execution path

The build prerequisites are the clearest statement of architecture in the repository. MIOpen and rocBLAS are listed "for running on the GPU", and so is HIP. That tells you the execution path: MIGraphX is a layer above AMD's own libraries, dispatching graph operations into MIOpen for convolution-style work and rocBLAS for linear algebra, with HIP as the device interface. MIGraphX is not writing its own GPU kernels from scratch for every operator; it is orchestrating and optimizing a graph on top of existing ROCm components.

Two more dependencies matter for what the tool can do. Protobuf is listed "for reading onnx files", so ONNX import is a first-class path rather than an afterthought. SQLite3 is described as being used "to create database of kernels' tuning information or run queries on existing database". That is the most interesting line in the prerequisite list, because it implies a tuning step: kernel selection information is persisted in a database that can be built once and queried later. The repository does not document the tuning workflow, only the dependency, so treat that as a lead to follow in the published docs rather than a described feature.

Serialization is handled by nlohmann JSON for "model serialization to json string format" and MessagePack for "model serialization to binary format". Two output formats, one human-readable and one compact, is a reasonable split for debugging versus deployment.

Installing the binary versus building from source

The shortest path is the package manager. The README gives one command: sudo apt update && sudo apt install -y migraphx. Header files and libraries land under /opt/rocm-<version>, where <version> is the ROCm version. That path convention is worth noting before you write any build scripts, because it means include and link paths move when ROCm moves.

Building from source has three documented routes. The first uses rbuild, the ROCm build tool. You install rocm-cmake, python3-pip, rocblas and miopen-hip with apt, create a virtual environment, and install rbuild from a tarball URL. Then the whole build is one command: rbuild build -d depend -B build -DGPU_TARGETS=$(/opt/rocm/bin/rocminfo | grep -o -m1 'gfx.*'). Note what that command does. It derives the GPU target from rocminfo output by grepping for the first gfx string, so the build is architecture-specific by default rather than universal. The README also flags a common failure: if rbuild is not found, it is because it installed into $HOME/.local/bin, which is not on PATH. Either export PATH=$HOME/.local/bin:$PATH or reinstall with --prefix /usr/local.

The second route is plain CMake. You still use rbuild, but only to fetch prerequisites: rbuild prepare -d depend, which places them in a folder you then pass as -DCMAKE_PREFIX_PATH=depend. If you have sudo, the README offers ./tools/install_prereqs.sh as an alternative, which installs to /usr/local by default or to ./tools/install_prereqs.sh $custom_location if you pass a path. Then you configure with CXX=/opt/rocm/llvm/bin/clang++ cmake .. -DGPU_TARGETS=$(/opt/rocm/bin/rocminfo | grep -o -m1 'gfx.*'). The default build type is Release; Debug and RelWithDebInfo are both documented. Build with make -j$(nproc), verify with make -j$(nproc) check, install with make install.

The third route is Docker, which the README calls the easiest way to set up a development environment. You build with docker build -t migraphx . or pass the architecture explicitly with --build-arg GPU_ARCH=$(rocminfo | grep -o -m1 'gfx.*'). The README explains the trade-off: setting GPU_ARCH reduces image size, while leaving it unset installs device code for all supported architectures, which is what you want if one image must run on several ROCm-supported GPUs. The run command mounts /dev/kfd and /dev/dri, adds the video group, and bind-mounts the source tree at /code/AMDMIGraphX.

Where the repository documentation stops

The README ends at a heading that reads "Using" and nothing after it. For a project whose whole purpose is to run models, that is a significant gap in this repository. There is no example in the supplied material of loading a model, compiling a graph, or running an inference call. The README points to the published documentation at rocm.docs.amd.com for the organized version, and notes that the documentation sources live in the docs folder of the repository, so the material exists. It just is not in the README.

That shapes how you should evaluate this project. You cannot judge the API from the repository front page. You cannot see from the README whether the C++ API, the Python bindings, or both are the intended surface for application code, even though pybind11 is listed as a prerequisite "for python bindings", which confirms Python bindings exist. You cannot see the tuning workflow that the SQLite3 dependency implies. Anyone deciding whether to adopt MIGraphX has to read the published docs first, and should treat the absence of usage examples here as a documentation layout choice rather than as evidence about the tool itself.

The limitation that matters most: ROCm comes first

The README states the constraint without hedging: you must install ROCm before installing MIGraphX. That single sentence rules out a large set of use cases. If you are on a machine without AMD GPUs, or on an operating system ROCm does not target, MIGraphX is not a candidate regardless of how good the graph optimizer is. It is not a portable runtime that happens to have an AMD backend. It is an AMD component that depends on the rest of the AMD stack.

The GPU_TARGETS pattern reinforces the same point from the other direction. Both the rbuild command and the CMake command derive the target architecture from rocminfo, which means the build is tied to the hardware present at build time unless you deliberately widen it. The Docker instructions show the same tension: the README says leaving GPU_ARCH unset installs device code for all supported architectures and is "useful when the same Docker image needs to run on different ROCm-supported GPUs", which is a real convenience but also a real size cost. There is no free option here. You either build for a known target or pay for a universal one.

A second limitation is less about capability than about documentation in this repository. The version scheme follows ROCm releases, with recent tags rocm-10.0, rocm-7.14 and rocm-7.2.4. That alignment is convenient for matching components, but it also means MIGraphX's release cadence is not its own. If you need a fix that is not tied to a ROCm release, the repository does not describe a separate channel for it.

How it compares to a framework-native inference path

The obvious alternative is to skip MIGraphX and run inference through the framework that produced the model, using ROCm as that framework's backend. The difference is where the optimization happens. A framework's own runtime executes the model as the framework defines it, which keeps you inside one toolchain for training and inference and avoids a separate install step. MIGraphX inserts a compilation stage between the model file and the GPU: the graph is read, presumably transformed, and dispatched into MIOpen and rocBLAS rather than executed by the framework's own kernels.

That trade is real in both directions. Going through MIGraphX means an extra artifact to install and an extra version to keep aligned with ROCm, and the README's dependency list shows how much of the ROCm stack it pulls in. In exchange you get a runtime whose stated purpose is inference alone, with a persisted kernel tuning database and two serialization formats, which are things a training-oriented framework has less reason to provide. The repository does not contain benchmarks or comparisons, so the size of the gain is not something this material can tell you. Anyone weighing the two paths has to measure on their own model rather than take a claim from the README.

Licence and the cost of keeping it current

The repository is MIT licensed. For most teams that is the permissive end of the spectrum: it permits use in proprietary products provided the licence notice is preserved. That is a general statement about MIT, not legal advice, and the actual terms are in the LICENSE file, which you should read rather than a summary.

The maintenance cost is dominated by ROCm, not by MIGraphX itself. Because the README requires ROCm first and the install path is /opt/rocm-<version>, upgrading ROCm moves your library paths. The recent tags (rocm-10.0, rocm-7.14, rocm-7.2.4) show the version numbers track ROCm releases, so an upgrade cycle for the GPU stack is also an upgrade cycle for MIGraphX. Building from source adds a second cost: the rbuild route pulls prerequisites into a depend folder, and the CMake route can either use that folder or install prerequisites system-wide via ./tools/install_prereqs.sh, which touches /usr/local by default and needs sudo. Teams that cannot grant sudo on build machines should use the depend folder path or the Docker image instead. The Docker route is also the one that isolates you from host ROCm drift, at the price of image size unless you pin GPU_ARCH.

Editorial conclusion

Adopt MIGraphX if you are already inside the ROCm stack on Linux and your model arrives as ONNX or another format the docs list as supported, because the binary install is a single apt command and the source build is scripted. Do not adopt it if you need a framework-neutral runtime that runs on hardware outside AMD's GPUs, or if you cannot install ROCm first, since the README states that requirement without qualification. The first thing to verify is the model support and operator coverage in the published documentation at rocm.docs.amd.com, not in this repository, because the README here ends at the word Using and leaves the API undescribed.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ROCm/AMDMIGraphX on GitHub