AI 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.

Python nicht nötig! Ich habe eine AI-Inferenz-Engine nur mit C++ aufgebaut

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

1. Einleitung: Warum Python aufgeben und eine KI-Inferenz-Engine in C++ schreiben?

In der modernen KI-Entwicklung ist Python der De-facto-Standard. Dank leistungsstarker Frameworks wie PyTorch und TensorFlow können komplexe neuronale Netze mit nur wenigen Codezeilen aufgebaut, trainiert und für die Inferenz genutzt werden. Hinter den Kulissen dieser Frameworks übernehmen jedoch Low-Level-Sprachen wie C++ und CUDA die rechenintensiven Aufgaben. Python fungiert hier lediglich als “Klebstoff” (Glue).

Warum sollte man also Python explizit ausschließen und eine KI-Inferenz-Engine ausschließlich mit C++ erstellen? Dafür gibt es einige triftige Gründe:

Extreme Leistung und niedrige Latenz: Der Overhead durch Pythons GIL (Global Interpreter Lock) und die dynamische Typisierung kann vollständig eliminiert werden. Besonders bei Systemen, die Echtzeitfähigkeit erfordern, können Verzögerungen im Millisekundenbereich fatal sein.
Einfaches Deployment: Der Aufbau einer Python-Umgebung (riesige Bibliotheken, Abhängigkeitshölle) auf dem System des Endbenutzers ist äußerst schwierig. Mit C++ reicht es aus, eine einzige statisch verlinkte ausführbare Binärdatei (.exe oder ELF-Binärdatei) zu verteilen.
Unterstützung für Edge-Geräte: In ressourcenbeschränkten Umgebungen wie Smartphones, eingebetteten Geräten oder dem Raspberry Pi gibt es keinen Spielraum, um eine Python-Laufzeitumgebung auszuführen, die mehrere Gigabyte an Speicher verbraucht.
Direkte Hardwaresteuerung: Low-Level-Steuerungen wie das Timing der Speicherzuweisung, die explizite Nutzung von SIMD-Befehlen und die Optimierung des Speichertransfers mit der GPU sind mit C++ möglich.

In diesem Artikel werden wir den Prozess des Aufbaus einer Inferenz-Engine für Large Language Models (LLMs) und andere Modelle komplett von Grund auf in C++ tiefgreifend und technisch erklären, stark inspiriert von der Architektur der Bibliothek “GGML”, die von Georgi Gerganov entwickelt wurde.

2. Gesamtarchitektur der Inferenz-Engine

KI-Inferenzprozesse sind im Wesentlichen “eine Reihe gigantischer Matrixberechnungen”. Um diese effizient auszuführen, muss eine Inferenz-Engine aus den folgenden Komponenten bestehen:

graph TD A["Eingabedaten (Tokens/Bilder)"] --> B["Tensor-Management"] B --> C["Berechnungsgraph (DAG)"] C --> D["Memory Arena & Allocator"] C --> E["Scheduler & Thread-Pool"] E --> F["CPU-Backend (AVX2/ARM NEON)"] E --> G["GPU-Backend (CUDA/Metal)"] F --> H["Ausgabeergebnisse"] G --> H

Tensor-Management: Verwaltet mehrdimensionale Array-Datenstrukturen und die Strides pro Dimension.
Berechnungsgraph (Computation Graph): Repräsentiert die Operationen jeder Schicht des neuronalen Netzes als gerichteten azyklischen Graphen (DAG).
Memory Arena: Ein Mechanismus zur vorab allokierten Speicherverwaltung, um den Overhead der dynamischen Speicherzuweisung (malloc oder new) zu vermeiden.
Backend: Für bestimmte Hardware wie CPU oder GPU optimierte Implementierungen der Operationen (Kernel).

Wir werden diese Komponenten unter Verwendung der mächtigen Funktionen von C++ (Templates, Zeigerarithmetik, RAII usw.) zusammensetzen.

3. Das Geheimnis der Speicherverwaltung: Memory Arena und SIMD-Alignment

Die Speicherverwaltung in einer Inferenz-Engine ist einer der wichtigsten Faktoren, der sich direkt auf die Leistung auswirkt. Während der Inferenz, insbesondere beim Durchlaufen der einzelnen Schichten eines Transformer-Modells, wird eine enorme Anzahl von Zwischen-Tensoren generiert. Wenn diese jedes Mal mit dem standardmäßigen malloc zugewiesen und freigegeben werden, führt dies aufgrund von Heap-Fragmentierung und OS-Kontextwechseln zu massiven Leistungseinbußen.

Daher verwenden wir den Ansatz einer “Memory Arena”. Bei dieser Methode wird die maximale Speichermenge, die zu Beginn der Inferenz benötigt wird, berechnet (oder vorgegeben) und auf einmal zugewiesen. Der Speicher wird dann einfach durch das Inkrementieren eines Zeigers reserviert.

3.1 Die Bedeutung des Alignments

Moderne CPUs unterstützen SIMD-Befehle (Single Instruction, Multiple Data), wie AVX2/AVX-512 von Intel/AMD oder NEON von ARM. Diese Befehle verarbeiten 256 Bit (32 Byte) oder 512 Bit (64 Byte) Daten auf einmal, erfordern aber, dass der zu verarbeitende Datenspeicher an bestimmten Byte-Grenzen (normalerweise 32 Byte oder 64 Byte) ausgerichtet (aligned) ist.

Hier ist ein C++-Implementierungsbeispiel für eine Memory Arena, die das Alignment berücksichtigt.

 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


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // Bei POSIX-Systemen posix_memalign verwenden, bei Windows _aligned_malloc
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // Berechnung des Alignments (Bestimmung des Paddings)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // Speicherfreigabe erfolgt nur durch Rücksetzen des Zeigers (O(1))
 }
};

Auf diese Weise wird der Speicher beim Erstellen von Tensoren immer über diese Arena zugewiesen. Durch einfaches Aufrufen von reset() am Ende jedes Inferenzschritts (z. B. nach jeder Token-Generierung) kann der Speicher sofort wiederverwendet werden.

4. Tensor-Datenstrukturen und die Magie des Strides

Ein Tensor ist ein generalisiertes Konzept von Skalaren, Vektoren und Matrizen. Bei der Implementierung ist es wichtig, das Konzept des “Strides” zu berücksichtigen, das es ermöglicht, die eigentlichen Daten, die als eindimensionales fortlaufendes Array im Speicher liegen, als mehrdimensional zu interpretieren.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // Für Quantisierung
 INT4 // Für Quantisierung
};

struct Tensor {
 int n_dims; // Anzahl der Dimensionen
 int64_t ne[4]; // Anzahl der Elemente pro Dimension (Number of Elements)
 size_t nb[4]; // Stride pro Dimension (Number of Bytes)
 DataType type; // Datentyp
 void* data; // Zeiger auf die Nutzdaten (Payload)

 // Für den Berechnungsgraphen
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

Der Stride nb[i] repräsentiert den Byte-Abstand im Speicher zwischen benachbarten Elementen in der Dimension i. Zum Beispiel sieht der Stride für eine Matrix mit $M \times N$ Elementen (FP32, 4 Bytes pro Element), die in Row-Major-Reihenfolge (zeilenweise) gespeichert ist, wie folgt aus:

nb[0] = 4 (Bytes): Bewegung in Spaltenrichtung
nb[1] = $N \times 4$ (Bytes): Bewegung in Zeilenrichtung

Durch die Nutzung dieses Konzepts können Operationen wie “Transponieren” (Transpose) oder “Ansicht” (View) durchgeführt werden, ohne Speicher zu kopieren, indem man lediglich die Stride-Werte austauscht. Das ist sehr elegant und schnell.

5. Aufbau des Berechnungsgraphen (DAG) und Lazy Evaluation

Ähnlich wie PyTorch verwendet auch unsere Inferenz-Engine eine verzögerte Auswertung (Lazy Evaluation), die dem “Define-by-Run”-Konzept ähnelt. Das bedeutet, dass zum Zeitpunkt des Aufrufs einer mathematischen Funktion keine Berechnungen durchgeführt werden, sondern nur der Graph (die Abhängigkeiten zwischen den Knoten) aufgebaut wird.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b ist meistens transponiert
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Der Ablauf des Inferenzprozesses ist wie folgt:

graph LR A["Tensoren definieren"] --> B["Graph über Ops erstellen"] B --> C["Topologische Sortierung"] C --> D["Speicher für Ausgaben reservieren"] D --> E["Knoten der Reihe nach ausführen"]

Bei der Auswertung des Graphen (Vorwärtspass) wird eine topologische Sortierung verwendet, um Knoten ohne Abhängigkeiten nacheinander auszuführen. Da wir bei reiner Inferenz keine Gradienten für die Backpropagation speichern müssen, bleibt die Speicherverwaltung sehr einfach.

6. Der Kern von Mathematik und Optimierung: Matrixmultiplikation (GEMM)

Mehr als 90 % der Rechenleistung bei der KI-Inferenz werden für Matrixmultiplikationen (GEMM: General Matrix Multiply) aufgewendet. Der Kern von Transformer-Modellen, der Attention-Mechanismus und das Feed-Forward Network (FFN), sind letztlich gigantische Matrixmultiplikationen.

Das Produkt $C = A B$ (Größe $M \times N$) von zwei Matrizen $A$ (Größe $M \times K$) und $B$ (Größe $K \times N$) wird mathematisch wie folgt ausgedrückt:

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

Wenn dies mit einer naiven dreifachen Schleife implementiert wird, treten häufig Cache-Misses auf, und es wird kaum Leistung erbracht.

6.1 Cache-Blocking auf der CPU und SIMD-Optimierung

Die grundlegende Strategie zur Beschleunigung von GEMM auf der CPU sieht folgendermaßen aus:

Loop-Tiling (Cache-Blocking): Die Matrix wird in kleine Blöcke unterteilt, die in den L1/L2-Cache passen, und blockweise berechnet.
Daten-Packing: Daten werden intern neu angeordnet, um kontinuierliche Speicherzugriffsmuster zu gewährleisten.
Nutzung von SIMD: Durch die Verwendung von FMA-Befehlen (Fused Multiply-Add) wie _mm512_fmadd_ps in AVX-512 können in einem einzigen Taktzyklus viele Multiplikations-Additions-Operationen durchgeführt werden.

Hier ist ein Beispiel für ein vereinfachtes Vektor-Skalarprodukt (Dot Product) unter Verwendung von C++ und SIMD Intrinsics.

 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


#include <immintrin.h> // Für AVX-Befehle

// Schnelles FP32-Skalarprodukt mit AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // Verarbeite 8 Elemente auf einmal (256 Bit = 32 Byte = 8 * 4 Byte)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // FMA-Befehl: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // Horizontale Addition der Werte im SIMD-Register
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // Verarbeitung des Rests
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

Schon dieser kleine Trick kann im Vergleich zu einer naiven Implementierung zu einer mehrfachen bis zu über zehnfachen Geschwindigkeitssteigerung führen.

7. Hardwaregrenzen überwinden: Integration von CUDA- und Metal-Backends

Eine reine C++-Implementierung läuft auf der CPU zwar einigermaßen gut, aber um riesige Modelle wie LLMs mit praktischer Geschwindigkeit auszuführen (z. B. mehr als 20 Tokens pro Sekunde), ist die parallele Rechenleistung einer GPU unerlässlich. Daher führen wir eine Backend-Abstraktionsschicht in unsere Engine ein.

7.1 Backend-Abstraktion

Wir nutzen den C++-Polymorphismus, um die Ausführungseinheit (Executor) für die Berechnungen wechseln zu können.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // Ausführung verschiedener Operationen
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 Implementierung des NVIDIA CUDA-Backends

Um NVIDIA-GPUs zu nutzen, implementieren wir das Backend mit CUDA-C++-Erweiterungen. Obwohl es möglich ist, eigene Kernel zu schreiben, ist es bei Matrixmultiplikationen am besten, “cuBLAS”, die erstklassige Bibliothek von NVIDIA, zu verwenden.

 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


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // Bei CUDA ist Column-Major der Standard, daher muss man auf die Parameter achten
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // src1 wird als transponiert vorausgesetzt

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

Da die Datenübertragung (cudaMemcpy) zwischen CUDA-Speicher und Host-(CPU)-Speicher sehr ressourcenintensiv ist, ist es wichtig, die Engine so zu entwerfen, dass alle Gewichte (Gewichtstensoren) und Zwischentensoren während der Inferenz so weit wie möglich im VRAM verbleiben.

7.3 Apple Silicon (Metal) Backend

In den letzten Jahren haben sich Macs mit M1/M2/M3-Chips (Apple Silicon) als hervorragende Maschinen für die KI-Inferenz erwiesen. Der Grund dafür ist der “Unified Memory”. Da sich CPU und GPU denselben Speicherbereich teilen, entfallen die teuren Host-Device-Speichertransfers über den PCIe-Bus, wie sie bei CUDA erforderlich sind, komplett.

Um Metal von C++ aus aufzurufen, verwendet man entweder Objective-C++ (.mm-Dateien) als Brücke oder die Bibliothek metal-cpp. Kernel werden mithilfe von Metal Compute-Shadern (in .metal-Dateien C++-ähnlich geschrieben) implementiert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Metal-Shader (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // Vereinfacht
 }
 C[row * n + col] = sum;
 }
}

In Apple Silicon-Umgebungen steht auch eine optimierte Bibliothek für Matrixmultiplikationen namens MPS (Metal Performance Shaders) zur Verfügung. Wenn man diese in der Praxis nutzt, lassen sich beeindruckende Inferenzgeschwindigkeiten erzielen.

8. Spezifische Verarbeitung für Transformer-Modelle: Attention und KV-Cache

