Wie ein Smartphone-Chip KI tatsächlich ausführt: Der A20 Pro verständlich erklärt

Kurzfassung: Ein Modell mit 3 Milliarden Parametern benötigt bei 4-Bit-Präzision 1,5 GB allein für die Rohgewichte, bei 16 Bit sind es 6 GB. Der Speicherbedarf von App und Gesprächscache kommt noch hinzu. CPU, GPU und Neural Engine teilen sich die Arbeit je nach Modell und Laufzeitumgebung.^[2] Die zusätzliche Bandbreite und Kühlung des A20 Pro setzen an unterschiedlichen Engpässen an: Daten schnell genug zu bewegen und die Arbeit ohne Überhitzung aufrechtzuerhalten.^[1]

Den A20 Pro versteht man am besten als kleine, gemeinsam genutzte Werkstatt. Die CPU plant die Arbeit. Die GPU übernimmt parallele Mathematik. Die Neural Engine führt Modelloperationen aus, die Core ML für spezialisierte Hardware kompiliert hat. Keine davon ist ein universeller „KI-Knopf“: Der Ausführungspfad der Laufzeitumgebung verändert sich mit Format, iOS-Version, unterstützten Operatoren, Speicherauslastung und Entwicklerkonfiguration.^[2] Apple hat Prozessorblöcke und relative Leistungsangaben veröffentlicht, aber weder den RAM des Duo noch GB/s, Taktraten, Leistungsaufnahme oder eine Testumgebung mit festgelegtem Modell und Prompt. Diese Lücken verhindern eine Geschwindigkeitsrangliste.^[1]

Die Fakten zur Vorstellung finden Sie in unserem Beitrag zur lokalen KI von iPhone Duo und AirPods 5 und im A20-Pro-Vergleich. Den Modellmarkt ordnet unsere Analyse von Liquid AIs LFM2.5 (Englisch) ein.

Rechenleistung: Drei Prozessoren, unterschiedliche Aufgaben

Die CPU ist der Koordinator. Sie übernimmt App-Code, die Vorbereitung von Audio und Dateien, Ablaufplanung, Tokenisierung, Aktualisierungen der Oberfläche und die kleinen Entscheidungen rund um die Inferenz. Bei verzweigter Logik ist sie flexibel und kann kleine Modelle direkt ausführen. GPUs und dedizierte neuronale Prozessoren können bei unterstützten parallelen Operationen Durchsatz oder Energieverbrauch verbessern. Welcher Pfad der beste ist, hängt von der Arbeitslast ab.

Die GPU ist die breite Werkbank. Sie führt dieselben Berechnungen gleichzeitig auf vielen Teilen eines Tensors aus. Das eignet sich für dichte Matrixmultiplikation, Attention, Bildverarbeitung und bestimmte Modellformate. Eine lokale Laufzeitumgebung wie llama.cpp unterstützt Apples Metal-Stack neben ARM NEON und Accelerate.^[6] Ihr SwiftUI-Beispiel für das iPhone zeigt, dass lokale Inferenz in eine App eingebettet werden kann, statt die Anfrage an einen Webdienst weiterzuleiten.^[7]

Die Neural Engine ist die spezialisierte Fertigungslinie. Core ML kann CPU, GPU, Neural Engine oder Kombinationen daraus auswählen, abhängig davon, was das kompilierte Modell ausführen kann. Nicht unterstützte Operatoren können anderswo laufen. Deshalb ist die vollständige Übertragung eines Rechengraphen auf die Neural Engine eine Leistung, die für jedes Modell einzeln erbracht werden muss. Desert Ant gibt an, dass sein Voz-Transkriptionsgraph dies auf den getesteten iPhones erreicht. Das belegt etwas über die Konvertierung und Laufzeitumgebung von Voz, nicht über jede iOS-App.^[8]

Speicher: Kapazität ist nicht Bandbreite

Die Kapazität beantwortet die Frage: „Passt die Aufgabe hinein?“ Die Bandbreite beantwortet: „Wie schnell kann der Chip immer wieder abrufen, was er benötigt?“ Beides zählt, weil ein Sprachmodell für jedes erzeugte Token einen großen Teil seiner Gewichtsdaten lesen muss. Ein schneller Beschleuniger, der auf Speicher wartet, fühlt sich für jemanden, der auf eine Antwort schaut, nicht schnell an.

