Thomas.will: Die Seite wurde neu angelegt: „ == Transformer-Architektur im Detail == Die Transformer-Architektur besteht aus gestapelten '''Encoder'''- und/oder '''Decoder'''-Blöcken. Für generative S…“

2026-05-10T16:28:26Z

Die Seite wurde neu angelegt: „ == Transformer-Architektur im Detail == Die Transformer-Architektur besteht aus gestapelten '''Encoder'''- und/oder '''Decoder'''-Blöcken. Für generative S…“

Neue Seite

== 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:

<pre>
Attention(Q, K, V) = softmax(QKᵀ / √dₖ) · V
</pre>

'''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:

<pre>
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)
</pre>

Typische Vokabulargrößen: 32.000 (Llama 2) bis 128.256 (Llama 3).

=== Sondertokens ===

Jedes Modell nutzt spezielle Tokens zur Strukturierung:

{| class="wikitable"
! Token !! Bedeutung
|-
| <code><s></code> || Beginn der Sequenz (BOS)
|-
| <code></s></code> || Ende der Sequenz (EOS)
|-
| <code>[INST]</code> || Beginn einer Benutzeranweisung (Llama 2)
|-
| <code><|im_start|></code> || 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:

{| class="wikitable"
! 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 ===

{| class="wikitable"
! 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:

{| class="wikitable"
! 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
|}

<code>Q4_K_M</code> 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):

<pre>
KV-Cache = 2 × Schichten × Heads × Kontextlänge × dₖ × Bytes/Element
</pre>

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:

<pre>
Open WebUI (Browser)
↓
Ollama API (REST, Port 11434)
↓
llama.cpp (Inferenz-Engine)
↓
GGUF-Modell (Datei auf Disk)
↓
CPU / GPU (Hardware)
</pre>

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

Lokale KI – Technische Grundlagen - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „ == Transformer-Architektur im Detail == Die Transformer-Architektur besteht aus gestapelten '''Encoder'''- und/oder '''Decoder'''-Blöcken. Für generative S…“