Josev-4B-GGUF

Der große Bruder, jetzt auch im Format für die Hosentasche. Für eine etwas größere Hosentasche.

Ausprobieren: Josev-4B im Browser, ohne Installation, auf ZeroGPU. Anklickbare Beispiele inklusive.

GGUF-Dateien von mayflowergmbh/Josev-4B für llama.cpp. Josev ist ein Decider, der Deutsch gelernt hat, und soweit wir wissen, gehört er mit seinem kleinen Bruder Josev-2B zu den ersten Decision Models, die breit auf deutschen Daten trainiert wurden: auf decisions-de (Version 3) mit 90 Aufgabenquellen und 140.989 Trainingszeilen. Übersetzt hat eine KI, für die Deutsch selbst eine Fremdsprache ist. Die Option-Keys sind Englisch geblieben (card_arrival), die Beschreibungen sind Deutsch. Denglisch by Design.

Josev spricht die System-One-/Jev-API /v1/systemone. Man gibt einen state und typisierte Fragen (noul, choice, score) hinein und bekommt für jede Option eine Wahrscheinlichkeit zurück, in einem einzigen Prefill mit "output_tokens": 0. Im Grunde ist das ein Klassifikator, dessen Klassen mit jedem Request kommen. Mehr dazu steht auf der Model-Card des PyTorch-Modells.

Versionen: main enthält Version 3 (trainiert auf decisions-de Version 3; als GGUF noch nicht vermessen). Die GGUFs von Version 2 mit dem korrigierten Kontextwert liegen im Commit cfbe5142, die von Version 2 mit dem alten Wert unter dem Tag v2, die von Version 1 unter dem Tag v1, zum Beispiel mit hf download mayflowergmbh/Josev-4B-GGUF Josev-4B-Q8_0.gguf --revision v1.

Wer schwankt: Josev-4B-Q4_K_M ist ungefähr so groß wie Josev-2B-BF16. Gemessen haben wir den Vergleich nicht, wir sagen es nur.

Exportiert mit Unsloths Decision-GGUF-Exporter und dem Clef-Konverter von llama.cpp. Die Temperaturen pro Fragetyp, die Unsloth nach dem Training gefittet hat (Version 3: choice 1,03, score 1,03, noul 0,93), stecken in den GGUF-Metadaten. llama.cpp liefert also kalibrierte Wahrscheinlichkeiten direkt ab Werk.

Veröffentlicht von Mayflower GmbH.

Server starten

Braucht llama.cpp b11443 oder neuer (Version 2 getestet mit b11719, Version 3 noch nicht getestet).

llama-server -m Josev-4B-Q8_0.gguf --mmproj mmproj-Josev-4B-Q8_0.gguf -ngl 99 \
  -np 2 -c 32768 -b 16384 -ub 16384 --port 8080

Wichtig, wirklich wichtig: Josev verarbeitet den ganzen Request in einem Batch. -b/-ub müssen deshalb mindestens so groß sein wie der längste Request in Tokens. Mit dem Default 512 endet jeder längere Request mit HTTP 500 („input is too large to process“). Das ist die einzige Entscheidung, die Josev nicht selbst treffen kann, egal wie viele Parameter er hat. -c teilen sich die -np Slots.

Ollama

Seit dem 19.10.2026 steht in den Modell-GGUFs clef.context_length = 16384. Vorher stand dort der Wert des Qwen3.5-Basismodells, 262.144. Ollama legt den Compute-Buffer nach diesem Wert an, das waren rund 160 GiB, und das Modell startete nicht. Josev braucht so viel Kontext nicht, trainiert und gemessen wird mit höchstens 16.384 Tokens pro Request. Jetzt geht es ganz ohne Modelfile, direkt vom Hub (der Vision-Tower kommt automatisch mit):

ollama pull hf.co/mayflowergmbh/Josev-4B-GGUF:Q8_0
ollama show hf.co/mayflowergmbh/Josev-4B-GGUF:Q8_0   # clef, context length 16384, Capabilities: decision, vision

Wer eine lokale Datei importiert, braucht nur ein Modelfile mit einer Zeile, ganz ohne Parameter:

echo "FROM ./Josev-4B-Q8_0.gguf" > Modelfile
ollama create josev-4b -f Modelfile

ollama run passt nicht, Josev generiert keinen Text. Ollama spricht dieselbe API wie llama.cpp, nur auf Port 11434:

