Colibri führt GLM-5.2 auf Consumer-Hardware aus. Der Haken.

Colibri kann GLM-5.2 weiterhin mit ungefähr 25 GB RAM ausführen. Das ist ein Fortschritt bei der benötigten Speicherkapazität, aber kein Versprechen für schnelle Chats. Die ursprüngliche Entwicklermessung lag bei kaltem Cache bei 0,05-0,1 erzeugten Token pro Sekunde. 100 Ausgabe-Token benötigen damit rechnerisch etwa 17-33 Minuten, ohne Prompt-Verarbeitung. Spätere Messungen mit bestimmten Modellcontainern sind schneller. Der alte Wert ist deshalb keine allgemeine Obergrenze für ein RAM-Budget von 25 GB.

Aktualisiert und anhand der Quellen geprüft am 24. September 2026. Die neueste für diesen Artikel verifizierte Veröffentlichung ist Colibri v1.12.0 vom 20. September. Die bisherige Beschreibung als überwiegend textorientiertes Experiment mit acht Modellfamilien reicht nicht mehr aus. Brio bewertet erlaubte Antworten, ohne eine Antwort zu generieren; das Dashboard wurde neu gestaltet und mehrere Backend- und Validierungsfehler wurden behoben. Bereits Version 1.11.0 hatte DeepSeek V4.1 Flash als neunte Engine-Familie ergänzt.

Der Schwerpunkt dieses Artikels bleibt erhalten: Was leistet Colibri auf Ihrer Hardware tatsächlich, welche Kosten entstehen durch Latenz und Speicherbedarf, und wie testen Sie das, ohne einen erfolgreichen Start mit einer produktiven Bereitstellung zu verwechseln? Sämtliche Geschwindigkeiten stammen aus den verlinkten Projektmessungen, nicht aus Wavect-Benchmarks.

Was ist Colibri, und was hat sich seit unserem letzten Review geändert?

Colibri, vom Projekt als Colibrì geschrieben, ist eine unter Apache 2.0 veröffentlichte Inferenzlaufzeit. Sie verteilt Modellgewichte auf NVMe-Speicher, Arbeitsspeicher und optionalen Grafikspeicher. Dabei wird kein Modell mit 744 Milliarden Parametern in 25 GB gepresst. Der Checkpoint bleibt auf dem Datenträger; nur die gerade benötigten Teile müssen in schnellerem Speicher liegen. Die README der geprüften Version unterscheidet zwischen der abhängigkeitsfreien C-Inferenzengine und dem Python-Launcher samt HTTP-Gateway. „Kein Python zur Laufzeit“ ist für den üblichen coli-Workflow deshalb irreführend.

Der Colibri-Container für GLM-5.3 umfasst ungefähr 419 GB und verwendet dieselbe Engine-Familie wie GLM-5.2. Anders als der empfohlene 5.2-Container enthält er keinen MTP-Head. Dieser Pfad für spekulatives Decoding bleibt daher ausgeschaltet. Es handelt sich um einen anderen Checkpoint, nicht um ein automatisches Upgrade vorhandener 5.2-Gewichte.

Wie läuft ein 744B-Modell mit 25 GB RAM?

GLM-5.2 ist ein Mixture-of-Experts-Modell: Pro Token sind ungefähr 40B der rund 744B Parameter aktiv. Die offizielle Modellkarte beschreibt das Modell. Ihre Leistungsangaben belegen jedoch nicht automatisch die Qualität einer bestimmten Colibri-Quantisierung. Colibri hält ungefähr 9,9 GB dichter Gewichte im RAM und lädt ausgewählte geroutete Experten vom Datenträger. Das ursprüngliche Layout umfasst 19.456 Expertenblöcke über 75 MoE-Schichten und den MTP-Head.

Ein Cache pro Schicht, gelernte Priorisierung häufig verwendeter Experten, Betriebssystem-Caches und optionale GPU-Platzierung vermeiden einen Teil wiederholter Lesezugriffe. Für den ursprünglichen kalten Zustand werden etwa 11 GB gelesene Expertengewichte pro erzeugtem Token angegeben. Das ist eine Schätzung für ein bestimmtes Layout und eine bestimmte Last, keine Konstante für sämtliche Modelle, Checkpoints oder spekulativen Modi.

