1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Core AI ist ein neues Framework zum Ausführen, Optimieren und Bereitstellen von AI-Modellen innerhalb von Apps auf Apple silicon
  • Es nutzt CPU, GPU und die Neural Engine; mit Swift-APIs lässt sich .aimodel-Inference in Apps integrieren
  • Eine Toolchain bietet die Umwandlung von PyTorch-Modellen in Core AI-Modelle sowie Komprimierung, Debugging und Precompilation
  • Große Modelle benötigen vor der Ausführung specialization; daher sind Download, Cache und der Ablauf beim ersten Start wichtig
  • Mit Beispielen zu SAM 3, Qwen und Transformer werden Optimierungsabläufe für On-Device-Visual-, Sprach- und State-Caching vorgestellt

Die Rolle von Core AI

  • Core AI ist ein neues Technologiepaket für die On-Device-AI-Ausführung auf allen Apple-Plattformen
    • Unterstützt iOS 27.0+ Beta, iPadOS 27.0+ Beta, macOS 27.0+ Beta, tvOS 27.0+ Beta, visionOS 27.0+ Beta und watchOS 27.0+ Beta
    • Ermöglicht hochperformante AI-Inference direkt in der App, ohne Nutzerdaten an Geräte außerhalb zu senden
  • Core AI ist nicht nur eine reine Ausführungs-API, sondern umfasst den gesamten Weg von der Modellvorbereitung bis zur App-Integration
    • Bietet Modelloptimierung, PyTorch-Konvertierung, .aimodel-Erstellung, Debugging, Xcode-Profiling und Precompilation
    • Für decision tree- oder tabular feature engineering-Modelle statt neuronaler Netze ist weiterhin Core ML vorgesehen

Entwicklungsablauf: von PyTorch bis zur Swift-App

  • Core AI verbindet bestehende PyTorch-Workflows mit dem Bereitstellungsablauf für Apple silicon
    • Mit torch.export wird ein PyTorch-Modell in ein exported program umgewandelt
    • Mit TorchConverter aus den Core AI PyTorch Extensions wird ein .aimodel erzeugt
    • Mit Core AI Optimization werden Komprimierung und Optimierung für Apple silicon angewendet
  • In Swift-Apps werden Modelle über die neue Core AI Framework-API geladen und Inference ausgeführt
    • AIModel lädt .aimodel-Dateien und prüft Inference-Funktionen
    • InferenceFunction ist ein einzelner ausführbarer Berechnungsgraph
    • NDArray ist der Typ für mehrdimensionale Ein- und Ausgabedaten
    • Über run werden NDArray-Eingaben übergeben und Inference-Ergebnisse zurückgegeben
  • In Xcode lassen sich .aimodel-Dateien direkt prüfen
    • Modellgröße, Verteilung der Operationen, Metadaten und Funktionssignaturen sind einsehbar
    • Dynamische shape-Dimensionen werden mit ? angezeigt

Performance-Optimierung: state, cache, memory layout

  • Bei Transformer-Modellen mit länger werdenden Eingabesequenzen kann die Inference-Zeit stetig ansteigen
    • Im Snake-Beispiel wurde das Spiel mit der Zeit langsamer, als beide Snakes als AI-Modelle ausgeführt wurden
    • In Core AI Instruments war zu sehen, dass die Inference-Abschnitte immer länger wurden
  • Core AI kann mit state Strukturen wie key/value cache implementieren
    • Der Zustand ist ein Modelleingang, wird während der Inference gelesen und in place aktualisiert
    • Frühere key/value-Werte werden im Cache gespeichert statt erneut berechnet
    • So muss nicht bei jedem Schritt die gesamte Spielhistorie erneut als Eingabe übergeben werden
  • Auf Swift-Seite wird über das states-Argument von InferenceFunction.run eine Sammlung mutabler Views übergeben
    • Das aktualisierte Modell hält auch über längere Zeit eine konstante Geschwindigkeit
    • Auch in Instruments steigt die Inference-Latenz deutlich langsamer an
  • Core AI bietet zudem Speichersteuerungsfunktionen zur Reduzierung des Overheads in Inference-Schleifen
    • Das optimale memory layout von NDArray kann geprüft und entsprechend allokiert werden
    • Ausgabewerte lassen sich vorab allokieren, um neue Output-Allokationen während der Inference zu vermeiden
    • Mit asynchronen Werten lassen sich mehrere Inference-Funktionen pipelinen

