Bestes Ollama-Modell für Zammad AI: On-Premise-LLM-Guide [2026]
Welches Ollama-Modell funktioniert am besten mit Zammad 7 AI? Ein praxisnaher On-Premise-Modell-Guide — der Structured-Output-Fallstrick, echte Geschwindigkeitswerte, VRAM-Dimensionierung und das richtige lokale LLM für Zusammenfassungen, Titel und Klassifikation.
Bestes Ollama-Modell für Zammad AI: On-Premise-LLM-Guide [2026]
📖 9 Minuten Lesezeit • Aktualisiert am 23. Juni 2026

Sie haben auf Zammad 7 aktualisiert, die KI-Funktionen aktiviert und sie auf den Ollama-Server gerichtet, der ohnehin schon lief — und die Ticket-Zusammenfassungen kamen leer, fehlerhaft oder gar nicht zurück. Es gibt GPU-Last, manchmal sogar eine Antwort, aber Zammad kann sie nicht verwenden.
Sie machen nichts falsch. Das gewählte Modell ist das Problem. Zammads KI-Funktionen verlangen vom LLM eine strikte JSON-Struktur, und überraschend viele beliebte Modelle — auch sehr große — können diese nicht zuverlässig liefern. Dieser Guide beantwortet die Frage, die Zammad-Administratoren im Community-Forum immer wieder stellen: Welches Ollama-Modell funktioniert am besten mit Zammad AI — und wie Sie die Hardware dahinter dimensionieren.
Bauen Sie gerade den Rest des Stacks auf? Kombinieren Sie diesen Beitrag mit unserem Zammad-7-On-Premise-Setup-Guide und dem ausführlichen Zammad-7-KI-Funktionen-Leitfaden.
Das eigentliche Problem: Structured Output, nicht „Intelligenz“
Der Reflex ist, zum größten, klügsten Modell zu greifen, das man betreiben kann. Bei Zammad AI geht dieser Reflex nach hinten los. Zammads KI-Aufgaben — Ticket-Zusammenfassung, Titel-Umformulierung, Kategorisierung — sind Structured-Output-Aufgaben: Das Modell muss gültiges JSON in einem festen Schema zurückgeben. Drei Fehlerbilder dominieren:
- Kaputtes JSON. Manche Modelle halten den OpenAI-artigen Structured-Output-Vertrag nicht ein.
gpt-oss(sowohl die 20B- als auch die 120B-Variante) ist ein gut dokumentiertes Beispiel — es liefert Prosa oder abgeschnittene Fragmente, wo Zammad JSON erwartet, sodass die Funktion stillschweigend fehlschlägt. Dieses Ollama/gpt-oss-Problem wurde vom Zammad-Kernteam im Community-Thread bestätigt. - „Thinking“-/Reasoning-Modelle, die leer zurückkommen. Reasoning-Modelle (die Qwen3-Familie und ähnliche) haben Thinking oft standardmäßig aktiviert. Mit aktiviertem Thinking kann die strukturierte Antwort leer zurückkommen. Neuere Zammad-Releases deaktivieren Thinking automatisch; auf einem älteren Point-Release müssen Sie Reasoning selbst abschalten.
- Zu groß für die GPU. Ein 120B-Modell auf einer schwachen GPU läuft nicht harmlos „langsam“ — es läuft in Timeouts. Ein Betreiber, der
qwen32bauf einem Cluster aus drei Tesla P40 betrieb, berichtete von rund 30 % fehlgeschlagenen Anfragen durch Timeouts. Zammads KI-Aufrufe müssen zügig zurückkommen, um in der Agenten-Oberfläche nützlich zu sein.
Das Gewinnermodell ist also nicht das größte — sondern jenes, das zuverlässig JSON liefert, in Ihren VRAM passt und in Sekunden antwortet.
Welche Ollama-Modelle wirklich mit Zammad AI funktionieren
Die folgende Tabelle bündelt, was Zammad-Betreiber und das Kernteam im produktiven Einsatz berichtet haben, plus die oben genannten Structured-Output- und Hardware-Beschränkungen. Die Zeiten sind Richtwerte für eine einzelne Ticket-Zusammenfassung und skalieren mit Ticketlänge und GPU.
| Modell | ca. VRAM | Tempo (1 Zus.) | JSON-Zuverlässigkeit | Am besten für | Fazit |
|---|---|---|---|---|---|
llama3.2:3b | ~4–6 GB | ~6 s | Gut | Schnelle Zusammenfassungen, kleine GPUs | Zammads vorausgefüllter Standard. Schnell und verlässlich; Qualität ist grundlegend. Bester Einstieg. |
gemma3 (4B) | ~8 GB | ~6–10 s | Gut | Titel-Umformulierung auf Mini-GPUs | Läuft in 8 GB VRAM; bessere Titel als llama3.2 berichtet. Starke Budget-Wahl. |
mistral-small3.2:24b | ~16–24 GB | ~15 s | Sehr gut | Beste Gesamtqualität | Betreiber-Favorit: spürbar bessere Zusammenfassungen und deutlich bessere Titel-Umformulierung. Beste Balance aus Qualität/Tempo. |
qwen3.6-35b-a3b (35B/3B aktiv) | ~20–24 GB | ~10–18 s | Gut (Thinking AUS) | Top-Qualität bei kleinem Footprint | MoE mit nur 3B aktiven Parametern — rivalisiert laut Qwen mit dichten 27–31B-Modellen, passt aber in 24 GB. Starke Wahl auf einer RTX PRO 4000 Blackwell. Thinking deaktivieren. |
gemma3:27b (Google) | ~16–20 GB | ~12–18 s | Sehr gut | Hohe Qualität, gute Titel | LMArena-Elo 1338 — schlägt DeepSeek-V3 und o3-mini. Beweist: der Hersteller (Google) ist egal, lokal läuft es genauso privat. |
qwen3-Familie (Thinking AUS) | variiert | mittel | Gut mit Thinking aus | Mehrsprachige Zusammenfassungen | Solide, sobald Reasoning deaktiviert ist. Mit Thinking an: langsam, Timeouts oder leer. |
gemma-4-e2b / gemma-4-e4b | ~6–10 GB | schnell | Gut | Effiziente Zusammenfassungen | ~95 % des Detailgrads viel größerer Modelle bei einem Bruchteil des Footprints. |
llama4:latest | groß | ~31 s | Inkonsistent | — | Langsam und unzuverlässig im Test. Vorerst überspringen. |
gpt-oss:20b / gpt-oss:120b | sehr groß | — | Kaputt | — | Structured Output schlägt fehl. Aktuell nicht mit Zammad AI verwenden. |
Die Kurzantwort
- Soll einfach auf einer bescheidenen GPU laufen? Beginnen Sie mit
llama3.2:3b(dem Standard) odergemma3. - Haben ~24 GB VRAM (z. B. RTX PRO 4000 Blackwell) und wollen die besten Ergebnisse? Nutzen Sie
mistral-small3.2:24b,qwen3.6-35b-a3b(Thinking aus) odergemma3:27b— qualitativ praktisch gleichauf. - Betreiben Sie ein Reasoning-Modell (Qwen3)? Thinking deaktivieren, sonst brechen die Zusammenfassungen.
- Vermeiden Sie
gpt-oss(JSON) und überdimensionierte Modelle auf unterdimensionierten GPUs (Timeouts).
Was die offiziellen Benchmarks wirklich sagen
Viele Teams glauben, sie müssten zu Mistral greifen. Die offiziellen Benchmarks zeichnen ein anderes Bild: Open-Weight-Modelle von Alibaba (Qwen), Google (Gemma) und Mistral liegen in derselben Liga. Die folgenden Zahlen stammen aus dem offiziellen Qwen-Vergleich — gleiches Test-Setup für alle Modelle:
| Modell (Hersteller) | MMLU-Pro | MMLU-Redux | GPQA | AIME 2026 |
|---|---|---|---|---|
| Qwen3.6-35B-A3B — 35B/3B aktiv (Alibaba) | 85,2 | 93,3 | 86,0 | 92,7 |
| Qwen3.5-27B — dicht (Alibaba) | 86,1 | 93,2 | 85,5 | 92,6 |
| Gemma 4-31B (Google) | 85,2 | 93,7 | 84,3 | 89,2 |
| Gemma 4-26B-A4B (Google) | 82,6 | 92,7 | 82,3 | 88,3 |
Quelle: offizieller Qwen3.6-35B-A3B-Benchmark (14.04.2026). Höher ist besser; alle Werte in %.
Zwei weitere belegte Datenpunkte:
- Gemma 3 27B (Google) erreicht auf der LMArena-Rangliste einen Elo-Wert von 1338 und schlägt damit DeepSeek-V3 (1318) und o3-mini (1304) — bei deutlich geringerem GPU-Bedarf (Quelle: Google – Gemma 3).
- Mistral Small 3.2 24B hebt das Instruction-Following auf 84,78 % (vs. 82,75 % in 3.1) und liefert eine stabilere Ausgabe — genau das, was für sauberes JSON zählt (Quelle: Mistral / Hugging Face).
Wichtige Einordnung: Das sind allgemeine Wissens-, Reasoning- und Coding-Benchmarks, keine Zammad-Messung. Für Zammad entscheiden am Ende zuverlässiges JSON und Latenz auf Ihrer GPU — nicht der Leaderboard-Platz. Die Tabelle belegt aber: Bei der reinen Modellqualität müssen Sie sich auf keinen einzelnen Hersteller festlegen.
Der Hersteller des Modells ist egal