Die reine Gewichtsberechnung ist bewusst einfach. Ein Modell mit 3 Milliarden Parametern und 4 Bit pro Gewicht benötigt 3.000.000.000 × 4 ÷ 8 = 1.500.000.000 Byte, also 1,5 dezimale GB, für die Rohgewichte. Bei 16 Bit ergibt dieselbe Rechnung 6 GB. Beide Werte schließen Metadaten, Quantisierungsskalen, Tokenizer, ausführbaren Code, temporäre Rechenpuffer, Betriebssystem, Host-App und Gesprächscache aus. Die Rechnung zeigt, warum die Bitzahl wichtig ist. Sie belegt nicht, dass ein Modell mit 3 Milliarden Parametern auf dem iPhone Duo Platz findet oder gut läuft. Dessen RAM-Kapazität wurde nicht veröffentlicht.^[1]

Apples Angabe „50% mehr Bandbreite des gemeinsamen Speichers“ ist deshalb relevant, aber unvollständig. Sie sagt, dass eine Pipeline mit gemeinsamem Speicher Modelldaten in Apples Vergleich möglicherweise schneller als die vorige Generation bewegt. Sie sagt weder, wie viel Kapazität das Duo hat, noch, wie ein bestimmtes LLM abschneidet.^[1] Ein Modell kann in den Speicher passen und sich trotzdem langsam anfühlen, wenn wiederholtes Lesen der Gewichte die Bandbreite auslastet. Umgekehrt kann ein kleineres Modell mit kürzerem Kontext unmittelbar reagieren, während ein größeres Modell keinen zweiten Puffer mehr anlegen kann.

Quantisierung und Kontext: Ein veränderliches Speicherbudget

Quantisierung speichert eine Zahl mit weniger Bit. Wird die Präzision der Gewichte von 16 auf vier Bit reduziert, sinkt der rechnerische Rohgewichtsbedarf um 75%. Eine kleinere Datei ist jedoch kein verlustfreies Modell. Die Laufzeitumgebung muss sie effizient dekodieren, und das Modell muss genügend Aufgabenqualität bewahren. Apples Forschung von 2024 verwendete eine gemischte 2-Bit-/4-Bit-Strategie, weil Operationen Kompression unterschiedlich gut vertragen.^[4]

Bei Transformer-Schichten mit vollständiger Attention ist der KV-Cache ein zweiter, wachsender Speicherbereich. Nachdem das Modell ein Prompt-Token gelesen hat, speichert es Attention-„Keys“ und „Values“. Das nächste Token kann so auf Vorheriges zurückgreifen, ohne das gesamte Gespräch neu zu berechnen. Deshalb kann ein langes Gespräch langsamer werden oder scheitern, obwohl sich die Gewichtsdatei nicht verändert hat. Der Cache wächst mit der Kontextlänge und hängt von Architektur, Schichten, verborgenen Dimensionen, Aufbau der Attention-Köpfe, Präzision und Laufzeitkonfiguration ab. Er lässt sich nicht allein aus der Parameterzahl ableiten. Sliding-Window-Attention begrenzt das Cache-Wachstum in den betroffenen Schichten. Hybride Modelle aus Faltung und Attention führen nicht in jeder Schicht einen vollständigen Attention-Cache.^[10][11]

Betrachten wir ein hypothetisches Modell mit vollständiger Attention, 32 Schichten, acht KV-Köpfen pro Schicht, einer Kopfdimension von 128 und zwischengespeicherten 16-Bit-Werten. Keys und Values zusammen benötigen 2 × 32 × 8 × 128 × 2 = 131.072 Byte pro Token: 128 KiB. Bei 4.096 Token sind das 512 MiB, bei 32.768 Token 4 GiB. Diese Rechnung schließt zusätzlichen Verwaltungsaufwand aus und beschreibt eine beispielhafte Architektur, nicht den A20 Pro, Apples Modell oder Liquids Modell mit 230 Millionen Parametern.

Einige Optimierungen setzen direkt an diesem Budget an. Apples Forschung von 2024 beschreibt effiziente KV-Cache-Aktualisierungen auf seinen Neural Engines. Der technische Bericht von 2025 ergänzt die gemeinsame Nutzung des KV-Caches als Architekturoptimierung.^[5] llama.cpp unterstützt quantisierte K/V-Cache-Optionen in seinen Backends. Die Funktionsmatrix behandelt diese Fähigkeiten jedoch als backendabhängig, nicht als Versprechen, dass jedes Format überall gleich schnell ist.^[4][9] Die praktische Regel ist einfach: Den kleinsten Kontext ausliefern, der die Funktion erfüllt, und anschließend den tatsächlichen Speicherbedarf auf einem physischen Gerät messen.

Prefill und Decode: Zwei unterschiedliche Wartezeiten

