Lokal ist eine Eigenschaft der Workload
«KI lokal ausführen» kann verschiedene Architekturen meinen: ein Modell in einer Desktop-Anwendung, einen Inferenzserver im eigenen Rechenzentrum, einen Kubernetes-Dienst auf privater Infrastruktur oder ein Edge-System nahe bei Maschinen und Sensoren.
Foundry Local adressiert eine konkrete Form: Modellinferenz wird mit einer Anwendung ausgeliefert und auf dem Gerät des Nutzers ausgeführt. Microsoft beschreibt SDKs für mehrere Sprachen, einen kuratierten Katalog optimierter Modelle, automatische Hardwarebeschleunigung, Modellverwaltung und eine OpenAI-kompatible Schnittstelle.
Das ist wertvoll – aber keine Serverplattform für viele gleichzeitige Nutzer.
Wann Inferenz auf dem Gerät passt
Foundry Local ist ein glaubwürdiger Kandidat, wenn die Mission eine oder mehrere dieser Bedingungen hat:
- Prompts und Resultate sollen während der Inferenz auf dem Gerät bleiben;
- die Anwendung muss ohne Netzverbindung weiterarbeiten;
- die Reaktion darf nicht von einem Cloud-Roundtrip abhängen;
- eine Person nutzt das Modell auf der eigenen Hardware;
- das unterstützte lokale Modell erfüllt die gemessene Aufgabe;
- Verteilung und Aktualisierung der Modellartefakte sind betrieblich beherrschbar.
Beispiele sind private Dokumentassistenz auf einem verwalteten Laptop, Offline-Unterstützung im Feld, lokale Transkription oder eine interaktive Anwendung, die ein kleines Modell für sofortige Klassifikation und Entwürfe nutzt.
Lokale Ausführung macht nicht automatisch die gesamte Anwendung privat. Modelldownloads, Anwendungsupdates, Diagnosen, Synchronisation und Cloud-Fallbacks benötigen weiterhin einen dokumentierten Datenfluss.
Wann es nicht passt
Nutzen Sie eine Client-Runtime nicht als Serverplattform für viele gleichzeitige Nutzer. Geteilte Inferenz benötigt Warteschlangen, Batching, Kapazitätsmanagement, Isolation und GPU-Auslastungsmuster, die für einen Service entwickelt wurden.
Lokale Inferenz kann auch ungeeignet sein, wenn die Aufgabe ein zu grosses Modell benötigt, zentral gesteuertes Retrieval über häufig wechselnde Quellen verlangt, konsistente Leistung über sehr unterschiedliche Geräte braucht oder Betriebskontrollen voraussetzt, die die Endpoint-Flotte nicht tragen kann.
«Keine Cloud-Kosten pro Token» bedeutet nicht kostenlos. Berücksichtigen Sie Endpoint-Hardware, Modellverteilung, Speicher, Energie, Support, fehlgeschlagene Updates und Tests über die Geräteflotte.
Die hybride Route explizit entwerfen
Eine hybride Anwendung kann verschiedene Inferenzpfade nutzen:
- ein lokales Modell bearbeitet sensible, routinemässige oder latenzkritische Aufgaben;
- ein verwaltetes Cloud-Modell übernimmt komplexe Fälle mit höherem Fähigkeitsbedarf;
- privates Retrieval erstellt einen minimierten Kontext;
- eine Richtlinienebene entscheidet, ob eine Anfrage Gerät oder Grenze verlassen darf;
- vorgemerkte Arbeit synchronisiert, sobald die Verbindung zurückkehrt.
Der Router sollte, wo möglich, deterministisch sein. Nutzen Sie Datenklassifikation, Aufgabentyp, Konnektivität, gemessene Modellfähigkeit, Latenzbudget und Einwilligung – nicht ein unbeschränktes Modell, das selbst über den Datenpfad entscheidet.
Machen Sie Fallbacks sichtbar. Ist das lokale Modell nicht verfügbar, darf die Anwendung die Anfrage nicht unbemerkt an einen Cloud-Endpunkt senden.
Pro Zielgerät evaluieren
Eine lokale Modellvariante kann sich anders verhalten als das Cloud-Modell aus der Entwicklung. Evaluieren Sie Modelle, Quantisierung, Prompts, Runtime und Hardwareklassen, die tatsächlich ausgeliefert werden.
Messen Sie:
- Aufgabenerfolg und kritische Fehlerfälle;
- Startzeit und Antwortlatenz;
- Speicher-, Platz- und Energiebedarf;
- Verhalten auf CPU-, GPU- und NPU-Pfaden;
- Offline- und Download-Wiederherstellung;
- Versionskompatibilität und Rollback;
- Ergebnisunterschiede zwischen lokaler und Cloud-Route.
Fixieren Sie Versionen, wenn Reproduzierbarkeit zählt. Behandeln Sie Modell- und Runtime-Updates als Anwendungsänderungen mit Release-Gate.
Die Flotte betreiben
On-Device-KI verlagert einen Teil des Plattformbetriebs auf den Endpoint. Definieren Sie, wie Modelle freigegeben, verteilt, zwischengespeichert, entfernt und unterstützt werden. Wissen Sie, welche Versionen aktiv sind und wie ein fehlerhaftes oder verwundbares Modellpaket zurückgezogen wird.
Erfassen Sie nur die für den Betrieb nötige Telemetrie innerhalb klarer Einwilligungs- und Datenschutzgrenzen. Lokale Inferenz darf kein Anlass sein, sensible Prompts in zentrale Logs zu kopieren.
Die kleinste ausreichende Umgebung wählen
Die richtige Bereitstellung ist die einfachste Umgebung, die Qualität, Datenschutz, Latenz, Kontinuität, Kosten und Betriebsverantwortung erfüllt.
Nutzen Sie On-Device-Inferenz, wenn das Gerät tatsächlich die beste Grenze ist. Nutzen Sie verwaltete oder private Server-Inferenz, wenn zentrale Kapazität und Kontrolle nötig sind. Nutzen Sie hybrid nur, wenn unterschiedliche Arbeitsklassen die zusätzliche Routing- und Beobachtbarkeitskomplexität rechtfertigen.
Offizielle Referenz
Microsoft erklärt Umfang, Szenarien, lokale Datenverarbeitung, Modellverwaltung und Servergrenzen in Was ist Foundry Local?.