Lokale KI-Modelle: Lizenz und Leistung im Test

"Läuft auf einer einzelnen Consumer-GPU." Diesen Satz haben in den letzten zwei Wochen vier Hersteller geschrieben, und er stimmt jedes Mal ein bisschen anders. Meta hat am 10. August Muse Glimmer veröffentlicht, ein Modell mit angeblich 30 Milliarden Parametern unter Apache 2.0, einen Tag später zog NVIDIA mit Nemotron 3.5 Lightning nach, ebenfalls angeblich 30 Milliarden. Davor kamen Mistrals Shieldstral und Liquid AIs LFM2.5. Alle vier zielen auf dieselbe Frage, die in DACH-Teams gerade oft gestellt wird: Was können wir eigentlich selbst betreiben, ohne dass Daten das Haus verlassen?

Die ehrliche Antwort hängt an zwei Dingen, über die Pressemitteilungen ungern sprechen. Erstens: Was heißt "läuft" auf der Hardware, die tatsächlich unter dem Schreibtisch steht? Zweitens: Was steht in der Lizenz, und zwar in der Datei, nicht im Blogpost?

Wir haben Glimmer und Nemotron deshalb heruntergeladen, beide auf demselben gewöhnlichen Arbeitsgerät gemessen und die Lizenztexte aller vier Modelle gelesen. Das Ergebnis vorweg: Zwei Modelle derselben Größenklasse liegen bei der Geschwindigkeit um den Faktor fünf auseinander, und bei einem der beiden bekommt man je nach Bezugsweg zwei verschiedene Lizenzen.

Wenn ihr noch gar nichts lokal betreibt, fangt ihr besser bei Ollama an, dort steht das Setup. Hier geht es um die Modelle, die seit Anfang August dazugekommen sind.

Die vier Kandidaten im Überblick

Beim Speicher lohnt der Blick auf die Klammern: Nur die Werte für Glimmer und Nemotron stammen aus unseren eigenen Läufen. Der Wert für Shieldstral ist aus der Parameterzahl gerechnet und von uns nicht nachgemessen. Die 2,5 GB für LFM2.5 nennt Liquid AI selbst, allerdings ohne eine Quantisierungsstufe dazuzusagen, gemessen bei CPU-Inferenz auf einem M5 Max und einem Ryzen AI Max+ 395. Direkt vergleichbar sind die vier Zahlen also nicht.

Ein Detail zur Größenangabe, das beim Vergleichen hilft. Metas Blogpost spricht durchgehend vom 30-Milliarden-Modell. Die Modellkarte auf Hugging Face nennt dann schon 29,6 Milliarden, und die tatsächlich ausgelieferten Gewichte melden 27,9 Milliarden Parameter für das Sprachmodell plus 1,9 Milliarden für den CLIP-Encoder, der die Bilder verarbeitet.

Bei Nemotron ist es dasselbe Spiel mit anderem Vorzeichen. NVIDIA bewirbt 30 Milliarden, die Gewichtsdateien auf Hugging Face summieren sich auf 31,6 Milliarden, und ollama show meldet 32,9 Milliarden. Diesmal ist das Modell also größer als der Name verspricht, nicht kleiner. Keine dieser Zahlen ist falsch, sie zählen nur Verschiedenes. Für die Praxis heißt das: Die Parameterzahl im Produktnamen ist eine Marketingangabe, kein Messwert.

Die für Nemotron wichtigere Zahl steht ohnehin daneben. Es ist ein Mixture-of-Experts-Modell, bei dem pro Token nur rund 3 Milliarden Parameter aktiv sind, sechs Experten von vielen. Dazu kommt eine Architektur, die NVIDIA nemotron_h_moe nennt: eine Mischung aus Mamba- und Transformer-Schichten, bei der die Mamba-Anteile konstanten Speicher pro erzeugtem Token brauchen statt eines mitwachsenden Caches. Genau daher kommt das Kontextfenster von einer Million Token, und wie sich zeigen wird, auch der Geschwindigkeitsunterschied.

Der Lizenzcheck, und warum er zuerst kommt

