KI auf dem Gerät: die strategische Entscheidung zwischen Server und On-Device

KI-Entscheidungen werden schnell zu Architekturentscheidungen, und Architekturentscheidungen werden zu Kosten-, Risiko- und Compliance-Entscheidungen. Daher sollte die Wahl, wo die Inferenz stattfindet, auf dem Server oder auf dem Gerät des Benutzers, nicht an das Ende des Projekts delegiert werden. Es prägt das Produkt von Anfang an.

Dieser Text ist für diejenigen, die entscheiden. Technischer Leiter, Produktleiter, CTO. Die grundlegende Frage ist praktischer Natur: Wann ist es sinnvoll, KI auf dem Gerät des Nutzers statt auf seiner Infrastruktur auszuführen, und was kostet das im Gegenzug?

Ich werde das Thema als Kompromiss betrachten, denn genau das ist es. Es gibt keine universelle rechte Seite. Es gibt eine rechte Seite für einen Anwendungsfall, eine Zielgruppe und ein Risikoprofil.

Der Kompromiss aus geschäftlicher Sicht

Durch die Ausführung auf dem Server haben Sie die Kontrolle. Sie wählen das Modell aus, aktualisieren es, wann immer Sie möchten, beobachten, was passiert, messen und passen es an. Sie können große Grenzmodelle mit Kapazitäten verwenden, die kein Benutzergerät aufnehmen kann. Diese Freiheit hat einen doppelten Preis: Sie zahlen pro Inferenzanruf und die Daten des Benutzers müssen an Ihren Computer übertragen werden.

Wenn Sie es auf dem Gerät ausführen, wird die Gleichung umgekehrt. Die Grenzkosten der Inferenz sinken auf nahezu Null, da die Verarbeitung die Hardware des Benutzers nutzt. Die Daten verlassen das Gerät nicht, was die Diskussion über den Datenschutz verändert. Und die Anwendung kann offline arbeiten. Der Preis hier ist die Einschränkung: Sie werden von der Kapazität des Geräts, den Modellen, die darauf passen, und der Komplexität der Wartung verteilter Modelle als Geisel gehalten.

Um die zentrale Spannung zusammenzufassen: Server bedeutet Kontrolle und Kapazität auf Kosten von Geld und Datenverkehr. Das Gerät ist geschützt, es fallen keine Inferenzkosten an und es ist offline, allerdings auf Kosten der Drosselung und Fragmentierung. Die technische Übersicht über dieses Szenario finden Sie ausführlich in In-Browser AI and Local Inference.

Wenn sich die Kosten ändern, ändert sich die Rechnung

Das finanzielle Argument verdient ehrliche Aufmerksamkeit. Serverseitige Inferenz skaliert mit der Nutzung. Je mehr Benutzer und je mehr Anrufe, desto höher ist die GPU-Rechnung. Bei einem Produkt mit vielen aktiven Benutzern und vielen KI-Interaktionen pro Sitzung wächst diese Zahl aggressiv.

Durch die Inferenz auf dem Gerät werden diese Kosten auf die Hardware übertragen, die der Benutzer bereits gekauft hat. Bei häufigen, kleinen Aufgaben kann dies den Unterschied zwischen einer abgeschlossenen Einheitsökonomie und einer Einheitsökonomie, die mit jeder Iteration Geld blutet, ausmachen.

Aber Vorsicht vor naiver Lektüre. Sie tauschen Inferenzkosten gegen Engineering-Kosten aus: Das Konvertieren, Optimieren, Quantisieren, Versionieren und Verteilen clientseitiger Modelle ist nicht kostenlos. Der Gewinn tritt ein, wenn das Inferenzvolumen hoch genug ist, um die festen technischen Kosten zu verwässern. Bei einem Produkt mit geringer Stückzahl ist der Server in der Regel insgesamt günstiger.

Der Zusammenhang mit LGPD und sensiblen Daten

Hier liegt meiner Meinung nach das stärkste und am meisten unterschätzte Argument für On-Device. Wenn Daten das Gerät nicht verlassen, entsteht ein Großteil des Compliance-Problems einfach nicht.

LGPD behandelt Kategorien sensibler Daten mit besonderer Sorgfalt: Gesundheit, Biometrie, Kinderdaten, Informationen, die eine solide Rechtsgrundlage und eine sorgfältige Verarbeitung erfordern. Jedes Mal, wenn diese Daten übertragen und in Ihrer Infrastruktur gespeichert werden, übernehmen Sie die Verantwortung, das Leckagerisiko und die Schutzpflicht.

