On-Device-KI in Mobile Apps: der 2026-Leitfaden für Teams in den USA & der EU

Anna Kowalski Senior Mobile Engineer, YuSMP Group · iOS-, Android- und Cross-Plattform-KI-Features seit 2015

TL;DR — was ist On-Device-KI 2026?

• On-Device-KI ist der Leittrend der Mobile-Entwicklung 2026, und das aus einem konkreten Grund: Sie macht KI-Features standardmäßig privat, sofort verfügbar, offline-fähig und frei von API-Kosten pro Anfrage.
• Die Plattformen liefern sie Ihnen jetzt mit. Apple Intelligence stellt jeder iOS-App On-Device Foundation Models bereit; Google bietet Gemini Nano über AICore unter Android an. Sie müssen kein ML-Team mehr sein, um ein lokales Modell zu nutzen.
• Denken Sie hybrid, nicht entweder/oder. Ein kleines On-Device-Modell erledigt die häufigen, datenschutzsensiblen 80 % — Zusammenfassungen, smarte Antworten, Klassifizierung, Transkription, Schwärzung — und eskaliert die schwierigen 20 % stillschweigend an ein Cloud-Modell.
• Das Schwierige ist nicht das Modell, sondern der Geräte-Schwanz. Ein Flaggschiff betreibt ein Modell mit 3 Milliarden Parametern bequem; ein drei Jahre altes Android-Mittelklassegerät nicht. Die Erkennung der Geräteklasse und ein sauberer Fallback sind die Architektur, kein Nice-to-have.
• Für ein fokussiertes Feature kalkulieren Sie grob 4–8 Wochen und 25–60k €. Der größte Posten ist die QA auf echter Hardware. Wie wir das umsetzen, sehen Sie in unserer Leistung zur Mobile App-Entwicklung.

Was bedeutet „On-Device-KI" 2026 tatsächlich?

On-Device-KI (auch Edge-KI oder lokale Inferenz genannt) bedeutet, dass das Modell auf dem eigenen Chip des Smartphones läuft — Apples Neural Engine, Qualcomms Hexagon NPU, Googles Tensor — statt auf einem Server, den Sie über das Netz aufrufen. Die praktischen Folgen sind der Grund, warum jedes Produktteam in den USA und der EU plötzlich danach fragt:

• Die Daten verlassen das Gerät nie. Das Foto, die Nachricht, die Sprachnotiz oder die Gesundheitsakte wird lokal verarbeitet. Nichts wird hochgeladen, also gibt es nichts abzufangen, zu protokollieren oder per Gerichtsbeschluss anzufordern.
• Es funktioniert offline. Im Flugzeug, im Tunnel, im Kellergeschoss eines Krankenhauses — das Feature funktioniert weiterhin, weil das Modell bereits auf dem Smartphone liegt.
• Es ist sofort verfügbar. Kein Netz-Roundtrip bedeutet, dass Antworten in zweistelligen Millisekunden beginnen, nicht erst nach einer Sekunde Latenz.
• Es hat keine Grenzkosten. Es gibt keine API-Rechnung pro Token. Zehn Nutzer oder zehn Millionen Nutzer kosten bei der Inferenz dasselbe: nichts.

Dieser letzte Punkt verändert die Ökonomie von KI-Features still und leise. Cloud-LLM-Rechnungen skalieren linear mit der Nutzung; On-Device-Inferenz tut das nicht. Für eine Consumer-App mit Millionen täglicher KI-Interaktionen kann das Verlagern des Standardfalls auf das Gerät unbegrenzte variable Kosten in null verwandeln.

Das neuronale Silizium, das es ermöglicht

Jedes aktuelle Flaggschiff bringt eine dedizierte NPU (Neural Processing Unit) mit. Diese Hardware-Landschaft bestimmt, welche Modelle Ihre Nutzer ausführen können:

Android-Mittelklasse (Dimensity-7000-Klasse, Snapdragon 6 Gen) hat begrenzte oder keine NPU-Beschleunigung für große Modelle — genau deshalb sind Gerätetier-Erkennung und Fallback-Pfad obligatorisch.

Was sich 2024–2026 geändert hat

Wenn Ihr mentales Modell lautet „Man braucht ein ML-Team, um ein Modell auf einem Smartphone laufen zu lassen", ist es zwei Jahre veraltet. Drei Dinge haben sich verändert.

Apple Intelligence brachte ein Modell in jede iOS-App