Ein Modell, das ihr nicht einsetzen dürft, braucht ihr auch nicht zu benchmarken. Deshalb steht die Lizenz hier vor der Technik, und deshalb reicht die Modellkarte dafür nicht. Warum "offen" bei Modellen so unterschiedlich viel bedeuten kann, haben wir in Offene Gewichte: Souveränität auf dem Papier auf der politischen Ebene beschrieben. Hier folgt die Version zum Nachmachen, mit drei konkreten Lizenzdateien.

Bei Shieldstral ist die Sache in einer Minute erledigt: Apache 2.0, die Lizenzdatei enthält den unveränderten Text, fertig. Deutsch ist unter den zwölf Sprachen. Wer eine Ein- und Ausgabeprüfung für ein eigenes KI-Feature braucht, bekommt hier eine, die die Daten nicht an einen US-Dienst schickt und selbst in voller Genauigkeit auf eine 16-GB-GPU passt, quantisiert auf 4 Bit sogar auf deutlich weniger.

Bei LFM2.5 muss man dagegen den Volltext öffnen. Die Modellkarte sagt nur license: other mit dem Namen lfm1.0. In Abschnitt 5 der LFM Open License steht dann die Klausel, die für den DACH-Mittelstand entscheidet:

Any Commercial Use of the Work or a Derivative Work by a Legal Entity that exceeds the Threshold is not licensed under this Agreement.

Die Schwelle definiert die Lizenz an anderer Stelle als 10 Millionen US-Dollar Jahresumsatz. Bemerkenswert ist die Formulierung: Oberhalb der Schwelle ist die kommerzielle Nutzung schlicht nicht lizenziert. Es gibt keinen automatischen Anschlusstarif, den man bucht. Wer darüber liegt, muss mit Liquid AI verhandeln, bevor irgendetwas produktiv geht. Viele Mittelständler in Deutschland liegen über dieser Schwelle, ohne sich groß zu fühlen.

Der Ankündigungstext desselben Unternehmens bewirbt die Modelle übrigens wörtlich als "Open-weight, Download, fine-tune, and deploy without restrictions". Wer nur den Blogpost liest, bekommt also exakt das Gegenteil dessen erzählt, was zwei Klicks weiter in der Lizenzdatei steht. Besser lässt sich nicht zeigen, warum die Datei zählt und nicht die Überschrift.

Glimmer haben wir am gründlichsten geprüft, weil Metas Lizenzgeschichte bei Llama keine gute war. Diesmal stimmt es: Die Lizenzdatei im Repository ist unveränderter Apache-2.0-Text, keine Community-Lizenz mit Nutzerzahl-Klausel. Das ist ein echter Schritt. Daneben liegt allerdings eine USAGE_POLICY.md mit einer langen Liste verbotener Verwendungen: Militär und ITAR, Betrieb kritischer Infrastruktur, das Verarbeiten sensibler personenbezogener Daten ohne Rechtsgrundlage und die Klausel, dass man nicht behaupten darf, Ausgaben seien von Menschen erstellt.

Wie sich eine solche Policy zu einer Apache-2.0-Lizenz verhält, die selbst keinerlei Nutzungsbeschränkungen kennt, ist juristisch nicht geklärt.

Praktisch heißt das für Teams: Für normale Produktentwicklung ist Glimmer deutlich freier als alles, was Meta bisher unter dem Llama-Namen herausgegeben hat. Wer aber in einer der genannten Branchen arbeitet, sollte die Policy der Rechtsabteilung zeigen, bevor das Modell in ein Produkt wandert.

Nemotron: dasselbe Modell, zwei verschiedene Lizenzen

Bei Nemotron haben wir den unangenehmsten Fund dieses Tests gemacht, und er betrifft nicht die Lizenz selbst, sondern den Bezugsweg.

In NVIDIAs eigenem Repository auf Hugging Face liegt eine LICENSE-Datei mit dem OpenMDW License Agreement 1.1. Der Text ist kurz, 2.693 Zeichen, und er ist ehrlich freizügig:

permission is hereby granted, free of charge, to deal in the Model Materials without restriction

Kommerzielle Nutzung ist erlaubt, die einzige Auflage ist das Mitliefern von Lizenz und Herkunftsvermerken bei Weitergabe, und die Lizenz stellt ausdrücklich klar, dass sie keinerlei Einschränkungen für die erzeugten Ausgaben macht. Dazu die übliche Patentklausel. Für ein Modell aus einem US-Konzern ist das bemerkenswert sauber.

