openai/gpt-oss-120b mit dem LoRA-Adapter dustin2050/finrag-gpt-oss-120b-v2 verlustarm eingerechnet und als GGUF für llama.cpp / LM Studio / Ollama bereitgestellt.


Datei	`finrag-120b-Q8_0.gguf`
Größe	124,3 GB (8,51 bpw)
Basis	`openai/gpt-oss-120b` (MXFP4, 117 B total / 5,1 B aktiv, 128 Experten, 36 Layer)
Adapter	QLoRA r=16, α=32 auf Attention und allen MoE-Expert-Projektionen
Trainingsdaten	`distill_v3` — 14.452 Beispiele, 8.452 eigene Distillation (500 Volltext-Papers) + 6.000 gefilterte aus `ianncity/GLM-5.2-Finance-80000x`

Warum Q8_0 und nichts Kleineres

Das ist die wichtigste Information in diesem Repo. Das LoRA-Delta ist klein relativ zu den Basisgewichten — gemessen am echten Adapter gegen die echten MXFP4-Basisgewichte:


Basisgewichte `gate_up_proj`	RMS 0,0320
LoRA-Delta	RMS 0,00076 (Median über 36 Layer)
‖Δ‖/‖W‖	2,3 % (Spanne 1,2–3,8 %)

Erhalt der Wirkrichtung nach Quantisierung, cosine(Q(W+Δ) − Q(W), Δ):

bf16	Q8_0	Q6_K	Q5_K	Q4_K	MXFP4
0,997	0,936	0,596	0,347	0,227	0,168

Ein 4-Bit-Quantisat dieses Modells wäre nicht „Basis ohne Fine-Tune", sondern schlechter als die Basis: es weicht um mehr ab, als das Delta groß ist, zeigt aber nur zu ~17 % in dessen Richtung — der Rest ist Quantisierungsrauschen. Besonders scharf, weil die Basis nativ MXFP4 ist und im Zielformat exakt darstellbar: nur 0,53 % der Expertengewichte könnten ihren Code überhaupt ändern.

Es gibt kein Q6_K/Q5_K/Q4_K für dieses Modell

Alle K-Quants nutzen 256er-Superblöcke. gpt-oss hat hidden_size = 2880, und 2880/256 = 11,25 — nicht teilbar. llama-quantize meldet dann 217 of 687 tensor(s) required fallback quantization und legt die Experten (90 % der Parameter) auf Q8_0. Ein „Q6_K"-File wäre inhaltlich ein Q8_0 mit schlechter quantisierter Attention — und die trägt ebenfalls LoRA-Deltas. Nutzbar sind nur Block-32-Typen: Q8_0, Q5_0, Q4_0, MXFP4. Von denen trägt nur Q8_0 das Fine-Tune.

Ausführen

RTX PRO 6000 / 96 GB VRAM

124 GB passen nicht in 96 GB. llama.cpp kann Expert-Tensoren im Host-RAM halten und pro Token nur die tatsächlich gerouteten Experten auf die GPU kopieren:

llama-server -m finrag-120b-Q8_0.gguf -ngl 99 --n-cpu-moe 10 -c 16384 --port 8080

--n-cpu-moe 10 ist gemessen: 87,7 von 96 GB VRAM belegt, lädt zuverlässig. Nur 10 der 36 Layer müssen ihre Experten ins Host-RAM.

Gemessener Durchsatz (RTX PRO 6000 Server Edition, 600 W, llama-bench):


Prompt-Verarbeitung (pp512)	130–147 tok/s
Generierung (tg128)	7,0–7,5 tok/s

Die 7 tok/s sind die Rechnung für das CPU-Offload: eine 2.000-Token-Antwort dauert ~4,5 Minuten. Ohne Auslagerung (2× RTX PRO 6000 = 192 GB, oder H200 141 GB) wären deutlich höhere Werte zu erwarten. Das ist der Preis dafür, dass dieses Fine-Tune 8 Bit braucht — das Basismodell in MXFP4 (63 GB) passt vollständig in eine Karte und erreicht mit vLLM ~1.500 tok/s, hat aber kein Fine-Tune.

