Welches Ollama-Modell für Tool-Calling Agents 2026 wählen? Umfassender Vergleich und Benchmarks

Tool-Aufrufe in Ollama sind eine der am wenigsten offensichtlichen Funktionen lokaler Modelle. Nicht weil die API kompliziert ist. Sondern weil zwischen "Modell unterstützt Tools" in der Dokumentation und "Modell ruft Tools stabil in der Produktion auf" ein großer Unterschied besteht, der sich erst unter Last zeigt.

Einige Modelle sind nativ für Tool-Aufrufe trainiert: Sie erkennen JSON-Schema, geben strukturierte tool_calls zurück und machen selten Fehler bei den Argumenten. Andere kennen das Format, entscheiden aber selbst, ob sie es verwenden. Wieder andere serialisieren Tools in den System-Prompt und versuchen, textbasiert JSON zu antworten. Das Verhalten von außen ist dasselbe. Die Ergebnisse sind grundlegend unterschiedlich.

Weiter geht's konkret: Welche Modelle wohin gehören, wie man das mit einem Befehl überprüft und was zu tun ist, wenn selbst ein zuverlässiges Modell schweigt.

Wenn du noch nicht damit vertraut bist, wie Tool-Aufrufe auf API-Ebene funktionieren, beginne mit Ollama REST API: Integration in deine Anwendung, dort gibt es eine vollständige Analyse des Aufrufzyklus mit Beispielen in Java, Python und JavaScript.

Was bedeutet "unterstützt Tool-Aufrufe" – und warum ist das nicht nur ein Häkchen

In der offiziellen Ollama-Dokumentation gibt es die Seite Tool Calling mit Codebeispielen. Dort gibt es eine Liste von Modellen, Curl-Beispiele, das JSON-Schema-Format. Aber die Dokumentation beantwortet nicht die Hauptfrage: wie zuverlässig ruft ein bestimmtes Modell Tools unter realen Bedingungen auf?

Das Wort "unterstützt" im Kontext von Tool-Aufrufen ist vage. Es kann drei grundlegend unterschiedliche Dinge bedeuten, und von außen sehen sie gleich aus.

Eine Analogie vor dem Code

Stell dir vor, du hast drei Assistenten eingestellt und jedem von ihnen eine Anweisung gegeben: "Wenn der Kunde nach dem Wetter fragt, rufe den Wetterdienst an und sage mir das Ergebnis. Wenn er nach dem Wechselkurs fragt, fordere die Bank-API an."

• Der erste Assistent versteht klar, wann er anrufen muss, und liefert dir immer ein strukturiertes Ergebnis – "Anruf getätigt, Antwort: +18°C".
• Der zweite Assistent ruft manchmal an, manchmal antwortet er "nun, wahrscheinlich warm" ohne anzurufen – je nach Laune.
• Der dritte Assistent weiß überhaupt nicht, wie er anrufen soll, aber wenn du ihm in einer Notiz detailliert erklärst, was er schreiben soll – versucht er manchmal, das Format zu kopieren. Das Ergebnis ist unvorhersehbar.

Zu allen dreien hast du dasselbe gesagt. Das Verhalten ist unterschiedlich. Genau so sieht die "Unterstützung von Tool-Aufrufen" bei verschiedenen Ollama-Modellen aus.

Drei Unterstützungsstufen – technisch

1. Native Unterstützung (auf Gewichtsebene)

Das Modell wurde auf Daten trainiert, die Beispiele für Tool-Aufrufe enthielten. Es "kennt nicht nur das Format" – es versteht, wann eine externe Funktion aufgerufen werden muss und wann mit Text geantwortet werden muss. JSON-Schema wird als Teil des Dialogs wahrgenommen, nicht als Text. Ollama übergibt Tools über spezielle Token – und das Modell reagiert darauf sachbezogen.

Ergebnis: stabiles tool_calls in der Antwort, korrekte Argumente, vorhersehbares Verhalten bei wiederholten Anfragen. Beispiele: qwen3, llama3.1+, gemma4.

2. Teilweise Unterstützung

Das Modell kennt das JSON-Schema-Format und kann tool_calls zurückgeben – aber nicht immer. Es bewertet die Anfrage und entscheidet selbst, ob ein Tool aufgerufen werden "sollte". Manchmal ist diese Bewertung richtig. Manchmal nicht. Das Verhalten hängt von der Formulierung der Frage, der Länge des Prompts, der Generierungstemperatur ab.

Praktische Konsequenz: Bei einfachen Testanfragen sieht alles gut aus. Unter realer Last treten "stumme" Antworten auf, bei denen tool_calls nicht kam, aber auch kein Fehler auftrat. Der Agent hängt in einem Schritt fest, wo er etwas tun sollte.

3. "Unterstützung" durch Prompt-Engineering

Ollama serialisiert die Beschreibung der Tools in normalen Text und fügt sie in den System-Prompt ein. Das Modell sieht etwas wie: "Du hast eine Funktion get_weather mit den Parametern city und units. Wenn nötig, gib JSON im Format zurück..." Das Modell antwortet basierend auf der Anweisung, nicht auf dem Training.

Ergebnis: JSON kann im Feld content als normaler Text kommen (oft in einem ```json ... ```-Block) und nicht in strukturierten tool_calls. Oder das JSON ist unvollständig. Oder das Modell entscheidet, dass die Frage "einfach genug" ist und antwortet ohne jeglichen Aufruf. Das Parsen einer solchen Ausgabe ist unzuverlässig.

So sieht der Unterschied in der Antwort aus

Dieselbe Anfrage – "Wie ist das Wetter in Charkiw?" – mit verschiedenen Modellen:

Native Unterstützung (qwen3:8b):

{
  "message": {
    "role": "assistant",
    "content": "",
    "tool_calls": [
      {
        "function": {
          "name": "get_weather",
          "arguments": { "city": "Харків", "units": "celsius" }
        }
      }
    ]
  }
}

Prompt-Engineering (mistral-nemo):

{
  "message": {
    "role": "assistant",
    "content": "```json\n{\"tool\": \"get_weather\", \"city\": \"Kharkiv\"}\n```"
  }
}

Ignorieren (phi-4 bei einer Anfrage ohne Kontext):

{
  "message": {
    "role": "assistant",
    "content": "Derzeit ist das Wetter in Charkiw gemäßigt. Normalerweise im Sommer +20–25°C..."
  }
}

HTTP 200 in allen drei Fällen. Code ohne explizite Prüfung auf das Vorhandensein von tool_calls "schluckt" die zweite und dritte Variante als erfolgreiche Antwort – und der Agent geht mit falschen oder fehlenden Daten weiter.

Warum das gerade in der Produktion wichtig ist

Bei einer einzigen Testanfrage ist das Problem unauffällig. Selbst ein Modell mit teilweiser Unterstützung funktioniert richtig, wenn die Frage klar und kurz ist. Das Problem tritt auf, wenn:

• Es viele Anfragen gibt und darunter untypische oder lange sind
• Der Agent mehrere aufeinanderfolgende Schritte ausführen muss (Multi-Step)
• Ein verpasster Tool-Aufruf die gesamte weitere Kette zerstört
• Es keine explizite Prüfung gibt, dass tool_calls angekommen ist, bevor man weitermacht

Deshalb ist die Wahl eines Modells für eine Agenten-Pipeline keine Frage der Antwortqualität. Es ist eine Frage der Zuverlässigkeit der strukturierten Ausgabe unter verschiedenen Bedingungen. Der Unterschied zwischen der ersten und der dritten Unterstützungsoption ist der Unterschied zwischen einem Agenten, der stabil funktioniert, und einem Agenten, der im zweiten Schritt ohne jegliches Log abbricht.

Wie Ollama Tools an das Modell übergibt: System-Prompt vs. Native Function Calling

Wenn du eine Anfrage an /api/chat mit einem Array von tools sendest – Ollama leitet dein JSON nicht einfach weiter. Es entscheidet, *wie genau* die Funktionsbeschreibung an das Modell übergeben wird. Und diese Entscheidung hängt davon ab, ob das Modell den nativen Weg unterstützt. Zwei verschiedene Wege – zwei verschiedene Ergebnisse.

Eine Analogie vor den Details

Stell dir vor, du gibst zwei Übersetzern eine Aufgabe. Dem ersten gibst du die Aufgabe in deiner Muttersprache – er versteht sofort, ohne Anstrengung, und antwortet genau im gewünschten Format. Dem zweiten gibst du die Aufgabe über einen Vermittler-Übersetzer, der die gesamte Anweisung in normalen Text umformuliert. Der zweite Übersetzer versucht es – aber der Vermittler hat vielleicht etwas vereinfacht, etwas falsch umformuliert. Das Ergebnis ist weniger vorhersehbar.