Wer dasselbe Modell aber über Ollama zieht, weil das der bequeme Weg ist, und dann ollama show --license aufruft, bekommt etwas anderes zu sehen: die NVIDIA Open Model License Agreement vom 24. Oktober 2025, 10.128 Zeichen. Und die ist an drei Stellen deutlich enger:

• Die Rechteeinräumung ist ausdrücklich widerruflich ("revocable"), nicht dauerhaft.
• Wer eine technische Schutzvorrichtung im Modell umgeht, abschaltet oder in ihrer Wirkung reduziert, verliert die Rechte automatisch. Das ist eine Nutzungsbeschränkung, die OpenMDW gar nicht kennt.
• NVIDIA darf das Abkommen jederzeit ändern, und man muss dann entweder die neue Fassung akzeptieren oder die Nutzung einstellen. Zusätzlich hängt die Nutzung an einer externen "Trustworthy AI"-Seite, die sich ebenfalls ändern kann.

Welche gilt? Maßgeblich ist die Datei, die der Rechteinhaber selbst ausliefert, und das ist die OpenMDW-Fassung in NVIDIAs Repository. Die Ollama-Kopie ist eine Weitergabe durch Dritte, und sie trägt offenbar noch NVIDIAs alten Standardtext. Wir haben beide Texte im Volltext verglichen, das Wort "OpenMDW" kommt in der Ollama-Fassung kein einziges Mal vor.

Für die Praxis ist die Lehre wichtiger als der Einzelfall: ollama show --license ist keine verlässliche Quelle. Wenn eine Lizenzfrage über den Einsatz eines Modells entscheidet, gehört der Text aus dem Repository des Herstellers geholt, nicht aus dem Werkzeug, mit dem ihr das Modell gerade laufen lasst. Bei Glimmer haben wir gezeigt, dass Blogpost und Lizenzdatei auseinandergehen können. Hier gehen zwei Auslieferungen derselben Datei auseinander.

Wer den Lizenzcheck für alle vier in einer Minute machen will, geht in dieser Reihenfolge vor: Liegt euer Jahresumsatz über 10 Millionen Dollar, fällt LFM2.5 aus, ohne Verhandlung mit Liquid AI. Verarbeitet euer Anwendungsfall sensible personenbezogene Daten, etwa im Personalwesen oder im Gesundheitsbereich, oder arbeitet ihr in Rüstung oder kritischer Infrastruktur, braucht Glimmer vorher eine Rechtsprüfung wegen der Usage Policy. Bei Nemotron notiert ihr euch, unter welcher Lizenz ihr es bezogen habt, und legt die OpenMDW-Datei aus NVIDIAs Repository zu den Akten. Shieldstral überlebt alle Fragen unbeschadet.

Der Praxistest: zwei 30B-Modelle auf einem M3 Pro

Ab hier wird es technisch. Die Kurzfassung für alle, die den Rest überspringen wollen: Beide Modelle laufen auf einem gewöhnlichen Arbeits-MacBook, und beide liefern brauchbare Antworten. Bei der Geschwindigkeit liegen sie aber um den Faktor fünf auseinander, obwohl sie dieselbe Größenklasse tragen. Glimmer ist für Agentenarbeit auf diesem Gerät zu langsam, Nemotron nicht.

Getestet haben wir beide auf demselben MacBook mit Apple M3 Pro und 36 GB Unified Memory. Das ist bewusst kein Spitzengerät: Metas Referenzhardware sind MacBook M4 Max und M5 Max sowie eine RTX 5090, NVIDIA nennt RTX-PCs, DGX Spark und RTX-PRO-Workstations. Also jeweils das obere Ende dessen, was man noch "Consumer" nennt. Die interessante Frage ist ja gerade, was eine Klasse darunter passiert.

Erste Hürde: die Werkzeugkette, zweimal dieselbe

Glimmer braucht Ollama in Version 0.32.8. Diese Version erschien am 10. August, am selben Tag wie das Modell. Homebrew lieferte am Tag darauf noch 0.32.7, und damit bricht der Download kommentarlos ab:

