Laguna S 2.1 INT4 auf 8×3090: Der schnelle Spezialist mit scharfen Kanten

Die meisten Modelle auf unserem 8×3090-Rig landeten bisher in einem von zwei Lagern: HY3 war klug und quälend langsam, frühe MiniMax-Quants waren schnell und fachlich nicht immer auf der Höhe. Wie sich diese Unterschiede unter langer Agentenlast auswirken, haben wir im Vergleich von MiniMax, HY3 und Qwen ausführlich beschrieben.

Laguna S 2.1 von Poolside durchbricht dieses Muster. Das Modell ist so schnell, dass wir zunächst die Messung geprüft haben. Zugleich beherrscht es ausgerechnet jene Aufgaben, an denen andere lokale Modelle oft scheitern: schwierige Fehler, Code-Reviews und lange Analysen ganzer Repositories.

Ein universeller Ersatz für diese Modelle ist Laguna trotzdem nicht. In ehrlichen Erfahrungsberichten taucht immer wieder das Wort „spiky“ auf: Je nach Aufgabe schwankt das Leistungsprofil ungewöhnlich stark. Nach unseren Tests verstehen wir, weshalb.

Dieser Artikel behandelt ausschließlich Laguna. Sämtliche Leistungswerte stammen von unserem Rig und wurden nicht aus der Modellkarte übernommen.

Was Laguna S 2.1 technisch ist

Poolside veröffentlichte Laguna S 2.1 am 21. Juli 2026 und beschrieb Architektur, Training und eigene Evaluationen im Release-Artikel. Zum Zeitpunkt unserer Tests war das Modell also wenige Tage alt. Entsprechend schnell änderten sich Gewichte, Konfigurationen und Runtime-Unterstützung.

Wir betrieben die offizielle Variante poolside/Laguna-S-2.1-INT4 mit diesen Eckdaten:

Merkmal	Wert
Architektur	117,6B MoE insgesamt, ungefähr 8,5B aktiv
Layer	48
Experten	256 geroutete Experten, Top-10 plus Shared Expert
Attention	12 Full-Attention- plus 36 Sliding-Window-Layer mit 512 Tokens
KV-Heads	8, Head-Dimension 128
Gewichte	Compressed-Tensors INT4, Gruppengröße 32, symmetrisch
Kernel-Pfad	Marlin W4A16 auf SM86
Lokale Größe	ungefähr 67 GiB in 15 Safetensors-Shards
Engine	vllm/vllm-openai:v0.25.1

Für den Decode ist die Zahl 117B weniger wichtig als die Zahl der pro Token aktiven Parameter. Laguna aktiviert ungefähr 8,5 Milliarden davon. Das Prinzip ähnelt Qwen3.6-35B-A3B: Ein dünn besetztes Mixture-of-Experts-Modell berührt für jedes Token nur einen Teil seiner Gewichte. Laguna besitzt allerdings deutlich mehr Gesamtparameter, und im getesteten Stand waren die gerouteten MLP-Gewichte zusätzlich auf vier Bit komprimiert.

Die lokale quantization_config erfasste vor allem die gerouteten w1-, w2– und w3-Gewichte. Attention-Projektionen, LM Head, Shared Expert und der dichte erste MLP-Layer standen auf der Ignore-Liste. Wir testeten daher keinen pauschalen Vier-Bit-Quant, sondern eine gezielte Kompression der speicherintensiven Bereiche. Dadurch blieb der Decode-Aufwand trotz 117 Milliarden Gesamtparametern ungewöhnlich niedrig.

Ein wichtiger Hinweis zum Reproduktionsstand

Unsere Messungen beziehen sich auf den am 26. Juli 2026 lokal getesteten 256K-Stand. Poolside ersetzte das INT4-Repository im August durch neue Gewichte und eine neue 1M-Konfiguration. Die aktuelle Commit-Historie und Modellkarte kennzeichnen diesen Checkpoint ausdrücklich als Nachfolger der früheren Fassung. Die folgenden Messwerte, YaRN-Overrides und Fehlerbilder dürfen deshalb nicht ungeprüft auf den heutigen Checkpoint übertragen werden.

Die Geschwindigkeit auf vier GPUs

TG bezeichnet hier die reine Token-Generierung im Single-User-Decode nach dem ersten Token. Für sämtliche Messungen verwendeten wir dasselbe Protokoll: einen Warm-up-Lauf, drei Messläufe, 256 Ausgabetokens, temperature=0 und Streaming. Die Time to First Token ist in den TG-Werten nicht enthalten.

