Bake-off M3: qwen3.8 vs qwen3.6 gemessen; Topologie korrigiert (Remote-GPU-Maschine)

Zwischenstand Bake-off (Antwortmodus, 35 Goldset-Fragen):
qwen3.8:27b 100% Zitier-Praezision / 94,3% Verweigerung korrekt / 32s;
qwen3.6:27B 94,3% / 85,7% / 43s (10 Regenerierungen) - klar schwächer.

Topologie korrigiert: 100.103.83.12:11435 ist die Remote-GPU-Maschine
(Tailscale, R9700), NICHT dieselbe wie die Dev-Maschine (deren localhost:
11434 ist ein eigener, fast leerer Ollama; URL-Nicht-auf-11434-Korrigieren
in Skill/README/Config präzisiert). bge-m3 auf der GPU-Maschine gepullt.

gemma4:26b-Lauf brach ab: auf der GPU-Maschine sterben seit dem Crash
alle llama-server-Loads (API 500 'exit status 1'), auch bge-m3. Neustart
dort noetig: sudo systemctl restart ollama. Danach mistral-small3.1:24b
und gemma4:12B ausstehen.

.agents/MEMORY.md

@@ -30,6 +30,24 @@ zu planen.
 - Der ATZ-Konfliktfall (28,5 vs. 27,5 %) wird korrekt mit ⚠ und beiden
   IDs beantwortet; harte Verweigerung (UStVA, Retrieval nicht leer)
   funktioniert.
+- **Topologie geklärt**: `100.103.83.12` ist die **Remote-GPU-Maschine**
+  (Entwicklungsumgebung, R9700, Tailscale); die Dev-Maschine selbst hat
+  einen eigenen, fast leeren Ollama auf localhost:11434 (dorthin ging der
+  erste bge-m3-Pull — auf die GPU-Maschine neu gepullt). Ziel-Instanz ist
+  ausschließlich `http://100.103.83.12:11435`.
+- **Bake-off M3, Zwischenstand** (Antwortmodus, 35 Fragen):
+  - `qwen3.8:27b` (Baseline): Zitier-Präzision **100 %**, Verweigerung
+    korrekt 94,3 %, erwartete Quelle 80,6 %, mean 32 s/p95 53 s,
+    4 Regenerierungen (`data/eval-qwen38.json`).
+  - `qwen3.6:27B`: Zitier-Präzision 94,3 % (2 dauerhafte Verstöße),
+    Verweigerung 85,7 %, mean 43 s/p95 89 s, 10 Regenerierungen —
+    klar schwächer (`data/eval-qwen36.json`).
+  - `gemma4:26b`: Lauf abgebrochen (GPU-Maschine crashte mitten im Lauf).
+  - `mistral-small3.1:24b`, `gemma4:12B`: ausstehend (Server-Neustart).
+  - Kandidaten sind installiert; Pro-Kandidat-Befehl:
+    `PV_ANSWER_MODEL=<tag> python3 -u -m agent.cli eval --answers --json-out data/eval-<name>.json`
+    (vor jedem Lauf vorheriges Modell entladen: `/api/generate` mit
+    `keep_alive: 0`; `python3 -u` gegen Buffering bei Absturz).
 
 ## Open issues / blockers
 
@@ -44,11 +62,13 @@ zu planen.
   Hebel: weniger Kontextblöcke (aktuell 8+6), schnellere Kandidaten.
 - **Cloud-Modelle** (`*:cloud` auf der Ollama-Instanz) sind für Antworten
   tabu (Anforderung: lokal). Nicht versehentlich konfigurieren.
-- **Bake-off M3**: Kandidaten sind bereits installiert — `qwen3.8:27B`,
-  `qwen3.6:27B`, `gemma4:26b`, `mistral-small3.1:24b`, `gemma4:12B`
-  (Latenz-Untergrenze). Achtung: Plan nennt mistral-small3.**2**:24b —
-  installiert ist 3.1; 3.2 ggf. noch pullen oder 3.1 als Proxy.
-  Pro Kandidat: `PV_ANSWER_MODEL=<tag> python -m agent.cli eval --answers`.
+- **Bake-off M3 — Remote-GPU-Maschine neu starten**: seit ~22:45 sterben
+  dort ALLE llama-server-Loads (auch bge-m3), der Ollama-Hauptprozess
+  antwortet noch (API-Requests 500 „llama-server process has terminated:
+  exit status 1"). Ursache vermutlich GPU-/Runner-Crash beim gemma4:26b-
+  Lauf. **Auf der GPU-Maschine ausführen:** `sudo systemctl restart ollama`
+  (ggf. vorher freien RAM prüfen; Ollama läuft dort auf Port 11435).
+  Danach laufen die restlichen Kandidaten ohne weiteres Zutun.
 - **M4 Odoo**: native LLM-Module des konkreten Odoo-19-Stands verifizieren
   (keine API-Annahmen); Option A (dünnes Custom-Modul + Service-API) ist
   Default.