Error: pull model manifest: 412:
The model you are attempting to pull requires a newer version of Ollama.

Erst mit der offiziellen Binary von GitHub lief es. Bei Nemotron wiederholte sich das exakt einen Tag später: Das Modell verlangt 0.32.9, erschienen am 11. August, und Homebrew lieferte am Morgen des 12. August immer noch 0.32.7. Wieder half nur die offizielle Binary.

Der Nachtrag gehört dazu, weil er die Empfehlung entschärft: Homebrew zog am selben Vormittag auf 0.32.9 nach, keine drei Stunden nach unserem Testlauf. Der Rückstand betrug hier also Stunden, nicht Tage.

Zweimal derselbe Stolperstein in zwei Tagen bleibt trotzdem ein Muster, und es ist ein vorhersehbares: Wer ein Modell am Erscheinungstag ausprobieren will, trifft mit einiger Wahrscheinlichkeit auf einen Paketmanager, der die passende Ollama-Version noch nicht hat. Die Tag-eins-Unterstützung ist echt, sie hängt nur an einem Release, das erst durch die Distributionswege muss. Wer nicht warten will, holt sich die Binary direkt von GitHub, wer warten kann, wartet einen halben Tag.

Der Download selbst war bei Nemotron ebenfalls zäh: 25 GB, und der Server brach die Verbindung wiederholt ab ("unexpected EOF, retrying"). Ollama setzt jedes Mal sauber wieder auf, es dauert nur.

Was gemessen wurde

Das Modell ist in der Variante q4_K_M ein 18-GB-Download und belegt im Betrieb 16 GB. ollama show verrät dabei mehr über das Modell als Metas Blogpost, unter anderem die Parameterzahl und die Kontextlänge, die im Blogpost gar nicht steht:

  Model
    architecture        muse-glimmer
    parameters          27.9B
    context length      131072
    embedding length    6656
    quantization        Q4_K_M
    requires            0.32.8

  Capabilities
    completion
    vision
    tools
    thinking

Im laufenden Betrieb dann die erfreulichste Zahl des Tests: Das Modell liegt vollständig auf der GPU, nichts wird auf die CPU ausgelagert. Die Ausgabe ist hier um die Spalten ID und Ablaufzeit gekürzt:

NAME                       SIZE     PROCESSOR    CONTEXT
muse-glimmer:30b-q4_K_M    16 GB    100% GPU     32768

Das bleibt auch so, wenn man das volle Kontextfenster von 131.072 Token anfordert. Wie in der Ausgabe zu sehen, setzt Ollama den Kontext standardmäßig auf 32.768, wer mehr will, muss es explizit konfigurieren.

Nemotron ist ein 25-GB-Download und belegt im Betrieb ebenfalls 25 GB. Dieselbe Abfrage zeigt hier die Architektur und ein Kontextfenster, das eine Größenordnung darüber liegt:

  Model
    architecture        nemotron_h_moe
    parameters          32.9B
    context length      1048576
    embedding length    2688
    quantization        Q4_K_M
    requires            0.32.9

  Capabilities
    completion
    tools
    thinking

Zwei Unterschiede zu Glimmer fallen sofort auf. Nemotron hat kein vision, ist also reines Textmodell, während Glimmer Bilder verarbeitet. Und die Einbettungslänge ist mit 2.688 weniger als halb so groß wie Glimmers 6.656, was zur Bauweise passt: Die Breite steckt hier in den Experten, nicht im Grundmodell.

Auch Nemotron lag vollständig auf der GPU, trotz der 25 GB:

NAME                                     SIZE     PROCESSOR    CONTEXT
nemotron-3.5-lightning:30b-a3b-q4_K_M    25 GB    100% GPU     32768

Die letzte Zeile der Zeitmessung ist nicht ganz sauber vergleichbar, weil die Kontexte unterschiedlich groß waren und Nemotron dabei fast viermal so viel geantwortet hat. Pro Token gerechnet wird der Abstand eher größer als kleiner: Glimmer braucht für 13.272 Prompt-Token allein rund 182 Sekunden, Nemotron für 11.565 Token etwa 28.