TP4 war der praktische Sweet Spot

Topologie	TG bei kurzem Kontext	TG bei 100k aktivem Kontext	KV-Kapazität
TP4, FP8-KV, util 0.92	105,8	97,2	377.571 (1,44-fach bei 262k)
TP4, BF16-KV, util 0.96	109,1	85,6	394.028 (1,50-fach bei 262k)
TP2+PP3, BF16-KV, 6 GPUs	89,3	67,2	–

Schon 105,8 Token pro Sekunde bei kurzem Kontext sind für ein 117B-Modell auf Consumer-Ampere erfreulich. Ungewöhnlich war jedoch der Wert bei 100.000 aktiven Tokens: Der Decode sank lediglich von 105,8 auf 97,2 Token pro Sekunde, also um rund acht Prozent.

Zum Vergleich: HY3 fiel in unserem früheren Lauf von ungefähr 45 auf etwa 12 Token pro Sekunde. MiniMax geriet bei ähnlicher Last in lange Schleifen. Laguna blieb schnell, weil nur zwölf Layer die gesamte Historie per Full Attention lesen. Die übrigen 36 Layer arbeiten mit einem Sliding Window von 512 Tokens.

FP8-KV überholte BF16-KV erst bei langem Kontext

Bei kurzem Kontext war BF16-KV mit 109,1 gegenüber 105,8 Token pro Sekunde etwas schneller. Bei 100.000 aktiven Tokens drehte sich das Verhältnis um: FP8-KV erreichte 97,2, BF16-KV nur 85,6 Token pro Sekunde. BF16 muss doppelt so viele KV-Daten lesen. Solange der Cache klein ist, fällt das kaum auf; bei langem Kontext wird die Speicherbandbreite zum Engpass.

FP8-KV war in diesem Messpunkt ungefähr 13,5 Prozent schneller und ließ zugleich mehr VRAM-Reserve übrig. BF16-KV konnte den vollständigen 262k-Kontext nur mit --gpu-memory-utilization 0.96 bereitstellen. Danach blieben etwa 0,85 GiB Reserve je GPU. In diesem Bereich genügt ein ungünstiger Moment während des CUDA-Graph-Captures, um den Server mit einem OOM zu beenden.

Für unseren getesteten Stand entschieden wir uns daher für TP4 mit FP8-KV und 262k Kontext. Diese Konfiguration lieferte den besten 100k-Wert, ließ mehr Reserve übrig und entsprach der damaligen Qualitätskonfiguration von Poolside.

Wie weit der Kontext tatsächlich reichte

Zum Testzeitpunkt bezeichnete Poolside die Gewichte als „1M Checkpoints“, lieferte sie standardmäßig aber für 262.144 Tokens konfiguriert aus. Die damalige Modellkarte empfahl diese Einstellung ausdrücklich für die beste Ausgabequalität und warnte vor möglicher Qualitätsverschlechterung bei 1M. Angesichts einer Warnung des Herstellers zu seinem eigenen Maximalwert behandelten wir 1M nicht als bedenkenlosen Betriebsmodus.

Auf TP4 passten physisch mehr als 262k

Die konfigurierte Kontextgrenze und der physisch verfügbare KV-Speicher waren zwei verschiedene Größen. Der Server meldete auf vier GPUs eine KV-Kapazität von 377.571 Tokens mit FP8 beziehungsweise 394.028 Tokens mit BF16. Wer mehr als 262k benötigte, konnte mit dem getesteten Checkpoint praktisch ungefähr 370.000 bis 390.000 Tokens auf TP4 unterbringen.

Für 1M brauchten wir TP8 und einen YaRN-Override

Für den 1M-Versuch veränderten wir die lokale config.json nicht. Stattdessen überschrieben wir die Werte beim Serverstart. --max-model-len 1048576 allein hätte nicht genügt: YaRN-Faktor und Attention-Faktor mussten zur 1M-Konfiguration passen, andernfalls wären die Positionsinformationen falsch skaliert worden.

{
  "max_position_embeddings": 1048576,
  "rope_parameters": {
    "full_attention": {
      "rope_type": "yarn",
      "factor": 128.0,
      "original_max_position_embeddings": 8192,
      "attention_factor": 1.4852030263919618,
      "partial_rotary_factor": 0.5
    }
  }
}

