Was es wirklich braucht, um einem lokalen Modell zu vertrauen

Ich baue einen persönlichen KI-Assistenten, der statt eines Generalzweck-Modells eine kleine Flotte lokaler Modelle fährt: ein schnelles, billiges Worker-Model für Arbeit wie strukturierte Daten aus unordentlichem Text zu ziehen, und ein langsameres, größeres Modell als Rückfall für alles, was echtes Reasoning verlangt. Dieses Design funktioniert nur, wenn die Worker-Aufrufe billig und schnell genug sind, viele davon parallel laufen zu lassen, ohne bei jedem Schritt eine kommerzielle API anzusprechen. Billig und schnell, auf einem Mac, hieß eine Frage stellen, die die meisten MLX-Nutzer nie stellen müssen: Ist Apples eigener nativer Inference-Stack, nicht MLX, dafür eigentlich praktikabel?

Dieser Stack hat zwei Namen, die fremd klingen, wenn du nur MLX benutzt hast. CoreML ist Apples bestehendes Framework, Modelle direkt auf der Neural Engine, GPU oder CPU laufen zu lassen. Core AI ist der neuere, noch im Beta befindliche Nachfolger, den Apple speziell für diese Art von LLM-Arbeit auf dem Gerät baut. Keiner davon ist es, wohin die meisten Local-Inference-Gidsen weisen, und dafür gibt es einen Grund: Sie sind schwerer zu benutzen, die Dokumentation ist schmaler, und vorab war nicht offensichtlich, ob einer von beiden die Modelqualität hält, wenn echte Anfragen einlaufen.

Sechs Wochen und drei Arbeitsphasen später: Was tatsächlich geschah, und warum der Prozess, der mich dorthin brachte, wichtiger herausstellte als die Antwort selbst.

Gewichte in eine Form bringen, die macOS schnell laden kann

CoreML ist der naheliegende Startpunkt auf macOS. Apples Framework kompiliert Modellgewichte zu .mlmodelc-Bundles, die direkt auf Neural Engine, GPU oder CPU laden, je nachdem, was Hardware und Firmware zulassen. LFM2.5-350M von LiquidAI war der Kandidat für die Worker-Ebene: klein genug, dass mehrere Varianten neben einem größeren Rückfallmodell auf die Schijf passten, schnell genug für viele gleichzeitige Aufrufe.

LFM2.5 vom HuggingFace-Checkpoint nach CoreML zu konvertieren, bedeutete, es durch coreml-llm zu laufen, das ein Apple .mlpackage erzeugt, das auf dem Gerät zu .mlmodelc kompiliert wird. Dieser Kompilierungsschritt ist der ganze Punkt. Er macht CoreML bei der Inference schnell: Ahead-of-Time-Kompilierung auf hardware-spezifisches IR, nicht nur das Verpacken von Gewichten.

Die Konvertierung lieferte nicht ein Artifact. Zwei Achsen, Quantisierung (fp16, int8) und Kontextfenster (2K bis 32K), ergaben eine Matrix von Kandidaten, denn die Kontextlänge bestimmt die KV-Cache-Größe pro gleichzeitigem Aufruf und Quantisierung tauscht Qualität gegen Durchsatz. Drei Konfigurationen überlebten bis zur Qualitätstests:

• lfm2.5-350m-int8-2k: die Speed-Option. ~284 Tokens/Sek., minimales Kontext, niedrigster Speicherbedarf.
• lfm2.5-350m-fp16-16k: längerer Kontext, ~47 Tokens/Sek., Platz für größere Dokumente.
• lfm2.5-1.2b-fp16-32k: der Rückfall. Fast 4x die Parameter, ~3,2 Tokens/Sek., der Kandidat für Aufgaben, die die 350M-Modelle nicht schafften.