Das größere Modell ist das schnellere, und das ist kein Widerspruch. Glimmers Zahlen sind Physik: Der M3 Pro hat rund 150 GB/s Speicherbandbreite, das Modell belegt 16 GB, damit liegt das theoretische Maximum bei etwa 9 Token pro Sekunde. Die gemessenen 7,5 sind nah am Anschlag. Für jedes einzelne Token muss das Gerät das komplette Modell einmal durch den Speicherbus ziehen.

Nemotron belegt mit 25 GB deutlich mehr, aktiviert pro Token aber nur rund 3 Milliarden Parameter. Es liest also je Token nur einen Bruchteil dieser 25 GB, und genau deshalb bricht die Bandbreitenrechnung, die bei Glimmer noch gilt. Dazu kommen die Mamba-Schichten, deren Speicherbedarf pro Token konstant bleibt, statt mit dem Kontext zu wachsen. Sichtbar wird das an der Zeile, die uns am meisten überrascht hat: Nemotron generiert bei großem Kontext genauso schnell wie bei kurzem, teilweise sogar minimal schneller. Glimmer verliert dort spürbar.

Für die Praxis dreht das die Empfehlung um. Bei Glimmer kostet ein Kontext von 13.000 Token allein drei Minuten, bevor das erste Antwortzeichen fällt, ein Agentenlauf über einem Repository wird zur Geduldsprobe. Nemotron liest denselben Kontext in einer halben Minute. Ein lokaler Agent, der mehrere Runden über eine Codebasis dreht, ist damit auf diesem Gerät zum ersten Mal realistisch.

Der Preis dafür steht in der letzten Zeile: 25 GB im Betrieb. Auf unseren 36 GB lag das Modell noch vollständig auf der GPU, aber viel Luft bleibt nicht. Auf einem Gerät mit 24 GB fällt Nemotron in dieser Quantisierung aus, während Glimmer mit 16 GB dort noch läuft.

Die Reasoning-Falle

Glimmer denkt, bevor es antwortet, und zwar per Voreinstellung. Der Denkschritt landet in einem eigenen Feld und ist erstaunlich ausführlich. Auf die Aufforderung "Sag Hallo." produzierte das Modell 462 Zeichen Gedanken für 31 Zeichen Antwort. Bei einer Fachfrage lag das Verhältnis bei etwa sieben zu eins.

Zwei Beobachtungen dazu. Erstens denkt das Modell auf Englisch, auch wenn Frage und Antwort deutsch sind. Zweitens wirkt der Denkprozess redundant, er wiederholt die Aufgabenstellung mehrfach und tastet sich in Halbsätzen voran.

Das hat eine praktische Konsequenz, in die wir beim ersten Testlauf prompt hineingelaufen sind: Mit einem knappen Token-Budget kommt gar keine Antwort. Das Budget geht vollständig ins Denken, die Anfrage endet mit done_reason: length, und das Antwortfeld bleibt leer. Wer Glimmer in eine Pipeline einbaut, muss das Budget großzügig setzen oder das Denken abschalten. Letzteres halbierte in unserem Test die Laufzeit von 110 auf 49 Sekunden bei gleicher Aufgabe und praktisch gleicher Antwortqualität.

Bei Nemotron ist dieselbe Falle noch etwas tiefer, und wir sind erneut hineingetreten. Auf "Sag Hallo." kamen 612 Zeichen Gedanken für 39 Zeichen Antwort. Bei zwei von sechs Testläufen blieb das Antwortfeld komplett leer, obwohl das Budget bei 400 beziehungsweise 600 Token lag: Beide Male ging es vollständig ins Denken, beide Male endete der Lauf mit done_reason: length.

Der Effekt des Abschaltens ist hier drastischer als bei Glimmer. Dieselbe Aufgabe, einmal mit und einmal ohne Denkschritt:

Faktor zehn bei der Laufzeit, bei praktisch identischer Antwort. Für die aufwendigeren Aufgaben blieb die Qualität ebenfalls gleich: Die Sicherheitsanalyse über 11.565 Token lieferte ohne Denkschritt dasselbe korrekte Ergebnis, nur in 2,2 statt 43,6 Sekunden.