Der native Weg ist der erste Übersetzer. Der Prompt-Weg ist der zweite.

Der native Weg: Tools als Teil der Modellsprache

Modelle mit nativer Unterstützung haben spezielle Token in ihrer Architektur für die Beschreibung von Funktionen – genauso wie es Token für die Rollen user, assistant, system gibt. Während des Trainings hat das Modell tausende von Beispielen gesehen, bei denen diese Token in einem bestimmten Kontext erschienen und danach ein strukturierter Aufruf folgte.

Wenn Ollama eine Anfrage mit tools erhält und erkennt, dass das Modell den nativen Weg unterstützt – serialisiert es das JSON-Schema in diese speziellen Token und fügt sie an der richtigen Stelle in die Chat-Vorlage ein. Das Modell "liest" sie so natürlich, wie es Benutzernachrichten liest.

Ergebnis: Das Modell entscheidet selbst, wann es ein Tool aufruft (und entscheidet in den meisten Fällen richtig), gibt strukturierte tool_calls mit korrekten Argumenten zurück und benötigt keine zusätzlichen Hinweise im System-Prompt.

Schema des nativen Weges:

Deine Anfrage (tools + messages)
        ↓
    Ollama
        ↓ serialisiert tools in spezielle Modell-Token
[TOOL_DEF] get_weather(city: string) [/TOOL_DEF]
[USER] Wie ist das Wetter in Charkiw? [/USER]
        ↓
    Modell generiert:
[TOOL_CALL] {"name": "get_weather", "arguments": {"city": "Харків"}} [/TOOL_CALL]
        ↓
    Ollama parst → gibt strukturiertes tool_calls in der Antwort zurück

Der Prompt-Weg: Tools als Textanweisung

Wenn das Modell den nativen Weg nicht unterstützt – kann Ollama Tools nicht über spezielle Token übergeben (sie sind einfach nicht im Vokabular des Modells). Stattdessen konvertiert es die gesamte Funktionsbeschreibung in normalen Text und fügt sie zum System-Prompt hinzu.

Das Modell erhält etwas wie:

You have access to the following tools:

get_weather: Aktuelles Wetter für eine Stadt abrufen
Parameters:
  - city (string, required): Stadtname
  - units (string, optional): celsius oder fahrenheit

If you need to call a tool, respond with JSON in this format:
{"tool": "tool_name", "arguments": {...}}

[USER]: Wie ist das Wetter in Charkiw?

Jetzt versucht das Modell, der Textanweisung zu folgen. Das Problem ist, dass diese Anweisung nur Text unter anderem Text ist. Das Modell "weiß" nicht, dass von ihm ein strukturierter Aufruf auf Trainingsebene erwartet wird. Es generiert einfach das nächste Token basierend auf allem, was es sieht.

Daher kann das Ergebnis beliebig sein:

• Richtiges JSON im Feld content (aber nicht in tool_calls)
• JSON in einem ```json```-Block – Text, der manuell geparst werden muss
• Teilweises JSON ohne schließende Klammer
• Textantwort ohne jegliches JSON – das Modell hat entschieden, dass es "auch so verständlich" ist
• JSON mit Schlüsseln, die sich von denen unterscheiden, die du beschrieben hast ("tool_name" statt "name")

Schema des Prompt-Weges:

Deine Anfrage (tools + messages)
        ↓
    Ollama
        ↓ konvertiert tools in Textanweisung → fügt sie zum System-Prompt hinzu
"You have access to: get_weather(city)... respond with JSON..."
[USER] Wie ist das Wetter in Charkiw? [/USER]
        ↓
    Modell generiert Text (kann JSON sein, kann nicht)
        ↓
    Ollama gibt alles im content-Feld zurück – tool_calls ist leer oder fehlt

Wie man feststellt, welchen Weg dein Modell verwendet – ein Befehl

Ollama zeigt die Fähigkeiten jedes Modells über ollama show an. Das Vorhandensein von tools im Abschnitt ist ein Zeichen für native Unterstützung:

# Native Unterstützung – tools ist in capabilities vorhanden
ollama show llama3.1:8b

Model
  arch            llama
  parameters      8.0B
  context length  131072
  ...

Capabilities
  completion
  tools           ← vorhanden – Ollama verwendet den nativen Weg
  vision

# Prompt-Weg – tools fehlt
ollama show mistral-nemo:latest

Model
  arch            mistral
  parameters      12.2B
  context length  131072
  ...

Capabilities
  completion      ← tools fehlt – es gibt einen Fallback über den Prompt

Dies ist der erste Befehl, den du ausführen solltest, bevor du eine Agenten-Pipeline auf einem neuen Modell aufbaust. Wenn tools in den capabilities fehlt – verschwende keine Zeit mit dem Debugging von "warum ruft es nicht auf" – das Modell unterstützt es einfach nicht nativ.

Kann man den Prompt-Weg in der Produktion verwenden?

Technisch gesehen ja. Praktisch – mit großen Vorbehalten.

Der Prompt-Weg kann funktionieren, wenn:

• Du ein einziges einfaches Tool mit einem oder zwei Parametern hast
• Die Anfragen immer klar und kurz sind
• Du bereit bist, einen Parser für content anstelle von tool_calls zu schreiben und zu warten
• Ein Fehler nicht kritisch ist – der Agent kann es noch einmal versuchen

Aber wenn du mehrere Tools, komplexe Parameter, einen Multi-Step-Agenten oder eine Produktion hast, bei der jeder Fehler Geld und Kundenzeit kostet – wähle ein Modell mit nativer Unterstützung. Das ist keine Frage der Präferenz, sondern der Zuverlässigkeit.

Kurz gesagt: Überprüfe ollama show <model> vor dem Start. tools in capabilities vorhanden – nativer Weg, stabil. Fehlt – Prompt-Weg, unvorhersehbar. Die Wahl des Modells für einen Agenten beginnt mit dieser Überprüfung.

Modelle mit nativer Unterstützung: Wer ruft wirklich Tools auf

Unten sind Modelle aus meiner lokalen Sammlung und öffentlichen Daten, die nachweislich Tool-Aufrufe nativ über Ollama unterstützen, Stand Mai 2026. Für jedes Modell – nicht nur "unterstützt", sondern konkret: was es gut kann, wo es Einschränkungen hat und für welche Aufgaben es am besten geeignet ist.

Bevor du eines dieser Modelle ausprobierst – überprüfe die native Unterstützung: ollama show <model> und suche nach tools im Abschnitt Capabilities. Selbst innerhalb derselben Serie können verschiedene Versionen unterschiedlich sein.

Qwen3 (8b, 14b, 30b, 32b) – die stabilste Wahl im Jahr 2026

Qwen3 von Alibaba ist derzeit die stabilste Serie für Tool-Aufrufe unter den Modellen, die lokal laufen. Laut Morph LLM Benchmarks hat Qwen3 den niedrigsten Prozentsatz an "dropped tool calls" – das Modell ignoriert selten Tools oder gibt ungültiges JSON zurück.

Was macht Qwen3 besonders für Tool-Aufrufe:

• Thinking mode (think=True) – das Modell "denkt" zuerst in einem versteckten Block, dann generiert es den Aufruf. Dies erhöht die Genauigkeit bei komplexen Multi-Tool-Szenarien, bei denen das richtige Tool aus mehreren Optionen ausgewählt werden muss.
• Stabiles JSON – die Argumente in tool_calls sind fast immer gültig, die Typen entsprechen dem Schema.
• Große Auswahl an Größen – von 8B (5,2 GB, passt auf jeden modernen Mac) bis 32B für diejenigen mit leistungsstarker Hardware.

qwen3:8b – meine aktuelle Wahl für die lokale Entwicklung auf einem Mac M1 mit 16 GB. Läuft zusammen mit nomic-embed-text für RAG ohne Swapping auf die Festplatte.

ollama pull qwen3:8b    # 5,2 GB – für 8–16 GB RAM
ollama pull qwen3:14b   # ~9 GB – wenn höhere Genauigkeit benötigt wird
ollama pull qwen3:32b   # ~20 GB – für leistungsstarke Hardware

Wann Qwen3 wählen: Agenten mit mehreren Tools, RAG-Pipelines, bei denen zwischen searchDocuments / findDeadlines / extractContacts gewählt werden muss, jede Aufgabe, bei der die Stabilität des Aufrufs wichtig ist.

Einschränkungen: Der Thinking-Modus erhöht die Latenz der ersten Antwort um 1–3 Sekunden. Wenn maximale Geschwindigkeit benötigt wird – kann er über "think": false in der Anfrage deaktiviert werden.

