KI ohne Cloud: Foundry Local für Offline- und Datenschutz-Szenarien

Wer in den letzten Monaten mit Kunden aus dem Gesundheitswesen, der Finanzbranche oder dem öffentlichen Sektor über KI gesprochen hat, kennt den Moment: Die Begeisterung ist da, die Use Cases liegen auf dem Tisch — und dann kommt die Frage: “Wo liegen die Daten? Wo werden die Daten hin übertragen?” Und je nach Branche reicht “in der EU” als Antwort nicht aus.

Microsoft hat auf der Build 2025 mit Foundry Local ein Tool vorgestellt, das genau dieses Problem adressiert: KI-Modelle laufen direkt auf dem Gerät des Benutzers. Keine Cloud, kein Server, keine Netzwerkverbindung nötig. Die Daten verlassen das Gerät nie.

Klingt zu schön, um wahr zu sein? Schauen wir uns an, was Foundry Local kann, wie wir es in bestehende .NET-Anwendungen integrieren, und warum ein Hybrid-Ansatz aus lokal und Cloud die spannendste Option sein könnte.

Was ist Foundry Local?

Foundry Local ist eine leichtgewichtige Runtime von Microsoft, die KI-Modelle direkt auf dem Endgerät ausführt. Unter der Haube nutzt es ONNX Runtime — eine performante Inference-Engine in C++ — und bringt damit minimalen Disk- und Speicherbedarf mit.

Die wichtigsten Eigenschaften:

• Komplett offline — Einmal heruntergeladen, brauchen Modelle keine Netzwerkverbindung mehr
• Automatische Hardware-Erkennung — NPU, GPU oder CPU werden automatisch erkannt und genutzt, ohne dass wir eine Zeile Code dafür schreiben
• OpenAI-kompatible API — Der lokale Endpoint spricht dasselbe Protokoll wie Azure OpenAI. Bestehender Code lässt sich mit minimalen Änderungen umstellen
• Plattformübergreifend — Windows, macOS (Apple Silicon), Linux und Android
• Mehrere Aufgaben — Chat/Textgenerierung und Audio-Transkription (Whisper) in einer einzigen Runtime

Foundry Local ist kein Forschungsprojekt. Es ersetzt separate Tools wie llama.cpp, whisper.cpp oder ollama durch eine einheitliche Lösung mit SDK-Unterstützung für C#, JavaScript, Python und Rust.

Installation

Auf Windows geht die Installation über winget:

winget install Microsoft.FoundryLocal

Auf macOS über Homebrew:

brew install microsoft/foundrylocal/foundrylocal

Nach der Installation können wir direkt testen, ob alles funktioniert:

# Verfügbare Modelle anzeigen
foundry model ls

# Ein Modell laden und direkt chatten
foundry model run phi-4-mini

Das war’s. Kein Azure-Konto, kein API-Key, kein Setup. Der foundry model run-Befehl prüft automatisch, ob das Modell lokal gecacht ist, lädt es bei Bedarf herunter und startet eine Chat-Session.

Modellauswahl: Phi-4-mini vs. GPT-OSS-20B

Die beiden spannendsten Modelle im Foundry-Local-Katalog stehen für zwei grundlegend verschiedene Ansätze:

Phi-4-mini (~3,8B Parameter) — Microsofts kompaktes Reasoning-Modell. Läuft auf fast jeder Hardware, auch auf Laptops ohne dedizierte GPU. Die Qualität ist für ein Modell dieser Größe beeindruckend — besonders bei Instruktionsfolge und logischem Schließen.

GPT-OSS-20B (~20B Parameter) — Das größere Geschütz. Mit 20 Milliarden Parametern übertrifft es laut Microsoft sogar das damalige Frontier-Modell GPT-3.5 in Benchmarks — und das als lokal lauffähiges, quantisiertes Open-Source-Modell. Der Haken: Es braucht deutlich mehr Ressourcen.

	Phi-4-mini	GPT-OSS-20B