Modellbereitstellung: Download, specialization, Precompilation

  • Core AI-Modelle sind eine Quellrepräsentation, die auf allen Apple-Geräten laufen kann, benötigen vor der tatsächlichen Ausführung aber gerätespezifische specialization
    • Beim Laden eines Modells wird geprüft, ob bereits ein specialization-Ergebnis im Cache vorhanden ist
    • Falls nicht, wird ein Ausführungsartefakt passend zu Gerät und OS-Version erzeugt
  • Bei großen Modellen kann specialization Zeit kosten, daher sollte sie nicht mitten in einer Nutzerinteraktion stattfinden
    • Im SAM 3-Beispiel wurde beim ersten Start durch model load und ein großes specialization-Ereignis lange ein Spinner angezeigt
    • Vorgeschlagen wird ein Ablauf, bei dem das Modell per Background Assets erst dann heruntergeladen wird, wenn Nutzer es auf einem Einführungsbildschirm ausprobieren möchten
  • Mit dem Befehl coreai-build kann ein Teil der Kompilierung vorab auf der Entwicklungsmaschine ausgeführt werden
    • Damit lässt sich ein compiled model für eine bestimmte Gerätearchitektur erzeugen
    • Auch dann bleibt auf dem Nutzergerät specialization nötig, aber der verbleibende Aufwand ist geringer und die Vorbereitungszeit kürzer
  • Mit AIModelCache lässt sich der Modell-Cache programmatisch steuern
    • Nicht benötigte Einträge löschen
    • Aufbewahrungsrichtlinien für Einträge steuern
    • Cache zwischen mehreren Apps derselben app group teilen

Modelloptimierung und Debugging

  • Core AI Optimization bietet Modellkomprimierung und Quantisierungsfunktionen
    • Unterstützt Gewichtskomprimierung mit INT4, INT8, FP4 und FP8
    • Bietet Quantisierungs-APIs mit calibration-Daten oder quantization aware training
  • Im SAM 3-Beispiel war das 32-Bit-Basis-Asset größer als 3 GB und nach 4-Bit-Komprimierung etwa 430 MB groß
    • Bei aggressiver Komprimierung aller Schichten wurde eine verdeckte Blume nicht erkannt
    • Anhand der Ausgabe allein war schwer festzustellen, welche Schicht das Problem verursachte
  • Der Core AI Debugger vergleicht interne Werte des konvertierten Modells mit dem ursprünglichen PyTorch-Modell
    • Visualisiert die Modellstruktur als Graph
    • Zeigt Zwischen-Tensorwerte an
    • Verfolgt bis zu einer bestimmten Zeile im Python-Quellcode zurück
    • Markiert Operationen mit großen Abweichungen auf Basis von PSNR
  • Beim SAM 3-Vergleich traten die meisten sync points mit niedrigem PSNR im detector decoder auf
    • Der detector block macht nur 4 % der gesamten Parameter aus, daher ist der Komprimierungsgewinn gering
    • Wurde der detector von der Quantisierung ausgenommen, wurden wieder alle Blumen erkannt und die Basisqualität war wiederhergestellt

Core AI Models und High-Level-APIs

  • Das Repository Core AI Models bietet populäre Modelle und Export-Recipes, die für Apps konvertiert und optimiert werden können
    • Dort lassen sich Modelle der SAM 3- und Qwen-Familie finden und in Core AI-Modelle umwandeln
    • Swift-Pakete abstrahieren modellabhängige Vor- und Nachverarbeitung
  • Segmentierungsmodelle wie SAM 3 lassen sich mit CoreAIImageSegmenter verwenden
    • Objekte können per Text-Prompt segmentiert werden
    • Masken lassen sich über Swift-APIs extrahieren, ohne raw tensor shapes direkt behandeln zu müssen
  • Sprachmodelle wie Qwen lassen sich mit CoreAILanguageModel laden
    • asset loading, engine creation und tokenizer setup werden abstrahiert
    • Kann mit LanguageModelSession aus FoundationModels verbunden werden
    • Streaming-Antworten und strukturierte Ausgaben auf Basis von @Generable sind möglich

