Mir ist heute ein Ollama-Release aufgefallen, das für alle relevant ist, die lokale Modelle auf dem Mac fahren: https://github.com/ollama/ollama/releases/tag/v0.40.0-rc0 Was drinsteht, ist kurz: Modellarchitekturen, die der MLX-Runner unterstützt, laufen auf Apple Silicon ab diesem Release standardmäßig über MLX. Kein Umschalten, kein Flag. Als Beispiel nennen die Release Notes ollama pull qwen3.8 und ollama run qwen3.8. Und es ist ausdrücklich ein Release Candidate: Weitere Modelle werden während der RC-Phase getestet und freigeschaltet. Warum mich das mehr interessiert als die meisten Release Notes: Meine Empfehlung auf dem Mac war immer MLX statt llama.cpp. Genau daran hing meine Zurückhaltung gegenüber Ollama – nie am Tooling, das war immer das bequemste. Wenn der Unterbau jetzt MLX ist, verschiebt sich die Frage von „welche Engine" zu „welche Feinheiten". Und die Feinheiten stehen nicht in der Meldung. Offen bleibt, wie sich der Prefix-Cache über mehrere Turns verhält, wie das Speicherverhalten bei parallelen Anfragen aussieht und welche Architekturen in der RC wirklich schon auf MLX laufen und welche still auf den alten Runner zurückfallen. Das sind offene Punkte, keine Mängel – aber es sind genau die Punkte, die im Alltag über Wartezeit entscheiden. Wie du das für dich einordnen kannst, ohne dich auf fremde Benchmarks zu verlassen: Nimm einen Prompt, den du wirklich täglich fährst – nicht „schreib ein Gedicht", sondern deinen echten Zusammenfassungs- oder Klassifikations-Prompt. Miss zwei Dinge getrennt: die Zeit bis zum ersten Token und die Tokens pro Sekunde danach. Und dann miss denselben Ablauf noch einmal als Multi-Turn-Session mit fünf, sechs Nachfragen. Genau dort trennt sich ein Setup, das den Kontext wiederverwendet, von einem, das jedes Mal neu rechnet – und genau dort merkst du einen Engine-Wechsel, nicht am Einzelprompt. Für die n8n-Seite bleibt die Rechnung nüchtern: Am Ende hängt ein HTTP-Node an einem lokalen Endpunkt. Was dahinter läuft, ist eine Frage von Tokens pro Sekunde, Stabilität unter Last und Wartungsaufwand. Beim Aufwand gewinnt Ollama klar – ein Befehl, fertig. Wenn die Geschwindigkeit aufholt, wird die Entscheidung für Teams ohne eigenen Infrastruktur-Menschen deutlich einfacher. Die Inferenz bleibt so oder so auf der eigenen Maschine.

Qwen hat gestern Qwen-Audio-3.1 vorgestellt, und weil die Meldung schnell falsch gelesen wird, hier der Punkt, auf den es ankommt: Das ist ein Cloud-Release, kein offenes Modell. Was drin ist: fünf Modelle (ASR, ASR-Next, TTS, TTS-Next, Realtime) und deutliche Preissenkungen — laut Meldung bis zu 95 % bei der Spracherkennung, 85 % bei Realtime, 70 % bei TTS. ASR-Next erkennt mehrere Sprecher mit Zeitstempeln, dazu Emotionen und Hintergrundgeräusche, und bereinigt Füllwörter automatisch. Was nicht drin steht: Parameterzahlen, Benchmarks, Lizenz — und kein Wort zu offenen Gewichten. Der Zugang läuft über Alibaba Cloud. Ich habe nichts gefunden, das auf einen Download der Gewichte hindeutet. Wenn jemand von euch etwas anderes sieht, korrigiert mich gerne. Warum ich das trotzdem poste: Der Sprecher-Split mit Zeitstempeln ist die Funktion, an der lokale Protokoll-Ketten bisher hängen. Ein Transkript ohne Sprecherzuordnung ist eine Textwand, mit Zuordnung ist es ein Protokoll. Genau da liegt für uns die Lücke. Wer die Kette lokal plant, sollte zwei Stellen getrennt betrachten: - Das ASR-Modell läuft einmal pro Aufnahme durch. Hier zählt, ob es in den Unified Memory passt und wie lang die Datei ist. - Das Sprachmodell danach arbeitet auf reinem Text. Grob 130 bis 150 gesprochene Wörter pro Minute, also rund 8.000 Wörter bei einer Stunde. Damit ist schnell das Kontextfenster erreicht, und du brauchst entweder abschnittsweises Zusammenfassen oder ein Modell mit großem Kontext. Bei mir läuft Whisper lokal, ohne Sprechertrennung. Ich schaue mir diese Woche an, was es dafür lokal gibt, und poste die Ergebnisse hier. Quelle: https://the-decoder.de/alibaba-stellt-sprechmodelle-fuer-erkennung-synthese-und-echtzeit-interaktion-vor/ Transkribiert ihr lokal oder in der Cloud, und wie löst ihr die Sprechertrennung?

