Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!
If you've been on the internet recently, there's a high chance you heard about Large Language Models. Most notable companies in this field include OpenAI, Google, Antropic and xAI. To access their models you typically need to communicate with the service via an API. Such use while convenient, means user has little to no knowledge about how the data sent there is stored and used.
Additionally, when users submit data through these services, it might be embedded into future models. Companies often train new models on a variety of user-submitted data, which can include any text inputs you've provided. This raises serious privacy concerns, as personal information could inadvertently become part of the training set for subsequent AI models. AI giants will often say they're trying to respect your privacy with data "anonymization" and other techniques, but we all know how this works in practice. See: Anthropic's Privacy Policy and OpenAI explaining how they "improve model performance" with users data.
The vast amount of sensitive user data stored can have devastating consequences if a leak occurs. In AI space it's not uncommon to leak data either via compromised servers or models themselves. In the past year alone companies suffering such leaks include: OpenAI, Anthropic and DeepSeek.
Assume all conversations with online chatbots can be public at any time.
A partial solution to those problems could be a service that aggregates multiple model APIs and anonymizes their users. A bit like searxng does for search engines.
AI companies can't know who exactly uses their models since the amount of metadata is heavily limited.
There're several such services including ppq.ai, NanoGPT or DuckDuckGo chat. This is only a partial solution since your conversation contents can still be saved and used for later training by large AI companies.
Another option available is to self-host LLM on your own infrastructure. This will effectively prevent sending your data from being sent to third parties.
It can work fully offline on device but you'll need to have the required resources. You also have to understand certain more advanced concepts related to LLMs.
Parameter Count
Each open model has specified number of parameters. This can range from 0.5 billion (qwen 2.5) to even 671 billion (deepseek r1). The more parameters model has, the more knowledge can be packed into it. This comes at a cost of more physical RAM/VRAM memory being used. Newer generation models are fairly capable even at 8 billion parameters but it's not uncommon to use 12, 14 or 32 B ones.
Quantization (improving memory usage)
Usually the model + context needs to fit into RAM/VRAM memory. Each model parameter can be represented with certain precision. For example, FP16 uses 16 bits (2 bytes) of memory to store a single parameter, while Q4_0 uses only 4 bits. This means that FP16 model will use ~4x of the memory compared to Q4_0.
Of course using Q4_0 will introduce some rounding error in quantization step, but it's usually not a big deal. Look at the graph below to see how different quantization parameters affect model accuracy and memory usage of llama 3.1 8B.
I highlighted the Q4_K_S and Q4_K_M quantization methods since they're usually offer the best balance between model size and accuracy.
They usually use a bit more than 4 bits per parameter, but have better precision than plain Q4_0. If you're pulling model from ollama without specifying the precision, there's a high chance that you'll get Q4_K_M variant since it has been the default for some time.
The rough formula for calculating memory usage of an Q4_K_M quantized LLM would be: [n billion parameters] * (4.5 / 8) + [context window size].
For 8B model, we would require around 6 GB VRAM/RAM to comfortably run it as Q4_K_M.
Context size
Context size is the number of tokens that LLM remembers from previous messages to generate a response. It's usually measured in tokens.
In ollama it's usually set to 2048 tokens, which is around 1200 words or 6 kilobytes of text. With larger sizes, more memory is required to store the context. Also, the models have a context size limit (ex. 16k tokens for Phi-4, 128k for Gemma 3).
If the context size is too small, the LLM may forget what it was doing before. Take a look at this simplified example:
In order to generate a correct response, the entire prompt should fit into the context window:
We'll show how to check prompt length and set appropriate context size in Open WebUI a bit later on.
Model recommendations
[table that I accidentally deleted...]
Contrary to what companies in the field often say - AI isn't a silver bullet. It won't solve all most problems we face as privacy conscious people.
However when it comes to self-hosted models, there are some good use-cases even for privacy and anonymity. We already discussed how stylometry protection can be achieved with an LLM running locally.
Translation - LLMs provide high-quality, real-time translations, allowing for communication across languages without external data leaks.
Rewriting - They assist in paraphrasing content to protect against stylometry or improving the flow.
Solving Problems - LLMs can be used as personal assistants to answer every day questions and help with personal issues.
Programming Aid - Developers use them for code suggestions and debugging without exposing their sensitive codebases.
It's crucial to stress that AI can hallucinate (make stuff up). Thus it's never to be fully trusted with anything important. You should always check the information in reputable sources in case of any doubts.
To follow this tutorial, you'll need a system running Debian 12. Although ollama can work on CPU only, the performance will be much worse than having model that fits in GPU's VRAM.
To comfortably use an 8B model, it's strongly advised to have a dedicated GPU with at least 6GB of VRAM. You can check the supported GPU models here.
This tutorial showcases ollama setup with Nvidia drivers, but AMD GPUs are also supported.
If you want to expose Open WebUI via Tor to access it remotely, you should have an onion v3 vanity address and Tor installed.
It's also possible to set this up inside a Proxmox VE or any KVM based VM. You just need to PCI passthrough appropriate GPU inside the Hardware tab:
To install Docker, follow the official guide: Install Docker Engine on Debian. After installation, add your user to the docker group:
oxeo@andromeda:~$ /sbin/usermod -aG docker oxeo
oxeo@andromeda:~$ sudo systemctl enable docker
This ensures you can manage Docker without needing sudo privileges. Finally, reboot your system.
oxeo@andromeda:~$ sudo systemctl reboot
Update your package list to include "contrib non-free" at the end of every line in /etc/apt/sources.list:
deb http://deb.debian.org/debian/ bookworm main contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main contrib non-free
deb http://security.debian.org/debian-security bookworm-security main contrib non-free
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
Run:
oxeo@andromeda:~$ sudo apt update
oxeo@andromeda:~$ sudo apt install linux-headers nvidia-driver firmware-misc-nonfree
To verify installation, execute:
oxeo@andromeda:~$ docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
This command checks if the NVIDIA driver is accessible within Docker.
Create a docker-compose.yml file in ~/openwebui-stack with the following contents. This setup uses ollama for LLM management and open-webui as the user interface.
services:
ollama:
image: ollama/ollama
container_name: ollama
volumes:
- ollama:/root/.ollama
pull_policy: always
ports:
- 127.0.0.1:11434:11434
tty: true
restart: unless-stopped
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities:
- gpu
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
volumes:
- open-webui:/app/backend/data
depends_on:
- ollama
ports:
- 127.0.0.1:3000:8080 # Remove "127.0.0.1:" to access from LAN
environment:
- 'OLLAMA_BASE_URL=http://ollama:11434'
- 'WEBUI_SECRET_KEY='
extra_hosts:
- host.docker.internal:host-gateway
restart: unless-stopped
volumes:
ollama: {}
open-webui: {}
To start the stack:
oxeo@andromeda:~$ cd ~/openwebui-stack
oxeo@andromeda:~$ docker compose up -d
To expose open-webui via Tor, edit your torrc file:
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:3000
Restart Tor and check the generated hostname:
sudo systemctl restart tor
cat /var/lib/tor/hidden_service/hostname
If you encounter issues with hardware acceleration on ollama, check:
In this tutorial, you've set up a private LLM experience using ollama and open-webui. By exposing it via Tor, your interactions remain anonymous and secure. While consumer-grade hardware may offer less computational power than corporate setups, you retain full control over your data and privacy.
Donate XMR: 8AUYjhQeG3D5aodJDtqG499N5jXXM71gYKD8LgSsFB9BUV1o7muLv3DXHoydRTK4SZaaUBq4EAUqpZHLrX2VZLH71Jrd9k8
Donate XMR to the author: 862Sp3N5Y8NByFmPVLTPrJYzwdiiVxkhQgAdt65mpYKJLdVDHyYQ8swLgnVr8D3jKphDUcWUCVK1vZv9u8cvtRJCUBFb8MQ
Contact: nihilist@contact.nowhere.moe (PGP)