curl -s http://127.0.0.1:11434/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "hf.co/mayflowergmbh/Josev-4B-GGUF:Q8_0",
  "state": {"kommentar": "Du bist so ein Vollpfosten, lösch einfach deinen Account."},
  "questions": {"beleidigend": {"type": "noul", "instructions": "Ist der Kommentar beleidigend?"}}}'

Auch die Version-3-Dateien tragen clef.context_length = 16384. Getestet haben wir Ollama mit Version 2 (Ollama 0.40.6 auf einer RTX PRO 6000, lokal importiert und direkt vom Hub): Das Modell lädt komplett auf die GPU mit 16.384 Tokens Kontext. Die decisions-de-Validation läuft ohne Fehler durch:

Die Gewichte sind unverändert, nur dieser eine Metadaten-Wert ist neu. Auch llama-server braucht jetzt kein -c mehr, solange ein Slot reicht. Die Dateien mit dem alten Wert liegen weiter unter dem Tag v2. Die mmproj-Dateien sind unverändert.

Beispiele

Alle Ausgaben stammen echt aus Josev-4B-Q8_0.gguf von Version 2 und sind gekürzt. Für Version 3 sind sie noch nicht neu gelaufen.

Rechnung: drei Fragetypen in einem Request

curl -s http://127.0.0.1:8080/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "josev-4b",
  "state": {"rechnung": {"betrag": 1250.0, "status": "seit 30 Tagen überfällig"}},
  "questions": {
    "status": {"type": "choice", "instructions": "Welchen Status hat die Rechnung?",
               "criteria": {"paid": "bezahlt", "overdue": "überfällig", "draft": "Entwurf"}},
    "gross":  {"type": "noul", "instructions": "Ist der Betrag höher als 1000 EUR?"},
    "dring":  {"type": "score", "instructions": "Wie dringend ist eine Mahnung?",
               "criteria": ["gar nicht", "etwas", "sehr"]}
  }}'

{"answers": {
  "status": {"type": "choice", "choice": "overdue", "probabilities": {"draft": 0.0002, "overdue": 0.9995, "paid": 0.0003}, ...},
  "gross":  {"type": "noul", "noul": 0.9995},
  "dring":  {"type": "score", "score": 1.66, "probabilities": {"0": 0.026, "1": 0.289, "2": 0.685}, ...}},
 "usage": {"input_tokens": 339, "output_tokens": 0}}

Der 2B fand: mahnen, aber freundlich (1,70). Version 1 des 4B fand: mahnen (1,86). Version 2 liegt mit 1,66 wieder näher beim kleinen Bruder.

Intent-Erkennung

curl -s http://127.0.0.1:8080/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "josev-4b",
  "state": {"nachricht": "Meine neue Karte ist immer noch nicht da, dabei habe ich sie vor zwei Wochen bestellt."},
  "questions": {"intent": {"type": "choice", "instructions": "Welches Anliegen hat der Bankkunde?",
    "criteria": {"card_arrival": "Karte noch nicht angekommen", "lost_or_stolen_card": "Karte verloren oder gestohlen",
                 "card_not_working": "Karte funktioniert nicht", "exchange_rate": "Wechselkurs",
                 "transfer_not_received": "Überweisung nicht angekommen"}}}}'
# intent: card_arrival (0.999)

Und sonst so

Beim „Vollpfosten“ ist Version 2 strenger als Version 1 (delete vorn statt keep), aber noch unentschlossen. Der 2B löscht ihn mit 0,90. Mehr dazu und die vollständigen Requests stehen auf der PyTorch-Model-Card.

Messwerte

Version 3 ist als GGUF noch nicht vermessen. Die folgenden Werte gehören zu Version 2: Q8_0 über llama-server /v1/systemone gegen das bf16-PyTorch-Modell, auf der alten decisions-de-Validation (565 Fälle, 1.215 Entscheidungen, heute validation_legacy):

* PyTorch mit denselben Typ-Temperaturen, die im GGUF stecken. Studio hat die Temperaturen auf genau diesem Split gefittet, die ECE ist also ein Heimspiel.

Q8_0 trifft sogar drei Entscheidungen mehr als PyTorch (1.092 gegen 1.089 von 1.215). Das ist Rauschen der Quantisierung, kein Qualitätsgewinn. Version 1 lag bei 0,858 (Q8_0). Die anderen Quantisierungen sind nicht vermessen; wer Q4_K_M nimmt, entscheidet auf eigenes Risiko. Details, Training und Kleingedrucktes stehen auf der Model-Card von Josev-4B.

Lizenz

Apache-2.0, wie das Basismodell Qwen3.5-4B. Die Trainingsdaten behalten die Lizenzen ihrer Quellen, siehe Dataset-Card.