Open WebUI 0.12 on a VPS Without GPU: What Works on CPU

Open WebUI AI on CPU Ollama

Open WebUI 0.12 runs well on a VPS without a GPU, but only part of its new voice feature does. The headline Realtime voice mode needs OpenAI's paid Realtime API. The older Standard voice mode runs fully on your own CPU: local Whisper turns a short question into text in about 3.5 seconds, a small local voice model reads the answer aloud, and the first spoken words arrive 6 to 10 seconds after you stop talking. We installed Open WebUI 0.12.2 on Debian 13 with 4 vCPUs and 6 GB of RAM and timed every step.

Key facts, checked on 15 October 2026:

Open WebUI v0.12.0 was released on 10 October 2026, followed by v0.12.1 and v0.12.2 on 14 October (GitHub releases). We tested v0.12.2.
Realtime calls default to the gpt-realtime-2.1-mini model with the "marin" voice, and a call ends after one hour (v0.12.0 release notes).
The v0.12.2 Docker image is 4.53 GB on disk, and Open WebUI used 1.1 to 2.0 GB of RAM in our lab.
With Ollama on 4 threads, qwen2.5:1.5b wrote 27 to 29 tokens per second and llama3.2:3b about 12. With the wrong thread count the same 1.5B model fell to 0.3 tokens per second.
The open-source Kokoro-FastAPI v0.9.0 (released 10 September 2026, GitHub) made 10.2 seconds of speech in 6.4 seconds on CPU.

This is a release review. For the basics (RAM per model size, mixing API and local models) read our Open WebUI and LLM on a VPS guide first.

The 0.12 features, rated for a CPU-only server

Open WebUI is a self-hosted chat interface, similar to ChatGPT, for local models (through Ollama) or cloud models (through an API). Version 0.12 is mostly about voice, plus admin features.

Feature	On a CPU server	What we measured
Realtime voice calls (new in 0.12.0)	Needs a paid API	Not tested; the 0.12 release notes name only OpenAI and Azure OpenAI as providers
Standard voice calls, speech to text with local Whisper "base"	Works on CPU	3.3 to 3.5 s for a 3 s question, 7.4 s for 30 s of speech, every word right
Whisper "small" model	Works, but slow	9.3 s for 10 s of speech, about 0.6 GB more RAM
Text to speech with Kokoro-FastAPI (CPU image)	Works on CPU	1.8 s for a 6-word sentence, 6.4 s for 27 words, 24 s for 81 words
Built-in "Transformers" text to speech	Failed in our test	HTTP 500, see the voice section
Knowledge bases (RAG) with the new file browser	Works on CPU	125 KB of text indexed in 18 to 23 s, answers in 8 to 20 s
Two-factor sign-in, admin reset command	Works, no model needed	Recovery token printed, existing sessions signed out
Nested groups	Works, no model needed	Parent and child group created through the API
Animated avatars, Tool Search, skills, version history, shared chat replies	Not tested	Release-note features we did not run in our lab

Voice that answers as fast as a person needs OpenAI's paid Realtime API or a GPU server; a CPU server cannot run that part locally.

Our test box, and why your numbers may differ

We used a Debian 13 container limited to 4 vCPUs and 6 GiB of RAM on our Amsterdam lab server, an AMD EPYC 7742 with 8 cores shared with other test labs (load average 6 to 19 during our runs). These are results from our lab, and real plan speed can differ. A VDS Small has the same 4 vCPUs, dedicated, so expect similar or better numbers. Software: Ollama 0.40.4, Open WebUI 0.12.2, Kokoro-FastAPI 0.9.0, Docker 26.1.5. Models: qwen2.5:1.5b (986 MB) and llama3.2:3b (2.0 GB), both 4-bit quantized, meaning each weight is stored in about 4 bits to save RAM.

Voice on CPU: Standard mode works, Realtime does not run locally

Open WebUI 0.12 has two voice call modes. Standard is a chain of three steps: speech to text (STT), the chat model, and text to speech (TTS). Each step can run on your own server. Realtime, new in 0.12.0, puts a cloud voice model on the line. It handles small talk and hands real questions to your chosen chat model (Open WebUI blog, 10 October 2026). Its switch, under Admin Settings, Audio, Voice calls, is off by default, and we left it off: our labs use no paid API keys.

Speech to text: keep Whisper on "base"

Whisper is OpenAI's open speech recognition model, and Open WebUI ships it built in (as faster-whisper) with the "base" size as the default. On our 4 vCPUs, base transcribed a 2.9-second question in 3.3 to 3.5 seconds and a 30-second paragraph in 7.4 seconds. The text came back word for word. Most short-clip time is fixed overhead.

The "small" model took 9.3 seconds for 10 seconds of speech and 17.9 for 30, with no better text on our clear audio and 0.6 GB more RAM. Stay on base unless your users have strong accents or noisy microphones.

