# AMD MIGraphX: a graph inference engine for ROCm GPUs

> MIGraphX is AMD's graph optimization and inference engine for machine learning models on ROCm hardware. The README covers installing, building and containerizing it, but says nothing about what happens after a model loads.

**ROCm/AMDMIGraphX** — AMD's graph optimization engine.

- Repository: https://github.com/ROCm/AMDMIGraphX
- Website: https://rocm.docs.amd.com/projects/AMDMIGraphX/en/latest/
- Stars: 336 · Forks: 150
- Language: C++
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/rocm-amdmigraphx

## What MIGraphX is for, and who ends up using it

MIGraphX takes a trained model and runs it on AMD GPUs. The README calls it "AMD's graph inference engine, which accelerates machine learning model inference." That places it after training, in the serving path, not in the training loop. The repository is C++, MIT licensed, and lives under the ROCm organisation, so it is one component of a larger stack rather than a standalone product.

The audience is narrow in a useful way. You need a ROCm installation before MIGraphX will install at all; the README marks this with a note that says you must install ROCm first. If your hardware is NVIDIA and your toolchain is CUDA, nothing here applies. If you run AMD data centre or workstation GPUs on Linux and you want a graph-level inference engine that is versioned alongside the driver stack, this is the component AMD ships for that job.

The topic list on the repository (amdgpu, deep-learning, gpu-acceleration, inference, migraphx, rocm) matches that reading. There is no claim of training support, and no claim of CPU-only operation.

## The mechanism: graph reading, optimization, and serialization

MIGraphX is a graph engine. It reads a model, works on the graph rather than on individual operators, and executes the result on the GPU. The prerequisite list in the README is the clearest evidence of the data flow. Protobuf is listed "for reading onnx files", so ONNX is the input format the build depends on. HIP, MIOpen and rocBLAS are listed "for running on the GPU", which is the execution side. JSON and MessagePack are listed "for model serialization to json string format" and "to create database of kernels' tuning information" respectively, so a compiled or tuned graph can be written out and read back rather than rebuilt from scratch each run.

SQLite3 appears in the same list, and the README describes its purpose as creating "database of kernels' tuning information or run queries on existing database". That is a tuning cache: kernel selection results are persisted rather than rediscovered on every process start. It also means the engine has state outside the model file, and that state lives in a database you will need to manage in a container or a read-only filesystem.

pybind11 is a build prerequisite, so Python bindings are compiled from the same source tree rather than maintained separately. The README does not describe the internal pass pipeline, the operator coverage, or how the tuning database is keyed, so those remain open questions you would answer from the docs folder or the source.

## Installing MIGraphX from binaries and running a first model

The shortest path is the distribution package. The README gives a single apt command, and states that header files and libraries land under /opt/rocm-<version>, where <version> is the ROCm version. Run it on a machine that already has ROCm installed:

```bash
sudo apt update && sudo apt install -y migraphx
```

After that completes, the libraries are not on the default linker path unless your ROCm installation already put them there. You should expect to find them under the versioned /opt/rocm-<version> directory the README names.

If you would rather not install into the host, the repository ships a Dockerfile that builds a development environment with the prerequisites already present. The README gives the build and run commands. The build accepts a GPU_ARCH argument, and the README explains the trade-off directly: setting it reduces the image size, while leaving it unset installs device code for all supported architectures, which is what you want when one image has to run on different ROCm-supported GPUs.

```bash
docker build -t migraphx --build-arg GPU_ARCH=$(rocminfo | grep -o -m1 'gfx.*') .
```

The container needs the GPU device nodes passed through, and the README's run command also adds the video group and mounts the working tree:

```bash
docker run --device='/dev/kfd' --device='/dev/dri' -v=`pwd`:/code/AMDMIGraphX -w /code/AMDMIGraphX --group-add video -it migraphx
```

Inside the container the README says all required prerequisites are already installed, and points you at the CMake build steps starting from step 2. Note that the Dockerfile header in the repository uses a different image tag (migraphx-therock) and a different run invocation than the section above it; both appear in the repository, so match the one that corresponds to the Dockerfile you actually built. The README's Using section is where a first inference example would live, and in the version available here it is cut off at the heading.

## Building from source, and the GPU_TARGETS detail

Three build routes are documented: the ROCm build tool rbuild, plain CMake, and Docker. All three converge on the same prerequisite set, and the README recommends rbuild for installing those prerequisites even when you intend to use CMake.

The rbuild route is one command, but the interesting part is the argument:

```bash
rbuild build -d depend -B build -DGPU_TARGETS=$(/opt/rocm/bin/rocminfo | grep -o -m1 'gfx.*')
```

GPU_TARGETS is derived by asking rocminfo for the first gfx architecture string on the machine. That means the binary you produce is targeted at the GPU you built it on. Build on the wrong host and the artifact is not portable, which is a real constraint in CI where the build machine and the deployment machine are often different. The CMake path repeats the same expression, so the coupling is deliberate rather than incidental.

The CMake route also pins the compiler. The README's configure line sets CXX to /opt/rocm/llvm/bin/clang++, so the HIP toolchain's clang is expected, not the system compiler. Build type defaults to Release; Debug and RelWithDebInfo are documented as alternatives. Verification is a check target, and installation is a separate step:

