Lokale KI betreiben

Lokal, gehostet und Open Weights

Lernziel: Du unterscheidest Rechenort, Modellzugang und Lizenz.

Erklärung

Lokal bedeutet, dass die Inferenz auf eigener oder kontrollierter Hardware läuft. Open Weights bedeutet verfügbare Gewichte, aber nicht automatisch eine offene Lizenz oder freie kommerzielle Nutzung. Ein Anbieter kann offene Gewichte ebenfalls gehostet anbieten.

Inferenz bedeutet hier: Das bereits trainierte Modell berechnet eine Ausgabe. ‚Lokal‘ beschreibt, wo diese Berechnung stattfindet. ‚Open Weights‘ beschreibt dagegen, ob Modellgewichte bereitgestellt werden. Die Lizenz legt fest, unter welchen Bedingungen du sie verwenden darfst. Das sind drei verschiedene Fragen, auch wenn sie in Werbung oft direkt nebeneinanderstehen.

Karte A kann Gewichte anbieten und trotzdem eine gehostete App beschreiben. Für eine eigene lokale Ausführung fehlen dir dann noch ein geeigneter Rechner, eine passende Laufzeit und die geklärte Lizenz. Kreuze nur Angaben an, die die Karte wirklich nennt. So entsteht eine brauchbare Planung, ohne einen bereits bestandenen Betrieb zu behaupten.

Vom Lesen zum eigenen Versuch

So beginnst du.

Lies zuerst die beiden fiktiven Karten. Für die Einordnung musst du nichts installieren.

1. 01

   Gewichte separat prüfen

   Markiere, ob Modellgewichte angeboten werden.

   Erkennbar an: Du trennst verfügbar und nicht bereitgestellt.

2. 02

   Den beschriebenen Betrieb prüfen

   Notiere bei Karte A die gehostete App und bei B die API.

   Erkennbar an: Die Bereitstellung von Gewichten macht die App nicht automatisch lokal.

3. 03

   Die Lizenz offenhalten

   Notiere den ungeklärten Lizenzpunkt und suche ihn vor echtem Einsatz in der konkreten Modellquelle.

   Erkennbar an: Offene Gewichte werden nicht mit uneingeschränkter Nutzung gleichgesetzt.

Eigenes fiktives Lernbeispiel

Deine Vorlage und Aufgabe.

Übungsmaterial

Text

Fiktive Karte A: Gewichte verfügbar; Lizenz separat. Betrieb in einer gehosteten App. Karte B: Gewichte nicht bereitgestellt; Zugriff per API.

Vorlage kopierenAls Textdatei ↓

Ordne Zugang, derzeitigen Rechenort und offene Lizenzfrage getrennt ein.

Mögliche Lösung prüfen

Bei A sagt die Bereitstellung von Gewichten noch nichts über die konkrete Lizenz und macht den beschriebenen Appbetrieb nicht lokal. B beschreibt einen API-Zugang ohne verfügbare Gewichte.

Deine Aufgabe

Ordne drei Modelle nach Gewichtszugang, möglichem Betriebsort und Lizenz.

Häufiger Denkfehler: ‚Lokal‘ mit automatisch sicher oder DSGVO-konform gleichzusetzen.

Du bist fertig, wenn: Du kannst diese drei Fragen getrennt beantworten.

Quelle: huggingface.co

Speicher, Quantisierung und Kontext planen

Lernziel: Du erkennst, welche Angaben für einen Hardware-Test fehlen.

Erklärung

Gewichte, Laufzeit, Cache, Kontext und weitere Prozesse teilen sich Speicher. Quantisierung reduziert die Zahl der Bits pro Gewicht und kann Speicherbedarf senken; die Auswirkungen auf Qualität und Geschwindigkeit hängen von Modell und Implementierung ab.

RAM ist der Arbeitsspeicher des Rechners; VRAM ist Speicher einer Grafikkarte. Bei manchen Geräten teilen sich Prozessor und Grafik einen gemeinsamen Speicher. Notiere, welche Angabe dein Gerät tatsächlich ausweist. Quantisierung bedeutet vereinfacht, Modellwerte mit weniger Bits darzustellen. Das kann Speicher sparen; Tempo und Antwortqualität musst du für die konkrete Variante trotzdem prüfen.

