Windows on kenji.blog

Microsoft.Windows.AI: Neueste API-Anwendungsfälle und Beispielcode

Fri, 11 Sep 2026 18:00:00 +0900

Microsoft.Windows.AI: Neueste API-Anwendungsfälle und Beispielcode – Die Tiefen der Windows Copilot Runtime erkunden

1. Einführung: Eine neue Ära für Windows mit nativer KI-Integration

In den letzten Jahren hat sich die KI-Technologie bemerkenswert weiterentwickelt, was zu einem schnellen Paradigmenwechsel von der Nutzung großer Sprachmodelle (LLMs) in der Cloud hin zu KI-Inferenzen auf Edge-Geräten (lokalen PCs) geführt hat. Das Herzstück dieser Entwicklung sind die von Microsoft für Windows 11 bereitgestellte “Windows Copilot Runtime” und die “Microsoft.Windows.AI”-API zu deren Steuerung.

Die Entwicklung von Anwendungen mithilfe von Cloud-APIs (wie OpenAI oder Azure OpenAI) ist zwar einfach, bringt jedoch Herausforderungen in Bezug auf Latenz, Datenschutz und laufende Kosten mit sich. Durch die lokale Ausführung von KI-Modellen können hingegen extrem latenzarme Anwendungen realisiert werden, die auch offline funktionieren, ohne dass sensible Daten das Gerät verlassen.

Dieser Artikel bietet eine äußerst detaillierte Erklärung zur Implementierung lokaler KI-Funktionen, die für die zukünftige Entwicklung von Windows-Anwendungen unerlässlich sind. Anhand praktischer Beispielcodes in C# und C++ werden Aspekte von der Architektur bis hin zum Performance-Tuning umfassend behandelt. Wir gehen dabei tief auf technische Details ein, wie die Nutzung der zugrunde liegenden Hardware (NPU und GPU) und die Integration mit DirectML, anstatt nur API-Aufrufe zu demonstrieren.

2. Windows Copilot Runtime und der Architekturüberblick

Die Windows Copilot Runtime ist ein KI-Stack, der so konzipiert ist, dass Entwickler KI-Modelle problemlos in Windows integrieren und gleichzeitig die beste Leistung erzielen können. Diese Laufzeitumgebung abstrahiert die Hardwarebeschleunigung auf Betriebssystemebene und bietet Entwicklern eine einheitliche Schnittstelle.

graph TD App["Windows-Anwendung (C# / C++)"] --> API["Microsoft.Windows.AI APIs"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (OS-Schicht)"] WCR --> SLM["Lokale Modelle (Phi-Silica, etc.)"] ORT --> DML["DirectML Execution Provider"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Neural Processing Unit)"] DXCore --> GPU["GPU (Graphics Processing Unit)"] DXCore --> CPU["CPU"]

Wie das obige Architekturdiagramm zeigt, können Anwendungen über die High-Level-API Microsoft.Windows.AI direkt auf Small Language Models (SLMs wie Phi-Silica) zugreifen, die im Betriebssystem integriert sind. Bei der Verwendung benutzerdefinierter Modelle ist es zudem möglich, die Hardwarebeschleunigung explizit über die ONNX Runtime und DirectML zu nutzen. Da die Betriebssystemschicht die Verteilung der Arbeitslast auf CPU, GPU und NPU optimiert, können Entwickler hochleistungsfähige KI-Anwendungen erstellen, ohne sich tiefgreifend um Hardwareunterschiede kümmern zu müssen.

3. Hardwarebeschleunigung und mathematische Bewertung der NPU

Die neuesten Copilot+ PCs sind mit NPUs (Neural Processing Units) ausgestattet, Prozessoren, die speziell auf KI-Verarbeitung zugeschnitten sind. Die Leistung von NPUs wird im Allgemeinen in TOPS (Tera Operations Per Second) gemessen.

Bei der Inferenz von KI-Modellen bestimmt insbesondere die Rechenleistung bei der Matrixmultiplikation (GEMM: General Matrix Multiply) den Durchsatz. Die theoretische maximale Leistung der Hardware $P_{\text{peak}}$ kann mit der folgenden Formel geschätzt werden:

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

Hierbei ist:

$f$ die Taktfrequenz der NPU (Hz)
$N_{\text{cores}}$ die Anzahl der Kerne in der NPU
$N_{\text{MACs/core}}$ die Anzahl der MAC-Einheiten (Multiply-Accumulate) pro Kern
Die abschließende $2$ steht dafür, dass eine MAC-Operation als zwei Operationen (Multiplikation und Addition, FLOPs/OPs) gezählt wird.

Für eine NPU mit einer Frequenz von 1,5 GHz, 4 Kernen und 4096 MACs pro Kern ergibt sich beispielsweise:

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

Dies zeigt mathematisch, dass die Leistung die Anforderung von 40 TOPS für Copilot+ PCs in Windows 11 erfüllt.