Eine LLM-Sitzung hat zwei Aufgaben. Prefill liest den übergebenen Prompt und baut den KV-Cache auf. Bei einem langen Prompt trägt diese Phase meist den größten Teil zur Zeit bis zum ersten Token bei. Decode erzeugt jeweils ein neues Token und greift dabei wiederholt auf den gespeicherten Cache und die Gewichte zurück. Seine Rate ist die Zahl, die üblicherweise als Token pro Sekunde bezeichnet wird. Diese Messgrößen sind nicht austauschbar.

Das verändert das Produktdesign. Eine lokale Funktion zum Zusammenfassen von Notizen kann ein begrenztes Dokument einmal einlesen, eine kurze Antwort generieren und das Modell anschließend freigeben. Ein Chat-Assistent mit ausuferndem Prompt und langem Verlauf trägt höhere Prefill-Kosten, bevor er überhaupt etwas sagt. Ein stabiler Präfix ermöglicht Cache-Wiederverwendung nur dann, wenn sich dieser Präfix wiederholt. Neuer Kontext muss weiterhin gelesen werden.^[10]

Das erstmalige Laden ist eine dritte Wartezeit. Bevor Prefill beginnt, muss ein Smartphone möglicherweise das Modell aus dem Gerätespeicher lesen und für ein Hardware-Backend vorbereiten. Desert Ant berichtet von 20 Sekunden für die erste Core-ML-Spezialisierung von Voz und 0,2 Sekunden für spätere Ladevorgänge.^[8] Deshalb sollte ein Produkt Kaltstart, Zeit bis zum ersten Token und Generierungsrate getrennt ausweisen. Eine schnelle Antwort nach dem Aufwärmen verrät dem Nutzer nicht, wie sich der erste Start anfühlt.

Kühlung und Cloud: Die Grenzen eines Smartphones

Ein Smartphone kann Spitzenrechenleistung nicht unbegrenzt aufrechterhalten. Es hat ein dünnes Gehäuse, einen Akku, ein Betriebssystem, das die Reaktionsfähigkeit schützt, und einen Nutzer, dem ein heißes Gerät auffällt. Apples Ankündigung des iPhone 18 Pro beschreibt ein A20-Pro-Package mit Speicher neben dem Silizium, wodurch der direkte Weg vom Chip zur Dampfkammer frei bleibt.^[12] Auch das Duo verwendet den A20 Pro mit einer speziell angepassten Dampfkammer. Das ist ein glaubwürdiger Hinweis auf ein Design für anhaltende Arbeitslasten, aber weiterhin kein gemessenes KI-Ergebnis des A20 Pro.^[1]

Sinnvolle lokale Aufgaben sind klar begrenzt und häufig: Transkription nach einer Aufnahme, Offline-Textklassifikation, Bildverständnis für ein ausgewähltes Foto, private Suche in einer kleinen Dokumentensammlung oder eingeschränkte Extraktion in ein bekanntes Schema. Liquids LFM2.5 mit 230 Millionen Parametern zielt ausdrücklich auf Datenextraktion und leichtgewichtiges Tool-Routing ab. Von Mathematik mit hohem Reasoning-Bedarf, Codegenerierung und kreativem Schreiben rät der Anbieter ab. Diese Arbeitsteilung beschreibt die Zukunft mobiler KI ehrlicher als die Behauptung, jede Anfrage gehöre auf ein Smartphone.^[11]

Bei schwierigerer Arbeit ist ein hybrider Ansatz eine Funktion, kein Scheitern. Apple beschreibt lokale Verarbeitung für viele Anfragen und Private Cloud Compute für größere Aufgaben. Eine gut gestaltete App sollte dieselbe Wahl treffen: private, latenzarme und begrenzte Arbeit lokal erledigen; für breites Wissen, schwieriges Reasoning oder Aufgaben jenseits des Speicher- und Wärmebudgets des Geräts um Erlaubnis bitten und ein entferntes Modell verwenden.^[3]

Kehren wir zur Werkstatt im Smartphone zurück. Die CPU koordiniert den Auftrag. GPU und Neural Engine führen die von ihnen unterstützten Operationen aus. Der Speicher hält das Material griffbereit, und die Kühlung bestimmt, wie lange die Arbeit weitergehen kann. Eine Verbesserung an einer Stelle hilft nur, wenn nicht bereits ein anderer Teil die Grenze setzt. Deshalb können ein kleineres Modell, ein kürzerer Kontext oder eine bessere Laufzeitumgebung für eine App manchmal wichtiger sein als eine weitere Chipgeneration.

