⚡ HomelabVergleich

LLM-Server-Software im Vergleich: Ollama, llama.cpp, vLLM und LM Studio für GPU-Selbsthoster

Du hast ein GPU-Server oder einen PCs mit einer brauchbaren Grafikkarte, und du möchtest ein offenes Sprachmodell nicht nur herunterladen, sondern tatsächlich ansprechen — als API, als Web-Oberfläche, als Dienst, den mehrere Personen oder Anwendungen parallel nutzen können. Dann brauchst du nicht nur ein Modell, sondern Software, die das Modell rundum betreibt: Läd es, beantwortet Anfragen, puffert Warteschlangen, spricht eine Schnittstelle an, und verbraucht nicht die ganze GPU, während niemand fragt.

Das ist der Unterschied zwischen Modell-Download und LLM-Server: Ein Modell als GGUF- oder Safetensors-Datei ist nur das Gewicht. Ein LLM-Server ist das HALROUND-Programm, das das Gewicht lädt, Token generiert, Anfragen serialisiert oder parallelisiert, eine Schnittstelle (HTTP, gRPC, stdio) anbietet, und oft auch eine Eingabe- und Ausgaberegelung mitbringt. Ohne Server läufst du mit einem Modell in die Luft, das du nur über Python-Scripte oder CLI-Tools von Hand jagt — das funktioniert für ein einmaliges Experiment, nicht für einen Dauer-Server.

Welche Betriebssysteme spielen eine Rolle

Die meisten LLM-Server-Software läuft auf Linux und Windows. macOS kommt als Entwicklerplattform infrage, ist aber für GPU-Server-Themen weniger relevant (Metal-Unterstützung für kleinere Modelle existiert, ist aber kein Homelab-Standard).

Faustregel: Wenn der Server dauerhaft laufen soll, auf dem ein GPU-Infrastruktur läuft, ist Linux der Standard-CL. Wenn du Windows als Host nutzt und eine GPU dauerhaft zum Server gehören soll, ist Ollama die glatteste Einzel-Software (Windows-Service bringt), und vLLM mit WSL2/Docker ist möglich, aber komplexer.

Vergleichstabelle

Die folgende Tabelle vergleicht die vier Software-Optionen nach Kriterien, die für Homelab- und kleine-Firmen-Betrachtungen relevant sind: Bedienoberfläche, Betriebssystem, GPU- und CPU-Betrieb, GGUF-Unterstützung, llama.cpp-Kompatibilität, parallele Anfragen und Warteschlange, Open-WebUI-Einbindung, Leerlauf-Verbrauch.

| Kriterium | Ollama | llama.cpp server | vLLM | LM Studio |

|---|---|---|---|---|

| Bedienoberfläche | CLI (ollama run, ollama list, ollama ps) + optional eigene Weboberfläche über Drittsoftware; keine eingebaute Web-Oberfläche | CLI-basiert (HTTP-API auf Port 8080); kein native GUI, keine Weboberfläche | CLI (vllm serve ...); kein native GUI; reine Server-Software | Eigene grafische Desktop-Oberfläche (Downloads, Chat, Modellverwaltung) |

| Betriebssystem | Linux, Windows, macOS (Apple Silicon) | Linux, Windows, macOS (plattformübergreifend, compiliert) | Linux (prime), Windows möglich über WSL2/Docker mit Einschränkungen | macOS, Windows (Desktop-App; keine Server-Widerleinung) |

| GPU-Betrieb | NVIDIA CUDA, ROCm (experimentell auf Linux), Metal (macOS) | CUDA, ROCm, Metal, DirectML (Windows), SVD-Varianten; flexibel über Build-Optionen und Backend-Selection | NVIDIA GPU primär (CUDA), MPI für Multi-GPU; ROCm ersichtlich in der Doku, weniger ausgereift als CUDA | GPU-Beschleunigung über Metal (macOS) / CUDA (Windows bei NVIDIA); keine ROCm-Option nennenswert |