Zum Modell kommen unter anderem Laufzeit und zusätzlicher Speicher für die Verarbeitung längerer Eingaben. Deshalb ist ‚passt als Datei auf die Festplatte‘ nicht dasselbe wie ‚lässt sich unter diesen Bedingungen ausführen‘. Vergleiche in deiner Checkliste Modelltag, Quantisierung, Kontext und freie Ressourcen. Eine offene Angabe bleibt offen, bis sie dokumentiert oder im eigenen Versuch geprüft ist.

Passende Anleitung: Für die Unterscheidung von RAM, VRAM, Modelldatei und laufendem Bedarf hilft dir „Speicher für lokale KI planen“. Übertrage die Angaben auf deine ausgewählte Variante, statt sie als feste Kompatibilitätszusage zu lesen.

Vom Lesen zum eigenen Versuch

So beginnst du.

Öffne die Systeminformationen deines Rechners und ein leeres Testblatt. Lade noch kein großes Modell herunter.

1. 01

   Den Rechner beschreiben

   Notiere Betriebssystem, Arbeitsspeicher, freien Datenträgerplatz und – wenn vorhanden – Grafikspeicher.

   Erkennbar an: Das Testblatt nennt deinen tatsächlichen Rechner.

2. 02

   Die Variante benennen

   Übernimm Modelltag, Quantisierung und Laufzeit aus der konkreten Auswahl; kennzeichne Unbekanntes.

   Erkennbar an: Die beiden Varianten sind anhand ihres Tags unterscheidbar.

3. 03

   Einen kleinen Versuch planen

   Starte erst mit einer kurzen Anfrage und halte Einstellungen sowie Ergebnis fest.

   Erkennbar an: Ein geplanter Versuch ist nicht als bestandener Hardwaretest markiert.

Eigenes fiktives Lernbeispiel

Deine Vorlage und Aufgabe.

Übungsmaterial

Text

Testblatt mit zwei Varianten: gleiche Modellfamilie, verschiedene Quantisierung; Kontext noch offen. Rechner und freie Ressourcen sind nicht dokumentiert.

Vorlage kopierenAls Textdatei ↓

Fülle Modelltag, Quantisierung, Laufzeitversion, Kontext, RAM, VRAM und freien Platz als Prüffelder ein. Was kannst du noch nicht zusagen?

Mögliche Lösung prüfen

Ohne diese Bedingungen ist die konkrete Eignung offen. Eine Planung ist noch kein durchgeführter Kompatibilitäts- oder Geschwindigkeitstest.

Deine Aufgabe

Lege für zwei Modellvarianten eine Checkliste der zu prüfenden Hardwaredaten an.

Häufiger Denkfehler: Eine Speicherangabe ohne Quantisierung oder Laufzeit als Kompatibilitätsgarantie zu verwenden.

Du bist fertig, wenn: Du kannst eine vorsichtige Testplanung von einer gemessenen Kompatibilität unterscheiden.

Quelle: huggingface.co

Ollama installieren und Modell abrufen

Lernziel: Du kannst dem bestehenden Ollama-Lernpfad folgen und eine Installation kontrollieren.

Erklärung

Ollama ist eine Laufzeit, die lokale Modelle verwaltet und über eine lokale Schnittstelle anbietet. Die Modellseite beschreibt den konkreten Startbefehl; installiere und starte nur Software aus überprüften Quellen.

Das Terminal ist ein Fenster für Textbefehle: unter Windows etwa PowerShell, unter macOS die App Terminal. Du gibst Befehle nach der Installation dort ein, nicht in eine Suchmaschine. Die Version prüft die verfügbare Ollama-Laufzeit. Die Modellliste beantwortet getrennt, welche Modelle bereits vorhanden sind. Eine leere Liste vor dem ersten Download ist daher nicht automatisch ein Installationsfehler.