Mit TP8 und FP8-KV meldete der Server anschließend eine KV-Kapazität von 3.604.506 Tokens, entsprechend 3,44 parallelen 1M-Kontexten. Unser Langkontext-Sweep ergab:

Stufe	TG bei kurzem Kontext	TG bei gefülltem Kontext
524k	ungefähr 108	62,1
786k	ungefähr 104	42,9
1,048 Mio.	ungefähr 112	34,6

Der kurze Decode blieb mit ungefähr 104 bis 112 Token pro Sekunde stabil, unabhängig davon, ob der Server für 262k oder 1M konfiguriert war. Die bloße Reservierung des größeren Fensters verlangsamte ihn also nicht. Zusätzliche Arbeit entstand erst durch den tatsächlich gefüllten KV-Cache: Jedes neue Token musste in den Full-Attention-Layern die gewachsene Historie lesen.

Alle drei 1M-Ausgaben blieben strukturell kohärent. Wir sahen weder einen Zusammenbruch der Positionsverarbeitung noch Attention-Ausfälle oder CUDA-/OOM-Fehler. Bei 1.048.006 Prompt-Tokens erkannte Laguna sogar, dass wir denselben deutschen Testsatz sehr häufig wiederholt hatten, und verstand die abschließende Anweisung.

Für eine Empfehlung reichte das trotzdem nicht. Eine kohärente Ausgabe beweist noch kein verlässliches Verständnis.

1M lief, war aber inhaltlich nicht validiert

Unser langer Prompt war bewusst synthetisch und bestand im Wesentlichen aus der Wiederholung eines Satzes. Damit prüften wir Speicher, Positionsverarbeitung und eine sehr einfache inhaltliche Reaktion. Schwieriges Retrieval, mehrstufige Logik oder Arbeit an einem Repository über 1M Tokens hinweg waren damit nicht belegt.

Der Begriff „1M-Kontext“ musste für den getesteten Stand deshalb genauer aufgeschlüsselt werden:

1M allokierbar und bootfähig:                         nachgewiesen
1M-Prompt verarbeitbar, kohärente Ausgabe möglich:   lokal nachgewiesen
1M einfaches wörtliches Retrieval:                   öffentlich nicht sauber dokumentiert
1M für Multi-Hop-Logik und Repo-Coding zuverlässig:  unbekannt
1M mit derselben Qualität wie 262k:                  nicht dokumentiert; Hersteller warnte davor

Am 26. Juli 2026 gab es keinen öffentlich reproduzierbaren Laguna-Lauf mit RULER bei 500k oder 1M, keinen Multi-Needle-Test und keine reale Repository-Evaluation über 1M Tokens hinweg. Die damals veröffentlichte Langkontexttabelle von Poolside bezog sich auf das nicht nachtrainierte Basismodell und endete bei 128k. Bereits dort sank RULER schrittweise von 81,6 Prozent bei 32k auf 72,8 Prozent bei 128k.

Für diesen Checkpoint blieb 262k daher die Betriebsgrenze, die wir sachlich vertreten konnten. Zwischen 500k und 1M war der Betrieb technisch real, die semantische Verlässlichkeit jedoch nicht nachgewiesen. Bei wirklich großen Datenmengen boten RAG, gezielte Dateiauswahl und Kontextkomprimierung die bessere Evidenzbasis.

Der inzwischen veröffentlichte August-Checkpoint ist nativ für 1M konfiguriert und laut aktueller Modellkarte auch mit dieser Konfiguration kalibriert. Die Karte weist weiterhin auf mögliche Qualitätsverluste bei langem Kontext hin. Unsere alten 1M-Tests ersetzen deshalb keine neue inhaltliche Evaluation des aktuellen Gewichtsstands.

Der PP3-Fehler, der uns eine Stunde kostete

Für eine Variante mit sechs GPUs testeten wir TP2 plus PP3, also Pipeline Parallelism über drei Stufen. Mit FP8-KV startete der Server ohne erkennbare Probleme, meldete 1.885.184 KV-Tokens, bestand den Healthcheck und produzierte beim ersten echten Prompt unbrauchbare Ausgabe.

Die Ursache lag tief genug, um zunächst wie ein Modellfehler auszusehen. In den Pipeline-Layern wurden k_scale und v_scale wegen eines doppelten attn-Präfixes im Tensornamen nicht geladen. vLLM 0.25.1 fiel für die fehlenden Skalen still auf 1.0 zurück. Damit war der FP8-KV-Cache mathematisch falsch skaliert.

