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.