Punkte, auf die Entwickler achten sollten

  • Core AI ist mehr als eine „API zum Ausführen von Modellen in Apps“; es ist ein umfassendes On-Device-AI-Bereitstellungssystem
    • Ein Ablauf, um PyTorch-Modelle in .aimodel für Apple silicon umzuwandeln
    • APIs, um Modelle in Swift-Apps sicher und effizient auszuführen
    • Diagnose von Performance und Genauigkeit über Xcode, Instruments und Debugger
  • Beim App-Design hat oft eher der Vorbereitungsprozess als das Modell selbst großen Einfluss auf die User Experience
    • Es muss entschieden werden, ob ein Modell mit der App gebündelt oder per Background Assets geladen wird
    • Es braucht ein Design dafür, wie Download und specialization beim ersten Start gezeigt werden
    • Cache-Richtlinien und Precompilation-Strategien sind direkt mit der Nutzbarkeit großer Modelle verbunden
  • Core AI zeigt einen Entwicklungsablauf, um Vision-Modelle, Sprachmodelle und Transformer-basierte Modelle auf Apple-Plattformen On-Device zu nutzen
    • Am Beispiel SAM 3 wird der Ablauf für Komprimierung, Trennung und Debugging eines Segmentierungsmodells gezeigt
    • Am Beispiel Qwen wird die Verbindung zwischen einem benutzerdefinierten Sprachmodell und der Foundation Models-API gezeigt
    • Am Beispiel Snake Transformer wird die Optimierung eines key/value cache auf Basis von state gezeigt

Referenzlinks

