Lemonade 2026.40 RC Fixes AMD APU Streaming, Drops OpenMOSS ROCm

The release candidate appeared on GitHub on September 23, 2026, the same day as the 2026.39.1 release that introduced a new year-and-week version scheme. Phoronix first reported the changes. Everything below comes from Lemonade's release notes and the merged pull requests behind them.

Lemonade 2026.40 RC stops judging AMD APUs by their VRAM carve-out​

The bug hit a hardware class Lemonade is meant to serve well. On an AMD APU, the firmware reserves a small, fixed slice of system memory as dedicated VRAM, called the carve-out. The integrated GPU can also use a much larger share of system RAM through the GTT (Graphics Translation Table) pool. Per the release notes, streaming models now run on AMD APUs by sizing against the addressable GTT memory pool instead of the smaller fixed vRAM carve-out, resolving failures with models like DeepSeek-V4-Flash-IQ2XXS-DS4 on Ryzen AI Max (Strix Halo) hardware.

Pull request #3502 lays out the numbers. On a Ryzen AI MAX+ 395 (Strix Halo, gfx1151), the carve-out is about 1–4 GB, while the iGPU can allocate about 100–120 GB from GTT. DeepSeek-V4-Flash-IQ2XXS-DS4 streams from disk through Lemonade's ds4 backend and needs about 16 GB resident in GPU memory. Lemonade refused to serve it with a message saying the device's "largest memory pool is only 1.0 GB."

The cause was a dead code branch. Lemonade's model manager was supposed to use a "Largest" pool rule for any device labelled amd_igpu. The system-info layer never produces that label, though. Integrated AMD GPUs appear under amd_gpu with an "integrated": true flag, and their GTT size is stored in a virtual_mem_gb field. Every device therefore fell through to the "Hardware" rule, which reads only vram_gb. On an APU, that meant only the carve-out.

The fix picks the rule per device based on that device's own integrated flag. For an AMD APU, the ceiling becomes the larger of the carve-out and the GTT pool. AMD discrete GPUs and NVIDIA cards keep the old behaviour. The existing enable_dgpu_gtt option, which adds VRAM and GTT together for discrete-GPU setups, is also unchanged.

The Strix Halo test numbers behind the APU streaming fix​

The contributor tested three configurations on a Strix Halo system with 128 GB of RAM and a 1 GiB carve-out.

With the fix and no workarounds, lemonade load DeepSeek-V4-Flash-IQ2XXS-DS4 succeeded and chat ran on the iGPU. Resident memory while serving was 0.3 GB of VRAM and 32.1 GB of GTT. That confirms the carve-out never limited what the machine could run. Decoding was logged at about 4.98 tokens per second. That figure comes from one model on one machine and says nothing about speed on other models or APUs.