Llama 3.1 / 3.2 / 3.3 / Llama 4 Scout – das breiteste Ökosystem

Llama 3.1 von Meta war eines der ersten breit verfügbaren Modelle mit nativem Tool-Aufruf – und seitdem bleibt die Serie ein Standard, bei dem es die meisten fertigen Beispiele, Tutorials und Framework-Unterstützung gibt.

llama3.1:8b (4,9 GB) – das am meisten "erforschte" Modell für Tool-Aufrufe: wenn du nach einem Integrationsbeispiel mit Spring AI, LangChain oder LlamaIndex suchst – in 90% der Fälle wird es genau auf llama3.1 sein. Laut Prompt Quorum ist Llama 4 Scout (MoE-Architektur, ~10 GB VRAM) die neueste Variante mit der breitesten Tool-Unterstützung in der Meta-Linie.

Hauptunterschied zwischen den Versionen der Serie:

ollama pull llama3.1:8b   # stabile Wahl, breite Framework-Unterstützung
ollama pull llama4:scout  # das Neueste, MoE-Architektur

Wann Llama wählen: Wenn du Spring AI, LangChain oder LlamaIndex verwendest und maximale fertige Beispiele möchtest. Llama 3.1 ist die sicherste Wahl für den Start.

Einschränkungen: llama3.1:8b ist in der Zuverlässigkeit von Multi-Tool-Aufrufen schlechter als qwen3:8b. Bei einfachen Single-Tool-Aufgaben ist der Unterschied unauffällig.

Gemma 4 (9b, 26b) – der zuverlässigste Tool-Aufruf in seiner Klasse

Google hat Gemma 4 von Anfang an mit nativem Function Calling entwickelt – es ist keine Feinabstimmung auf Basis des Basismodells, sondern eine architektonische Entscheidung. In der Praxis bedeutet dies weniger "dropped tool calls" und seltener ungültiges JSON im Vergleich zu Modellen, bei denen Tool-Aufrufe später hinzugefügt wurden.

gemma4:latest ist in meiner lokalen Sammlung (9,6 GB, vor 3 Wochen heruntergeladen). Aus meiner Erfahrung – die höchste Zuverlässigkeit unter den 8–10B-Modellen: In Tests mit 20 Anfragen mit zwei Tools gleichzeitig (searchDocuments und findDeadlines) gab es in ~90% der Fälle gültige tool_calls zurück, verglichen mit ~85% bei qwen3:8b.

Zusätzlicher Bonus – Vision-Unterstützung mit denselben Tools:

# Du kannst ein Bild übergeben UND ein Tool in einer Anfrage aufrufen
curl http://localhost:11434/api/chat \
  -d '{
    "model": "gemma4:latest",
    "messages": [{
      "role": "user",
      "content": "Was ist auf dem Scan des Dokuments abgebildet? Finde die Daten.",
      "images": ["<base64_image>"]
    }],
    "tools": [{ ... "findDeadlines" ... }]
  }'

ollama pull gemma4:latest   # 9,6 GB – Tool-Aufruf + Vision, 12+ GB RAM
ollama pull gemma4:26b      # 18 GB – maximale Qualität, 20+ GB RAM

Wann Gemma 4 wählen: Agenten, bei denen maximale Aufrufzuverlässigkeit erforderlich ist, multimodale Aufgaben (Dokumente + Bilder + Tools), Produktion, wo ein Fehler teuer ist.

Einschränkungen: 9,6 GB – größere Datei als qwen3:8b (5,2 GB) oder llama3.1:8b (4,9 GB). Auf einem Mac M1 mit 16 GB parallel zu nomic-embed-text ist bei langen Sitzungen möglicherweise Swapping möglich.

Qwen2.5 / Qwen2.5-Coder – vorherige Generation, immer noch aktuell

Qwen2.5 unterstützt Tool-Aufrufe nativ und es ist immer noch sinnvoll, ihn in Betracht zu ziehen, wenn Qwen3 aus irgendeinem Grund nicht passt. In meiner Sammlung gibt es qwen2.5-coder:1.5b-base – aber das ist ein Basismodell ohne Instruction Tuning. Ein Basismodell ist nicht darauf trainiert, Anweisungen zu folgen, es sagt nur den nächsten Token voraus. Für Tool-Aufrufe bedeutet dies: Das Modell "versteht" nicht, dass ein Funktionsaufruf von ihm erwartet wird – es setzt einfach den Text fort.

Wichtig: Für Tool-Aufrufe wird immer eine instruct-Version des Modells benötigt, nicht eine base-Version. Base – zum Fine-Tuning. Instruct – zur Verwendung. Wenn du -base im Namen siehst – das ist nicht das richtige Modell.

# Falsch für Tool-Aufrufe:
ollama pull qwen2.5-coder:1.5b-base   # base – nicht geeignet

# Richtig:
ollama pull qwen2.5:7b                # instruct-Variante
ollama pull qwen2.5-coder:7b          # instruct + Fokus auf Code

Wann Qwen2.5 wählen: Wenn Qwen3 nicht verfügbar ist oder eine spezifische Version mit Unterstützung für ein bestimmtes Framework benötigt wird. Qwen2.5-Coder:7b ist eine gute Wahl für Agenten, die mit Code arbeiten.

DeepSeek-R1 (7b, 14b, 32b) – für komplexe Reasoning-Aufgaben

DeepSeek-R1 unterstützt Tool-Aufrufe, aber mit einer architektonischen Besonderheit, die wichtig zu verstehen ist: Bevor es tool_calls zurückgibt, generiert das Modell Überlegungen in einem versteckten Block <think>...</think>.

So sieht es in der Antwort aus:

{
  "message": {
    "role": "assistant",
    "content": "<think>\nDer Benutzer fragt nach dem Wetter. Ich habe das Tool get_weather.\nIch muss city='Харків' übergeben. units ist nicht angegeben, ich verwende celsius als Standard.\n</think>",
    "tool_calls": [
      {
        "function": {
          "name": "get_weather",
          "arguments": { "city": "Харків", "units": "celsius" }
        }
      }
    ]
  }
}

Der <think>-Block ist die interne Überlegung des Modells. Dein Code muss ihn ignorieren und nur tool_calls lesen. Aber gerade wegen dieser Überlegung macht DeepSeek-R1 seltener Fehler bei der Auswahl von Argumenten und bewältigt besser mehrdeutige Anfragen, bei denen unklar ist, welches Tool aufgerufen werden soll.

Praktische Konsequenz für die Latenz:

ollama pull deepseek-r1:7b    # 4,5 GB – Balance zwischen Qualität und Geschwindigkeit
ollama pull deepseek-r1:14b   # ~9 GB – für komplexe Reasoning-Aufgaben

Wann DeepSeek-R1 wählen: Agenten, bei denen die Korrektheit der Tool-Auswahl wichtig ist, nicht die Geschwindigkeit. Zum Beispiel: juristische Dokumentenanalyse, bei der das Modell entscheiden muss, ob checkCompliance oder extractKeyFacts aufgerufen werden soll – und ein Fehler bei der Auswahl kostet.

Einschränkungen: Die Latenz des ersten Aufrufs ist 2-3 Mal höher als bei llama3.1:8b. Für Echtzeit-Chat-Agenten, bei denen die Reaktionsgeschwindigkeit wichtig ist – keine beste Wahl.

Aus persönlicher Erfahrung: Wie ich das Modell für AskYourDocs gewählt habe

Als ich die Agenten-Pipeline für AskYourDocs – einen RAG-Dienst, bei dem der Agent mehrere Tools aufrufen muss (searchDocuments, extractKeyFacts, findDeadlines, extractContacts, checkCompliance) – implementierte, durchlief ich mehrere Modelle, bevor ich mich für eine funktionierende Variante entschied.

Zuerst verband ich qwen3:8b über Spring AI 2.0.0-M3 und Ollama. Das Modell kam an und... antwortete mit Text. Kein tool_calls. Das Problem lag nicht am Modell – Spring AI 2.0.0-M3 hat Einschränkungen, wie Tools über ToolCallingChatOptions an Ollama übergeben werden. Das Modell erhielt die Tools einfach nicht im richtigen Format.

Nachdem ich das Übertragungsformat verstanden hatte – verglich ich mehrere Modelle bei demselben Satz von Testanfragen:

• qwen3:8b – nach Korrektur des Formats funktionierte es stabil. Der Denkmodus half bei komplexen Anfragen, bei denen zwischen mehreren Tools gewählt werden musste.
• llama3.1:8b – die einfachste Integration mit Spring AI, die meisten Beispiele in der Dokumentation des Frameworks.
• mistral-nemo – funktionierte nicht nativ, antwortete mit Text. Die Überprüfung über ollama show bestätigte: keine tools in den capabilities.