1 Kommentare

 
GN⁺ 5 시간 전
Hacker-News-Kommentare
  • Ich bin noch gespannter auf das kommende Update für On-Device Foundation Models: https://developer.apple.com/documentation/updates/foundation...
    Bisher gibt es noch nicht viele Informationen dazu.
    Allerdings pflege ich https://github.com/Arthur-Ficial/apfel, daher könnte ich voreingenommen sein.

    • Ich frage mich, ob du das neue Tool fm gesehen hast. Es wurde in der Platforms State of the Union erwähnt.
      Wenn man es ausführt, kommt so etwas heraus: https://gist.github.com/robgough/7893602895e7580117475076198...
    • Stimme zu. Die Idee, On-Device-Modelle als zentralen Bestandteil der OS-API systemweit und plattformübergreifend verfügbar zu machen, ist sehr attraktiv.
      Normalerweise bevorzuge ich eher fragmentierte Software, aber bei Apple gibt es viele integrierte Funktionen, die ich wirklich mag.
      Besonders reizvoll finde ich, dass Software wissen kann: „Auf dieser Plattform gibt es dieses Modell“, und es dann für viele kleine und zunehmend größere generative KI-Aufgaben nutzen kann.
    • Apfel wirkt nützlich. Ich habe fast ein Jahr lang mit Apple Foundation Models experimentiert, und für eingebettete Anwendungen scheint es brauchbar zu sein.
      Ich grabe mich auch tiefer in lokale agentische Coding-Tools ein und habe mit little-coder --model ollama/gemma4:12b-it-qat angefangen.
      Ich habe auch ein kleines kostenloses Buch erstellt, das ein paar Minuten Einrichtungszeit sparen kann: https://leanpub.com/read/local-coding-agents
      Ich bin ziemlich verärgert über den Hype rund um hyperscaler-zentriertes KI-Wachstum, besonders wegen der ökologischen und gesellschaftlichen Kosten von Rechenzentren, daher unterstütze ich jeden Versuch, lokale, private KI voranzubringen.
    • Ich bin überrascht, dass Apple die Idee offenbar nicht aufgegriffen hat, Core AI mit einem OpenAPI-kompatiblen Endpoint auszustatten, wenn auch nur als Testwerkzeug.
      Jetzt, da MCP-Unterstützung angeboten wird, würde ich auch gern mehr über die Containerisierung-/Seatbelt-Strategie hören.
      Ich habe bisher noch nichts dazu gesehen, wie Darwin innerhalb von Apples Containersystem verwendet wird.
      Apfel ist ein großartiges Projekt und der einzige Grund, warum ich auf Tahoe upgraden wollte.
  • WWDC 2026 Core AI-Videos
    Meet Core AI - https://developer.apple.com/videos/play/wwdc2026/324/
    Dive into Core AI model authoring and optimization - https://developer.apple.com/videos/play/wwdc2026/325/
    Integrate on-device AI models into your app using Core AI - https://developer.apple.com/videos/play/wwdc2026/326/

  • Das sieht nach einem neuen Weg aus, PyTorch-Modelle in ein Format umzuwandeln, das auf CPU, GPU und der Apple Neural Engine (ANE) läuft [0].
    Ich frage mich, ob das die bestehende API Core ML vollständig ersetzen soll [1].
    [0]: https://apple.github.io/coreai-optimization/
    [1]: https://developer.apple.com/documentation/coreml/

    • Ja. Laut der Core-AI-Dokumentation soll man sich Core ML ansehen, wenn eine App andere Modelltypen als neuronale Netze verwendet, etwa Entscheidungsbäume oder tabellarisches Feature Engineering.
    • Ziemlich interessant, aber ich frage mich, wie die Performance im Vergleich zu bestehenden Ansätzen ausfällt, bei denen man zum Beispiel ein für Metal optimiertes Modell in so etwas wie llama.cpp lädt und nutzt.
      unsloth ist ein gutes Beispiel für so etwas als „batteries included“-Lösung.
    • Es scheint Core ML ersetzen zu wollen, aber im Moment ist das Verhältnis zwischen Core AI, Core ML, MLX und coremltools noch verwirrender.
      Apple sollte besser erklären, wo jeweils die Vor- und Nachteile liegen und wie weit die funktionale Gleichwertigkeit reicht.
    • Da OS 27 oder neuer erforderlich ist, bleibt Core ML wegen der Abwärtskompatibilität weiterhin nützlich.
  • Für Apps mit weniger als 2 Millionen Downloads soll der Zugang zu serverseitigen Modellen kostenlos sein und dieselben Datenschutzgarantien bieten.
    Hoffentlich wird das mit der Zeit auf alle Apps ausgeweitet. Es wird zwar Hardware- und Kostenbeschränkungen geben, aber größere Entwickler könnten die Kosten wahrscheinlich tragen.
    https://developer.apple.com/private-cloud-compute/

    • Aus der Erwähnung von Apple Intelligence Extensions lässt sich schließen, dass Apple das vorerst wohl nicht stark ausweiten wird, sondern Entwicklern stattdessen die Integration mit anderen Anbietern ermöglichen will, bei denen Nutzer bereits ein Konto haben.
  • Die Zukunft der AI ist eindeutig lokal, und in letzter Zeit wird das als „unendliche Tokens“ beschrieben
    Ein M1 MacBook Pro kann das ebenfalls, und eine RTX 3090 auch
    Man muss nicht jeden Monat Hunderte Dollar zahlen, und für andere gilt dasselbe

    • In den 1980er Jahren galt die Zukunft des Computings ebenfalls eindeutig als lokal. Das waren Heimcomputer, PCs, Macs, Büroserver (Novell, später Windows NT mit Filesharing)
      40 Jahre später sind wir wieder bei einer zentralisierten Infrastruktur angekommen, die modernen Smart-Terminals nahekommt
      Mit der Zukunft der AI wird es am Ende wohl ähnlich laufen. Wahrscheinlich wird sie zwischen lokal und zentralisiert hin- und herpendeln
      Wenn man allerdings Geld damit verdienen kann, Dinge zu verkaufen, die lokal laufen, scheint Zentralisierung doch mehr Macht und mehr Geld hervorzubringen
    • Bei „unendlichen Tokens“, begrenzt auf 10 Tokens pro Sekunde, sind das 26 Millionen Tokens pro Monat
    • Das eigentliche Geld steckt darin, den Code rund um das Modell zu schreiben und es für spezialisierte Aufgaben effizient zu machen
      Normale Nutzer wollen Allzweckmodelle, daher werden AI-Chat-Apps bleiben
      Die meisten Programme können jedoch von spezialisierter AI profitieren, die lokal läuft, und es gibt viel mehr Programme als Nutzer
  • Apple arbeitet offenbar auch an der Aktivierungsseite. Soweit ich weiß, geht es um w4a8, w4a16
    Wenn sie das richtig hinbekommen, und das ist eine große Annahme, könnten sie angesichts von Apples Marktreichweite erheblich mitbestimmen, wie Modelle mit weniger als 100 Milliarden Parametern trainiert und bereitgestellt werden
    Der wichtigste Einsatzbereich wird On-Device sein, und wahrscheinlich meist eher auf macOS als auf iOS

  • Ich habe noch nirgends gesehen, dass das stark hervorgehoben wurde, aber verteilte Inferenz zwischen Macs ist interessant. Dazu gehören JACCL über Thunderbolt 5, ein OpenAI-kompatibler mlx_lm.server und agentische Ausführung auf dem Mac
    Apple hält MLX (direkter Gewichtsimport) von Foundation Models / Core AI getrennt

  • Deshalb drängen AI-Unternehmen so stark an die Börse
    Ende nächsten Jahres werden wir den Großteil der AI direkt auf Geräten ausführen
    Sie haben keinen Burggraben, sie stoßen an Skalierungsgrenzen, und das meiste, was magisch wirkt, kann in kleinere Modelle destilliert werden, und sie wissen das auch

    • Qwens Modelle in der 30-Milliarden-Klasse sind praktisch völlig ausreichend, solange man eine Maschine mit genug Speicherbandbreite hat, um sie mit 30 bis 90 Tokens pro Sekunde laufen zu lassen
      Dass Qwen aufgehört hat, Modelle in der 120-Milliarden-Klasse zu veröffentlichen, ist sehr bezeichnend
      Irgendjemand wird in den nächsten 10 Jahren, vielleicht schon in 3 Jahren, ein lokal ausführbares 256-Milliarden-Modell auf Opus-4.5-Niveau herausbringen
      Unsere Engineers geben derzeit etwa 800 Dollar im Monat für Opus-Tokens aus, und bei dieser Rate liegt die Amortisationszeit für ein lokales LLM bei etwa 10 Monaten
    • Ich weiß nicht, ob wir wirklich an Skalierungsgrenzen angekommen sind
      Leider scheinen größere Modelle immer noch bessere Modelle zu sein
    • Im Coding-Bereich wird es wohl darauf hinauslaufen, 35B-, 70B- und 150B-Modelle für einige Hundert bis einige Tausend Dollar im Voraus zu verkaufen und ein Jahr lang monatliche oder zweimonatliche Updates bereitzustellen, die mit neuer Coding-Dokumentation und neuen Repositories trainiert wurden
    • Hurra, ihre Würgegriff-Herrschaft ist beendet. Es lebe die Revolution!
    • Ich will nur ein einziges sehr kleines Modell, das auf dem Gerät läuft. Zum Beispiel eines, das bei der Autovervollständigung weiß, dass ich „I'll be right back“ und nicht „I'll be right Brian“ schreiben will
      Das ist derzeit meine oberste AI-Anforderung. Bitte, Apple
  • Ich frage mich, ob es so etwas auch für Linux gibt
    Könnte man als Anwendungsentwickler zum Beispiel annehmen, dass es ab einer bestimmten Kernel-Version so etwas wie GNU Core AI gibt?

    • Auf Plattformen, die nicht von Apple sind, muss man sich normalerweise um die Zahl der zu unterstützenden Siliziumanbieter kümmern plus mindestens zwei weitere AI-Frameworks
      Apple scheint inzwischen mit Core ML, MLX und Core AI ebenfalls an diesem Punkt angekommen zu sein
      Ich sehe keine Anzeichen dafür, dass das Problem der Framework-Fragmentierung bald verschwindet
      NVIDIA will, dass alle für Training und Inferenz CUDA verwenden, und versucht zu leugnen, dass NPUs nützlich sind
      Jeder Hersteller, der NPUs baut, hat sein eigenes Architekturmodell und ein separates Framework, das auf die Beschränkungen der Hardware zugeschnitten ist, die noch vor LLMs entworfen wurde. Die meisten haben zusätzlich noch ein weiteres Framework, das auf GPUs abzielt
      Auch Betriebssystemanbieter haben meist ein oder zwei Frameworks, die sie lieber verwendet sehen würden als hardwarespezifische Frameworks
    • Praktisch gesehen übernimmt llama.cpp diese Rolle. Man kann es einbinden oder die Netzwerk-API verwenden
    • Nein. Red Hat und IBM machen so etwas aber für ihre eigenen Distributionen
    • Es gibt onnxruntime, llama.cpp und genauer gesagt ggml, und iree.dev versucht es ebenfalls
  • Ich frage mich, ob das bedeutet, dass man auf dem ANE alles ausführen kann, was man will
    Als ich es zuletzt ausprobiert habe, schien es nur für Apple-First-Party-Funktionen wie Face ID nutzbar zu sein

    • Wenn man Modelle in Core ML umwandelt, konnte man das schon
      Was das ANE überhaupt nicht nutzen konnte, war MLX
    • Mit Core ML macht man das schon seit Jahren