gfx115157 Fallstrickenach Symptom sortiert

Fallstricke auf Strix Halo

Die anderen Seiten sind nach Thema sortiert — Ollama, vLLM, Bildgenerierung. Wenn etwas kaputt ist, kennt man aber das Thema nicht, man kennt die Meldung im Terminal. Diese Seite ist deshalb umgedreht: Suchen nach dem, was man sieht. Die Fehlermeldung, die falsch gesetzte Einstellung, das Verhalten, das einen stutzig macht.

Schwere

Bereich

57 von 57 Fallstricken

Schweregrade

blockierend21: Stoppt Start oder Betrieb. Ohne Fix geht nichts.
tückisch21: Läuft still weiter — mit falschem, leerem oder fehlendem Ergebnis. Nichts crasht, aber etwas stimmt nicht.
wissenswert15: Kein Fehler. Aber eine Überraschung, wenn man sie nicht kennt.

Allgemein4

Connection error, obwohl der Server läuft und curl von außen funktioniert

Allgemeintückisch

Ursache: `localhost` löst zuerst auf `::1` (IPv6) auf, die Engine lauscht aber nur auf IPv4. Der Verbindungsaufbau geht gegen eine Adresse, auf der nichts sitzt — während `curl` auf `127.0.0.1` problemlos durchgeht und der Dienst damit als gesund aussieht.
Lösung: In der Client-Konfiguration `127.0.0.1` statt `localhost` schreiben. Kostet eine Zeile und spart die halbe Stunde Fehlersuche.

Aus dem laufenden Betrieb

Die Inferenz-API ist im Netz erreichbar, ohne dass ein Passwort verlangt wird

Allgemeintückisch

Ursache: `--host 0.0.0.0` (vLLM) und `OLLAMA_HOST=0.0.0.0:11434` (Ollama) öffnen die API auf allen Interfaces. Diese Engines haben standardmäßig keine Authentifizierung.
Lösung: So lange wie möglich auf `127.0.0.1` lassen. Für Gegenstellen firewalld-Rich-Rules auf eine IP setzen, nicht das Netz öffnen.

vllm.md · Sicherheitshinweis · setup.ts Schritt 9Details auf /setup →

Das Log besteht fast nur aus Prozentzeichen, die eigentliche Meldung ist nicht mehr zu finden

Allgemeinwissenswert

Ursache: Fortschrittsbalken schreiben bei jedem Takt eine neue Zeile. Ein 19-GB-Pull erzeugte rund 57 KB Ausgabe, die fast ausschließlich aus Prozentzeichen besteht.
Lösung: Nicht `tail` auf das Log setzen, sondern nach Statuszeilen greppen: `grep -a "EXIT\|=== PULL" /tmp/ollama_pull.log`.

setup.ts · Schritt 4Details auf /setup →

Die eigenen tok/s-Werte sind weit entfernt von den Zahlen, die im Netz für das Modell stehen

Allgemeinwissenswert

Ursache: Public-Benchmark-Zahlen sind fast immer Peak-Durchsatz bei hoher Parallelität — etwa 100 gleichzeitige Requests. Die Latenz einer einzelnen Anfrage ist davon unbeeindruckt.
Lösung: Bei Unified Memory und Einzelnutzung ist Latenz das Ziel, nicht Durchsatz. Nur eigene Messungen unter gleichen Bedingungen vergleichen.

vllm.md · ErwartungsmanagementDetails auf /vllm →

System & Kernel5

Der Rechner ist mitten im Download einfach weg — „No route to host“, ARP INCOMPLETE

System & Kernelblockierend

Ursache: Fedora Workstation suspendiert bei Inaktivität (Ruhezustand). Der laufende Modell-Download wird dabei eingefroren — von außen sichtbar als „No route to host“ und ARP INCOMPLETE.
Lösung: `sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target`. Ob es schon passiert ist: `journalctl -b -u systemd-suspend | tail`.

setup.ts · Schritt 2Details auf /setup →

OOM schon beim Laden eines großen Modells — der RAM ist doch voll genug