Im Ergebnis verwende ich für die lokale Entwicklung qwen3:8b, für die Produktion auf Railway – deepseek/deepseek-chat über OpenRouter (für normale Kunden) oder anthropic/claude-3.5-sonnet (für juristische Kunden, wo Genauigkeit wichtig ist). Ein lokales Modell für die Entwicklung und ein Cloud-Modell für die Produktion – das ist eine Standardpraxis, wenn die Hardware auf dem Server keine großen Modelle lokal bewältigt.

Modelle, die „so tun als ob“: antworten mit Text statt JSON

Wenn der vorherige Abschnitt von denen handelt, die tatsächlich Tools aufrufen, dann handelt dieser von denen, die das nicht tun, aber auch keinen Fehler zurückgeben. HTTP 200, Text in content, leere tool_calls. Genau diese Modelle nehmen beim Debugging die meiste Zeit in Anspruch – denn äußerlich sieht alles normal aus.

Wichtig: Das bedeutet nicht, dass diese Modelle schlecht sind. Sie sind einfach nicht für Agenten-Pipelines gedacht. Jedes hat seine eigene Stärke – und die liegt nicht hier.

Mistral Nemo – ein ausgezeichneter Textassistent, kein Agent

mistral-nemo:latest ist in meiner lokalen Sammlung (7,1 GB). Ein Test liefert sofort eine Antwort:

ollama show mistral-nemo:latest

Capabilities
  completion    ← tools fehlt

Mistral Nemo hat kein natives Tool-Calling. Ollama verwendet einen Prompt-Pfad – serialisiert die Funktionsbeschreibung in den Text des System-Prompts. Das Ergebnis ist unvorhersehbar: bei etwa 30 % der Testanfragen gab das Modell JSON in einem Textblock ```json...``` innerhalb von content zurück, bei den restlichen antwortete es einfach mit Text, als ob die Tools nicht existieren würden.

Wo Mistral Nemo wirklich stark ist: Zusammenfassen langer Dokumente, Übersetzung, Textschreiben, Fragen und Antworten ohne externe Aufrufe. 12,2B Parameter in 7,1 GB – eine gute Größe/Qualität für diese Aufgaben. Nur nicht für Agenten.

Phi-4 – Analytik ja, Agenten nein

Phi-4 von Microsoft ist ein kompaktes Modell (9,1 GB, 16K Kontext) mit starken Leistungen bei STEM- und analytischen Aufgaben. Laut Computing for Geeks belegt Phi-4 hohe Plätze in Benchmarks für Mathematik und Reasoning – ist aber eindeutig schwach bei Tool-Calling und Long-Context-Retrieval.

Der Grund ist technisch: Phi-4 ist für dichtes Wissen pro Parameter optimiert, nicht für Instruction Following im Format von Function Calling. Das Modell „versteht“ die Aufgabe, gibt aber keinen strukturierten Aufruf stabil zurück.

Faustregel: Wenn ein lokaler analytischer Assistent für numerische Daten, Berichte oder mathematische Aufgaben ohne externe APIs benötigt wird – Phi-4 ist eine ausgezeichnete Wahl. Wenn ein Agent benötigt wird, der Tools aufruft – suchen Sie weiter.

Gemma 3 – nicht mit Gemma 4 verwechseln

Das ist ein häufiger Fehler: Jemand liest, dass „Gemma Tool-Calling unterstützt“, installiert gemma3:9b – und erhält Text statt tool_calls. Der Grund ist einfach: natives Tool-Calling erschien in Gemma 4, nicht in Gemma 3.

ollama show gemma3:9b
Capabilities
  completion
  vision        ← tool calling fehlt

ollama show gemma4:9b
Capabilities
  completion
  tools         ← vorhanden – native Unterstützung
  vision

Zwischen den Generationen gibt es einen prinzipiellen Unterschied in der Lernarchitektur. Wenn Sie gemma3:* installiert haben und einen Agenten bauen – aktualisieren Sie auf gemma4. Wenn Sie nicht aktualisieren können (RAM- oder Festplattenbeschränkungen) – erwägen Sie llama3.1:8b oder qwen3:8b als Alternative gleicher Größe.

Alte Code-Modelle – CodeLlama, StarCoder2, CodeGemma

Diese Modelle wurden für Code Completion entwickelt – die Vorhersage der nächsten Codezeile in einer Datei. Das ist eine fundamental andere Aufgabe als Instruction Following oder Tool-Calling.

Ein Code-Completion-Modell sieht unvollständigen Code und setzt ihn fort. Tool-Calling erfordert: eine Anfrage in natürlicher Sprache verstehen → entscheiden, welches Tool aufgerufen werden soll → ein JSON mit Argumenten erstellen. Diese Modelle wurden nicht für diesen Weg trainiert.

Im Jahr 2026 wichen sie spezialisierten Instruct-Modellen: qwen2.5-coder:7b für Code und kimi-k2.6 für komplexe Agentenaufgaben. CodeLlama und StarCoder2 sind Relikte aus dem Jahr 2023, nützlich für eng definierte Aufgaben der Autovervollständigung, aber nicht für Agenten.

Wie man jedes neue Modell schnell überprüft

Bevor Sie Zeit mit der Integration verschwenden – zwei Überprüfungsschritte:

Schritt 1 – Capabilities:

ollama show <model> | grep tools
# Wenn nichts ausgegeben wird – keine Tools, Prompt-Pfad

Schritt 2 – Live-Test über curl (1 Minute):

curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<your-model>",
    "messages": [{"role": "user", "content": "Яка погода у Києві?"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Отримати поточну погоду для будь-якого міста",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "Назва міста"}
          },
          "required": ["city"]
        }
      }
    }],
    "stream": false
  }' | python3 -m json.tool | grep -A5 "tool_calls"

Wenn in der Ausgabe tool_calls mit korrektem name und arguments vorhanden ist – das Modell ist geeignet. Wenn die Ausgabe leer ist oder tool_calls fehlt – prüfen Sie die Capabilities und steigen Sie zum nächsten Modell in der Liste in Abschnitt 3 auf.

Benchmark: Zuverlässigkeit, Geschwindigkeit des ersten Tool-Calls, Multi-Tool

Die Dokumentation sagt „unterstützt“. Aber wie oft von 10 gibt das Modell tatsächlich ein valides tool_calls zurück? Wie viele Sekunden vergehen bis zum ersten Token? Kann das Modell zwei Tools parallel aufrufen – oder nur eines nach dem anderen? Genau diese drei Parameter bestimmen, ob ein Modell für eine Agenten-Pipeline unter realen Bedingungen geeignet ist, nicht in einer Test-Curl-Anfrage.

Was und wie wurde gemessen

Der Benchmark ist hybrid: persönliche Tests auf einem Mac M1 mit 16 GB mit Modellen aus meiner aktuellen Sammlung (ollama list), ergänzt durch öffentliche Daten von Morph LLM und Computing for Geeks (RTX 4090, Ollama 0.23.1, Mai 2026).

Drei Parameter, die für Agenten wichtig sind:

1. Zuverlässigkeit des Tool-Calls – Prozentsatz der Anfragen, bei denen das Modell ein valides tool_calls mit korrekten Argumenten zurückgab, anstatt Text in content. Gemessen an 20 gleichartigen Anfragen mit demselben Satz von Tools. Warum 20, nicht 100: Für die lokale Entwicklung reichen 20 Anfragen aus, um das systemische Verhalten zu erkennen. 100 % bei 5 Anfragen bedeuten nichts – schauen Sie auf 20.

2. Zeit bis zum ersten Token in tool_calls (TTFT) – wie viele Sekunden vergehen von der Absendung der Anfrage bis zum Erscheinen des ersten Bytes der strukturierten Antwort. Für Streaming – Zeit bis zum ersten Token überhaupt. Für einen Agenten, der auf das Ergebnis eines Tools vor dem nächsten Schritt wartet – ist dies eine direkte UX-Verzögerung.

3. Multi-Tool (paralleler Aufruf) – ob das Modell in einer Anfrage mehrere tool_calls gleichzeitig zurückgeben kann. Zum Beispiel: „Finde Dokumente zur Miete UND extrahiere die Schlüsseldaten“ – idealerweise sollte dies sowohl searchDocuments als auch findDeadlines in einer Antwort auslösen. Wenn das Modell Multi-Tool nicht unterstützt – ruft es diese sequenziell auf oder ignoriert einen der Anfragen.