Parameter	~3,8 Milliarden	~20 Milliarden
Min. RAM/VRAM	8 GB RAM	12+ GB VRAM (GPU empfohlen)
Tokens/s (GPU)	~40–60	~15–25
Tokens/s (CPU)	~10–20	~2–5
Stärke	Schnell, effizient, breite Hardware-Basis	Höhere Qualität, komplexere Reasoning-Aufgaben
Typischer Einsatz	Chat, Q&A, Zusammenfassungen, Code-Hilfe	Dokumentenanalyse, komplexe Instruktionen, mehrsprachige Aufgaben

Meine Empfehlung: Für die meisten Business-Szenarien ist Phi-4-mini der Sweet Spot. Es liefert solide Qualität bei überschaubarem Ressourcenverbrauch und läuft auf Hardware, die in den meisten Unternehmen bereits vorhanden ist. GPT-OSS-20B lohnt sich, wenn die Aufgaben komplexer werden und entsprechende Hardware bereitsteht — zum Beispiel auf Workstations mit NVIDIA RTX oder in Server-Szenarien.

Die Modelle werden automatisch in der für die jeweilige Hardware besten Variante heruntergeladen. Foundry Local wählt selbstständig die optimale Quantisierung — wir müssen uns nicht mit GGUF-Formaten oder Quantisierungsstufen beschäftigen.

Daneben gibt es noch weitere nützliche Modelle im Katalog:

• Phi-3.5-mini — Guter Allrounder, ähnliche Größe wie Phi-4-mini
• Qwen 2.5 (0.5B–7B) — Extrem effizient bei kleiner Größe, ideal für ältere Hardware
• Qwen 2.5 Coder — Spezialisiert auf Code-Verständnis
• Whisper Tiny — Speech-to-Text, komplett lokal

Integration in eine bestehende .NET-Anwendung

Jetzt wird’s praktisch. Wir bauen eine minimale .NET-Konsolenanwendung, die Foundry Local nutzt.

Projekt einrichten

dotnet new console -n FoundryLocalDemo
cd FoundryLocalDemo

Für Windows (empfohlen — unterstützt zusätzlich NPU-Beschleunigung via WinML):

dotnet add package Microsoft.AI.Foundry.Local.WinML
dotnet add package Microsoft.Extensions.Logging.Abstractions

Für macOS oder Linux:

dotnet add package Microsoft.AI.Foundry.Local
dotnet add package Microsoft.Extensions.Logging.Abstractions

Einfache Chat-Completion

Das C# SDK übernimmt den kompletten Lifecycle: Service starten, Modell laden, Inference ausführen.

using Betalgo.Ranul.OpenAI.ObjectModels.RequestModels;
using Microsoft.AI.Foundry.Local;
using Microsoft.Extensions.Logging.Abstractions;

var config = new Configuration { AppName = "foundry_local_demo" };
await FoundryLocalManager.CreateAsync(config, NullLogger.Instance);
var manager = FoundryLocalManager.Instance;

// Modell aus dem Katalog laden
var catalog = await manager.GetCatalogAsync();
var model = await catalog.GetModelAsync("phi-4-mini");

// Download (nur beim ersten Mal, danach aus dem Cache)
await model.DownloadAsync();
await model.LoadAsync();

// Chat-Client erstellen und Antwort streamen
var chatClient = await model.GetChatClientAsync();
var messages = new List<ChatMessage>
{
    new("system", "Du bist ein hilfreicher Assistent. Antworte auf Deutsch."),
    new("user", "Erkläre die drei wichtigsten Grundsätze der DSGVO in je einem Satz."),
};
Console.Write("[Assistent]: ");
await foreach (var chunk in chatClient.CompleteChatStreamingAsync(messages, CancellationToken.None))
{
    Console.Write(chunk.Choices[0].Message.Content);
}
Console.WriteLine();

// Modell entladen wenn fertig
await model.UnloadAsync();

Was passiert hier unter der Haube?

1. CreateAsync — Sucht die lokale Foundry-Local-Installation und startet den Inference-Service, falls er noch nicht läuft. Erwartet einen ILogger — hier nutzen wir NullLogger.Instance für die Demo.
2. GetModelAsync — Wählt automatisch die beste Modellvariante für die vorhandene Hardware (NPU > GPU > CPU)
3. DownloadAsync — Lädt das Modell beim ersten Aufruf herunter, danach wird der lokale Cache genutzt
4. LoadAsync — Lädt das Modell in den Inference-Service
5. CompleteChatStreamingAsync — Streamt die Antwort Token für Token (erwartet einen CancellationToken)

