Nachtrag zu meinem Beitrag über Kev und snapjudge: Ich hatte angekündigt, Kev-4B auf denselben 114 deutschen Entscheidungen laufen zu lassen. Hier ist der Vergleich. Setup - Kev-4B (jaredpalmer/kev-4b, Apache 2.0, Basis Qwen3.5-4B-Base plus Adapter), bf16, auf MLX, Server laut README: uv sync --extra serve, dann python -m kev.serve --run jaredpalmer/kev-4b --port 8009. Download rund 8 GB. Ich habe den Kev-Code vorher nach Netzwerk- und Exec-Aufrufen durchsucht: außer dem Download der Gewichte war nichts Auffälliges dabei. - Testsatz: 52 deutsche Kurztexte, 114 Entscheidungen (Mail: Kategorie, Dringlichkeit, Ton, Phishing; Mieter: Anliegen, Notfall; Konto: Kategorie). - Gleiches Skript (eval/run_eval.py) und gleiche Fragen für alle Modelle. Qwen in 4 Bit und im Prozess gerechnet, Kev in bf16 über die HTTP-Schnittstelle (/v1/systemone). Die Latenzen sind deshalb nicht direkt vergleichbar, die Trefferquoten schon. Ergebnis, gesamt Modell: Trefferquote | mittlere Sicherheit | ECE | p ≥ 0,9: Anteil / richtig | Median-Latenz (Kev über HTTP, Qwen im Prozess) - Kev-4B: 91,2 % | 80,0 % | 0,119 | 33 % / 100 % | 319 ms - Qwen3.5-4B: 93,9 % | 94,3 % | 0,044 | 84 % / 99 % | 182 ms - Qwen3.5-9B: 93,0 % | 94,0 % | 0,048 | 85 % / 99 % | 334 ms - Qwen3.6-35B-A3B: 95,6 % | 96,3 % | 0,016 | 89 % / 99 % | 242 ms - Qwen3.8-27B: 96,5 % | 94,5 % | 0,035 | 85 % / 99 % | 1059 ms Die 95-%-Intervalle bei n = 114: Kev 84,6 bis 95,2 %, Qwen3.5-4B 87,9 bis 97,0 %. Der Unterschied zum 4B sind drei Entscheidungen und liegt innerhalb der Streuung. Je Frage (Trefferquote) - konto.kategorie: Kev 90,0 % | Qwen3.5-4B 85,0 % - mail.dringend: 100 % | 100 % - mail.kategorie: 88,2 % | 94,1 % - mail.phishing: 94,1 % | 94,1 % - mail.ton: 100 % | 86,7 % - mieter.anliegen: 66,7 % | 100 % - mieter.notfall: 100 % | 100 % Was dahintersteckt - Kev ist deutlich vorsichtiger. Mit p ≥ 0,9 entscheidet es nur 33 % der Fälle automatisch (alle richtig), das Qwen3.5-4B 84 % (99 % richtig). Mit niedrigerer Schwelle holt Kev auf: p ≥ 0,8 sind 61 % der Fälle, p ≥ 0,7 sind 75 %, beide Male alle richtig; p ≥ 0,6 sind 86 % mit 98 % richtig. Die Schwelle gehört also zum Modell und muss gemessen werden.