Test auf Mac M1 16 GB – persönlich

Testanfrage: „Finde Dokumente zur Miete und extrahiere die Schlüsseldaten“ mit zwei Tools: searchDocuments (Suche in Dokumenten) und findDeadlines (Suche nach Daten und Fristen). Beide Tools sind in meinem realen Projekt AskYourDocs vorhanden – daher ist die Anfrage nicht synthetisch, es ist ein reales Agentenszenario.

Bedingungen: Ollama lokal gestartet, Modelle vor dem Test in den RAM geladen (um Cold-Starts auszuschließen), stream: false, Standardtemperatur.

Die Zuverlässigkeitsangaben in Prozent sind ungefähre Schätzungen basierend auf 20 Anfragen pro Modell. Die tatsächlichen Werte hängen von drei Faktoren ab: der Genauigkeit der Anfrageformulierung, der Qualität der description im JSON-Schema der Funktion und der Ollama-Version. Eine schlecht geschriebene description kann die Zuverlässigkeit selbst des besten Modells um 20–30 % reduzieren.

Was die Zuverlässigkeit wirklich beeinflusst – nicht nur das Modell

Während der Tests habe ich bemerkt: dasselbe Modell kann bei einer klaren Anfrage 90 % Zuverlässigkeit und bei einer vagen 60 % erzielen. Das Modell ist nur die halbe Gleichung. Die andere Hälfte ist die Qualität der Funktionsbeschreibung.

Vergleichen Sie zwei Beschreibungen desselben Tools:

// Schlechte Beschreibung – das Modell ignoriert das Tool oft
{
  "name": "searchDocuments",
  "description": "Search documents",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string"}
    }
  }
}

// Gute Beschreibung – das Modell ruft stabil auf
{
  "name": "searchDocuments",
  "description": "Sucht relevante Dokumente in der Wissensdatenbank anhand einer Textanfrage. Rufen Sie dieses Tool IMMER auf, wenn der Benutzer nach Dokumenten, Verträgen, Bedingungen oder beliebigen Informationen aus der Datenbank fragt.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Textanfrage für die Suche. Zum Beispiel: 'Mietbedingungen', 'Zahlungsdaten', 'Verantwortlichkeiten der Parteien'"
      },
      "topK": {
        "type": "integer",
        "description": "Anzahl der Ergebnisse. Standardmäßig 5."
      }
    },
    "required": ["query"]
  }
}

Der Unterschied in der Zuverlässigkeit bei qwen3:8b zwischen diesen beiden Beschreibungen beträgt etwa 20–25 Prozentpunkte bei demselben Satz von Anfragen. Bevor Sie das Modell beschuldigen – überprüfen Sie Ihre description.

Öffentliche Daten: RTX 4090 (Morph LLM + Computing for Geeks, Mai 2026)

Für diejenigen, die eine leistungsstarke GPU haben oder eine Serverbereitstellung planen – unten die Daten auf einer RTX 4090 (24 GB VRAM, CUDA 12.6). Tokens/sec – Geschwindigkeit der Antwortgenerierung nach dem ersten Token. VRAM – Bedarf bei Q4_K_M-Quantisierung und Standard-Kontextgröße.

Beachten Sie gemma4:26b MoE: insgesamt 26B Parameter, aber nur 4B aktiv pro Token. Daher ist die Geschwindigkeit (~55 tok/s) höher als bei dichten 32B-Modellen, und der VRAM-Bedarf ist geringer. MoE-Architektur ist kein „kleines Modell“, sondern eine intelligente Verteilung der Berechnungen.

Schlussfolgerung des Benchmarks

Für die lokale Entwicklung (8–16 GB RAM, Apple Silicon oder mittlerer Laptop): llama3.1:8b wenn Geschwindigkeit wichtig ist, gemma4:latest wenn Zuverlässigkeit wichtig ist, qwen3:8b – der goldene Mittelweg.

Für einen GPU-Server mit 20–24 GB VRAM: gemma4:26b – die beste Option für Produktionsagenten. Die MoE-Architektur liefert die Qualität von 26B bei deutlich geringerem Ressourcenverbrauch.

Und denken Sie daran: 10–15 % Zuverlässigkeitssteigerung können Sie einfach durch Verbesserung der description im JSON-Schema erzielen – ohne das Modell zu ändern.

Vergleichstabelle: Modell / Größe / Zuverlässigkeit / RAM

Zusammenfassende Tabelle aller im Artikel erwähnten Modelle. Gedacht als schneller Nachschlagehilfe – damit Sie nicht wieder durch den Text scrollen müssen, wenn Sie ein Modell für spezifische Hardware und Aufgaben auswählen müssen.

Zuverlässigkeitskennzeichnung für Tool Calling: ✅ Nativ – stabil 75%+, strukturierte tool_calls in der Antwort. ⚠️ Teilweise / Prompt – instabil, weniger als 50%, JSON kann in content erscheinen. ❌ Abwesend – das Modell gibt unter Standardbedingungen keine tool_calls zurück.

So lesen Sie die Tabelle für Ihre Hardware

Mac / Laptop 8 GB RAM:

• Start: llama3.1:8b oder qwen3:8b
• Zusammen mit RAG (nomic-embed-text): qwen3:8b – beide passen ohne Swap
• Vermeiden Sie: gemma4:9b (benötigt 12 GB), llama4:scout (~10 GB)

Mehr darüber, was genau auf 8 GB läuft und wie Ollama konfiguriert wird, um nicht zu swappen – in einem separaten Artikel: Ollama auf 8 GB RAM: Welche Modelle funktionieren im Jahr 2026 .

Mac M1/M2/M3 16 GB:

• Optimal für Tool Calling: gemma4:9b (~90% Zuverlässigkeit) oder qwen3:8b (~85%)
• Mit RAG parallel: qwen3:8b + nomic-embed-text – ohne Swap (5.2 + 0.27 GB)
• Wenn höhere Genauigkeit benötigt wird: qwen3:14b (~9 GB) – funktioniert, aber knapp. Mit RAG ist Swap möglich.
• Vermeiden Sie: gemma4:26b (18 GB) und llama3.3:70b – passen nicht

GPU-Server 20–24 GB VRAM (RTX 3090 / 4090):

• Produktionsagent: gemma4:26b – ~93% Zuverlässigkeit beim Tool Calling, ~55 tok/s dank MoE
• Agent mit Fokus auf Code: qwen2.5-coder:32b (~20 GB, das stärkste lokale Coding-Modell im Jahr 2026)
• Wenn die Hardware 20 GB hat und ein Puffer übrig bleiben soll: qwen3:14b + RAG-Modell parallel

GPU-Server 40+ GB VRAM:

• Maximale Qualität: llama3.3:70b (~43 GB bei Q4_K_M)
• Aber beachten Sie: ~18 tok/s auf RTX 4090 – für Echtzeit-Chats möglicherweise zu langsam. Für Batch-Dokumentenverarbeitung – akzeptabel.
• Alternative: zwei Instanzen von gemma4:26b (~36 GB zusammen) mit Lastverteilung – höhere Durchsatz als ein einzelnes 70B

Wenn Sie sich bei Ihrer Hardware nicht sicher sind – führen Sie ollama ps nach dem Laden des Modells aus und überprüfen Sie das Feld size_vram. Wenn der Wert kleiner ist als die Modellgröße – ein Teil wird in den Systemspeicher geladen und das Modell swappt. Für einen Tool-Calling-Agenten bedeutet Swap eine Latenz von 5–15 Sekunden anstelle von 1–2 Sekunden für den ersten Aufruf.

Größenempfehlungen: 3B / 7–8B / 14B+ – Wo liegt die Qualitätsgrenze

Die Modellgröße ist nicht der einzige Faktor für die Zuverlässigkeit des Tool Callings, aber sie setzt die Obergrenze. Selbst eine perfekt geschriebene description wird ein 3B-Modell nicht auf das Niveau eines 14B-Modells in einem komplexen Multi-Tool-Szenario bringen. Unten – wo die praktische Grenze liegt und wie ich dazu gekommen bin.

Bis zu 4B: für Edge und Tests, nicht für die Produktion

Kleine Modelle (1–4B) können technisch tool_calls zurückgeben – aber ihre Fähigkeit, JSON-Schema korrekt zu interpretieren, ist begrenzt. Was konkret kaputt geht:

• Die Funktionsbeschreibung ist länger als 2–3 Zeilen – das Modell „liest nicht weiter“ und überspringt Parameter
• Mehrere Tools in der Anfrage – das Modell wählt das erste und ignoriert den Rest
• Ungewöhnliche Formulierung der Anfrage – das Modell antwortet mit Text anstelle eines Aufrufs
• Parameter mit komplexen Typen (enum, verschachteltes Objekt) – gibt oft ungültiges JSON zurück