Auch der naheliegende Schalter --calculate-kv-scales half nicht. Er war in vLLM 0.25.1 als veraltet markiert und in diesem Fall wirkungslos.

TP2+PP3, FP8-KV, 88 Tokens:      87.27 TG  -> ungültig, Garbling
TP2+PP3, FP8-KV, 100k Tokens:    78.22 TG  -> ungültig, Garbling

Die Zahlen sehen auf dem Papier brauchbar aus und sind trotzdem wertlos. Für PP3 war nur BF16-KV valide:

--tensor-parallel-size 2 --pipeline-parallel-size 3 \
--max-model-len 262144 --kv-cache-dtype bfloat16

Selbst damit blieb PP3 für einen einzelnen Agentenstream die schlechtere Wahl. TP4-BF16 war bei kurzem Kontext ungefähr 22 Prozent und bei 100k ungefähr 27 Prozent schneller als PP3-BF16, obwohl TP4 zwei GPUs weniger verwendete. PP3 gewann KV-Reserve, bezahlte sie aber mit Pipeline-Latenz.

Dieser Fehler bestätigte eine Regel, an die uns unser Rig regelmäßig erinnert: Ein gestarteter Server ist noch kein funktionierender Server. Healthcheck und TG-Wert genügen nicht; zu jedem Start gehört ein Kontrollprompt, dessen kohärente Antwort wir prüfen können. TP8 funktionierte in diesem Versuch unauffällig. Der Skalenfehler betraf speziell den Pipeline-Pfad.

Unser Start für den täglichen Einsatz

Die folgende Konfiguration ist der tatsächlich verwendete TP4-/FP8-KV-/262k-Start des getesteten Checkpoints. Sie belegt die GPUs mit den Gerätenummern 3, 4, 6 und 7; die übrigen vier Karten bleiben für ein zweites Modell frei.

docker rm -f laguna_s21_int4 2>/dev/null || true
docker run -d --name laguna_s21_int4 --entrypoint vllm \
  --gpus '"device=3,4,6,7"' --ipc host --shm-size 64g \
  -e NVIDIA_DISABLE_REQUIRE=1 -e CUDA_DEVICE_ORDER=PCI_BUS_ID \
  -e NCCL_P2P_DISABLE=1 -e NCCL_IB_DISABLE=1 -e NCCL_CUMEM_ENABLE=0 \
  -e VLLM_ALLREDUCE_USE_SYMM_MEM=0 -e VLLM_WORKER_MULTIPROC_METHOD=spawn \
  -e VLLM_ENABLE_CUDA_COMPATIBILITY=0 \
  -v /bigData/hf-cache/Laguna-S-2.1-INT4:/models/Laguna-S-2.1-INT4 \
  -v /bigData/vllm/data/torch-extensions-v024:/root/.cache/torch_extensions \
  -v /bigData/vllm/data/triton-v024:/root/.triton \
  -v /bigData/vllm/data/cuda-cache-v024:/root/.cache/cuda \
  -v /bigData/vllm/data/vllm-cache-v024:/root/.cache/vllm \
  -p 8005:8000 \
  vllm/vllm-openai:v0.25.1 \
  serve /models/Laguna-S-2.1-INT4 --served-model-name laguna-s-2.1-int4 \
  --tensor-parallel-size 4 --max-model-len 262144 \
  --kv-cache-dtype fp8 --gpu-memory-utilization 0.92 \
  --disable-custom-all-reduce --enable-prefix-caching --generation-config auto \
  --reasoning-parser poolside_v1 --enable-auto-tool-choice --tool-call-parser poolside_v1 \
  --default-chat-template-kwargs '{"enable_thinking":true}' --trust-remote-code \
  --max-num-seqs 1 --max-num-batched-tokens 4096 \
  --host 0.0.0.0 --port 8000
until curl -fsS http://127.0.0.1:8005/health; do sleep 3; done

Einige Flags sind für diesen Aufbau unverzichtbar:

• --reasoning-parser poolside_v1 und --tool-call-parser poolside_v1: Laguna besitzt ein eigenes Format für Reasoning und Tool-Calls. Ein generischer Parser bewertet das Modell auf einer falschen Grundlage. Native Tool-Calls gehören zu seinen Stärken, sofern der richtige Parser verwendet wird.
• --default-chat-template-kwargs '{"enable_thinking":true}': Thinking verbessert laut Poolside die Leistung deutlich, verbraucht aber sehr viele Tokens. Im Release-Artikel liegen die mittleren Completion-Längen der gezeigten Benchmarks bei ungefähr 129.000 bis 249.000 Tokens. Reasoning-Budgets und finish_reason müssen deshalb überwacht werden.
• --enable-prefix-caching: Agenten- und Tool-Schleifen erweitern den bisherigen Kontext überwiegend am Ende. Prefix Caching vermeidet dabei wiederholte Arbeit.