Text to speech: the built-in engine failed, Kokoro worked

The default TTS engine is the browser's own voice, which runs on the user's device. For a server-side voice, Open WebUI offers a local "Transformers" engine. In 0.12.2 it answered with HTTP 500, and the log showed RuntimeError: Dataset scripts are no longer supported, but found cmu-arctic-xvectors.py. A library it depends on no longer loads its voice data, so skip that engine until the release notes mention a fix.

Kokoro-FastAPI worked. It wraps the 82-million-parameter Kokoro voice model behind an OpenAI-style speech API, and Open WebUI's docs list it as a community integration (Kokoro-FastAPI integration). Its CPU image is 3.28 GB and used 1.0 to 1.6 GB of RAM. Speed in our lab:

Text	Time to make it	Length of the audio
"Sure, here is the short answer." (6 words)	1.84 s	1.92 s
15 words	3.47 s	5.16 s
27 words	6.44 s	10.25 s
81 words	24.06 s	30.14 s
The same 27 words again	0.03 s	10.25 s (Open WebUI cached it)

Kokoro runs a little faster than speech plays, and Open WebUI splits replies at punctuation, so short first sentences make the voice feel much quicker.

One full voice turn, timed

For a 2.9-second spoken question with qwen2.5:1.5b already in memory, Whisper took 3.3 seconds, the model's first sentence 1.4 seconds, and Kokoro 5 to 6 seconds to voice a 25-word sentence (under 2 seconds for a 6-word opener). That is about 6 to 10 seconds from the end of your question to the first spoken word: fine for hands-free questions, dictation and accessibility, not a natural conversation. With llama3.2:3b add 1.5 seconds, and if the model must load first (after 5 idle minutes by default) add 3 to 7 more.

The thread setting that made chat 90 times faster

Our first test gave 0.31 tokens per second for a 1.5B model, which is unusable. The Ollama log explained it: n_threads = 8 (n_threads_batch = 8) / 4. Ollama counted the host's 8 cores and started 8 threads on 4 vCPUs, and the threads stalled each other. Forcing 4 threads fixed it:

Model	2 threads	4 threads	8 threads on 4 vCPUs
qwen2.5:1.5b	18.6 tokens/s	26.6 to 29.1 tokens/s	0.3 tokens/s
llama3.2:3b	7.3 tokens/s	12.1 to 12.4 tokens/s	not run

On a KVM server the guest should see only its own vCPUs, so this mainly bites inside containers with a CPU limit, but it costs nothing to check. Run journalctl -u ollama --no-pager | grep n_threads as root after the first chat, and if the first number is bigger than your vCPU count, pin it as in step 3 below. The 2-thread column shows why cores matter: 4 threads were about 50% faster.

A token is a piece of a word, about three quarters of an English word. Through Open WebUI, the 1.5B model wrote a 52 to 73 word answer in 2.9 to 4.1 seconds; the 3B model took 9.5 seconds for 92 words.

Knowledge bases on CPU: the file browser and RAG

RAG (retrieval-augmented generation) means Open WebUI cuts your documents into chunks, turns each into numbers with an embedding model, and pastes the best matches into the prompt. In 0.12 a knowledge base opens as a file browser where you can edit the text the model searches.

We loaded six licence texts (AGPL, Apache 2.0, GPL 3, LGPL 3, MPL 2.0, CC BY 3.0), 125 KB in total, into a knowledge base. The default embedding model, all-MiniLM-L6-v2, runs on the CPU inside Open WebUI. Indexing took 23.4 seconds with the default batch size of 1 and 18.2 seconds with batch size 16 (Admin Settings, Documents). The longest file, the 34.5 KB AGPL text, took 4.8 to 6.4 seconds on its own. Fine for manuals, slow for a 10,000-file archive.

The question "Under the Apache License 2.0, what must I give recipients when I redistribute the work?" took 8.1 seconds with qwen2.5:1.5b and 19.8 seconds with llama3.2:3b once the models were warm, and 28 to 73 seconds cold. Both used the right document, but only the 3B model mentioned "a copy of the License"; the 1.5B model fixed on the appendix's boilerplate notice. For answers you rely on, keep the embeddings local and use a cloud model for the chat step.

Two-factor sign-in (MFA) is new in 0.12.0: admins can require an authenticator app, and users get ten recovery codes. If someone loses their phone, an admin runs a reset command. The release notes call it open-webui mfa reset, but that program is not on the PATH inside the Docker image. This form worked for us:

# as the ai user
docker exec -w /app/backend open-webui python -c "from open_webui import app; app()" mfa reset admin@lab.test --reason "lab test"