System & Kernelblockierend

Ursache: Ohne reservierte GTT-Region kann die GPU keine großen Buffer anlegen. Der freie Systemspeicher ist dafür nicht ansprechbar; es fehlt die explizit reservierte Zone.
Lösung: Kernel-Parameter setzen — Beispiel 128 GB: `amdgpu.gttsize=100` und `ttm.pages_limit=26214400` — dann `grub2-mkconfig -o /boot/grub2/grub.cfg` und Reboot.

vllm.md · Host konfigurierenDetails auf /vllm →

Ohne die Kernel-Parameter läuft alles — nur vLLM nicht

System & Kernelblockierend

Ursache: Das IOMMU ist standardmäßig aktiv und kostet 15–25 % Speicherbandbreite. Zusätzlich fehlt ohne `amdgpu.gttsize` die reservierte Zone für große Modelle.
Lösung: `amd_iommu=off` plus `amdgpu.gttsize` und `ttm.pages_limit` in die Kernel-Commandline.

vllm.md · Host konfigurierenDetails auf /vllm →

`amd_iommu=off` reißt andere Dinge mit

System & Kernelblockierend

Ursache: VFIO-Gäste — etwa eine Windows-VM mit durchgereichter GPU — brauchen das IOMMU zwingend. Die Kernel-Parameter gelten global, es gibt keine Aufteilung pro Prozess.
Lösung: Von dieser Kombination absehen oder die VM vorher entfernen. Wer beides will, muss sich für eines entscheiden.

vllm.md · Host konfigurierenDetails auf /vllm →

Zufällige Hänger und allgemeine Instabilität

System & Kernelblockierend

Ursache: Kernel-Version unter 6.18.4.
Lösung: Kernel aktualisieren — unterhalb dieser Version ist das Setup nicht zuverlässig betreibbar.

vllm.md · TroubleshootingDetails auf /vllm →

Ollama8

`Error: pull model manifest: file does not exist`

Ollamablockierend

Ursache: Der angegebene Tag existiert nicht — im konkreten Fall war `qwen3-coder:80b` empfohlen worden.
Lösung: Tags vorher in der Bibliothek verifizieren: `https://ollama.com/library/<modell>/tags`. Größenordnungen erfinden bringt hier nichts.

setup.ts · Schritt 3Details auf /setup →

Ein anderer Rechner im Netz kommt nicht an die Engine heran

Ollamablockierend

Ursache: Ollama lauscht standardmäßig nur auf `127.0.0.1`.
Lösung: `OLLAMA_HOST=0.0.0.0:11434` im Override, dann die Gegenstelle per firewalld-Rich-Rule freigeben — den Port nur für eine IP öffnen, nicht fürs ganze Netz.

setup.ts · Schritt 9Details auf /setup →

`systemctl cat ollama` → „No files found for ollama.service“, obwohl die Binary installiert ist

Ollamatückisch

Ursache: Das Installationsskript lädt rund 700 MB. Reißt dabei die SSH-Sitzung ab, liegt die Binary unter `/usr/local/bin/ollama` — aber der systemd-Dienst und der Benutzer `ollama` wurden nie angelegt.
Lösung: Installation immer von der Sitzung entkoppeln (`nohup`) und die drei Prüfungen durchlaufen lassen: `systemctl list-unit-files | grep ollama`, `systemctl is-active ollama`, `curl -s -o /dev/null -w "%{http_code}" http://localhost:11434/api/tags`.

setup.ts · Schritt 1Details auf /setup →

Alles ist zäh, aber es läuft — niemand meldet einen Fehler

Ollamatückisch

Ursache: Das Modell liegt auf der CPU, die iGPU wird gar nicht genutzt.
Lösung: `ollama ps` — die Spalte PROCESSOR muss „100% GPU“ zeigen. Im Log nach `inference compute library=ROCm compute=gfx1151` suchen. Das ist der wichtigste Check überhaupt.

setup.ts · Schritt 5Details auf /setup →

Nach einem Update sind die optimierten Einstellungen spurlos weg

Ollamatückisch

