senn-techZwei Modellwechsel auf einer RTX 5090 — und warum nur einer stattfand
Innerhalb von fünf Tagen erschienen zwei Modelle, die beide auf dieselbe Hardwareklasse zielen: Metas Muse Glimmer 30B am 10. August 2026 und Alibabas Qwen3.8-27B am 14. August — beide unter Apache 2.0, beide für 24- bis 32-GB-Karten gebaut.
Wir haben beide gegen dieselbe Frage geprüft: Ersetzt du das Modell, das bei uns Dokumente liest? Die Antwort war zweimal unterschiedlich — und der interessante Teil ist, warum.
Der Kandidat, der nicht kam
Muse Glimmer ist ein starkes Modell. Der Hersteller bewirbt es als agentisches Modell für Dauerbetrieb auf lokaler Hardware, und die veröffentlichten Bewertungen stützen das: Bei Werkzeugnutzung und mehrstufigen Abläufen liegt es deutlich vorn.
Nur ist das nicht unsere Aufgabe. Unsere Lane liest Belege — Lieferscheine, Rechnungen, Bestellungen. Auf den Bewertungen, die Dokumentenverständnis messen, liegt Muse Glimmer gleichauf oder knapp dahinter. Die klaren Siege liegen im agentischen Bereich, und agentische Arbeit läuft bei uns auf einer anderen, deutlich grösseren Maschine.
Dazu kam ein Architekturargument: Muse Glimmer ist dicht gerechnet, mit knapp 30 Milliarden aktiven Parametern plus Bildencoder. Unser damaliges Modell war ein Mixture-of-Experts mit rund drei Milliarden aktiven Parametern pro Token. Bei parallelen Anfragen auf einer Karte ist das der Unterschied zwischen „läuft" und „steht an".
Ergebnis: kein Wechsel. Nicht weil das Modell schlecht ist, sondern weil es für eine andere Aufgabe gebaut wurde.
Die Regel, die falsch war
Vier Tage später kam Qwen3.8-27B — und damit ein Problem: auch dieses Modell ist dicht gerechnet. Nach der Logik von oben hätte es also ausscheiden müssen. Wir hatten sogar eine feste Regel im eigenen Runbook stehen: „Ein dichtes 27B geht auf dieser Karte nicht."
Diese Regel war falsch. Sie stammte aus einem einzigen Fehlstart einige Tage zuvor, dessen Protokolle niemand aufgehoben hatte. Der darin behauptete Spitzenverbrauch des Bildencoders von rund 10,9 GiB existiert nicht — gemessen sind 3,0 GiB.
Tatsächlich passt das dichte Modell besser als sein MoE-Vorgänger:
| dicht (neu) | MoE (alt) | |
|---|---|---|
| Gewichte | 19,41 GiB | 22,74 GiB |
| KV-Cache | 6,47 GiB | 3,41 GiB |
| KV-Tokens | 184.320 | 158.222 |
Die Lehre daraus ist unbequem und allgemeingültig: Aus einem einzelnen Fehlschlag keine Architekturregel machen — und die Protokolle aufheben. Wir hätten das neue Modell um ein Haar ungeprüft verworfen, gestützt auf eine Messung, die es nie gegeben hat.
Der Hebel, den niemand gezogen hatte
Möglich macht das ein einziger Schalter: --kv-cache-dtype fp8_e4m3.
Der KV-Cache hält den bisherigen Kontext während der Generierung. Wird er in 8 statt 16 Bit abgelegt, passt bei gleichem Speicher etwa doppelt so viel hinein. Dieser Schalter war nie ausprobiert worden — und er ist der Grund, warum die Rechnung überhaupt aufgeht.
Was dabei ebenfalls klar wurde: Das Absenken von Kontextlänge oder Speicherauslastung, der übliche erste Reflex, hilft hier nicht. Beides war zuvor erfolglos getestet worden.
Drei Flags gegen drei stille Fehler
Der eigentliche Praxiswert dieses Wechsels steckt in drei Startparametern. Jeder verhindert einen Fehler, der nicht als Fehler auffällt — und genau das macht sie teuer:
--max-num-seqs 64— die Architektur belegt pro paralleler Sequenz einen internen Block. Zu hoch gesetzt bricht der Start ab, nachdem der Speicher bereits reserviert wurde. Das sieht aus wie ein Speicherproblem und ist keines.--tool-call-parser qwen3_xmlstatt des naheliegenden Standards — das Modell gibt Werkzeugaufrufe als XML aus. Mit dem falschen Parser kommen die Aufrufe leer zurück. Keine Fehlermeldung, kein Hinweis im Protokoll, nur ein Ergebnis ohne Inhalt.--default-chat-template-kwargs '{"enable_thinking": false}'— die Vorlage öffnet von sich aus einen Denkabschnitt. Ohne diesen Schalter landet der Denktext in der Antwort statt im dafür vorgesehenen Feld, und jede nachgelagerte JSON-Auswertung zerbricht daran.
Alle drei haben eines gemeinsam: Das System meldet Erfolg und liefert Unbrauchbares. Wer nur auf Startmeldungen und Statuscodes schaut, merkt es nicht.
Der Preis: langsamer einzeln, stark unter Last
Ehrlichkeit gehört dazu: Das dichte Modell ist bei einzelnen Anfragen deutlich langsamer — 27 Milliarden aktive Parameter gegen rund drei. Interessant wird es unter Parallellast:
Für eine Lane, die Belege stapelweise verarbeitet, ist die rechte Seite dieser Grafik die relevante. Für einen interaktiven Chat wäre es die linke — dieselbe Hardware, dieselben Modelle, entgegengesetzte Empfehlung.
Was das im Eigenbetrieb bedeutet
Der Wechsel lief am 15. August, einen Tag nach Veröffentlichung des Modells. Was dabei half, war nicht Mut, sondern Vorbereitung: ein Rückweg, der in einer Minute greift, weil die alten Gewichte im Cache liegen, und ein Prüfskript, das nach dem Tausch jeden abhängigen Dienst durchtestet.
Letzteres war nötiger als gedacht. Bei dieser Gelegenheit stellte sich heraus, dass eines unserer Testskripte seit dem ersten Tag kaputt war: Durch einen Fehler in der Skriptstruktur schickte es bei jedem Lauf ein leeres Dokument an die Schnittstelle — und bekam brav eine leere Antwort zurück, in Sekundenbruchteilen. Grün, schnell, wertlos. Der Produktivpfad war nie betroffen, aber der Test hatte monatelang nichts geprüft.
Das ist die eigentliche Geschichte dieses Wechsels: Nicht das Modell war das Risiko, sondern die Annahmen drumherum. Eine erfundene Speichermessung, ein Test, der nichts testete, und drei Schalter, deren Fehlen sich als Erfolg tarnt.
Offen, und das sagen wir auch
Der Qualitätsvergleich zwischen beiden Modellen steht noch aus. Gemessen sind Passen und Tempo, nicht die Güte der Auslesung auf echten Belegen. Bis dieser Vergleich vorliegt, ist der Wechsel technisch vollzogen, aber fachlich nicht abschliessend entschieden.
Wir schreiben das hin, weil das Gegenteil in Fachbeiträgen üblich ist: Tempo messen, Qualität behaupten. Ein Durchsatzwert sagt nichts darüber, ob die Rechnungsnummer richtig erkannt wurde.
Fazit
Zwei Modelle in einer Woche, ein Wechsel. Muse Glimmer ist stark — für agentische Arbeit, nicht für unsere Dokumente. Qwen3.8 passt, entgegen einer eigenen Regel, die sich als Erfindung entpuppte.
Der übertragbare Teil hat mit keinem der beiden Modelle zu tun: Prüfen Sie die Regeln, die Sie über Ihre eigene Infrastruktur mit sich herumtragen. Manche davon stammen aus einem einzigen schlechten Tag, an dem niemand die Protokolle aufgehoben hat.
Weiterführende Quellen
Warum wurde Muse Glimmer trotz guter Bewertungen nicht eingesetzt?+
Weil seine Stärken nicht zu unserer Aufgabe passen. Muse Glimmer ist auf agentische Abläufe ausgelegt und dort deutlich stark. Unsere Lane macht etwas anderes: Sie liest Dokumente. Auf den Bewertungen, die genau das messen, liegt es gleichauf oder knapp dahinter. Dazu kommt die Architektur: Ein dichtes Modell dieser Grösse hätte den Durchsatz bei parallelen Anfragen auf derselben Karte deutlich gedrückt.
Was bedeutet fp8 beim KV-Cache konkret?+
Der KV-Cache speichert den bisherigen Kontext während der Generierung und belegt einen erheblichen Teil des Grafikspeichers. Wird er statt in 16 Bit in 8 Bit abgelegt, passt bei gleichem Speicher etwa doppelt so viel Kontext hinein. In unserem Fall war das der entscheidende Hebel: Erst dadurch passte das dichte Modell überhaupt sinnvoll auf die Karte — und zwar besser als sein Vorgänger.
Ist das neue Modell nun besser als das alte?+
Das ist offen, und wir sagen das bewusst so. Gemessen haben wir bisher, dass es auf die Karte passt und wie schnell es unter Last ist. Ein sauberer Qualitätsvergleich zwischen beiden Modellen auf echten Belegen steht noch aus. Fachlich ist der Wechsel deshalb erst dann entschieden, wenn dieser Vergleich vorliegt — Tempo und Speicherbedarf allein sind kein Qualitätsnachweis.