Ollama installieren: So betreiben Sie ein LLM auf dem eigenen Server

Was ist Ollama und wofür nutzen Sie es?

Ollama ist ein Open Source Werkzeug, mit dem Sie große Sprachmodelle (LLMs) auf dem eigenen Rechner oder Server herunterladen und ausführen. Es lädt die Modelldateien, hält sie im Arbeitsspeicher und stellt sie über die Kommandozeile sowie eine lokale REST API bereit. Ihre Eingaben verlassen damit nicht Ihre eigene Infrastruktur.

Wir sind Talha Aslan und Team, ein Team für digitales Marketing, Web und KI Automatisierung. Ein Hosting Anbieter sind wir nicht. Deshalb stützen wir jeden Befehl und jeden Einstellungsnamen in diesem Leitfaden auf die offizielle Dokumentation und das GitHub Repository des Projekts. Unser Ziel: Sie sollen erkennen, wann ein eigener Modellserver sinnvoll ist und wie Sie ihn sicher einrichten.

Falls Ihnen das Konzept LLM noch neu ist, lesen Sie zunächst unseren Leitfaden zu großen Sprachmodellen in der Softwareentwicklung. Außerdem behandelt dieser Artikel nur den Modellserver. Möchten Sie darauf einen Agenten aufbauen, der Werkzeuge nutzt, dann hilft Ihnen unser Beitrag KI Agent selbst hosten.

Warum sollten Sie ein Sprachmodell auf dem eigenen Server betreiben?

Für den lokalen Betrieb sprechen vor allem drei Gründe: Datenschutz, Kostenkontrolle und Unabhängigkeit vom Internet. Allerdings hat jeder Vorteil auch einen Preis. Wer beide Seiten kennt, plant also realistischer.

• Datenschutz: Laut offizieller FAQ sehen die Entwickler Ihre Eingaben und Daten nicht, solange Sie Modelle lokal ausführen. Kundenkorrespondenz, interne Dokumente und personenbezogene Daten bleiben auf Ihrem Server.
• Kostenkontrolle: Cloud APIs rechnen meist nach verbrauchten Tokens ab. Auf dem eigenen Server verschieben sich die Kosten zu festen Posten wie Hardware und Strom. Bei hoher und gut planbarer Nutzung lässt sich das leichter budgetieren.
• Offline Betrieb: Liegt ein Modell einmal auf der Platte, antwortet es auch ohne Internetverbindung. Das zählt in abgeschotteten Netzen und auf Geräten im Außeneinsatz.
• Anpassung: Systemprompt, Parameter wie die Temperatur und die Kontextlänge legen Sie selbst fest.

Andererseits tragen Sie die volle Verantwortung für Hardware, Updates und Sicherheit. Zudem erreichen offene Modelle, die Sie lokal betreiben können, nicht bei jeder Aufgabe die Qualität der größten kommerziellen Cloud Modelle. Kurz gesagt: Ollama ist kein „kostenloses ChatGPT“, sondern ein Baustein Ihrer Infrastruktur.

Wie viel RAM und VRAM braucht ein lokales LLM?

Eine feste Zahl nennen wir bewusst nicht. Der Bedarf hängt nämlich von der Parameterzahl, der Quantisierung und der Kontextlänge ab. Die Grundregel ist dennoch einfach: Die Gewichte des Modells müssen vollständig in den Speicher passen, und darüber hinaus brauchen Sie Platz für den Kontext.

Beispielrechnung (grobe Schätzung, keine Garantie): Nehmen Sie ein Modell mit 8 Milliarden Parametern bei 4 Bit Quantisierung. Jeder Parameter belegt dann etwa ein halbes Byte. Die Gewichte allein kommen also auf rund 4 GB. Kontextfenster und Arbeitspuffer kommen zudem noch hinzu. Die 16 Bit Variante desselben Modells braucht dagegen ungefähr das Vierfache, also deutlich mehr.

Daraus folgen drei praktische Regeln:

• Verdoppelt sich die Parameterzahl, verdoppelt sich grob auch der Speicherbedarf.
• Eine stärkere Quantisierung spart Speicher. Allerdings kann sie etwas Antwortqualität kosten.
• Ein längerer Kontext braucht ebenfalls mehr Speicher; planen Sie das ein, wenn Sie lange Dokumente zusammenfassen.

Konkret nennt jede Modellseite in der Bibliothek die Downloadgröße. Diese Größe ist ein guter Hinweis auf die Untergrenze des Speicherbedarfs. Prüfen Sie daher zuerst die Größe des Zielmodells und wählen Sie dann den Server mit ausreichend Reserve.

Läuft ein lokales Modell auch ohne GPU?

Ja. Findet das Werkzeug keine passende GPU, führt es das Modell auf der CPU und im normalen Arbeitsspeicher aus. Allerdings sinkt die Geschwindigkeit dann deutlich. Für Tests mit kleinen Modellen, nächtliche Stapelverarbeitung oder interne Werkzeuge mit wenig Last kann die CPU trotzdem genügen.

Für Echtzeitchat, viele gleichzeitige Nutzer oder große Modelle macht eine GPU dagegen den Unterschied. Die offizielle Docker Dokumentation nennt eigene Startbefehle für NVIDIA und AMD Karten. Passt ein Modell nicht vollständig in den Grafikspeicher, teilt der Server es zudem zwischen GPU und CPU auf. Die Geschwindigkeit liegt dann irgendwo dazwischen.

Welcher Prozessor arbeitet, zeigt Ihnen ollama ps. Laut offizieller FAQ listet dieser Befehl die geladenen Modelle samt Aufteilung: vollständig GPU, vollständig CPU oder eine Mischung in Prozent. An dieser Stelle hilft Ihnen unser Ratgeber zum Mieten von GPU Servern.

Sind Sie beim Servertyp unsicher, dann vergleicht unser Beitrag VPS oder Cloud Server die Grundoptionen. Kurz gesagt: Definieren Sie zuerst die Arbeitslast und wählen Sie erst dann die Hardware.

Wie installieren Sie Ollama auf einem Linux Server?

Die offizielle Linux Dokumentation bietet ein Installationsskript an. Dort steht es als Einzeiler, der das Skript herunterlädt und direkt an die Shell weiterreicht. Dieses Muster empfehlen wir nicht, denn damit führen Sie ein Skript aus dem Internet mit Administratorrechten aus, ohne es gelesen zu haben. Gehen Sie stattdessen in drei Schritten vor: herunterladen, prüfen, ausführen.

curl -fsSL https://ollama.com/install.sh -o install.sh
less install.sh
sh install.sh

Im zweiten Schritt lesen Sie, was das Skript tut. Im Kern legt es zunächst das Programm ab, richtet einen Systembenutzer ollama ein und erstellt einen Dienst unter systemd. Wo nötig, fragt es außerdem nach Administratorrechten.

Ohne Skript geht es ebenfalls: Die Dokumentation beschreibt auch eine manuelle Installation. Dabei laden Sie das Archiv, entpacken es unter /usr und schreiben die Dienstdatei selbst. Die Unit Datei aus der Dokumentation sieht so aus:

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Die manuelle Variante gibt Ihnen mehr Kontrolle. Andererseits erledigen Sie dann auch Updates von Hand. Für einen einzelnen Testserver ist das geprüfte Skript daher meist praktischer.

Wie prüfen Sie den Dienst nach der Installation?

Nach der Installation prüfen Sie zuerst, ob der Dienst läuft. Die Dokumentation nennt diese Reihenfolge: systemd neu laden, den Dienst beim Systemstart aktivieren und dann den Status ansehen.

sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama
systemctl status ollama

Meldet der Dienst einen Fehler, lesen Sie die Protokolle mit journalctl -e -u ollama. Dort finden Sie zum Beispiel Hinweise auf einen fehlenden Grafiktreiber, zu wenig Speicher oder einen belegten Port.

Schließlich testen Sie die API vom selben Server aus. Dafür eignet sich der Endpunkt, der die lokalen Modelle auflistet:

curl http://localhost:11434/api/tags

