Derselbe OpenAI-Chat-Loop lokal mit Ollama ausführen

Chats mit gehosteten Anbietern sind kostenintensiv, und jede Anfrage wird in das Rechenzentrum eines Dritten gesendet. Durch den Betrieb eines offenen Modells auf eigener Maschine mit Ollama entfallen beide Probleme. Das Beste daran ist, dass der vorhandene, auf OpenAI basierende Chat-Code weiterhin funktioniert, da sich nur die Adresse ändert.

Derselbe Dialekt, andere Maschine

Ollama ist ein lokaler Modellserver. Nach der Installation lädt man das Modell einmal herunter, wobei die Gewichte genauso wie bei einer Docker-Image heruntergeladen werden. Anschließend hört der Server auf Anfragen über HTTP auf localhost:11434. Praktisch ist dabei, dass Ollama absichtlich die Chat Completions API von OpenAI nachahmt: derselbe /v1/chat/completions-Pfad, dieselbe Liste an mit Rollen versehenen Nachrichten, dieselbe Antwortstruktur mit choices[0].message.content sowie dieselben Nutzungszähler.

Das Verschieben eines OpenAI-Chat-Loops ist daher keine Neuimplementierung, sondern lediglich ein Wechsel des Standorts. Der Vorteil ist offensichtlich: Es gibt keine API-Schlüssel, keine Abrechnung pro Token und keine Daten, die die Maschine verlassen, und im Gegenzug erhält man die Geschwindigkeit der eigenen Hardware sowie die Qualität eines offenen Modells anstelle eines hochentwickelten Modells. Für das Lernen, wie Agenten funktionieren – wobei Hunderte von Iterationen üblich sind – ist das eine sehr gute Lösung.

Einrichtung und ein einziger Turn

Holen Sie sich Ollama von ollama.com. Es wird in einem Schritt installiert und der Server läuft im Hintergrund. Anschließend laden Sie ein kleines Modell herunter. llama3.2 mit etwa 2 GB ist eine sinnvolle Standardwahl. Auf der Python-Seite ist nichts Neues erforderlich, da das Standardpaket openai einfach auf einen anderen Ort verweist:

from openai import OpenAI

# Part 2's SDK, different address
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # required, unused
)

resp = client.chat.completions.create(
    model="llama3.2",
    messages=[
        {
            "role": "system",
            "content": "You are a concise "
                       "assistant.",
        },
        {
            "role": "user",
            "content": "Where are you running "
                       "right now?",
        },
    ],
    temperature=0,
)
print(resp.choices[0].message.content)

Zwei Einstellungen verdienen eine besondere Erwähnung. Wenn base_url auf localhost gesetzt wird, wird der gesamte Verkehr von OpenAI umgeleitet. Der String api_key="ollama" scheint sinnlos zu sein, ist es aber nicht: Das SDK weigert sich, einen Client ohne Schlüssel zu erstellen, während Ollama selbst alles ignoriert, was gesendet wird – daher reicht jeder nicht leere Text aus. Schließlich muss model ein bereits heruntergeladener Name sein. Es gibt keine Preisklassen zur Auswahl, nur das, was auf Ihrer Festplatte gespeichert ist, was ollama list anzeigt.

Der Historielauf wird unverändert beibehalten

Eine gute Prüfung dafür, ob es sich um „denselben Dialekt“ handelt, ist, ob die frühere ask()-Funktion ohne Änderungen gegen Ollama ausgeführt wird. Das ist der Fall. Nur der Code, der den Client erstellt, unterscheidet sich.

Ein kurzes Gespräch beweist das, beginnend mit einer Systemnachricht und anschließend weiterentwickelnd:

msgs = [{
    "role": "system",
    "content": "You are a concise assistant.",
}]

def ask(text: str) -> str:
    msgs.append(
        {"role": "user", "content": text}
    )
    resp = client.chat.completions.create(
        model="llama3.2",
        messages=msgs,  # full history
        temperature=0,
    )
    reply = resp.choices[0].message.content
    msgs.append({
        "role": "assistant",
        "content": reply,
    })
    return reply

print(ask("Define a context window."))
print(ask("Now for a five-year-old."))
print(ask("Which answer was shorter?"))

Die dritte Frage zeigt weiterhin das Historie-Mechanismus, und alles, was aus der gehosteten Version gelernt wurde, wird übernommen. Der Server erinnert sich zwischen den Aufrufen an nichts. Die wachsende msgs-Liste ist der Grund dafür, dass spätere Antworten länger dauern. Hier wird nicht abgerechnet, doch man zahlt bereits in Sekunden – und wenn man beobachtet, wie ein lokales Modell durch anwachsende Historie langsamer wird, wird der Kontextkostenaspekt auf eine Weise greifbar, wie es eine Rechnung niemals könnte.