Eine private Notizzusammenfassung ist ein nützliches Anwendungsbeispiel für dieses Denkmodell. Zunächst müssen Gewichte und Arbeitsspeicherbedarf in das Gerätebudget passen. Danach werden Kaltladen, Prompt-Verarbeitung und Antwortgenerierung getrennt gemessen. Schließlich wird die Aufgabe auf einem warmen Smartphone wiederholt und entschieden, welche Anfragen einen Server benötigen. Jeder Schritt verbindet einen Teil des Chips mit etwas, das der Nutzer spürt: ob die App zügig öffnet, flüssig reagiert und fertig wird, ohne den Akku übermäßig zu belasten.

Die Änderungen an Bandbreite und Wärmeabfuhr des A20 Pro erweitern den technischen Spielraum für diese Entscheidungen. Sie wählen weder die Arbeitslast noch gestalten sie das Nutzungserlebnis. Ist dieser Unterschied klar, lässt sich lokale KI leichter beurteilen: den Daten folgen, die begrenzende Ressource erkennen und die abgeschlossene Aufgabe messen. Der Wert des Chips liegt in der nützlichen Arbeit, die das Smartphone mit ihm erledigen kann. Der Wert der App liegt darin, zu wissen, welche Arbeit dorthin gehört.

Quellen und Referenzen

1. 1
   Apple stellt das iPhone Duo vor

   Apple Newsroom; Apple2026-09-09

   Apples Primärangaben zum A20 Pro und Package: Konfiguration von CPU, GPU und Neural Engine, relative Angaben zu KI und Speicherbandbreite sowie Anbindung an die Dampfkammer.
2. 2
   Core-ML-Dokumentation

   Apple Developer Documentation; AppleAbgerufen am 2026-09-10

   Core ML ist Apples Framework zur Modellausführung. Die Hardwareauswahl hängt von Modell und Konfiguration ab.
3. 3
   Apple stellt Siri AI vor

   Apple Newsroom; Apple2026-06-08

   Apple beschreibt die Aufteilung zwischen lokaler Verarbeitung und größeren Anfragen über Private Cloud Compute.
4. 4
   Vorstellung von Apples lokalen und serverbasierten Foundation-Modellen

   Apple Machine Learning Research; Apple2024-06-10

   Apple erläutert sein lokales Modell mit rund 3 Milliarden Parametern, gemischte 2-/4-Bit-Palettisierung, durchschnittlich 3,7 Bit pro Gewicht, KV-Cache-Optimierung und Messungen auf dem iPhone 15 Pro.
5. 5
   Technischer Bericht zu den Apple Intelligence Foundation Language Models

   Apple Machine Learning Research; Apple2025-07-17

   Apples späterer technischer Bericht beschreibt Architekturarbeit einschließlich gemeinsam genutztem KV-Cache und quantisierungsbewusstem Training.
6. 6
   Projekt-README von llama.cpp

   GitHub; Mitwirkende von ggml-orgAbgerufen am 2026-09-10

   Die Laufzeitumgebung unterstützt Quantisierung mit wenigen Bit sowie Apples ARM-NEON-, Accelerate- und Metal-Pfade.
7. 7
   iPhone-Beispiel llama.swiftui

   GitHub; Mitwirkende von ggml-orgAbgerufen am 2026-09-10

   Ein gepflegtes Beispiel zeigt lokale llama.cpp-Inferenz auf einem iPhone.
8. 8
   Lokale Spracherkennung mit Voz

   Desert Ant Labs; Desert Ant LabsAbgerufen am 2026-09-10

   Anbieterspezifische Belege für einen Einsatz auf der Apple Neural Engine, einschließlich Modellgröße, Ladeverhalten und Bedingungen des Batch-Tests auf dem iPhone 17 Pro.
9. 9
   Funktionsmatrix von llama.cpp

   GitHub; Mitwirkende von ggml-orgAbgerufen am 2026-09-10

   Unterstützung für Quantisierung und KV-Cache ist ein backendabhängiges Implementierungsdetail.
10. 10
    Cache-Strategien

    Hugging Face Transformers; Hugging FaceAbgerufen am 2026-09-10

    Cache-Wachstum, begrenzte Sliding-Window-Schichten, Cache-Wiederverwendung und Zielkonflikte beim Speicherbedarf.
11. 11
    Modellkarte zu LFM2.5-230M

    Hugging Face; Liquid AI2026-06-25

    Liquid positioniert sein Instruktionsmodell mit 230 Millionen Parametern für Datenextraktion und leichtgewichtige lokale Agentenpipelines, nicht für Aufgaben mit hohem Reasoning-Bedarf.
12. 12
    Apple präsentiert iPhone 18 Pro und iPhone 18 Pro Max

    Apple Newsroom2026-09-09

    Das benachbarte Speicherpackage des A20 Pro und der direkte thermische Pfad zur Dampfkammer.

12 Quellen. Die Links führen zu den Originalquellen.

Zuletzt aktualisiert: 10. September 2026