Eine Sache tauchte bei der Konvertierung auf und prägte alles danach: LFM2.5s Architektur trägt einen rollenden Faltungszustand, conv_state_in / conv_state_out, der getrennt vom Standard-KV-Cache verfolgt wird. Ein normaler Transformer braucht zwischen Decode-Schritten nur einen KV-Zustand. LFM2 braucht beide. Wenn das Zustandsmanagement falsch läuft, bricht die Ausgabe nicht sichtbar aus. Sie degradiert einfach leise. Das ist ein schlechterer Fehlermodus als ein Crash, denn nichts sagt dir, dass es passiert ist.

Die Architekturfrage beantworten, bevor eine Zeile Bridge-Code existiert

Bevor Serving-Code geschrieben wurde, war da eine frühere Frage, die es wert war, sauber zu klären: Wie teilen gleichzeitige Aufrufe ein geladenes Modell?

Der naive Ansatz, ein MLModel pro Aufruf, ist leicht nachvollziehbar und in der Praxis teuer. Ein MLModel von der Schijf zu laden kostet 250MB bis 2.300MB, je nach Konfiguration, und diese Kosten fallen bei jedem Load an. Zehn gleichzeitige Aufrufe bedeuten zehn Loads, was auf einem MacBook mit 32GB Unified Memory eine echte Einschränkung ist, keine theoretische.

Das richtige Muster, bestätigt über 16 Benchmark-Konfigurationen in einem früheren Test-Harness, ist, ein MLModel einmal zu laden und pro Aufruf eine frische MLState zu zuweisen. Der Zustand hält KV-Cache und Conv-Zustand einer einzelnen Sequenz: billig (24-385MB) und vollständig isoliert. Die Gewichte duplizieren sich nie. Das ist Apples beabsichtigte Architektur, aber nichts, was man allein aus den API-Docs ableiten würde; der Benchmark hat "wahrscheinlich" in "bestätigt" verwandelt. Die Concurrency-Gewinne waren real, aber bescheiden, wobei die 350M-int8-2K-Konfiguration bei 4 gleichzeitigen Aufrufen etwa 1,16x aggregierten Durchsatz erreichte, was mehr für die Kapazitätsplanung zählte als für das Ja/Nein zur Architektur selbst.

Derselbe Benchmark fand auch einen Umgebungs-Bug, der immer wieder auftauchen würde: macOS 26 Tahoos ANE-Firmware versagt still auf .all Compute Units und fällt ohne Warnung auf GPU oder CPU durch. Der Fix liegt nicht im Code. Es ist eine Fallback-Kette: .all anfordern, den Fehler abfangen, .cpuAndGPU versuchen, dann .cpuOnly. Wenn Apple den Firmware-Fix ausliefert, muss sich nichts ändern; .all fängt einfach an zu funktionieren.

Etwas bauen, das sauber startet

Die Bridge (der Dienst, der eine Anfrage annimmt und sie an das richtige Modell routet) ist eine Swift-Binary auf Vapor, strukturiert um zwei Actors. ModelRegistry hält pro Modell-ID einen ModelWorker und pre-loadet beim Boot alles, was in config.json steht. Wenn ein Modell nicht lädt, beendet der Prozess sofort, denn ein lauter Fehler beim Start schlägt einen mysteriösen drei Anfragen später in der Produktion. ModelWorker hält das geladenes Modell und weist pro Anfrage einen frischen Zustand zu, führt Prefill aus, dekodiert und verwirft den Zustand danach. Kein Leakage zwischen Anfragen, was speziell zählt, weil LFM2s rollender Conv-Zustand sonst den Kontext eines Anrufers in die Antwort eines anderen tragen würde.

Sauber zu booten kostete eine echte Debug-Runde. Das 1.2B-FP16-Modell löste beim Start einen OOM-Crash während der GPU-Kompilierung aus. Der Treiber versuchte, einen Ausführungsplan für ein 2,4GB-Modell im GPU-Speicher zu bauen, traf auf ein Limit, und macOS gab SIGKILL. Das Log hörte einfach auf:

No outputs specified. @ Impl