Darüber hinaus ist die Inferenz von KI-Modellen, insbesondere von LLMs (Dekodierungsphase), oft speichergebunden (Memory-Bound). Die theoretische Bandbreite des Systemspeichers $BW$ wird wie folgt berechnet:

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

Bei LPDDR5x-8533-Speicher ($f_{\text{mem}} = 8533 \text{ MT/s}$) und einem 128-Bit-Bus ($W_{\text{bus}} = 128$) beträgt die Bandbreite etwa $136 \text{ GB/s}$. Bei der Optimierung von KI-Anwendungen ist es entscheidend, wie diese Bandbreite eingespart werden kann, weshalb die später erläuterte Modellquantisierung (Quantization) unerlässlich ist.

4. Einrichtung der Entwicklungsumgebung

Um die neuesten Windows AI APIs zu nutzen, müssen folgende Umgebung und Toolchains eingerichtet werden:

OS: Windows 11 Version 24H2 oder neuer (Geräte mit NPU, die die Anforderungen für Copilot+ PCs erfüllen, werden dringend empfohlen)
SDK: Windows App SDK (Version 1.5 oder neuer mit KI-Erweiterungsunterstützung)
Entwicklungsumgebung: Visual Studio 2022 (v17.10 oder neuer), Workloads für native C++-Entwicklung und .NET-Desktopentwicklung
Pakete: Installation von Microsoft.Windows.AI und Microsoft.ML.OnnxRuntime.DirectML über NuGet

1
2
3
4
5
6


<!-- Beispiel für die .csproj-Konfiguration -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. 【Deep Dive 1】Nutzung lokaler Sprachmodelle (Phi-Silica) mit C#

Die Windows Copilot Runtime enthält als standardmäßige Betriebssystemkomponente das von Microsoft entwickelte, hocheffiziente kleine Sprachmodell “Phi-Silica”. Dadurch wird eine fortschrittliche Verarbeitung natürlicher Sprache (Zusammenfassung von Texten, Codegenerierung, Chatbots) in Offline-Umgebungen ermöglicht, ohne dass gigabytegroße Modelle aus dem Netzwerk heruntergeladen werden müssen.

Im Folgenden finden Sie einen fortgeschrittenen Beispielcode in C#, der den Namensraum Microsoft.Windows.AI.Generative verwendet, um eine Chat-KI zu erstellen. Er unterstützt Streaming-Antworten und generiert Text in Echtzeit, ohne den UI-Thread zu blockieren.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// Initialisiert das Sprachmodell. Überprüft die Verfügbarkeit der NPU und lädt das Modell auf das optimale Gerät.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("Systemanforderungen und Verfügbarkeit des lokalen KI-Modells (Phi-Silica) werden überprüft...");

 // Überprüfen, ob das Modell auf dem System verfügbar ist (falls nicht unterstützt, kann ein Download angefordert werden)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"Das lokale KI-Modell ist derzeit nicht verfügbar. Status: {availability}");
 }

 // Erstellen der Modellinstanz (Zu diesem Zeitpunkt erfolgen das Mapping in den Speicher und die NPU-Initialisierung)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("Initialisierung des Sprachmodells abgeschlossen. Hardwarebeschleunigung über DirectML ist aktiv.");
 }

 /// <summary>
 /// Nimmt die Benutzereingabe (Prompt) entgegen und generiert die Antwort als Stream.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[Benutzereingabe]: {prompt}\n[KI-Assistent]: ");

 // Hyperparameter für die Generierung festlegen
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // Aufbau des Konversationskontexts
 var context = new LanguageModelContext();
 context.AddSystemMessage("Du bist ein hochentwickelter KI-Assistent, der direkt auf der lokalen NPU von Windows läuft. Denke logisch Schritt für Schritt und antworte prägnant.");
 context.AddUserMessage(prompt);

 try
 {
 // Aufruf der Streaming-Inferenz-API
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // Asynchrones Iterieren über die Chunks, die als IAsyncEnumerable zurückgegeben werden
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // Generierte Token (Chunks) in Echtzeit in der Konsole ausgeben
 // In einer UI-Anwendung würde hier der DispatcherQueue verwendet werden, um z. B. eine TextBox zu aktualisieren
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[Generierung wurde vom Benutzer oder System abgebrochen]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[Ein schwerwiegender Fehler ist aufgetreten: {ex.Message}]");
 }
 }
 }
}

5.1 Architektur-Erklärung der C#-Implementierung

Der Kern dieses Codes liegt in der Vorabprüfung durch LanguageModel.CheckAvailabilityAsync() und dem asynchronen Streaming durch GenerateResponseStreamAsync. Wenn die im Hintergrund des Betriebssystems laufende Copilot Runtime diesen API-Aufruf empfängt, startet sie intern die ONNX Runtime und wählt den optimalen Execution Provider (bei vielen modernen PCs DirectML + NPU) basierend auf der Systemkonfiguration aus.

Entwickler können modernste KI-Inferenzpipelines mit nur wenigen Zeilen C#-Code in ihre Anwendungen integrieren, ohne sich um die Tensorform des Modells, die Implementierung des Tokenizers oder die Speicherverwaltung des KV-Caches kümmern zu müssen.

