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

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.

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’d not use ollama, it’s basically just a fancy wrapper around lama.cpp.

There’s also modules/docker containers to hot swap models with lama.cpp

My model hosting setup is: Lama.cpp -> Open web UI

Lama.cpp is running in a local shell on my Mac Mini, since setting up GPU support with metal is (or was?) a pain. And open web UI sits in a docker with a local storage mounted so it have persistence when updating or moving the docker.

16gigs vram however ain’t too much, you’ll be fairly limited to fairly low quants. It will be reasonably fast tho. If you can use most of your system ram you could go and host f.e. qwen 3.6 bf8(~56gb) or bf4 (~30gb). It would be slower but you also gain a lot of usability from that.

Or you host two models a smaller one on the GPU and bigger one with system ram so you can switch between “knowledge” and speed.

Using lama.cpp you’ll have to take a look at huggingface & use gguf models.

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.