Ursache: Die Umgebungsvariablen standen direkt in der Unit-Datei; das nächste Update überschreibt sie.
Lösung: Drop-in unter `/etc/systemd/system/ollama.service.d/override.conf`. Kontrolle, ob die Variablen wirklich greifen: `journalctl -u ollama -b | grep -oE "OLLAMA_FLASH_ATTENTION:[a-z]+|OLLAMA_CONTEXT_LENGTH:[0-9]+"`.

setup.ts · Schritt 7Details auf /setup →

Dasselbe Modell liefert über Ollama deutlich schlechtere Ergebnisse als über llama-server

Ollamatückisch

Ursache: DeepSeek V4 Flash: über Ollama 8/10 Tool-Call-Score bei 14,6 s Antwortzeit, über llama-server 10/10 bei 8,4 s. Der Unterschied liegt am Stack, nicht am Modell.
Lösung: Für Agenten llama-server direkt anbinden — opencode mit `npm:@ai-sdk/openai-compatible` und `options: { thinking: { type: "enabled", budgetTokens: 8192 } }`.

QWEN38-STRIX-HALO.md · Tool-Call-VergleichDetails auf /qwen38 →

Vulkan-Backend fehlt, die iGPU wird verworfen: „dropping integrated GPU; to enable, set OLLAMA_IGPU_ENABLE=1“

Ollamawissenswert

Ursache: Ältere Strix-Halo-Anleitungen empfehlen Vulkan, weil ROCm lange nicht lief. Das ist überholt: Ollama 0.32.5 nutzt hier ROCm und verwirft Vulkan aktiv. Vulkan ist in diesem Setup inkompatibel.
Lösung: Nicht eingreifen — ROCm ist der funktionierende Pfad. Der OpenCL-Pfad steht zusätzlich über `OLLAMA_OPENCL=1` zur Verfügung.

setup.ts Schritt 5 · AGENTS.md · models.ts optimizationTipsDetails auf /setup →

KV-Cache auf q8_0 gestellt, um Speicher zu sparen — es wurde langsamer

Ollamawissenswert

Ursache: Bei 94 GB Unified Memory ist der gesparte Speicher nicht knapp, die Quantisierung kostet aber Rechenzeit: 69,1 → 63,7 tok/s, das sind −8 %.
Lösung: KV-Cache in fp16 lassen. Quantisieren spart hier nichts, was fehlt.

setup.ts · Schritt 7 OptimierungstabelleDetails auf /setup →

llama.cpp8

Lockups, besonders in Kombination mit MTP-Anhängen

llama.cppblockierend