```bash
make -j$(nproc) check
make install
```

The README notes that if rbuild is not found, it is because pip placed it in $HOME/.local/bin, and gives two fixes: export PATH with that directory prepended, or pass --prefix /usr/local to the pip install. That is a small thing, but it is the first error most people will hit.

## Where MIGraphX is the wrong choice

The hardest constraint is the platform. The README documents apt packages, an Ubuntu 24.04 based Dockerfile, and Linux build instructions. There is no Windows section, no macOS section, and no statement that either is supported. If your inference target is Windows, this repository does not give you a path, and the related searches for a Windows build have no corresponding answer in the README.

The second constraint is the ROCm dependency. MIGraphX is not a self-contained runtime you can drop into an arbitrary environment; the README requires ROCm first, and the build prerequisites pull in MIOpen, rocBLAS and HIP. On a machine without ROCm, or with a ROCm version that does not match the migraphx package your distribution carries, the install is not going to resolve cleanly.

The third is the tuning database. Because kernel tuning information is persisted in SQLite, a first run and a later run are not necessarily the same. That is normally what you want, but it complicates reproducible benchmarking and read-only container filesystems, and the README does not describe how to seed, version or discard that database.

Finally, the README does not document rollback. If a ROCm upgrade breaks your inference workload, there is no described procedure for returning to the previous MIGraphX build. That absence is worth weighing before you put it in a production path.

## How it differs from running ONNX Runtime on the same GPU

The closest alternative for many teams is ONNX Runtime, which also reads ONNX models and also has an execution provider for AMD hardware. The difference is architectural rather than a matter of speed. ONNX Runtime is a portable runtime with a pluggable provider model: the graph execution and the session API are the product, and a vendor contributes a backend. MIGraphX is the vendor's own engine, built inside ROCm and versioned with it, with its own serialization formats (JSON and MessagePack) and its own kernel tuning database.

That changes what you depend on. With ONNX Runtime you track one runtime version and a provider version that move on their own schedules. With MIGraphX you track the ROCm release train: the recent tags in this repository are named rocm-10.0, rocm-7.14 and rocm-7.2.4, so upgrading the engine generally means upgrading the stack around it. If your organisation already pins ROCm for other reasons, that alignment is a benefit. If you need to move the runtime independently of the driver stack, it is friction.

The repository layout reinforces the vendor-engine reading. There are example directories for diffusion, nlp, vision, transformers and onnxruntime under examples/, which suggests the project treats interoperation with ONNX Runtime as one scenario among several rather than as the primary interface.

## Licence, releases and the upgrade bill

MIGraphX is MIT licensed. The repository's requirements.txt carries the full MIT text with a copyright line covering 2015 to 2026, Advanced Micro Devices. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained, and it disclaims warranty. That is a statement about the licence text, not legal advice, and if you redistribute binaries you should confirm how the bundled ROCm components (MIOpen, rocBLAS, HIP, Protobuf and the rest) are licensed, because those are separate projects with their own terms.

Upgrade cost is the practical question. The release cadence follows ROCm: rocm-10.0 on 2026-08-28, rocm-7.14 on 2026-07-20, and rocm-7.2.4 on 2026-05-28. The last push to the develop branch was on 2026-09-10, so the tree is being worked on, but the tags tell you what the supported artefacts are. Because the build targets a specific GPU_TARGETS value and the tuning database is versioned by whatever the engine writes into it, an upgrade is not a drop-in library swap. Plan for a rebuild and a retune on each ROCm move you take, and check the CHANGELOG.md in the repository root for what changed between the tags you are jumping across.

## Conclusion

Adopt MIGraphX if you already run ROCm on AMD GPUs and want an inference engine that ships as a versioned ROCm component with a Python binding and ONNX reading through Protobuf. Do not adopt it if your deployment target is Windows, or if you need a documented rollback path between ROCm releases, since the README gives none. Before committing, verify that the ROCm version you have installed matches the migraphx package your distribution offers, because the README states ROCm must be installed first and installs headers and libraries under /opt/rocm-<version>.

## FAQ

### What is AMD MIGraphX?

It is AMD's graph inference engine, described in the README as accelerating machine learning model inference. It is written in C++, MIT licensed, and distributed as part of ROCm.

### How do I install MIGraphX?

The README gives a single apt command, sudo apt update && sudo apt install -y migraphx, and notes that ROCm must be installed first. Header files and libraries are installed under /opt/rocm-<version>.

### Does MIGraphX work on Windows?

The README documents apt packages, a Linux build via rbuild or CMake, and an Ubuntu 24.04 based Dockerfile. It contains no Windows installation or build instructions.

### What does MIGraphX need to read ONNX models?

The build prerequisites list Protobuf specifically for reading onnx files. The README does not describe model format support beyond that.

## Sources

- [License: MIT](https://github.com/ROCm/AMDMIGraphX/blob/develop/LICENSE)
- [Project website](https://rocm.docs.amd.com/projects/AMDMIGraphX/en/latest/)
- [README](https://github.com/ROCm/AMDMIGraphX/blob/develop/README.md)
- [Releases](https://github.com/ROCm/AMDMIGraphX/releases)
- [ROCm/AMDMIGraphX on GitHub](https://github.com/ROCm/AMDMIGraphX)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rocm-amdmigraphx