Ollama Multi-Modell-Parallelbetrieb: Qwen, Llama und DeepSeek in der Praxis

Seit Ollama 0.2 können mehrere Modelle gleichzeitig laufen. Kein ständiges Wechseln mehr zwischen ollama run deepseek-coder für Code und ollama run qwen2.5 für Übersetzungen – jedes Mal neu laden und zehn-plus Sekunden warten. Ein Dienst, drei Modelle on demand: DeepSeek für Code, Qwen für Chinesisch, Llama für allgemeine Fragen.

Drei Umgebungsvariablen aktivieren paralleles Laden: OLLAMA_MAX_LOADED_MODELS steuert, wie viele Modelle gleichzeitig geladen bleiben, OLLAMA_NUM_PARALLEL die Parallelität pro Modell und OLLAMA_KEEP_ALIVE die Standby-Zeit. Dieser Artikel erklärt die Konfiguration, die Stärken der drei Modelle und Speicherverwaltung – häufig genutzte Modelle vorladen, seltene bei Bedarf laden, bei VRAM-Mangel auf System-RAM ausweichen.

Grundlagen der Ollama-Multi-Modell-Parallelität

Zuerst die gute Nachricht: Seit Ollama 0.2 ist paralleler Multi-Modell-Betrieb nativ unterstützt. Keine Extra-Plugins, keine komplexen Konfigurationsdateien – ein paar Umgebungsvariablen genügen, damit mehrere Modelle bereitstehen.

Die schlechte Nachricht: Reicht der Grafikspeicher (VRAM) nicht aus, können die Modelle den System-RAM vollständig belegen – und Ihr Rechner wird zur Schnecke.

Drei zentrale Umgebungsvariablen

Öffnen Sie ein Terminal und setzen Sie diese drei Variablen:

# Maximal gleichzeitig geladene Modelle
export OLLAMA_MAX_LOADED_MODELS=3

# Maximal parallele Anfragen pro Modell
export OLLAMA_NUM_PARALLEL=2

# Maximale Warteschlangenlänge (danach werden neue Anfragen abgelehnt)
export OLLAMA_MAX_QUEUE=512

OLLAMA_MAX_LOADED_MODELS ist der Kern. Auf 3 gesetzt, laufen Qwen, Llama und DeepSeek parallel. Aber nicht zu großzügig wählen – der Wert hängt von Ihrer Hardware ab. Speicherbedarf erläutere ich weiter unten.

OLLAMA_NUM_PARALLEL steuert die Parallelität pro Modell. Bei gleichzeitigen Anfragen kann der Wert höher sein – für den Privatgebrauch reicht meist der Standard.

Systemdienst-Konfiguration (Linux)

Unter systemd (Standard auf den meisten Linux-Distributionen) geht die Konfiguration so:

sudo systemctl edit ollama.service

Im Editor ergänzen:

[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_KEEP_ALIVE=30m"

Speichern, beenden, Dienst neu starten:

sudo systemctl restart ollama

OLLAMA_KEEP_ALIVE steuert, wie lange ein Modell im Speicher bleibt. Bei 30m bleibt es nach dem Laden 30 Minuten geladen – der nächste Aufruf entfällt ohne erneutes Laden. Mit -1 bleibt es unbegrenzt, bis Sie es manuell entladen.

Reicht der Speicher? Eine grobe Faustregel

Konfiguration steht – aber reicht der Speicher?

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Grobe Schätzung: Ein 7B-Modell benötigt etwa 4–5 GB VRAM (FP16-Quantisierung), ein 14B-Modell 8–10 GB. Drei 7B-Modelle gleichzeitig erfordern mindestens 16 GB VRAM.

Meine RTX 3060 mit 12 GB VRAM läuft mit zwei 7B-Modellen flüssig; das dritte nutzt System-RAM – die Geschwindigkeit bricht spürbar ein. Auf dem Mac (Apple Silicon) teilen sich System- und GPU-Speicher; mit 32 GB Unified Memory sind drei Modelle kein Problem.

Die drei Modelle im Vergleich und Auswahlstrategie

Konfiguration erledigt – welches Modell wofür? Am Anfang war ich unsicher: alle drei heruntergeladen, aber bei jedem Aufruf die falsche Wahl. Nach etwas Erfahrung habe ich eine klare Regel gefunden.

Qwen: Stark bei Chinesisch und Mehrsprachigkeit

Als Open-Source-Serie von Alibaba überzeugt Qwen besonders bei Chinesisch. Damit habe ich viele chinesische Dokumente geschrieben und technische Artikel übersetzt – die Ergebnisse sind überzeugend. Laut Hersteller unterstützt Qwen über 100 Sprachen – nicht nur Chinesisch und Englisch, sondern auch Japanisch, Koreanisch, Französisch, Spanisch und mehr.

Für chinesische Inhalte oder mehrsprachige Übersetzungen ist Qwen die erste Wahl. Mit qwen2.5:7b habe ich ein 5.000-Wörter-Technikdokument übersetzt – die Qualität übertrifft viele Online-Tools. Bei Fachbegriffen übersetzt es korrekt: „API endpoint” wird nicht zu „API-Endpunkt” im falschen Sinne verhunzt.

Llama: Ausgewogene Allround-Fähigkeiten

Metas Llama-Serie ist der etablierte Standard unter Open-Source-Modellen. Bei unklarem Aufgabentyp: Llama wählen – meist die richtige Entscheidung.

Ein großer Vorteil: die Lizenz ist großzügig. Bis 7 Millionen monatliche Nutzer ist kommerzielle Nutzung kostenlos – wichtig für Indie-Entwickler und kleine Teams.

Außerdem: großes Kontextfenster. Llama 3.2 unterstützt bis zu 128K Tokens – genug für ein ganzes Buch. Bei sehr langen Dokumenten ist das ein klarer Pluspunkt.

DeepSeek: Stark bei Code und Reasoning

DeepSeek nutze ich erst seit Kurzem, bin aber schnell überzeugt. Bei Code-Aufgaben überrascht es positiv – hohe Codequalität und erklärende Ausgaben.

Laut Premai-Vergleich liegen die Inferenzkosten von DeepSeek etwa 95 % unter vergleichbaren Modellen. Auf begrenzter Hardware bedeutet das: mehr Aufgaben in derselben Zeit.

Auswahl auf einen Blick

Meine Gewohnheit: Code mit DeepSeek, chinesische Dokumente mit Qwen, englische oder unklare Aufgaben mit Llama. Klare Rollenverteilung – selten noch Zögern.

Modellwechsel und Speicherverwaltung

Am Anfang war der langsame Wechsel mein größtes Problem. Jeder Modellwechsel kostete Zeit – neu laden, Lüfter hochdrehen, warten. Später zeigte sich: Die Verzögerung lässt sich optimieren.

Woher kommt die Wechselverzögerung?

Typisch 10 bis 30 Sekunden – abhängig von Modellgröße, Festplattengeschwindigkeit und Speicherstatus. Ein 7B-Modell braucht vom Disk zum GPU etwa 10–15 Sekunden; 14B eher 20–30 Sekunden.

Im Alltag nervt das. Beim Debuggen: DeepSeek generiert eine Funktion, Qwen soll Kommentare übersetzen – und Sie warten.

keep_alive: Modelle bereithalten

Die Lösung ist OLLAMA_KEEP_ALIVE.

Prinzip: Einmal geladen, bleibt das Modell im Speicher. Beim nächsten Aufruf sofort verfügbar – kein erneutes Laden.

Global setzen:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

export OLLAMA_KEEP_ALIVE=30m  # 30 Minuten im Speicher halten
# oder
export OLLAMA_KEEP_ALIVE=-1   # Unbegrenzt, bis manuell entladen

Pro Anfrage überschreiben:

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "prompt": "", "keep_alive": "60m"}'

Eine leere Anfrage (prompt leer) lädt das Modell und hält es im Speicher. Gute Methode zum Vorladen – häufig genutzte Modelle im Voraus bereitstellen, danach sofortige Antworten.

Modelle manuell entladen

Bei knappem Speicher können Sie ein Modell gezielt entladen:

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "keep_alive": 0}'

Mit keep_alive: 0 wird das Modell sofort aus dem Speicher entfernt. Die Modell-Datei auf der Festplatte bleibt erhalten – nur der belegte RAM/VRAM wird freigegeben.

Speicherbedarf nach Modellgröße

Referenzwerte aus Community-Feedback und eigenen Tests:

Meine RTX 3060 mit 12 GB VRAM: Mit Q4-Quantisierung ein 14B- plus ein 7B-Modell parallel, oder drei 7B-Modelle. Das dritte nutzt System-RAM – langsamer, aber stabil.

Reicht VRAM nicht, System-RAM aber groß (32 GB+), geht auch CPU-Inferenz. Deutlich langsamer, aber funktionsfähig. Manchmal reicht das.

Tipp: Häufig genutzte Modelle zuerst laden

Meine Gewohnheit: Das meistgenutzte Modell dauerhaft auf der GPU, seltene bei Bedarf – ggf. über System-RAM.

In meinem Workflow ist DeepSeek am häufigsten – bleibt auf der GPU. Qwen und Llama lade ich bei Bedarf, oft über System-RAM.

So sind häufige Aufgaben schnell, seltene etwas langsamer – insgesamt die bessere Erfahrung. Passen Sie die Reihenfolge an Ihre Gewohnheiten an.

Praxis-Szenarien

Genug Theorie – wie sieht das im Alltag aus? Drei Szenarien, die ich regelmäßig nutze.

Coding-Assistent: Code + Dokumentation