Seit Apple sein On-Device-Framework Foundation Models für Drittentwickler geöffnet hat, kann jede iOS-App mit wenigen Zeilen Swift ein System­modell von rund 3 Milliarden Parametern aufrufen — geführte Generierung, Tool Calling und strukturierte Ausgabe inklusive, alles auf der Neural Engine. Sie erhalten ein leistungsfähiges lokales Modell, ohne selbst eines auszuliefern, zu aktualisieren oder dafür zu bezahlen. Für die meisten „Fasse das zusammen"-, „Schreibe das um"- und „Extrahiere diese Felder"-Features ist dies unter iOS nun der Standard-Ausgangspunkt.

Google machte Gemini Nano zum Systemdienst unter Android

Auf der Android-Seite läuft Gemini Nano über AICore als verwaltete Systemkomponente. Apps fordern On-Device-Inferenz über die ML-Kit-GenAI-APIs an — Zusammenfassung, Korrekturlesen, Umformulierung, Bildbeschreibung — und das Betriebssystem verwaltet das Modell. Wie bei Apple wird das Modell vom System geteilt, bläht also Ihr APK nicht auf und wird durch Plattform-Updates aktuell gehalten.

Offene Modelle wurden klein genug — und die Laufzeiten gut

Jenseits der integrierten Systemmodelle läuft eine Welle kleiner offener Modelle (in der 1–4-Mrd.-Klasse, auf 4 Bit quantisiert) inzwischen gut auf Smartphones — über ausgereifte Laufzeiten: Core ML und MLX unter iOS, LiteRT (das umbenannte TensorFlow Lite) und der MediaPipe-LLM-Stack unter Android sowie plattformübergreifende Engines wie ExecuTorch, MLC LLM und llama.cpp. Damit können Sie Ihr eigenes feinabgestimmtes Modell ausliefern, wenn das Systemmodell nicht genügt — um den Preis, die Gewichte mitzuführen und den Engineering-Aufwand, sie schnell zu halten.

On-Device vs. Cloud: die echte Abwägung

Das ist die Entscheidung, auf die es ankommt, und sie ist nicht ideologisch. On-Device und Cloud sind Werkzeuge mit unterschiedlichen Aufgaben.

Die ehrliche Antwort für die meisten Apps ist hybrid: Routen Sie jede Anfrage an die günstigste Ebene, die sie bewältigen kann. On-Device erledigt Zusammenfassung, smarte Antworten, Klassifizierung, Entitäten-Extraktion, Transkription, Schwärzung und semantische Suche über lokale Daten — die volumenstarke, datenschutz- und latenzsensible Arbeit. Die Cloud übernimmt den langen Schwanz, der wirklich Spitzen-Reasoning oder frisches Wissen braucht. Wir entwerfen diese Routing-Schicht als erstklassigen Teil der Architektur, so wie wir eine Caching-Schicht entwerfen würden — mehr zum Engineering in unserer Leistung KI, ML & Data.

Der On-Device-KI-Stack, nach Plattform

Hier ist, wozu wir je nach Ziel tatsächlich greifen.

iOS

• Apple Intelligence Foundation Models — der Standard für Textgenerierung, Zusammenfassung, strukturierte Extraktion und Tool-Nutzung auf unterstützten Geräten. Kein eigenes Modell auszuliefern.
• Core ML + MLX — für eigene Modelle: Vision, Audio oder ein feinabgestimmtes LLM, das Sie konvertieren und auf der Neural Engine / GPU ausführen.
• Vision, Natural Language, Speech, Sound Analysis — ausgereifte First-Party-Frameworks für OCR, Klassifizierung, On-Device-Transkription und mehr, alles lokal.

Android

• Gemini Nano via AICore + ML Kit GenAI — der verwaltete Standardweg für Zusammenfassen / Korrekturlesen / Umformulieren / Bildbeschreiben auf leistungsfähigen Geräten.
• LiteRT + MediaPipe LLM Inference — für die Ausführung eigener quantisierter Modelle (Gemma und andere) mit GPU-/NNAPI-Beschleunigung.
• NNAPI / Hersteller-NPUs — Qualcomm und andere stellen eigene SDKs bereit, wenn Sie die Hardware ausreizen müssen.

Cross-Plattform (React Native / Flutter)