Der Fix war, das 1.2B-Modell in der Config auf .cpuOnly zu pinnen. Langsamer, aber es lädt. Zwei kleinere Probleme wurden im selben Durchgang behoben: Force-Unwraps auf CoreML-Ausgabewerten (sicher, bis ein Modell eine unerwartete Form zurückgibt, dann ein Crash) wurden zu guarded Unwraps mit echten Fehlern, und die Bridge wehrte überlange Prompts jetzt direkt ab, statt still ungültige KV-Cache-Positionen an das Modell durchzureichen. Danach luden und wärmten alle drei Modelle beim ersten Versuch:

[lfm2.5-350m-int8-2k] Loaded successfully and warmed up with computeUnits: MLComputeUnits(rawValue: 1)
[lfm2.5-350m-fp16-16k] Loaded successfully and warmed up with computeUnits: MLComputeUnits(rawValue: 0)
[lfm2.5-1.2b-fp16-32k] Loaded successfully and warmed up with computeUnits: MLComputeUnits(rawValue: 0)
[Boot] CoreML Bridge HTTP server starting on http://127.0.0.1:8090

Die Frage, die wirklich zählte: Kann es die Arbeit erledigen

Ein Modell, das startet und Anfragen bedient, hat noch nichts bewiesen. Der echte Test war eine Suite aus 13 Aufgaben über fünf Kategorien, gebaut, um direkt auf das abzubilden, was ein Worker-Model wie dieses tatsächlich tun muss: Extraktion, Klassifikation, Retrieval-QA, Verifikation und Code-Review. Jede Aufgabe ist retrieval-gegroundet, das heißt, die Antwort liegt im bereitgestellten Kontext und nirgendwo sonst. Das ist keine Designpräferenz. Ein Worker, der aus parametrischem Gedächtnis antwortet, wenn die Passage die Antwort nicht enthält, ist ein Halluzinationsrisiko in der Produktion, nicht ein Qualitätshärtchen, über das man die Schultern zuckt.

Alle drei Modelle fuhren die volle Suite bei Temperature 0,0, insgesamt 39 Aufrufe:

Beide 350M-Varianten landeten genau bei 5/13, mit identischen Aufgaben aus identischen Gründen gescheitert, was an sich die Erkenntnis ist. Quantisierung und Kontextfenster machten keinen Unterschied für das Fehlermuster, wodurch int8-Präzisionsverlust als Ursache ausscheidet. D1 und D2 verlangen, eine Behauptung und eine Quelle gleichzeitig im Attention zu halten und über die Beziehung dazwischen zu reasoning, was Inference statt Retrieval ist, und bei 350M Parametern hielt diese Lücke über beide Varianten. C1 war der interessantere Fehler: eine direkte Frage mit klar in der Passage stehender Antwort, und das Modell scheiterte trotzdem. Das deutete auf einen Prompt-Attractor-Effekt hin, bei dem das Prior des Modells, wie eine Frage zu beantworten ist, mit der Anweisung konkurrierte, die Antwort aus dem gegebenen Text zu ziehen. Die Prompt-Umformulierung, härter auf die Passage zu verankern, verbesserte C1 manchmal, aber nicht konsistent genug, um das Urteil zu drehen. E2 zeigte ein völlig anderes Muster: Das Modell markierte die richtige Funktion (eine mit legitimer Empty-List-Guard) als verdächtig, genau der False-Positive-Tendenz, die diese Aufgabe fangen sollte.

Die Bridge ausschließen, bevor man dem Modell die Schuld gibt

Bevor ich etwas über die Decke des 350M-Modells schlussfolgerte, gab es eine sorgfältigere Frage: Ist irgendetwas davon die Schuld der Bridge? HTTP-Routing, Chat-Template-Rendering, Input-Validierung, Token-Decoding durch CoreMLs Swift-API. Jede Schicht in diesem Stack könnte prinzipiell die Qualität gegenüber dem degradieren, was die rohen Gewichte können. Die Infrastruktur auszuschließen, bevor man dem Modell die Schuld gibt, ist die einzige methodologisch ehrliche Reihenfolge.

Hier bewährte sich MLX als Ground Truth zum Testen, statt als das Getestete. Der Isolationstest lud identische Gewichte über mlx_lm, zog LiquidAI/LFM2.5-350M-MLX-8bit direkt von HuggingFace und lief es nativ über MLX. Keine Bridge, keine HTTP-Schicht, keine Swift-CoreML-API dazwischen. Gleiche 13 Aufgaben, gleiche Prompts, gleiches Grading, Temperature 0,0.