Ursache: `--split-mode tensor` (upstream Issue #27122).
Lösung: `--split-mode layer` verwenden — das ist ohnehin der Default.

QWEN38-STRIX-HALO.md · Issue #27122Details auf /qwen38 →

Bilder werden nicht verstanden, obwohl die mmproj-Datei vorhanden ist

llama.cppblockierend

Ursache: Multimodal ist auf AMD AI Max defekt (upstream Issue #27124). Die Projektionsdatei liegt brav im Verzeichnis, der Textpfad läuft einwandfrei — nur das Bild kommt nicht an.
Lösung: Vorher prüfen, ob das eigene Build Multimodal meldet. Für Bildaufgaben ist dieses Setup derzeit nicht zu gebrauchen.

QWEN38-STRIX-HALO.md · Issue #27124Details auf /qwen38 →

Die Flags werden nicht erkannt, das Modell startet nicht

llama.cppblockierend

Ursache: Das installierte System-llama.cpp ist zu alt.
Lösung: Build ≥ b10419 verwenden.

QWEN38-STRIX-HALO.md · Versionsanforderung

Prefill bricht um den Faktor 20 ein

llama.cpptückisch

Ursache: KV-Cache in `q4_0` oder `q4_1` (upstream Issue #27109). Es crasht nichts — die Eingabe verarbeitet nur gefühlt in Zeitlupe.
Lösung: `--cache-type-k bf16 --cache-type-v bf16`.

QWEN38-STRIX-HALO.md · Issue #27109Details auf /qwen38 →

Abstürze und Performance-Einbrüche ohne erklärende Meldung

llama.cpptückisch

Ursache: `-fa 1` und `--no-mmap` fehlen. Auf dieser Hardware sind beide Flags Pflicht, nicht optional.
Lösung: Beide Flags immer setzen.

QWEN38-STRIX-HALO.md · Pflicht-FlagsDetails auf /qwen38 →

Das content-Feld ist leer, obwohl sichtbar Tokens verbraucht wurden

llama.cpptückisch

Ursache: Das Reasoning-Modell antwortet standardmäßig mit Thinking-Stufe `xhigh`. Bei knappem `max_tokens` geht die eigentliche Antwort im Reasoning auf.
Lösung: `chat_template_kwargs: {"thinking": false}` oder `reasoning_effort: "low"` — oder `max_tokens` großzügig bemessen.

QWEN38-STRIX-HALO.md · halogen.ts Fallstrick 4Details auf /halogen →

Der Kontext reicht plötzlich nicht mehr, obwohl die Unterhaltung kurz ist

llama.cpptückisch

Ursache: `preserve_thinking: true` sendet das Reasoning in jeder Runde mit und frisst damit den Kontext auf.
Lösung: Nur setzen, wenn das Reasoning über die Runden hinweg wirklich erhalten bleiben muss.

QWEN38-STRIX-HALO.md · preserve_thinking

DeepSeek V4 Flash passt nicht rein, obwohl 117 GB frei gemeldet werden

llama.cpptückisch

Ursache: 90 GB Modell plus 11 GB Drafter sind rund 101 GB bei `--no-mmap`. Wenn Ollama zu dem Zeitpunkt noch ein anderes Modell hält, ist der Platz längst belegt.
Lösung: Vorher `ollama ps` prüfen und das alte Modell entladen lassen.

QWEN38-STRIX-HALO.md · DeepSeek V4 Flash

vLLM15

`rocm-smi` findet im Container nichts

vLLMblockierend

Ursache: `--device /dev/kfd --device /dev/dri` fehlen, oder der Nutzer ist nicht in den Gruppen `video` und `render`.
Lösung: Beide Devices durchreichen und die Gruppen setzen.

vllm.md · TroubleshootingDetails auf /vllm →

Rootless Podman startet den Container nicht

vLLMblockierend

Ursache: Benannte Gruppen sind im rootless Modus nicht verfügbar.
Lösung: `--group-add keep-groups` an die Container-Flags setzen.

vllm.md · TroubleshootingDetails auf /vllm →

Crash beim Initialisieren, Traceback mit „CUDA graph capture“ (RMSNorm / AITER)

vLLMblockierend

Ursache: Der AITER-Kernel passt zum laufenden Build nicht.
Lösung: `VLLM_ROCM_USE_AITER=0` setzen.

vllm.md · TroubleshootingDetails auf /vllm →

Bare-Metal-Build: „undefined symbol“ oder Crash beim Import

vLLMblockierend

Ursache: Mit GCC gebaute Erweiterungen sind ABI-inkompatibel zum Clang-gebauten PyTorch. Ein bekannter ABI-Bruch zwischen den Compiler-Frontends.
Lösung: `CC=clang CXX=clang++` setzen, ggf. `AR=llvm-ar RANLIB=llvm-ranlib`. In den TheRock-Nightly-Images ist das bereits gelöst.

vllm.md · Weg C Bare MetalDetails auf /vllm →

Build bricht ab, weil der Bitcode-Pfad fehlt

vLLMblockierend

Ursache: Die TheRock-Nightlies enthalten den Bitcode-Pfad nicht.
Lösung: `HIP_DEVICE_LIB_PATH` auf das Verzeichnis mit den `.bc`-Dateien setzen.

vllm.md · Weg C Bare MetalDetails auf /vllm →

Der `bitsandbytes`-Wheel von PyPI funktioniert unter ROCm nicht

vLLMblockierend

Ursache: Der offizielle Wheel ist nicht ROCm-fähig.
Lösung: ROCm-Fork verwenden (`vllm-project/bitsandbytes` oder `grao23/bitsandbytes`, mit `--force-reinstall`). Für gfx1151 ist die native bitsandbytes-Unterstützung ab vLLM 0.23 der einfachste Weg.

vllm.md · Weg B eigenes ImageDetails auf /vllm →

Läuft an, aber nach einer Weile Betrieb geht der Speicher aus

vLLMtückisch

Ursache: Der KV-Cache wächst mit der Zahl gleichzeitiger Sequenzen. Ein zu hoher Wert für `--max-num-seqs` überlebt den Start, aber nicht den Lastfall.
Lösung: `--max-num-seqs` senken — 1 für Einzelnutzung, 4–8 für Agenten.

vllm.md · TroubleshootingDetails auf /vllm →

Trotz korrekt gesetzter Parameter sind nur rund 64 GB nutzbar

vLLMtückisch

Ursache: Bekannter Bug in ROCm-Nightlies.
Lösung: Auf eine neuere Nightly wechseln. An den eigenen Parametern liegt es nicht.

vllm.md · TroubleshootingDetails auf /vllm →

Nach einem Image-Update plötzliche, seltsame Fehler

vLLMtückisch

Ursache: Der Compile-Cache unter `~/.cache/vllm` passt nicht mehr zum neuen Image.
Lösung: `rm -rf ~/.cache/vllm`.

vllm.md · TroubleshootingDetails auf /vllm →

Das Modell lädt durch und liefert Kauderwelsch

vLLMtückisch

Ursache: Falsches Attention-Backend oder eine Quantisierung, die mit diesem Build nicht zusammenpasst.
Lösung: Attention-Backend umstellen und eine andere Quantisierungsvariante probieren.

vllm.md · TroubleshootingDetails auf /vllm →

Die erste Inferenz dauert extrem lange

vLLMwissenswert

Ursache: Triton-Kernel werden kompiliert.
Lösung: Nicht wundern — ab der zweiten Anfrage ist es schnell. Beim Messen den ersten Lauf verwerfen.

vllm.md · TroubleshootingDetails auf /vllm →

„unrecognized environment variable“ beim Start

vLLMwissenswert

Ursache: Das Image ist zu alt für die Variable — im konkreten Fall `PYTORCH_TUNABLEOP_ENABLED`.
Lösung: Image aktualisieren.

vllm.md · TroubleshootingDetails auf /vllm →

`podman pull` schlägt für das erwartete Image-Tag fehl

vLLMwissenswert

Ursache: Die Tags `stable` und `latest` wurden umbenannt.
Lösung: Das aktuelle Tag im vLLM-Dokuindex nachsehen, nicht aus dem Gedächtnis pullen.

vllm.md · Image-TagsDetails auf /vllm →

Der alte Notnagel `HSA_OVERRIDE_GFX_VERSION=11.5.1` bringt nichts

vLLMwissenswert

Ursache: gfx1151 wird nativ erkannt; die Override-Variante stammt aus der Zeit vor der Unterstützung.
Lösung: Weglassen. Wenn es ohne nicht läuft, ist die Ursache eine andere.

vllm.md · VoraussetzungenDetails auf /vllm →

`--max-num-seqs 1` für Stabilität gesetzt — jetzt ist der Agent träge

vLLMwissenswert

Ursache: Für Einzelnutzung ist 1 richtig. Agenten stellen aber mehrere parallele Requests; die Stärke von vLLM bleibt dann ungenutzt.
Lösung: Für Agenten 4–8 setzen.

vllm.md · TuningDetails auf /vllm →

Bildgenerierung7

„Conditioner model tensor ... q_norm.weight not in model metadata“

Bildgenerierungblockierend

Ursache: Der Textencoder passt nicht zum Diffusionsmodell. Bei Qwen-Image-Modellen passiert das schnell, weil mehrere Modelle ähnlich heißen.
Lösung: Encoder-Zuordnung prüfen: Qwen-Image 20 B → `qwen_2.5_vl_7b.safetensors`; Flux.2 → `clip_l.safetensors` + `mistral_3_small_flux2.safetensors`.

media.ts · Encoder-ZuordnungDetails auf /media →

Build bricht ab: „missing components: glslangValidator“

Bildgenerierungblockierend

Ursache: `glslang` und `spirv-headers-devel` sind nicht installiert.
Lösung: `sudo dnf install glslang spirv-headers-devel`.

media.ts · Build-VoraussetzungenDetails auf /media →

ComfyUI mit ROCm hängt die GPU fest

Bildgenerierungblockierend

Ursache: ComfyUI bricht bei Fehlern nicht sauber ab und lässt die GPU in einem ungültigen Zustand zurück.
Lösung: Mit ROCm-ComfyUI nicht experimentieren, wenn die Maschine wichtig ist. `stable-diffusion.cpp` direkt verwenden.

media.ts · Gründe gegen ROCm für BildDetails auf /media →

PyTorch mit ROCm findet die GPU nicht oder stürzt ab

Bildgenerierungblockierend

Ursache: Die PyTorch-ROCm-Builds kennen `gfx1151` nicht.
Lösung: Vulkan/RADV-Pfad über stable-diffusion.cpp statt PyTorch.

media.ts · gfx1151 UnterstützungDetails auf /media →

„Failed to allocate pinned memory“ ab 1024 × 1024

Bildgenerierungtückisch

Ursache: Vulkan/RADV erlaubt keine einzelne Zuweisung über 2 GB (`maxMemoryAllocationSize = 2147483648`). Der freie Speicher ist nicht das Problem — gemeldet wird eine völlig andere Grenze, und die sucht man im RAM vergeblich.
Lösung: Unterhalb von 1024 × 1024 bleiben (z. B. 1024 × 576) oder den gepinnten Pfad mit `--offload-to-cpu` umgehen.

media.ts · Vulkan-RADV LimitDetails auf /media →

`--offload-to-cpu` bringt fast nichts

Bildgenerierungwissenswert

Ursache: Bei Unified Memory ist nicht die Bandbreite das Limit, sondern die reine Rechenleistung. Gemessen: 16,59 s → 14,72 s, also nur 11 % langsamer.
Lösung: Offload nur bei echtem Speicherbedarf einsetzen, nicht als Performance-Hebel.

media.ts · Offload-MessungDetails auf /media →

Schrift im Bild ist Unsinn, geometrische Angaben werden ignoriert

Bildgenerierungwissenswert

Ursache: Qualitätsgrenze dieser Modellgeneration — kein Bug im Setup.
Lösung: Text nicht vom Modell rendern lassen; Bild ohne Schrift erzeugen und selbst beschriften.

media.ts · GrenzenDetails auf /media →

Modellwahl3

Das größere Modell ist schlechter als sein kleiner Bruder

Modellwahltückisch

Ursache: Im Benchmark wiederholt beobachtet: laguna-xs schlägt laguna-s, ornith:9b schlägt ornith:35b. Die wiederkehrende Schwäche großer Modelle in diesem Setup ist eigenmächtige Parameterinterpretation.
Lösung: Immer auch das kleinere Modell gegentesten, bevor eine Größe festgelegt wird.

AGENTS.md · Erkenntnis 4

Qwen3.8-27B bleibt bei 7,7 t/s, obwohl 128 GB Unified Memory da sind

Modellwahlwissenswert

Ursache: Dichtes Modell: pro Token müssen alle Gewichte gelesen werden, und Q8_0 ist bandbreitenhungrig. Der Speicher ist groß, die Bandbreite ist es nicht.
Lösung: `IQ4_XS` statt `Q8_0` bringt 16,5 t/s, mit MTP-Drafter 25,5 t/s — das sind +231 % gegenüber dem Ausgangswert.

QWEN38-STRIX-HALO.md · QuantisierungsvergleichDetails auf /qwen38 →

95 GB Modell läuft 15,3 t/s — die Bandbreite würde nur 2,3 t/s erlauben

Modellwahlwissenswert

Ursache: Bei MoE sagt die Dateigröße nichts über die aktiven Parameter. Gerechnet werden pro Token nur rund 5,4 GB, nicht 95.
Lösung: Dateigröße nicht als Geschwindigkeitsindikator nehmen — aktive Parameter zählen.

QWEN38-STRIX-HALO.md · MoE-Rechnung

Agentenbetrieb7

Der Tool-Call kommt als reiner Text statt als strukturiertes Call-Pair (`<function=...>`)

Agentenbetriebblockierend

Ursache: `qwen3-coder:30b` im Agentenbetrieb — Totalausfall, kein Randfall.
Lösung: Anderes Modell oder den Toolfix-Proxy dazwischenschalten: Port 11435 → 11434, übersetzt alle Textdialekte in echte Tool-Calls und ist fail-open für Unparsebares. Debug mit `TOOLFIX_DEBUG=1`.

models.ts · modelErrors · AGENTS.md Erkenntnis 2

Aus `postgres` wird `postgresql`

Agentenbetriebtückisch

Ursache: `qwen3.6:35b` interpretiert Parameter eigenmächtig — semantisch oft richtig, für Tool Calling falsch. Der Aufruf schlägt fehl, weil der Dienst so nicht heißt.
Lösung: Parameter im Prompt exakt vorgeben oder auf ein Modell ohne dieses Muster wechseln.

models.ts · modelErrors

Aus `plex` wird `plexmediaserver`

Agentenbetriebtückisch

Ursache: `laguna-s-2.1` zeigt dasselbe Muster wie der postgres-Fall — zusätzlich verschwindet die Parallelität. Und das bei einem 5× größeren Modell als der kleine Bruder.
Lösung: Kleineres Modell testen: laguna-xs schlägt laguna-s.

models.ts · modelErrors

10/10 im Einzeltest, 0/6 in der End-to-End-Kette

Agentenbetriebtückisch

Ursache: `glm-4.7-flash`: kaputter langer Kontext fällt im Einzelaufruf schlicht nicht auf. Der Einzeltest ist nicht falsch, aber er misst das Falsche.
Lösung: Immer Ketten testen, nicht Einzelaufrufe. Für langen Kontext ist das Modell in diesem Setup unbrauchbar.

AGENTS.md · Erkenntnis 1

Der Chatverlauf wird still abgeschnitten, ohne Fehlermeldung

Agentenbetriebtückisch

Ursache: Ollama liefert 64K Kontext, opencode deklarierte ursprünglich 262K. Die Diskrepanz führt zum stillen Abschneiden des Verlaufs.
Lösung: Beidseitig 65536 setzen (siehe `override.conf`). Kein zusätzliches Drop-in — das überschreibt die Einstellung sonst wieder.

AGENTS.md · Erkenntnis 3

Aus „3 Hosts prüfen“ wird ein einziger Aufruf

Agentenbetriebwissenswert

Ursache: `laguna-xs-2.1` bündelt die Prüfung nicht in einem Schritt. Der Agent holt den Rest in den Folgerunden nach — es geht nichts verloren, es kostet nur Runden.
Lösung: Explizit mehrere Aufruf in einem Zug verlangen oder mit dem Modell leben.

models.ts · modelErrors

Der Agent schreibt keine Dateien

Agentenbetriebwissenswert

Ursache: opencode ist standardmäßig read-only ohne Nachfrage; Schreiben und Edits müssen per Prompt bestätigt werden (`opencode.jsonc` → `permission`).
Lösung: Für headless-Benchmarks lässt sich das per Skript vorab umschalten.

AGENTS.md · Sichtbarkeit / Permissions

Woher das stammt

Jeder Eintrag trägt seine Quelle unter der Lösung. Zusammengetragen aus AGENTS.md, CLAUDE.md, QWEN38-STRIX-HALO.md, vllm.md und den Datendateien halogen.ts, media.ts, setup.ts, models.ts. Nichts ist hier erfunden — was in keiner Quelle steht, steht auch nicht auf dieser Seite.