Quantisierte lokale Modelle bewerten: Qualität und Geschwindigkeit auf deiner Hardware

Warum vor der Auswahl messen?

Quantisierung senkt den Speicherbedarf für die Modellgewichte. Daraus lässt sich jedoch nicht unmittelbar ableiten, wie sich die Qualität bei einer bestimmten Aufgabe verändert. Auch die Parameterzahl eines Modells reicht nicht aus, um seine Geschwindigkeit auf deinem System vorherzusagen: Prozessor, verfügbarer Speicher, Inferenzkonfiguration, Kontext und Systemauslastung spielen ebenfalls eine Rolle. Eine fundierte Entscheidung erhältst du, indem du die Alternativen mit Eingaben misst, die der tatsächlichen Nutzung entsprechen.

Eine Studie aus dem Jahr 2025 verglich sechs lokal mit Ollama ausgeführte Modelle in einem akademischen Retrieval-Augmented-Generation-System. Untersucht wurden Genauigkeit, Zeit bis zum ersten Token und Generierungsgeschwindigkeit. Die Arbeit zeigt einen passenden empirischen Ansatz, belegt aber nicht, dass eine bestimmte GGUF-Quantisierung bei anderen Modellen, Aufgaben oder Geräten dieselbe Qualität bewahrt. Die folgende Anleitung überträgt das Grundprinzip auf ein eigenes Prüfverfahren: Lege zuerst fest, was als richtig gilt und welche Leistung du benötigst. Vergleiche anschließend jede Konfiguration mit einer ausdrücklich definierten Referenz.

1. Aufgabe und Baseline festlegen

Beschreibe zunächst, was das Modell im Produktivbetrieb leisten soll: Wer nutzt es, welche Eingaben erhält es, welche Ausgabe soll es liefern, welche Fehler sind kostspielig und wie lange darf es dauern? Bei der Extraktion von Feldern musst du die Übereinstimmung der Werte messen. Bei Antworten auf Basis von Dokumenten ist die Treue zu den Quellen entscheidend. Für Codegenerierung solltest du Tests ausführen, statt nur zu beurteilen, ob eine Antwort plausibel klingt. Wenn du unterschiedliche Aufgaben in einer einzigen Bewertung zusammenfasst, können wichtige Fehler verborgen bleiben.

Erstelle eine Testsammlung, die die erwartete Nutzung abbildet: häufige Eingabetypen, Grenzfälle, mehrdeutige Eingaben und schwierige Beispiele. Hinterlege für jeden Fall eine überprüfbare Referenz – etwa eine korrekte Antwort, erwartete Felder, automatisierte Tests oder ein Bewertungsraster – und dokumentiere deren Herkunft. Trenne eine Entwicklungsmenge, mit der du Prompts oder Parameter anpassen darfst, von einer Evaluationsmenge, die du nicht wiederholt zur Optimierung verwendest. So verringerst du das Risiko, eine Konfiguration auszuwählen, die nur bei bereits bekannten Beispielen gut funktioniert.

2. Qualität passend zur Aufgabe messen

Qualität ist keine einzelne Kennzahl. Bei Aufgaben mit bekannter Lösung berechnest du die Genauigkeit oder Trefferquote. Bei der Extraktion misst du die exakte Übereinstimmung pro Feld und pro Datensatz. Bei Klassifikationen solltest du Präzision und Recall je Klasse angeben, wenn falsch positive und falsch negative Ergebnisse unterschiedlich schwer wiegen. Für offene Textgenerierung verwendest du ein klar definiertes Bewertungsraster – etwa für Faktentreue, Vollständigkeit, Verständlichkeit und Nützlichkeit – und sammelst Fehlerbeispiele, um die Punktzahl einordnen zu können. Automatisierte Bewertungen oder Bewertungen durch ein weiteres Modell können bei großen Datenmengen helfen, sollten aber nicht ungeprüft als Referenz gelten.

Wenn das System JSON, eine feste Struktur, einen Tool-Aufruf oder eine Begrenzung der Länge verlangt, behandle das Format als eigenständiges Kriterium. Prüfe, ob die Ausgabe mit dem tatsächlich verwendeten Validator geparst werden kann und Pflichtfelder, Datentypen, Aufzählungen und Einschränkungen einhält. Dokumentiere bei stochastischer Ausgabe außerdem die Konsistenz zwischen mehreren Durchläufen: Eine einzige richtige Antwort belegt keine Zuverlässigkeit. Bei risikoreichen Aufgaben zählst du schwerwiegende Fehler ausdrücklich und legst eine Ablehnungsregel oder menschliche Kontrolle fest, bevor du die Modelle vergleichst.

3. Geschwindigkeit, Latenz und Speicher messen

Erfasse mindestens die Zeit bis zum ersten Token und die Generierungsgeschwindigkeit in Tokens pro Sekunde. Die erste Kennzahl gibt näherungsweise an, wie lange eine Person auf den Beginn der Antwort wartet. Die zweite beschreibt die anschließende Ausgabe. Ergänze die Gesamtzeit bis zur fertigen Antwort, denn eine lange Ausgabe kann trotz hoher Generierungsrate viel Zeit beanspruchen. Halte fest, welches Werkzeug die jeweilige Kennzahl meldet und was darin enthalten ist: Modellstart, Vorbereitung des Prompts, Verarbeitung der Eingabe oder nur die Generierung.