6. 【Deep Dive 2】Schnelle Inferenz benutzerdefinierter Modelle mit C++ und DirectML

Bei der Arbeit mit spezifischen Domänen (wie etwa eigene Bildsegmentierung, Spracherkennung oder benutzerdefinierte Objekterkennungsmodelle), die von den standardmäßigen Sprachmodellen des Betriebssystems nicht abgedeckt werden, müssen Entwickler direkt mit der ONNX Runtime und DirectML interagieren, die in den unteren Schichten von Microsoft.Windows.AI angesiedelt sind.

Durch die Verwendung von C++ kann die Speicherzuweisung extrem optimiert werden, um die Spitzenleistung der NPU/GPU abzurufen. Im Folgenden sehen Sie eine Kernimplementierung einer fortschrittlichen Initialisierungs- und Inferenzpipeline für die Ausführung eines benutzerdefinierten Modells im ONNX-Format (z. B. YOLOv8) mit DirectML in C++.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // Optimierung der Thread-Anzahl
 sessionOptions.SetIntraOpNumThreads(1);
 // Maximale Graphenoptimierungsstufe festlegen
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. Hinzufügen des DirectML Execution Providers (DML EP)
 // device_id = 0 ist der vom System empfohlene Standardadapter (NPU oder Hochleistungs-GPU)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] DirectML Execution Provider wurde erfolgreich angehängt." << std::endl;
 } else {
 std::cerr << "[Warning] DirectML API konnte nicht abgerufen werden. Ausführung im CPU-Fallback-Modus." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. Laden des Modells und Erstellen der Session
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] ONNX-Modell erfolgreich geladen und Berechnungsgraph kompiliert." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] Fehler beim Laden des Modells: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. Puffer für den Eingabetensor erstellen
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. Dynamisches Abrufen der Ein- und Ausgabeknotennamen
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. Inferenz ausführen (wird über DirectML an die NPU/GPU ausgelagert)
 std::cout << "[Info] Ausführung der Inferenz-Engine gestartet..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. Ergebnistensor abrufen und analysieren
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] Inferenz abgeschlossen: " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] Anzahl der Elemente im Ausgabetensor: " << outputSize << std::endl;
 // * Anschließend werden NMS (Non-Maximum Suppression) oder das Zeichnen von Bounding-Boxen für den Ausgabetensor implementiert
 }
};