| CPU-Betrieb | CPU-Inference möglich (langsam, für kleine Modelle oder Tests) | CPU-Inference (ggml-Backend, oft langsamer als CUDA, aber existiert) | CPU-Support inaktuell / nicht primär (fokussiert auf GPU) | CPU-Modus möglich, aber GPU bevorzugt |

| GGUF-Unterstützung | Native GGUF (Ollama-Modellformate basieren auf GGUF; ollama pull lädt GGUF-basierte Modelle) | Native GGUF (GGML/gguf als Kernformat; ./server dient GGUF-Dateien direkt) | Keine native GGUF-Unterstützung (fokussiert auf PyTorch/Safetensors-Checkpoint-Formate; GGUF-Konvertierung möglich, aber nicht der Standardweg); für GGUF-Nutzer sonst Ollama oder llama.cpp | Native GGUF (LM Studio lädt GGUF-Modelle, Verwaltung im UI) |

| Kompatibilität mit llama.cpp-basierten Servern | Ollama ist nicht auf llama.cpp aufgebaut (eigenes Backend), aber GGUF-format-kompatibel; Modellformate teilweise austauschbar (mit Konvertierung, nicht 1:1) | llama.cpp server ist der llama.cpp-basierte Server | Kein direktes llama.cpp-basiertes System; eigene Tensor-Parallelismus- und Scheduling-Implementierung | LM Studio nutzt llama.cpp-basiertes Backend intern (Desktop-App, nicht direkt als Server für externe Anfragen konzipiert, aber basiert auf llama.cpp-Code) |

| Parallele Anfragen / Warteschlange | Einfache Serialisierung (eine Anfrage nach der anderen im Standard; ollama serve hat keine ausgeprägte Warteschlangen-Konfiguration; parallele Anfragen möglich, aber GPU-Ressourcen teilen sich die Anfragen — kein explizites Queue-Management) | HTTP-API mit paralleler Anfrage-Akzeptanz; kein integriertes Queue-Management (Client-Seite oder externe Warteschlange nötig für Kontrolle); batch für Batch-Verarbeitung vorhanden | Explizites Scheduling, parallele Anfragen mit PagedAttention-Memory-Management; Multi-Gateway-unterstützung; Skalierung auf mehrere Anfragen gleichzeitig mit GPU-Parallelismus | Kein paralleler Server-Modus (Desktop-App; Einzelanfrage-Oberfläche) |

| Einbindung in Open WebUI | Direkte Kompatibilität: Open WebUI kann als "Ollama"-Anbieter konfiguriert werden (Host + Port, meist 11434); Open WebUI spricht die Ollama-API | Open WebUI kann einen Custom-API-Endpunkt konfigurieren, aber native llama.cpp-Integration weniger direkt als Ollama; erfordert ggf. Adapter oder Proxy | Keine native Open WebUI-Integration (Open WebUI erwartet eine OpenAI-kompatible oder Ollama-API; vLLM kann OpenAI-kompatible API ausliefern mit Konfiguration, aber nicht 1:1 eingebunden wie Ollama) | Kein Server-Modus; LM Studio als API-Server umbaubar über eigene Konfiguration (LM Studio hat einen lokalen API-Modus, aber weniger standardisiert als Ollama für Open WebUI) |

| Ressourcenverbrauch im Leerlauf | Ollama-Daemon läuft als Hintergrundprozess; verbraucht RAM für geladene Modelle (Modelle bleiben geladen, wenn sie im Speicher sind, sonst Laufzeit-Laden); GPU-Ressourcen abhängig von geladenem Modell; ohne Anfrage relativ ruhig | Server-Prozess läuft; ähnliches Laden von Modellen in RAM/VRAM; ohne Anfrage idle, aber Prozess vorhanden | vLLM-Prozess läuft, hält GPU-Speicher für den Modell-Checkpoint und Scheduling-Strukturen; ohne Anfrage idle, aber GPU-Speicher gebunden | LM Studio als Desktop-App verbraucht RAM/VRAM bei geladenem Modell; ohne Anfrage idle als App, aber nicht als Daemon |

