Okay, so that VRAM Vs RAM recommendation is a bit of BS. You absolutely do not need more than the base 512MB assigned to the GPU, as thanks to UMA and GTT, the GPU can actually access and utilise system RAM.

I personally didn't splurge for 395 with 128GB RAM, instead have two nodes:

• a Minisforum UM890 Pro with Ryzen 8945HS and 64GB DDR5. The main downside of this APU is the relatively low power NPU - although thanks to open-xdna, it is becoming more and more usable, especially if you want full TTS/STT pipelines (those can run on the NPU, leaving the CPU and GPU usable for LLMs).
• a Minisforum N5 Pro for NAS. Ryzen AI 370 + 64GB DDR5 as well. Thanks to the NPU, I can pin two smaller models (12-20b at Q4_M_K) and run them parallel without impacting other services, or one large model

Lemonade runs quite well in Docker, allowing for much cleaner updates - and the ability to use a barebones OS if need be - and as the Lemonade SDK guys went out of their way to provide API compatibility with llamacpp, OpenAI, Ollama and even Anthropic, plus an MCP server, it is now incredibly easy to hook it up to any downstream wrapper - say, OmniRoute, or Home Assistant, or direct into VSCode.

Lemonade being better than Ollama

Practically any modern runtime is better than Ollama at this point. Ollama is an expensive wrapper around llamacpp. Lemonade uses a bunch of runtimes - llamacpp, vLLM, FastFlowLM, plus ROCm environments for audiovisual genAI (TTS, STT, image, video and sound generation) - to provide you an all in one solution regardless what model you want to run.

One drawback is that dependency updates can be slow at times - meaning if a new model drops that requires a super recent runtime, you’re SOL.

But then again, it contains everything needed to start deploying LLMs - all you need is a base OS with a relatively recent kernel, AMD drivers and Linux-firmware packages, plus of course Docker. I’ve actually been utilising self hosted models to keep my Docker compose setup up to date - to research changes between versions, update the config accordingly, and verify any further one-shot upgrade needs.

The NPU doesn’t really need any extra setup if you run Lemonade in Docker. The Linux kernel ships with up to date amdxdna base drivers since 6.19, and the rest is in the firmware and ROCm runtime, which can be updated separately. An up to date Ubuntu or Debian server, and the latest Lemonade docker image should have it working - all you need to do is pass through the right device /dev/accel. Then download the NPU runtimes in the Lemonade web interface, download FLM models (regular GGUF doesn’t work, so you’re limited to models converted to what FastFlowLM expects), and you’re golden.

FLM models in my experience are a bit less performant (about 20% slower tpks, haven’t measured other metrics like TTFT etc), but at the time use a fraction of power compared to the GPU or CPU - 1-2W compared to the up to ~60W max TDP of the latter two combined… and it might be placebo but I’ve also noticed that the same model FLM vs GGUF, FLM tends to have slightly higher quality responses.

I use Strix Halo

On Linux you can just go into the bios and map like 512mb video and then update your grub config and you’re fine, Linux knows to use the unified memory correctly. I don’t know what your LLM told you, but you do not need a 50/50 split. The whole thing has worked for over a year now smoothly, and there are guides like kuz0’s online to help you get everything set up.

Lemonade is better than Ollama for a few reasons:

• lemonade is open source, ollama is a for profit closed source company that gives you simple and terrible defaults. They want you to pay for their cloud API. Ollama is also a hard fork of llama.cpp that never contributes back, and has unique bugs.
• lemonade can run many different engines, llama.cpp/stable diffusion, whatever, and AMD ships them precompiled for lemonade, so the rocm support is good
• lemonade does a reasonably good job making things easy to use but you can add params for whatever llama.cpp flags you want. It’s a good middle ground, but the default context window sizes need to be bumped (typically to 128*1024 on 128gb strix, more can get quite slow). Ollama has the same issue.