Protokolliere außerdem den Speicherverbrauch während der Inferenz und den getesteten Kontext. Die Größe einer GGUF-Datei entspricht nicht automatisch dem gesamten Speicherbedarf: Kontext, Attention-Cache, Laufzeitumgebung und Betriebssystem können ebenfalls eine Rolle spielen. Vergleiche dasselbe Modell und dieselbe Aufgabe mit identischem Kontextlimit, denselben Generierungsparametern und derselben Hardware. Wenn eine Konfiguration nicht in den Speicher passt und auf Auslagerung oder einen anderen Ausführungspfad zurückgreift, dokumentiere das. Andernfalls vergleichst du keine gleichartigen Bedingungen.

4. Einen kontrollierten Vergleich durchführen

Damit Unterschiede der geprüften Konfiguration zugeschrieben werden können, müssen Testsammlung, Promptvorlage, Tokenlimit, Temperatur und andere relevante Parameter konstant bleiben. Notiere Modellname und Revision, Herkunft der GGUF-Datei und genaue Quantisierung. Dokumentiere auch die Version von Ollama oder LM Studio, Betriebssystem, Prozessor, Beschleuniger, Speicher und Optionen zur Auslagerung von Modellschichten. Gib im Protokoll an, ob das Modell bereits geladen war oder ob du auch die Ladezeit misst.

Führe zunächst einen Aufwärmdurchlauf aus, wenn das Modell geladen oder die Ausführung stabilisiert werden muss. Vermische ihn nicht mit den üblichen Messungen, es sei denn, der Start gehört zu den betrieblichen Anforderungen. Wiederhole jeden Test mehrmals und gib Median sowie Streuung an, statt den günstigsten Durchlauf auszuwählen. Wenn die Anwendung stochastische Ausgaben erzeugt, fixiere – sofern das Werkzeug es zulässt – den Seed oder bewerte mehrere Stichproben mit derselben Richtlinie. Wechsle die Reihenfolge der Konfigurationen, wenn sich Temperatur oder Systemlast während der Sitzung verändern könnten. Wiederhole die Tests unter Bedingungen, die dem späteren Betrieb ähneln, und nicht nur direkt nach einem Neustart.

5. Zwischen Quantisierung und Modellgröße entscheiden

Prüfe zuerst, ob jede Option die zuvor festgelegten Anforderungen an Qualität und Leistung erfüllt. Verwirf Konfigurationen, die ein kritisches Kriterium verfehlen, selbst wenn sie bei einer anderen Kennzahl gut abschneiden. Vergleiche anschließend bei den verbleibenden Optionen Gesamtzeit, anfängliche Latenz, Speicherbedarf und Formatstabilität. Wenn eine aggressivere Quantisierung des größeren Modells die benötigte Qualität erhält und auf die Hardware passt, kann sie die bessere Wahl sein. Geht bei einer empfindlichen Aufgabe Genauigkeit verloren, kann ein kleineres Modell mit konservativerer Quantisierung besser abschneiden. Ohne Messungen gibt es keine allgemeine Regel, die diese Wahl entscheidet.

Es kann sich auch herausstellen, dass ein anderes Modell als ursprünglich geplant die beste Wahl ist. Denkbar ist außerdem ein Ablauf, der einfache Aufgaben an ein schnelles Modell weitergibt und ein leistungsfähigeres Modell für schwierige Fälle reserviert. Die zuvor erwähnte Ollama-Studie fand in ihrem eigenen RAG-System Unterschiede zwischen Modellen bei Geschwindigkeit und Genauigkeit. Diese Ergebnisse sind keine Garantie für eine andere Konfiguration. Halte für eine technische Begründung die Ergebnisse je Aufgabentyp fest und erkläre, welche Kompromisse das Team akzeptiert. Liegen zwei Optionen eng beieinander, berücksichtige die Messunsicherheit und wiederhole den Test, bevor du dich festlegst.

6. Grenzen und bewährte Vorgehensweisen

Eine kleine Testsammlung kann seltene Fehler übersehen. Eine Testsammlung, die den Entwicklungsbeispielen zu ähnlich ist, kann eine auf diese Fälle abgestimmte Konfiguration begünstigen. Auch eine aggregierte Punktzahl kann Fehler nach Sprache, Länge, Dokumenttyp oder seltener Klasse verbergen. Untersuche Ergebnisse deshalb nach Gruppen aufgeschlüsselt und bewahre Fehlerbeispiele auf. Liegt ein Unterschied innerhalb der Schwankungen zwischen den Durchläufen, solltest du ihn nicht ohne weitere Wiederholungen oder zusätzliche Belege als eindeutige Verbesserung darstellen.

Ergebnisse einer veröffentlichten Untersuchung in einem akademischen RAG-System gelten für deren untersuchten Aufbau und Konfiguration. Sie stellen weder eine GGUF-Quantisierungsevaluation noch eine universelle Empfehlung dar. Ebenso ersetzen allgemeine Angaben zu angeblich festen Qualitätsverlusten einer Quantisierungsstufe keinen Test mit dem konkreten Modell und der konkreten Aufgabe. Dokumentiere die Herkunft der Dateien, verwende in Testprompts keine personenbezogenen Daten ohne Genehmigung und setze bei potenziell schädlichen Fehlern menschliche Kontrolle oder Ablehnungsmechanismen ein. Prüfe nach der Bereitstellung regelmäßig eine Stichprobe aus der tatsächlichen Nutzung und wiederhole das Verfahren, wenn sich Modell, Laufzeitumgebung, Hardware oder Eingabemuster ändern.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.