Ein Modelltag benennt die gewünschte Variante. Prüfe dessen Anforderungen, bevor du einen Download startest; das gezeigte Herstellerbeispiel ist kein winziger Platzhalter. Erst wenn das Modell vorhanden ist, testest du eine kurze Anfrage. Notiere Laufzeit, Tag und Ergebnis. Eine erhaltene Antwort belegt diesen Versuch, aber noch keine besondere Qualität oder Geschwindigkeit auf anderen Geräten.

Passende Anleitung: Wenn du bewusst den Container-Weg wählst, arbeite mit „Ollama mit Docker einrichten“ weiter. Dort prüfst du Service, API-Erreichbarkeit und Modellbestand getrennt; für eine native Installation bleibst du bei der Herstelleranleitung deines Betriebssystems.

Vom Lesen zum eigenen Versuch

So beginnst du.

Wähle genau einen Installationsweg: Windows, macOS oder Linux. Die Befehle unten gehören nach der Installation in dein Terminal.

1. 01

   Ollama installieren

   Nutze den offiziellen Download für dein System. Unter Windows öffnest du den Installer; unter macOS die App. Für Linux findest du unten einen getrennten Ablauf.

   Erkennbar an: Du hast einen Installer aus der Herstellerquelle verwendet.

2. 02

   Ein neues Terminal öffnen

   Starte PowerShell unter Windows oder Terminal unter macOS/Linux. Prüfe zunächst ollama --version und danach ollama list.

   Erkennbar an: Die Laufzeit antwortet; die Modellliste ist separat geprüft.

3. 03

   Ein Modell laden und testen

   Prüfe vorab Ressourcen und Modellquelle. Lade dann das dokumentierte Beispiel gemma4:e2b und stelle eine kurze Frage.

   Erkennbar an: Modelltag, Antwort und offene Fehler sind notiert.

Eigenes fiktives Lernbeispiel

Deine Vorlage und Aufgabe.

Übungsmaterial

Text

Optional nach eigener Installation: ollama --version / ollama list. Der Modelltag muss gesondert ausgewählt werden.

Vorlage kopierenAls Textdatei ↓

Halte das Ergebnis beider Abfragen getrennt fest oder markiere beide als nur geplant.

Mögliche Lösung prüfen

Die erste Abfrage prüft die Laufzeitversion, die zweite vorhandene Modelle. Eine Versionsausgabe alleine bestätigt keinen erfolgreichen Modelllauf.

1 · Laufzeit prüfen

PowerShell / Terminal

Nach der Installation in einem neu geöffneten Terminal. Eine leere Modellliste ist vor dem ersten Download normal.

ollama --version
ollama list

Befehle / Code kopierenAls Textdatei ↓

2 · Lokales Herstellerbeispiel laden

PowerShell / Terminal

Prüfe zuvor die Anforderungen. Im geprüften Herstellerbeispiel umfasst der Download etwa 7,2 GB; 8 GB verfügbarer VRAM beziehungsweise Mac-Unified-Memory werden empfohlen. Das ist keine Messung auf deinem Rechner.

ollama pull gemma4:e2b
ollama run gemma4:e2b

Befehle / Code kopierenAls Textdatei ↓

3 · Erste Unterhaltung

Im Ollama-Chat

Die Frage gehört in den gestarteten Chat. /bye beendet diesen Chat; es deinstalliert nichts.

Erkläre in zwei Sätzen den Unterschied zwischen einer Laufzeit und einem Modell.

/bye

Befehle / Code kopierenAls Textdatei ↓

Linux · Anweisung und Kopiervorlagen

Linux · Installer erst lesen

Bash

Optionaler Linux-Weg. Prüfe das Skript vor der Ausführung; die Installation kann Administratorrechte verlangen. Die Seite führt keinen dieser Schritte aus.

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

Befehle / Code kopierenAls Textdatei ↓

Linux · Dienst überprüfen

Bash

Nach der Installation. ollama serve ist nur ein alternativer Start für einen noch nicht laufenden Server; starte keinen zweiten Dienst auf demselben Port.

systemctl status ollama --no-pager
ollama --version
curl -s http://127.0.0.1:11434/api/tags