Mac mit 128 GB Unified Memory

Geht, ist aber knapp. macOS gibt der GPU per Default nicht genug:

bash

sudo sysctl iogpu.wired_limit_mb=122880     # 120 GB freigeben
llama-server -m finrag-120b-Q8_0.gguf -ngl 99 -c 8192

Auch hier ohne --jinja — siehe den Abschnitt zum Chat-Endpunkt unten.

Mit kleinem Kontext arbeiten. Bei 64 GB oder weniger ist dieses Modell nicht nutzbar — dann besser das Basismodell unsloth/gpt-oss-120b-GGUF verwenden, das ohne Fine-Tune auch in 4 Bit sinnvoll bleibt.

WICHTIG: Der OpenAI-Chat-Endpunkt funktioniert NICHT

HTTP 500: The model produced output that does not match the expected peg-native format

Ursache (verifiziert): Das Modell emittiert nach <|start|>assistant direkt <|message|><think>… — ohne die von harmony verlangte <|channel|>-Deklaration. Es gibt damit exakt wieder, was das Training ihm zeigte: die Trainingsdaten wurden mit apply_chat_template(msgs, add_generation_prompt=False) gerendert, und dieses Template schreibt für eine einfache Assistant-Nachricht <|start|>assistant<|message|>{content} ohne Kanal. llama.cpps strikter gpt-oss-Parser lehnt das ab. Ein Datenaufbereitungs-Fehler, kein Modelldefekt — die Gewichte sind in Ordnung, die Ausgabe ist inhaltlich kohärent.

Workaround: den Roh-Endpunkt /completion benutzen und den Prompt selbst bauen.

bash

llama-server -m finrag-120b-Q8_0.gguf -ngl 99 --n-cpu-moe 10 -c 16384 --port 8080
# KEIN --jinja: der Chat-Parser wuerde die Ausgabe verwerfen

python

prompt = ("<|start|>system<|message|>You are a quantitative trading analyst.\n"
          "Reasoning: low<|end|>"
          f"<|start|>user<|message|>{question}<|end|><|start|>assistant")
requests.post("http://127.0.0.1:8080/completion",
              json={"prompt": prompt, "n_predict": 4096, "temperature": 0.7,
                    "stop": ["<|return|>", "<|end|>"]})

Token-Budget großzügig wählen. Die Trainingsziele haben im Median 2.772 Zeichen Denkteil plus 6.300 Zeichen Antwort (~2.700 Token). Auf schwierigen, offenen Fragen denkt das Modell allerdings deutlich länger — beobachtet wurden 15.000–20.000 Zeichen allein im <think>-Block. Unter ~4.000 Token kommt dort oft keine Antwort mehr, weil das Modell noch abwägt. Antwortteil = alles nach </think>.

Wer das saubere Format braucht, muss den Adapter mit korrekt gerenderten Zielen neu trainieren: Assistant-Inhalt explizit in den final-Kanal legen (<|channel|>final<|message|>…), statt das Template ohne Kanalangabe rendern zu lassen.

Wie gemergt wurde

Unsloths save_pretrained_merged ist für gpt-oss nicht verwendet worden — es schrieb einen PEFT-Wrapper statt gemergter Gewichte. Stattdessen ein eigener Streaming-Merge (merge_lora_streaming.py, nur torch + safetensors, CPU):

MXFP4-Blöcke dequantisieren (blocks [E,out,G,16] + scales [E,out,G], Wert = FP4_VALUES[nibble] · 2^(scale−127)), Ergebnis [E, in, out]
Delta = B @ A · (α/r) in fp32 addieren (delta.T für Experten, ohne Transposition für Attention), einmal am Ende auf bf16 runden
Als bf16 im vanilla-Layout schreiben → convert_hf_to_gguf.py --outtype bf16 → llama-quantize … Q8_0

Verifikation (jede Prüfung hat einen Fehler gefunden oder ausgeschlossen):