Kurz gesagt: Wenn du eine einfache, gut dokumentierte Einsteigerlösung suchst, die eine API anbietet, die Open WebUI direkt versteht, und die auf Linux und Windows läuft — ist das Ollama. Wenn du YYUF-Modelle direkt, plattformnah, ohne Zwischenschicht von Ollama willst und bereit bist, selbst die HTTP-API-Konfiguration zu machen — ist llama.cpp der Weg. Wenn du größere Deployment-Produktion mit GPU-Parallelismus und Scheduling brauchst — ist vLLM der Kandidat. Wenn du eine Desktop-Oberfläche zum Ausprobieren und Chatten willst — ist LM Studio die Wahl.

Ollama

Was es ist: Ein Einzel-Dienst, der ein Modell (meist als GGUF-basiertes Ollama-Modellformat) lädt, eine lokale HTTP-API auf Port 11434 anbietet, und CLI-Tools zum Interagieren mitbringt (ollama run, ollama list, ollama ps, ollama pull, ollama stop). Es ist nicht auf llama.cpp aufgebaut, aber spricht GGUF-kompatible Modelle an und ist kompatibel mit Clients, die eine Ollama-API erwarten.

Stärken:

Schwächen:

llama.cpp server

Was es ist: Ein aus fpm dem llama.cpp-Projekt stammender Serve-Modus (./server), der eine HTTP-API auf einem konfigurierbaren Port (Standard 8080) anbietet und GGUF-Modelle direkt anspricht. Es ist plattformübergreifend, compiliert aus dem Source, und bringt keine eingebaute Weboberfläche mit.

Stärken:

Schwächen:

vLLM

Was es ist: Eine Produktions-gerichtete LLM-Server-Software von B형 (vLLM-Projekt), die auf GPU-Parallelismus, PagedAttention für effiziente Memory-Verwaltung, und Scheduling von parallelen Anfragen fokussiert ist. Sie spricht PyTorch/Safetensors-Checkpoint-Formate direkt an, nicht primär GGUF. Für große Modelle auf Multi-GPU-Setups ist sie konzipiert.

Stärken:

Schwächen:

LM Studio

Was es ist: Eine Desktop-App (Windows/macOS) mit eigener grafischer Oberfläche zum Herunterladen, Verwalten und Chatten mit lokalen GGUF-Modellen. Intern basiert LM Studio auf llama.cpp-Code, aber als Desktop-Produkt, nicht als Server-Software für externe Anfragen.

Stärken:

Schwächen:

GGUF-Dateien und Q-Stufen: was ist sinnvoll

GGUF (GPT-Generated Unified Format) ist ein Modellformat, das von llama.cpp stammt und Weight-Quantisierung in verschiedenen Q-Stufen (Quantisierungsqualität) unterstützt. Q-Stufe bestimmt, wie viele Bit pro Gewicht verwendet werden — weniger Bit = weniger VRAM/Bedarf und oft kleinere Dateigröße, aber potenziell geringere Qualität. Die Wahl der Q-Stufe ist eine Kompromisspraktik: VRAM-Budget gegen Qualität.

Wichtige Q-Stufen (gängig bei GGUF-Modellen):

Keine Benchmarks erfinden: Die hier genannten VRAM-Werte sind grobe Orientierungshilfen nach Modellgröße und Q-Stufe, keine gemessenen Benchmarks. Die tatsächliche VRAM-Nutzung hängt von Kontext-Länge, GPU-Runtime, und 세부-Parametern ab. Eine grobe Orientierung:

Faustregel ohne Benchmarks: Für Homelab-Setups mit einer Consumer-GPU (8–12 GB VRAM) sind 7B-Modelle mit Q4_K_M oder Q5_K_M der Normalfall. Für 16–24 GB VRAM kommen 13B-Modelle mit Q4_K_M in Frage, 30B-Modelle mit Q4_K_M bei ausreichender VRAM (und ggf. GPU-Offload-Konfiguration). Bei sehr knappem VRAM (unter 8 GB) sind IQ4_XS oder kleinere Q-Stufen einzusetzen, aber Qualitätseinschränkungen sind real.