Zwei Dinge müssen getrennt werden: Quantisierung verändert die Darstellung der Gewichte; die Speicherhierarchie verändert deren Aufenthaltsort. Identische quantisierte Ergebnisse auf CPU und GPU beweisen nicht, dass die Quantisierung die Genauigkeit des ursprünglichen Modells erhalten hat. Umgekehrt kann eine korrekt rechnende Engine für Ihre Anwendung trotzdem zu langsam sein.

Welche Modelle unterstützt Colibri, und welche Hardware benötigen sie?

Das Familienregister von v1.12.0 hilft, eine Engine-Familie von einem Checkpoint-Namen zu unterscheiden. Neun Familien bedeuten nicht neun beliebig austauschbare Modellkennungen. Jede benötigt passende Implementierungen für Routing, Attention, Tensorformate und Chat-Verarbeitung. Colibri ist kein universeller GGUF-Loader.

Wichtige Korrektur zum Plattenbedarf: Die versionierte README bezeichnet den GLM-5.2-Container weiterhin als 372 GB groß. Die Container-Modellkarte enthält abweichende Größenangaben; die aktuelle Dateiliste zeigt ungefähr 429 GB. Planen Sie anhand der konkreten Revision und ausgewählten Dateien, nicht anhand der alten Schlagzeile. Dezimale GB und binäre GiB dürfen nicht vermischt werden. Ein kleinerer E8/IQ3-Container nennt etwa 289 GB, verändert aber die Gewichtsdarstellung und hat eigene Genauigkeits- und Decoding-Abwägungen. Die Verkleinerung ist nicht kostenlos.

Die Engine-Dokumentation für DeepSeek V4.1 Flash erklärt, warum die gesamte Checkpoint-Größe den Aufwand pro Token schlecht vorhersagt: Ungefähr 203 GB entfallen auf datenträgergestützten N-Gramm-Speicher. Die gerouteten Experten verursachen vor Cache-Treffern ungefähr 4,5 GB pro Token. Die Gewichte benötigen keine Konvertierung; die dokumentierte Einrichtung erzeugt jedoch eine kleine Begleitdatei namens dsv41_engram.json. „Keine Konvertierung“ bedeutet nicht „keine Vorbereitung“.

Auch bei Qwen3.8 widersprechen sich Dokumentationsstellen. Die alte README-Zusammenfassung nennt weiterhin mindestens 16 GB und ausschließlich CPU-Betrieb. Die detaillierten Qwen3.8-Messungen zeigen bei einer kurzen Anfrage mit cap 32 ungefähr 16,5 GiB maximale RSS und empfehlen für dieses Setup praktisch 24 GB Gesamtspeicher, für einen größeren Cache 32 GB. v1.12.0 ergänzt CUDA trotz verbliebener Aussagen über ein fehlendes Backend. Maßgeblich sind die zur Version passende Implementierung und die gemessene Konfiguration, nicht eine isolierte Tabellenzeile.

Wie schnell ist Colibri auf Consumer-Hardware?

Die Benchmark-Sammlung des Projekts dokumentiert die folgenden GLM-5.2-Ergebnisse. Die Core-Ultra-9-Zeile mit begrenztem RAM stammt aus der oben verlinkten Container-Karte. Es sind historische Läufe mit unterschiedlichen Builds, Cache-Verläufen und Containern, kein kontrollierter Vergleich unter v1.12.0. Einige ältere Zeilen erfüllen die inzwischen strengeren Anforderungen an GPU-Korrektheitsnachweise nicht.

Das Ergebnis mit sechs GPUs ist keine Ausgangsbasis für einen Consumer-Laptop. Spätere Tests mit selektiver NUMA-Platzierung erreichten auf einem bestimmten Mehrsockel-Host ungefähr 9 tok/s. Auch die in den Release Notes genannte Qwen3.6-Steigerung von 12,8 auf 15,7 tok/s bei sinkendem residentem Speicher von 29 auf 17 GB gehört zu diesem Qwen-Workload. Sie macht GLM-5.2 auf 25 GB nicht zu einem Modell mit 15,7 tok/s.

Für einen realen Dienst zählt die vollständige Anfrage: Warteschlange, Prompt-Prefill, Generierung und mögliche Werkzeugaufrufe. Ein wiederverwendeter Prompt kann nahezu ohne Prefill auskommen, während ein neues Dokument langsam bleibt. Ein Dashboard-Screenshot mit warmem Cache belegt keine Latenz für neue Dokumente.

