Inside OpenClaw #2: Die versteckten vLLM-Flags für Mistral

“Es funktioniert” ist nicht genug

Wenn Sie ein Open-Source-Modell wie Mistral Small 24B auf vLLM starten, passiert auf den ersten Blick alles Richtige: Der Server läuft, die API antwortet, Text wird generiert. Alles grün. Solche technischen Details sind Teil meiner KI & Automatisierungs-Beratung.

Bis Sie Tool-Calling aktivieren.

In der OpenClaw-Serie haben wir beschrieben, wie unser KI-Agent auf einer einzelnen GPU lokal läuft. Dieser Artikel beschreibt die technischen Stolpersteine, die zwischen “Modell läuft” und “Agent funktioniert produktiv” liegen.

Das Symptom: Stille Fehler

Tool-Calling mit lokalen Modellen versagt selten laut. Stattdessen passiert Folgendes:

• Das Modell ignoriert das Tool und antwortet in Fließtext
• Es generiert syntaktisch kaputte JSON-Aufrufe, die der Parser nicht versteht
• Es halluziniert Toolnamen, die nicht existieren
• Oder es ruft das richtige Tool auf, aber mit falschen Parametern

In den Logs sieht alles normal aus. Keine Fehlermeldung. Der Agent antwortet sogar — nur eben falsch.

Die drei Flags, die alles verändern

Nach Wochen systematischer Tests haben wir die entscheidenden vLLM-Konfigurationsparameter identifiziert:

1. --tool-call-parser mistral

vLLM unterstützt mehrere Tool-Call-Parser. Der Standard-Parser versteht Mistral’s spezifisches Format nicht korrekt. Mistral-Modelle verwenden ein eigenes Token-Schema für Funktionsaufrufe — [TOOL_CALLS] statt des OpenAI-üblichen function_call-Formats.

Ohne diesen Flag interpretiert vLLM die Tool-Calls als normalen Text. Das Modell “denkt”, es ruft ein Tool auf — der Server leitet den Aufruf aber nie weiter.

2. --chat-template

Mistral-Modelle erwarten ein spezifisches Chat-Template mit speziellen Tokens. Das Standard-Template von vLLM passt nicht immer. Je nach Modellversion kann es nötig sein, ein explizites Jinja2-Template zu definieren.

Das Template steuert, wie System-Prompt, User-Nachrichten und Tool-Definitionen dem Modell präsentiert werden. Ein falsches Template bedeutet: Das Modell sieht die Tool-Definitionen, versteht sie aber nicht als solche.

3. --enable-auto-tool-choice

Dieser Flag erlaubt dem Modell, selbst zu entscheiden, wann ein Tool-Aufruf sinnvoll ist. Ohne ihn muss der Client bei jedem Request explizit tool_choice: "auto" setzen — was nicht bei allen Gateway-Implementierungen der Fall ist.

In Kombination mit dem Mistral-Parser ermöglicht dieser Flag das gleiche Verhalten, das Sie von der OpenAI-API kennen: Das Modell entscheidet kontextbasiert, ob es ein Tool nutzt oder direkt antwortet.

Die vollständige Startsequenz

Unsere produktive vLLM-Konfiguration für Mistral Small 24B:

vllm serve Mistral-Small-24B-Instruct-2501-AWQ \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --tool-call-parser mistral \
  --enable-auto-tool-choice \
  --gpu-memory-utilization 0.95 \
  --dtype auto

Jeder einzelne Parameter hat einen Grund:

• --max-model-len 32768: Maximale Kontextlänge. Für Agent-Szenarien mit Tool-Aufrufen braucht man mindestens 16K — die Tool-Definitionen selbst verbrauchen bereits mehrere tausend Tokens.
• --gpu-memory-utilization 0.95: Nutzt 95% des VRAM. Bei einer RTX 4090 mit 24 GB bleiben so ~22,8 GB für das Modell. Weniger führt zu OOM-Fehlern bei langen Kontexten.
• --dtype auto: Automatische Precision-Erkennung. Für AWQ-quantisierte Modelle wählt vLLM die korrekte Konfiguration.

Was wir auf dem Weg gelernt haben

Tokenizer-Kompatibilität prüfen

Nicht jede Mistral-Version verwendet denselben Tokenizer. Wenn Sie ein älteres Modell mit einem neueren vLLM starten, kann es zu Token-Mismatches kommen — erkennbar an unsinnigen Zeichen in der Ausgabe oder abrupten Satzabbrüchen.

Temperature für Tool-Calling senken

Bei Text-Generierung kann Temperature 0.7 sinnvoll sein. Für Tool-Calling empfehlen wir 0.1-0.3. Höhere Werte führen zu kreativen Interpretationen von Funktionsnamen und Parametern — das Modell erfindet dann Tools, die nicht existieren.

Logs systematisch auswerten

vLLM loggt Tool-Calls nur im Debug-Modus. Aktivieren Sie --log-level debug während der Einrichtung. Sobald alles stabil läuft, reduzieren Sie auf info.

Warum das für den Mittelstand relevant ist

Lokale KI-Infrastruktur ist kein Plug-and-Play. Die Differenz zwischen “Modell startet” und “Agent funktioniert zuverlässig” liegt in Details, die in keiner Readme stehen.

Wenn Sie evaluieren, ob lokale KI-Agenten für Ihr Unternehmen sinnvoll sind, sollten Sie diesen Aufwand einplanen. Die gute Nachricht: Einmal korrekt konfiguriert, läuft das System stabil — ohne laufende API-Kosten und ohne dass Daten Ihr Netzwerk verlassen.

Nächster Schritt

Sie planen lokale KI-Infrastruktur und wollen die Fallstricke vermeiden? Ich teile meine Erfahrungen aus der Praxis.

→ Erstgespräch vereinbaren — kostenfrei

→ Oder zuerst mehr lesen: Lokales LLM als KI-Agent — ohne Cloud