Eine leere Liste ist normal, weil Sie noch kein Modell geladen haben. Entscheidend ist, dass die Verbindung steht. Für Updates empfiehlt die Dokumentation, das Installationsskript erneut auszuführen. Bleiben Sie auch dabei beim Ablauf aus Herunterladen und Prüfen.

Zum Deinstallieren nennt die Dokumentation diese Reihenfolge: Dienst stoppen, deaktivieren, Dienstdatei löschen und anschließend Benutzer und Gruppe ollama entfernen. Danach löschen Sie das Verzeichnis mit den Modellen. Überlegen Sie das gut, denn Modelle sind groß und ein erneuter Download dauert.

Wie unterscheidet sich die Einrichtung unter macOS und Windows?

Auf Desktopsystemen ist die Einrichtung deshalb einfacher, weil ein Installer die Arbeit übernimmt. Sie laden die App für macOS oder das Installationsprogramm für Windows von der offiziellen Downloadseite. Danach läuft die App im Hintergrund, und Sie nutzen dieselben Befehle im Terminal.

Unterschiede zeigen sich vor allem bei der Konfiguration. Laut offizieller FAQ gilt:

• macOS: Sie setzen Umgebungsvariablen mit launchctl setenv und starten die App danach neu. Modelle liegen standardmäßig unter ~/.ollama/models.
• Windows: Sie bearbeiten die Benutzervariablen in den Systemeinstellungen und öffnen die App danach erneut über das Startmenü. Modelle liegen im Ordner .ollama\models Ihres Benutzerprofils.
• Linux: Sie übergeben Einstellungen über eine Override Datei für systemd. Modelle liegen standardmäßig unter /usr/share/ollama/.ollama/models.

Eine Desktopinstallation eignet sich ideal, um Modelle zu testen und Prompts zu entwerfen. Für einen Dienst, den Ihr ganzes Team nutzt, wählen Sie allerdings besser einen Server. So unterbrechen Ruhezustand, Systemupdates und private Nutzung den Betrieb nicht.

Mit welchem Befehl starten Sie Ollama in Docker?

Das offizielle Image stammt aus dem eigenen Repository des Projekts auf Docker Hub. Der Befehl für den reinen CPU Betrieb in der Dokumentation speichert Modelle in einem benannten Volume und veröffentlicht Port 11434 mit -p 11434:11434. Dank des Volumes bleiben Ihre Modelle erhalten, auch wenn Sie den Container löschen und neu anlegen.

Auf einem Server mit NVIDIA Karte ergänzen Sie das Flag --gpus=all. Dafür muss auf dem Host das NVIDIA Container Toolkit installiert sein. Für AMD Karten zeigt die Dokumentation den Tag rocm sowie zusätzliche Geräteoptionen.

Achten Sie vor allem auf ein Detail. Mit -p 11434:11434 veröffentlicht Docker den Port auf allen Netzwerkschnittstellen des Servers. Zudem können die Netzwerkregeln von Docker in manchen Konfigurationen Firewalls wie ufw umgehen. Nutzen also nur Anwendungen auf demselben Server die API, dann binden Sie den Port an localhost:

docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama run gemma4

Die zweite Zeile lädt ein Modell im Container und startet eine interaktive Sitzung. Ist Docker für Sie neu, lesen Sie zuerst unseren Leitfaden zu Docker Containern. Dort erklären wir Volumes, Ports und Images ausführlich.

Wie laden und starten Sie ein Modell?

Die tägliche Arbeit besteht zum Glück aus wenigen Befehlen, denn das Werkzeug bleibt schlank. In den Beispielen nutzen wir gemma4, den Modellnamen aus der offiziellen Referenz der Kommandozeile. Sie setzen dort einfach Ihr gewähltes Modell ein.

ollama pull gemma4
ollama run gemma4
ollama ls
ollama ps
ollama stop gemma4
ollama rm gemma4

Das leisten die Befehle im Einzelnen:

1. pull lädt ein Modell aus der Bibliothek, ohne es zu starten. Das erledigen Sie zuerst, wenn Sie einen Server vorbereiten.
2. run startet das Modell und öffnet einen interaktiven Chat. Fehlt das Modell, lädt der Befehl es vorher herunter.
3. ls (Langform list) zeigt die Modelle auf der Festplatte.
4. ps zeigt die aktuell geladenen Modelle samt Aufteilung auf GPU und CPU.
5. stop entlädt ein Modell sofort aus dem Speicher.
6. rm löscht ein Modell von der Festplatte.

Außerdem erstellen Sie mit ollama create und einer Modelfile Ihre eigene Modelldefinition. Zum Beispiel legen Sie eine Variante für den Kundenservice mit festem Systemprompt und fester Temperatur an. Dann muss Ihre Anwendung diese Einstellungen nicht bei jeder Anfrage mitschicken.

Für welche Aufgaben eignet sich ein lokales Modell?

Ein lokales Modell ersetzt nicht bei jeder Aufgabe ein Cloud Modell. Dennoch liefert es bei manchen Aufgaben genug Qualität und hält die Daten im Haus. In unseren Projekten zur KI Automatisierung empfehlen wir diese Einstiegsfelder:

• Klassifizierung: Eingehende Supportanfragen, Formularnachrichten oder Bewertungen nach Thema und Priorität sortieren.
• Zusammenfassung: Besprechungsnotizen, lange Mailverläufe oder Berichtsentwürfe in kurze Stichpunkte verwandeln.
• Erste Entwürfe: Produktbeschreibungen, Kategorietexte oder Antwortvorlagen vorbereiten; die Endkontrolle übernimmt weiterhin ein Mensch.
• Datenextraktion: Namen, Daten und Beträge aus Rechnungen, Bestellungen oder Anträgen in ein strukturiertes Format übertragen.
• Semantische Suche: Interne Dokumente mit Embedding Modellen in Vektoren umwandeln und die Frage „Welches Dokument ähnelt diesem?“ beantworten.

Gemeinsam ist diesen Aufgaben somit eine kurze Ausgabe, die ein Mensch prüfen kann. Lange, kreative und fehlerfreie Texte verlangen dagegen eher ein größeres Modell. Wählen Sie deshalb ein kleines, messbares erstes Projekt und erweitern Sie den Umfang erst nach dem Erfolg.

Welches Modell sollten Sie wählen?

Die Modellwahl kostet mehr Zeit als die Installation. Ein „bestes“ Modell nennen wir nicht, denn die richtige Wahl hängt von Aufgabe, Sprache und Hardware ab. Grenzen Sie stattdessen in dieser Reihenfolge ein:

1. Aufgabe: Chat und Textgenerierung, Code, Bildverständnis oder Embeddings für die Suche? Die Bibliothek ordnet Modelle nach diesen Fähigkeiten.
2. Sprache: Arbeiten Sie auf Deutsch, testen Sie die Qualität mit eigenen Beispieltexten.
3. Größe: Beginnen Sie mit der größten Variante, die bequem in den Speicher Ihres Servers passt. Verkleinern Sie dann bei Bedarf.
4. Lizenz: Lesen Sie die Bedingungen für kommerzielle Nutzung auf der Modellseite. Dazu folgt unten ein eigener Abschnitt.

Eine praktische Methode hat sich bewährt. Schreiben Sie 20 realistische Fragen aus Ihrem Geschäft auf und testen Sie zwei oder drei Kandidaten mit genau diesen Fragen. Notieren Sie danach Antwortqualität, Geschwindigkeit und Speicherverbrauch. Dieser kleine Test liefert eine solidere Entscheidung als jede allgemeine Rangliste.

Ein Onlineshop, der Entwürfe für Produktbeschreibungen braucht, kommt zum Beispiel oft mit einem mittelgroßen Chatmodell aus. Zusammenfassungen von Verträgen mit langem Kontext brauchen dagegen mehr Speicher und sorgfältige Tests.

Wie binden Sie die REST API an Ihre Anwendung an?

Sobald der Dienst läuft, öffnet er eine lokale HTTP API. Laut offizieller Dokumentation lautet die lokale Basisadresse http://localhost:11434/api. Für Unterhaltungen nutzen Sie /api/chat, für einmalige Textgenerierung /api/generate und für Vektoren /api/embed.

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{"role": "user", "content": "Wie funktioniert unsere Rückgabe?"}],
  "stream": false
}'