Praktischer Hinweis: Eine GGUF-Datei laden und als Benchmark bezeichnen ist nicht dasselbe wie die Server-Software konfigurieren — die Server-Software (Ollama, llama.cpp server, LM Studio) muss mit der Q-Stufe, der Kontext-Länge und der GPU-Layers-Konfiguration harmonieren. Kontext-Länge (z.B. 4096, 8192, 16384 Token) erhöht den VRAM-Verbrauch während der Inferenz (KV-Cache), unabhängig von der Q-Stufe des Modells — das ist ein separater VRAM-Faktor.

Anleitung: Reines Ollama mit API-Zugriff

Dieser Weg richtet Ollama als lokalen Dienst ein, der eine API auf Port 11434 anbietet. Eine Oberfläche (z.B. Open WebUI) oder ein Client spricht die API an. Für Einbenutzer-Setup oder einfache API-Nutzung ist das der direkte Weg.

Voraussetzungen:

Schritt 1: Ollama installieren (Linux-Beispiel)


curl -fsSL https://ollama.com/install.sh | sh

Danach startet Ollama als systemd-Dienst automatisch (oder lässt sich mit systemctl start ollama starten; systemctl enable ollama für Autostart).

Schritt 2: Erster Modell-Check


ollama list

Ohne vorheriges ollama pull ist die Liste leer. Ein Modell herunterladen:


ollama pull <modellname>

Beispielsweise ein 7B-Modell aus dem Ollama-Registry (Modellname je nach verfügbarer Liste; ollama list und die Ollama-Dokumentation zeigen verfügbare Modelle).

Schritt 3: Modell starten und testen


ollama run <modellname>

Das bringt eine interaktive CLI. Zum Beenden /bye oder Strg+D. Danach läuft das Modell im Hintergrund (Ollama hält es geladen, wenn es nicht explizit gestoppt wird).

Schritt 4: API-Zugriff prüfen

Ollama spricht standardmäßig auf http://localhost:11434. Eine einfache Test-Anfrage (z.B. mit curl):


curl http://localhost:11434/api/generate -d '{"model": "<modellname>", "prompt": "Hallo, kurze Antwort bitte.", "stream": false}'

Die Antwort ist JSON mit dem generierten Text. Für streaming-Anfragen setzt man stream: true und verarbeitet die Chunk-Antworten.

Schritt 5: Open WebUI einbinden (optional)