Ergebnis: 5/13. Gleiche Aufgaben gescheitert. Gleiche Aufgaben bestanden.

Das regelt es sauber. Das 350M-LFM2.5-Modell hat auf dieser Skala eine echte Capability-Decke, und sie zeigt sich identisch, ob man es durch eine Swift-HTTP-Bridge oder durch MLXs Python-Runtime mit unveränderten HuggingFace-Gewichten fährt. Die Bridge degradiert nichts. Das Modell ist das Modell. Und die 10/13 des 1.2B-Modells beweist, dass die Suite selbst lösbar ist; nichts im Testdesign verlangt Capability, die nirgends in der LFM2.5-Familie existiert, sie existiert bei 350M Parametern schließlich noch nicht für Reasoning und mehrstufige Synthese. Extraktion und Klassifikation meistern die 350M-Modelle gut. Halluzinationsverweigerung, die eine Eigenschaft, auf die dieses ganze Design für Sicherheit wirklich baut, hielt über jeder Konfiguration.

350M ist für Reasoning unzuverlässig. 1,2B ist praktikabel. Die Laufzeitwahl ändert keines dieser Urteile.

Ein Fünf-Schritte-Protokoll, keine einmalige Antwort

Nichts davon ging wirklich um LFM2.5. Es ist ein wiederverwendbares Protokoll, jedes lokale Modell unter jeder Laufzeit zu evaluieren, und der Grund, warum sich diese Übung lohnte, sorgfältig statt schnell gemacht zu werden.

Zuerst die Gewichts-Herkunft pinnen: exakter Checkpoint, exakte Quantisierung, exakte Konvertierungspipeline. "350M int8" ist allein nicht spezifisch genug; Kontextfenster und Konvertierungswerkzeug ändern beide das Verhalten. Zweitens eine Laufzeit-Isolations-Baseline etablieren, indem rohe Gewichte durch eine direkte Laufzeit wie MLX laufen, bevor man irgendetwas testet, das eine Serving-Schicht berührt. Ohne diese Baseline ist ein Fehler über die Bridge nicht zuordenbar. Drittens die Pass/Fail-Qualitätssuite laufen. Die 13-Aufgaben-Struktur ist direkt wiederverwendbar gegen jeden Kandidaten, und der Halluzinationsverweigerungs-Test bleibt unverhandelbar, egal wie gut ein Modell anderswo abschneidet. Viertens die Bridge-Ergebnisse gegen die Isolations-Baseline vergleichen. Eine Übereinstimmung heißt, dass die Serving-Schicht sauber ist; eine Abweichung verengt die Suche genau auf das, was die Bridge hinzufügt. Und für alles, das knapp unter der Schwelle landet, fünftens eine Prompt-Sensitivitäts-Ablation laufen. Das C1-Ergebnis bewies, dass Formulierung einzelne Aufgaben-Ergebnisse verändert, während die zugrunde liegende Capability fest ist, was ein Modell-Urteil nicht ändert, aber enorm zählt für das, was in der Produktion ausgeliefert wird.

Die ganze Suite läuft in Minuten. Der Isolationstest kostet eine Stunde, meistens Warten auf einen Modell-Download. Das ist ein kleiner Preis für ein sauber, wohlcharakterisiertes Capability-Urteil, und ein viel kleinerer Preis als einen Worker auszuliefern, der auf Reasoning-Aufgaben still scheitert, sobald er live ist.

Dann lieferte Apple eine Beta, und das Framework durfte sich beweisen

Der ursprüngliche Plan verbuchte Core AI, Apples .aimodel-Format und den beabsichtigten Nachfolger von CoreMLs .mlpackage, unter "später testen". Später kam am selben Tag, an dem macOS 27 Golden Gate Beta 4 erschien, mit einem expliziten Changelog-Eintrag für Bug 176210080: ein Fix für ANE-Fehler bei bestimmten Gewichtskonfigurationen, genau die Fehlerklasse, die die 16-Pass-Benchmark seit Wochen dokumentiert hatte. Das Upgrade passierte sofort.

