Llama.cpp has its own built-in web UI that is fairly decent. Not as full featured as open web UI, but depends what you're after.

OpenWebUI works with plain llama.cpp

16 is a bit small so try a MoE (e.g. QWEN 3.6 35BA3B) model and put experts on the CPU (although DDR4 may be underwhelming) which you can do with llama ( with offloading and drafting for T/s) but not ollama (spitting noise). Here's a good starting point. You'll likely get 60+T/s on say a 6 bit quant.

You can use a container approach, but llama.cpp is a bit of a moving target, with new cool features coming along regularly to support new models. I build it in a distrobox and running it is a simple call. When it doesn't want to build anymore because dependencies have changed too much, I just spin up a new distrobox and leave the old one there for older models. I find it a good balance between flexibility and ease of maintenance, and technically it's also a container approach. Take notes so you know how to set up the new one.

The main reason anyone would "need to" switch to llama.cpp is if they want to do partial offloading, i.e. split the model between GPU and CPU. This works quite well for MoE models, but you didn't say anything about this, so I'm just wondering what your goals are.

Absolutely nothing wrong with switching to llama.cpp, I also use it, but that's because I occasionally want to run models larger than my VRAM. It has official docker images and a server with both API access and a decent web-UI.

If you're only going to run models which fully fit in VRAM, then tabbyAPI is also a good option. However, it uses Exl3 format instead of gguf, so llama.cpp probably makes more sense if you already have a lot of models in gguf format. tabby also comes with docker files and API support, so either should be quite easy to integrate with your setup.

I replaced ollama with LocalAI and its been smooth sailing ever since.