• ExecuTorch (PyTorchs On-Device-Laufzeit) und MLC LLM geben Ihnen ein Modell, das auf beiden Plattformen läuft.
• llama.cpp-Bindings bleiben die pragmatische Wahl, um ein bestimmtes offenes Modell mit voller Kontrolle auszuliefern.
• Für die beste Leistung pro Watt binden Sie weiterhin an die nativen Frameworks oben an — ein wiederkehrendes Thema in unserem Vergleich React Native vs. Flutter: Die Cross-Plattform-Schicht ist Ihre UI, die KI lebt nah an der Hardware.

Framework-Vergleich auf einen Blick

Modelle auf das Gerät bringen: Optimierungsgrundlagen

Ein Modell auf einem Smartphone gut zum Laufen zu bringen, ist zu 80 % Engineering, zu 20 % Modellwahl. Drei Techniken, die Sie bei jedem Projekt einsetzen werden:

• Quantisierung (INT8 / INT4) — Gewichtspräzision von FP32 oder FP16 reduzieren. Ein 3-Mrd.-Modell in FP16 ist ~6 GB; bei INT4 schrumpft es auf ~1,7 GB — smartphone-kompatibel. Der Genauigkeitsverlust liegt typischerweise bei 2–6 % auf Standard-Benchmarks; überprüfen Sie es immer für Ihre spezifische Aufgabe, bevor Sie ausliefern.
• Pruning — redundante Gewichte auf null setzen und ihre Berechnung überspringen. Am effektivsten bei aufgabenspezifischen feinabgestimmten Modellen; erhöht den Trainingsaufwand, reduziert aber die Inferenzzeit erheblich.
• Knowledge Distillation — ein kleines „Schüler"-Modell so trainieren, dass es ein großes „Lehrer"-Modell imitiert. Apples und Googles integrierte Systemmodelle entstanden auf diese Weise.

Hardware-Delegierung ist ebenso wichtig: Core ML leitet automatisch an die Neural Engine weiter; LiteRT nutzt NNAPI mit GPU- oder Hexagon-Delegate als Fallback. Ohne Delegierung zahlen Sie auf demselben Gerät 5–10-fach höhere Latenz.

Was Sie heute tatsächlich ausliefern können

Konkrete Features, die wir On-Device gebaut oder konzipiert haben, ohne Cloud-Abhängigkeit für den Kernpfad:

• Zusammenfassen & smarte Antwort — lange Threads, E-Mails, Dokumente lokal verdichtet; Antwortvorschläge generiert, ohne das Gespräch hochzuladen.
• Offline-Transkription & -Übersetzung — Sprachnotizen und Meetings On-Device transkribiert; nützlich im Gesundheitswesen, in der Rechtsbranche und im Außendienst, wo Audio das Smartphone nicht verlassen darf.
• On-Device-Schwärzung — Gesichter, Kennzeichen, Kartennummern und PII in Bildern erkennen und verpixeln, bevor irgendetwas geteilt oder hochgeladen wird.
• Semantische Suche über persönliche Daten — Ihre eigenen Notizen, Fotos und Nachrichten nach Bedeutung durchsuchen, mit lokal berechneten und gespeicherten Embeddings.
• Smarte Kamera & Dokumentenerfassung — Echtzeit-Klassifizierung, OCR und Feldextraktion (Belege, Ausweise, Formulare) ohne Netz.
• Personalisierung, die privat bleibt — Ranking, Vorschläge und On-Device-Profile, die nie zu einem serverseitigen Dossier werden.

Datenschutz, DSGVO und die EU-KI-Verordnung

Hier ist On-Device-KI mehr als ein Performance-Trick — sie ist eine Compliance-Haltung, was genau der Grund ist, warum sie im europäischen Markt so stark anklingt.

• DSGVO-Datenminimierung, von Grund auf. Werden personenbezogene Daten nur auf dem Gerät des Nutzers verarbeitet und nie übertragen, entfällt eine ganze Klasse von Pflichten: keine grenzüberschreitende Übermittlung, keine Drittland-Garantien, weit weniger aufzubewahren, zu protokollieren oder offenzulegen. Es ist einer der saubersten Wege, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen zu belegen.
• Kein Drittanbieter-Verarbeiter für den Kernpfad. Das Senden von Nutzertext an ein Cloud-LLM macht diesen Anbieter zu einem Auftragsverarbeiter, den Sie vertraglich binden, dokumentieren und offenlegen müssen. Behalten Sie es On-Device, und diese Beziehung — und ihr Risiko — existiert schlicht nicht.
• Die EU-KI-Verordnung gilt weiterhin. On-Device befreit Sie nicht. Transparenzpflichten (Nutzern mitteilen, dass sie mit KI interagieren), verbotene Praktiken und Hochrisiko-Einstufungen hängen vom Anwendungsfall ab, nicht davon, wo die Inferenz läuft. Was On-Device beseitigt, ist das grenzüberschreitende und das Verarbeiter-Risiko, nicht Ihre Pflichten aus der KI-Verordnung. Den Rahmen haben wir in unserer Checkliste zur EU-KI-Verordnung behandelt.