Konkret liefert der Wert "stream": false die Antwort am Stück. In Chatoberflächen bleibt das Streaming dagegen meist aktiv, damit Nutzer die ersten Wörter ohne Wartezeit sehen.

Zusätzlich bietet das Werkzeug einen zur OpenAI API kompatiblen Endpunkt unter http://localhost:11434/v1. Eine Anwendung, die Sie mit der OpenAI Bibliothek gebaut haben, richten Sie somit über die Basisadresse auf das lokale Modell aus. Die Cloud Seite erklären wir in unserer Anleitung zur OpenAI API; sie hilft Ihnen beim Vergleich.

Eine Warnung gehört dazu. Die offizielle Dokumentation sagt klar: Lokale Anfragen brauchen keine Authentifizierung. Das heißt, jeder, der die API erreicht, kann Ihre Modelle nutzen. Der nächste Abschnitt behandelt genau dieses Risiko.

Warum ist es riskant, die Ollama API ins Internet zu stellen?

Laut offizieller FAQ lauscht der Server standardmäßig auf 127.0.0.1 und Port 11434. Direkt nach der Installation erreicht ihn also nur derselbe Rechner. Das ist ein sicherer Ausgangspunkt. Problematisch wird es, wenn Sie OLLAMA_HOST auf 0.0.0.0 setzen und den Port ins Internet öffnen.

Weil die lokale API weder Passwort noch Schlüssel verlangt, bringt ein offener Port diese Risiken:

• Missbrauch von Ressourcen: Fremde nutzen Ihre CPU und GPU für eigene Zwecke. Die Rechnung und die Verlangsamung tragen Sie.
• Verwaltung der Modelle: Die API umfasst mehr als Chat. Sie enthält auch Endpunkte zum Laden und Löschen von Modellen, sodass Unbefugte Ihre Festplatte füllen oder Modelle entfernen könnten.
• Offengelegte Konfiguration: Systemprompts und Einstellungen Ihrer eigenen Modelle lassen sich von außen auslesen.

Daher gilt eine klare Regel: Öffnen Sie diesen Port nie ungeschützt. Brauchen Sie Fernzugriff, dann setzen Sie einen Reverse Proxy mit Authentifizierung davor, beschränken den Zugriff auf bestimmte Adressen oder nutzen ein VPN. Betreiben Sie außerdem eine Firewall auf dem Host; unser Beitrag zur CSF Firewall ist dafür ein guter Einstieg.

Wie schützen Sie den Modellserver mit einem Reverse Proxy unter Nginx?

Am häufigsten bleibt der Modellserver auf localhost, und Nginx steht davor. Nginx spricht nach außen HTTPS, verlangt eine Basisauthentifizierung und lässt nur freigegebene Adressen zu. Die offizielle FAQ zeigt ein Beispiel für Nginx, das Anfragen an den lokalen Port weiterleitet und den Host Header auf localhost:11434 setzt.