Der ANEF -14-Fehler, den die Bridge umging, verschwand nicht, denn der Fix zielte speziell auf .aimodel-Modelle, und die Bridge fährt .mlpackage, ein anderes Format auf einem völlig anderen Laufzeitpfad. "Core AI hat den ANE-Bug gefixt" stimmte sich als auch hier nicht zutreffend. Eine echte Verbesserung tauchte auf: .cpuAndGPU lädt und wärmt jetzt sauber für die kleinen Modelle, wo es zuvor einen Metal-OOM auf macOS 26 auslöste. GPU-Ausführung wurde für .mlpackage-Modelle verfügbar, die sie vorher nicht hatten, aber es ist immer noch keine ANE, und immer noch nicht das Format, das der Fix eigentlich anvisierte.

Core AI richtig zu testen bedeutete, es auf eigenen Bedingungen zu testen. apple/coreai-models, Apples eigene Export-Rezepte, Python-Primitives, Swift-Runtime und CLI-Tools, sauber gegen das Beta-4-SDK gebaut. Qwen3-0.6B ins .aimodel-Format zu exportieren, kostete einen Befehl:

uv run coreai.llm.export Qwen/Qwen3-0.6B --output-dir /tmp/qwen3-0.6b-int4

Das Benchmark-Ergebnis: 1.426 Tokens/Sek. Prompt-Verarbeitung, 159,5 Tokens/Sek. Generierung. Das ist die erste End-to-End-Core-AI-Inference auf diesem Rechner, und 159 tok/s für ein 0,6B-Modell ist schnell, etwa 19x schneller als der CPU/BNNS-Pfad, den die CoreML-Bridge fährt. powermetrics zeigte Landung auf GPU, nicht ANE: 6.261 mW Spitze, null ANE-Watt, und das Export-Verzeichnis wörtlich gpu-pipelined genannt. Die Entscheidung über die Rechenplatzierung fällt bei der Export-Zeit durch Apples eigene Pipeline, und für macOS heute wählt diese Pipeline GPU für LLM-Generierung. Der ANE-Fix in Beta 4 entfernte einen Blocker für ANE-gerichtete Modelle. Er änderte nicht, wo Apples eigener Scheduler entscheidet, ein LLM auf einem M2 laufen zu lassen.

Der härtere Test war LFM2.5-8B-A1B, das bereits über eine Community-Konvertierung im Core-AI-Format auf der Schijf lag. Apples eigenes llm-runner wies es direkt ab:

Error: Invalid output type for 'Expected 2 states (KV cache), got 3:
["keyCache", "valueCache", "convState"]'

Apples Toolkit geht von zwei KV-Zuständen aus. LFM2.5 hat drei: derselbe rollende Conv-Zustand, der schon bei der CoreML-Konvertierung zählte, ist noch da, und er ist immer noch nichts, das ein Standard-Transformer-Runner zu allokieren weiß. Kein Bug. Eine Lücke in dem, was Apples Katalog derzeit unterstützt. Ein Community-coreai-kit hat eine eigene LFM2-Engine, die die Drei-Zustands-Architektur durchaus handhabt, aber gegen Beta 4 zu bauen, bedeutete, drei separate API-Brechungen zu patchen: eine get-only Property, die früher mutable war, ein Typ, der noncopyable wurde und explizite Ownership-Semantik brauchte, und zuletzt einen Runtime-Crash beim Auflösen des Tensor-Layouts für die MoE-Routing-Tensoren:

CoreAIRuntime/NDArray+Layout.swift:126: Fatal error:
Cannot make a Tensor.Layout from an unresolved TensorRequirements