Die Lehre gilt inzwischen für beide Modelle, und sie ist die praktischste Erkenntnis dieses Tests: Bei Reasoning-Modellen in einer Pipeline ist think: false die richtige Voreinstellung, nicht die Ausnahme. Eingeschaltet wird der Denkschritt für die Aufgaben, bei denen er nachweislich etwas bringt. Wer es andersherum macht, zahlt die Rechenzeit bei jeder Trivialanfrage mit.

Ein kosmetisches Detail am Rande: Nemotron setzt mit Denkschritt gern ein Emoji in die Antwort ("Hallo! 👋"), ohne nicht. Wer die Ausgabe weiterverarbeitet, sollte damit rechnen.

Die Qualität stimmt

Das ist die gute Nachricht, und sie war in allen vier Tests konsistent. Das Deutsch ist idiomatisch, mit korrekten Umlauten und richtig eingesetzten Fachbegriffen. Auf die Bitte um genau drei Sätze zum Thema lokale KI und Datenschutz kamen genau drei Sätze, inhaltlich sauber.

Beim Code ebenso. Gefragt war eine Funktion, die Pfade außerhalb eines erlaubten Basisverzeichnisses erkennt. Glimmer lieferte den kanonischen Ansatz, ohne Umwege:

from pathlib import Path

def paths_outside_base(paths, base_dir):
    base = Path(base_dir).resolve()
    outside = []
    for p in paths:
        try:
            Path(p).resolve().relative_to(base)
        except ValueError:
            outside.append(p)
    return outside

Das ist genau richtig: erst auflösen, dann relative_to als Prüfung nutzen und den ValueError als Signal für "liegt außerhalb" behandeln. Kein Stringvergleich, keine selbstgebaute Normalisierung.

Auch das Tool Calling saß auf Anhieb, und zwar mit deutschen Parameternamen aus einer deutschen Anfrage heraus:

Kein erklärender Text daneben, keine erfundenen Parameter, kein zweiter Anlauf. Für ein Modell, das genau dafür gebaut wurde, ist das die Mindesterwartung, aber sie wird nicht von allen erfüllt.

Zuletzt der Test, der am meisten über die Eignung als Coding-Assistent sagt: rund 13.000 Token Beispielcode mit einer eingebauten Schwachstelle, dazu die Frage nach dem Sicherheitsproblem. Glimmer erkannte den Path Traversal und benannte ihn präzise, mit Verweis auf die konkrete unverifizierte Variable. Inhaltlich also alles richtig, es dauerte nur gut drei Minuten.

Und Nemotron?

Nemotron besteht dieselben Prüfungen, aber nicht überall gleich gut. Das Tool Calling sitzt genauso sauber, mit deutschen Parameternamen und ohne Begleittext. Das Deutsch stimmt, drei geforderte Sätze wurden drei Sätze, Umlaute korrekt.

Beim Code wird der Unterschied deutlich. Dieselbe Aufgabe wie oben, Pfade außerhalb eines Basisverzeichnisses finden:

import os

def filter_outside_paths(paths, base_dir):
    normalized_base = os.path.normpath(base_dir)
    result = []

    for path in paths:
        try:
            abs_path = os.path.normpath(os.path.abspath(path))
            if not abs_path.startswith(normalized_base + os.sep) and abs_path != normalized_base:
                result.append(path)
        except ValueError:
            result.append(path)

    return result

Das funktioniert für den einfachen Fall, ist aber die schwächere Lösung. os.path.abspath löst keine Symlinks auf, os.path.realpath täte das. Ein Link innerhalb des Basisverzeichnisses, der nach außen zeigt, rutscht hier durch. Dazu kommt ein try/except ValueError um Aufrufe, die gar keinen ValueError werfen. Glimmers Antwort mit Path.resolve() und relative_to() ist an beiden Punkten sauberer.

Bei der Sicherheitsanalyse über den großen Kontext fand Nemotron den eingebauten Path Traversal zuverlässig:

Path Traversal via handle_download_request, das durch os.path.join(BASE_DIR, filename) ohne Validierung ausgenutzt werden kann.