Prüfung	Ergebnis
Dequantisierung gegen unabhängige elementweise Referenz	`max abs diff = 0.0`
Delta-Platzierung / Transposition	max rel. Fehler 0,0038 (bf16-Rundung)
Abdeckung	9.360 / 9.360 Module, 216 / 216 Ziel-Tensoren
Stichproben unabhängig nachgerechnet	10 / 10
Struktur	72 fusionierte Expert-Tensoren, keine `lora_`/`base_layer`-Altlasten, `quantization_config` entfernt
GGUF-Konversion	687 Tensoren, 233,8 GB bf16 → Q8_0 8,51 bpw

Der Abdeckungszähler ist nicht Kosmetik: down_proj ist quadratisch (2880×2880), eine falsche Transposition erzeugt keinen Shape-Error, sondern Kauderwelsch.

Bewertung — gemessen, mit klaren Grenzen

Blind-Judge (GLM-5.2), 15 offene Trading-Strategie-Fragen, Reihenfolge pro Frage permutiert, beide Varianten aus einem Modell-Load (Adapter an/aus) — identische Gewichte, Quantisierung, Sampling. Bewertet wurde der Antwortteil, nicht das Denken; dafür wurde die Deliberationsphase per Prefill übersprungen (answer_prefilled-Eval, kein Test des natürlichen Chat-Verhaltens).

Gepaarter Vorzeichentest, Δ = Fine-Tune minus Basis:

Kriterium	Δ	v>b : v<b	p
realism	+1,20	12 : 3	0,035
mechanism	+1,13	10 : 4	0,180
risk_awareness	+0,53	6 : 4	0,754
falsifiability	+0,47	9 : 3	0,146
originality	−0,33	6 : 7	1,000
actionability	−0,93	5 : 10	0,302
Gesamt (90 Vergleiche)	+0,34	48 : 31	0,071

Was das heißt: Das Fine-Tune liefert keine originelleren Ideen — bei originality liegt es leicht hinten. Es antwortet nüchterner (weniger Überversprechen), verliert dafür an Umsetzbarkeit (weniger konkrete Regeln und Parameter).

Ehrliche Einordnung der Signifikanz: realism ist der einzige Einzelwert unter p = 0,05, hält aber der Bonferroni-Korrektur nicht stand (Schwelle 0,05/6 = 0,0083). Bei sechs geprüften Kriterien entspricht ein p = 0,035 etwa der Zufallserwartung. Belastbar bleibt ein schwacher positiver Gesamttrend (p = 0,071).

Warum so wenig Wirkung — Ursache offen. Naheliegend wäre „Teacher nicht überlegen", das ist aber widerlegt: Artificial Analysis Intelligence Index v4.1 gibt GLM-5.2 (max) 51 und gpt-oss-120b (high) 24. Der Lehrer ist dem Schüler mehr als doppelt überlegen, Fähigkeitstransfer wäre also grundsätzlich möglich gewesen. Die Ursache liegt damit im Trainings-Aufbau, nicht in der Teacher-Wahl — Kandidaten: die fehlerhafte Kanal-Renderung der Ziele, packing=True ohne Grenzmaskierung, zu geringe Adapter-Kapazität (r=16 → Delta nur 2,3 %), oder fehlende Completion-only-Loss-Maskierung.

Beide Modelle machen weiterhin gravierende Fachfehler (Judge-Zitate): Lookahead-Bias (shift(-21) für aktuellen Carry), Fixkosten von $1 Mrd. AUM auf einen $40-Mio-Fonds skaliert, erfundene SEC-Regeln, halluzinierte Marktinfrastruktur, fehlende Kapazitäts- und Decay-Analysen. Nicht ohne fachliche Prüfung für Anlageentscheidungen verwenden.

Herkunft und Lizenz

Apache 2.0, wie Basismodell und Trainingsdaten. Der Adapter liegt unter dustin2050/finrag-gpt-oss-120b-v2.

dustin2050/finrag-gpt-oss-120b-v2-GGUF

FinRAG Trading Expert — gpt-oss-120b · Q8_0 GGUF