Ein verbreiteter Irrtum lautet: „Aus Datenschutzgründen müssen wir Mistral nehmen, das ist europäisch.” Bei Open-Weight-Modellen stimmt das nicht. Sie laden die Modelldatei herunter und führen sie auf Ihrer Hardware über Ollama aus. Ob das Modell von Google (Gemma), Alibaba (Qwen), Mistral (Frankreich) oder Meta (Llama) stammt, ändert daran nichts:
- Es verlässt kein Byte das Haus. Open Weights rufen nicht „nach Hause”. Die Anfrage geht an Ihren lokalen Ollama-Host, die Antwort kommt von dort. Google sieht Ihr Ticket nie — auch nicht bei Gemma.
- Die Datensouveränität kommt vom Ort der Ausführung, nicht vom Logo des Herstellers. Ein lokal laufendes Gemma- oder Qwen-Modell ist exakt so privat wie ein lokales Mistral.
- Wählen Sie nach Eignung, nicht nach Marke: zuverlässiges JSON, Qualität auf Ihren Aufgaben, Tempo auf Ihrer GPU. Nach diesen Kriterien sind Gemma (Google) und Qwen (Alibaba) oft die bessere Wahl — die Benchmarks oben belegen es.
Der On-Prem-Vorteil in einem Satz: Sobald das Modell auf Ihrer GPU läuft, sind Datenschutz, DSGVO-/EU-AI-Act-Konformität, planbare Fixkosten statt Pro-Token-Gebühren, Offline-/Air-Gap-Fähigkeit und Unabhängigkeit vom Anbieter automatisch erfüllt — völlig unabhängig davon, wer das Modell trainiert hat.
So fließen die Daten bei einem lokalen Modell — und was eben nicht passiert:

