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.

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.

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 don't have answers, because I've been looking for such an amazing deal to fall into my own lap 😅 I'd love to hear your plans though! Which models are you excited to try out and what sort of tasks? Are you going to try to run a big MoE with Colibri? https://github.com/JustVugg/colibri

Good luck, and have fun!

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