Das Schöne daran: Kein manuelles Hardware-Management, kein Model-Format-Chaos. Das SDK abstrahiert das alles weg.

Mit dem OpenAI SDK arbeiten

Da Foundry Local eine OpenAI-kompatible API bereitstellt, können wir auch direkt das OpenAI SDK nutzen. Das ist besonders relevant für Teams, die bereits Azure OpenAI im Einsatz haben — der Code sieht fast identisch aus:

dotnet add package OpenAI

using System.ClientModel;
using Microsoft.AI.Foundry.Local;
using Microsoft.Extensions.Logging.Abstractions;
using OpenAI;
using OpenAI.Chat;

// Foundry Local starten und Modell laden
var alias = "phi-4-mini";
var config = new Configuration
{
    AppName = "foundry_local_demo",
    Web = new Configuration.WebService { Urls = "http://127.0.0.1:0" },
};
await FoundryLocalManager.CreateAsync(config, NullLogger.Instance);
var manager = FoundryLocalManager.Instance;

var catalog = await manager.GetCatalogAsync();
var model = await catalog.GetModelAsync(alias);
await model.DownloadAsync();
await model.LoadAsync();

// Webservice starten (OpenAI-kompatible REST-API)
await manager.StartWebServiceAsync();
var baseUri = new Uri(manager.Urls[0]);
var endpoint = new Uri(baseUri, "v1/");

// OpenAI SDK mit dem lokalen Endpoint verbinden
var credential = new ApiKeyCredential("unused");
var options = new OpenAIClientOptions { Endpoint = endpoint };
var client = new OpenAIClient(credential, options);
var chatClient = client.GetChatClient(model.Id);

// Streaming-Completion
var updates = chatClient.CompleteChatStreaming("Erkläre Federated Learning in drei Sätzen.");
Console.Write("[Assistent]: ");
foreach (var update in updates)
{
    if (update.ContentUpdate.Count > 0)
    {
        Console.Write(update.ContentUpdate[0].Text);
    }
}
Console.WriteLine();

// Aufräumen
await model.UnloadAsync();

Der entscheidende Punkt: StartWebServiceAsync startet einen lokalen HTTP-Endpoint mit OpenAI-kompatibler REST-API. Dasselbe ChatClient-Interface, dieselben Methoden — nur dass alles auf dem eigenen Gerät läuft, ohne dass ein einziges Byte das Netzwerk verlässt.

Der Hybrid-Ansatz: Lokal als Fallback, Cloud für komplexe Aufgaben

Hier wird es richtig spannend. In der Praxis wollen wir oft nicht nur lokal oder nur in der Cloud arbeiten. Der eleganteste Ansatz: Foundry Local als Standard für den Alltag, Azure OpenAI als Upgrade-Pfad für komplexe Aufgaben.

Da beide Endpoints dasselbe OpenAI-Protokoll sprechen, lässt sich das mit einer simplen Abstraktion umsetzen:

using OpenAI;
using OpenAI.Chat;
using System.ClientModel;

public class HybridAiClient
{
    private readonly ChatClient _localClient;
    private readonly ChatClient? _cloudClient;

    public HybridAiClient(
        Uri localEndpoint, string localApiKey, string localModelId,
        string? azureEndpoint = null, string? azureApiKey = null,
        string? azureModelId = null)
    {
        // Lokaler Client (Foundry Local)
        var localOptions = new OpenAIClientOptions { Endpoint = localEndpoint };
        _localClient = new OpenAIClient(
                new ApiKeyCredential(localApiKey), localOptions)
            .GetChatClient(localModelId);

        // Optionaler Cloud-Client (Azure OpenAI)
        if (azureEndpoint is not null && azureApiKey is not null)
        {
            var cloudOptions = new OpenAIClientOptions
            {
                Endpoint = new Uri(azureEndpoint)
            };
            _cloudClient = new OpenAIClient(
                    new ApiKeyCredential(azureApiKey), cloudOptions)
                .GetChatClient(azureModelId ?? "gpt-4o");
        }
    }

    public ChatClient GetClient(bool preferCloud = false)
    {
        if (preferCloud && _cloudClient is not null)
            return _cloudClient;

        return _localClient;
    }
}