Inhaltlich richtig, und in 2,2 Sekunden statt der gut drei Minuten, die Glimmer dafür brauchte. Etwas ungenau ist die Zuordnung trotzdem: Der verwundbare os.path.join steht in read_user_file, handle_download_request ist der Aufrufer. Glimmer hatte hier die konkrete unverifizierte Variable benannt.

Das Muster über alle Tests: Nemotron ist um ein Vielfaches schneller und für Werkzeugaufrufe mindestens ebenbürtig, bei der Sorgfalt im Code liegt Glimmer vorn. Das passt zum Einsatzzweck, den NVIDIA selbst nennt. Nemotron ist als Ausführungsschicht für Agenten gebaut, die viele kleine Schritte machen, nicht als das Modell, das den schwierigen Entwurf schreibt.

Muss das Modell überhaupt in den Speicher passen?

Die ganze Rechnung oben steht auf einer Annahme: Was nicht in den Arbeitsspeicher passt, läuft nicht. Deshalb fällt Nemotron auf einem 24-GB-Gerät aus. Diese Annahme ist seit dem 01.09.2026 angreifbar, und zwar mit demselben Argument, mit dem wir Nemotrons Tempo erklärt haben.

Wenn pro Token nur ein Bruchteil der Gewichte aktiv ist, müssen dann wirklich alle gleichzeitig im Speicher liegen? Ein Einzelprojekt namens slotstream sagt nein und zeigt es an einem extremen Beispiel. Es fährt Qwen3.8-Flash-Next, ein Mixture-of-Experts mit 125 Milliarden Parametern und 104 GB Gewichten auf der Platte, auf einem Mac mit 48 GB.

Der Trick liegt in der Aufteilung. Fast alle Bytes des Modells stecken in zwei Blöcken, nämlich 68 GB Experten (512 pro Schicht, davon 10 pro Token aktiv) und einer 32 GB großen N-Gramm-Tabelle. Der dichte Rumpf ist nur 3,8 GB groß und bleibt dauerhaft im Speicher. Die Experten werden per pread von der SSD in einen festen Cache-Pool geladen, den sich alle Schichten teilen, sodass stark genutzte Schichten sich Plätze von wenig genutzten borgen können.

Die Zahlen auf einem 48-GB-Mac mit M5 Pro: rund 12 Token pro Sekunde beim warmen Decode, etwa 2 Sekunden Startzeit, weil nur der Rumpf geladen wird, und rund 32 GB Spitzenspeicher. Für kleinere Maschinen nennt das Projekt eine Staffel bis hinunter zu 8 GB, wo noch etwa 3 Token pro Sekunde herauskommen sollen.

An dieser Stelle ist Vorsicht angebracht, und das Projekt selbst benennt sie. Nur die 48-GB-Zeile ist auf echter Hardware gemessen, alle anderen Werte sind aus deren Kurve geschätzt, und kleinere Macs haben zusätzlich langsamere SSDs. Wir haben das nicht nachgemessen. Anders als der Rest dieses Artikels sind die Zahlen hier also Fremdangaben.

Dazu kommen handfeste Grenzen. Unterstützt wird genau dieses eine Modell. Prompt und Antwort zusammen sind auf 32.768 Token gedeckelt. Vor allem aber ist der Prompt die langsame Achse: Er wird vollständig verarbeitet, bevor das erste Token erscheint, und 8.000 Token warten auf dem 48-GB-Mac laut Projekt etwa eine Minute, auf einem 16-GB-Gerät über drei. Innerhalb einer Unterhaltung zahlt man das nur einmal, Folgeturns verarbeiten nur das Neue. Und die Platte beißt vor dem Speicher: Nötig sind rund 110 GB frei, realistisch also mindestens ein 512-GB-Mac.

Für den Alltag ist das damit nichts. Ein Modell, das eine Minute braucht, bevor es anfängt zu antworten, ersetzt keines der vier oben. Interessant ist die Richtung. Die Frage bei der Anschaffung war bisher "wie viel Speicher brauche ich für das größte Modell". Bei Mixture-of-Experts-Architekturen wird daraus perspektivisch "wie viel Speicher brauche ich für die aktiven Experten, und wie schnell ist meine SSD". Praktisch hilfreich ist außerdem, dass slotstream die Ollama- und die OpenAI-Chat-API spricht, bestehende Werkzeuge also unverändert weiterlaufen.