Die einzige sinnvolle Ausnahme im Jahr 2026 ist gemma4:2b (E2B-Variante von Google). Dies ist das einzige Sub-4B-Modell, das Tools dank nativer Funktionsaufrufunterstützung in der Architektur mehr oder weniger zuverlässig aufruft. Aber „mehr oder weniger“ ist immer noch nicht produktionsreif. Für Edge-Geräte oder MVPs, bei denen ein Ausfall nicht kritisch ist – ok. Für einen echten Agenten – nein.

Wenn Sie nur 4–6 GB RAM haben und Tool Calling ausprobieren möchten – llama3.2:3b oder gemma4:2b geben Ihnen ein Gefühl für die Mechanik. Aber bauen Sie kein Produkt darauf auf.

7–8B: Die „goldene Mitte“ für die lokale Bereitstellung

Das ist mein Arbeitsbereich. Auf einem Mac M1 mit 16 GB RAM entwickle ich eine Agenten-Pipeline für AskYourDocs genau mit qwen3:8b (5.2 GB) und nomic-embed-text (274 MB) parallel – beide Modelle gleichzeitig im RAM, ohne Swap auf die Festplatte.

Warum 7–8B die praktische Grenze für die meisten Aufgaben ist:

• Passen in 6–8 GB VRAM oder 8–16 GB System-RAM
• Bieten 70–85% Zuverlässigkeit beim Tool Calling bei typischen Geschäftsanfragen
• Laufen auf den meisten modernen Laptops und MacBooks ohne zusätzliche Hardware
• Single-Tool und grundlegendes Multi-Tool – stabil. Komplexe 3+ Tool-Ketten – schon schlechter.

qwen3:8b und llama3.1:8b – die Standardwahl für diese Klasse. Wenn Sie zwischen ihnen wählen müssen: llama3.1:8b, wenn Kompatibilität mit Spring AI / LangChain und schnelle TTFT wichtig sind. qwen3:8b, wenn höhere Zuverlässigkeit wichtig ist und Sie Zeit für die Konfiguration des Denkmodus haben.

Kritische Warnung vor Swap: Wenn das Modell nicht in den RAM passt und anfängt zu swappen, sinkt die Generierungsgeschwindigkeit von 15–25 tok/s auf 1–3 tok/s. Für einen Agenten bedeutet dies 10–30 Sekunden pro Tool-Aufruf anstelle von 1–2. In der Praxis macht dies den Agenten ungeeignet für Echtzeit-Interaktionen. Überprüfen Sie nach dem Laden:

ollama ps
# NAME          SIZE    PROCESSOR    UNTIL
# qwen3:8b      5.5GB   100% GPU     4 minutes from now
#                       ↑ wenn hier CPU oder teilweise CPU – das Modell swappt

14B+: für komplexe Agenten und Produktion

Wenn 8B 80–85% Zuverlässigkeit bietet – lohnt es sich, auf 14B umzusteigen? Das hängt von der Aufgabe ab. Hier ist der Unterschied spürbar:

qwen3:14b (~9 GB) – der optimale Schritt nach oben von 8B: höhere Genauigkeit bei moderater Größensteigerung. gemma4:26b (MoE, 4B aktive Parameter pro Token) – die beste Wahl, wenn 20+ GB VRAM vorhanden sind: 26B-Qualität bei deutlich geringerem Ressourcenverbrauch als bei dichten 26B-Modellen.

In meinem Produktions-Stack für AskYourDocs verwende ich keine lokalen Modelle auf dem Server – Railway bietet keine GPUs. Für die Produktion verwende ich OpenRouter: deepseek/deepseek-chat für Standardkunden und anthropic/claude-3.5-sonnet für juristische Kunden, wo maximale Genauigkeit bei der Arbeit mit Dokumenten erforderlich ist. Lokales Ollama – nur für die Entwicklung und das Testen neuer Tools vor dem Deployment. Das ist eine ehrliche Antwort auf die Frage „Was soll man in der Produktion verwenden?“.

Praktische Regel: Auswahlalgorithmus

Anstelle allgemeiner Empfehlungen – ein konkreter Algorithmus, den ich verwende:

1. Beginnen Sie mit llama3.1:8b oder qwen3:8b, abhängig von der Hardware.
2. Führen Sie 20 Testanfragen mit Ihrem tatsächlichen Tool-Set aus.
3. Zählen Sie, wie oft ein gültiger tool_calls empfangen wurde.
4. Wenn weniger als 80% – schreiben Sie zuerst die description der Funktionen neu. Wiederholen Sie den Test.
5. Wenn nach der Verbesserung der Beschreibung immer noch weniger als 80% – wechseln Sie zu 14B.
6. Wenn auch 14B bei komplexen Multi-Step-Szenarien instabil ist – erwägen Sie ein Cloud-Modell für die Produktion.

Aus meiner Erfahrung: In der Hälfte der Fälle, in denen „das Modell keine Tools aufruft“ – liegt das Problem an einer schlechten description und nicht an der Modellgröße. Die Korrektur der Funktionsbeschreibung ist günstiger als der Wechsel zu einem größeren Modell. Prüfen Sie dies zuerst.

Typische Fehler und wie man sie diagnostiziert

Die meisten Fehler beim Tool Calling sehen gleich aus: HTTP 200, leere tool_calls und Stille in den Logs. Unten – sieben konkrete Szenarien, die ich persönlich erlebt habe oder die regelmäßig in den GitHub Issues von Ollama auftauchen. Für jedes – Diagnose und Lösung.

Fehler 1. Das Modell ignoriert Tools und antwortet mit Text

Wie es aussieht: Sie senden eine Anfrage mit tools und erhalten eine normale Textantwort. tool_calls in der Antwort fehlt oder ist ein leeres Array.

Drei Gründe in absteigender Häufigkeit:

1. Das Modell unterstützt Tool Calling nicht nativ – überprüfen Sie ollama show <model>, suchen Sie nach tools in Capabilities
2. Die Funktionsbeschreibung (description) ist unklar – das Modell versteht nicht, wann es aufgerufen werden soll
3. Das Framework (Spring AI, LangChain) übergibt Tools nicht im richtigen Format an Ollama

Diagnose – isolieren Sie das Framework: Testen Sie direkt über curl. Wenn curl tool_calls zurückgibt – liegt das Problem im Framework. Wenn nicht – liegt das Problem am Modell oder der Funktionsbeschreibung.

curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "Wie ist das Wetter in Charkiw?"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Holen Sie sich das aktuelle Wetter für jede Stadt. Rufen Sie dieses Tool IMMER auf, wenn nach dem Wetter gefragt wird.",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "Name der Stadt"}
          },
          "required": ["city"]
        }
      }
    }],
    "stream": false
  }' | python3 -m json.tool

Fehler 2. Das Modell gibt JSON in einem Textblock anstelle von tool_calls zurück

Wie es aussieht:

{
  "message": {
    "role": "assistant",
    "content": "```json\n{\"tool\": \"get_weather\", \"city\": \"Харків\"}\n```"
  }
  // tool_calls – fehlt
}

Das ist der Prompt-Pfad in Aktion (Abschnitt 2). Ollama konnte die Tools nicht über native Token übergeben und hat sie als Text in den System-Prompt eingefügt. Das Modell hat „so gut es ging“ geantwortet – versucht, das Format aus der Anleitung zu wiederholen.

Warum content nicht manuell parsen: Das Format ist unvorhersehbar. Manchmal ```json```, manchmal nur {...}, manchmal heißen die Schlüssel anders ("tool" statt "name"). Jeder Parser wird fehleranfällig sein.

Lösung: Ersetzen Sie das Modell durch eines, das tools in Capabilities hat. Das ist die einzige zuverlässige Lösung.

Fehler 3. Ungültiges oder unvollständiges JSON in Argumenten

Wie es aussieht: tool_calls ist vorhanden, aber die Argumente sind nicht das, was Sie erwarten: obligatorische Felder fehlen, falscher Typ oder null, wo ein Wert sein sollte.

Die häufigste Ursache – minimale Parameterbeschreibung:

// ❌ Schlecht – das Modell weiß nicht, was es übergeben soll
"parameters": {
  "type": "object",
  "properties": {
    "city": {"type": "string"}
  }
}