Die Nutzung:

using Microsoft.AI.Foundry.Local;
using Microsoft.Extensions.Logging.Abstractions;

// Foundry Local starten
var alias = "phi-4-mini";
var config = new Configuration
{
    AppName = "foundry_local_demo",
    Web = new Configuration.WebService { Urls = "http://127.0.0.1:0" },
};
await FoundryLocalManager.CreateAsync(config, NullLogger.Instance);
var manager = FoundryLocalManager.Instance;

var catalog = await manager.GetCatalogAsync();
var model = await catalog.GetModelAsync(alias);
await model.DownloadAsync();
await model.LoadAsync();

await manager.StartWebServiceAsync();
var baseUri = new Uri(manager.Urls[0]);
var localEndpoint = new Uri(baseUri, "v1/");

// Hybrid-Client erstellen
var hybrid = new HybridAiClient(
    localEndpoint: localEndpoint,
    localApiKey: "unused",
    localModelId: model.Id,
    azureEndpoint: Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT"),
    azureApiKey: Environment.GetEnvironmentVariable("AZURE_OPENAI_KEY"),
    azureModelId: "gpt-4o"
);

// Einfache Aufgabe → lokal
var localClient = hybrid.GetClient(preferCloud: false);
var localResult = localClient.CompleteChat("Fasse diesen Absatz in einem Satz zusammen: ...");
Console.WriteLine(localResult.Value.Content[0].Text);

// Komplexe Aufgabe → Cloud (wenn verfügbar, sonst Fallback auf lokal)
var cloudClient = hybrid.GetClient(preferCloud: true);
var cloudResult = cloudClient.CompleteChat("Analysiere diesen 50-seitigen Vertrag auf Risiken...");
Console.WriteLine(cloudResult.Value.Content[0].Text);

Die Entscheidungslogik, wann lokal und wann Cloud genutzt wird, hängt vom Use Case ab:

• Einfache Aufgaben (Zusammenfassungen, Klassifikation, Q&A) → Foundry Local
• Komplexe Aufgaben (lange Dokumente, Agenten, mehrsprachige Analyse) → Azure OpenAI
• Sensible Daten (Patientendaten, Finanzdaten, Personaldaten) → Immer Foundry Local
• Offline oder Cloud nicht erreichbar → Automatisches Fallback auf Foundry Local

Das Entscheidende: Der gesamte Application Code arbeitet gegen dasselbe Interface. Ob die Antwort vom lokalen Phi-4-mini oder von GPT-4o aus der Azure Cloud kommt, ist für den restlichen Code transparent.

DSGVO: Warum “Daten bleiben in der EU” manchmal nicht reicht

Ich höre es in fast jedem Kundengespräch: “Wir nutzen Azure in der Region West Europe, also sind wir DSGVO-konform.” Das ist… nicht ganz falsch, aber auch nicht die ganze Wahrheit.

Die DSGVO unterscheidet mehrere Dimensionen:

1. Datenresidenz — Wo werden die Daten gespeichert? (Azure EU-Regionen ✓)
2. Datenverarbeitung — Wo werden die Daten verarbeitet? (Azure EU-Regionen ✓)
3. Auftragsverarbeitung — Wer verarbeitet die Daten in unserem Auftrag? (Microsoft als Auftragsverarbeiter → AV-Vertrag nötig)
4. Technisch-organisatorische Maßnahmen — Wie werden die Daten geschützt?

Für viele Szenarien ist Azure mit entsprechendem AV-Vertrag ausreichend. Aber es gibt Fälle, in denen selbst das nicht reicht:

• Berufsgeheimnisträger (Ärzte, Anwälte, Steuerberater) — Die Weitergabe an einen Cloud-Provider kann bereits eine Verletzung des Berufsgeheimnisses darstellen (§ 203 StGB). Ob der AV-Vertrag hier ausreicht, ist rechtlich umstritten.
• Besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) — Gesundheitsdaten, biometrische Daten oder Daten über politische Meinungen erfordern besonders strenge Schutzmaßnahmen. Die Verarbeitung durch Dritte erhöht das Risiko.
• Interne Compliance-Vorgaben — Manche Unternehmen haben schlicht die Regel: “Bestimmte Daten verlassen unser Netzwerk nicht.” Punkt.
• Datenschutz-Folgenabschätzung (Art. 35 DSGVO) — Bei KI-gestützter Verarbeitung von Personendaten ist eine DSFA oft Pflicht. “Verarbeitung findet ausschließlich lokal statt” vereinfacht diese Bewertung erheblich.