Hugging Face hat angekündigt, dass Jun Kim, Erschaffer und Maintainer von oMLX, ins Team wechselt: https://huggingface.co/blog/omlx Was konkret in der Ankündigung steht: oMLX bleibt Apache 2.0, Jun führt das Projekt weiter wie bisher, aus dem Nebenprojekt wird ein finanziertes und dauerhaft gepflegtes Projekt. oMLX soll als Testfeld für neue Ideen dienen und weiterhin auf der Grundlagenarbeit seiner Abhängigkeiten aufbauen, genannt werden mlx-lm und mlx-vlm. Ergebnisse sollen dort upstream landen, wo es sinnvoll ist. Als konkreter Schwerpunkt wird der schnelle Weg von einer transformers-Modelldefinition zu einer Referenz-Implementierung in MLX genannt, die verschiedene Engines nutzen können – damit sich jede Engine auf ihre eigenen Besonderheiten konzentrieren kann. Die Zusammenarbeit mit mlx-lm, mlx-vlm und LM Studio wird ausdrücklich erwähnt. Für ein lokales Setup ist daran vor allem eine Größe interessant, die man selten misst: die Zeit zwischen einem Modell-Release und dem Moment, in dem es bei dir auf Apple Silicon brauchbar läuft. Genau da setzt der transformers-nach-MLX-Pfad an. Wer das für sich einordnen will, kann rückblickend schauen: Bei den letzten drei Modellen, die du lokal eingesetzt hast – wie viele Tage lagen jeweils zwischen Veröffentlichung und deinem ersten funktionierenden Lauf? Und wie oft war der Grund keine fehlende Hardware, sondern eine fehlende oder unfertige Portierung? Der zweite Punkt ist eher eine Architekturfrage als eine Tool-Frage. Wenn n8n-Workflows oder andere Automatisierungen auf einen lokalen Endpunkt zeigen, hängt deren Stabilität an der Pflege der Schicht darunter. Ein bezahlter Maintainer ist dafür ein Argument, das man einem Kunden nennen kann – aber eben kein Messwert. Nüchtern bleibt offen, wie viel tatsächlich in mlx-lm zurückfließt und ob dieser Pfad automatisiert genug wird, um bei neuen Releases am Tag eins zu greifen. In der Ankündigung steht das als Absicht, nicht als Fahrplan.