Was sollten Sie zuerst optimieren: RAM, NVMe oder GPU?

Beginnen Sie bei der Phase, die tatsächlich die Laufzeit verbraucht. Auf einem GLM-System mit wenig RAM können wiederholte Cache-Fehlzugriffe dominieren. Auf einem weitgehend residenten System können dagegen CPU-Matrixmultiplikation oder Speicherbandbreite begrenzen. Beim historischen SSD-Vergleich auf demselben Rechner stieg die gemessene Bandbreite von 1,51 auf 8,81 GB/s, die Generierung aber nur von 0,10 auf 0,28 tok/s, weil die Rechenarbeit wichtiger wurde.

Messen Sie kalte, nicht zwischengespeicherte Shard-Lesezugriffe statt der beworbenen sequenziellen SSD-Höchstgeschwindigkeit. Unter macOS entfernt der dokumentierte F_NOCACHE-Test keine bereits vorhandenen Cache-Seiten. Vergleichen Sie außerdem mehrere Prompts: Gelernte Pins können die Trainingslast des Caches bevorzugen. Ein größerer Cache oder mehr zugewiesener RAM ist nicht automatisch schneller, wenn dadurch Ressourcenkonkurrenz entsteht oder Systemreserven fehlen.

Eine GPU hilft, wenn ihr Backend den gemessenen Engpass reduziert. Ihre bloße Anwesenheit beseitigt keine Plattenzugriffe. Zu jedem CUDA-, HIP-, Metal- oder Vulkan-Zeitwert gehört ein Qualitätscheck. Das Projekt dokumentiert einen HIP-Fall mit ähnlicher Geschwindigkeit, aber erheblich schlechterer Perplexität. Die reine Geschwindigkeit hätte den Fehler verdeckt.

Auch MTP ist ein Experiment, kein kostenloser Beschleunigungsschalter. GLM-5.2 benötigt den richtigen int8-MTP-Head; zusätzliche spekulative Expertenzugriffe können bei kaltem Cache nachteilig sein. Die Router-Abkürzung --topp 0.7 verändert das Routing ausdrücklich verlustbehaftet. Sie ist nicht dasselbe wie gewöhnliches Sampling von Ausgabe-Token. Sobald sich die Modellsemantik ändert, muss die Qualität erneut geprüft werden.

Wie viel Qualität erhält die GLM-5.2-int4-Variante?

Die Evidenz trägt weiterhin keine pauschale Aussage wie „Frontier-Qualität auf dem Laptop“. Ein kleiner GLM-5.2-Test des Projekts meldet 62,5 % mittlere normalisierte Genauigkeit über HellaSwag, ARC und MMLU bei nur 40 Fragen pro Aufgabe. Ein separates OLMoE-Experiment maß 8,2 Prozentpunkte Quantisierungsverlust; gruppierte Skalierung holte davon ungefähr 63 % zurück. Das sagt etwas über die Methode, ist aber kein sauberer Vergleich zwischen unquantisiertem GLM-5.2 und int4.

Es gibt inzwischen auch direktere GLM-Evidenz: Die gruppierte-int4-Modellkarte nennt für HellaSwag 87,0 % gegenüber 83,5 % normalisierter Genauigkeit bei zeilenweiser int4-Quantisierung, mit 200 Fragen. Die E8-Karte vergleicht ebenfalls mit gruppiertem int4. Ihre kleinen Stichproben und das eingeschaltete cacheabhängige Routing isolieren den Quantisierungsfehler jedoch nicht. Das sind hilfreiche, begrenzte Tests, keine Gleichwertigkeit zum Originalmodell und kein Nachweis produktiver Reasoning-Qualität.

Halten Sie bei eigenen Tests Checkpoint, Quantisierung, Prompt-Vorlage und erwartete Ergebnisse fest. Verwenden Sie schwierige Negativbeispiele, mehrsprachige Eingaben und Aufgaben, die zuvor Schleifen oder erschöpfte Ausgabelimits auslösten. Prüfen Sie sowohl Antwortqualität als auch korrektes Beenden. Tokenidentische Implementierung und nützliche Geschäftsergebnisse sind unterschiedliche Prüffragen.