server {
    listen 443 ssl;
    server_name llm.example.com;
    # Zeilen für ssl_certificate und ssl_certificate_key hier

    location / {
        allow 203.0.113.10;
        deny all;
        auth_basic "LLM";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

Die Passwortdatei erstellen Sie dann mit dem Werkzeug htpasswd. Die Adresse im Beispiel stammt aus einem Bereich für Dokumentation. Ersetzen Sie sie durch die Adresse Ihres Büros oder Anwendungsservers.

Richten Sie Nginx neu ein, dann folgen Sie unserer Anleitung zur Installation und Konfiguration von Nginx. Das Prinzip des Reverse Proxy und eine grafische Alternative erklären wir in unserem Beitrag Nginx Reverse Proxy einrichten. Nach der Einrichtung des Zertifikats prüfen Sie Ihre Domain mit unserem SSL Check.

Was bringen Weboberflächen wie Open WebUI?

Für Entwickler genügen Kommandozeile und API. Kolleginnen und Kollegen außerhalb der Entwicklung bevorzugen allerdings ein Chatfenster im Browser. Open WebUI ist eine Open Source Weboberfläche, die sich mit dieser API verbinden lässt. Sie bietet Benutzerkonten, Chatverlauf und Modellauswahl.

Für die Einrichtung folgen Sie der offiziellen Dokumentation von Open WebUI, nicht einer beliebigen Anleitung. Das Projekt hält Versionen, Imagenamen und Umgebungsvariablen auf den eigenen Seiten aktuell. Deshalb nennen wir hier keine Befehle dafür.

Mit einer Oberfläche ändert sich allerdings Ihr Sicherheitsbild. Sie betreiben dann zwei Dienste: den Modellserver und die Oberfläche. Halten Sie sich an diese Grundsätze:

• Lassen Sie den Modellserver weiterhin nur auf localhost oder in einem internen Docker Netzwerk lauschen. Nach außen öffnen Sie nur die Oberfläche.
• Legen Sie das erste Administratorkonto sofort an. Schalten Sie danach offene Registrierungen ab oder machen Sie sie freigabepflichtig.
• Stellen Sie auch die Oberfläche nur per HTTPS bereit.

So chatten Nutzer im Browser, während der Modellserver von außen unerreichbar bleibt.

Wie steuern Sie Speicher und parallele Anfragen?

Das Verhalten des Servers steuern Sie über Umgebungsvariablen. Unter Linux führt der offizielle Weg über eine Override Datei für systemd:

sudo systemctl edit ollama
# im geöffneten Editor:
[Service]
Environment="OLLAMA_KEEP_ALIVE=10m"
Environment="OLLAMA_MODELS=/data/llm-models"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Die wichtigsten Einstellungen aus der offiziellen FAQ im Überblick:

Zusammengefasst ist jede Einstellung ein Kompromiss. Parallele Anfragen und langer Kontext verbessern das Nutzererlebnis, kosten aber Speicher. Beobachten Sie nach jeder Änderung das Ergebnis mit ollama ps.

Erlauben die Lizenzen offener Modelle eine kommerzielle Nutzung?

Hier greifen zwei getrennte Lizenzen, und viele verwechseln sie. Die Software selbst steht im GitHub Repository unter der MIT Lizenz. Jedes Modell, das Sie herunterladen, hat jedoch eine eigene Lizenz, und die stammt vom Entwickler des Modells.

Manche Modelle stehen unter freizügigen Open Source Lizenzen wie Apache 2.0. Andere kommen mit eigenen Nutzungsbedingungen des Entwicklers. Diese Bedingungen können etwa eine Richtlinie zur zulässigen Nutzung, eine Zusatzgenehmigung ab einer bestimmten Nutzerzahl oder Grenzen für das Training anderer Modelle mit den Ausgaben enthalten.

In der Praxis gehen Sie so vor:

1. Öffnen Sie zunächst den Lizenzabschnitt auf der Modellseite der Bibliothek.
2. Lesen Sie dann den vollständigen Text auf der offiziellen Seite des Entwicklers.
3. Planen Sie ein kommerzielles Produkt, einen Dienst für Kunden oder ein Feintuning, notieren Sie, ob die Lizenz das ausdrücklich erlaubt.
4. Im Zweifel fragen Sie Ihre Rechtsberatung.

Dieser Abschnitt ist keine Rechtsberatung. Wir möchten lediglich darauf hinweisen, dass „offenes Modell“ nicht immer „frei für jeden Zweck“ bedeutet. Verarbeiten Sie personenbezogene Daten, gelten außerdem Ihre Pflichten aus der DSGVO, ganz gleich, wo das Modell läuft.

Sicherheitscheckliste für einen eigenen Modellserver

Haken Sie nach der Einrichtung diese Liste Punkt für Punkt ab. Die Punkte stammen aus der offiziellen Dokumentation und aus allgemeinen Grundsätzen der Serversicherheit.

• Lauscht der Modellserver nur auf 127.0.0.1 oder einer internen Adresse? Ist bei Docker der veröffentlichte Port an localhost gebunden?
• Ist Fernzugriff nur über einen Reverse Proxy mit Authentifizierung, ein VPN oder eine Liste erlaubter Adressen möglich?
• Öffnet die Firewall auf dem Host nur die nötigen Ports?
• Haben Sie das Installationsskript vor dem Ausführen gelesen, und stammt es von der offiziellen Domain?
• Aktualisieren Sie Systempakete und Modellserver regelmäßig?
• Reicht der Speicherplatz für die Modelle, und überwachen Sie ihn?
• Passen die Lizenzen Ihrer Modelle zu Ihrem Geschäftszweck?
• Sind bei einer Chatoberfläche offene Registrierungen abgeschaltet?

Wir empfehlen, die Liste einmal im Monat durchzugehen. Jede neue Oberfläche, jedes Plugin und jeder Agent vergrößert nämlich die Angriffsfläche. Für allgemeine Risiken von Webanwendungen ist unser Beitrag zu den OWASP Top 10 eine gute Ergänzung.

Ollama oder Cloud API für LLMs: Was passt besser?

Beide Ansätze haben vor allem unterschiedliche Stärken. Die folgende Tabelle ist eine allgemeine Übersicht als Entscheidungshilfe. Sie spiegelt weder Preise noch Leistung eines bestimmten Anbieters wider.

Für viele Teams lautet die Antwort: eine Mischung. Sensible Daten verarbeiten Sie lokal, und Aufgaben mit höchstem Qualitätsanspruch schicken Sie an eine Cloud API. Der zur OpenAI API kompatible Endpunkt erleichtert diesen Wechsel.

Wann sollten Sie Ollama nicht selbst einrichten?

Ehrlich gesagt braucht nicht jedes Unternehmen einen eigenen Modellserver. In diesen Fällen empfehlen wir, abzuwarten oder die Aufgabe einem Hosting Anbieter beziehungsweise einem technischen Team zu überlassen:

• Niemand in Ihrem Team kann Linux Updates, Firewallregeln und Protokolle betreuen.
• Sie stellen nur wenige Dutzend Anfragen im Monat. Dann übersteigen die Serverkosten oft die Kosten einer Cloud API.
• Ihre Arbeit verlangt die Qualität der stärksten kommerziellen Modelle, und Tests mit offenen Modellen haben nicht gereicht.
• Sie müssen hohe Verfügbarkeit zusagen. Das erfordert eine Architektur, die über einen einzelnen Server hinausgeht.
• Sie nutzen ein Shared Hosting Paket. Solche Pakete erlauben meist keine dauerhaft laufenden Dienste und keinen hohen Speicherverbrauch.

Trotzdem lohnt sich selbst dann ein Test auf dem eigenen Rechner. So erfahren Sie, welches Modell zu Ihrer Arbeit passt, und treffen die Serverentscheidung auf Basis von Daten.

Wo fangen Sie am besten an?

Unsere empfohlene Reihenfolge sieht so aus. Testen Sie zunächst ein kleines Modell auf Ihrem eigenen Rechner. Vergleichen Sie danach zwei oder drei Modelle mit echten Fragen aus Ihrem Geschäft. Wählen Sie dann einen passenden Server, führen Sie das geprüfte Installationsskript aus und belassen Sie die API auf localhost.

Brauchen Sie Fernzugriff, ergänzen Sie Nginx und Authentifizierung, prüfen die Lizenzen und gehen die Sicherheitsliste regelmäßig durch. Mit dieser Reihenfolge wird Ihr lokaler Modellserver zu einem soliden KI Baustein, der Ihre Daten im Haus behält.

Möchten Sie ein lokales Modell in Ihre Abläufe einbinden, etwa um Supportanfragen zu sortieren oder Produkttexte vorzuentwerfen, dann plant unser Team für KI Automatisierung diese Integration. Benötigen Sie eine eigene Oberfläche oder einen Workflow für Ihre Software, unterstützen wir Sie ebenso über die individuelle Softwareentwicklung.

Quellen: Ollama Dokumentation für Linux, Ollama FAQ, Ollama Dokumentation für Docker, Ollama auf GitHub.