So verbinden Sie Zammad mit Ihrem Ollama-Modell
Zammad 7 bietet im Admin-Bereich eine AI-Provider-Konfiguration. Ollama ist eine erstklassige Option, und jeder OpenAI-kompatible Endpunkt funktioniert ebenfalls.
- Modell auf dem Ollama-Host laden:
# Auf dem GPU-Server, der Ollama betreibt
ollama pull mistral-small3.2:24b
# oder, für kleine GPUs:
ollama pull llama3.2:3b
- In Zammad zu Admin → System → KI gehen und Ollama (oder Custom / OpenAI-kompatibel) als Provider wählen:
- API-URL:
http://ihr-ollama-host:11434(oder.../v1für den OpenAI-kompatiblen Pfad) - Modell: das exakte Tag, das Sie geladen haben, z. B.
mistral-small3.2:24b - API-Key: für lokales Ollama leer lassen (oder einen Dummy-Wert, falls das Feld einen verlangt)
-
Geben Sie dem Modell genug Kontext. Lange Ticketverläufe brauchen ein großes Kontextfenster; Betreiber fahren Ollama mit 16K–128K Kontext für KI-Funktionen. Ein zu kleiner Kontext schneidet das Ticket ab und verschlechtert die Zusammenfassungen.
-
Thinking deaktivieren, falls Sie ein Reasoning-Modell gewählt haben und Ihre Zammad-Version es nicht selbst tut.
Da der Endpunkt in Ihrem eigenen Netzwerk liegt, bleibt jeder KI-Aufruf — Zusammenfassung, Titel, Kategorisierung — auf Hardware, die Sie kontrollieren. Aktuelle Feldnamen finden Sie in der offiziellen Zammad-AI-Provider-Dokumentation.
Hardware: Wie viel GPU brauchen Sie wirklich?
Die Modellgröße bestimmt sowohl VRAM als auch Latenz. Eine grobe Dimensionierung für On-Premise-Zammad-AI:
| Ziel | Modellklasse | Praktische GPU | VRAM |
|---|---|---|---|
| Einstieg / kleines Team | 3–4B (llama3.2:3b, gemma3) | RTX 3060 / 4060 oder geteilte 8-GB-Karte | 8 GB |
| Beste Qualität, Mainstream | ~24–35B (mistral-small3.2:24b, qwen3.6-35b-a3b, gemma3:27b) | RTX PRO 4000 Blackwell (24 GB) oder RTX 3090 / 4090 | 24 GB |
| Höchster Durchsatz / mehrere Modelle parallel | dichte 30B+ oder mehrere Modelle gleichzeitig | NVIDIA L40S / A100 / H100 | 40–80 GB |
Die NVIDIA RTX PRO 4000 Blackwell ist hier der Sweet Spot: 24 GB GDDR7 mit ECC, PCIe 5.0, fünfte Tensor-Core-Generation und ein Single-Slot-Design — genug VRAM für die gesamte 24–35B-Klasse, ohne Workstation-Umbau (NVIDIA-Datenblatt). Weil qwen3.6-35b-a3b als MoE nur ~3B Parameter aktiv hält, läuft selbst dieses 35B-Modell quantisiert komfortabel auf 24 GB.
Zwei praktische Regeln aus echten Deployments:
- Latenz skaliert mit der Modellgröße. Gleiches Ticket, verschiedene Modelle:
llama3.2:3b≈ 6 s,mistral-small3.2:24b≈ 15 s,llama4:latest≈ 31 s. Wählen Sie das kleinste Modell mit akzeptabler Qualität. - Überdimensionieren Sie nicht relativ zur GPU. Ein Modell, das in den System-RAM auslagert oder gerade so passt, läuft unter den Erwartungen der Agenten-Oberfläche in Timeouts. Reserve zählt mehr als reine Parameterzahl.
Wenn bereits eine GPU im Rack steckt, sind die Grenzkosten für On-Premise-KI im Wesentlichen Strom und Wartung. Eine vollständige Kostenaufstellung (Server + GPU + Betrieb) finden Sie im On-Premise-Setup-Guide.
Datenschutz: genau darum geht es bei lokalen Modellen
Das Modell über Ollama im eigenen Netzwerk zu betreiben bedeutet, dass Ticketinhalte das Haus nie verlassen — der Grund, warum die meisten Teams überhaupt selbst gehostete KI wählen, und eine saubere Passung für DSGVO und EU AI Act. Wenn Sie aus Qualitätsgründen dennoch ein Cloud-Modell wollen, aber konform bleiben müssen, setzen manche Betreiber einen PII-entfernenden Proxy vor den Provider, sodass personenbezogene Daten vor dem Senden entfernt und in der Antwort wiederhergestellt werden. Local-First ist einfacher: Halten Sie die Daten on-prem, und die Compliance-Frage entfällt vollständig.
Wo ein allgemeines LLM aufhört — und ein trainiertes Modell beginnt
Hier die ehrliche Grenze des obigen Ansatzes. Ein Allzweck-Ollama-Modell ist hervorragend bei Zusammenfassungen und Titel-Umformulierung — offenen Textaufgaben, bei denen „gut genug“ wirklich gut ist. Es ist deutlich schwächer bei Klassifikation und Routing: der Entscheidung über die exakte Queue, Priorität oder Kategorie für Ihre Organisation, mit Ihrer Taxonomie, konsistent und im Maßstab. Ein generisches Modell per Prompt auf 40 interne Queues abzubilden, erzeugt plausibel-falsche Antworten und driftet, sobald sich Prompts ändern.
Genau dafür ist Open Ticket AI gebaut. Statt ein allgemeines LLM zu prompten, trainiert OTAI ein kundenspezifisches Klassifikationsmodell aus Ihren Queue-Metadaten (QueueSpec) — beim Training verlassen keine Rohticketdaten Ihre Umgebung. Das Ergebnis:
- Höhere, messbare Genauigkeit auf Ihren Kategorien als beim Prompten eines generischen Modells.
- Kleinerer Footprint — ein trainierter Klassifikator läuft bequem neben Ihrem Ollama-Zusammenfassungsmodell auf derselben GPU.
- Stabiles Verhalten — kein Prompt-Drift; Sie evaluieren es gegen historische Labels.
Beide Schichten ergänzen sich sauber:
- Ollama + Zammad 7 AI → Zusammenfassungen, Titel-Umformulierung, Schreibassistent.
- Open Ticket AI → spezialisierte, hochgenaue Klassifikation und Routing, on-premise, angebunden über das OTAI-Zammad-Plugin.
Beide laufen auf Ihrer Hardware. Beide halten Ihre Daten dort, wo sie hingehören.
Empfehlungen auf einen Blick
- Standard / kleine GPU:
llama3.2:3bodergemma3— schnell, zuverlässiges JSON, 8 GB VRAM. - Beste Qualität (24 GB, z. B. RTX PRO 4000 Blackwell):
mistral-small3.2:24b,qwen3.6-35b-a3b(Thinking aus) odergemma3:27b— qualitativ gleichauf. - Der Hersteller ist egal: Gemma (Google), Qwen (Alibaba), Mistral, Llama — lokal laufen alle gleich privat. Wählen Sie nach JSON-Zuverlässigkeit, Qualität und Tempo, nicht nach Marke.
- Reasoning-Modelle (Qwen3): Thinking deaktivieren, sonst brechen die Zusammenfassungen.
- Vermeiden:
gpt-oss(kaputtes JSON) und überdimensionierte Modelle auf kleinen GPUs (Timeouts). - Großes Kontextfenster (16K+) geben, damit lange Verläufe gut zusammengefasst werden.
- Brauchen Sie genaues Routing/Klassifikation? Fügen Sie ein trainiertes Modell hinzu — das ist Open Ticket AI, kein größerer Prompt.
Häufige Fragen
Welches Ollama-Modell ist das beste für Zammad AI?
Für die meisten Teams bietet mistral-small3.2:24b die beste Balance aus Qualität und Tempo (~15 s pro Zusammenfassung, starke Titel-Umformulierung) auf einer 24-GB-GPU. Auf einer kleinen GPU beginnen Sie mit llama3.2:3b (Zammads Standard) oder gemma3, die in rund 8 GB VRAM laufen.
Warum sind meine Zammad-AI-Zusammenfassungen leer oder fehlerhaft?
Fast immer ein Structured-Output-Problem. Zammad fordert vom Modell striktes JSON. gpt-oss-Modelle können es nicht zuverlässig liefern, und Reasoning-Modelle mit aktiviertem Thinking geben oft leere Antworten zurück. Wechseln Sie zu einem funktionierenden Modell (mistral-small3.2:24b, llama3.2:3b, gemma3) und deaktivieren Sie Thinking bei Reasoning-Modellen.
Muss ich aus Datenschutzgründen ein europäisches Modell wie Mistral nehmen?
Nein. Bei Open-Weight-Modellen kommt die Datensouveränität vom Ort der Ausführung, nicht vom Hersteller. Ein lokal über Ollama betriebenes Gemma (Google) oder Qwen (Alibaba) ist exakt so privat wie ein lokales Mistral — es verlässt kein Byte Ihr Netzwerk. Laut offiziellen Benchmarks liegen Gemma, Qwen und Mistral ohnehin in derselben Liga; wählen Sie nach JSON-Zuverlässigkeit, Qualität und Tempo.
Kann Zammad AI vollständig on-premise mit Ollama laufen?
Ja. Die AI-Provider-Einstellungen von Zammad 7 unterstützen Ollama und jeden OpenAI-kompatiblen Endpunkt. Richten Sie Zammad auf Ihren lokalen Ollama-Host, und keine Ticketdaten verlassen Ihr Netzwerk — eine saubere Passung für DSGVO und EU AI Act.
Wie viel GPU brauche ich für Zammad AI?
8 GB VRAM reichen für 3–4-Milliarden-Parameter-Modelle wie llama3.2:3b und gemma3. Für mistral-small3.2:24b wollen Sie eine 24-GB-Karte wie eine RTX 3090 oder 4090. Die Latenz wächst mit der Modellgröße — wählen Sie also das kleinste Modell, das Ihren Qualitätsanspruch erfüllt.
Ersetzt Open Ticket AI Ollama in Zammad?
Nein — sie ergänzen sich. Nutzen Sie Ollama für Zusammenfassungen und Schreibhilfe; nutzen Sie Open Ticket AI für hochgenaue, kundenspezifisch trainierte Ticket-Klassifikation und Routing. Beide laufen on-premise.
Quellen
- Zammad Community — Which model from Ollama works best for AI features? (Berichte von Betreibern und Kernteam zu
llama3.2:3b,mistral-small3.2:24b,gemma3,gpt-oss, Reasoning/Thinking und Ausführungszeiten) - Qwen — Qwen3.6-35B-A3B: offizielle Benchmarks (MMLU-Pro, GPQA, AIME u. a. im Vergleich zu Qwen3.5-27B und Gemma 4)
- Google — Gemma 3 (LMArena-Elo 1338) · Gemma-Modellübersicht
- Mistral AI — Mistral Small 3 · Mistral Small 3.2 (Hugging Face)
- NVIDIA — RTX PRO 4000 Blackwell – Datenblatt (24 GB GDDR7)
- Zammad Admin Docs — AI-Provider-Konfiguration
- Zammad — Künstliche-Intelligenz-Produktübersicht
- Ollama — Structured outputs