Durch die lokale Bearbeitung wird diese Oberfläche reduziert. Wenn die Schlussfolgerung auf dem Gerät erfolgt und die Daten nicht auf dem Server übertragen oder gespeichert werden, minimieren Sie, was Sie sammeln und was Sie aufbewahren, ein Grundsatz, der den Kern des Gesetzes selbst bildet. Für Branchen wie das Gesundheitswesen und die Regierung, in denen sensible Daten eher die Regel als die Ausnahme sind, kann die Verarbeitung auf dem Gerät ein echter Compliance-Vorteil sein.

Es ist keine Wunderwaffe. Das kundenseitige Modell erfordert weiterhin Sorgfalt, und es gibt Verpflichtungen, die nicht verschwinden. Aber die Reduzierung der Übertragung und Speicherung sensibler Daten ist eine der effektivsten Möglichkeiten, regulatorische Risiken zu reduzieren, denn der beste Schutz für Daten besteht darin, sie nicht auf Ihrem Server zu haben.

Es gilt auch das Vertrauensargument. Dem Benutzer mit technischer Aufrichtigkeit mitteilen zu können, dass die Analyse seines Fotos oder seiner Gesundheitsinformationen das Gerät nicht verlässt, ist eine aussagekräftige Produktbotschaft. In datenschutzrelevanten Märkten ist dies kein technisches Detail mehr, sondern ein Unterscheidungsmerkmal im Wettbewerb und ein Markennarrativ.

Die Risiken, die Sie eingehen, wenn Sie sich für ein Gerät entscheiden

Bei einer ausgereiften strategischen Entscheidung werden die Kosten von unten betrachtet, nicht nur der Nutzen von oben. Rückschlüsse auf dem Gerät bergen drei Risiken, die berücksichtigt werden müssen.

Die erste ist die Hardwarefragmentierung. Ihr Publikum nutzt Geräte mit sehr unterschiedlichen Funktionen. In einigen Fällen dedizierte NPU, in anderen alte Hardware. Die gleiche Funktion sorgt für unterschiedliche Erlebnisse, und Sie haben keine Kontrolle über diesen Park. Dies zwingt Sie dazu, einen Fallback einzuplanen, und ein Fallback bedeutet in der Regel auch die Beibehaltung des Serverpfads.

Die zweite ist unreife Unterstützung. Die meisten APIs, die eine Browserbeschleunigung ermöglichen, befinden sich noch in der Entwicklung. WebNN beispielsweise bleibt beim W3C in der Vorschau und wird noch nicht für die Produktion empfohlen. Auf einem instabilen Fundament aufzubauen bedeutet, Nacharbeiten in Kauf zu nehmen.

Der dritte Punkt ist die Modellpflege. Das Aktualisieren eines Modells auf dem Server ist trivial: Sie ändern es und das war’s. Das Aktualisieren eines Modells, das über Millionen von Geräten verteilt ist, stellt ein Rollout-Problem dar, da Versionen nebeneinander existieren, der Cache ungültig gemacht werden muss und Benutzer sich in unterschiedlichen Zuständen befinden. Diese Betriebskosten sind fortlaufend und still und können bei der Planung leicht unterschätzt werden.

So treffen Sie die Entscheidung in der Praxis

Ich verwende einen einfachen, mehrschichtigen Filter. Erstens die Art der Daten. Wenn es sensibel und reguliert ist, gewinnt das On-Device an Stärke für die Compliance. Zweitens die Größe des benötigten Modells. Wenn die Aufgabe eine große Modellkapazität erfordert, ist der Server fast obligatorisch. Drittens, der Umfang der Schlussfolgerung. Ein hohes Volumen begünstigt das Gerät aufgrund der Wirtschaftlichkeit; Ein geringes Volumen begünstigt den Server aufgrund seiner Einfachheit.

Die in der Praxis häufigste Antwort ist Hybrid. Lokales Modell für den häufigen, privaten und latenzempfindlichen Fall mit Eskalation an den Server, wenn die Aufgabe mehr Kapazität erfordert. Dies erfordert eine Architektur, die zur Laufzeit entscheiden kann, wo die einzelnen Dinge ausgeführt werden sollen. Es erfordert Arbeit, aber es fängt das Beste aus beiden Welten ein, ohne das Produkt an ein Extrem zu binden.

Was ich nicht empfehle, ist, sich für eine Modeerscheinung zu entscheiden. Bei der KI im Produkt geht es um Prozesse, Datenverwaltung und Ergebnismessung, nicht um Buzzword-Rennen. Die alles bestimmende Frage lautet: Welches konkrete Problem lässt sich am besten lösen, indem man den Ort ändert, an dem die Schlussfolgerung stattfindet? Wenn Sie nicht klar antworten können, ist die Entscheidung noch nicht reif.