Ein Punkt gehört noch dazu, weil er die Lizenzlektion von weiter oben bestätigt. Slotstream selbst steht unter MIT. Das sagt aber nichts über die Gewichte: Qwen3.8-Flash-Next läuft unter der Qwen Community License 1.0, auf Hugging Face als license: other geführt. Werkzeug und Modell haben getrennte Lizenzen, und die des Werkzeugs ist die unwichtigere von beiden.

Was Teams daraus mitnehmen

Die Lizenz gehört vor die Technik. Bei drei von vier Modellen entscheidet sie über den Einsatz oder braucht zumindest einen zweiten Blick, unabhängig davon, wie gut die Modelle sind. Und sie steht nicht auf der Modellkarte: Bei LFM2.5 muss man bis Abschnitt 5 des Lizenztexts lesen, bei Glimmer in eine separate Datei daneben schauen, und bei Nemotron hängt es sogar davon ab, über welchen Kanal ihr das Modell bezogen habt. Holt den Lizenztext beim Hersteller, nicht beim Werkzeug.

Der zweite Punkt ist der, an dem wir unsere eigene Empfehlung von gestern einschränken müssen. Nach dem Glimmer-Test lautete sie: Der Deckel ist die Speicherbandbreite, nicht die Kapazität, also schaut auf GB pro Sekunde statt auf GB. Das gilt weiterhin, aber nur für Modelle, bei denen pro Token alle Gewichte gelesen werden. Nemotron ist mit 25 GB anderthalbmal so groß wie Glimmer und trotzdem viermal so schnell, weil pro Token nur rund 3 der 32,9 Milliarden Parameter aktiv sind.

Die brauchbarere Faustregel heißt deshalb: Nicht die Modellgröße bestimmt die Geschwindigkeit, sondern die aktiven Parameter pro Token. Die Modellgröße bestimmt, ob es überhaupt in den Speicher passt, und selbst das gilt inzwischen nur noch für den üblichen Weg über Ollama, wie der Abschnitt zu slotstream oben zeigt. Das sind zwei verschiedene Fragen, und die Produktnamen beantworten keine davon. Wer eine Maschine anschafft, braucht beide Zahlen: genug Kapazität für das größte Modell, das laufen soll, und genug Bandbreite für den dichtesten Kandidaten. Für die Hardware-Seite drumherum, von NPUs bis zur Compliance-Frage, haben wir das in Lokale KI: Deine Daten bleiben bei dir ausgeführt.

Was heißt das nun konkret? Eine Ein- und Ausgabeprüfung für ein eigenes KI-Feature ist mit Shieldstral heute lösbar. Klein, schnell und ohne Lizenzrisiko. Für einen Agenten auf schwacher Hardware ist LFM2.5 der Kandidat, sofern die Umsatzschwelle passt. Für einen lokalen Agenten, der viele Schritte macht und dabei große Kontexte liest, ist Nemotron 3.5 Lightning die erste Wahl in diesem Feld, sofern ihr die 25 GB unterbringt. Und wenn es auf Sorgfalt im erzeugten Code ankommt oder Bilder im Spiel sind, bleibt Glimmer vorn, dann aber auf einer Maschine oberhalb dessen, was in den meisten Teams auf den Schreibtischen steht.

Bleibt der Hinweis, den wir uns bei jedem dieser Releases selbst geben: Die Leistungsaussagen der Hersteller taugen zur Orientierung und sonst wenig. Metas Hauptbenchmarks laufen gegen ähnlich große Modelle wie Gemma4-31B und Qwen3.6-27B, gegen die großen geschlossenen Cloud-Modelle vergleicht Meta gar nicht erst. NVIDIA wirbt mit bis zu vierfacher Ausgabegeschwindigkeit und 30 Prozent schnellerer Aufgabenerledigung, gemessen mit einem Benchmark namens PinchBench, den wir nicht nachgeprüft haben. Dass unsere eigene Messung in dieselbe Richtung zeigt, macht die Herstellerzahl nicht richtig, es macht sie nur plausibel. Ein Nachmittag mit dem heruntergeladenen Modell sagt mehr als jedes Datenblatt, und er kostet außer Bandbreite nichts.