Verschleißt Experten-Streaming die SSD?

11 GB gelesene Daten sind nicht 11 GB Verbrauch eines Schreibbudgets. Kingstons Erklärung von TBW und DWPD bezieht diese Kennzahlen auf geschriebene Daten und Programmier-/Löschzyklen. Colibris Expertenpfad ist leseintensiv. Modelldownloads, Konvertierung, gespeicherter Zustand und Betriebssystem-Swap können dennoch Schreibzugriffe verursachen.

Beobachten Sie bei einem langen repräsentativen Lauf Temperatur, SMART-Zustand und Swap-Aktivität. Lassen Sie RAM-Reserven, damit Caching nicht schreibintensive Auslagerung auslöst. Eine dedizierte 1-TB-NVMe ist für den ungefähr 429 GB großen Referenzdownload plus Betriebsreserve eine vernünftige Planungsgröße. Sie ist weder ein Softwareminimum noch eine Garantie, dass jede Konvertierung vom Quellmodell darauf passt. Temporären Speicherbedarf separat prüfen.

Was ist Colibri Brio, und wann bringt es einen Vorteil?

Brio ist ein Bewertungsmodus des bereits in Colibri geladenen Modells, kein neues Modell und keine Jev- oder Laya-Integration. Sie geben eine geschlossene Menge zulässiger Antworten vor. Die Engine bewertet deren Token und liefert eine Auswahl, relative Optionswerte und normalisierte Entropie, statt freien Text zu erzeugen.

Der Endpunkt unterstützt drei Formen: options für eine Frage, questions für mehrere Fragen zu demselben Zustand und schema für Felder mit festgelegten Wertelisten. Hier ist schema eine Brio-Zuordnung von Feldnamen zu zulässigen Werten, kein beliebiges JSON Schema. Der Server schreibt die JSON-Struktur; das Modell bewertet nur die erlaubten Werte. Formal korrektes JSON kann trotzdem die falsche Geschäftsentscheidung enthalten.

Null Completion-Token bedeuten nicht null Inferenzaufwand. Das Dokument benötigt weiterhin Prefill und jede Option muss bewertet werden. Präfix-Snapshots vermeiden einen Teil wiederholter Verarbeitung, solange die Engine läuft. Ein Neustart verliert diese Snapshots; dazwischenliegende Anfragen und verfügbare KV-Slots beeinflussen die Wiederverwendung. Das dokumentierte Vier-Felder-Beispiel benötigte mit Brio 103,8 Sekunden statt 246,0 Sekunden mit Generierung, rechnerisch etwa Faktor 2,37. Das ist ein Qwen3.6-Experiment des Projekts, kein GLM-Benchmark und keine allgemeine Einsparquote.

Standardmäßig mittelt Brio die logarithmierten Tokenwahrscheinlichkeiten, bevor die Optionswerte normalisiert werden. Das reduziert einen einfachen Längennachteil, macht den Wert aber nicht zu einer kalibrierten Wahrscheinlichkeit einer richtigen Entscheidung. Niedrige Entropie bedeutet, dass eine angebotene Option dominiert. Sie beweist nicht, dass die richtige Option überhaupt angeboten wurde. Planen Sie einen Prüfpfad ein, testen Sie alternative Formulierungen und Optionslängen und kalibrieren Sie Schwellenwerte anhand gelabelter Beispiele. Die zusätzliche Option „human review“ garantiert keine zuverlässige Enthaltung.

Wiederholte Klassifikation eines gemeinsamen Dokuments ist damit ein sinnvoller Testfall, wenn lokale Ausführung wichtig ist. Brio schlägt dadurch nicht automatisch einen kleinen Klassifikator, eine Regel oder einen gehosteten Entscheidungsendpunkt. Unser Review des Jev-Entscheidungsmodells behandelt diese separate Modellkategorie. Hier geht es gezielt darum, Colibris bestehende Engine effizienter zu nutzen.

Wie installieren und testen Sie Colibri v1.12.0?

Für einen reproduzierbaren Build auf einem unterstützten Unix-ähnlichen System sollten Sie die Version festlegen, statt einen unbekannten zukünftigen main-Stand zu laden. Python 3 und ein unterstützter C-Compiler mit OpenMP müssen vorhanden sein. Die folgenden Befehle laden keine Gewichte herunter: Unter /nvme/glm52_i4 muss bereits der oben verlinkte GLM-5.2-Referenzcontainer mit gruppiertem int4 und int8-MTP liegen. Für Windows oder andere Compiler und Backends gelten die jeweiligen Plattformanleitungen.