Mein häufigstes Setup – zwei Modelle im Wechsel:

• DeepSeek: Code-Logik, Erklärungen, Bugfixes
• Qwen: Kommentare übersetzen, chinesische Dokumentation

Beispiel: Beim Schreiben einer API zuerst DeepSeek für das Code-Gerüst:

curl http://localhost:11434/api/generate \
  -d '{"model": "deepseek-coder:6.7b", "prompt": "Schreibe eine Express.js-RESTful-API für Benutzerregistrierung und Login"}'

Danach Qwen für chinesische Kommentare:

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "prompt": "Übersetze die englischen Kommentare in diesem Code ins Chinesische:\n[Code-Inhalt]"}'

Geteilte Arbeit ist effizienter als ein einzelnes Modell. DeepSeek liefert solide Codequalität, Qwen natürliche Übersetzungen.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Intelligenter Kundenservice: Zweisprachig

Für internationalen Support:

• Llama für englische Anfragen
• Qwen für chinesische Anfragen

Sprache erkennen, passendes Modell aufrufen:

import requests

def get_response(user_input, language):
    model = "llama3.2:3b" if language == "en" else "qwen2.5:7b"

    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": model, "prompt": user_input, "stream": False}
    )

    return response.json()["response"]

Jeder Nutzer erhält Antworten in seiner Sprache – deutlich besser als ein einsprachiges Modell.

Wissens-Q&A: Reasoning + Smalltalk

Unterschiedliche Fragetypen, unterschiedliche Modelle:

• DeepSeek für Reasoning-Fragen (z. B. „Warum”, „Wie funktioniert”)
• Llama für offene Fragen (z. B. „Was meinst du”, „Deine Meinung”)

Reasoning braucht logische Analyse – DeepSeek liefert strukturiertere Antworten. Offene Fragen brauchen weniger Strenge – Llama klingt natürlicher, mehr wie ein Gespräch.

Anhand von Schlüsselwörtern entscheiden: „Warum”, „Grund”, „Prinzip” → DeepSeek; „Was meinst du”, „Deine Meinung”, „Lass uns reden” → Llama.

Vollständiges Beispiel

Ein einfaches Python-Skript wählt das Modell nach Aufgabentyp:

import requests

def call_ollama(task_type, prompt):
    """Passendes Modell je nach Aufgabentyp wählen"""

    model_map = {
        "code": "deepseek-coder:6.7b",
        "chinese": "qwen2.5:7b",
        "english": "llama3.2:3b",
        "reasoning": "deepseek-coder:6.7b",
        "general": "llama3.2:3b"
    }

    model = model_map.get(task_type, "llama3.2:3b")

    # Modell vorladen (optional)
    requests.post(
        "http://localhost:11434/api/generate",
        json={"model": model, "prompt": "", "keep_alive": "30m"}
    )

    # Eigentlicher Aufruf
    response = requests.post(
        "http://localhost/11434/api/generate",
        json={"model": model, "prompt": prompt, "stream": False}
    )

    return response.json()["response"]

# Beispielaufruf
result = call_ollama("code", "Schreibe eine Python-Funktion, die das N-te Fibonacci-Element berechnet")
print(result)

Einfach, aber bereits grundlegendes Multi-Modell-Scheduling. Erweiterbar um weitere Aufgabentypen, komplexere Auswahlregeln oder Antwort-Kombination mehrerer Modelle.

Für Ollama-Grundlagen empfehle ich die ersten beiden Artikel der Serie: „Ollama-Einstieg: Der erste Schritt zum lokalen LLM” und „Ollama Modelfile: Parameter im Detail”. Dieser Artikel setzt dort an und ergänzt das Thema Multi-Modell-Deployment.

Konfigurations-Übersicht

Fazit

Kurz zusammengefasst, drei Kernpunkte:

1. Drei Umgebungsvariablen konfigurieren – dann läuft Multi-Modell-Parallelbetrieb. OLLAMA_MAX_LOADED_MODELS steuert die Anzahl, OLLAMA_KEEP_ALIVE die Standby-Zeit.

2. Modell nach Aufgabe wählen. Code: DeepSeek. Chinesisch: Qwen. Allgemein: Llama. Jedes Modell hat seine Stärke.

3. Speicherverwaltung zählt. Häufige Modelle vorladen, seltene bei Bedarf. VRAM reicht nicht – System-RAM nutzen. Hauptsache, es funktioniert.

Mit 16 GB+ VRAM oder 32 GB+ Unified Memory auf dem Mac lohnt sich paralleles Deployment dreier Modelle. Anfangs etwas Einarbeitung – danach deutlich flüssiger als Einzelmodell-Betrieb. Kein ständiges Wechseln, kein Warten beim Laden.

Fragen oder Fallstricke? Hinterlassen Sie einen Kommentar. Ich lerne mit – vielleicht habe ich die Antwort auf Ihr Problem.