// ✅ Gut – detaillierte Beschreibung mit Beispiel und required
"parameters": {
  "type": "object",
  "properties": {
    "city": {
      "type": "string",
      "description": "Name der Stadt auf Ukrainisch oder Englisch. Zum Beispiel: 'Харків' oder 'Kharkiv'"
    },
    "units": {
      "type": "string",
      "enum": ["celsius", "fahrenheit"],
      "description": "Temperatureinheiten. Standardmäßig Celsius."
    }
  },
  "required": ["city"]
}

Das Feld required ist nicht optional. Ohne es kann das Modell entscheiden, dass alle Parameter optional sind und keine übergeben. Auch wenn es logisch ist, dass city benötigt wird – geben Sie dies explizit im Schema an.

Fehler 4. Endlosschleife – das Modell ruft immer wieder dasselbe Tool auf

Wie es aussieht: Der Agent ruft searchDocuments auf, erhält das Ergebnis und… ruft erneut searchDocuments mit derselben Anfrage auf. Und wieder. Und wieder. Ohne Unterbrechung.

Ursache: Das Modell hat kein klares Signal erhalten, dass die Aufgabe gelöst ist. Es sieht das Tool-Ergebnis in den Nachrichten, versteht aber nicht, dass jetzt eine endgültige Antwort gegeben werden muss – und generiert weiterhin den nächsten Schritt.

Zwei Lösungen:

1. System-Prompt mit expliziter Anweisung:

Sie sind ein Agent, der Benutzerfragen beantwortet.
Sie haben Zugriff auf Tools zur Informationssuche.

Regeln:
- Rufen Sie ein Tool nur auf, wenn externe Informationen benötigt werden
- Geben Sie nach Erhalt des Tool-Ergebnisses sofort die endgültige Antwort
- Rufen Sie nicht dasselbe Tool zweimal im selben Dialog auf
- Wenn Sie ein Ergebnis erhalten haben – machen Sie KEINE zusätzlichen Aufrufe, antworten Sie sofort

2. Schrittlimit auf Code-Ebene (zuverlässiger):

// Java: Schutz vor Endlosschleife
int maxSteps = 5;
int step = 0;

while (step < maxSteps) {
    var response = callOllama(messages);
    var toolCalls = response.getMessage().getToolCalls();

    if (toolCalls == null || toolCalls.isEmpty()) {
        // Das Modell hat die endgültige Antwort gegeben – wir beenden
        return response.getMessage().getContent();
    }

    // Führen Sie die Tool-Aufrufe aus und fügen Sie die Ergebnisse zu den Nachrichten hinzu
    executeToolCalls(toolCalls, messages);
    step++;
}

// Wenn das Limit erreicht ist – geben Sie zurück, was vorhanden ist
log.warn("Agent reached max steps limit: {}", maxSteps);
return "Konnte nicht innerhalb der zugewiesenen Schritte abgeschlossen werden.";

Fehler 5. Tool Calling funktioniert nicht in Spring AI 2.0.0-M3 mit Ollama – mein persönlicher

Das ist dieselbe Situation, die ich in Abschnitt 3 beschrieben habe: Ich habe qwen3:8b über Spring AI verbunden und das Modell hat einfach Text geantwortet. Curl gab das richtige tool_calls zurück – also unterstützt das Modell es. Das Problem lag bei Spring AI.

Konkret: Spring AI 2.0.0-M3 hat eine bekannte Einschränkung – ToolCallingChatOptions serialisiert Tools nicht immer korrekt in das Format, das Ollama für native Aufrufe erwartet. Einige Konfigurationen übergaben Tools in einem Format, das spezifisch für OpenAI war, und nicht für Ollama – und Ollama ignorierte sie stillschweigend oder wechselte zum Prompt-Pfad.

Was geholfen hat:

// ❌ Funktioniert nicht immer mit Ollama
ToolCallingChatOptions options = ToolCallingChatOptions.builder()
    .toolCallbacks(toolCallbacks)
    .build();

// ✅ Übergeben Sie Tools über den Standard-Prompt
List<Message> messages = buildMessages(question);
Prompt prompt = new Prompt(messages,
    OllamaChatOptions.builder()
        .model("qwen3:8b")
        .build()
);
// Registrieren Sie Tools über die @Tool-Annotation bei Methoden,
// nicht über ToolCallingChatOptions

Fehler 6. Das Modell „erfindet“ Argumente, die nicht vorhanden sind (halluzinierte Argumente)

Wie es aussieht: tool_calls ist vorhanden, Argumente sind vorhanden, aber die Werte entsprechen nicht der Anfrage. Zum Beispiel fragt der Benutzer nach Charkiw – und das Modell übergibt "city": "Kyiv". Oder es übergibt "date": "2024-01-01", obwohl kein Datum in der Anfrage vorhanden war.

Ursache: Ein kleines Modell (bis 8B) füllt bei mehrdeutigen Anfragen fehlende Argumente mit seinen Vermutungen auf, anstatt entweder den Benutzer zu fragen oder einen leeren Wert zu übergeben.

Lösung – drei Ansätze:

• Argumentvalidierung vor der Ausführung: Überprüfen Sie, ob die erhaltenen Argumente logisch zur Benutzeranfrage passen, bevor Sie sie an die tatsächliche Funktion übergeben.
• Obligatorische Felder mit Enum: Wenn ein Parameter eine begrenzte Anzahl von Werten hat – geben Sie immer "enum": [...] an. Das Modell erfindet seltener Werte, wenn es eine erlaubte Liste sieht.
• Wechsel zu 14B: Halluzinierte Argumente sind eines der Hauptsymptome, bei denen 14B deutlich besser ist als 8B.

Fehler 7. Kaltstart – die erste Anfrage dauert 10–30 Sekunden

Wie es aussieht: Die erste Anfrage nach dem Start von Ollama oder nach einer längeren Pause dauert um ein Vielfaches länger als die folgenden. Der Agent „hängt“ beim ersten Schritt.

Ursache: Das Modell wurde aus dem RAM entladen (standardmäßig 5 Minuten nach der letzten Anfrage) und wird nun erneut geladen – dies dauert 5–15 Sekunden, abhängig von der Modellgröße und der Festplattengeschwindigkeit.

Lösung – keep_alive:

// Bei jeder Anfrage – das Modell 30 Minuten im RAM halten
{
  "model": "qwen3:8b",
  "messages": [...],
  "tools": [...],
  "keep_alive": "30m"   // oder -1, um es dauerhaft zu halten
}

// Oder global über Umgebungsvariable:
// OLLAMA_KEEP_ALIVE=30m ollama serve

Für eine Agenten-Pipeline, bei der Anfragen gebündelt eintreffen – ist "keep_alive": "30m" die Standardlösung. Für einzelne Anfragen oder Batch-Aufgaben, bei denen RAM wichtig ist – "keep_alive": 0 entlädt das Modell sofort nach der Antwort.

Schnelle Diagnosetabelle

Welches ist das zuverlässigste Modell für Tool Calling auf einem Mac mit 16 GB RAM?

Es hängt davon ab, was wichtiger ist – Zuverlässigkeit oder die Möglichkeit, RAG parallel auszuführen.

Wenn nur ein Agent ohne RAG: gemma4:latest (9.6 GB) – höchste Zuverlässigkeit in seiner Klasse (~90% bei 20 Testanfragen). Google hat Gemma 4 von Anfang an mit nativem Funktionsaufruf entwickelt, daher funktioniert Multi-Tool stabiler als bei Konkurrenten gleicher Größe.

Wenn Agent + RAG parallel: qwen3:8b (5.2 GB) + nomic-embed-text (274 MB) – beide passen ohne Swap auf M1 16 GB (zusammen ~5.5 GB, Puffer bleibt übrig). Zuverlässigkeit ~85% – etwas niedriger als Gemma 4, aber für die meisten Geschäftsanforderungen ausreichend.

Ich persönlich verwende genau diese Kombination für die lokale Entwicklung von AskYourDocs: qwen3:8b als Agent und nomic-embed-text für Embeddings. Beide sind ständig im RAM, ohne Kaltstart zwischen den Anfragen.

Wenn höhere Genauigkeit benötigt wird und RAM ausreicht: qwen3:14b (~9 GB) – aber dann wird das parallele Ausführen eines RAG-Modells knapp, Swap ist möglich.

Wie überprüfe ich, ob ein Modell Tool Calling nativ unterstützt?

Ein Schritt – ollama show:

ollama show qwen3:8b

# Model
#   arch            qwen3
#   parameters      8.2B
#   context length  40960
#
# Capabilities
#   completion
#   tools           ← vorhanden – native Unterstützung
#   thinking

ollama show mistral-nemo:latest

# Capabilities
#   completion      ← tools fehlt – Prompt-Pfad, unzuverlässig

Wenn Sie sofort mehrere Modelle aus Ihrer Sammlung überprüfen möchten:

# Alle installierten Modelle auf Tool Calling-Unterstützung prüfen
ollama list | awk 'NR>1 {print $1}' | while read model; do
  result=$(ollama show "$model" 2>/dev/null | grep -c "tools")
  if [ "$result" -gt 0 ]; then
    echo "✅ $model – Tools werden unterstützt"
  else
    echo "❌ $model – Tools fehlen"
  fi
done

Danach – ein Live-Test über curl (1 Minute), um dies in der Praxis zu bestätigen. Details in Abschnitt 4.

Kann man ein Modell ohne natives Tool Calling trotzdem Tools aufrufen lassen?

Technisch – ja. Ein detaillierter System-Prompt, in dem Sie das JSON-Schema beschreiben und um eine Antwort in einer klaren Struktur bitten, funktioniert manchmal:

system: """
Wenn externe Informationen benötigt werden – antworten Sie NUR im Format:
{"tool": "funktionsname", "arguments": {"parameter": "wert"}}
Verfügbare Funktionen: get_weather(city: string), get_rate(currency: string)
Schreiben Sie nichts anderes – nur JSON.
"""

In der Praxis – instabil. Aus meiner Erfahrung mit mistral-nemo: in ~30% der Anfragen gab das Modell etwas zurück, das wie JSON in content aussah. Aber das Format konnte von Anfrage zu Anfrage variieren, Schlüssel hießen manchmal anders als beschrieben, manchmal kam unvollständiges JSON. Ein Parser dafür ist schwieriger zu warten als einfach das Modell zu ersetzen.

Wann der Prompt-Ansatz gerechtfertigt ist: Wenn Sie ein einzelnes einfaches Tool haben, klare Anfragen und ein MVP, bei dem die Entwicklungsgeschwindigkeit wichtiger ist als die Zuverlässigkeit. Für die Produktion – nicht empfohlen. Der Austausch des Modells gegen qwen3:8b oder llama3.1:8b dauert 30 Minuten und löst das Problem für immer.

Unterstützt Mistral Tool Calling?

Hängt von der Version ab – und das ist die Hauptfalle:

mistral-nemo:latest ist in meiner Sammlung (7.1 GB) – ich habe es persönlich getestet. Ein ausgezeichnetes Modell für Textaufgaben, aber nicht für Agenten. Wenn Sie Mistral für Tool Calling möchten – nehmen Sie mistral-small:latest, nicht Nemo. Und überprüfen Sie immer die spezifische Version mit ollama show, bevor Sie eine Pipeline aufbauen.

Eignet sich DeepSeek-R1 für Agenten?

Ja – aber mit einem klaren Anwendungsbereich. Es ist kein „Allzweck“-Agent, sondern ein Agent für Aufgaben, bei denen die Korrektheit der Entscheidung wichtiger ist als die Reaktionsgeschwindigkeit.

Latenz: Das erste Token in tool_calls erscheint nach 3–10 Sekunden (abhängig von der Modellgröße und der Komplexität der Anfrage) – weil zuerst ein <think>-Block generiert wird. Für Echtzeit-Chats, bei denen der Benutzer auf eine Antwort wartet – ist das zu viel. Für Batch-Dokumentenverarbeitung, bei der niemand auf die Uhr schaut – ist es in Ordnung.

Wo es gewinnt: Mehrdeutige Anfragen, bei denen unklar ist, welches Tool aufgerufen werden soll. Zum Beispiel: „Überprüfen Sie, ob der Vertrag dem Gesetz entspricht“ – das Modell muss zwischen checkCompliance und extractKeyFacts wählen. DeepSeek-R1 wählt dank des Denkens seltener falsch.

Mein Fazit: Für juristische Kunden von AskYourDocs, wo Dokumente komplex sind und ein Fehler bei der Tool-Auswahl kostspielig ist – würde ich DeepSeek-R1:14b in Betracht ziehen. Für normale Kunden, bei denen Geschwindigkeit wichtig ist – Qwen3 oder Llama 3.1.

Warum gibt curl tool_calls zurück, aber Spring AI nicht?

Das ist die verwirrendste Situation, und ich habe sie selbst durchgemacht. Wenn curl mit derselben Anfrage und demselben Modell die richtige tool_calls zurückgibt, aber Spring AI Text, bedeutet das fast immer, dass das Framework die Tools nicht im richtigen Format übergibt.

In Spring AI 2.0.0-M3 ein spezifisches Problem: ToolCallingChatOptions serialisiert in einigen Konfigurationen Tools im OpenAI-Format, nicht im Format, das Ollama für native Aufrufe erwartet. Ollama wechselt stillschweigend zum Prompt-Pfad – und das Modell antwortet mit Text.

Diagnose – aktivieren Sie die Debug-Protokollierung der Anfrage an Ollama:

# application.properties
logging.level.org.springframework.web.reactive.function.client=DEBUG

Finden Sie im Log den Anfragekörper und prüfen Sie, ob dort das Feld tools im richtigen Format vorhanden ist. Wenn tools fehlt oder das Format vom Format in curl abweicht – liegt das Problem bei der Serialisierung des Frameworks.

Was ist der Unterschied zwischen qwen3:8b und qwen3-ua:latest für Tool Calling?

qwen3-ua:latest ist in meiner Sammlung (5.2 GB) – es ist eine angepasste Version von Qwen3 mit verbesserter Unterstützung für die ukrainische Sprache. Für Textaufgaben auf Ukrainisch – sichtbar bessere Antwortqualität.

Aber für Tool Calling – das Basis-qwen3:8b ist stabiler. Aus meinen Tests: qwen3:8b gab ~85% Zuverlässigkeit, qwen3-ua:latest – ~75% bei demselben Satz von Anfragen. Multi-Tool in der UA-Version funktionierte nur bei jedem zweiten Mal.

Mein Ansatz für ukrainischsprachige Projekte: qwen3:8b für den Agententeil (Tool Calling) und die Spracheinstellung über den System-Prompt („Antworten Sie ausschließlich auf Ukrainisch“). Das Basismodell versteht ukrainische Anfragen – generiert aber englische Antworten, wenn keine Sprache explizit angegeben ist.

Wie viele Tools kann man in einer Anfrage übergeben?

Ollama begrenzt die Anzahl der Tools in einer Anfrage formal nicht. Aber in der Praxis gibt es eine Grenze, bei der die Qualität zu sinken beginnt – und diese hängt von der Modellgröße ab.

Bei AskYourDocs habe ich 5 Tools: searchDocuments, extractKeyFacts, findDeadlines, extractContacts, checkCompliance. Auf qwen3:8b ist das am Limit – manchmal ruft das Modell checkCompliance bei Anfragen, wo es benötigt wird, nicht auf. Wenn es 8–10 Werkzeuge gäbe – würde ich zu 14B wechseln.

Schlussfolgerungen

• Überprüfen Sie die Capabilities vor der Auswahl: ollama show <model> zeigt sofort, ob native Tool-Unterstützung vorhanden ist.
• Für 8 GB RAM: qwen3:8b oder llama3.1:8b – ein zuverlässiger Start.
• Für Mac 16 GB + RAG: qwen3:8b + nomic-embed-text – beide passen ohne Swap.
• Für maximale Zuverlässigkeit beim Tool Calling: gemma4:latest (wenn 12+ GB RAM vorhanden sind) oder gemma4:26b (20+ GB).
• Mistral Nemo und Phi-4 – ausgezeichnete Modelle für ihre jeweiligen Aufgaben, aber nicht für Agenten mit Tools.
• Wenn das Modell Tools ignoriert – testen Sie zuerst direkt über curl, um das Problem des Frameworks vom Problem des Modells zu trennen.
• In der Produktion mit komplexen Agenten-Pipelines – qwen3:14b oder gemma4:26b. Der Unterschied in der Zuverlässigkeit zwischen 8B und 14B+ ist bei Multi-Tool und langen Aufrufketten spürbar.

Quellen

• Ollama — Tool Calling: Offizielle Dokumentation
• Morph LLM — 12 Ollama Models Ranked with Real Benchmarks (2026)
• Computing for Geeks — Ollama Models Cheat Sheet 2026
• Prompt Quorum — New Ollama Models May 2026
• WebCraft — Ollama REST API: Integration in eine Anwendung (Java, Python, JavaScript)
• WebCraft — Ollama auf 8 GB RAM: Welche Modelle funktionieren im Jahr 2026
• WebCraft — Reasoning Mode in Gemma 4: Wie man ihn einschaltet, wann er benötigt wird und was er kostet
• AskYourDocs — Persönliche Erfahrung mit Agenten-Pipelines auf Ollama