Befehle / Code kopierenAls Textdatei ↓

Herstellerunterlagen zu diesen Schritten · geprüft 19.10.2026

• docs.ollama.com/quickstart
• docs.ollama.com/windows
• docs.ollama.com/linux
• ollama.com/blog/new-app

Die Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.

Deine Aufgabe

Öffne die passende Anleitung und notiere Betriebssystem, Laufzeitversion und verwendete Modell-ID.

Häufiger Denkfehler: Laufzeit und Modell als denselben Anbieter oder dasselbe Produkt zu behandeln.

Du bist fertig, wenn: Du kannst Laufzeitversion und Modell-ID in deinem Testprotokoll festhalten.

Quelle: docs.ollama.com

Datenfluss und Zugriff kontrollieren

Lernziel: Du kannst prüfen, ob ein Test tatsächlich lokal bleibt.

Erklärung

Ein lokal laufendes Modell sagt noch nichts darüber aus, ob eine Oberfläche, Erweiterung, Telemetrie oder ein Download weitere Verbindungen nutzt. Betrachte Modelllaufzeit, UI, Zusatzdienste und Serverzugriffe separat.

Zeichne jede beteiligte Komponente als eigenen Kasten: Oberfläche, Modelllaufzeit und zusätzliche Werkzeuge. Pfeile zeigen, wohin Eingaben gehen. Ein Modelldownload aus dem Internet ist ein anderer Vorgang als eine spätere lokale Antwort. Eine anschließend zugeschaltete Websuche kann wieder einen externen Datenweg öffnen.

In unserem geplanten Ablauf erhält der lokale Dienst den Text aus dem Editor. Das zusätzlich vorgesehene Suchtool bekommt einen eigenen Pfeil. Ob diese Wege in einer echten Anwendung genau so verlaufen, musst du an ihrer Konfiguration und einem nachvollziehbaren Versuch prüfen. Das Wort ‚lokal‘ auf einer Produktseite ersetzt diese Betrachtung nicht.

Vom Lesen zum eigenen Versuch

So beginnst du.

Zeichne den Datenweg deiner Anfrage. Der Modelldownload ist ein anderer Vorgang als die spätere Antwort.

1. 01

   Download und Anfrage trennen

   Zeichne den Weg aus dem Internet zum Modell und daneben den Weg deiner Texteingabe.

   Erkennbar an: Beide Wege sind getrennt dargestellt.

2. 02

   Zusätzliche Tools prüfen

   Notiere, ob Suche, Browser, Dateiablage oder andere Erweiterungen beteiligt sind.

   Erkennbar an: Ein externes Suchtool ist als eigener Netzwerkweg sichtbar.

3. 03

   Einen überschaubaren Versuch machen

   Teste mit einem erfundenen Satz und dokumentiere Modelltag, Endpunkt und eingeschaltete Tools.

   Erkennbar an: Die Beobachtung belegt nur den dokumentierten Versuch.

Eigenes fiktives Lernbeispiel

Deine Vorlage und Aufgabe.

Übungsmaterial

Text

Geplanter Datenweg: Internet→Modelldownload; Texteditor→lokaler Dienst→Antwort. Zusätzlich ist ein externes Suchtool vorgesehen.

Vorlage kopierenAls Textdatei ↓

Zeichne Download, Inferenz und zusätzliche Suche getrennt. Wo fehlen dir noch Nachweise?

Mögliche Lösung prüfen

Der Download und das externe Suchtool sind eigene Netzwerkwege. Ein lokal laufendes Modell beweist nicht, dass zusätzliche Werkzeuge ebenfalls lokal bleiben.

Deine Aufgabe

Zeichne, welche Komponente Eingabe, Modellgewichte und Antwort jeweils verarbeitet.

Häufiger Denkfehler: Aus ‚läuft lokal‘ eine Datenschutzgarantie abzuleiten.

Du bist fertig, wenn: Du kannst offene Netzwerk- und Datenfragen klar benennen.

Quelle: ollama.com

Fehler systematisch eingrenzen

Lernziel: Du diagnostizierst einen lokalen Modellfehler anhand von Protokoll und Konfiguration.