Das praktische Muster: Erledigen Sie die datenschutzsensible Arbeit On-Device, und wenn Sie in die Cloud eskalieren, eskalieren Sie geschwärzte, minimierte Daten mit ausdrücklicher Einwilligung — niemals den Rohdatensatz.

Kosten, Zeitplan und Team

Echte Zahlen, wie wir diese Arbeit 2026 für Kunden in den USA und der EU kalkulieren:

• Ein fokussiertes On-Device-Feature (Zusammenfassung, smarte Antworten, Offline-Transkription oder Schwärzung): ~4–8 Wochen, ~25–60k €. Team: 1 Mobile-Entwickler mit On-Device-ML-Erfahrung, ML-Support in Teilzeit, QA über eine Gerätematrix.
• Eine KI-first-App mit mehreren On-Device-Features plus einer hybriden Cloud-Eskalationsschicht: ~3–5 Monate, pro Feature kalkuliert.
• Der dominierende Kostenfaktor ist die QA, nicht das Modell. Integrierte Systemmodelle sind kostenlos aufrufbar; die Arbeit besteht darin, Verhalten, Performance und Akku über den langen Schwanz echter Android-Hardware zu verifizieren, plus den Fallback-Pfad für nicht unterstützte Geräte.

Für vollständige Benchmarks über den gesamten Build hinweg siehe unseren Kostenleitfaden zur Mobile-App-Entwicklung 2026. Der On-Device-spezifische Rat: Budgetieren Sie ausdrücklich ein Testlabor mit echten Geräten, und legen Sie Ihre minimal unterstützte Geräteklasse fest, bevor Sie eine Zeile Inferenzcode schreiben.

Herausforderungen und Einschränkungen, von denen niemand spricht

Das Muster ist real und liefert Ergebnisse. Aber es gibt echte Engineering-Einschränkungen, die Budgets belasten, wenn sie zu spät entdeckt werden. Folgendes planen erfahrene Teams von Anfang an explizit ein:

• Modellgröße und RAM-Druck. Ein 3-Mrd.-Modell bei 4-Bit ist rund 1,7 GB auf dem Datenträger und benötigt vergleichbaren RAM zur Inferenzzeit. Auf einem Gerät mit 6 GB Gesamt-RAM — von dem das Betriebssystem und die Vordergrundapp bereits 2–3 GB beanspruchen — konkurrieren Sie um den Rest. iOS beendet Prozesse, die RAM-Spitzen verursachen; Android-Mittelklasse ist noch enger. Modellgröße-Budgetierung ist eine erstklassige Architekturentscheidung, kein nachträglicher Feinschliff.
• Akku-Entladung und Wärmeentwicklung. Anhaltende On-Device-Inferenz — eine Live-Transkriptionssitzung, ein langer Generierungslauf — kann den Akkuverbrauch auf 15–25 % pro Stunde treiben und auf manchen Geräten Thermal Throttling auslösen. Die NPU ist weit effizienter als dieselbe Last auf CPU oder GPU, aber es ist dennoch real. Profilen Sie Akkuverbrauch und CPU-Temperatur auf echten Geräten, bevor Sie ein Feature-Design bestätigen, das anhaltende Inferenz erfordert.
• Android-Fragmentierung. Es gibt mehr als 10.000 aktive Android-Gerätemodelle weltweit. Gemini Nano via AICore erfordert einen spezifischen ML-Capability-Tier, der nicht auf allen Android-12+-Geräten vorhanden ist. Gerätetier-Erkennung und ein sauberer Fallback-Pfad sind keine Nachgedanken — sie sind das Design.
• Modell-Veralterung. Das On-Device-Modell ist auf die mit der App ausgelieferte Version eingefroren. Es kennt keine regulatorische Änderung, keine Preisaktualisierung und kein Ereignis der letzten Woche. Wenn Ihr Feature aktuelle Kenntnisse benötigt — Preise, Nachrichten, Inventar — werden On-Device-Antworten veralten. On-Device eignet sich am besten für zeitlose Aufgaben; aktuelles Wissen gehört in die Cloud.
• Langsamer Iterationszyklus. Im Gegensatz zu einer Cloud-API, bei der Sie Modellversionen in Minuten tauschen, bedeutet das Aktualisieren eines On-Device-Modells einen App-Store-Update oder einen Hintergrund-Asset-Download. Planen Sie Model-Versionierung als benanntes Engineering-Anliegen von Tag eins an.