Wenn du Open WebUI (ein separates Stück Software, z.B. über Docker oder direkt) nutzt, konfiguriere Open WebUI mit dem Ollama-Host (standardmäßig http://localhost:11434 oder die IP des Ollama-Servers, wenn Open WebUI auf einem anderen Host läuft). Open WebUI spricht die Ollama-API direkt an.

Hinweis VRAM: Das geladene Modell verbraucht VRAM, solange es im Speicher ist. Wenn mehrere Modelle zwischengespeichert sind, summieren sich die VRAM-Ansprüche. ollama stop <modellname> entlädt das Modell aus dem Speicher (ggf. VRAM freigeben). Für Systeme mit knappem VRAM ist das ein Faktor: zwischen Modellen wechseln bedeutet Laden/Unladen, was Zeit kostet.

Anleitung: Mehrbenutzer-Server mit Open WebUI

Dieser Weg kombiniert einen LLM-Server (z.B. Ollama oder llama.cpp server) mit einer Web-Oberfläche (Open WebUI), die mehrere Benutzer oder mehrere Anwendungen bedient. Open WebUI ist eine separate Weboberfläche, die eine LLM-API (Ollama-API oder Custom-API) als Backend spricht.

Voraussetzungen:

Schritt 1: LLM-Server vorbereiten

Richte Ollama (wie oben) oder llama.cpp server ein. Für Ollama:


# Ollama-Dienst läuft (systemd auf Linux)
systemctl status ollama

Für llama.cpp server (nach Kompilierung oder Binary-Besorgung):


./server -m <pfad/zur/gguf-datei> -c <kontextlaenge> --port 8080

(Der Port ist konfigurierbar; der Standard ist 8080.)

Schritt 2: Open WebUI installieren (Docker-Beispiel)

Open WebUI wird oft über Docker bereitgestellt. Ein Beispiel für Docker auf Linux:


docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Der OLLAMA_BASE_URL zeigt Open WebUI auf den Ollama-Server (hier host.docker.internal, weil Open WebUI in Docker läuft und Ollama auf dem Host). Für llama.cpp server als Backend müsste die URL entsprechend angepasst werden (Custom-API-Konfiguration in Open WebUI).

Schritt 3: Open WebUI initialisieren

Nach dem Start von Open WebUI (Docker-Container, Webinterface auf Port 3000) öffnet sich die Weboberfläche (http://localhost:3000 oder die IP des Servers). Die erste Nutzung erfordert oft eine Initialisierung (Admin-Konto, Konfiguration). Open WebUI verbindet sich mit dem konfigurierten LLM-Server und zeigt Modelle an, die dort verfügbar sind.

Schritt 4: Mehrbenutzer-Konfiguration (optional)

Open WebUI unterstützt mehrere Nutzer (Benutzerkonten, Chat-Isolation). Für ein Homelab- oder Firmen-Setup mit mehreren Personen, die den Server nutzen, sind Benutzerkonten in Open WebUI die isolierende Schicht — nicht der LLM-Server selbst (Ollama oder llama.cpp server haben keine Benutzer-Isolation; die Isolation liegt in der Open WebUI-Schicht).

Schritt 5: VRAM-Hinweis für Mehrbenutzer

Der LLM-Server (Ollama/llama.cpp server) lädt das Modell undhält es im VRAM. Parallele Anfragen aus mehreren Nutzern (über Open WebUI) teilen sich die GPU-Ressourcen des Servers — ohne explizites Queue-Management (bei Ollama und llama.cpp server) ggf. zu Wartezeiten bei hoher Last. Für mehrere gleichzeitige Nutzer auf einem Single-GPU-Setup ist das ein praktischer Faktor: Entweder die GPU ist groß genug für mehrere parallele Inferenzen, oder die Nutzer akzeptieren Warteschlangen-Verzögerungen.

Hinweis zu llama.cpp server als Backend für Open WebUI:

Open WebUI konfiguriert primär Ollama als Backend; eine Custom-API-Konfiguration für llama.cpp server ist möglich, aber weniger standardisiert. In der Open WebUI-Konfiguration gibt es einen Custom-API-Endpunkt, der auf die llama.cpp server-HTTP-API (Port 8080) zeigen kann; die Antwortformate müssen kompatibel sein (Open WebUI erwartet bestimmte API-Formate; bei Nicht-Kompatibilität funktioniert die Einbindung nicht direkt ohne Anpassung).

Häufige Fehler

1. Port 11434 (Ollama) oder Port 8080 (llama.cpp server) ins Internet freigeben

Ein häufiger Fehler: die Firewall so konfigurieren, dass der Ollama-Port (11434) oder der llama.cpp-server-Port (8080) von außen erreichbar ist — ohne Authentifizierung, ohne Access-Control. Beide Ports haben keine eingebaute Authentifizierung im Standard (Ollama: kein Passwort im Standard-Modus; llama.cpp server: keine Authentifizierung im Standard). Wer also den Port ins Internet gibt, exponiert die API ohne Schutz. Korrekt: Port nicht ins Internet geben, oder nur über einen Reverse-Proxy mit Authentifizierung (Basic Auth, OAuth, etc.) und TLS zugreifen. Für Homelab-Server, die nur lokal genutzt werden, bleibt der Port auf localhost oder im lokalen Netzwerk.

2. Ollama ohne Authentifizierung betreiben

Ollama im Standard-Modus hat keine eingebaute Authentifizierung. Auf einem Server, der von mehreren Nutzern genutzt wird, oder der über das Netzwerk erreichbar ist, bedeutet das: jeder, der den Port erreicht, spricht die API an. Für einen Single-User-Laptop ist das kein Problem; für einen Server im Netzwerk ist das ein Risiko. Korrekt: Entweder den Server auf localhost halten, oder einen Reverse-Proxy mit Authentifizierung davor setzen, oder das Netzwerk so gestalten, dass nur vertrauenswürdige Hosts zugreifen können (VLAN, Firewall-Regeln).

3. Modellwechsel zur Laufzeit ohne berücksichtigen von VRAM

Ein Modell laden, ein anderes Modell laden, ohne das erste zu entladen: beide Modelle können teilweise im VRAM verbleiben (je nach Server-Implementierung und Speicherverwaltung), was VRAM-Ansprüche summieren lässt. Korrekt: Modell explizit entladen, bevor das nächste geladen wird (Ollama: ollama stop <modellname>; llama.cpp server: Server-Neustart oder Konfiguration, die das Modell entlädt; bei vLLM: Modell-Loading/Unloading über API-Konfiguration).

4. Docker-Container ohne GPU-Durchreichen

Wenn Ollama, llama.cpp server oder vLLM in Docker läuft (z.B. für Open WebUI-Zwecke oder für isolierte Umgebungen), muss die GPU an den Container durchgereicht werden. Ohne GPU-Passthrough läuft der Server ohne GPU-Beschleunigung (CPU-Inferenz oder Fehler, je nach Software). Korrekt: Docker-GPU-Passthrough konfigurieren (NVIDIA: docker run --gpus all ..., oder nvidia-container-toolkit installieren; AMD ROCm: entsprechende Docker-Flags; WSL2 auf Windows: GPU-Passthrough in die WSL2-Umgebung). Ohne das läuft der Container ohne GPU.

5. Server läuft, aber die Härte fehlt (fail2ban, Authentifizierung, Zugriffskontrolle)

Ein LLM-Server, der im lokalen Netzwerk läuft und keine Authentifizierung hat, ist für das lokale vertrauenswürdige Netzwerk akzeptabel. Sobald der Server von mehreren Nutzern bedient wird, oder über ein Netzwerk mit unsicheren Hosts erreichbar ist, fehlt die Härte. Korrekt: Authentifizierungsschicht (Reverse-Proxy mit Basic Auth, OAuth, oder eingebaute Authentifizierungsschicht der Software, wenn vorhanden), Firewall-Regeln (nur bestimmte IPs), und ggf. fail2ban für Brute-Force-Schutz auf einem Reverse-Proxy oder Server (wenn der Server extern erreichbar ist). Für reine Homelab-Setups auf localhost oder isoliertem Netzwerk ist das weniger kritisch.

FAQ

F1: Brauche ich einen LLM-Server, wenn ich nur ein Modell heruntergeladen habe?

Nein, nicht zwingend. Ein Modell als Datei kann mit CLI-Tools oder Python-Skripten angesprochen werden. Aber für wiederkehrende Nutzung, API-Zugriff, Web-Oberfläche oder parallele Anfragen ist ein Server die praktische Wahl. Ein Modell ohne Server ist ein Datei, kein Dienst.

F2: Welche Software soll ich nehmen, wenn ich Open WebUI nutzen will?

Open WebUI ist primär für die Ollama-API konzipiert. Wenn du Open WebUI als Oberfläche willst, ist Ollama der direkte Weg (native Kompatibilität). Llama.cpp server ist mit einer Custom-API-Konfiguration möglich, aber weniger direkt. vLLM kann eine OpenAI-kompatible API liefern, ist aber nicht die 1:1-Integration wie Ollama für Open WebUI.

F3: Läuft Ollama auf AMD-GPUs?

Ollama unterstützt ROCm auf Linux (experimentell, je nach Version und GPU); auf Windows mit AMD-GPU ist die Unterstützung weniger direkt (kein CUDA, ROCm auf Windows nicht der Standardpfad). Für AMD-Selfhoster auf Linux ist Ollama mit ROCm ein Weg; für Windows-Nutzer mit AMD-GPU sind llama.cpp mit DirectML oder ROCm-Konfiguration (je nach Setup) Alternativen.

F4: Was ist der Unterschied zwischen Ollama und llama.cpp server

Ollama ist ein Dienst mit eigener Modellverwaltung, Registry, und einer API, die Open WebUI direkt versteht. Llama.cpp server ist ein Server-Modus aus dem llama.cpp-Projekt, der GGUF-Modelle direkt anspricht und eine HTTP-API anbietet, aber keine eingebaute Modell-Registry oder Weboberfläche mitbringt. Beide dienen GGUF-kompatible Modelle, aber mit unterschiedlichen Ökosystemen.

F5: Welche Q-Stufe soll ich für ein 7B-Modell auf einer GPU mit 8 GB VRAM nehmen?

Ohne Benchmarks pauschal: Q4_K_M oder IQ4_XS sind gängige Wahl für 7B auf 8 GB VRAM. Q5_K_M ist möglich, wenn VRAM es zulässt (Kontext-Länge und GPU-Runtime beeinflussen den tatsächlichen Bedarf). Q8_0 ist für 8 GB VRAM bei einem 7B-Modell oft anspruchsvoll (je nach Kontext-Länge). Eine konkrete Entscheidung erfordert Wissen über die genaue VRAM-Situation, Kontext-Länge, und Modellgröße — keine pauschale Empfehlung ohne diese Faktoren.

F6: Kann ich vLLM und Ollama gleichzeitig auf demselben Server laufen lassen?

Ja, technisch möglich, wenn sie verschiedene Ports nutzen und nicht um dieselbe GPU konkurrieren (GPU-Ressourcen-Sharing zwischen zwei Server-Software ist möglich, aber begrenzt — beide wollen GPU-Zeit). Für praktische Setups ist es üblicher, einen Server-Software-Stack zu wählen, nicht zwei parallel für dieselbe GPU, es sei denn, es gibt eine klare Architekturbedarf (z.B. verschiedene Modelle für verschiedene Anfragen). GPU-Konkurrenz zu berücksichtigen.

Kurzfassung in 5 Punkten

1. Ein LLM-Server ist die Software, die ein Modell als Dienst betreibt — API, Warteschlangen, Schnittstelle — nicht nur die Modelldatei selbst. Für wiederkehrende Nutzung, Web-Oberfläche oder parallele Anfragen ist ein Server die praktische Wahl.

2. Die drei Hauptkandidaten für Homelab- und kleine-Firmen-Betrachtungen sind Ollama (einfach, API-kompatibel mit Open WebUI, Windows-Service), llama.cpp server (direkte GGUF-Unterstützung, plattformübergreifend, ohne Weboberfläche), und vLLM (GPU-Parallelismus, Produktionsprofil, keine native GGUF-Unterstützung). LM Studio ist eine Desktop-App zum Ausprobieren, nicht ein Server-Produkt.

3. GGUF-Q-Stufen bestimmen VRAM-Budget gegen Qualität. Für 7B-Modelle auf Consumer-GPUs (8–12 GB VRAM) sind Q4_K_M oder IQ4_XS der Normalfall; für größere Modelle (13B, 30B, 70B) steigt der VRAM-Bedarf und Multi-GPU oder CPU-Offload werden nötig. Keine Benchmarks erfinden — die Werte sind grobe Orientierungshilfen.

4. Häufige Fehler: Port ins Internet geben ohne Authentifizierung, Ollama ohne Authentifizierung auf dem Netzwerk, Modellwechsel ohne VRAM-Berücksichtigung, Docker ohne GPU-Durchreichen, Server ohne Härte (fail2ban, Authentifizierung, Firewall). Für lokale Homelab-Setups auf localhost oder isoliertem Netzwerk ist das weniger kritisch.

5. Für Open WebUI als Oberfläche ist Ollama der direkteste Weg (native API-Kompatibilität). Für reine API-Nutzung ohne Weboberfläche ist Ollama oder llama.cpp server je nach Vorliebe (Registry vs. direkte GGUF-Kontrolle). Für Produktions-Profiling mit GPU-Parallelismus ist vLLM der Kandidat.

Bildvorschläge

Bild 1

Bild 2

Bild 3

Bild 4

Bild 5

Interne Verlinkungsvorschläge auf vorhandene BsN-Artikel (homelab.brillianze.de/artikel/<slug>/):

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.