git clone --branch v1.12.0 --depth 1 https://github.com/JustVugg/colibri.git
cd colibri/c
./setup.sh
export COLI_MODEL=/nvme/glm52_i4
./coli doctor --deep
./coli plan
./coli chat

doctor --deep prüft die Modellbereitschaft; plan erklärt die Speicherplatzierung. Beide belegen weder Antwortqualität noch Dienstlatenz. Speichern Sie den Plan zusammen mit der Checkpoint-Revision oder Prüfsummen im Benchmark-Protokoll. Dieselbe Engine-Familie lädt GLM-5.3, benötigt aber dessen eigenen Container. Erwarten Sie nicht das MTP-Verhalten von GLM-5.2.

Starten Sie zum Gateway-Test einen dauerhaften Server in einem Terminal. Ersetzen Sie den Platzhalter durch ein starkes lokales Geheimnis und behalten Sie während der Evaluation die Loopback-Bindung bei:

export COLI_API_KEY='replace-with-a-long-random-local-secret'
COLI_MODEL=/nvme/glm52_i4 ./coli serve \
  --host 127.0.0.1 --port 8000 --model-id glm-5.2-colibri

Setzen Sie in einem zweiten Terminal COLI_API_KEY auf dasselbe Geheimnis und senden Sie dieses synthetische Brio-Beispiel. Die Modellkennung muss mit dem Server übereinstimmen. Die Anfrage schlägt eine Prüfwarteschlange vor. Sie erstattet keine Zahlung und beweist nicht, dass tatsächlich doppelt abgebucht wurde.

curl --fail-with-body http://127.0.0.1:8000/v1/brio \
  -H "Authorization: Bearer ${COLI_API_KEY:?Set the same key as the server}" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "model": "glm-5.2-colibri",
    "state": "The ticket reports two charges for one renewal. The payment ledger has not been checked.",
    "question": "Which team should inspect the evidence?",
    "options": ["billing", "technical support", "human review"],
    "normalize": "mean"
  }'

Das Beispiel basiert auf dem dokumentierten API-Vertrag, nicht auf einem für diesen Artikel durchgeführten Integrationstest. Ergänzen Sie in einer Anwendung ein zur gemessenen Prefill-Zeit passendes Timeout, Antwortvalidierung sowie Fehlerbehandlung für Warteschlangen-Ablehnung und Engine-Ausfälle. Machen Sie den Listener nicht öffentlich, nur damit sich ein entfernter Editor verbinden kann.

Lässt sich die API mit Claude Code oder einer Geschäftsanwendung verwenden?

Die Gateway-Dokumentation beschreibt OpenAI-kompatible Chat-/Completion-Routen und eine Route /v1/messages im Anthropic-Protokoll. Protokollkompatibilität garantiert weder identisches Werkzeugverhalten noch dieselbe Coding-Qualität. Große Agenten-Systemprompts und Werkzeugkataloge können die Zeit bis zum ersten Token gegenüber einem kurzen manuellen Chat stark erhöhen.

Der normale Serving-Pfad führt weiterhin nur eine Generierung gleichzeitig aus. Er begrenzt die Aufnahme neuer Anfragen und antwortet bei abgewiesenen oder abgelaufenen Warteschlangen-Anfragen mit HTTP 429. Mehrere KV-Slots halten getrennte Kontexte, soweit die Engine das unterstützt. Sie sind kein Continuous Batching und nicht bei allen Engines gleich verfügbar. Legen Sie Warteschlangen-Timeouts anhand gemessener Anfragedauern fest, nicht anhand optimistischer Tokenraten.

Manche API-Absätze behaupten noch pauschal, Bilder und Logwahrscheinlichkeiten würden nicht unterstützt. Das ist für das aktualisierte Projekt zu weit gefasst: Neuere Engines besitzen Vision-Pfade und Brio verwendet ausdrücklich Options-Logwahrscheinlichkeiten. Umgekehrt beweist Brio nicht, dass jeder normale API-Parameter, multimodale Inhaltsblock oder Werkzeugaufruf an jedem Endpunkt funktioniert. Prüfen Sie die genaue Kombination aus Engine, Endpunkt und Eingabeform. Nicht unterstützte Kombinationen sollten eindeutig scheitern, statt Daten still zu verwerfen.