Setzen Sie Ihre Erwartungen entsprechend. Ein Modell mit etwa 3 Milliarden Parametern ist deutlich weniger leistungsstark als GPT-4o oder Claude. Es kann ins Stocken geraten, wenn es den Systemhinweis überspringt oder bei Vergleichen wie „was von den beiden Dingen war kürzer“ ins Straucheln gerät. Das ist kein Fehler im Algorithmus – es ist einfach das Ergebnis von 3 Milliarden Parametern, und das eigene Erleben dieser Unterschiede lehrt mehr als das Lesen von Leistungsvergleichen.

Ausführung des Beispiels

Drei Befehle reichen aus. Der erste installiert das Modell, der zweite installiert die Python-Abhängigkeiten, und der dritte führt das Skript aus:

# one-time: install from ollama.com, then
ollama pull llama3.2

pip install -r requirements.txt
python examples/part05_ollama.py

Zunächst überprüft das Skript, ob der Ollama-Server auf localhost:11434 antwortet. Falls nicht, beendet das Skript sich mit Anweisungen zur Installation und zum Herunterladen. Das ist die lokale Entsprechung zum schnellen Scheitern bei fehlender API-Schlüssel. Anschließend führt es ein einseitiges Gespräch sowie ein dreiseitiges Gespräch durch und protokolliert die Token-Nutzung, da Ollama die Nutzung in denselben Feldern meldet. Es gibt weder einen Schlüssel noch Kosten. Zudem wird es aus anderen Gründen als die gehosteten Beispiele nicht in CI eingesetzt: CI-Maschinen führen keinen Modellserver aus.

Wenn etwas schiefgeht

• Ein „Modell nicht gefunden“-Fehler bedeutet, dass die entsprechende Tag noch nicht heruntergeladen wurde – führen Sie daher ollama pull llama3.2 aus.
• Ein Verbindungsfehler deutet darauf hin, dass der Server nicht läuft. Starten Sie ihn mit ollama serve, obwohl Desktop-Installationen ihn automatisch starten.

Bei erster Verwendung tritt eine Pause von mehreren Sekunden ein, bevor das erste Token verarbeitet wird – das Modell wird dabei in den Speicher geladen. Es ist nichts hängengeblieben.

Warum ein lokaler Endpunkt vorteilhaft ist

Agentenexperimente wiederholen sich endlos. Die Abrufpipeline wird neu aufgebaut, in Denkzyklen werden für eine Frage mehrere Modellaufrufe durchgeführt, und Graphenworkflows werden nach jeder kleinen Debugging-Anpassung erneut ausgeführt. Der Kostenansatz pro Token für jede dieser Ausführungen summiert sich, während ein kostenloser lokaler Endpunkt es ermöglicht, zu experimentieren, ohne auf einen Kostenanzeiger schauen zu müssen. Da Ollama die OpenAI-Dialekt spricht, kann jedes Beispiel auf beide Weisen ausgeführt werden, indem einfach die Basis-URL und der Modellname ausgetauscht werden – ansonsten nichts. Das Ergebnis ist ein Sandbox-Umfeld mit unbegrenzten Tokens.

Das offensichtliche nächste Thema ist RAG. Ein Modell kennt Ihre Dokumente nicht, daher stellt sich die eigentliche Frage, welche Tokens einen Platz im Kontextfenster erhalten.

Weitere Literatur

• Der zustandslose Chat-Loop: Die OpenAI API manuell in Python aufrufen — Erstellen Sie einen mehrteiligen Chat mithilfe des OpenAI Python SDK, indem Sie den Nachrichtenverlauf selbst verwalten, und erfahren Sie, warum derselbe Loop die Grundlage für das Gedächtnis- und Agentensystem von LangChain bildet.
• Local AI nach Ollama: Die Auswahl von Laufzeiten im Jahr 2026 — Warum Ollama eine hervorragende Einstiegslösung ist, aber ein schwaches Langzeit-Steuerungssystem darstellt – und welche Tools wie llama.cpp, LM Studio, vLLM und ähnliche zu den jeweiligen Phasen passen.

AI-Engineer werden im Jahr 2026 ohne Informatik-Abschluss — Ein Plan vom Anfang bis zur Anstellung, um 2026 ohne Informatik-Abschluss AI-Engineer zu werden: die sieben Fähigkeitsbereiche, kleine Projekte, praktische Erfahrungen und kluges Netzwerken.