int main() {
 try {
 // Pfad zum auszuführenden ONNX-Modell
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // Dummy-Bilddaten für die Inferenz (Batch-Größe 1 x 3 Kanäle x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "Das Programm wurde unerwartet beendet: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 Die Bedeutung von Speicherverwaltung und Zero-Copy-Inferenz in C++

Der größte Vorteil der Verwendung von DirectML in C++ ist die enge Integration mit DirectX 12 (DX12). Während der obige Code aus pädagogischen Gründen ein standardmäßiges Kopieren von Daten aus dem CPU-Speicher enthält, ist es in realen Spiel-Engines oder Videoverarbeitungsanwendungen oft der Fall, dass Bilder (Texturen) mithilfe von DX12 bereits im Speicher der GPU oder NPU vorgehalten werden.

In solchen Fällen können die erweiterten Bindungsfunktionen der OrtDmlApi genutzt werden, um DX12-Ressourcen direkt als Tensoren der ONNX Runtime abzubilden, wodurch eine “Zero-Copy Inference” (Inferenz ohne Kopiervorgänge) realisiert wird. Dadurch entfällt der Overhead der Datenübertragung über den PCIe-Bus (der Verbrauch der oben erwähnten Bandbreite $BW$) vollständig, und die Bildrate bei der Echtzeit-Videoverarbeitung wird drastisch verbessert.

7. Leistungsoptimierung und Best Practices

Im Folgenden werden unverzichtbare Optimierungsstrategien für die Entwicklung erstklassiger KI-Anwendungen unter Verwendung der Windows AI API und DirectML zusammengefasst.

7.1 Modellquantisierung (Quantization) und das Olive Toolkit

Um das wahre Potenzial der NPU zu entfalten, ist es absolut notwendig, die Gewichte und Aktivierungen von KI-Modellen von FP32 (einfache Genauigkeit) zu INT8 oder INT4 zu quantisieren (Quantization). Die NPU-Architektur ist auf Ganzzahloperationen spezialisiert und bietet mit INT8 im Vergleich zu FP32 theoretisch den vierfachen Durchsatz und massive Energieeinsparungen.

Durch die Verwendung der von Microsoft bereitgestellten Toolchain Olive (ONNX Live) können Modelle aus PyTorch und anderen Frameworks automatisch für Windows-Umgebungen optimiert werden. Olive bietet starke Unterstützung für spezielle Aufmerksamkeitsoptimierungen (Attention-Optimierungen) in Transformer-Modellen und die hardwarebezogene Kompilierung von Graphen.

7.2 Der Kompromiss: Batch-Verarbeitung vs. interaktives Streaming

Bei API-Aufrufen kann die Auslastung der NPU (Compute Utilization) durch das Zusammenfassen mehrerer Inferenzanforderungen in einer Batch-Verarbeitung (Stapelverarbeitung) erhöht werden. Bei einer interaktiven Benutzeroberfläche wie einem Chatbot bestimmt jedoch die Zeit, bis das erste Token angezeigt wird (TTFT: Time To First Token), das Benutzererlebnis (UX) mehr als der bloße Durchsatz. Daher besteht die Best Practice für interaktive UIs darin, die Batch-Größe auf 1 zu setzen und der Streaming-Generierung Vorrang zu geben.

7.3 Hintergrundaufgaben und Zusammenarbeit mit dem Betriebssystem

KI-Inferenzen verbrauchen lokal große Mengen an Strom und Systemressourcen. Durch die Integration mit der Windows App Lifecycle API wird erwartet, dass Inferenzaufgaben mit niedriger Priorität angehalten (Suspend) oder der Ressourcenverbrauch gedrosselt wird, wenn die Anwendung in den Hintergrund tritt.

sequenceDiagram participant User as "Benutzer" participant App as "Windows-Anwendung (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "NPU-Hardware" User->>App: "Prompt eingeben" App->>API: "GenerateResponseStreamAsync()" API->>OS: "Dispatch des Inferenzjobs" OS->>ORT: "Graph-Ausführungsanforderung" ORT->>NPU: "Ausführen der Befehlsliste via DirectML" NPU-->>ORT: "Berechnung abgeschlossen (1 Token generiert)" ORT-->>OS: "Tensorergebnis" OS-->>API: "Dekodierter Text" API-->>App: "IAsyncEnumerable Chunk" App-->>User: "Echtzeit-Zeichenausgabe in der UI" Note over ORT,NPU: "Diese Schleife wird schnell wiederholt, bis sie abgeschlossen ist"

Dieses Sequenzdiagramm veranschaulicht die Eleganz der asynchronen Verarbeitung, bei der Daten von der untersten NPU-Hardwareschicht bis zur Präsentationsschicht der Anwendung fließen, ohne dass der UI-Thread jemals blockiert wird.

8. Zukunftsausblick und die Evolution von Windows AI

Die Microsoft.Windows.AI-API und die Copilot Runtime entwickeln sich rasant weiter. Zukünftige Updates für Entwickler lassen folgende Paradigmenwechsel erwarten:

OS-native Integration multimodaler APIs: Nahtlose, gleichzeitige Verarbeitung nicht nur von Text, sondern auch von Audio, Bildern und sogar Live-Video-Feeds, wodurch cross-modale KI-Inferenzen standardmäßig auf OS-Ebene bereitgestellt werden.
RAG (Retrieval-Augmented Generation) auf Systemebene: Die Verknüpfung persönlicher Dokumente und des Windows-Suchindex auf dem lokalen PC mit KI-Modellen innerhalb der sicheren OS-Sandbox. Dies ermöglicht den Aufbau hochentwickelter, persönlicher KI-Assistenten, die die Privatsphäre des Benutzers vollständig wahren.
Dynamische Ressourcenskalierung der NPU: Ein Mechanismus, bei dem der Windows-Kernel-Scheduler den Ausführungskontext der NPU dynamisch umschaltet, um QoS (Quality of Service) zu gewährleisten, wenn mehrere KI-Anwendungen (z. B. Rauschunterdrückung im Hintergrund und Codegenerierung im Vordergrund) gleichzeitig ausgeführt werden.

9. Fazit: Die Zukunft von Anwendungen durch lokale KI

Die Copilot Runtime in Windows 11 und die Microsoft.Windows.AI-API haben allen Windows-Entwicklern die extrem mächtige Waffe der “lokalen KI” an die Hand gegeben. Es besteht keine absolute Abhängigkeit mehr von Cloud-APIs. Sie können den Benutzern KI-Erlebnisse der nächsten Generation bieten, die Latenzen eliminieren, den Datenschutz strikt wahren und auch offline vollständig funktionieren.

Nutzen Sie das Wissen aus diesem Artikel – von der Integration standardmäßiger Sprachmodelle des Betriebssystems mit C# über mathematische Leistungsbewertungen bis hin zu extremer Hardwareoptimierung mithilfe von C++ und DirectML –, um eigenhändig “KI-native” Windows-Anwendungen der nächsten Generation zu erschaffen. Die unbegrenzten Möglichkeiten, die KI bietet, liegen direkt vor dem Code, den Sie schreiben.

Hinweis: Dieser Artikel basiert auf den Preview-APIs und den neuesten Spezifikationen mit Stand September 2026. Da sich API-Spezifikationen und Hardwareanforderungen aufgrund von Windows-Updates ändern können, konsultieren Sie bei der Implementierung immer auch die offizielle Dokumentation von Microsoft Learn.

【2026 Aktuell】Der ultimative Leitfaden zur Ausführung von lokalen LLMs unter Windows

Fri, 11 Sep 2026 10:00:00 +0900

1. Einführung: Warum gerade jetzt lokale LLMs unter Windows?

Im Jahr 2026 hat die Entwicklung generativer KI und großer Sprachmodelle (LLMs) einen gewaltigen Paradigmenwechsel vollzogen – von riesigen API-Diensten in der Cloud hin zu “lokalen LLMs”, die auf privaten PCs oder in On-Premise-Umgebungen laufen. Cloud-KIs wie GPT-5 von OpenAI und Claude 3.5 von Anthropic sind extrem leistungsstark, aber Unternehmen und Privatpersonen können nicht all ihre Daten in die Cloud senden. Aus Gründen des Datenschutzes, der Sicherheit, der Latenzzeit sowie der langfristigen und nachhaltigen Kosten ist die Nachfrage nach lokalen LLMs so explosionsartig gestiegen wie nie zuvor.

Besonders im Windows-Umfeld ist die Entwicklung des Ökosystems für lokale LLMs bemerkenswert. Noch vor einigen Jahren galt “KI-Entwicklung und -Ausführung gleich Linux” als gängige Regel, doch im Jahr 2026 hat sich Windows zu einer äußerst leistungsstarken und zugänglichen KI-Plattform gewandelt.

In diesem Artikel bieten wir einen vollständigen Leitfaden zur Einrichtung, zum Betrieb und zur Optimierung lokaler LLMs in einer Windows-Umgebung, basierend auf den neuesten Technologietrends von 2026. Von der einfachen Einrichtung für Anfänger mit Ollama über die extreme Optimierung für Fortgeschrittene mithilfe von llama.cpp bis hin zu tiefergehenden mathematischen Ansätzen zur VRAM-Berechnung, dem Verständnis der Architektur und lokalem Fine-Tuning – wir erklären alles ausführlich und in gewaltigem Umfang.

1.1 Technologietrends rund um lokale LLMs im Jahr 2026

Die wichtigsten Trends, die das aktuelle Ökosystem für lokale LLMs prägen, sind:

Vollständige Verbreitung des GGUF-Formats: GGUF (GPT-Generated Unified Format), das Metadaten und Tensoren in einer einzigen Datei vereint, hat sich vollständig als De-facto-Standard etabliert. Dadurch genügt es, eine einzige Datei von Hugging Face herunterzuladen, um sie in beliebigen Umgebungen auszuführen.
Demokratisierung der MoE-Architektur (Mixture of Experts): Es wurden zahlreiche kleine, aber leistungsstarke MoE-Modelle veröffentlicht. Indem während der Inferenz nur ein Teil der Experten aktiviert wird, erreichen sie die Leistung riesiger Modelle, während die Rechenlast für Consumer-PCs gering gehalten wird.
Fortgeschrittene Abstraktion und Optimierung von Inferenz-Engines: Tools wie Ollama, LM Studio und AnythingLLM wurden so verfeinert, dass sich der Benutzer nicht mehr um komplexe Abhängigkeiten wie die Installation von CUDA-Treibern kümmern muss. Zudem hat die native Windows-Unterstützung von FlashAttention 3 die Inferenzgeschwindigkeit drastisch erhöht.
Nutzung von NPUs und der Aufstieg von Windows Copilot+ PCs: Die Technologie zur Ausführung kleiner LLMs (SLM: Small Language Models) mit geringem Stromverbrauch unter Nutzung der verbauten NPU (Neural Processing Unit) hat auch bei Laptops ohne GPU die Praxisreife erreicht.

2. Hardwareanforderungen und OS-Vorbereitung

Um ein lokales LLM mit praktikabler Geschwindigkeit (15 bis 30 Token pro Sekunde oder mehr) auszuführen, ist die Wahl der Hardware von entscheidender Bedeutung.

2.1 Empfohlene Hardwarekonfiguration

Mit der Weiterentwicklung von AI-PCs haben sich auch die Spezifikationsanforderungen geändert.

OS: Windows 11 Pro (24H2 oder neuer). Zwingend erforderlich für die volle Funktionalität von WSL2, erweitertes Speichermanagement sowie die Nutzung der neuesten APIs von DirectML.
CPU: Intel Core Ultra 200 Serie oder neuer, bzw. AMD Ryzen 9000 Serie oder neuer. Bei gleichzeitiger Nutzung der CPU-Inferenz ist eine hohe Speicherbandbreite unerlässlich.
RAM: Mindestens 32 GB, empfohlen 64 GB oder mehr. Die Bandbreite des Hauptspeichers (MB/s) wird zum entscheidenden Flaschenhals bei CPU-Inferenz oder Offloading. Schneller DDR5-6000 Speicher oder höher ist ideal.
GPU: NVIDIA RTX 4000/5000 Serie. Bei lokalen LLMs ist nicht die Rechenleistung, sondern die “VRAM-Kapazität” das Wichtigste.
- Einsteiger: RTX 4060 Ti (16GB-Version) - Bestes Preis-Leistungs-Verhältnis. Ideal für Modelle der 8B- bis 14B-Klasse.
- Mittelklasse: RTX 4070 Ti SUPER (16GB) / RTX 4080 SUPER (16GB)
- High-End: RTX 4090 (24GB) / RTX 5090 (32GB) - Erforderlich für die Ausführung quantisierter Modelle der 30B- bis 70B-Klasse.
Speicher: PCIe Gen4 oder Gen5 NVMe SSD. Reduziert die Ladezeiten für zig Gigabyte große Modelle drastisch.

2.2 Einrichtung von WSL2 (Windows Subsystem for Linux 2)

Viele GUI-Tools laufen nativ unter Windows, aber für die Python-Entwicklung, das Kompilieren neuester Tools und das spätere LoRA-Fine-Tuning ist WSL2 äußerst praktisch. In den neuesten Windows 11-Umgebungen muss lediglich der NVIDIA-Treiber auf dem Host installiert werden, um die GPU (CUDA) transparent aus WSL2 heraus nutzen zu können.

Öffnen Sie PowerShell mit Administratorrechten und führen Sie Folgendes aus:

1
2
3
4
5


# Installation von WSL2 und dem neuesten Ubuntu
wsl --install -d Ubuntu-24.04

# Kernel-Update
wsl --update

Führen Sie nach der Installation nvidia-smi im WSL2-Terminal aus. Wenn die GPU korrekt erkannt wird, war die Einrichtung erfolgreich.

3. Architektur lokaler LLMs und Inferenzmechanismus

Das Verständnis der internen Struktur, wie ein Modell in einer lokalen Umgebung Text generiert, ist für die Fehlerbehebung und Optimierung äußerst nützlich.

Das folgende Mermaid-Diagramm zeigt eine typische Inferenz-Pipeline eines lokalen LLMs.

graph TD User["Benutzereingabe (Prompt)"] --> Tokenizer["Tokenizer (Tokenizer)"] Tokenizer --> Embedding["Embedding-Schicht (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["Selbst-Aufmerksamkeit (Self-Attention)"] Attn --> KVCache["KV-Cache (Key/Value-Erhalt)"] Attn --> FFN["Feed-Forward-Netzwerk (FFN)"] end FFN --> Logits["Logit-Berechnung (Logits)"] Logits --> Sampler["Sampler (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["Ausgabe-Token"] OutputToken --> |"Autoregressive Generierung"| Tokenizer OutputToken --> Decoder["Detokenizer (Detokenizer)"] Decoder --> FinalOutput["Finaler Ausgabetext"]

3.1 Zwei Phasen: Prefill und Decode

Die Textgenerierung bei LLMs unterteilt sich in zwei Phasen mit unterschiedlichen Berechnungseigenschaften.

Prefill-Phase (Prompt-Verarbeitung): In dieser Phase wird der gesamte eingegebene Prompt auf einmal verarbeitet und verstanden. Da parallele Berechnungen möglich sind, steht die Rechenleistung der GPU (FLOPS) in direktem Zusammenhang mit der Geschwindigkeit. Bei langen Prompts kann diese Phase mehrere Sekunden dauern.
Decode-Phase (Token-Generierung): In dieser Phase wird iterativ ein Token vorhergesagt und als nächste Eingabe zurückgeführt (autoregressiv). Da hier parallele Berechnungen eingeschränkt sind, wird die VRAM-Bandbreite (Memory Bandwidth) der GPU zum entscheidenden Flaschenhals.

4. Berechnung des VRAM-Verbrauchs und mathematisches Verständnis der Modellgröße

Um richtig einschätzen zu können, “welches Modell auf meinem PC läuft”, muss man die Berechnungsformel für den VRAM verstehen. Ein Fallback auf den Systemspeicher (RAM) aufgrund von VRAM-Mangel macht die Inferenzgeschwindigkeit 10- bis 100-mal langsamer.

4.1 Basis-VRAM basierend auf der Parametergröße

Dies ist die Speichermenge, die benötigt wird, um die Gewichte (Weights) des Modells in den VRAM zu laden. Sie wird anhand der Modellgröße $P$ (Anzahl der Parameter, Einheit: 1 Milliarde = 1B) und der Anzahl der Bytes pro Parameter $B$ berechnet.

$$ V_{base} = P \times B \quad \text{(GB)} $$

Wenn Sie beispielsweise ein 8B (8 Milliarden) Parameter-Modell in FP16 (Halbgenauigkeits-Gleitkommazahl, 16 Bit = 2 Byte) laden:

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

Das bedeutet, selbst wenn Ihre GPU 16 GB VRAM hat, ist allein durch das Laden des Modells das Limit fast erreicht.

4.2 Die Magie der Quantisierung (Quantization)

Hier kommt die “Quantisierung” ins Spiel. Durch Verringern der Parametergenauigkeit wird die Modellgröße drastisch reduziert. Bei der gängigsten 4-Bit-Quantisierung (z. B. Q4_K_M) beträgt ein Parameter im Durchschnitt etwa 0,55 Byte.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

Dadurch können Sie mit 16 GB VRAM problemlos ein 8B-Modell mit ausreichend Spielraum ausführen.

4.3 Berechnung des KV-Caches (GQA-unterstützte Version)

Während der Inferenz verbraucht der “KV-Cache”, der den bisherigen Kontext speichert, VRAM. In neuesten Modellen wie Llama 3 wird GQA (Grouped Query Attention) eingesetzt, um Speicher zu sparen.

Der Verbrauch des KV-Caches $V_{kv}$ (in Gigabyte) lässt sich durch folgende Formel darstellen:

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

Vereinfacht ausgedrückt, kann es mithilfe der Anzahl der Key- und Value-Köpfe $h_{kv}$ einfach berechnet werden:

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

Hierbei ist:

$b$: Batch-Größe (bei lokaler Einzelnutzung meist 1)
$s$: Sequenzlänge (Kontextlänge, z. B. 8192)
$l$: Anzahl der Schichten (Layer, z. B. 32)
$h_{kv}$: Anzahl der KV-Köpfe (KV-Heads, z. B. 8)
$d$: Dimensionalität pro Kopf (z. B. 128)
$B_{kv}$: Bytegröße des KV-Caches (2 für FP16)

Berechnungsbeispiel (Llama 3 8B, Kontext 8192, FP16 Cache): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

Beachten Sie, dass der erforderliche VRAM linear ansteigt, je länger die Kontextlänge $s$ gewählt wird.

5. Praxis 1: Schnellstes und kürzestes Setup mit Ollama

Da wir nun die Theorie verstehen, lassen Sie uns ein LLM tatsächlich in einer Windows-Umgebung ausführen. Im Jahr 2026 ist das benutzerfreundlichste Tool “Ollama”. Es bietet ein Docker-ähnliches, intuitives CLI.

5.1 Installation und Ausführung

Laden Sie den Windows-Installer von der offiziellen Ollama-Website herunter und führen Sie ihn aus.
Öffnen Sie PowerShell und geben Sie den folgenden Befehl ein. Hier verwenden wir das japanischsprachige llama3:8b.

1

ollama run llama3:8b

Beim ersten Ausführen wird das Modell heruntergeladen. Sobald dies abgeschlossen ist, können Sie direkt im Terminal chatten.

5.2 Erstellen einer benutzerdefinierten KI mit Modelfile

Sie können ganz einfach eine KI mit einer bestimmten Persona erstellen. Erstellen Sie ein Modelfile an einem beliebigen Ort.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
Sie sind ein hervorragender Senior-Software-Ingenieur.
Beantworten Sie Benutzerfragen stets mit Codebeispielen, logisch und präzise.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

Erstellen und starten Sie Ihr eigenes Modell mit den folgenden Befehlen:

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 Nutzung über externe Apps (KI-Editoren)

Ollama stellt einen OpenAI-kompatiblen API-Endpunkt unter http://localhost:11434 zur Verfügung. Indem Sie diese URL in den Backend-Einstellungen von VS-Code-Erweiterungen wie Cursor oder Continue.dev angeben und als Modellnamen z.B. SeniorDev festlegen, erhalten Sie kostenlos einen leistungsstarken lokalen Coding-Assistenten.

6. Praxis 2: Extreme Leistungsoptimierung mit llama.cpp

Wenn Sie feinkörnige Speicherverwaltung wünschen oder die neuesten Formate (wie EXL2 oder IQ-Quantisierung) schnell ausprobieren möchten, steuern Sie die Kern-Engine llama.cpp direkt.

6.1 Schritte zum Kompilieren von llama.cpp

In einer Windows-Umgebung ist es am besten, mithilfe von CUDA Toolkit und CMake aus dem Quellcode zu kompilieren.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# Für CUDA konfigurieren und kompilieren
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 Fortgeschrittener Start im Server-Modus

Verwenden Sie die kompilierte llama-server.exe, um das Modell zu hosten.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: Verlagert so viele Layer wie möglich auf den GPU VRAM.
--flash-attn: Aktiviert FlashAttention 3, um die Inferenzgeschwindigkeit zu erhöhen und den VRAM-Verbrauch des KV-Caches zu senken.

7. GUI-Frontends: LM Studio und Aufbau lokaler RAGs

Wenn Sie die Kommandozeile meiden möchten oder RAG (Retrieval-Augmented Generation) intuitiv umsetzen wollen, nutzen Sie eine GUI.

7.1 LM Studio

LM Studio ist eine fantastische Anwendung, die Modellsuche, Download, Überprüfung der Systemanforderungen und eine Chat-UI in einem vereint. Durch einfaches Klicken auf den Button “Local Server” in der App wird eine OpenAI-kompatible API gestartet.

7.2 RAG-Architektur mit AnythingLLM

Hier ist das Architekturdiagramm einer RAG-Umgebung zum Einlesen interner Dokumente oder privater Notizen.

graph LR Document["Dokument (PDF, MD)"] --> Chunking["Chunk-Aufteilung"] Chunking --> EmbedModel["Embedding-Modell"] EmbedModel --> VectorDB["Vektordatenbank"] UserQuery["Benutzeranfrage"] --> EmbedQuery["Anfrage-Embedding"] EmbedQuery --> VectorDB VectorDB --> |"Ähnlichkeitssuche"| RetrievedDocs["Extrahierte relevante Dokumente"] UserQuery --> PromptBuilder["Prompt-Generierung"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["Lokales LLM"] LocalLLM --> Answer["Finale Antwort"]

Mit der Desktop-Version von AnythingLLM (für Windows) können Sie diese Architektur in wenigen Minuten aufbauen, indem Sie in den Einstellungen Ollama (für LLM und Embedding) auswählen und eine lokale Vektor-DB (LanceDB) festlegen. Dies ist die Geburtsstunde einer privaten KI, die keinerlei Daten nach außen sendet.

8. Fine-Tuning (LoRA) auf Windows WSL2

Wenn Sie Modelle nicht nur lokal ausführen, sondern mit Ihren eigenen Daten intelligenter machen wollen, ist ein Fine-Tuning mit LoRA (Low-Rank Adaptation) möglich. Im Jahr 2026 können Sie mit der Bibliothek “Unsloth” in einer Windows WSL2-Umgebung das Training eines 8B-Modells mit 16 GB VRAM in wenigen Stunden abschließen.

Richten Sie die Umgebung ein, indem Sie Folgendes in WSL2 Ubuntu ausführen:

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth optimiert CUDA-Kernel bis zum Äußersten, verdoppelt die Trainingsgeschwindigkeit im Vergleich zu Standard-Hugging-Face-Bibliotheken und halbiert den VRAM-Verbrauch. Starten Sie einfach ein Jupyter Notebook, laden Sie Ihren Datensatz (im JSONL-Format) ein, und schon ist ein Training über mehrere Epochen selbst auf einer RTX 4060 Ti mit 12 GB bis 16 GB VRAM möglich.

9. Leistungs-Fehlerbehebung (Troubleshooting)

Häufig auftretende Probleme und deren Lösungen.

1. Inferenzgeschwindigkeit ist extrem langsam (1-2 tokens/s)

Ursache: Das Modell passt nicht in den VRAM und wird auf den Systemspeicher (RAM) ausgelagert. Lösung: Überprüfen Sie den “Dedizierten GPU-Speicher” im Task-Manager. Wenn das Limit erreicht ist, verringern Sie die Kontextgröße (-c) oder verwenden Sie ein quantisiertes Modell mit niedrigerer Bitrate (z. B. Q4_K_M).

2. “CUDA out of memory” Fehler

Ursache: Der VRAM ist vollständig erschöpft. Tritt besonders dann auf, wenn der Dialog lang wird und der KV-Cache anwächst. Lösung: Begrenzen Sie bewusst die Werte für num_ctx bei Ollama oder -c bei llama.cpp.

3. Japanische (oder eine andere) Generierung ist seltsam

Ursache: Falsches Prompt-Template oder inkompatibles Modell. Lösung: Verwenden Sie Modelle, die Instruct im Namen tragen, und stellen Sie sicher, dass das vom Modellautor angegebene korrekte Template (wie ChatML oder Llama3-Format) im Tool ausgewählt ist.

10. Zusammenfassung und zukünftige Aussichten

Im Jahr 2026 ist der Aufbau lokaler LLMs unter Windows kein Privileg mehr für eine kleine Gruppe von Ingenieuren. Durch den De-facto-Standard des GGUF-Formats, das Erscheinen ausgereifter Ökosysteme wie Ollama und LM Studio und Hardware-Optimierungen wie FlashAttention kann heute jeder ganz einfach eine KI-Umgebung auf Unternehmensniveau einrichten.

Bitte nutzen Sie die in diesem Artikel erläuterten Punkte:

Wählen Sie durch mathematische VRAM-Berechnungen logisch die optimale Modellgröße und Quantisierungsstufe für die Spezifikationen Ihres PCs aus.
Bauen Sie mit Ollama in kürzester Zeit eine Umgebung auf und steigern Sie die Produktivität drastisch durch die Integration mit einem KI-Editor.
Holen Sie durch erweiterte Parametersteuerung mit llama.cpp die maximale Leistung aus Ihrer Hardware heraus.
Errichten Sie mit AnythingLLM ein sicheres lokales RAG-System, das auch vertrauliche Daten verarbeiten kann.
Nutzen Sie Unsloth (WSL2), um Ihre eigene benutzerdefinierte KI mit Fachwissen zu trainieren.

Die “Demokratisierung” der KI ist nicht länger nur ein Schlagwort, sondern ein reales System, das auf Ihrem Windows-Desktop läuft. Befreien Sie sich von Cloud-API-Kosten sowie Risiken von Informationslecks und treten Sie noch heute in die freie und mächtige Welt der privaten KI ein.