Lokale KI – Technische Grundlagen
Transformer-Architektur im Detail
Die Transformer-Architektur besteht aus gestapelten Encoder- und/oder Decoder-Blöcken. Für generative Sprachmodelle (wie Llama, Mistral) wird ausschließlich der Decoder verwendet (Decoder-only).
Jeder Decoder-Block enthält:
- Multi-Head Self-Attention: Berechnet für jedes Token, wie stark es auf alle anderen Tokens im Kontextfenster „achten" soll
- Feed-Forward Network (FFN): Zwei lineare Schichten mit nichtlinearer Aktivierungsfunktion (meist SiLU/GELU)
- Layer Normalization: Stabilisiert das Training (RMSNorm bei neueren Modellen)
- Residual Connections: Ermöglichen tiefe Netzwerke ohne Gradientenprobleme
Self-Attention
Für jedes Token werden drei Vektoren berechnet:
- Q (Query) – Was sucht dieses Token?
- K (Key) – Was bietet jedes andere Token?
- V (Value) – Was wird weitergegeben?
Die Attention-Gewichte berechnen sich als:
Attention(Q, K, V) = softmax(QKᵀ / √dₖ) · V
Multi-Head bedeutet: Diese Berechnung wird parallel mehrfach durchgeführt (z.B. 32 Heads bei einem 7B-Modell), jeder Head lernt andere Abhängigkeiten.
Positional Encoding
Transformer haben keine inhärente Reihenfolge. Position wird durch Positional Encoding injiziert. Moderne Modelle nutzen RoPE (Rotary Position Embedding), das relative Positionen effizienter kodiert und längere Kontextfenster ermöglicht.
Tokenisierung
Byte Pair Encoding (BPE)
Das am weitesten verbreitete Tokenisierungsverfahren ist BPE. Dabei wird ein Vokabular aus häufigen Zeichenkombinationen aufgebaut:
Schritt 1: Zeichen-Vokabular: {a, b, c, ..., z}
Schritt 2: Häufigste Paare zusammenfassen: "th" → neues Token
Schritt 3: Wiederholen bis Vokabulargröße erreicht (z.B. 32.000 Tokens)
Typische Vokabulargrößen: 32.000 (Llama 2) bis 128.256 (Llama 3).
Sondertokens
Jedes Modell nutzt spezielle Tokens zur Strukturierung:
| Token | Bedeutung |
|---|---|
<s> |
Beginn der Sequenz (BOS) |
</s> |
Ende der Sequenz (EOS) |
[INST] |
Beginn einer Benutzeranweisung (Llama 2) |
| im_start|> | Chat-Turn-Beginn (ChatML-Format) |
Das Chat Template definiert, wie Nutzereingaben und Modellantworten in Token-Sequenzen verpackt werden. Ollama übernimmt dies automatisch anhand der Modell-Metadaten.
Training im Detail
Pre-Training
Ziel: Next Token Prediction – gegeben eine Sequenz, sagt das Modell das nächste Token vorher.
Verlustfunktion: Cross-Entropy Loss zwischen vorhergesagtem und tatsächlichem Token.
Optimizer: AdamW mit Lernratenplanung (Warmup + Cosine Decay).
Typische Größenordnungen für ein 7B-Modell:
| Parameter | Wert |
|---|---|
| Trainingsdaten | 1–2 Billionen Tokens |
| GPU-Bedarf | 500–1.000 A100-GPUs |
| Trainingszeit | 3–6 Wochen |
| Stromverbrauch | ~1 GWh |
Supervised Fine-Tuning (SFT)
Das vortrainierte Basismodell wird auf Instruktions-Datensätzen weitertrainiert. Format: Prompt-Response-Paare, kuratiert von Menschen oder synthetisch erzeugt (z.B. durch stärkere Modelle).
RLHF / DPO
- RLHF (Reinforcement Learning from Human Feedback)
- Menschen bewerten Modellantworten. Ein separates Reward Model lernt diese Präferenzen. Das Hauptmodell wird per PPO (Proximal Policy Optimization) optimiert.
- DPO (Direct Preference Optimization)
- Neuere, stabilere Alternative zu RLHF. Direkte Optimierung auf bevorzugte vs. abgelehnte Antwortpaare ohne separates Reward Model.
Quantisierung im Detail
Zahlenformate
| Format | Bits | Wertebereich | Verwendung |
|---|---|---|---|
| FP32 | 32 | ±3.4×10³⁸ | Training |
| FP16 | 16 | ±65.504 | Training / Inferenz |
| BF16 | 16 | ±3.4×10³⁸ | Training (stabiler) |
| INT8 | 8 | −128 bis 127 | Quantisierte Inferenz |
| INT4 | 4 | −8 bis 7 | Aggressiv quantisiert |
GGUF-Format
Ollama verwendet das GGUF-Format (GPT-Generated Unified Format), entwickelt von llama.cpp. Es speichert Modellgewichte, Metadaten und Chat-Templates in einer einzigen Datei.
Quantisierungsstufen in GGUF:
| Stufe | Bits/Gewicht | Größe (7B) | Perplexity-Verlust |
|---|---|---|---|
| Q2_K | 2,5 | ~2,8 GB | Hoch |
| Q4_K_M | 4,5 | ~4,8 GB | Gering |
| Q5_K_M | 5,5 | ~5,7 GB | Sehr gering |
| Q8_0 | 8 | ~7,7 GB | Minimal |
| F16 | 16 | ~14 GB | Keiner |
Q4_K_M ist der Standard in Ollama – gutes Gleichgewicht zwischen Größe und Qualität.
KV-Cache
Während der Inferenz werden die K- und V-Matrizen aller bereits verarbeiteten Tokens im Speicher gehalten (KV-Cache). Dies verhindert redundante Berechnungen, verbraucht aber erheblich RAM/VRAM – besonders bei langen Kontexten.
Speicherbedarf KV-Cache (approximiert):
KV-Cache = 2 × Schichten × Heads × Kontextlänge × dₖ × Bytes/Element
Bei einem 7B-Modell mit 32 Schichten, 32 Heads und 4.096 Tokens Kontext: ~512 MB (FP16).
Inferenz-Stack
Ollama nutzt intern llama.cpp als Inferenz-Engine. llama.cpp ist in C++ geschrieben und optimiert für:
- CPU: AVX2/AVX-512-Vektorinstruktionen
- Apple Silicon: Metal-Backend (unified memory)
- NVIDIA: CUDA-Backend
- AMD: ROCm-Backend (experimentell)
Die Schichten des Stacks:
Open WebUI (Browser)
↓
Ollama API (REST, Port 11434)
↓
llama.cpp (Inferenz-Engine)
↓
GGUF-Modell (Datei auf Disk)
↓
CPU / GPU (Hardware)
Zusammenfassung
Lokale Sprachmodelle sind Decoder-only Transformer, die per Next-Token-Prediction auf Billionen von Tokens vortrainiert und anschließend per SFT/RLHF/DPO auf Instruktionsfolge spezialisiert werden. GGUF-Quantisierung (Q4_K_M) reduziert den Speicherbedarf um ~65 % bei geringem Qualitätsverlust. Ollama abstrahiert den gesamten Stack – von der Modellverwaltung bis zur Inferenz via llama.cpp – hinter einer einfachen REST-API.