Der Kaltstart dauerte wegen des JIT von Triton und torch.compile mehrere Minuten. Deshalb wartet der Befehl auf einen erfolgreichen Healthcheck, statt eine feste Wartezeit zu raten.

Für unseren damaligen 1M-Start kamen --gpus all, --tensor-parallel-size 8 und der oben dokumentierte YaRN-Block per --hf-overrides hinzu. Alle übrigen Werte blieben gleich. Für den aktuellen August-Checkpoint muss das Rezept anhand der aktuellen Modellkarte neu geprüft werden.

Fachlich stark, operativ sprunghaft

Die Inferenz war bei Laguna der einfache Teil. Das Modell war schnell und technisch beeindruckend. In öffentlichen Tests zeigte sich allerdings ein sehr ungleichmäßiges Coding-Profil: Seine Stärken konzentrierten sich auf bestimmte Aufgabenarten, und die Ergebnisse hingen stark von der Konfiguration ab.

Ein öffentlicher SparkRun auf vergleichbarer Hardware zeigte diese Ungleichmäßigkeit besonders deutlich:

Test	Laguna NVFP4	Qwen 3.6 27B FP8	Qwen 3.6 35B-A3B FP8
HumanEval pass@1	36,6 %	70,7 %	50,6 %
MBPP pass@1	76,4 %	40,2 %	49,8 %
BFCL-v4 Overall	21 %	28 %	27 %
BFCL, parallele Calls	4 bis 8 %	92 bis 96 %	88 bis 96 %

Bei HumanEval lag Laguna in diesem Lauf hinten, bei MBPP deutlich vorn. Zwei auf den ersten Blick ähnliche Coding-Benchmarks ergaben damit beinahe gegensätzliche Rangfolgen. Das war kein Beleg für allgemeine Überlegenheit oder allgemeine Schwäche, sondern für eine stark gezackte Fähigkeitskurve.

In den belastbareren Erfahrungsberichten wiederholten sich einige Stärken:

• Schwierige Algorithmen und Debugging: In einem Community-Test löste Laguna eine In-place-Transformation in Julia, an der Qwen 122B und 27B zuvor gescheitert waren. Dafür benötigte es mehr als 60.000 Thinking-Tokens; anschließend liefen die Tests durch.
• Native Tool-Calls: Ein Nutzer dokumentierte 209 bis 270 saubere Tool-Calls gegen reale Geschäftsobjekte. Seine erste euphorische Bewertung korrigierte er später auf „ordentlich“, was gut zum schwankenden Gesamtbild passt.
• Lange Repository-Analysen und Reviews: Diese Aufgaben wurden in mehreren Berichten als Stärke genannt.

Ebenso klar waren die wiederkehrenden Schwächen:

• Frontend, UI und gewöhnliches Python: In einem Blindvergleich lag Laguna deutlich hinter Qwen und Gemma.
• Zerdenken und fehlender Abschluss: Die NVFP4-Variante beendete in einem Test zwölf von zwölf Läufen ohne finale Antwort und verbrauchte ihr Budget vollständig im Reasoning. Beim INT4-Quant trat nach ungefähr 20.000 Tokens eine Schleife auf, in der das Modell immer wieder dieselben Ordner durchging.
• Planung und rechtzeitiger Abschluss: In einem OpenCode-Coding-Test hielt der Agent mehrfach an und musste zum Weitermachen aufgefordert werden.

Aus diesen Berichten entstand ein konsistentes Betriebsbild. Laguna kann bei schwierigen, durch Tests überprüfbaren Coding-Aufgaben außergewöhnlich gut sein. Qwen verhält sich als Alltagsmodell planbarer, arbeitet bei Frontend-Aufgaben effizienter und kommt mit generischen Tool-Harnesses besser zurecht. Bei Laguna gehören externe Tests und harte Abbruchkriterien von Anfang an zur Konfiguration.

Zwei Befunde aus unserem DOCX-Stresstest