Hochmoderne LLMs wie LLaMA 2/3 oder GPT basieren auf der Transformer-Architektur. Um dies in C++ zu implementieren, ist es unerlässlich, die “Scaled Dot-Product Attention”, ausgedrückt durch folgende mathematische Formel, aufzubauen:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Zudem müssen bei der autoregressiven Token-Generierung die Berechnungsergebnisse (Key und Value) vergangener Tokens aufbewahrt werden. Dies nennt man “KV-Cache (Key-Value Cache)”.

graph TD T["Aktuelles Token"] --> Q["Query"] T --> K["Key"] T --> V["Value"] K --> KCache["An KV-Cache anhängen"] V --> VCache["An KV-Cache anhängen"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["Skalieren (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["Kontextvektor"]

Auch für den KV-Cache wird der Speicher im Voraus reserviert. Dies erfolgt ähnlich wie bei einem Ringpuffer, indem man in der Arena Platz für die maximale Kontextlänge (z. B. 4096 oder 8192 Tokens) allokiert. Dadurch können Neuallokationen bei jedem Generierungsschritt vermieden werden.

Für die Positionscodierung (Positional Encoding) implementieren wir “RoPE (Rotary Position Embedding)”, was sich in den letzten Jahren durchgesetzt hat. Dies ist eine Methode, bei der Positionsinformationen als Rotationsvektoren im komplexen Raum eingebettet werden. Die Optimierung der Aufrufe von sin- und cos-Funktionen in C++ (z. B. durch Look-up-Tabellen) ist hier der Schlüssel zur Leistung.

9. Extreme Optimierung durch Modellquantisierung (Quantization)

Wenn ein großes Modell (beispielsweise ein LLaMA-Modell mit 7 Milliarden Parametern) als FP32 (32-Bit-Fließkommazahl) geladen wird, verbrauchen allein die Gewichte etwa 28 GB Speicher (VRAM). Nimmt man den KV-Cache und die Inferenzpuffer hinzu, übersteigt der Verbrauch leicht 30 GB, was eine Ausführung auf normalen Consumer-GPUs unmöglich macht.

Hier kommt die “Quantisierung (Quantization)” ins Spiel. Sie ist auch die wahre Stärke des GGML-Formats.

Bei der Quantisierung wird die Genauigkeit der Gewichte bewusst verringert.

FP16 (16-bit): Größe halbiert. Nahezu kein Genauigkeitsverlust.
INT8 (8-bit): Ein Viertel der Größe. Leichte Verschlechterung.
INT4 (4-bit): Ein Achtel der Größe. Bei Verwendung von eigenem Blocking und Skalierungsfaktoren ist eine praktische Inferenz möglich.

Auf der Seite der Inferenz-Engine werden die als INT4 (oder INT8) komprimierten Gewichte aus dem Speicher gelesen und unmittelbar nach dem Laden in die CPU- oder GPU-Register auf FP16 oder FP32 entpackt (dequantisiert), bevor die Berechnung erfolgt.

Erstaunlicherweise ist es schneller, das aus dem Speicher gelesene Datenvolumen zu reduzieren, selbst wenn dies die Berechnungsmenge erhöht. Dies liegt daran, dass bei moderner Hardware der Engpass bei Inferenzaufgaben nicht in der “Rechenleistung (Compute Bound)”, sondern in der “Speicherbandbreite (Memory Bandwidth Bound)” liegt. Mit einer in C++ implementierten Engine, die INT4-Quantisierung nutzt, ist es möglich, lokale LLMs selbst auf einem MacBook Air mit 8 GB VRAM flüssig auszuführen.

10. Performance-Tuning: NUMA-Architektur und Thread-Pools

Bei der Inferenz auf einer CPU ist Multithreading unerlässlich. Es ist jedoch nicht optimal, einfach viele std::threads zu starten.

In modernen Multi-Socket-Servern oder High-End-CPUs wie dem Ryzen Threadripper wird eine NUMA (Non-Uniform Memory Access)-Architektur verwendet. Der Zugriff auf physisch nahegelegenen Speicher (lokalen Speicher) von einem bestimmten CPU-Kern aus ist schnell, während der Zugriff auf Speicher, der mit einem anderen Prozessor verbunden ist, extrem langsam ist.

Fortgeschrittene C++-Inferenz-Engines nutzen die folgenden Techniken:

Thread-Pinning: Jeder Thread wird an einen bestimmten CPU-Kern gebunden (Festlegen der Affinity), um zu verhindern, dass Caches durch Kontextwechsel verworfen werden.
NUMA-Aware Allocation: Der Speicher wird auf demselben NUMA-Knoten zugewiesen wie der Thread, der die Daten verarbeitet.
Work-Stealing Thread-Pool: Implementierung eines effizienten Schedulers, der jeden Knoten des Berechnungsgraphen in kleinere Aufgaben unterteilt. Freie Threads “stehlen” sich dann automatisch Aufgaben und führen diese aus.

Indem man all dies einsetzt, kann die CPU-Auslastung konstant nahe an 100 % gehalten und ein Durchsatz erreicht werden, der nah am theoretischen Maximum liegt.

11. Fazit: Der Spaß daran, KI mit C++-“Muskeln” anzutreiben

Python ist zweifellos praktisch. In der Forschung, Entwicklung und beim Prototyping gibt es keine Sprache, die an seine Produktivität heranreicht. Wenn man jedoch in die Phase übergeht, in der man ein fertiges Modell “in der realen Welt, effizient und auf jedem Gerät ausführen” möchte, schlägt die Stunde von C++.

Das Erfolgserlebnis, das man verspürt, wenn die eigens entwickelte Inferenz-Engine – erschaffen durch das direkte Manipulieren von Speicher-Bytefolgen, das Ausreizen von Registern durch SIMD-Befehle und den Kampf mit der VRAM-Bandbreite der GPU – nacheinander natürliche japanische (oder deutsche) Text-Tokens in der Konsole generiert, bietet eine “reine Ingenieursfreude”, die man beim Aufrufen von model.generate() in einem Python-Framework niemals erleben wird.

KI-Technologie neigt dazu, eine “Black Box” zu sein. Doch indem man von Tensor-Operationen bis hin zur Speicherverwaltung alles selbst in C++ schreibt, kann man ein tiefes Verständnis für die wahren Mechanismen erlangen und begreifen, wie ein LLM “denkt”.

Wenn Sie über Grundkenntnisse in C++ verfügen und ein starkes Interesse an der aktuellen KI-Technologie haben, sollten Sie unbedingt versuchen, eine eigene Inferenz-Engine zu entwickeln. Die Quellcodes von GGML und llama.cpp werden Ihnen dabei als die besten “lebenden Lehrbücher” dienen.

Also, lassen Sie die schwere Python-Laufzeitumgebung hinter sich und treiben Sie modernste KI mit den Muskeln von C++ an!

Wie man TinyLLaMA in einer On-Premises-Umgebung am schnellsten feinabstimmt

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

1. Einführung: Warum gerade jetzt TinyLLaMA und On-Premises?

Die Entwicklung von Large Language Models (LLM) schreitet mit enormer Geschwindigkeit voran, und dementsprechend wächst auch die Anzahl der Modellparameter stetig in die Hunderte von Milliarden. Während gigantische Modelle wie GPT-4 und Claude 3 eine beispiellose Leistung aufweisen, stellen die Rechenkosten für Inferenz und Training sowie Sicherheits- und Datenschutzbedenken bei der Nutzung externer APIs große Hürden für Unternehmen dar. Insbesondere in Geschäftsbereichen, die mit hochsensiblen internen Daten oder persönlichen Informationen umgehen, ist das Senden von Daten an öffentliche LLM-APIs in der Cloud aus Compliance-Gründen (wie DSGVO oder APPI) oft nicht zulässig.

Daher rücken Small Language Models (SLM) und der lokale Betrieb in On-Premises-Umgebungen ins Rampenlicht. Unter diesen zeichnet sich “TinyLLaMA” durch seine kompakte Größe von nur 1,1B (1,1 Milliarden) Parametern aus, während es mit einem riesigen Datensatz von etwa 3 Billionen Token vortrainiert wurde. Es zeigt im Vergleich zu Modellen derselben Klasse eine erstaunliche Leistung.

Dieser Artikel bietet einen vollständigen Leitfaden, wie Sie TinyLLaMA in einer On-Premises-Umgebung (lokaler Server oder Workstation) “am schnellsten und effizientesten” für Ihre eigenen spezifischen Aufgaben feinabstimmen (Fine-Tuning) können. Wir werden alles umfassend abdecken, von den mathematischen Grundlagen über die neuesten Optimierungstechnologien bis hin zum konkreten PyTorch-Implementierungscode.

2. Architektur und Eigenschaften von TinyLLaMA

TinyLLaMA folgt der von Meta entwickelten LLaMA (Large Language Model Meta AI)-Architektur. Obwohl die Anzahl der Parameter auf 1,1B begrenzt ist, verwendet es denselben Technologie-Stack wie LLaMA 2, was zu einer extrem hohen Ökosystem-Kompatibilität führt.

Hauptkomponenten der Architektur

RMSNorm (Root Mean Square Normalization): Eine Normalisierungsmethode, die die Subtraktion des Mittelwerts aus der herkömmlichen LayerNorm-Berechnung weglässt und so die Recheneffizienz verbessert. Sie erhöht den Durchsatz, während die Stabilität des Trainings erhalten bleibt.
SwiGLU-Aktivierungsfunktion: Im Feed Forward Network (FFN) wird SwiGLU anstelle von herkömmlichem ReLU oder GELU verwendet. Dies wird mathematisch wie folgt ausgedrückt: $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Hierbei steht $\otimes$ für das elementweise Produkt (Hadamard-Produkt) und die Swish-Funktion ist $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Dadurch wird die Ausdruckskraft deutlich erhöht.
RoPE (Rotary Position Embedding): Eine Methode, die die Vorteile von absoluter und relativer Positionskodierung kombiniert. Sie bietet eine hohe Generalisierungsleistung, auch wenn die Sequenzlänge erweitert wird.
Grouped Query Attention (GQA): Ein Ansatz, der zwischen Multi-Head Attention (MHA) und Multi-Query Attention (MQA) liegt. Durch die Gruppierung von Key- und Value-Heads wird Speicherbandbreite gespart und die Inferenzgeschwindigkeit drastisch verbessert.

Das folgende Mermaid-Diagramm zeigt den allgemeinen Datenfluss und die Struktur der Transformer-Blöcke von TinyLLaMA.

graph TD A["Eingabetext"] --> B["Tokenizer (BPE)"] B --> C["Embedding-Schicht"] C --> D["Transformer-Blöcke (x22 Schichten für TinyLLaMA)"] D --> E["RMSNorm (Final)"] E --> F["Lineare Projektion (Vokabulargröße)"] F --> G["Ausgabewahrscheinlichkeiten (Softmax)"] subgraph "Aufbau des Transformer-Blocks" D1["Eingabe Hidden State"] --> D2["RMSNorm"] D2 --> D3["Grouped Query Attention (GQA)"] D3 --> D4["Residuales Hinzufügen"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["Residuales Hinzufügen"] D7 --> D8["Ausgabe zur nächsten Schicht"] D1 -.-> D4 D4 -.-> D7 end

3. Durchbruch beim Fine-Tuning: LoRA und QLoRA

Die Feinabstimmung aller Parameter in einer On-Premises-Umgebung würde selbst für ein 1,1B-Modell Dutzende Gigabyte an VRAM (Videospeicher) verbrauchen, um die Optimizer-Zustände und Gradienten zu speichern. Um mit begrenzten Ressourcen effizient trainieren zu können, ist der Einsatz von PEFT (Parameter-Efficient Fine-Tuning)-Methoden wie “LoRA” und dessen quantisierter Erweiterung “QLoRA” unerlässlich.

3.1 Mathematischer Hintergrund von LoRA (Low-Rank Adaptation)

LoRA ist eine Methode, bei der die vortrainierte Gewichtsmatrix fixiert (eingefroren) wird und der Aktualisierungsbetrag dieser Gewichte ($\Delta W$) durch das Produkt von zwei kleinen Matrizen mit niedrigem Rang (Low-Rank) angenähert wird.

Sei das vortrainierte Gewicht $W_0 \in \mathbb{R}^{d \times k}$. Beim vollständigen Fine-Tuning wird $W_0$ selbst aktualisiert zu $W_0 + \Delta W$, aber bei LoRA wird die Aktualisierungsmatrix $\Delta W$ wie folgt zerlegt:

$$ \Delta W = B \times A $$

Hierbei sind $B \in \mathbb{R}^{d \times r}$ und $A \in \mathbb{R}^{r \times k}$, und $r$ ist ein Hyperparameter namens Rang (Rank), der ein sehr kleiner Wert ist (typischerweise 8, 16, 32 usw.), der $r \ll \min(d, k)$ erfüllt.

Die Berechnung des Vorwärtsdurchlaufs (Forward Pass) sieht wie folgt aus:

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

Im Initialzustand wird die Matrix $A$ zufällig mit einer Normalverteilung (Gauß-Verteilung) initialisiert, und die Matrix $B$ wird als Nullmatrix initialisiert. Dadurch ist $\Delta W$ zu Beginn des Trainings null, sodass das Training in einem Zustand gestartet werden kann, in dem die Ausgabe des Basismodells vollständig erhalten bleibt.

graph LR X["Eingabevektor x"] --> W0["Eingefrorenes vortrainiertes Gewicht (W_0)"] X --> A["Trainierbare LoRA-Matrix A (r x k)"] A --> B["Trainierbare LoRA-Matrix B (d x r)"] W0 --> Add["Vektoraddition"] B --> Add Add --> Y["Ausgabevektor h"]

3.2 Die Innovation von QLoRA (Quantized LoRA)

QLoRA treibt den Ansatz von LoRA weiter voran, indem das Basismodell $W_0$ in 4-Bit-Präzision (NormalFloat 4, NF4) quantisiert und in den Speicher geladen wird. Dies reduziert den VRAM-Verbrauch drastisch.

In QLoRA sind drei wichtige Technologien integriert:

4-bit NormalFloat (NF4) Quantisierung: Ein theoretisch optimaler Datentyp, der für normalverteilte Gewichte optimiert ist.
Double Quantization (Doppelte Quantisierung): Spart noch mehr Speicherplatz, indem die Quantisierungskonstante (Skalierungsfaktor) selbst quantisiert wird.
Paged Optimizers: Ein Mechanismus, der die Unified-Memory-Funktion von NVIDIA nutzt, um Optimizer-Statusse bei VRAM-Mangel vorübergehend in den RAM der CPU auszulagern.

Dadurch kann ein Tuning, das normalerweise 16 GB bis 24 GB VRAM benötigt, selbst auf Consumer-GPUs (wie RTX 3060 12 GB oder RTX 4070) mühelos durchgeführt werden.

4. Hardwareanforderungen und Einrichtung in der On-Premises-Umgebung

Die Hardwareanforderungen für die Feinabstimmung von TinyLLaMA (1,1B) mit QLoRA können sehr niedrig gehalten werden.

Empfohlene Hardwarespezifikationen

GPU: NVIDIA RTX 3060 (12GB), RTX 3090/4090 (24GB) oder NVIDIA A10G/A100 usw. Ein Minimum von 8 GB VRAM ist für den Betrieb ausreichend, aber 12 GB oder mehr werden empfohlen, um größere Batch-Größen zu ermöglichen.
CPU: Moderne CPU mit 8 oder mehr Kernen (Intel Core i7/i9, AMD Ryzen 7/9)
RAM: 32 GB oder mehr (Wichtig als Auslagerungsziel für den VRAM bei Verwendung von Paged Optimizers)
Speicher: NVMe SSD (Zur Beschleunigung des Ladens von Datensätzen und des Speicherns von Modellen)

Einrichtung der Softwareumgebung

Dies ist ein Einrichtungsprozess, der für eine Ubuntu 22.04 LTS-Umgebung vorgesehen ist. Python 3.10 oder höher wird verwendet.

1
2
3
4
5
6
7
8
9


# Virtuelle Umgebung erstellen und aktivieren
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# PyTorch installieren (für CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Transformer-bezogene Bibliotheken installieren
pip install transformers datasets peft trl accelerate bitsandbytes

5. Optimierungstechnologien für schnellstes Tuning

Um das Tuning nicht nur einfach durchzuführen, sondern “am schnellsten” abzuschließen, müssen die folgenden Optimierungsmethoden kombiniert werden.

5.1 Flash Attention 2

Der Standard-Attention-Mechanismus hat eine Zeit- und Raumkomplexität von $O(N^2)$ für die Sequenzlänge $N$. Flash Attention 2 optimiert die Speicherzugriffe zwischen dem SRAM der GPU und dem HBM (High Bandwidth Memory), wodurch E/A-Engpässe ohne Reduzierung der Berechnungskomplexität beseitigt werden. Dies beschleunigt das Training um ein Vielfaches und reduziert den Speicherverbrauch drastisch.

5.2 Gradient Checkpointing (Gradienten-Checkpointing)

Hierbei werden nicht alle im Vorwärtsdurchlauf (Forward Pass) berechneten Zwischenaktivierungen im VRAM gespeichert, sondern nur ein Teil davon. Diese werden dann bei Bedarf im Rückwärtsdurchlauf (Backward Pass) neu berechnet. Die Berechnungszeit erhöht sich zwar um etwa 20 %, aber der Speicherverbrauch kann drastisch gesenkt werden, was letztendlich die Einstellung größerer Batch-Größen und eine Erhöhung des Gesamtdurchsatzes ermöglicht.

5.3 Mixed Precision Training (Gemischte Genauigkeit) und Bfloat16

Um die Tensor Cores der GPU optimal zu nutzen, werden die Trainingsberechnungen in bfloat16 (Brain Floating Point) durchgeführt. Im Vergleich zu float16 ist die Bitlänge des Exponenten dieselbe wie bei float32, sodass das Risiko von Overflows und Underflows extrem gering ist, was zu einem stabileren Training führt.

6. Praxis: QLoRA Fine-Tuning Code für TinyLLaMA

Lassen Sie uns nun das PyTorch-Skript für das schnellste Tuning erläutern, das alle oben genannten Optimierungen enthält. Hier verwenden wir den SFTTrainer aus der Bibliothek trl (Transformer Reinforcement Learning) von Hugging Face.

6.1 Vorbereiten des Datensatzes und Laden des Modells

 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


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Spezifikation von Modell und Tokenizer
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. 4-Bit-Quantisierungseinstellungen für QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Berechnungen in bfloat16 durchführen
)

# 3. Laden des Modells (Flash Attention 2 aktivieren)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # Schlüssel zur maximalen Geschwindigkeit
)

# 4. Laden des Tokenizers
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Auf right setzen, um Bugs während fp16/bf16-Trainings zu vermeiden

6.2 Anwendung des LoRA-Adapters und Formatierung des Datensatzes

 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


# 5. Vorbereitung auf k-Bit-Training und Aktivierung des Gradient Checkpointings
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. LoRA-Konfiguration
peft_config = LoraConfig(
 r=16, # Rang
 lora_alpha=32, # Skalierungsfaktor
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # Die Einbeziehung aller linearen Schichten verbessert die Leistung
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Ausgabebeispiel: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Laden des Datensatzes (Hier verwenden wir als Beispiel einen japanischen Instruction-Datensatz)
# In der Praxis laden Sie z.B. private JSONL-Dateien aus der On-Premises-Umgebung
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Formatiert den String so, dass er zum ChatML-Format oder Prompt-Template passt
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Ausführung des Trainings

 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


# 8. Einstellen der Trainingsargumente
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Erhöhen, falls noch VRAM verfügbar ist
 gradient_accumulation_steps=2, # Effektive Batch-Größe = 8 * 2 = 16
 optim="paged_adamw_32bit", # VRAM-Einsparung durch Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Gemischte Genauigkeit (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 Schritte zu Testzwecken. In der Produktion durch Epochenanzahl angeben
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Starten des Trainings mit SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Anpassen an die erwartete Eingabelänge
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. Speichern des LoRA-Adapters
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. Leistungsbewertung und Fehlerbehebung

Dies sind häufig auftretende Probleme und deren Lösungen beim Training in On-Premises-Umgebungen.

OOM (Out Of Memory) tritt auf:
- Senken Sie per_device_train_batch_size auf 1.
- Erhöhen Sie gradient_accumulation_steps, um die effektive Batch-Größe beizubehalten.
- Verkürzen Sie max_seq_length von 2048 auf 1024 oder 512.
Loss sinkt nicht oder divergiert:
- Möglicherweise ist die Lernrate (learning_rate) zu hoch. Versuchen Sie, sie von 2e-4 auf etwa 5e-5 zu senken.
- Wenn Float16 anstelle von Bfloat16 verwendet wird, könnte ein Gradienten-Underflow auftreten. Stellen Sie sicher, dass bf16=True gesetzt ist.
Bei der Inferenz werden mysteriöse Zeichenketten generiert:
- Stellen Sie sicher, dass padding_side="right" korrekt eingestellt ist. Darüber hinaus muss überprüft werden, ob das Datensatzformat (Spezial-Token wie <|im_start|>) mit dem des Basismodells beim Vortraining übereinstimmt.

8. Modellbereitstellung (Deployment) nach dem Tuning

Wenn das Tuning abgeschlossen ist, wird nicht das “gesamte Basismodell” gespeichert, sondern nur der wenige MB bis Dutzende MB große “LoRA-Adapter (Differenzgewichte)”. Um eine schnelle Inferenz durchzuführen, müssen diese LoRA-Gewichte mit dem ursprünglichen Basismodell zusammengeführt (gemergt) und als einzelnes Modell exportiert werden.

Skript zum Mergen des Modells

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Laden von Modell und Adapter in FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Gewichte zusammenführen und speichern
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

Aufbau eines extrem schnellen Inferenzservers mit vLLM

Um den Inferenzdurchsatz (Tokens per second) in On-Premises-Umgebungen zu maximieren, wird dringend empfohlen, vLLM oder TGI (Text Generation Inference) anstelle der Standard-pipeline von Hugging Face zu verwenden. vLLM verwendet die PagedAttention-Technologie, um Speicherfragmentierung der GPU zu verhindern und die Verarbeitungskapazität für gleichzeitige Anfragen drastisch zu verbessern.

Das folgende Mermaid-Diagramm zeigt die Pipeline vom Training bis zur Bereitstellung auf dem Inferenzserver.

graph TD A["Rohe private Daten"] --> B["Vorverarbeitung & Formatierung (JSONL)"] B --> C["QLoRA Fine-Tuning (SFTTrainer)"] C --> D["LoRA-Adaptergewichte (.safetensors)"] D --> E["Zusammenführung mit Basis-TinyLLaMA 1,1B"] E --> F["Zusammengeführtes Modell"] F --> G["Bereitstellung über vLLM-Server"] G --> H["API-Endpunkt / UI (z. B. Chatbot)"]

Das Starten des API-Servers mit vLLM ist mit folgendem Einzelbefehl erledigt:

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Damit ist ein mit der OpenAI-API kompatibler Endpunkt in der On-Premises-Umgebung eingerichtet, wodurch die lokale KI sicher und mit hoher Geschwindigkeit genutzt werden kann.

9. Fazit

Dieser Artikel erläuterte Methoden zur schnellsten und speichereffizientesten Feinabstimmung von “TinyLLaMA”, einem Modell, das trotz seiner kompakten Größe von 1,1B Parametern eine hohe Leistung bietet, in einer On-Premises-Umgebung.

Durch LoRA / QLoRA ist ein vollwertiges LLM-Tuning auch auf Consumer-GPUs möglich.
Die Nutzung von Flash Attention 2 und Gradient Checkpointing optimiert die Trainingszeit und den VRAM-Verbrauch auf das Äußerste.
Durch die Bereitstellung mit vLLM wird auch in Produktionsumgebungen ein hoher Durchsatz erzielt.

Der lokale Betrieb von LLMs vor Ort schützt nicht nur die Datenvertraulichkeit, sondern ist auch die stärkste Waffe zum Aufbau spezialisierter KI für bestimmte Domänen (wie Recht, Medizin, interne Vorschriften usw.) zu geringen Kosten. Nutzen Sie diesen Leitfaden gerne als Referenz, um Ihr eigenes unternehmensspezifisches TinyLLaMA zu entwickeln.

Wie sollten Programmierer im KI-Zeitalter überleben?

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

Wie sollten Programmierer im KI-Zeitalter überleben? Das Ende des Codings und der Beginn eines neuen Engineerings

Im Jahr 2026 befindet sich die Softwareentwicklung in einer beispiellosen Phase des Umbruchs. Bis vor wenigen Jahren beschränkte sich das Konzept “KI schreibt Code” bestenfalls auf die Generierung von Boilerplate-Code (Standardcode) und die automatische Vervollständigung von Funktionen – als “Hilfswerkzeug” für Programmierer. Doch durch die erstaunliche Entwicklung von Large Language Models (LLMs) hat sich die Situation grundlegend geändert. Die moderne KI ist nicht mehr nur eine “schlaue Schreibmaschine”, sondern hat sich zu einem “autonomen Junior-Engineer” entwickelt: Wenn man ihr ein Anforderungsdokument gibt, ist sie in der Lage, autonom und in Sekundenschnelle ein komplettes System aufzubauen – von der Frontend- und Backend-Logik über das Datenbankschema-Design bis hin zur Einrichtung von CI/CD-Pipelines.

Wie sollten wir “Programmierer” und “Software-Ingenieure” in einem solchen Zeitalter überleben? Während der wirtschaftliche Wert des bloßen “Code-Schreibens” rapide abnimmt, werden “Coder”, die lediglich die Syntax einer bestimmten Programmiersprache kennen und mit der API eines bestimmten Frameworks vertraut sind, schnell vom Markt verdrängt.

In diesem Artikel werden wir die Überlebensstrategien für Programmierer im KI-Zeitalter aus technischen, mathematischen und philosophischen Perspektiven sehr detailliert untersuchen. Dies ist nicht nur eine Karrieredebatte, sondern eine Neudefinition der Disziplin des Software Engineerings selbst.

1. Die Geschichte der Abstraktion und die Neudefinition des “Programmierens”

Wenn wir auf die Geschichte des Software Engineerings zurückblicken, erkennen wir, dass es immer eine Geschichte der “Abstraktion” war. Wir haben stets Schichten (Layer) aufgebaut, um komplexere Systeme in einer menschenähnlicheren Sprache beschreiben zu können.

Frühe Informatiker verwendeten Lochkarten, um physische Hardware-Schalter direkt zu bedienen, und gaben dem Computer Anweisungen in Maschinensprache (einer Reihe von 0en und 1en). Später erschien die Assemblersprache, die es ermöglichte, Hardware mit menschenlesbaren Mnemonics zu steuern. Im Laufe der Zeit kamen höhere Programmiersprachen wie C und Fortran auf, denen es gelang, komplexe Hardware-Details wie Speicherverwaltung und CPU-Register zu kapseln. Moderne Sprachen wie Java, Python, Ruby und TypeScript ermöglichten es Programmierern schließlich, sich mehr darauf zu konzentrieren, “was der Computer tun soll (What)”, anstatt “wie der Computer es tun soll (How)”.

Das Aufkommen von KI (LLMs) ist der neueste und größte Paradigmenwechsel in dieser Geschichte der Abstraktion. Wenn die Evolution von Programmiersprachen das “Verbergen von Hardware” war, dann ist die Evolution von LLMs das “Verbergen von Syntax (Grammatik)”.

graph TD A["Maschinencode / Lochkarten (1940er)"] --> B["Assemblersprache (1950er)"] B --> C["Kompilierte Hochsprachen (1970er)"] C --> D["Managed / Skriptsprachen (1990er)"] D --> E["Natürliche Sprache via LLMs (2020er)"] E --> F["Autonome KI-Agenten (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

Die Zeit, in der Entwickler sich um Speicherlecks sorgen, Zeiger manipulieren oder Hunderte von Zeilen Standardcode für das Parsen von JSON schreiben mussten, ist vorbei. Die Verwendung natürlicher Sprache (wie Deutsch oder Englisch) – der für die Menschheit am höchsten abstrahierten Sprache – zur Definition von Systemen ist zum Standard des “Programmierens” im Jahr 2026 geworden.

2. Das mathematische Modell der Produktivität: Auf der Welle des exponentiellen Wachstums reiten

Lassen Sie uns die durch KI bedingte Produktivitätssteigerung quantitativ anhand eines mathematischen Modells bewerten. Die individuelle Produktivität in der traditionellen Softwareentwicklung $P_{traditional}$ konnte als lineare Kombination aus individuellem Qualifikationsniveau $S$, Domänenerfahrung $E$ und Werkzeugeffizienz $T$ modelliert werden.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

In der modernen, KI-gestützten Entwicklung wirkt die Fähigkeit der KI $A(t)$ jedoch als “starker Hebel (Multiplier)”, der die menschlichen Fähigkeiten verstärkt. Da die Fähigkeiten der KI im Laufe der Zeit $t$ exponentiell wachsen (eine KI-Version des mooreschen Gesetzes), kann die Produktivität im KI-Zeitalter $P_{AI}(t)$ durch die folgende Gleichung dargestellt werden:

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

Hierbei haben die Variablen folgende Bedeutung:

$\alpha$: Basiskoeffizient der menschlichen Produktivität
$S_{core}$: “Menschliche Kernkompetenzen”, die nicht durch KI ersetzt werden können (z.B. Architekturdesign, Verständnis von Geschäftsanforderungen, ethisches Urteilsvermögen)
$A(t)$: Absolute Leistungsfähigkeit des KI-Modells zum Zeitpunkt $t$ (Parameteranzahl, Kontextfenster, Schlussfolgerungsfähigkeit)
$\beta$: Ein Koeffizient, der angibt, wie effektiv KI-Werkzeuge genutzt werden können (Qualität des Prompt-Engineerings, Raffinesse des kollaborativen Workflows mit der KI)

Eine wichtige Erkenntnis aus dieser Formel ist: In einer Welt, in der $A(t)$ exponentiell zunimmt, haben traditionelle Fähigkeiten wie bloße Tippgeschwindigkeit oder das Auswendiglernen einer bestimmten Sprache nur noch einen sehr geringen Einfluss auf die Gesamtproduktivität. Stattdessen werden der Multiplikator $\beta$, um auf dem exponentiellen KI-Wachstum aufzubauen, und der von der KI nicht abdeckbare Bereich $S_{core}$ zu den dominierenden Faktoren, die den Marktwert eines Entwicklers bestimmen.

3. Wahrscheinlichkeit der Aufgabenautomatisierung (Probability of Automation)

Welche Aufgaben werden also automatisiert und welche bleiben in menschlicher Hand? Die Wahrscheinlichkeit $P_{auto}(T)$, dass eine bestimmte Aufgabe $T$ vollständig von einer KI automatisiert wird, lässt sich wie folgt formulieren:

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: Vorhersehbarkeit der Aufgabe (wie viele Muster in historischen Daten vorhanden sind)
$\text{Complexity}(T)$: Komplexität der Aufgabe
$\text{Context Dependency}(T)$: Stärke des “impliziten Kontexts” (domänenspezifisches Wissen oder menschliche Beziehungen), von dem die Aufgabe abhängt
$\lambda$: Technologische Fortschrittsrate der KI

Aufgaben mit hoher Vorhersehbarkeit und geringer Kontextabhängigkeit, wie das Schreiben von API-Routings oder das Erstellen einfacher CRUD-Bildschirme, haben ein $P_{auto} \approx 1$ und werden fast vollständig automatisiert. Andererseits sind Aufgaben mit extrem hoher Kontextabhängigkeit schwer zu automatisieren, wie zum Beispiel “Wie integriert man ein bestehendes Legacy-System sicher mit neuen Microservices?” oder “Wie gestaltet man einen Authentifizierungsfluss, der die Anforderungen der Rechtsabteilung erfüllt, ohne die Benutzererfahrung zu beeinträchtigen?”.

4. Rückkehr von der Syntax (Grammatik) zur Architektur (Struktur)

Eine klare Trennung zwischen dem, worin die KI gut ist, und dem, worin der Mensch gut ist, ist eine absolute Überlebensbedingung.

graph LR Sub1["Exzellenzbereiche der KI"] Sub2["Exzellenzbereiche des Menschen"] A["Codegenerierung nach Spezifikation"] --> Sub1 B["Syntaxfehler & Fehlerbehebung"] --> Sub1 C["Boilerplate / Testgenerierung"] --> Sub1 D["Log-Analyse & Mustererkennung"] --> Sub1 E["Systemarchitektur-Design"] --> Sub2 F["Lösung mehrdeutiger Anforderungen"] --> Sub2 G["Teamübergreifende Verhandlung"] --> Sub2 H["Ethisches Urteil / Verantwortung"] --> Sub2

Die KI übertrifft den Menschen bei der “lokalen Optimierung”. Wenn es um die Geschwindigkeit und Genauigkeit beim Schreiben einer einzigen Funktion, einer einzigen Klasse oder eines einzelnen Moduls geht, hat der Mensch keine Chance. Allerdings ist die KI sehr anfällig, wenn es um “globale Optimierung” oder “fehlenden Kontext (Missing Context)” geht.

Programmierer der Zukunft müssen ihre Rolle von “Code schreibenden Arbeitern” zu “Architekten, die unzählige von der KI generierte Komponenten orchestrieren” wandeln. Das gesamte System überblicken, entscheiden, wo die Grenzen von Microservices gezogen werden, wie der Kompromiss zwischen Verfügbarkeit und Konsistenz im CAP-Theorem im geschäftlichen Kontext gelöst wird, oder wie man technische Schulden kontrolliert: Dies sind hochgradig intellektuelle Aufgaben, die nur von Menschen ausgeführt werden können, die das Gesamtbild und die Geschäftsziele verstehen.

5. Anforderungsdefinition ist das “wahre Prompt-Engineering”

Der Begriff “Prompt-Engineering”, den man in letzter Zeit oft hört, wird häufig fälschlicherweise als “Hack, um die KI auszutricksen und die gewünschte Ausgabe zu erhalten” missverstanden. Das Wesen des Prompt-Engineerings in der Softwareentwicklung ist jedoch zweifellos “fortgeschrittene Anforderungsdefinition (Requirements Engineering)”.

Um der KI Anweisungen in natürlicher Sprache zu geben und sie dazu zu bringen, genau die beabsichtigte Software auszugeben, müssen die folgenden Elemente strikt verbalisiert werden:

Zweck (Why): Warum wird diese Funktion benötigt? Was ist der geschäftliche Wert?
Einschränkungen (Constraints): Leistungsanforderungen (Latenz, Durchsatz), Sicherheitsanforderungen, Kostenbeschränkungen.
Sonderfälle (Edge Cases): Fallback-Verarbeitung, wenn der Benutzer unerwartete Eingaben vornimmt.
Schnittstellen (Interfaces): Spezifikationen für die Integration in bestehende Systeme.

Aus vagen Anweisungen (Prompts) entstehen nur vage und anfällige Systeme. Die Fähigkeit, “was der Kunde wirklich wollte” tiefgehend zu erfragen, widersprüchliche Anforderungen zu ordnen und eine logisch fehlerfreie Spezifikation (Prompt) zu erstellen – das ist die stärkste “Coding-Fähigkeit” im KI-Zeitalter. Programmierer werden mehr Zeit damit verbringen, vor Notion- oder Markdown-Dateien anstatt vor Code-Editoren zu sitzen, und in Textform präzise beschreiben, wie das System idealerweise sein sollte.

6. Die überwältigende Überlegenheit von Domänenwissen (Domain Knowledge)

Da die KI auf Open-Source-Code und öffentlichen Dokumenten aus der ganzen Welt trainiert wurde, ist sie mit allgemeinen Webtechnologien und Algorithmen bestens vertraut. Es gibt jedoch Daten, auf die die KI keinen Zugriff hat: “die spezifischen Geschäftsregeln Ihres Unternehmens” und “Domänenwissen, das tief in bestimmten Branchen (wie Medizin, Finanzen, Fertigung usw.) verwurzelt ist”.

Angenommen, ein medizinisches Startup entwickelt ein System für elektronische Patientenakten. Die KI weiß “wie man mit React ein tabellarisches UI erstellt” oder “die allgemeine Datenstruktur von HL7 FHIR”. Sie hat jedoch nicht das implizite Wissen darüber gelernt, “in welcher Reihenfolge Ärzte in einer bestimmten Fachabteilung von Krankenhaus A die Patientendaten einsehen und wie eine Benutzeroberfläche gestaltet sein muss, um das Risiko von medizinischen Fehlern zu minimieren”.

In einer Welt, in der Technologie selbst zur Commodity (Massenware) wird, entsteht der wahre Wert eines Ingenieurs an der Schnittstelle von “Technologie” und “Business-Domäne”. Nicht diejenigen, die nur mit technischem Können konkurrieren, werden den zukünftigen Markt anführen, sondern diejenigen, die über tiefes Fachwissen in einer bestimmten Domäne wie Medizin, Finanzen, Logistik oder Unterhaltung verfügen und deren Herausforderungen mit dem mächtigen Werkzeug der KI lösen können.

7. Das “Trolley-Problem” der Softwareentwicklung: Wer übernimmt die Verantwortung?

Mit zunehmender Abhängigkeit von KI stehen wir vor schwerwiegenden philosophischen und ethischen Problemen. Es geht um die Frage der “Verantwortung” in der Softwareentwicklung.

Wenn von einer KI autonom generierter Code in einer Produktionsumgebung einen schweren Bug verursacht und einem Unternehmen Verluste in Millionenhöhe beschert, oder wenn er in einem lebenswichtigen medizinischen System eine Fehlfunktion auslöst – wer übernimmt dann die Verantwortung? Das Unternehmen, das das KI-Modell entwickelt hat? Oder der Ingenieur, der den Prompt eingegeben hat? Man kann eine KI weder “entlassen” noch “verhaften”.

Die Rolle des “Menschen” als Instanz, die die “rechtliche und ethische Verantwortung (Accountability)” für die Auswirkungen eines Systems auf die Gesellschaft übernimmt, wird niemals verschwinden, egal wie weit die Technologie fortschreitet. Im Gegenteil: Je mehr der Prozess der Codegenerierung zur Blackbox wird, desto größere Verantwortung trägt der Mensch als “letzter Genehmiger (Approver)” und “Überwacher (Supervisor)” für das System.

Die Überprüfung, ob die von der KI vorgeschlagene Architektur und der Code die Sicherheitsstandards erfüllen, ethisch unbedenklich sind (keine Verzerrungen/Bias enthalten) und die Compliance-Richtlinien einhalten, um letztendlich grünes Licht zu geben – dieser Akt des “Verantwortung-Übernehmens” selbst wird zu einem wichtigen Teil der Arbeit eines Ingenieurs.

8. KI-Pair-Programming und das Management der kognitiven Belastung (Cognitive Load)

In der Zusammenarbeit mit der KI verändert sich auch die Natur der “kognitiven Belastung” (Cognitive Load) des Menschen. Die kognitive Belastung beim Schreiben von Code von Grund auf ist völlig anders als die kognitive Belastung beim “Lesen und Überprüfen” von Hunderten Zeilen unbekannten, von einer KI generierten Codes.

Nach der Theorie der kognitiven Belastung aus der Psychologie erschöpft sich das Arbeitsgedächtnis des Menschen sehr schnell, wenn es komplexe Informationen verarbeiten muss, die nicht mit bestehenden Schemata (der Wissensstruktur im Kopf) übereinstimmen. Von KI generierter Code enthält manchmal hochgradige Optimierungen, auf die ein Mensch niemals kommen würde, kann aber gleichzeitig kontextignorierende “Halluzinationen” enthalten.

Um dies zu verhindern, muss der Überprüfungsprozess für die KI systematisiert werden.

sequenceDiagram participant H as "Menschlicher Ingenieur (Architekt)" participant A as "KI-Agent" participant S as "CI/CD & Testing" H->>A: "Definition strikter Anforderungen & Einschränkungen" A->>H: "Vorschlag für Architektur & Initialen Code" Note over H,A: Überprüfungsphase: Hohe kognitive Belastung H->>A: "Kritik an Designentscheidungen, Bitte um Refactoring" A->>S: "Generierung des finalen Codes & Push" S-->>H: "Automatisierte Testergebnisse & Statische Analyse" H->>H: "Finale Genehmigung & Übernahme der Verantwortung"

Der Mensch muss seine Fähigkeiten im “schnellen Lesen und sofortigen Erkennen logischer Fehler (Code Reading & Auditing)” noch stärker perfektionieren als seine Fähigkeiten im “Schreiben”. Die Bedeutung der testgetriebenen Entwicklung (TDD) nimmt im KI-Zeitalter noch weiter zu. Der Ansatz, bei dem ein Mensch oder eine andere KI strenge Testcodes schreibt, bevor die KI den eigentlichen Code schreiben darf, und die KI den Code so lange korrigieren lässt, bis er diese Tests besteht, wird sich durchsetzen.

9. Konkrete Überlebensstrategien: Was Sie ab morgen lernen sollten

Basierend auf der bisherigen Analyse präsentieren wir einen konkreten Aktionsplan, wie Programmierer im KI-Zeitalter überleben können.

Die “Grundlagen” der Technologie von Grund auf neu lernen: Die Verwendung von Frameworks kann man der KI überlassen. Ein tiefgreifendes Verständnis der Funktionsweise von Betriebssystemen, Netzwerkprotokollen (TCP/IP, HTTP/3), internen Datenbankstrukturen (B-Tree, Transaktionsisolationsstufen) sowie Datenstrukturen und Algorithmen ist jedoch absolut notwendig. Ein solides Fundament in der Informatik ist unerlässlich, um zu beurteilen, ob die Ausgabe der KI korrekt ist.
Cloud-Architekturen und verteilte Systeme meistern: Anstatt sich auf einzelnen Code zu konzentrieren, sollten Sie sich darauf fokussieren, wie Sie Cloud-Ressourcen wie AWS, GCP und Azure kombinieren können, um skalierbare Systeme aufzubauen. Verstehen Sie Konzepte von IaC (Infrastructure as Code) wie Terraform und entwickeln Sie die Fähigkeit, ganze Systeme als Code zu entwerfen.
Ein Experte für Geschäftsdomänen werden: Lernen Sie das Geschäftsmodell, die rechtlichen Rahmenbedingungen und die Verhaltenspsychologie der Benutzer in Ihrer Branche intensiv kennen. Gehen Sie über die Grenzen eines Ingenieurs hinaus und nehmen Sie eine Perspektive ein, die der eines Produktmanagers (PM) nahekommt.
Kommunikations- und Moderationsfähigkeiten verbessern: Der Prozess der Lösung von “Mehrdeutigkeiten” zwischen Menschen und der Konsensbildung kann nicht durch KI ersetzt werden. Soft Skills im Dialog mit Stakeholdern und zur Identifizierung der wahren Probleme werden zu den wertvollsten Fähigkeiten.
KI als “Kollegen” voll ausschöpfen: Anstatt sich vor der Entwicklung von KI-Werkzeugen zu fürchten, nutzen Sie sie als Ihre stärkste Waffe. Verwenden Sie im Alltag die neuesten LLMs und KI-Coding-Agenten und sammeln Sie das “implizite Wissen” darüber, wo die KI scheitert und wie Sie Prompts gestalten müssen, um die beste Leistung aus ihr herauszuholen.

Fazit: Keine Angst, reiten Sie die Welle

Die Automatisierung des Programmierens durch KI bedeutet nicht den “Tod” des Berufs des Programmierers. Vielmehr ist es eine “Renaissance”, die uns von der “unwesentlichen Arbeit” in der Softwareentwicklung befreit – wie dem Korrigieren von Tippfehlern, dem Beheben von Problemen bei der Einrichtung von Umgebungen und dem Schreiben langweiligen Boilerplate-Codes.

Historisch gesehen verbreitete sich Pessimismus über das Verschwinden von Arbeitsplätzen sowohl bei der Einführung des mechanischen Webstuhls als auch bei der Einführung von Tabellenkalkulationssoftware (Excel). In der Realität wurden jedoch durch die dramatische Steigerung der Produktivität neue Bedürfnisse geweckt und höherwertige Arbeitsplätze geschaffen. Dasselbe wird in der Welt der Software geschehen. Da Systeme “kostengünstiger erstellt werden können”, wird Software in alle Bereiche vordringen, die bisher aufgrund von unzureichender Rentabilität nicht digitalisiert wurden. Die Probleme, die Ingenieure lösen müssen (What), werden sich ins Unendliche ausweiten.

Uns Programmierern bietet sich nun die Chance, uns von handwerklichen Code-Schreibern zu “Orchesterdirigenten” zu entwickeln, die die mächtige Intelligenz der KI leiten. Anstatt aus Angst vor der technologischen Welle am Ufer zu bleiben, sollten wir sie als Erste reiten und uns auf die Reise begeben, um größere und wertvollere Systeme zu erschaffen. Das KI-Zeitalter ist die Ära, in der “Engineering” im wahrsten Sinne des Wortes beginnt.

Entwicklungsschritte für kleine KI-Modelle (wie TinyLLaMA) mit C++

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

Entwicklungsschritte für kleine KI-Modelle (wie TinyLLaMA) mit C++

In den letzten Jahren ist das Interesse an der Ausführung von Large Language Models (LLMs) in lokalen Umgebungen rasant gestiegen. Insbesondere kleine Modelle wie TinyLLaMA (1,1B Parameter) können selbst auf Edge-Geräten mit begrenzten Ressourcen oder herkömmlichen Laptops (einschließlich Windows-Umgebungen) mit praktischer Geschwindigkeit für Inferenzen genutzt werden. Während die Entwicklung hauptsächlich mit Python und PyTorch erfolgt, ist die Kombination aus C++ und „ggml“, einer C-basierten Tensor-Bibliothek, zum De-facto-Standard geworden, wenn es darum geht, die ultimative Leistung und Speichereffizienz zu erreichen.

In diesem Artikel werden wir die detaillierten Entwicklungsschritte erläutern, um eine Inferenz-Engine von Grund auf aufzubauen (oder die interne Struktur der bestehenden llama.cpp tiefgehend zu verstehen), mit der TinyLLaMA in C++ geladen und Text generiert wird.

1. Warum C++ und ggml?

In der Trainingsphase von KI ist Python mit seiner Flexibilität und seinem umfangreichen Ökosystem überwältigend im Vorteil. In der Bereitstellungs- oder „Inferenz“-Phase wird C++ jedoch aus den folgenden Gründen zu einer leistungsstarken Option.

Reduzierung von Overhead: Das Global Interpreter Lock (GIL) von Python und der Runtime-Overhead können vollständig eliminiert werden.
Speichereffizienz und Arena-Allokation: Da die Zuweisung und Freigabe von Speicher manuell gesteuert werden können, lassen sich unvorhersehbare Spitzen (Spikes) durch die Garbage Collection verhindern.
Direkter Zugriff auf die Hardware: SIMD-Intrinsics wie AVX-512, AVX2 und ARM NEON können direkt aufgerufen werden, um die Rechenleistung der CPU zu maximieren.
Keine Abhängigkeiten: ggml ist eine C/C++-Bibliothek ohne Abhängigkeiten (Zero dependencies) und kann problemlos auf Windows-Umgebungen mit MSVC kompiliert werden, solange ein Compiler vorhanden ist.

2. Gesamtbild der Architektur

Der Fluss der gesamten Inferenz-Pipeline ist im folgenden Mermaid-Diagramm dargestellt. Dies ist der Prozess vom Eingabetext des Benutzers bis zur endgültigen Generierung des nächsten Tokens.

graph TD A["Benutzereingabetext"] --> B["BPE Tokenizer"] B --> C["Token-IDs Array"] C --> D["Embedding Layer Lookup"] D --> E["Transformer Blocks"] E --> F["RMSNorm"] F --> G["LM Head Layer"] G --> H["Logits Array"] H --> I["Sampler-Modul"] I --> J["Nächste Token-ID"] J --> K["Detokenizer"] K --> L["Ausgabetext-Chunk"] J -.-> |"Zum Kontext hinzufügen"| C

Da es sich um ein autoregressives Modell handelt, wird das ausgegebene Token wieder dem Kontext hinzugefügt und als Eingabe für die Vorhersage des nächsten Tokens zyklisch verwendet (gestrichelte Linie im Diagramm).

3. Modellformat und Memory Mapping (mmap)

Das größte Hindernis beim Umgang mit den Gewichten riesiger neuronaler Netze sind Festplatten-I/O und Speicherverbrauch. In der C++-Implementierung wird dies durch Memory Mapping (mmap) gelöst.

3.1 Funktionsweise von Memory Mapping und Implementierung in Windows

Mit mmap kann der Inhalt einer Datei direkt in den virtuellen Adressraum des Prozesses abgebildet (gemappt) werden.

Zero-copy: Die Daten werden von der Festplatte direkt in den Page-Cache des Kernels geladen, ohne dass eine zusätzliche Kopie in den Userspace erfolgt.
On-Demand-Laden (Page Fault): In dem Moment, in dem die CPU tatsächlich auf diese Speicheradresse zugreift, tritt ein Page Fault (Seitenfehler) auf, und nur der benötigte Chunk (normalerweise 4 KB) wird in den physischen Speicher geladen.

In Windows-Umgebungen werden anstelle des POSIX mmap die Win32-APIs CreateFileMapping und MapViewOfFile verwendet.

sequenceDiagram participant OS["Windows OS"] participant RAM["Physischer Speicher"] participant App["C++ Anwendung"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Zeiger auf virtuelle Speicheradresse" App->>App: "Tensor-Daten am Zeiger lesen" OS->>RAM: "Page Fault / Seite von der Festplatte laden" RAM-->>App: "Daten bereit für SIMD-Berechnung"

3.2 Binäre Struktur des GGUF-Formats

Das aus Formaten wie .safetensors von Hugging Face konvertierte GGUF (GPT-Generated Unified Format) ist das ultimative Format für Inferenzen. Es verfügt über das folgende strikte binäre Layout.

Magic Bytes: 0x46554747 (GGUF).
Version: Die Versionsnummer des Formats.
Tensor Count & Metadata Count: Anzahl der Tensoren und der Metadaten-Schlüssel-Wert-Paare.
Metadata (Key-Value Pairs): Schlüssel mit Präfix für die Zeichenfolgenlänge und typisierte Werte.
Tensor Info: Name, Dimensionen, Datentyp (FP16, Q4_K usw.) jedes Tensors und die Offset-Position in der Datei.
Padding: Polsterung (Padding), die eingefügt wird, damit die Tensordaten an bestimmten Grenzen (normalerweise 32 oder 64 Byte) ausgerichtet (aligned) werden. Dies ist entscheidend für den schnellen Speicherzugriff mit SIMD-Befehlen (insbesondere AVX).
Tensor Data: Das eigentliche Array der ausgerichteten Gewichtsdaten.

4. Mathematische Grundlagen von TinyLLaMA und C++-Algorithmen

TinyLLaMA beinhaltet einige fortgeschrittene architektonische Tricks zur Effizienzsteigerung. Die mathematischen Ausdrücke zur korrekten Implementierung in C++ werden hier erläutert.

4.1 RMSNorm (Root Mean Square Normalization)

Die Rechenkosten werden reduziert, indem die Mittelwert-Zentrierung aus LayerNorm weggelassen und nur die Varianz-Skalierung durchgeführt wird.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ ist die Anzahl der Dimensionen, $\gamma$ ist der gelernte Skalierungstensor. Bei der Implementierung in C++ wird dies optimiert, indem zunächst die Summe der Quadrate des Arrays schnell mit AVX2s _mm256_fmadd_ps etc. berechnet wird und dann mit der inversen Quadratwurzel (z. B. _mm256_rsqrt_ps Befehl) multipliziert wird.

4.2 RoPE (Rotary Position Embedding)

Eine Technik, um die Positionsinformationen von Tokens als Rotation im Tensorraum anzuwenden. Es kann als Rotation auf einer komplexen Ebene betrachtet werden, wobei für benachbarte Dimensionspaare $(x_1, x_2)$ des Vektors $x$ die folgende Rotation angewendet wird.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Hier ist $m$ der absolute Positionsindex des Tokens und $\theta$ die vorberechnete Grundfrequenz. In ggml wird es parallel ausgeführt, indem einfach der ggml_rope-Operator während der Konstruktion des Inferenzgraphen hinzugefügt wird.

4.3 Grouped-Query Attention (GQA)

Bei der normalen Multi-Head Attention (MHA) gibt es die gleiche Anzahl von Heads für Query, Key und Value. TinyLLaMA verwendet jedoch Grouped-Query Attention (GQA), um die Speicherbandbreite und den KV-Cache-Verbrauch drastisch zu reduzieren.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

Bei GQA teilen sich mehrere Query-Heads einen Key/Value-Head. In der C++-Implementierung ist es erforderlich, den KV-Tensor so zu broadcasten (zu replizieren), dass er der Anzahl der Queries entspricht, bevor die Matrixmultiplikation ggml_mul_mat ausgeführt wird.

4.4 SwiGLU-Aktivierungsfunktion

Im Feed-Forward Network (FFN)-Layer wird anstelle von GELU SwiGLU verwendet.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

Im Berechnungsgraphen wird dies durch eine Kombination aus dem ggml_silu-Operator und ggml_mul dargestellt.

5. Konstruktion des Berechnungsgraphen mit ggml und Speicherverwaltung

ggml verfolgt einen „Define-and-Run“-Ansatz, bei dem ein statischer Berechnungsgraph für die Inferenz konstruiert und anschließend evaluiert wird.

5.1 ggml_context und Arena-Allocator

Die einzigartigste Eigenschaft von ggml ist die „Arena-Allokation“, bei der in der Inferenzschleife keinerlei dynamische Speicherzuweisungen (malloc oder new) stattfinden. Bei der Initialisierung wird ein riesiger zusammenhängender Speicherbereich (die Arena) reserviert, und bei jedem Aufruf von z. B. ggml_new_tensor wird der Zeiger dieses Bereichs inkrementiert. Sobald ein Inferenzschritt abgeschlossen ist, wird der Allokationszeiger einfach auf seine Ausgangsposition zurückgesetzt, wodurch die Speicherzuweisung für den nächsten Inferenzschritt sofort abgeschlossen ist.

5.2 Konkretes Beispiel für die Konstruktion eines Graphen

Für jeden Inferenzschritt wird der folgende Berechnungsgraph im Speicher aufgebaut.

graph TD A["Eingabe-Token-ID"] --> B["Embed Lookup"] B --> C["ggml_rms_norm"] C --> D["Q / K / V Projektionen"] D --> E["ggml_rope Positional"] E --> F["KV Cache Speichern"] E --> G["KV Cache Laden"] G --> H["Self Attention"] H --> I["Skalierung & Softmax"] I --> J["Attention Ausgabe"] J --> K["Out Projektion"] K --> L["Residual Hinzufügen"]

6. Quantisierung (Quantization) und Windows / SIMD-Optimierung

Wenn TinyLLaMA (1,1B) in FP16 verwendet wird, werden etwa 2,2 GB Speicher benötigt, aber durch 4-Bit-Quantisierung (wie Q4_K) kann dies drastisch auf etwa 600 MB komprimiert werden.

6.1 Block-Quantisierungsarchitektur

ggml quantisiert nicht den gesamten Tensor einheitlich, sondern in „Blöcken“. Im Q4_0-Format werden 32 FP16-Werte in einem Block zusammengefasst.

Skalierungsfaktor (Scale Factor): Ein FP16-Wert (2 Byte)
Quantisierte Daten: 32 4-Bit-Werte (16 Byte) Dadurch wird der Einfluss von lokalen Ausreißern (Outliers) minimiert.

6.2 Beschleunigung des Skalarprodukts durch AVX2

Beim Kompilieren für die neuesten x86-CPUs in einer Windows-Umgebung werden Compiler-Flags wie /arch:AVX2 verwendet und die SIMD-Verarbeitung läuft im folgenden Fluss ab:

Laden: Die quantisierten 4-Bit-Daten werden aus dem Speicher in ein 256-Bit-AVX-Register geladen.
Entpacken (Unpack): Die 4-Bit-Werte werden durch Bitmasken- und Shift-Operationen in Int8 oder Int16 entpackt.
Dequantisierung: Multiplikation mit dem Skalierungsfaktor zur Umwandlung in Gleitkommazahlen.
FMA-Berechnung: Parallele Ausführung der Multiply-Add-Operation mit den Aktivierungswerten über _mm256_fmadd_ps (Fused Multiply-Add).

7. Details zur Implementierung des KV-Caches

Bei der autoregressiven Generierung ist ein „KV-Cache“, der die Berechnung von Key und Value vergangener Tokens überspringt, eine zwingend erforderliche Funktion.

Bei der Implementierung in C++ sind die folgenden Punkte wichtig:

Vorabreservierung des Tensors: Ein riesiger Tensor für die maximale Kontextlänge (z. B. 2048 Tokens) wird für den KV-Cache initialisiert (FP16 wird empfohlen).
Offset-Kopie: Wenn die Berechnung für die Token-Position $N$ durchgeführt wird, werden die in diesem Schritt erhaltenen K- und V-Vektoren in der $N$-ten Zeile des KV-Cache-Tensors mithilfe von ggml_cpy o. Ä. gespeichert.
Erstellung eines Views bei der Attention: Bei der Berechnung der Attention wird ein „View“ (Ansicht) erstellt, der nur auf den Bereich der Tokens 0 bis $N$ verweist, und dieser View wird an die Matrixmultiplikation übergeben.

8. BPE Tokenizer und Dekodierung

Der Eingabe-String wird als Bytefolge in UTF-8 behandelt und mit einem vordefinierten Vokabular abgeglichen. Um die Vokabularsuche in C++ zu beschleunigen, werden Algorithmen implementiert, die Trie-Bäume (Präfixbäume) oder Prioritätswarteschlangen verwenden.

Die vom LM Head ausgegebenen Logits werden mithilfe des Temperature-Parameters skaliert, um Wahrscheinlichkeiten zu erhalten. Die Kandidaten werden durch Top-K-Extraktion oder Top-P-Methoden (Nucleus Sampling) eingegrenzt, und das endgültige nächste Token wird mithilfe von Zufallszahlen bestimmt.

9. Aufbau eines C++-Projekts (Windows / PowerShell-Umgebung)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Optimierungs- und AVX2-Flags für Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Beispiel für einen Build-Befehl in PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Zusammenfassung

Die Implementierung einer Inferenz-Engine für kleine KI-Modelle wie TinyLLaMA von Grund auf mit C++ und ggml ist eine hervorragende Gelegenheit, die Blackbox des Deep Learning zu entschlüsseln und die Schönheit der Low-Level-Hardwaresteuerung kennenzulernen. Durch den Einsatz von Zero-Copy-Laden mithilfe von Memory Mapping, SIMD-Optimierung und dem Aufbau von KV-Caches können Sie das Wesentliche der Systemprogrammierung in vollen Zügen genießen und gleichzeitig die Zukunft der Edge-KI mitgestalten.

Ein umfassender Vergleich der APIs von ChatGPT, Gemini und Claude: Welche sollten Sie wählen?

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

Ein umfassender Vergleich der APIs von ChatGPT, Gemini und Claude: Welche sollten Sie wählen?

Die Entwicklung der KI-Technologie ist bemerkenswert, insbesondere im Bereich der großen Sprachmodelle (LLM: Large Language Model). Hier liefern sich OpenAIs ChatGPT (GPT-Serie), Googles Gemini und Anthropics Claude einen erbitterten Dreikampf um die Vorherrschaft. Im Jahr 2026 veröffentlichen diese Unternehmen im Monats-, wenn nicht gar Wochentakt, neue Modelle und API-Funktionen. Für Entwickler und IT-Architekten von Unternehmen ist die Frage, „welche API in das Produkt integriert werden soll“, zu einer äußerst wichtigen Entscheidung geworden, die über den Erfolg eines Projekts bestimmen kann.

In diesem Artikel werden wir die APIs dieser drei großen KI-Anbieter nicht nur durch eine bloße Aufzählung von Spezifikationen vergleichen und erläutern, sondern auch aus der Perspektive von Entwicklern tiefgreifend auf Aspekte wie Architekturdesign, detaillierte Preisstrukturen, mathematische Analyse der Latenz (Verzögerung), konkrete Implementierungsbeispiele in Python und Node.js sowie die neuesten Methoden zur Kostenoptimierung wie Prompt Caching eingehen.

Wir hoffen, dass dieser Artikel ein vollständiger Leitfaden für Sie als Leser wird, um die optimale LLM-API für Ihren speziellen Anwendungsfall auszuwählen und skalierbare, kosteneffiziente KI-Anwendungen zu entwickeln.

1. Philosophie und Designkonzept der einzelnen LLM-APIs

Bei der Auswahl der Technologie ist es zunächst von entscheidender Bedeutung zu verstehen, mit welcher Philosophie die einzelnen Unternehmen ihre Modelle und APIs entwickeln.

1.1 OpenAI (ChatGPT)

OpenAI verfolgt die Mission, „Künstliche Allgemeine Intelligenz (AGI) zu verwirklichen“, und treibt stets den De-facto-Standard der Branche voran. Sie bieten vielfältige Modelle, die auf verschiedene Anwendungsfälle zugeschnitten sind, wie z. B. GPT-4o, GPT-4o-mini und die auf Inferenzen spezialisierten o1-Modelle. Das Ökosystem ist am ausgereiftesten und verfügt über die größte Fülle an offiziellen und inoffiziellen Bibliotheken und Dokumentationen.

1.2 Google (Gemini)

Google vertritt den „AI First“-Ansatz und nutzt die Skalierbarkeit seiner eigenen Infrastruktur (TPU-Netzwerk) als seine stärkste Waffe. Gemini 1.5 Pro/Flash zeichnet sich vor allem durch sein überwältigendes Kontextfenster (Kontextlänge) von bis zu 2 Millionen Token aus, mit dem es lange Dokumente und mehrstündige Videos oder Audios in einem Durchgang verarbeiten kann. Die starke Integration mit der Google Cloud (Vertex AI) ist auch für Unternehmen äußerst attraktiv.

1.3 Anthropic (Claude)

Anthropic ist ein von ehemaligen OpenAI-Mitgliedern gegründetes Unternehmen, das einen einzigartigen Sicherheitsansatz namens „Constitutional AI (Verfassungsgemäße KI)“ anwendet. Claude 3.5 Sonnet und Opus erfreuen sich aufgrund ihrer hohen Schlussfolgerungsfähigkeit, ihrer Fähigkeiten zur Codegenerierung und vor allem wegen ihrer „menschenähnlichen, natürlichen Konversation“ und dem „Mangel an Halluzinationen“ bei vielen Entwicklern begeisterter Unterstützung.

2. Ein detaillierter Spezifikationsvergleich der Modellfamilien

Wir vergleichen die Spezifikationen der wichtigsten Modelle im Jahr 2026.

Anbieter	Hauptmodell	Maximale Kontextlänge	Hauptstärken	Empfohlene Anwendungsfälle
OpenAI	GPT-4o	128K	Geschwindigkeit, visuelle Erkennung, Sprachunterstützung	Interaktive Apps, allgemeine Aufgaben
OpenAI	o1-preview	128K	Fortgeschrittenes logisches Denken, Mathematik, Programmieren	Erstellung komplexer Algorithmen, Forschungszwecke
Google	Gemini 1.5 Pro	2.000K	Verarbeitung sehr langer Texte, Multimodal (Video/Audio)	Analyse riesiger Codebasen, Videozusammenfassung
Google	Gemini 1.5 Flash	2.000K	Geringe Latenz, hoher Durchsatz, extrem niedrige Kosten	Echtzeitverarbeitung, Stapelverarbeitung riesiger Datenmengen
Anthropic	Claude 3.5 Sonnet	200K	Programmierfähigkeiten, natürliche Textgenerierung	Unterstützung bei der Softwareentwicklung, fortschrittlicher Kundensupport
Anthropic	Claude 3.5 Haiku	200K	Ultraschnelle Reaktion, Kosteneffizienz	Edge AI, Echtzeit-Chatbots

3. Ein tieferer Blick in die Architektur: Hinter den Kulissen von API-Anfragen

Welche Prozesse laufen im Backend ab, wenn ein API-Aufruf für ein LLM getätigt wird? Um die Leistung zu optimieren, muss man diese Architektur verstehen.

Das folgende Mermaid-Diagramm zeigt das Gesamtbild vom Senden einer API-Anfrage durch den Client bis zur Rückgabe der Token im Streaming-Verfahren.

graph TD A["Client-Anwendung"] -->|HTTP/REST oder gRPC| B["API-Gateway"] B --> C["Load Balancer"] C --> D["Inferenz-Cluster"] D --> E["Tokenizer (BPE / SentencePiece)"] E --> F["KV Cache & Attention-Mechanismus"] F --> G["Transformer-Blöcke (Forward Pass)"] G --> H["Output-Layer (Logits)"] H --> I["Sampler (Temperature, Top-p, Top-k)"] I --> J["Detokenizer"] J -->|Streaming-Antwort (Chunk)| A

3.1 Tokenisierungs-Algorithmen (Tokenization)

Der in die API eingegebene Text wird intern in Einheiten namens „Token“ unterteilt.

OpenAI (tiktoken): Verwendet Byte-Pair Encoding (BPE). Es komprimiert besonders im Englischen äußerst effizient, aber bei nicht-alphabetischen Sprachen wie Japanisch neigt die Anzahl der Token dazu, stark anzusteigen.
Google (Gemini): Verwendet SentencePiece (Unigram Language Model). Es ist stark in Mehrsprachigkeit und neigt dazu, selbst japanische Texte mit einer relativ geringen Anzahl von Token darstellen zu können.
Anthropic (Claude): Verwendet eine angepasste Version von BPE. Die Mehrsprachigkeit wurde verbessert, und ab Claude 3 hat sich die Token-Effizienz für Japanisch ebenfalls drastisch verbessert.

4. Mathematische Analyse von Latenz und Leistung

In Echtzeitanwendungen wirkt sich die Latenz direkt auf das Benutzererlebnis (UX) aus. Die Latenz einer LLM-API, $T_{total}$, lässt sich mathematisch wie folgt modellieren:

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

Hier haben die einzelnen Variablen die folgenden Bedeutungen:

$T_{network}$: Die Round-Trip-Time (RTT) des Netzwerks.
$T_{TTFT}$ (Time To First Token): Die Zeit, bis das erste Zeichen generiert wird. Sie hängt stark von den Berechnungskosten der Attention ab, die proportional zum Quadrat der Prompt-Länge (Anzahl der Eingabe-Token) steigen.
$N$: Die Gesamtzahl der ausgegebenen Token.
$T_{TPOT}$ (Time Per Output Token): Die Generierungszeit pro Token. Da es sich um ein autoregressives Modell handelt, wird es seriell in Abhängigkeit von der vorherigen Ausgabe berechnet.

4.1 Berechnungskomplexität des Self-Attention-Mechanismus

Die Berechnungskomplexität der Self-Attention in der Transformer-Architektur steigt quadratisch mit der Eingabesequenzlänge $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

Hierbei ist $d$ die Dimensionalität des Einbettungsvektors (Embedding Vector). Aufgrund dieser Einschränkung verschlechtert sich $T_{TTFT}$ normalerweise drastisch, wenn der Prompt länger wird. Googles Gemini 1.5 hat jedoch innovative Optimierungsarchitekturen wie „Ring Attention“ und „Block-wise Compute“ eingeführt, wodurch es gelingt, das erste Token in einer realistischen Zeit (wenige Sekunden bis Dutzende von Sekunden) zu generieren, selbst wenn ein langer Text von 2 Millionen Token eingegeben wird.

5. Preisstrukturen und Strategien zur Kostenoptimierung

Die API-Kosten werden grundsätzlich basierend auf der Anzahl der Eingabe- und Ausgabe-Token berechnet.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

Allerdings haben die neuesten APIs neue Mechanismen eingeführt, um die Kosten drastisch zu senken.

5.1 Prompt-Caching (Prompt Caching)

Es verursacht enorme Kosten, wenn man jedes Mal extrem lange System-Prompts oder riesige Mengen an Dokumenten, die über RAG (Retrieval-Augmented Generation) abgerufen wurden, sendet. Um dem entgegenzuwirken, bieten die Anbieter eine Caching-Funktion an.

Bei Anthropic (Claude) und Google (Gemini) können durch das Caching bestimmter Textblöcke die Eingabekosten erheblich (um bis zu 90 %) gesenkt werden.

Das Kostenmodell bei Verwendung von Cache sieht wie folgt aus:

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

Hierbei ist $Rate_{cache\_read}$ auf etwa 10 % bis 25 % des normalen $Rate_{in}$ festgelegt. Dadurch wurde es möglich, einen Chatbot kostengünstig zu betreiben, während ihm eine Codebasis von Zehntausenden von Zeilen permanent als Hintergrundwissen zur Verfügung steht.

5.2 Batch-API (Batch API)

Für Aufgaben, bei denen keine Echtzeitfähigkeit erforderlich ist (z. B. Log-Analyse, massenhafte Datenklassifizierung), bieten OpenAI und Anthropic eine Batch-API an. Dies ist ein leistungsstarker Mechanismus, bei dem Anfragen gebündelt gesendet werden und man die Ergebnisse innerhalb von 24 Stunden erhält, dafür aber nur den halben Preis (50 % Rabatt) der normalen API-Kosten extrinsisch zahlt.

6. Entwicklererfahrung (DX) und SDK-Vergleich

Wir vergleichen die von den einzelnen Unternehmen angebotenen SDKs (Software Development Kits) unter dem Gesichtspunkt der Entwicklungseffizienz.

6.1 OpenAI API

Es ist am weitesten verbreitet und auch die Unterstützung durch Bibliotheken von Drittanbietern (LangChain, LlamaIndex usw.) ist am schnellsten. Darüber hinaus garantiert die Funktion „Structured Outputs“ (strukturierte Ausgaben), dass Antworten zu 100 % konform mit einem JSON-Schema zurückgegeben werden, was die Systemintegration extrem vereinfacht.

6.2 Anthropic API (Claude)

Die SDK-Schnittstelle ist sehr ausgereift und Typdefinitionen in TypeScript sind beispielsweise äußerst benutzerfreundlich. Insbesondere die Struktur der Message-API ist intuitiv, und auch multimodale Anfragen, die mehrere Bilder enthalten, lassen sich einfach implementieren.

6.3 Google Gemini API

Es gibt zwei Zugangswege: über Google Cloud Vertex AI und über AI Studio (Google Gen AI SDK), was Anfänger möglicherweise etwas verwirren kann. Das Vertex AI SDK für Unternehmen ist jedoch vollständig in das IAM (Identitäts- und Zugriffsmanagement) der GCP integriert und ermöglicht den Aufbau einer sicheren Entwicklungsumgebung.

7. Praxis! Implementierung eines Integrationstests mehrerer APIs mit Python

Hier werden wir mit Python ein Skript implementieren, das gleichzeitig asynchrone Anfragen an die drei APIs von OpenAI, Anthropic und Gemini sendet und deren Latenz vergleicht.

 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


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# Initialisierung der Clients
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "Bitte erklären Sie für Anfänger verständlich die Grundlagen von Quantencomputern und deren Auswirkungen auf aktuelle Kryptographietechnologien."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Nutzung der asynchronen Methode des Gemini Python SDKs
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("Sende Anfragen an die jeweiligen LLM-APIs...")

 # Ausführung der drei APIs parallel
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} seconds")
 print(f"Response (Excerpt): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

Durch Ausführen dieses Skripts können Sie in einer realen Netzwerkumgebung leicht messen, welches Modell am schnellsten (bei Minimierung von $T_{total}$) antwortet.

8. Implementierung von Tool Calling (Function Calling) mit Node.js

Um ein LLM nicht nur als simplen Chatbot, sondern als „KI-Agenten“ fungieren zu lassen, der mit externen Systemen interagiert, ist Tool Calling (oder Function Calling) unerlässlich. Das folgende Beispiel zeigt, wie man mit Node.js (TypeScript) die OpenAI-API dazu bringt, eine Wetter-API aufzurufen.

 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


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "Ruft das aktuelle Wetter für die angegebene Stadt ab.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "Name der Stadt (z. B. Tokio, New York)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "Wie ist das Wetter heute in Tokio? Brauche ich einen Regenschirm?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`Das LLM hat einen Tool-Aufruf angefordert: Funktionsname = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`Argumente: ${args.location}`);

 // Hier wird der Prozess zum Aufrufen der eigentlichen Wetter-API (z. B. OpenWeatherMap) implementiert
 // const weather = await fetchWeatherFromAPI(args.location);

 // Das abgerufene Ergebnis wird wieder an das LLM übergeben, um die endgültige Antwort generieren zu lassen
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet und Gemini 1.5 Pro verfügen ebenfalls über gleichwertige Tool-Calling-Funktionen, und obwohl es leichte Unterschiede in der Art und Weise gibt, wie Schemata definiert werden, ist der grundlegende Ablauf derselbe.

9. RAG vs. Long Context Window: Welches sollte verwendet werden?

Eine der größten Debatten in der Enterprise-KI-Architektur ist derzeit die Frage, „ob man RAG (Retrieval-Augmented Generation) nutzen sollte, um externes Wissen einzubeziehen, oder ob man alles einem riesigen Kontextfenster (Long Context) überlassen sollte.“

Vorteile und Herausforderungen von RAG (Retrieval-Augmented Generation)

Vorteile: Die Kosten sind niedrig (da nur die benötigten Chunks in den Prompt eingefügt werden) und die Quelle der Antwort lässt sich leicht identifizieren.
Herausforderungen: Da es auf der Genauigkeit der semantischen Suche beruht, eignet es sich nicht für komplexe Schlussfolgerungsaufgaben, bei denen der Kontext über mehrere Dokumente verstreut ist (z. B. „Analysieren Sie chronologisch die Grundursache für die Verzögerung von Projekt A anhand aller Besprechungsprotokolle des letzten Jahres“).

Long Context (z. B. 2 Millionen Token von Gemini 1.5 Pro)

Vorteile: Kein Informationsverlust durch die Suche. Selbst im „Needle In A Haystack (NIAH)“-Test (Die Nadel im Heuhaufen suchen) können Modelle wie Gemini 1.5 Pro oder Claude 3.5 Sonnet Informationen mit einer Genauigkeit von über 99 % extrahieren.
Herausforderungen: Der Token-Verbrauch ist enorm, was die Kosten in die Höhe treibt, und die Latenz ($T_{TTFT}$) nimmt zu.

Fazit: Die Best Practice für das Jahr 2026 ist ein „Hybrid-Ansatz“. Für alltägliche Q&As wird RAG mit einer Vektordatenbank eingesetzt. Für spezialisierte Aufgaben, die komplexe Analysen oder Code-Reviews des gesamten Systems erfordern, wird hingegen Long Context in Kombination mit Prompt-Caching verwendet. Dieses Design ist heute der Mainstream.

10. Vergleich der multimodalen Verarbeitungsfähigkeiten

KI-Anwendungen der nächsten Generation erfordern die Fähigkeit, nicht nur Text, sondern auch Bilder, Audiodaten und Videos direkt zu verstehen.

sequenceDiagram participant User as "Benutzer" participant Client as "Frontend-App" participant API as "LLM-API (Multimodal)" User->>Client: Video & Text-Prompt hochladen Client->>API: Video Bytes/URI + Text senden Note over API: Video aufteilen & Audio trennen Note over API: Multimodales Embedding-Modell API-->>Client: Textzusammenfassung & Zeitstempel zurückgeben Client-->>User: Erkenntnisse anzeigen

OpenAI (GPT-4o): Bietet eine extrem hohe Bilderkennungsgenauigkeit und eignet sich hervorragend zum Lesen von handgezeichneten Skizzen oder komplexen Graphen. Die native Sprachinteraktion mit extrem geringer Latenz (einige hundert Millisekunden) über die Realtime-API ist ebenfalls sehr leistungsstark.
Google (Gemini 1.5 Pro): Ist bei der Videoanalyse unübertroffen. Man kann eine einstündige Videodatei (Frames + Audio) direkt eingeben und punktgenaue Fragen stellen wie: „Wie lautet der Titel des Dokuments, das die Person am rechten Bildschirmrand bei Minute 12:45 in der Hand hält?“.
Anthropic (Claude 3.5 Sonnet): Die Fähigkeiten zur Bilderkennung (Vision) sind auf dem gleichen Niveau wie bei GPT-4o und äußerst beeindruckend. Es zeigt eine beispiellose Stärke bei der Unterstützung der Frontend-Entwicklung, etwa wenn man einen Screenshot einer Benutzeroberfläche übergibt und anfordert: „Generiere den React-Komponentencode für diesen Bildschirm“.

11. Sicherheit und Compliance auf Unternehmensniveau

Wenn Unternehmen LLM-APIs in Produktionsumgebungen einsetzen, sind die größten Bedenken: „Werden unsere Daten zum Trainieren der KI verwendet?“ und „Werden Compliance-Anforderungen erfüllt?“.

Alle drei Unternehmen haben klar erklärt, dass die über die API gesendeten Daten (Prompts und Antworten) nicht zum Trainieren der Modelle verwendet werden (Zero Data Retention / No Training on Customer Data) (*Dies gilt nicht für die kostenlosen Web-Chat-UIs für Verbraucher).

Wenn ein noch höheres Sicherheitsniveau erforderlich ist:

OpenAI: Durch die Nutzung des Azure OpenAI Service stehen die Enterprise-Grade-Sicherheit von Microsoft, SLAs und geschlossene Netzwerkverbindungen über Azure Private Link zur Verfügung.
Google: Durch die Nutzung von Google Cloud Vertex AI sind eine strikte Netzwerktrennung mithilfe von VPC Service Controls und der Datenschutz durch CMEK (Customer-Managed Encryption Keys) möglich.
Anthropic: Durch die Nutzung über AWS Bedrock oder Google Cloud Vertex AI kann man von der robusten Sicherheitsinfrastruktur der Cloud-Anbieter profitieren.

12. Fazit: Der ultimative Leitfaden zur Auswahl nach Anwendungsfall

Wir haben bisher einen vielseitigen Vergleich angestellt, aber die endgültige Antwort auf die Frage „Welche API sollte man wählen?“ hängt letztendlich vom Anwendungsfall ab.

Komplexe Softwareentwicklung / Codegenerierung / Fortgeschrittenes logisches Denken: 👑 Gewinner: Claude 3.5 Sonnet (Anthropic) Es bietet derzeit die beste Leistung beim Verstehen von Code-Kontexten, beim Refactoring und bei der Erstellung von natürlichem, menschenähnlichem Text. Auch die Benutzerfreundlichkeit der API und die Kosteneffizienz durch Prompt-Caching sind hervorragend.
Analyse von extrem langen Dokumenten / Stapelverarbeitung von Video und Audio: 👑 Gewinner: Gemini 1.5 Pro (Google) Das Kontextfenster von 2 Millionen Token ist eine einzigartige Waffe. Bei Aufgaben, die ein Verständnis des Gesamtbildes der Daten erfordern, wie z. B. die Analyse von Hunderten Seiten langen PDF-Handbüchern oder die Zusammenfassung von stundenlangen Besprechungsaufzeichnungen, ist Gemini unübertroffen.
Vielseitigkeit / Ausführungsgeschwindigkeit / Stabile strukturierte Ausgaben (JSON): 👑 Gewinner: GPT-4o / GPT-4o-mini (OpenAI) Es erledigt alle Aufgaben einwandfrei und bietet die umfangreichste Unterstützung für Tools von Drittanbietern. Das OpenAI-Ökosystem ist unverzichtbar, wenn man ein zuverlässiges JSON-Parsing mithilfe von Structured Outputs benötigt oder extrem fortgeschrittenes logisches Denken mit dem o1-Modell erfordert.

Empfehlung für Multimodell-Routing

Anstatt sich auf eine einzige API zu verlassen (Vendor-Lock-in), ist die zukünftige Richtung eine Architektur des „LLM-Routings“, bei der Modelle je nach Schwierigkeitsgrad und Wichtigkeit der Aufgabe dynamisch umgeschaltet werden. Beispielsweise kann man auf einfache Fragen von Benutzern mit dem kostengünstigen und schnellen GPT-4o-mini oder Gemini 1.5 Flash antworten. Nur wenn festgestellt wird, dass eine komplexe Verarbeitung erforderlich ist, greift man als Fallback für die Aufgabe auf Claude 3.5 Sonnet zurück. So lässt sich das optimale Gleichgewicht zwischen Kosten und Leistung erreichen.

Die Entwicklung der KI ist unaufhaltsam. Verstehen Sie die Stärken und Schwächen der einzelnen APIs sowie die Besonderheiten ihrer Architektur genau, um flexible und flexibel skalierbare KI-Anwendungen zu entwickeln.

Einführung in die Nutzung und C++-Anpassung von llama.cpp

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

In den letzten Jahren war die Entwicklung von Large Language Models (LLMs) enorm und ihre Anwendungsbereiche erweitern sich täglich. Um jedoch Modelle mit Milliarden oder zig Milliarden Parametern in einer lokalen Umgebung auszuführen, benötigt man normalerweise eine High-End-GPU mit enorm viel VRAM. llama.cpp hat diese „Hardware-Barriere“ durchbrochen und ermöglicht praktische LLM-Inferenz auf gewöhnlichen PCs, Macs und sogar auf Geräten wie dem Raspberry Pi.

In diesem Artikel erklären wir nicht nur die Nutzung als reines Kommandozeilentool, sondern gehen für Entwickler äußerst detailliert auf die zugrunde liegende ggml-Architektur, den mathematischen Hintergrund von Transformern und Quantisierung sowie die Nutzung der C++-API ein, um LLMs in eigene Anwendungen zu integrieren und anzupassen.

1. Übersicht über llama.cpp und ggml

llama.cpp ist eine von Georgi Gerganov in C/C++ geschriebene, leichtgewichtige LLM-Inferenz-Engine. Ursprünglich wurde sie entwickelt, um Metas LLaMA-Modelle auf Apple Silicon (M1/M2 Macs) mit hoher Geschwindigkeit auszuführen, unterstützt aber mittlerweile verschiedene Architekturen und Modelle.

Das größte Merkmal ist, dass es sich um eine reine C/C++-Implementierung ohne externe Abhängigkeiten handelt. Da kein riesiges Ökosystem wie Python oder PyTorch benötigt wird und es als einzelne ausführbare Datei kompiliert werden kann, ist die Bereitstellung extrem einfach.

Das Herzstück von llama.cpp ist die Tensor-Berechnungsbibliothek ggml. ggml wurde von Grund auf neu entwickelt, um Matrixoperationen für maschinelles Lernen auf der CPU (und teilweise GPU) bis zum Äußersten zu optimieren.

1.1 Warum ist llama.cpp so schnell?

Nutzung von Memory Mapping (mmap): Beim Laden der Modellgewichte in den Speicher wird durch die Nutzung der mmap-Funktion des Betriebssystems das vollständige Laden in den RAM vermieden, was zu einem schnellen Start und Speicherplatzeinsparungen führt.
Umfassende Optimierung von SIMD-Befehlen: CPU-spezifische Befehlssätze wie AVX2, AVX-512, ARM NEON und Apple AMX werden genutzt, um Matrixmultiplikationen extrem zu beschleunigen.
Quantisierung (Quantization): Die Gewichte in 16-Bit-Gleitkommazahlen (FP16) werden in 4-Bit-, 5-Bit- oder 8-Bit-Ganzzahlen komprimiert, um Engpässe in der Speicherbandbreite zu beseitigen (Details siehe unten).

2. Mathematischer Hintergrund: Transformer und Quantisierung

Um llama.cpp tiefgreifend zu verstehen, muss man die mathematischen Formeln kennen, die es berechnet, und wissen, wie es diese Berechnungen annähert.

2.1 Transformer-Inferenzprozess

Modelle wie LLaMA verwenden eine autoregressive (Auto-regressive) Transformer-Decoder-Architektur. Der Kern der Textgenerierung ist der Self-Attention-Mechanismus.

Für eine Eingabematrix von verborgenen Zuständen $X \in \mathbb{R}^{N \times d}$ werden Query $Q$, Key $K$ und Value $V$ durch Multiplikation mit Gewichtsmatrizen berechnet:

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

Hierbei ist die Ausgabe der Attention wie folgt definiert:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

In der Inferenzschleife von llama.cpp liegt der Engpass in der Multiplikation dieser riesigen Matrizen $W_Q, W_K, W_V$ und der Gewichtsmatrizen des Feed-Forward-Networks (FFN) mit dem Vektor $X$ (da in der Generierungsphase Token für Token verarbeitet wird, ist $N=1$), also GEMV (General Matrix-Vector Multiplication).

2.2 Mathematische Grundlagen der Quantisierung

In der Inferenz, bei der die Speicherzugriffsbandbreite der Engpass ist, ist die Quantisierung, bei der Gewichtsparameter mit einer kleinen Anzahl von Bits dargestellt werden, unerlässlich. Wir erklären das Grundprinzip der in llama.cpp weit verbreiteten blockweisen Quantisierung (z. B. Q4_K oder Q4_0).

Betrachten wir zum Beispiel einen Block $w = [w_1, w_2, \dots, w_B]$ der Länge $B$ (normalerweise 32 oder 64), der Teil der FP16-Gewichtsmatrix $W$ ist. Dieser Block wird durch eine 4-Bit-Ganzzahl $q_i \in [-8, 7]$ und einen einzelnen Skalierungsfaktor $\Delta$ (FP16 oder FP32) angenähert.

$$ w_i \approx \Delta \times q_i $$

$\Delta$ wird basierend auf dem maximalen Absolutwert innerhalb des Blocks bestimmt.

$$ \Delta = \frac{\max_i |w_i|}{7} $$

Wenn das Skalarprodukt $y = w \cdot x$ unter Verwendung der quantisierten Gewichte berechnet wird und der Eingabevektor $x$ ebenfalls quantisiert wird, sodass $x_i \approx \Delta_x \times q_{x, i}$, gilt:

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

Dieser Teil $\sum q_i q_{x, i}$ ist eine reine Ganzzahloperation und kann mithilfe von SIMD-Befehlen extrem schnell parallel berechnet werden. Das ist der mathematische Trick, der llama.cpp auf CPUs atemberaubende Geschwindigkeiten erreichen lässt.

3. Architektur und Inferenzfluss

Um die interne Funktionsweise von llama.cpp zu verstehen, zeigt das folgende Mermaid-Diagramm die Gesamtsystemarchitektur und den Datenfluss.

graph TD A["Benutzereingabe (String)"] --> B["llama.cpp Tokenizer"] B --> C["Token-IDs (int32-Array)"] C --> D["Kontextpuffer (KV Cache)"] D --> E["ggml-Berechnungsgraph"] E --> F["Transformer-Schichten"] subgraph "ggml Engine" F --> G["Self-Attention (RoPE)"] G --> H["Feed Forward Network"] H --> F end F --> I["Logits (Vokabulargröße)"] I --> J["Sampler (Temperature, Top-K, Top-P)"] J --> K["Ausgewählte Token-ID"] K --> L["llama.cpp Detokenizer"] L --> M["Ausgabe-String"] K -. "Autoregressive Schleife" .-> D

Die Textgenerierung ist eine autoregressive Schleife, bei der jedes ausgegebene Token als nächste Eingabe in den KV-Cache aufgenommen wird und den Berechnungsgraphen erneut durchläuft.

4. Einrichtung der Umgebung und Build-Methode

Bevor wir llama.cpp in ein C++-Projekt integrieren, lassen Sie uns zunächst den Quellcode kompilieren (builden).

4.1 Klonen des Repositorys

1
2


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

4.2 Build mit CMake

Wenn Sie es als C++-Projekt in andere Anwendungen integrieren möchten, ist die Verwendung von CMake der Standardweg. Durch die Aktivierung von plattformspezifischen Beschleunigern (Backends) können Berechnungen beschleunigt werden.

Nur CPU (Basis-Build):

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

Bei Verwendung einer NVIDIA-GPU (CUDA):

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

Bei Verwendung von Apple Silicon (Metal):

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

Bei einem erfolgreichen Build werden ausführbare Dateien wie llama-cli und die llama-Bibliothek (sowie die ggml-Bibliothek) zur Verlinkung mit der unten beschriebenen C++-API im Verzeichnis build/bin/ generiert.

5. Einführung in die C++-Anpassung: Nutzung der llama.cpp API

Von hier an behandeln wir das Hauptthema: die Steuerung von llama.cpp aus C++-Code. Um ein LLM in Ihre eigenen Anwendungen (z. B. Spiel-Engines, Desktop-Apps, eingebettete Systeme usw.) zu integrieren, anstatt nur das Kommandozeilentool zu verwenden, müssen Sie die C++-API direkt aufrufen.

llama.cpp bietet hauptsächlich eine C-Schnittstelle über eine Header-Datei namens llama.h. Auch beim Aufruf aus C++ wird diese Schnittstelle verwendet.

5.1 Nötigste Includes und Einstellungen

Wenn Sie llama.cpp in Ihrem eigenen Projekt verwenden, inkludieren Sie Folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// Makro zur Fehlerbehandlung
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 Modell laden und Kontext initialisieren

Zuerst laden wir die Modelldatei im .gguf-Format und reservieren den Kontext (Speicherplatz und KV-Cache) für die Inferenz.

 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


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. Initialisierung des Backends (Umgebungs-Setup wie CPU/GPU)
 llama_backend_init();

 // 2. Standardeinstellungen für Modellparameter abrufen
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // Anzahl der auf die GPU ausgelagerten Schichten

 // 3. Modell laden
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. Kontextparameter einstellen
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // Maximale Kontextgröße (Anzahl der Tokens)
 ctx_params.n_threads = 8; // Anzahl der für die Inferenz verwendeten CPU-Threads

 // 5. Kontext erstellen
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... folgende Verarbeitung

5.3 Tokenisierung des Prompts (Tokenization)

LLMs verstehen Text nicht direkt, sondern verarbeiten ihn als eine Reihe von ganzzahligen IDs (Tokens). Die Eingabezeichenfolge muss in Tokens umgewandelt werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: Was ist die Hauptstadt von Japan?\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // Puffergröße mit etwas Spielraum

 // Ob spezielle Token (BOS: Begin of Sequence etc.) am Anfang hinzugefügt werden sollen
 bool add_special = true;
 // Zeichenfolge in ein Array von Token-IDs umwandeln
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // Logik für Neuallokation und Wiederholung erforderlich, wenn der Puffer nicht ausreicht (hier zur Vereinfachung weggelassen)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 Inferenzschleife und Sampling

Wir erstellen eine Schleife, in der Tokens in das Modell eingespeist werden, die Wahrscheinlichkeitsverteilung (Logits) für das nächste Token abgerufen wird, und dann durch Sampling das nächste Token bestimmt wird.

 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


 // Maximale Anzahl der zu generierenden Tokens
 const int max_gen_tokens = 100;

 // Struktur für die Batch-Evaluierung initialisieren
 llama_batch batch = llama_batch_init(512, 0, 1);

 // Prompt-Tokens zum Batch hinzufügen
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // So einstellen, dass Logits (Vorhersageergebnisse) nur für das letzte Token des Prompts ausgegeben werden
 batch.logits[batch.n_tokens - 1] = true;

 // Erste Evaluierung (Modell mit Prompt füttern)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // Aktuelle Kontextlänge
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // Sampler-Kontext initialisieren (Einstellungen wie Temperature, Top-K, Top-P etc.)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // Seed-Wert

 while (n_decode < max_gen_tokens) {
 // 1. Sampling: Vorhersage des nächsten Tokens basierend auf dem aktuellen Kontext
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. Wenn das Token EOS (End of Sequence) ist, Schleife beenden
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. Token in einen String (Text) dekodieren und anzeigen
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. Das neu generierte Token als nächsten Batch vorbereiten
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. Modellevaluierung (KV-Cache aktualisieren und nächstes vorhersagen)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // Bereinigung
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

Dieser Code implementiert eine eigene Inferenzschleife mit der Basis-API von llama.cpp. Er verwendet die llama_batch-Struktur zur Verwaltung der Tokengruppen und führt mit llama_decode einen Forward-Pass (Vorwärtsausbreitung) des neuronalen Netzwerks aus.

6. Fortgeschrittenes Anpassungsbeispiel: Logit-Manipulation und Penalty-Steuerung mit C++

Wenn Sie nicht nur einfachen Text generieren, sondern eine Ausgabe in einem bestimmten Format (z. B. nur JSON) erzwingen oder die Ausgabe bestimmter verbotener Wörter verhindern möchten, können Sie die Logits vor dem Sampling direkt in C++ manipulieren.

Sie können das Array der rohen Scores (Werte vor der Umwandlung in Wahrscheinlichkeiten) kurz vor der Ausgabe jedes Tokens durch das Modell abrufen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Rufen Sie das Array der rohen Logits direkt nach der Inferenz und vor dem Sampling ab
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// Liste der IDs verbotener Tokens (Beispiel: 1234, 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// Setzen Sie die Auftrittswahrscheinlichkeit verbotener Tokens auf 0 (Logit auf minus unendlich)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

Durch die direkte Nutzung der C++-API werden „Eingriffe im Mikrosekundenbereich pro Inferenzzyklus“ möglich, die über LangChain oder Python nur schwer zu realisieren wären oder mit großem Overhead verbunden sind.

7. Die Geheimnisse der Leistungsoptimierung (Performance Tuning)

Nach Abschluss der C++-Implementierung finden Sie hier einige Kontrollpunkte, um die Geschwindigkeit für den praktischen Einsatz auf das Maximum zu steigern.

Optimierung der Batch-Verarbeitung: Bei der gleichzeitigen Verarbeitung von Anfragen mehrerer Benutzer können Sie mehrere Sequenzen in einen llama_batch aufnehmen und llama_decode einmalig aufrufen (Continuous Batching). Dies bündelt Speicherzugriffe und kann den Durchsatz drastisch verbessern.
Flash Attention aktivieren: Durch Setzen von ctx_params.flash_attn = true; in den Kontextparametern können Sie die Attention-Berechnung beschleunigen und gleichzeitig den Speicherverbrauch reduzieren. Bei der Arbeit mit langen Kontexten (Zehntausende von Tokens) ist diese Einstellung zwingend erforderlich.
NUMA-Unterstützung: In Multi-Socket-Serverumgebungen kann die Speicherzugriffslatenz reduziert werden, indem NUMA vor dem Aufruf von llama_backend_init() entsprechend konfiguriert wird.

8. Fazit

In diesem Artikel haben wir detailliert alles vom mathematischen Hintergrund von llama.cpp über die Erklärung seiner Architektur bis hin zur Erstellung einer benutzerdefinierten Inferenz-Engine mithilfe der C++-API behandelt.

Während das Python-Ökosystem sehr nützlich für Prototyping ist, zeigt die direkte Steuerung des C/C++-basierten llama.cpp in Produktionsumgebungen, die Deployments auf Edge-Geräten, Integrationen in Spiele und Echtzeitverarbeitung erfordern, ihre überwältigende Stärke.

Wir laden Sie ein, eigenen C++-Code zu schreiben und den Spaß zu erleben, LLMs in Ihrer lokalen Umgebung frei zu steuern.

Referenzlinks

llama.cpp Official Repository

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【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.