It printed Recovery token (expires in 30 minutes; deliver securely to the verified user) followed by the token. Our open API session stopped working right after, so expect to sign in again. Nested groups worked too: we created a "Support" group inside "Company", and per the release notes the child inherits the parent's shares and permissions.

Set it up: the commands we ran

On a fresh Debian 13 server (harden it first with our Debian 13 security checklist):

Step 1. Install Docker and Ollama, and create a normal user for the containers:

# as root
apt-get update
apt-get install -y docker.io docker-compose curl sudo jq
useradd -m -s /bin/bash -G docker ai
curl -fsSL https://ollama.com/install.sh | sh

The installer warns "Unable to detect NVIDIA/AMD GPU", which is expected. Ollama then listens on 127.0.0.1:11434.

Step 2. Keep only one model in memory and download a model. Without this, Ollama kept two models loaded and the out-of-memory killer stopped it twice in our 6 GB lab:

# as root
mkdir -p /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment=OLLAMA_MAX_LOADED_MODELS=1\n' > /etc/systemd/system/ollama.service.d/override.conf
systemctl daemon-reload
systemctl restart ollama
ollama pull qwen2.5:1.5b

Step 3. Make a copy of the model with the thread count fixed to your vCPUs (4 on a VPS Mini or VDS Small, 8 on a VDS Medium):

# as root
cat > /root/Modelfile <<'EOF'
FROM qwen2.5:1.5b
PARAMETER num_thread 4
EOF
ollama create qwen2.5-cpu -f /root/Modelfile

Ollama prints "success", and qwen2.5-cpu:latest appears in the model list in Open WebUI.

Step 4. Start Open WebUI with a fixed secret key in a file. The key signs user sessions, and if it changes everyone is logged out (update docs). HOST=127.0.0.1 keeps port 8080 off the internet:

# as the ai user
mkdir -p ~/openwebui && cd ~/openwebui
printf 'WEBUI_SECRET_KEY=%s\nOLLAMA_BASE_URL=http://127.0.0.1:11434\nHOST=127.0.0.1\n' "$(openssl rand -hex 32)" > webui.env
chmod 600 webui.env
docker run -d --name open-webui --network host --env-file webui.env -v open-webui:/app/backend/data --restart always ghcr.io/open-webui/open-webui:v0.12.2
curl -s http://127.0.0.1:8080/api/version

The download took 4.5 minutes; about 30 seconds after the start the last command returned JSON with "version":"0.12.2". To reach the page from your computer, add HTTPS with our Caddy, Nginx and Traefik guide or use an SSH tunnel. The first account you create becomes the admin.

Step 5. Add Kokoro for server-side voices:

# as the ai user
docker run -d --name kokoro --restart always -p 127.0.0.1:8880:8880 ghcr.io/remsky/kokoro-fastapi-cpu:v0.9.0
curl -s http://127.0.0.1:8880/health

When the health check reports healthy (almost 4 minutes in our lab, including the download), go to Admin Panel, Settings, Audio. Set the TTS engine to OpenAI, the API base URL to http://127.0.0.1:8880/v1, the key to not-needed, the model to kokoro and the voice to af_bella. Leave speech to text on the built-in Whisper, model base. (In the lab we set these values through Open WebUI's API.)

Disk use: 7.8 GB of images, 3.1 GB of models and a 2.9 GB data volume. That fits easily on a VPS Mini's 80 GB.

Upgrading from 0.11 or older: back up the volume first

Backing up is your job, before every update: the docs warn that database migrations are one-way, so only a backup brings the old version back. We left out the cache folder, which holds models Open WebUI downloads again by itself:

# as the ai user
cd ~/openwebui
docker stop open-webui
docker run --rm -v open-webui:/data -v $(pwd):/backup alpine:3.22 tar czf /backup/openwebui-$(date +%Y%m%d).tar.gz --exclude=data/cache -C / data
ls -lh openwebui-*.tar.gz
docker rm open-webui
docker pull ghcr.io/open-webui/open-webui:v0.12.2
docker run -d --name open-webui --network host --env-file webui.env -v open-webui:/app/backend/data --restart always ghcr.io/open-webui/open-webui:v0.12.2

Without the cache the backup was 4.0 MB and took 1 second. With the cache it was 2.1 GB and took over 6 minutes. After the restart, Open WebUI was healthy in 29 seconds, and our knowledge bases and groups were all there. Copy the archive off the server too, for example with restic to another machine.

We re-created a 0.12.2 install; a real jump from 0.11.4 failed in the lab because the old image download kept breaking. From the 0.12.0 notes:

Update all Open WebUI instances at the same time. Rolling updates are not supported.
Milvus 2.5+ users: the first start copies every collection, which needs free disk and can take hours.
From 0.12.2, installs that use VECTOR_DB=valkey need valkey-glide-sync 2.5.2 or newer, or they fail at startup.