Das Letzte lebt in Apples eigenem CoreAIRuntime, nicht im Code des Community-Kits. Die API-Oberfläche der Beta bewegte sich schneller, als das Kit mithalten konnte. Zwei unabhängige Pfade, zwei unabhängige Urteile, beide am selben Ort: LFM2.5 ist in Beta 4 auf Core AI noch nicht lauffähig, ob die Mauer nun architektonisch ist (Apples Toolkit) oder ein bewegliches Beta-Ziel (das Community-Kit). MLX, mit erstparteiischen LiquidAI-Gewichten, einer reifen Generierungsschleife und ohne Drei-Zustands-Lücke, bleibt vorerst die richtige Laufzeit für LFM2.5.

Was Core AI wirklich ist, nachdem es benutzt statt nur gelesen wurde

Die Export-Pipeline läuft sauber. Die Benchmark-Tools sind solide. Generierungs-Durchsatz auf GPU schlägt den CoreML/BNNS-Pfad weit für Modelle, die das Toolkit bereits unterstützt. Qwen3, Gemma3, Mistral und Mixtral konvertieren und laufen ohne Zwischenfälle, und das Repository wird aktiv unter einer echten Open-Source-Lizenz gepflegt. Das ist der echte Pluspunkt, und kein kleiner.

Die Nuance ist, dass Core AI heute GPU-first für LLMs ist, nicht ANE-first, unabhängig davon, was der Beta-4-Changelog nahelegt, wenn man ihn überfliegt. Die Energieeffizienz-Geschichte, die ANE überhaupt erst zum interessanten Ziel machte, erscheint für generative Modelle noch nicht so wie für kleinere, nicht-generative, und ob sich das in einer zukünftigen Beta ändert, ist Apples Entscheidung, nicht etwas, das ein Gewichtsformat-Fix festlegt. Die Einschränkung, die hier wirklich zählt: Jede Architektur, die kein ganz normaler Zwei-Zustands-KV-Transformer ist, braucht explizite Engine-Unterstützung, bevor sie überhaupt läuft, und LFM2.5s hybrides Conv-Attention-Design mit seinem dritten Zustandstensor liegt außerhalb dieser Unterstützung. Die Community-Model-Zoo baut darauf hin. Sie jagt einer Beta hinterher, die sich weiterbewegt.

Wo das die Dinge lässt, und was als Nächstes kommt

Die Bridge funktioniert. Sie bedient drei Modelle aus einem Prozess über eine saubere OpenAI-kompatible API, die Fehlerbehandlung ist explizit statt mysteriös, und die Qualität, die sie liefert, ist genau das, was die rohen Gewichten können, nicht mehr und nicht weniger. Für Modelle im 350M-Maßstab speziell: vertrauenswürdig für Extraktion und Klassifikation, noch nicht vertrauenswürdig für Reasoning oder mehrstufige Synthese, und die Routing-Logik muss diese Decke widerspiegeln statt darum zu hoffen. Für Core AI: echt, schnell und heute bereit für Standard-Transformer-Architekturen, mit einem klaren Migrationspfad, sobald es gebraucht wird, aber noch keine Option für LFM2.5-Family-Worker, bis entweder Apple Engine-Unterstützung hinzufügt oder das Community-Kit sich gegen eine stehengebliebene Beta stabilisiert.

Der Teil, den es wert ist zu behalten, unabhängig davon, welches Modell gewinnt, ist, dass das Testprotokoll nicht interessiert, was es bewertet. Gewichts-Herkunft, Laufzeit-Isolation, die Pass/Fail-Suite, Bridge-Vergleich, Prompt-Sensitivitäts-Ablation: dieselben fünf Schritte, in derselben Reihenfolge, liefern ein sauberes Urteil, ob das Subjekt ein 350M-CoreML-Worker ist oder was auch immer Core AIs LFM2.5-Unterstützung in sechs Monaten ausliefert (einschließlich des Rests der lokalen Modellflotte, die ich jetzt dagegen fahre - Planner-, Coder- und Reviewer-Kandidaten, eine Geschichte für einen anderen Post). Das ist die Eigenschaft, die es wert ist, in Infrastruktur-Tests allgemein angestrebt zu werden: nicht ein Framework, das auf eine bestimmte Antwort hofft, sondern eines, das dir sagt, was wahr ist, und weitermacht.