Erklärung

Fehler können aus Modell-ID, Speicher, Laufzeitversion, Port, Berechtigungen oder Eingabeformat entstehen. Ändere jeweils eine Variable und notiere den Ausgangszustand.

Trenne zunächst die Verbindung vom Modelllauf. Wenn der Client den Dienst auf dem angegebenen Port nicht erreicht, ist eine andere Prüfung nötig als bei einer Antwort des Dienstes, die einen unbekannten Modelltag meldet. Ein Port ist dabei die nummerierte Ansprechstelle eines Dienstes. Ob der Dienst läuft, sagt noch nichts darüber, ob dein gewünschtes Modell geladen werden kann.

Schreibe vor jeder Änderung eine Erwartung auf: ‚Wenn nur die Adresse falsch ist, sollte die Anfrage an die richtige Adresse den Dienst erreichen.‘ Notiere anschließend die Beobachtung. Verändere nicht gleichzeitig Adresse, Modell und Speicherparameter. Sonst weißt du nach einem Erfolg nicht, welche Änderung ausschlaggebend war.

Passende Anleitung: Scheitert bereits die Verbindung, beginne mit „Ollama-Port und Verbindung prüfen“. Ein nicht erreichbarer Dienst ist eine andere Fehlerstelle als ein fehlendes Modell oder eine unpassende Speicherplanung.

Vom Lesen zum eigenen Versuch

So beginnst du.

Arbeite im Terminal. Ändere zunächst keine Modellparameter, wenn der Client den Dienst noch gar nicht erreicht.

1. 01

   Die genaue Meldung notieren

   Übernimm Fehlermeldung, Zeitpunkt und den fehlgeschlagenen Schritt.

   Erkennbar an: Du beschreibst einen beobachteten Fehler statt einer Vermutung.

2. 02

   Die Verbindung isoliert prüfen

   Frage den lokalen /api/tags-Endpunkt ab. Unter Linux kannst du zusätzlich den Dienststatus prüfen.

   Erkennbar an: Du weißt, ob die Anfrage den Dienst erreicht.

3. 03

   Erst danach weiterprüfen

   Prüfe Modelltag und Ressourcen nacheinander; ändere jeweils nur eine Bedingung.

   Erkennbar an: Jeder Versuch hat genau eine nachvollziehbare Änderung.

Eigenes fiktives Lernbeispiel

Deine Vorlage und Aufgabe.

Übungsmaterial

Text

Fiktiver Fehler: Client erreicht localhost:11434 nicht. Modelltag und Speicher wurden noch nicht geprüft.

Vorlage kopierenAls Textdatei ↓

Formuliere eine erste Hypothese und genau einen passenden Test.

Mögliche Lösung prüfen

Zuerst prüfen, ob der vorgesehene Dienst erreichbar ist. Die Beobachtung alleine belegt weder einen Modellfehler noch einen Speichermangel.

Windows · Lokalen Dienst anfragen

PowerShell

Teste zuerst nur die Erreichbarkeit. Leere models-Daten und ein Verbindungsfehler bedeuten unterschiedliche Dinge.

Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/tags"

Befehle / Code kopierenAls Textdatei ↓

macOS/Linux · Lokalen Dienst anfragen

Terminal

Das ist die entsprechende lokale Anfrage im Terminal, kein neuer Modelllauf.

curl -s http://127.0.0.1:11434/api/tags

Befehle / Code kopierenAls Textdatei ↓

Herstellerunterlagen zu diesen Schritten · geprüft 19.10.2026

• docs.ollama.com/quickstart
• docs.ollama.com/troubleshooting

Die Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.

Deine Aufgabe

Erstelle einen kurzen Fehlerbericht mit erwarteter Wirkung, Ist-Zustand, Versionen und einem nächsten Test.

Häufiger Denkfehler: Eine funktionierende Testantwort als Beweis für produktionsreife Stabilität zu werten.

Du bist fertig, wenn: Eine andere Person kann deinen Fehlerzustand reproduzieren oder gezielt weiter prüfen.

Quelle: ollama.com