However, on the negatives, lemonade lags behind upstream engines, so if you wanted to say use Qwen 3.8 125b that just came out, you have to build it and link to rocm yourself. Usually it’s fine waiting a couple weeks, but sometimes I run a custom build and I point lemonade at it.

My stack is NixOS+Podman. I run lemonade in a container it all works great. I use Caddy + Authelia for networking and i serve it over tailscale to my tailnet.

check out HaloFPX. I can dig up the URL if you can't find it. it's a runtime that's made for Strix Halo that ships with custom tuned models for ROCmFPX (I think that's what it's called), and it can give you really good speeds.

one of the models it comes with is a custom Ornith 1.5 35B, and with HaloFPX I get speeds in Deepseek Harness that are so fast I can't read fast enough to keep up with generation.

EDIT link: https://github.com/julianmb/halofpx

In case some Strix Halo (or even other chips!) enjoyer hasn't seen those, Donato Capitella / kyuz0 has been making very interesting and possibly useful content including IIRC pretty much ready to run Vulkan and rocm containers with guides and tips.

https://www.youtube.com/channel/UCP0QFok6EimQYTMj5qOLNow

https://github.com/kyuz0

You don't need to worry about the split in strix halo, it runs a unified memory architecture so Linux will dynamically allocate VRAM on demand up to maximum possible (which would be around 120GB I think)

I'm on an nvidia system so can't answer the rest of your questions other than to say that in my experience ollama gave me a much worse tokens per second speed compared to running the same model using llama.cpp, so if you get something slower than you expect it might be ollama caused.

Good luck with your £250 system 😉

I have a Strix Halo as well and I have it configured to dynamically allocate everything, so I have run some 100GB+ models as well. The OS itself needs way under a GB without UI so you can get pretty close to the 128GB.

Currently on Fedora, running llama-swap to start the llama.cpp toolboxes by kyuz0, audio.cpp and ComfyUI.

Qwen3.8-27b is my favorite model right now for most things, still playing around with Qwen3.8-Flash-Next but not quite there yet.

Gemma4-31b is also really good with languages and natural writing but I prefer Qwen3.8 for anything programming or logical.

Yes, but I also ended up picking up a couple of AMD's discrete GPUs (and sticking them in my decade old desktop) after using it for a while. It turns out that while decode speed for MoE models is decent on Strix Halo, prefill is rather slow -- i.e. you end up having to wait a rather long time before the model starts producing text unless you keep the amount of information in context very small -- and Strix Halo is abysmally slow for dense models.

I used ollama when I started out, but ditched it in favor of just using llama.cpp directly once I was more familiar with LLMs. ollama's "modelfile" is quite annoying to deal with compared to writing a presets.ini file and I couldn't figure out how to get multimodal models from HuggingFace working with it even after spending a long time trying... not that llama.cpp has been all roses either; they break shit a lot -- e.g. this major bug affecting Strix Halo systems still needs a manual fix if you're building llama.cpp yourself -- and the documentation leaves a lot to be desired... but I can change settings like temperature per request and multi-modal from community models actually works and so on. 🤷️

What OS are you using? How do you have the RAM/VRAM ratio configured? What's your stack?

Fedora, 32GB regular/96GB VRAM (because I got OOMs on 70B models with the default config -- similar to what you encountered; may end up experimenting with this more as I try to get Qwen3.8-Flash-Next working though), llama-server + custom harness.

I still mainly run Qwen3.6 35B-A3B on it (usually llmfan46's heretic version, sometimes the stock weights) but have a lot of models downloaded for testing.

Edit: Disabling the memory split (i.e. switching back to "auto" in the bios) lets me load Qwen3.8-Flash-Next at lower quants. I've managed to get it to work up to Q4_K_M so far. I think it should be possible to run a higher quant with other techniques though, but I haven't managed it yet (as of 2026-08-28 10:37PM UTC).

Please explain how you paid 250 for a 3k machine