Which plan and which city

RAM sets the floor: Open WebUI 1.1 to 2.0 GB, Kokoro 1.0 to 1.6 GB, qwen2.5:1.5b 1.2 GB, and llama3.2:3b more than that (its download alone is 2.0 GB). The full voice stack with the 1.5B model used 3.2 GB. CPU sets the speed.

Your situation	Plan	Why
1 or 2 people, chat with cloud API models, browser voice	VPS Mini (4 shared vCPU, 4 GB, 80 GB NVMe)	Open WebUI needs under 2 GB; the model runs at the API provider
Small team, local Whisper and Kokoro, 1.5B model for quick jobs	VDS Small (4 dedicated vCPU, 8 GB, 240 GB NVMe)	Same core count as our lab; the full stack used 3.2 GB, so RAG and a second model fit
Local 3B model plus voice, several users	VDS Medium (8 dedicated vCPU, 16 GB, 480 GB NVMe)	8 threads and enough RAM to keep voice and a bigger model loaded together
Department or many daily voice users	VDS Large (16 dedicated vCPU, 32 GB, 960 GB NVMe)	Room to run several model copies in parallel. We did not load-test this size.

With Ollama on its default settings, three users asking at once were served one after another: the first saw text after 0.4 seconds and the others waited 5.9 and 7.3 seconds. Dedicated vCPUs on VDS plans keep that speed steady when neighbours get busy. Our VPS vs VDS comparison explains the difference.

For the city, 6 seconds of processing dwarfs 10 ms of ping, so choose by where your users and data should be. Our own ping.pe measurements from 6 October 2026, published on our location pages, show Amsterdam reached in 6.6 ms from Frankfurt and 9.3 ms from Paris (VPS Netherlands), and Prishtina in 18.6 ms from Vienna and 3 ms from Skopje on our own network (VPS Kosovo). For Dublin, our VPS Ireland page quotes WonderNetwork averages of about 11 ms to London. Availability by city is on the plans page.

An honest note: for fluent, interruptible voice chat, a paid cloud voice service beats any CPU server, and for one person chatting with one cloud model, the provider's app is simpler. A server pays off when several people share one interface, documents must stay with you, or private jobs need local models. See the VPS and VDS plans page.

Frequently asked questions

Can Open WebUI 0.12 voice mode work without a GPU?

Yes, the Standard voice mode works without a GPU. In our test on 4 vCPUs, local Whisper base transcribed a short question in about 3.5 seconds, and Kokoro text to speech made speech slightly faster than real time. The first spoken word came 6 to 10 seconds after the question. The new Realtime mode needs OpenAI's paid Realtime API instead.

How much RAM does Open WebUI 0.12 need on a VPS?

Open WebUI 0.12.2 itself used 1.1 to 2.0 GB of RAM in our lab, and the higher figure is with the Whisper small model loaded. Add 1.0 to 1.6 GB for Kokoro and 1.2 GB for a 1.5B Ollama model. 4 GB suits cloud models; 8 GB suits a fully local voice setup.

How fast is Ollama on a CPU-only VPS?

On 4 vCPUs of an AMD EPYC 7742 in our lab, qwen2.5:1.5b generated 27 to 29 tokens per second and llama3.2:3b about 12 tokens per second. With 2 threads the speeds were 18.6 and 7.3. If Ollama starts more threads than you have vCPUs, speed can collapse; we saw 0.3 tokens per second.

Why is the Transformers text to speech engine failing in Open WebUI?

In our test of Open WebUI 0.12.2, the built-in Transformers engine returned HTTP 500 with "Dataset scripts are no longer supported, but found cmu-arctic-xvectors.py". Kokoro-FastAPI with the OpenAI engine setting worked instead.

How do I upgrade Open WebUI without losing chats?

Stop the container, archive the data volume, then remove the container, pull the new image and start it again with the same volume and the same WEBUI_SECRET_KEY. Database migrations are one-way, so the archive is the only way back. Leaving out the cache folder made our backup 4 MB instead of 2.1 GB.

Is a VPS or a VDS better for Open WebUI?

A VPS Mini with 4 shared vCPUs and 4 GB is enough when the models run at a cloud API. For local models and local voice, a VDS is better, because its vCPUs are dedicated and CPU inference uses every core it gets. VDS Small (4 vCPU, 8 GB) matches our test setup.

Try 0.12 on your own server

Start with Standard voice, Whisper base and Kokoro on dedicated cores, and add a cloud model when answers must be better. Pick a VPS or VDS plan in Amsterdam, Dublin or Prishtina. If you would like us to set up Open WebUI for you, ask on Telegram and we will quote the job. For the next step after chat, see our guides to running an LLM on a VPS without a GPU and hosting an MCP server.

← All articles