Lemonade 2026.46.2 can now install and run six containerized inference engines built for AMD’s Ryzen AI Max “Strix Halo” processors. The update turns a collection of specialized community runtimes into selectable backends inside one local-AI server. It is available now, but the new choices are Linux-only, limited to the gfx1151 GPU in Strix Halo, and described as guest backends rather than fully supported core components.[1][5][6]
A Ryzen AI Max machine can devote much of its unified memory to models that would never fit on an ordinary integrated GPU. The awkward part has been software: a fast community fork may expect a particular ROCm build, container image, launch command and set of device permissions. Lemonade now manages the image and model lifecycle while keeping its existing API and model manager in front.[3][4][5]
Six engines, one front door
The stable release adds Halogen Flash plus five container backends drawn from the Strix Halo Toolboxes project: DwarfStar4, Gufo, ROCm FPX, a NathanW Vulkan fork and the Halo Box ROCm fork.[1][5] They do not all do the same job. Some chase broad llama.cpp compatibility; others target particular models, quantization formats or performance paths. The underlying toolbox project recommends its standard Vulkan image for compatibility and labels several custom stacks experimental.[2]
Lemonade preserves some of that caution. Its support matrix classifies all six as “guest” backends. They appear only on Linux and only for AMD’s gfx1151 architecture.[6] A desktop Radeon card, a Strix Point laptop, an Nvidia GPU, a Mac and even a Windows Strix Halo box do not qualify for these new container paths. Lemonade’s existing native backends still serve many of those systems, but they are not what changed here.[6]
The practical gain is management, not free speed. Installing a backend pulls a digest-pinned image. Loading a model starts the matching container; unloading it stops the container. Model files remain outside the image and are mounted read-only, so changing engines should not require another copy of a 40GB or 80GB GGUF.[5][7]
HighVRAM checked the five Docker-hosted image digests pinned by this release against the registry. They were still retrievable on November 13. Their compressed layers total about 6.1GiB if a user installs all five: roughly 0.58GiB for NathanW, 1.32GiB for Halo Box, 1.30GiB for ROCm FPX, 1.57GiB for Gufo and 1.33GiB for DwarfStar4. That calculation sums the layer sizes for the exact pinned amd64 manifests; Halogen, hosted separately on GitHub Container Registry, is not included.[7][10][11]
Six runtimes are therefore a menu, not a recommended shopping list. Install the engine needed for a model or benchmark, and leave the rest in the registry. Disk is cheaper than unified memory, but it has not become decorative.
The setup is easier, not effortless
Lemonade prefers rootless Podman when it is installed and falls back to Docker. The packaged Linux service installs Podman and the needed account permissions automatically on supported Debian and Fedora packages. A user-run server needs Podman plus the crun runtime and membership in the render group. Docker Desktop and rootless Docker are explicitly unsupported for these backends.[5]
That distinction matters because a container can start successfully and still miss the GPU. The documentation warns that rootless Podman using runc instead of crun cannot preserve the render group inside the container; the backend may then fall back to the CPU. Lemonade checks the prerequisites and reports an action-required state, but owners should confirm GPU activity before trusting a benchmark.[5]
Halogen has one extra demand: Linux kernel 6.18.4 or newer with the HSA AMD shared-virtual-memory option enabled.[5] The other five still require the Strix Halo GPU device and a working container stack. None of this changes model fit. A 128GB system has a much wider choice of weights and context lengths than a 32GB configuration, and the operating system, runtime buffers and KV cache all consume part of the shared pool.
Fresh performance numbers are the missing piece. The release notes contain no cross-backend tokens-per-second table, and the toolbox project now labels its bundled benchmark results a legacy archive, directing readers to a newer external benchmark site.[1][2] It would be tempting to read six engine names as six upgrades. They are six testable options. The fastest one will depend on the model, quant, context length and workload.
A sensible container boundary
The container design is reasonably conservative. Lemonade pins every image by digest, mounts only the required model files as read-only, drops unneeded Linux capabilities, enables the no-new-privileges setting and puts each backend on an internal network. The inference service remains reachable from the host, while the container itself has no internet route.[5][8]
That does not make third-party code magically trustworthy. These are community engines running with access to GPU device nodes, and Docker membership or a rootful Podman socket gives the Lemonade service powerful control over the host’s containers.[5] Digest pinning prevents a tag from changing underneath an installation; it does not independently audit the code inside the pinned image.
Existing DwarfStar4 users should also note the one direct migration. Version 2026.46.2 replaces Lemonade’s native DwarfStar4 backend with a container while keeping previously downloaded GGUF files usable.[1][9] Automation that expects the old binary or inspects Lemonade’s model API should read the breaking changes before updating. The release also moves image and audio defaults inside recipe options and tightens several FastFlowLM request behaviors.[1]
For a Linux Strix Halo owner already comparing community runtimes, 2026.46.2 is worth installing. It replaces several hand-built launch paths with one manager and a consistent local API, while keeping the model files under the owner’s control. Windows users should stay on Lemonade’s native paths for now. Everyone else should wait for measurements before choosing a backend because its name sounds faster. The next useful result is a reproducible same-model, same-context comparison across these six engines, not another screenshot of a model loading successfully.
Sources
- [1] Lemonade v2026.46.2 release notes
- [2] AMD Strix Halo Llama.cpp Toolboxes
- [3] Lemonade repository
- [4] Lemonade project site
- [5] Lemonade container backend guide
- [6] Lemonade v2026.46.2 backend reference
- [7] Lemonade v2026.46.2 backend version pins
- [8] Lemonade container backend specification
- [9] Lemonade DS4 container backend pull request
- [10] AMD Strix Halo Toolboxes container registry
- [11] Strix Halo DwarfStar4 container registry