Umsetzungs-Checkliste

Die Reihenfolge, der wir folgen, wenn wir On-Device-KI in eine Mobile App einbauen:

1. Definieren Sie die Aufgabe. Ein Satz: „Threads zusammenfassen", „offline transkribieren", „PII schwärzen". Vage KI-Ambitionen sind der Ort, an dem Budgets sterben.
2. Probieren Sie zuerst das Systemmodell. Apple Intelligence unter iOS, Gemini Nano unter Android. Wenn es gut genug ist, sind Sie fast fertig.
3. Legen Sie die Geräteuntergrenze fest. Wählen Sie die minimale Geräteklasse, die Sie On-Device unterstützen, und entwerfen Sie den Cloud- (oder Graceful-Degrade-)Fallback für alles darunter.
4. Wählen Sie das Modell nur, wenn nötig. Reicht das Systemmodell nicht, wählen Sie ein kleines offenes Modell und quantisieren auf 4 Bit; messen Sie Größe, Latenz und Akku, nicht nur Genauigkeit.
5. Bauen Sie die Routing-Schicht. On-Device zuerst, Cloud-Eskalation für die schwierigen oder veralteten Fälle, mit Einwilligung und Schwärzung an der Grenze.
6. Testen Sie auf echter Hardware. Emulatoren lügen über NPU-Performance und Akku. Verwenden Sie eine physische Gerätematrix vom Flaggschiff bis zur Mittelklasse.
7. Messen Sie Akku und Thermik. Anhaltende Inferenz erhitzt Smartphones. Profilen Sie es; drosseln oder bündeln Sie, wo nötig.
8. Offenlegen und einwilligen. Sagen Sie Nutzern, wann KI im Spiel ist und was (falls überhaupt) das Gerät verlässt — gute UX und KI-Verordnungs-Hygiene zugleich.

Wann Cloud-KI weiterhin gewinnt

On-Device ist ein Standard, keine Religion. Wir liefern Cloud-first aus, wenn eines davon zutrifft:

• Spitzen-Reasoning — komplexe mehrstufige Analyse, Programmierung oder feines Urteilsvermögen, das ein 3-Mrd.-Modell nicht zuverlässig leisten kann.
• Großer Kontext — Reasoning über ein 200-seitiges Dokument oder eine lange Historie, die nicht in ein kleines lokales Modell passt.
• Frisches Wissen — Antworten, die heutige Daten, Preise oder Bestände widerspiegeln müssen, über Retrieval oder Live-Tools.
• Geteilter, serverseitiger Zustand — wenn die Intelligenz von Natur aus die Daten anderer Nutzer betrifft, nicht die auf diesem Smartphone.

Die siegreiche Architektur 2026 ist hybrid: On-Device für den privaten, sofortigen, volumenstarken Standardfall; Cloud für den schweren, gelegentlichen. Diese Grenze richtig zu ziehen — und die Einwilligung und Schwärzung daran — ist das eigentliche Engineering. Es ist der Kern dessen, wie wir Mobile Apps mit KI für Kunden in den USA und der EU bauen.

FAQ

Was ist On-Device-KI in einer Mobile App?

Das Modell läuft auf dem eigenen Chip des Smartphones (Apple Neural Engine, Android NPU) statt auf einem Cloud-Server. Die Eingabe verlässt das Gerät nie, es funktioniert offline, und es gibt keine Rechnung pro Anfrage. 2026 wird es über Apple Intelligence unter iOS und Gemini Nano unter Android bereitgestellt, dazu offene Modelle via Core ML, LiteRT, ExecuTorch, MLC und llama.cpp.

On-Device-KI vs. Cloud-KI — welche sollte ich nutzen?

On-Device für Datenschutz, Offline, Latenz und null Grenzkosten: Zusammenfassungen, smarte Antworten, Klassifizierung, Transkription, Schwärzung. Cloud für Spitzen-Reasoning, großen Kontext oder frisches Wissen. Die meisten produktiven Apps sind hybrid — On-Device für die häufigen 80 %, Cloud für die schwierigen 20 %.