Google hat EmbeddingGemma 2 veröffentlicht, und das ist für lokale RAG-Setups die interessantere Hälfte der Pipeline – über die fast niemand redet: https://the-decoder.de/embeddinggemma-2-googles-kleinstes-embedding-modell-schlaegt-doppelt-so-grosse-konkurrenz/ Was in der Meldung steht: ein offenes Modell mit 740 Millionen Parametern, das Text, Bilder, Video, Audio und Code in Vektoren umwandelt. Es läuft direkt auf dem Gerät, braucht rund 191 MB RAM und übertrifft laut Google teils doppelt so große Konkurrenzmodelle. Zusammen mit Gemma 4 ist es für Offline-RAG mit Datenschutzfokus gedacht. Der Grund, warum ich das hier poste: Die Qualität einer RAG-Kette entscheidet sich vor dem Sprachmodell. Wenn der Retriever die falschen drei Absätze liefert, rettet das kein Generator-Modell dahinter. Wir diskutieren hier viel über Modellgrößen und Token pro Sekunde – der Embedder ist dagegen ein 191-MB-Baustein, der die Antwortqualität mitbestimmt und auf jeder Apple-Silicon-Maschine neben dem eigentlichen Modell Platz hat. Für die RAM-Planung heißt das: Der Embedder fällt kaum ins Gewicht, die Entscheidung dreht sich um Qualität, nicht um Ressourcen. Zwei Dinge, die ich beim Einordnen für mich wichtig finde: Multimodal in einem Vektorraum. Reale Wissensbestände sind keine saubere Textdatenbank – Scans, Fotos, Mitschnitte, Codeschnipsel. Wer das bisher abdecken wollte, hat pro Datentyp eine eigene Pipeline gebaut. Ein gemeinsamer Raum spart diese Klebearbeit. Embeddings sind eine langfristige Entscheidung. Rechne vorher durch, was ein Modellwechsel bei dir kostet: Anzahl Dokumente mal Chunks pro Dokument ergibt die Zahl der Vektoren, die du bei jedem Wechsel komplett neu berechnest. Bei einem Cloud-Embedder läuft dafür jedes Dokument noch einmal durch fremde Server – bei Mandanten-, Patienten- oder Personalakten ist das keine Option. Lokal bleibt der Bestand reproduzierbar, auch wenn eine API morgen abgekündigt wird.

Kolibri-1 von Aleph Alpha (78 Mrd. Parameter, 3,46 Mrd. aktiv, Apache 2.0, seit 03.10.) ist zwei Tage alt und läuft schon auf dem Mac. Ich habe es gestern gemessen, hier die Ergebnisse mit Setup, damit ihr es nachbauen könnt. Setup - Gewichte: velaia/Kolibri-1-MLX-4bit, eine inoffizielle Umrechnung von FP8 auf MLX 4 Bit, 41 GiB: https://huggingface.co/velaia/Kolibri-1-MLX-4bit - Laufzeit: mlx-lm 0.32.0 in einer eigenen venv plus das mitgelieferte run.py, das das Modell registriert. Offizielle Unterstützung in mlx-lm gibt es noch nicht, deshalb geht es nur so. Ich habe den Code vorher gelesen, er enthält keinen Netzwerk- oder Exec-Code. - Mac: M2 Max, 96 GB. - Wichtig beim Start: Ohne Angabe läuft das Modell im langen Denkmodus. Für den Alltag habe ich reasoning_effort auf none gestellt: run.py server --model . --port 8727 --chat-template-args '{"reasoning_effort":"none"}' Tempo und Speicher - 56 bis 70 Token pro Sekunde beim Generieren (Rauchtest 70, 105er-Test 56 bis 60) - Prefill: 620 Token/s bei 7,5K Prompt, 511 Token/s bei 30K. Das heißt 12 bzw. 58 Sekunden bis zum ersten Token - Decode nach langem Prompt: 51 Token/s (7,5K), 40 Token/s (30K) - Spitzenspeicher 44 GB. Daneben läuft ein 35B in LM Studio mit rund 20 GB noch mit, mehr große Modelle würde ich nicht gleichzeitig laden. Qualität - Tool-Calling: 17 von 17 Fällen richtig, alle 39 Aufrufe korrekt, keine erfundenen Aufrufe, alle 5 Schreib-Fallen bestanden. Das ist für n8n-Pipelines das Wichtigste. - Deutsch: 4 bis 5 von 5 Punkten in allen Aufgaben, die beiden Business-Texte jeweils 13 von 15, keine Ausfälle ins Englische. - Mein 105-Punkte-Test: 74 Punkte (70 %), Platz 13 bis 16 von 24, gleichauf mit gpt-oss-20b. Vor Ministral-3-14B (67), hinter den Gemma-4-Modellen (79 bis 93). - Schwächen: Der Code der ersten Aufgabe stürzt im Standardaufruf ab. Beim Schweizer Datenschutzrecht (revDSG) sind alle drei Artikelverweise falsch, das Swiss-U.S. Data Privacy Framework fehlt, es argumentiert mit EU-Angemessenheit. Für Fachwissen zum Schweizer Recht würde ich es nicht einsetzen.