Auf Hacker News ist gerade "Kev" von Jared Palmer aufgetaucht: kleine Decision-Models in 0,8B, 4B und 9B auf Qwen3.5-Basis, Apache-2.0, mit Trainingscode und Evaluationsdaten: https://github.com/jaredpalmer/kev Das Prinzip kennt ihr vielleicht von TypeSafes Jev: Ein Text geht rein, dazu typisierte Fragen (Ja/Nein, Auswahl, Bewertung), und zurück kommen keine Sätze, sondern Wahrscheinlichkeiten für jede erlaubte Antwort. Kev erreicht das mit Training: ein LoRA-Adapter (Rang 16) plus ein kleiner eigener Bewertungskopf, der die Antwortoptionen gegen die Frage abgleicht. Laut README liegt Kev-9B auf dem eigenen Entwicklungssatz 3,5 Punkte hinter Jev (0,822 gegen 0,857). Ich habe letzte Woche denselben Weg ohne Training gebaut, snapjudge: https://github.com/Micha0827/snapjudge Dort liest die Engine die Wahrscheinlichkeiten direkt aus den Logits eines unveränderten Qwen-Modells, lokal mit MLX. Beide nutzen dieselbe Schnittstelle (/v1/systemone), ein Client kann also zwischen Jev, Kev und snapjudge umschalten. Meine Zahlen auf Deutsch, 114 gelabelte Geschäftsentscheidungen (Mail-Kategorie, Mieteranfragen, Buchungskategorien): Qwen3.6-35B-A3B kommt ohne jedes Training auf 95,6 %. 89 % der Antworten haben eine Sicherheit über 0,9, und davon sind 99 % richtig. Das ist für Automationen der eigentliche Punkt: Ab einer Schwelle entscheidet der Workflow allein, darunter geht es an einen Menschen. Zum Training, weil Kev genau darauf setzt: Ein Qwen3.5-2B mit LoRA stieg bei mir auf dem typed-decisions-Datensatz von 0,41 auf 0,78. Beim 4B hat dasselbe Training den Benchmark verbessert, auf meinem deutschen Satz aber verschlechtert (86,8 % statt 93,9 % untrainiert). Wer trainiert, bekommt einen Spezialisten für genau seine Aufgabe, keinen besseren Allrounder. Zwei Dinge, die ihr bei Kev prüfen solltet: Das README sagt selbst, dass die Reihenfolge der Optionen die Antwort ändern kann, und zu deutschen Texten gibt es keine Angaben. MLX ist erst als nächster Schritt geplant, auf dem Mac läuft es bis dahin in bf16 (4B und 9B passen auf 32 GB). Ich lasse Kev-4B als Nächstes auf meinen 114 deutschen Entscheidungen laufen und teile den Vergleich hier.

Nachtrag zu meinem Qwen-Image-2.1-Beitrag von gestern, diesmal zur Lizenz. Und es gibt seit heute eine wichtige Klarstellung von Qwen. Kurz zur Erinnerung, was lokal auf meiner RTX 5060 Ti (16 GB) herauskam: 1024² in 24 s, 2K in gut drei Minuten, echtes RGBA, deutsche Typografie fast fehlerfrei, Identitätserhalt beim Edit sehr gut. Qualitativ sehe ich gerade kein offenes Bildmodell, das mithält. Die Lizenz: Qwen-Image-2.1 steht unter der Qwen Research License, "for research or evaluation purposes only". Das ist ein Bruch zur bisherigen Linie, die Vorgänger standen unter Apache 2.0. Die Klarstellung von heute (Qwen und Qwen Developers auf X): "Outputs are not part of the licensed Materials. Users retain the rights to images and other content they generate using the model." Die Bilder gehören also euch. Was die Klarstellung nicht beantwortet: ob man das Modell selbst produktiv betreiben darf, zum Beispiel als Bildpipeline in einem Kundenprojekt. Das Modell steht weiter unter der Research License. Genau das habe ich Qwen gestern per Mail gefragt, zusammen mit dem Preis für eine kommerzielle Lizenz. Ich poste die Antwort hier. Meine Faustregel ab jetzt: zwei Fragen getrennt stellen. Wem gehört das Ergebnis? Und wofür darf ich das Modell betreiben? Bei Qwen-Image-2.1 ist die erste geklärt, die zweite noch nicht. Quelle zum Modell: https://the-decoder.de/alibabas-qwen-image-2-1-vereint-bildgenerierung-und-bearbeitung-in-einem-einzigen-open-weight-modell-das-lokal-laeuft/ Wie seht ihr das: Reicht euch die Klarstellung zu den Bildern, oder wartet ihr, bis auch der Betrieb geklärt ist?