Unser Ausschreibungsbenchmark lässt ein Modell elf Fullstack-Profile anhand von 180 Kriterien bewerten und anschließend über Word-MCP formularartige Dokumente erzeugen. Die Aufgabe ist lang, mehrstufig und voller Tool-Aufrufe. Genau dieses Muster hatte MiniMax zuvor zuverlässig in ausufernde Reasoning-Schleifen geführt.

Laguna absolvierte den DOCX-Benchmark in der TP4-/FP8-KV-Konfiguration dreimal in drei Läufen vollständig. Es gab keine Schleife, kein Garbling und keinen vorzeitigen Abbruch. Für ein wenige Tage altes Modell auf Consumer-Ampere war das die angenehmste Überraschung unserer Testreihe, besonders gegenüber den null von drei beziehungsweise zwei von drei erfolgreichen Läufen anderer lokaler Modelle mit derselben Aufgabe.

Zugleich dachte Laguna lange, bevor es lieferte. Die Reasoning-Phasen verbrauchten erhebliche Tokenmengen. Im sauberen 262k-Aufbau blieb das beherrschbar, bestätigte aber die extern beobachtete Neigung zum Zerdenken. Ohne begrenztes Reasoning-Budget und Kontrolle von finish_reason kann dieselbe Beharrlichkeit, die einen schwierigen Fehler löst, bei einer einfachen Aufgabe in Selbstgespräche kippen.

Weshalb frühe Berichte einander widersprachen

Zwischen dem 21. und 24. Juli änderten sich Modell und Laufzeitumgebung fortlaufend:

• FP8 erhielt einen spinquantless-Checkpoint mit dem Commit-Hinweis „fixes agentic looping“.
• INT4 und NVFP4 wurden auf neue 256k-Konfigurationen aktualisiert.
• Für GGUF wurden der YaRN-Attention-Faktor und das Chat-Template korrigiert.
• Der DFlash-Drafter war zeitweise nicht zur Version des Zielmodells kompatibel.
• In vLLM verhielten sich implizites und explizites Thinking über mehrere Turns hinweg unterschiedlich.

Ein Erfahrungsbericht ohne exakten Checkpoint-Commit, Quant, Runtime, Chat-Template, Parser, Sampling und KV-Dtype war in dieser Phase kaum mit einem anderen Lauf vergleichbar. Unser PP3-FP8-Fehler zeigt das Problem in Reinform: Der Server startete und lieferte plausible Leistungswerte, war inhaltlich aber unbrauchbar. Falsche YaRN-Metadaten, defekte Templates oder fehlende KV-Skalen konnten bei Laguna leicht wie ein Fehler des Modells selbst aussehen.

Die spätere Ersetzung des INT4-Checkpoints im August verschärft diese Anforderung an alte Berichte. Ein Ergebnis vom Juli bleibt nützlich, sofern der getestete Stand sichtbar bleibt. Ohne diese Zuordnung vergleicht man möglicherweise verschiedene Gewichte unter demselben Modellnamen.

Fazit: Laguna ist unser Skalpell, nicht unser Schweizer Taschenmesser

Laguna S 2.1 INT4 erreichte auf vier GPUs ungefähr 106 Token pro Sekunde bei kurzem und noch 97 Token pro Sekunde bei 100.000 Tokens aktivem Kontext. Mit dem getesteten Juli-Checkpoint lag der vernünftige Betriebswert bei 262k, ungefähr 390k passten physisch auf TP4 und selbst 1M lief auf TP8 strukturell kohärent. Für die inhaltliche Verlässlichkeit bei 1M fehlten jedoch belastbare Tests.

Bei anspruchsvollem Debugging, Reviews und Algorithmen konnte Laguna brillante Ergebnisse liefern. Bei Routineaufgaben, Frontend-Arbeit und dem rechtzeitigen Abschluss war es deutlich weniger verlässlich. Sein Reasoning war Stärke und Betriebsrisiko in einem.

Für unsere Arbeit ergab sich daraus eine klare Aufteilung:

Qwen bleibt das Alltagsmodell. Laguna ist das Skalpell für den schwierigen Fehler: TP4, 262k, FP8-KV und jedes Ergebnis durch Tests oder einen zweiten Prüfer abgesichert.

Wo Tests die Wahrheit sagen und ein hartes Tokenbudget das Ende markiert, ist Laguna ein ungewöhnlich starker lokaler Spezialist. Als beliebig einsetzbarer Frontend-Agent wäre dasselbe Modell vor allem ein zuverlässiger Weg, sich über die Begeisterung anderer Leute zu wundern.