The pull request also sets limits on the fix. It relies on the GTT pool appearing in virtual_mem_gb. On the tested systems it did, and the author says any APU setup that leaves it out would be a separate bug. The author also points to two related problems this change does not fix. lemonade bench still sizes its default context from vram_gb and chooses contexts that are too small on APUs (issue #3263). The VRAM-pressure monitor also needs the same GTT-aware accounting (issue #2631).

Why Lemonade pulled OpenMOSS ROCm instead of waiting for a fix​

The second change removes an option. OpenMOSS is one of Lemonade's experimental speech backends. According to a RunAIHome guide to Lemonade, v11.0 in July added text-to-speech through an OpenMOSS backend with voice cloning and voice-design models. The 2026.40 candidate's breaking-changes list says the OpenMOSS backend's 'rocm' and 'rocm_bin' removed on Windows and Linux because ROCm builds run ~40x slower than Vulkan on the same hardware — use backend: vulkan or backend: cuda instead.

Continuous-integration (CI) testing, the project's automated test runs, exposed the problem. Maintainer Jeremy Fowers wrote in pull request #3615 that he was looking into why the OpenMOSS+ROCm job takes so long in CI and it turns out its because it runs on CPU, not GPU. A maintainer has therefore identified CPU execution as the direct cause, not just a guess from outside. The OpenMOSS job took 22 minutes 48 seconds, the longest of the 76 jobs in that CI run and the last to finish.

The benchmark used the release-v2026.39 build and server_audio_generation.py, requesting a 3-second clip at 4 diffusion steps with a fixed seed. The model was already loaded, so the times cover generation only.

The OpenMOSS gap works out to about 41x on Windows and 44x on Linux. The comparison rows are the key evidence. The same test file, payload, ROCm runtime (AMD's TheRock builds) and runners give thinksound 1.6-2.6s and acestep 1.0-1.1s per generation on ROCm, so the regression is specific to the OpenMOSS binary rather than the harness, the runner or the ROCm runtime. ROCm itself works fine on these Strix Halo runners. The OpenMOSS ROCm build does not.

What the OpenMOSS ROCm removal costs: TTS coverage goes too​

The removal also takes out something that worked. The commit message explains that Lemonade's backend descriptor lists support as one flat entry per backend, with no separate text-to-speech and audio-generation modes. Dropping ROCm for OpenMOSS audio generation therefore also drops it for OpenMOSS TTS. The same run measured TTS on ROCm as healthy: a voice-design job took 20.8 seconds on ROCm versus 43.8 seconds on Vulkan. Users who relied on ROCm for OpenMOSS speech synthesis will lose roughly half of that speed until the backend returns.

Existing setups break visibly rather than quietly. OpenMOSS configs with backend: "rocm" or a rocm_bin override no longer resolve. The documented fix is to use vulkan (or cuda on NVIDIA), or backend: "auto".

The team treats this as temporary. Fowers proposed merging right away to save CI time and, whenever a fix is available (ideally before the next release cut next wednesday), revert this PR and apply the fix. Collaborator pwilkin approved and said he would investigate. The pull request merged on September 17, and the removal is in the 2026.40.0 candidate. Nothing in the record shows a fix has landed yet.

The same candidate has a similar Windows-only change for image generation. The release notes say sd-cpp ROCm removed on Windows where the backend ran at CPU speed without any acceleration — switch to backend: vulkan or backend: auto. Two ROCm paths that silently ran on the CPU are now gone from this release.

Junie, API changes and the new Lemonade weekly release cycle​

The candidate includes more than the AMD fixes. JetBrains' coding agent Junie by JetBrains is a new launch agent available via lemonade launch junie, with profile generation and integration documentation. Cloud provider context window and completion token limits are now parsed from model metadata and surfaced on GET /v1/models. AMD GPU entries in GET /api/v1/system-info now show a marketing name such as "AMD Radeon RX 9070 XT (gfx1201)") instead of a raw numeric code. FastFlowLM, the NPU backend, moves to v1.0.6.

Developers who call Lemonade's API should check three breaking changes:

• The POST /v1/images/upscale endpoint now needs the model to carry the upscaling label, and models without it get an HTTP 400 error.
• Code that parsed the numeric GPU name from system-info should read the family field for the ISA code instead.
• Edits to user_models.json now officially require restarting lemond, the Lemonade server daemon, before they take effect.

Windows users should know one packaging detail. The release page states that the Windows installers in this candidate are unsigned, so Windows SmartScreen will warn before installing. Stable releases are signed.

The release schedule changed with 2026.39.1. The GitHub releases page lists v2026.39.1 as the "Latest" release, published September 23. Its breaking change is the version format itself: versions move from X.Y.Z to YYYY.WW.N, or YYYY.WW.0~<count>.<hash> for builds between releases. Any script that parses --version output or compares version strings needs updating. The same release adds configurable VRAM auto-eviction through auto_evict and auto_evict_threshold_pct, and keeps the prompt cache during soft-idle transitions. It also starts publishing release candidates as GitHub prereleases under candidate-v<version> tags and a Docker candidate image tag. A separate change moved the weekly release cutoff to Wednesday 16:00 UTC, which is why Fowers described next Wednesday as the deadline for an OpenMOSS fix.

What this means for you​

Your decision depends on your hardware and your current settings. Strix Halo and other AMD APU owners who were refused a streaming model can try the candidate now or wait for the signed 2026.40.0 stable build. Anyone using OpenMOSS on ROCm should change their config before upgrading.

• If you turned on enable_dgpu_gtt=true only to get disk-streaming models past the size check on an AMD APU, the 2026.40 default now uses the GTT pool itself (120 GB versus 121 GB in the Strix Halo test), so the workaround should no longer be needed.
• If any OpenMOSS config uses backend: "rocm" or a rocm_bin override, switch it to vulkan, cuda on NVIDIA, or auto, because the ROCm settings will stop resolving.
• If you use ROCm for OpenMOSS text-to-speech, expect it to slow down on Vulkan (43.8 s versus 20.8 s for voice design in the project's test) until ROCm support is restored.
• On Windows, stable-diffusion.cpp users on ROCm should move to vulkan or auto; the release notes say the ROCm build gave no acceleration anyway.
• Update any script that parses Lemonade version strings for the new YYYY.WW.N format, and if you install the candidate on Windows, the SmartScreen warning is expected because RC installers are unsigned.
• Don't count on lemonade bench context sizing or the VRAM-pressure monitor being fixed for APUs; both still count the carve-out and are tracked separately.

The fix itself is small: one condition in the model manager now checks the right field. Its effect is bigger, because a 128 GB Strix Halo machine can now serve a model that Lemonade said needed 16 GB of GPU memory it didn't have. The OpenMOSS ROCm removal is stopgap cleanup of a build found running on the CPU, and the maintainers want it reverted once fixed. With cutoffs every Wednesday at 16:00 UTC, the 2026.40 stable release will show whether that fix arrived in time or whether OpenMOSS users on AMD hardware stay on Vulkan for at least another week.