FastFlowLM hit version 1.0 on August 11, 2026, and it did so from a new address: the ROCm organisation on GitHub, rather than an independent project page. That move is the actual news. FastFlowLM runs language models directly on the XDNA2 neural processing unit in Ryzen AI laptops, with no discrete GPU involved, out of a 17 MB install that behaves like the local model runners you already use. Until now AMD's NPU story on Linux was a collection of separate efforts. Putting this one under the ROCm umbrella turns it into something you can reasonably plan around.
The short answer
FastFlowLM 1.0 is the first general release under AMD's ROCm organisation on GitHub, carrying its full issue and pull request history across. It runs language, vision, audio, embedding and MoE models on Ryzen AI XDNA2 neural processing units with no discrete GPU, exposes a local server on port 52625, and adds support for the SmolVLA vision language action model.
Most laptops sold with a Ryzen AI badge in the past two years contain a piece of silicon their owner has never deliberately used. The NPU sits there, shows a flat line in Task Manager, and occasionally gets borrowed by a video call for background blur. FastFlowLM exists to change that, and as of August 11, 2026 it does so with AMD's name over the door.
Version 1.0 is described by the project as the first general release under the ROCm organisation, and the migration brought all issues, pull requests and history with it. That detail is the difference between a rebrand and an adoption. What was an independent runtime for a niche accelerator is now part of the same software umbrella as the rest of AMD's compute stack.
What it actually is
FastFlowLM, or flm at the command line, runs models on AMD Ryzen AI NPUs. Not on the integrated GPU, not on the CPU with NPU assistance, on the NPU. The project describes itself as NPU first and compares its shape to the local model runners most developers already have installed, which is an accurate description of how it behaves.
The scope has widened past text. The runtime now covers vision, audio, embedding and mixture of experts models, and 1.0 adds SmolVLA, a vision language action model built for robotics. Context lengths go up to 256k tokens. The whole thing is 17 MB installed and the project claims a twenty second install.
Supported hardware is narrower than the marketing category. It is all Ryzen AI series chips with XDNA2 NPUs, which the project names as Strix, Strix Halo, Kraken and Gorgon Point. There is also a driver floor at version 32.0.203.304, with .311 recommended, and that floor is worth checking before you conclude anything about compatibility.
The part that matters for your machine
The interesting argument for an NPU is not raw speed. It is that inference stops competing with everything else you are doing.
A model running on your discrete GPU takes VRAM and scheduling slots away from the compositor, the browser and anything else with a rendering path. A model running on your CPU takes cores away from your build. A model running on the NPU takes a resource that, on almost every laptop, is otherwise idle. The project's efficiency claim is over ten times better power efficiency than the alternatives, which on a machine running on battery is the difference between a local assistant you leave running and one you start deliberately.
That is the case for putting a small model on the NPU permanently: completion, classification, summarisation, embedding for a local search index. The tasks where you want an answer in a few hundred milliseconds and you want them available without thinking about what else is running.
Getting it into something you already have
The integration surface is a local HTTP server. flm serve starts it on port 52625 by default, optionally with a model tag to preload. If a request arrives naming a different model, the runtime switches rather than erroring, which removes a category of orchestration you would otherwise have to write yourself.
For interactive work, flm run llama3.2:1b opens a session in the terminal. Inside it, /verbose toggles performance reporting so you can see tokens per second without leaving the conversation, and /bye exits. flm list shows what is available locally.
Model storage differs by platform in a way that matters if you keep weights on a separate volume. On Linux the default is ~/.config/flm, overridable with the FLM_MODEL_PATH environment variable. On Windows it is under Documents, or wherever you pointed the installer. Model kernels are pulled from Hugging Face on first use, so the first run of any model needs network access, and the project documents flm pull <tag> --force for the case where a download lands corrupted.
Why the ROCm move is the story
AMD's software problem has never been that it lacked projects. It has been that a developer trying to target AMD hardware had to work out which of several overlapping efforts was the one with a future.
Pulling FastFlowLM under ROCm answers that question for the NPU specifically. It puts NPU inference in the same organisation as the GPU compute stack, under the same MIT licence the release carries, with the history intact so existing issues and discussions did not evaporate. For anyone deciding whether to build against the Ryzen AI NPU on Linux, that is a materially different risk calculation than it was a week ago.
It also fits a pattern we have been tracking. AMD has been steadily absorbing infrastructure into ROCm rather than leaving it scattered, as with Spur, its Rust job scheduler that speaks Slurm. And the demand side keeps arguing for exactly this class of tool: Meta's Muse Glimmer shipped a 30B agent model aimed at a single GPU, and the smaller models FastFlowLM targets are the ones that fit an NPU comfortably.
Sources and further reading
- FastFlowLM 1.0 Released Now As Part Of The AMD ROCm Umbrella, Phoronix, August 11, 2026
- FastFlowLM v1.0.0 release notes, GitHub
- FastFlowLM repository under the ROCm organisation
- FastFlowLM documentation
- FastFlowLM Linux getting started guide
Frequently asked questions
What does running a model on an NPU buy me over the CPU or GPU?
Power, mostly, and the freedom to keep working while it runs. An NPU is a fixed function matrix engine sitting on the same package as the CPU, designed for sustained inference at low wattage rather than peak throughput. FastFlowLM's own claim is over ten times better power efficiency than the alternatives on the same laptop. The second benefit is less discussed and often matters more day to day: the NPU is a resource almost nothing else on your machine competes for. Running a model there does not take your GPU away from the compositor, your browser or a game, and it does not saturate the cores your build is using.
Which hardware actually works?
All Ryzen AI series chips with XDNA2 NPUs, which the project lists as Strix, Strix Halo, Kraken and Gorgon Point. Anything older, including first generation XDNA parts, is out of scope. There is also a driver floor that catches people: the project requires NPU driver version 32.0.203.304 or newer and recommends .311. On Windows you can check that in Task Manager under Performance, or in Device Manager. If the runtime behaves oddly on paper compatible hardware, the driver version is the first thing to rule out rather than the last.
Is this Linux software or Windows software?
Both, with Windows currently the smoother path. The 1.0 release ships prebuilt binaries for Ubuntu, Debian, generic Linux x86_64 and Windows, and there is a dedicated Linux getting started guide in the repository. The Windows side has a packaged installer and is where most of the documentation and the demo material points. On Linux, models land in ~/.config/flm by default and you can redirect that with the FLM_MODEL_PATH environment variable, which is the detail you want if you keep model weights on a separate volume.
How does it fit into something I have already built?
Through a local HTTP server on port 52625. Running `flm serve` starts it, and if a request names a model that is not currently loaded the runtime switches to it rather than failing. That pattern will be familiar if you have wired anything against a local model runner before, and it means an existing client pointed at a different port is usually a one line change. For interactive use, `flm run <model>` gives you a terminal session, `/verbose` toggles performance reporting during that session, and `flm list` shows what is available locally.
What is new in 1.0 specifically, beyond the org move?
Three things worth noting. Support for SmolVLA, a vision language action model aimed at robotics, which extends the runtime past text and vision into models that emit actions. A reworked `flm bench`, which now runs two iterations at each context length from 1k to 32k by default with a flag to ask for more, making its output something you can actually compare between machines. And a fix for multi image handling in Qwen3-VL. The release also carried over every issue, pull request and the full history to the ROCm organisation, which matters more than it sounds: a move that drops its history is a restart, and this one is not.