Wo ergibt Colibri heute geschäftlich Sinn?

Unsere Einordnung ändert sich von einem pauschalen „nicht produktionsreif“ zu Workload und ausgewählte Engine getrennt bewerten. Das Projekt bietet konkrete Funktionen und Verbesserungen. Dieser Review belegt aber keinen produktiven Servicelevel. GLM-5.2 per Streaming auf einem 25-GB-Rechner bleibt für reaktionsschnelle, parallele Kundenchats eine schlechte Wahl.

Lokale Ausführung kann die Kontrolle über Modellverkehr verbessern. Sie löst nicht automatisch Zugriffsschutz, Aufbewahrung, Backups, Client-Telemetrie oder Berechtigungen. Für die Wirtschaftlichkeit nutzen Sie unseren Break-even-Leitfaden für lokale Modelle und APIs, statt nicht abgerechnete Token als kostenlos zu behandeln. Vor einem Hardwarekauf hilft unser llmfit-Hardwareleitfaden bei der Vorauswahl üblicher Modell-/Runtime-Kombinationen. Colibris Experten-Streaming-Cache simuliert er nicht.

Wie sollten Sie ein Upgrade vor dem verlässlichen Einsatz messen?

Verwenden Sie das reproduzierbare Benchmark-Protokoll des Projekts und bewahren Sie Rohprotokolle auf. Beginnen Sie mit repräsentativen Aufgaben statt einer einzelnen Begrüßung. Erfassen Sie Commit, Modellrevision, Konvertierungseinstellungen, Befehle, Kontextlänge, RAM-/VRAM-Platzierung und Datenträgerkonfiguration.

Trennen Sie kalte, identisch wiederholte und wechselnde Prompts in einem laufenden Server. Berichten Sie Erst-Token-Latenz, Gesamtzeit, akzeptierte Ausgabe, Decoding-Rate, Cache-Trefferrate, gelesene Bytes und maximalen Speicherverbrauch. Wiederholen Sie Konfigurationen abwechselnd, damit Temperatur, Cache-Verlauf und Hintergrundlast das Ergebnis nicht bestimmen. Für Brio gehören Optionsmenge, Normalisierung, Kosten falscher Zuordnungen und menschliche Prüfquote dazu.

Unsere Umsetzungsempfehlung beginnt im Schattenbetrieb: eine Entscheidung berechnen, ohne die Geschäftsaktion auszuführen, mit dem bisherigen Prozess vergleichen und erst nach Prüfung erweitern. Die Trennung zwischen überzeugender Demo und betreibbarem System zeigen auch unsere Twinsoft-AI-Fallstudie und unser Leitfaden zur Technologieauswahl. Wavects AI-Enablement-Service deckt Evaluation, Integration, Beobachtbarkeit und Rückfallmechanismen ab.

Quellen, Prüfdatum und Grenzen

Dies ist ein quellenbasierter technischer Review, aktualisiert am 24. September 2026 anhand von v1.12.0. Primärquellen stehen bei den zugehörigen Aussagen. Soweit verfügbar, verwenden wir Code und Dokumentation des Release-Tags. Modell-Repositories können sich weiter ändern. Das ursprüngliche Veröffentlichungsdatum bleibt 14. Juli 2026.

Wir haben die großen Checkpoints für dieses Update weder heruntergeladen noch ausgeführt, keine Community-Benchmarks reproduziert und keine laufende Brio-Installation getestet. Die Zeitumrechnung nutzt Sekunden = Ausgabe-Token / Token_pro_Sekunde, ohne Prefill und Warteschlange. Der Brio-Vergleich verwendet 246.0 / 103.8. Vorgeschlagene Abnahmekriterien und geschäftliche Eignung sind unsere Analyse, keine Garantien des Projekts. Dokumentationswidersprüche werden benannt und nicht in scheinbar sichere allgemeine Aussagen umgewandelt.

Sie brauchen aus diesen Tests eine belastbare Deployment-Entscheidung? Eine messbare lokale KI-Evaluation mit Wavect besprechen.