Drei weitere Kandidaten geprueft, alle drei abgelehnt

Ministral-3-3B: Architektur mistral3 steht nicht in der Liste des
rkllm-Toolkits, dazu FP8-Gewichte -- nie konvertiert. Config auf Llama
umbiegen waere moeglich gewesen, aber ein falsch eingelesenes Modell
haette plausiblen Unsinn produziert.

Phi-4-mini: konvertiert (5,06 GB), laedt aber nicht auf der NPU.
partial_rotary_factor 0.75 ergibt 48 LongRoPE-Faktoren, die Runtime
erwartet starr head_dim/2 = 64. Rockchips "Phi3" meint Phi-3-mini.

SmolLM3-3B: laeuft, in 2 von 3 Faellen schneller als Qwen3, scheitert
aber inhaltlich -- 13 statt 61 Todos, JSON-Schluessel als
Listeneintraege, Englisch-Drift im deutschen Text.

rkllm_server.cpp: Chat-Template kommt jetzt aus der Umgebung
(RKLLM_TMPL_SYSTEM / _USER_PRE / _USER_POST), Defaults = bisheriges
ChatML-Verhalten, mit Qwen3 gegengeprueft. Damit ist der naechste
Kandidat eine Drop-in-Zeile statt einer Neuuebersetzung.

Doku: Changelog 2026-09-29 (4) mit Messwerten und allen Fallstricken,
Kapitel 05 um Architektur-Vorpruefung und Template-Konfiguration
erweitert. Messstrecke: Zeitlimit 45 -> 90 Minuten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017A91sWU5aWrqZ2DWNTLVph

docs/05-llm-analyse.md

@@ -391,6 +391,29 @@ flowchart LR
 Die Konvertierung eines neuen Modells passiert **nicht** auf dem Board (kein CUDA), sondern auf dem PC
 mit `tools/rkllm-qwen35/` — rkllm-toolkit-Version muss exakt zur Runtime auf dem Board passen.
 
+### Bevor ein Kandidat geladen wird: Architektur prüfen
+
+Das rkllm-Toolkit 1.3.0 kennt nur diese Architekturen (aus `loader.so`/`common.so` extrahiert):
+
+```
+Baichuan, ChatGLM, Deepseek, DeepseekOCR, Gemma/2/3/3n/4, InternLM2, Llama,
+MiniCPM/3, Phi/Phi3, Qwen2/2VL/2.5VL/3/3VL/3.5, RWKV7, SmolLM3, TeleChat/2
+```
+
+`curl -sL https://huggingface.co/<repo>/raw/main/config.json` und `architectures` dagegenhalten —
+Sekunden statt Gigabyte. **Gelistet heißt aber nicht lauffähig:** Phi-4-mini trägt `Phi3ForCausalLM`,
+scheitert aber an der Geometrie (partielle Rotary Embeddings, 48 statt 64 LongRoPE-Faktoren), weil
+Rockchips Phi3-Pfad auf Phi-3-mini zugeschnitten ist. Ebenso zu prüfen: `quantization_config` —
+FP8-Gewichte (z. B. Ministral 3) kann das Toolkit nicht lesen.
+
+### Chat-Template aus der Umgebung
+
+rkllm wendet das HF-Template **nicht** selbst an. Ohne passende Marker bekommt das Modell den nackten
+Prompt und faselt generisches Füllmaterial. Seit 2026-09-29 kommen die Marker aus der Umgebung:
+`RKLLM_TMPL_SYSTEM`, `RKLLM_TMPL_USER_PRE`, `RKLLM_TMPL_USER_POST` (Defaults = ChatML, also unverändert
+für Qwen und Gemma3). `\n`/`\t` werden im Server dekodiert, weil systemd-`Environment=` keine echten
+Umbrüche kann — und aus demselben Grund beim Schreiben des Drop-ins **zitiertes Heredoc statt `printf`**.
+
 ### Denk-Modelle (Qwen3.5 und jünger)
 
 Modelle mit Denk-Modus liefern sonst Gedankengang statt JSON. `RKLLMInput.enable_thinking = false` genügt
@@ -405,3 +428,9 @@ langsamer**, Zusammenfassungen auf ein Drittel bis Viertel gekürzt, und von 61
 hält die JSON-Vorgabe nicht durch (13 Parse-Fehler mit Wiederholungen). Die Prosa selbst war nicht
 schlechter. **Qwen3-4B bleibt produktiv.** Lehre: bei diesem Aufbau entscheidet nicht der Benchmark,
 sondern ob ein Modell über lange deutsche Transkripte hinweg sauberes JSON liefert.
+
+Am selben Tag zusätzlich geprüft: **Ministral-3-3B** (Architektur `mistral3` nicht unterstützt, dazu
+FP8-Gewichte — nie konvertiert), **Phi-4-mini** (konvertiert, aber `rkllm_init failed` wegen partieller
+Rotary Embeddings) und **SmolLM3-3B** (läuft, stellenweise schneller als Qwen3, scheitert aber inhaltlich:
+13 statt 61 Todos, JSON-Schlüssel als Listeneinträge, Englisch-Drift). Drei Kandidaten, drei Absagen —
+Details im Changelog 2026-09-29 (4).