Foundry Local löst diese Fälle elegant: Wenn die Daten das Gerät nie verlassen, gibt es keinen Auftragsverarbeiter, keine Datenübermittlung und keine Drittstaaten-Problematik. Das ist nicht nur compliance-freundlich — das ist eine komplett andere Risikoklasse.

Natürlich ist lokale Verarbeitung kein Allheilmittel. Die Modelle sind kleiner und weniger leistungsfähig als GPT-4o in der Cloud. Aber für viele Anwendungsfälle — Zusammenfassungen, Klassifikation, einfache Q&A, Formularverarbeitung — reicht ein gut gewähltes lokales Modell vollkommen aus. Und genau hier greift der Hybrid-Ansatz: sensible Daten lokal, alles andere in der Cloud.

Hardware-Anforderungen: NPU vs. GPU vs. CPU

Foundry Local erkennt die verfügbare Hardware automatisch und wählt den besten Ausführungspfad. Aber welche Hardware brauchen wir eigentlich? Hier eine Orientierung für die Planung:

	NPU	GPU (dediziert)	CPU (Fallback)
Typische Hardware	Intel Core Ultra, Qualcomm Snapdragon X, AMD Ryzen AI	NVIDIA RTX, AMD Radeon	Jeder x86/ARM-Prozessor
Leistung (Phi-4-mini)	~20–30 Tokens/s	~30–60 Tokens/s	~5–15 Tokens/s
Energieverbrauch	Sehr niedrig (5–15W)	Mittel bis hoch (50–150W)	Mittel (15–45W)
Bester Einsatz	Dauerbetrieb, Laptops, Energieeffizienz	Maximaler Durchsatz, Batch-Verarbeitung	Universelle Kompatibilität
Max. Modellgröße	Bis ~4B Parameter	Bis ~20B+ Parameter (VRAM-abhängig)	Bis ~4B Parameter (RAM-abhängig)
Min. RAM	8 GB	8 GB + dedizierter VRAM	8 GB (für kleine Modelle)

Für Entscheider in Kurzform:

• Neubeschaffung steht an? → Geräte mit NPU bevorzugen (Intel Core Ultra, Snapdragon X). Die NPU-Beschleunigung macht KI-Workloads im Hintergrund möglich, ohne dass der Laptop zum Raumheizer wird.
• Bestehende Flotte mit NVIDIA GPUs? → Beste Performance. CUDA-Beschleunigung holt das Maximum aus den Modellen. Hier lohnt sich auch GPT-OSS-20B.
• Ältere Hardware ohne NPU/GPU? → Geht trotzdem. Foundry Local läuft nachweislich auf Intel 8th-Gen-PCs mit 8 GB RAM. Langsamer, aber funktional. Hier sind kompakte Modelle wie Qwen 2.5 0.5B oder Phi-4-mini die richtige Wahl.

Ressourcen

• Foundry Local auf GitHub — Quellcode, Samples und Dokumentation
• Building AI Apps with the Foundry Local C# SDK — Offizieller Einführungspost zum .NET SDK
• Run local AI on any PC or Mac — Microsoft Foundry Local — Video-Walkthrough mit Hardware-Demos auf verschiedenen Geräten

---

Foundry Local ist kein Ersatz für Azure OpenAI. Es ist eine Ergänzung — und für bestimmte Szenarien die einzige Option, die wirklich funktioniert. Die Kombination aus lokaler Inference für sensible Daten und Cloud-Power für komplexe Aufgaben ist der pragmatische Weg, KI auch in regulierten Branchen nutzbar zu machen.

Die Installation dauert zwei Minuten. Ein erstes Proof-of-Concept mit bestehendem .NET-Code einen Nachmittag. Die Compliance-Diskussion mit dem Datenschutzbeauftragten wird danach deutlich entspannter.

Update: Code für .NET 10 angepasst.