Wie groß kann ein Modell 2026 auf einem Smartphone sein?

Bequem 1–4 Milliarden Parameter bei 4 Bit auf einem aktuellen Flaggschiff (iPhone 15 Pro+, Pixel 8/9, Galaxy S24/S25). Die integrierten Systemmodelle liegen rund um die 3-Mrd.-Klasse. Android-Mittelklasse zielt auf kleinere Modelle oder weicht auf die Cloud aus — die Erkennung der Geräteklasse ist daher Teil des Designs.

Ist On-Device-KI besser für die DSGVO und die EU-KI-Verordnung?

Bei der DSGVO meist ja: Eine vollständig On-Device durchgeführte Verarbeitung senkt das Übermittlungs-, Verarbeiter- und Aufbewahrungsrisiko erheblich — saubere Datenminimierung. Die EU-KI-Verordnung gilt weiterhin nach Anwendungsfall (Transparenz, verbotene/Hochrisiko-Regeln), On-Device senkt also das grenzüberschreitende Risiko, befreit Sie aber nicht.

Wie viel kostet es, On-Device-KI in eine App einzubauen?

Ein fokussiertes Feature läuft grob über 4–8 Wochen und 25–60k € mit einem Senior-Team, inklusive Modellauswahl, einem Fallback nach Geräteklasse und QA auf echter Hardware. Der größte Kostentreiber ist das Testen über den Android-Geräte-Schwanz, nicht das Modell selbst.

Funktioniert On-Device-KI offline und auf älteren Smartphones?

Offline: ja, das ist der Sinn. Ältere Smartphones: Flaggschiffe der letzten 2–3 Jahre bewältigen 1–4-Mrd.-Modelle; ältere und Mittelklassegeräte benötigen kleinere Modelle oder einen Cloud-Fallback. Ein korrekter Build erkennt die Geräteklasse zur Laufzeit und routet entsprechend.

Entlädt On-Device-KI den Akku?

Es kommt auf die Aufgabe an. Ein Hintergrund-Klassifizierungsaufruf kostet vernachlässigbaren Akku — unter 0,1 % pro Sitzung. Anhaltende Echtzeit-Aufgaben wie Live-Transkription oder langer Textgenerierung können bei manchen Geräten 15–25 % Akku pro Stunde kosten. Die NPU ist weit effizienter als dieselbe Last auf CPU oder GPU, aber anhaltende Inferenz summiert sich. Profilen Sie Akku und Thermik auf echter Hardware und bündeln oder drosseln Sie schwere Aufgaben, wo es die UX erlaubt.

Wie funktionieren Modell-Updates On-Device?

Anders als bei einer Cloud-API, bei der Sie Modellversionen stillschweigend tauschen können, sind On-Device-Modelle mit der App gebündelt oder werden zusammen mit ihr heruntergeladen. Das Aktualisieren bedeutet einen App-Store-Update oder einen Hintergrund-Asset-Download über WLAN. Schnelle Iteration ist langsamer als in der Cloud — planen Sie Model-Versionierung von Tag eins an, besonders wenn Ihr Anwendungsfall von periodischem Retraining oder Fine-Tuning profitieren wird.

Wie wir für Ihre App entscheiden würden

Geben Sie uns 30 Minuten und das eine Feature, das Sie im Kopf haben, und wir sagen Ihnen, ob es On-Device, in die Cloud oder auf beides verteilt gehört — mit realistischen Kosten und einem Zeitplan für Ihr Team und Ihren Markt. Keine Folien, kein Upselling. Wir liefern beides aus, und es ist uns gleich, für welches Sie sich entscheiden, solange es das richtige ist.

Zuletzt aktualisiert am 4. September 2026. NPU-Hardware-Vergleichstabelle, Framework-Vergleich, Modelloptimierungstechniken, Herausforderungen-Abschnitt und zwei weitere FAQ-Einträge ergänzt. Modellklassen und Frameworks spiegeln Apple Intelligence Foundation Models, Google Gemini Nano / AICore, Core ML, LiteRT und ExecuTorch wider, wie Mitte 2026 verfügbar. Geräteleistung gemessen auf iPhone 15 Pro, Pixel 9 und einem Android-Mittelklasse-Referenzgerät. Methodik auf Anfrage verfügbar.