KI-Modelle verstehen & evaluieren

Technische Grundlagen, Evaluierungskriterien und Auswahlprozess – unabhängig von sich ändernden Modellnamen

Auf dieser Seite:

Modell-Architekturen verstehen

Die technischen Grundlagen hinter Large Language Models

Moderne LLMs basieren primär auf der Transformer-Architektur (Vaswani et al., 2017). Das fundamentale Prinzip: Self-Attention-Mechanismen ermöglichen es, Beziehungen zwischen allen Tokens im Context parallel zu berechnen – im Gegensatz zu sequenziellen Modellen (RNNs, LSTMs).

Decoder-Only Modelle

Architektur: Nur Decoder-Stack (GPT-Familie, LLaMA, Mistral)

Training: Causal Language Modeling (Auto-Regressive) – Vorhersage des nächsten Tokens

Use Cases: Text-Generierung, Chat, Code-Completion

Vorteil: Skaliert extrem gut, einfachere Architektur, beste Generation Quality

Encoder-Decoder Modelle

Architektur: Encoder + Decoder (T5, BART, ursprüngliches BERT)

Training: Masked Language Modeling + Seq2Seq Tasks

Use Cases: Übersetzung, Zusammenfassung, strukturierte Transformationen

Vorteil: Bidirektionale Attention im Encoder, gut für Klassifikation

Wichtige technische Konzepte

Multi-Head Attention

Mehrere parallele Attention-Mechanismen lernen verschiedene Relationen (Syntax, Semantik, long-range dependencies)

Positional Encoding

Da Transformers keine sequenzielle Struktur haben, wird Position durch Sinusoidal/Learned Embeddings kodiert

Layer Normalization

Stabilisiert Training bei sehr tiefen Netzen (moderne LLMs: 50-100+ Transformer-Schichten)

Evaluierungskriterien für Modelle

Wie Sie Modelle nach objektiven Kriterien vergleichen

1. Capability-Dimensionen

Reasoning & Problem-Solving

• Multi-step Reasoning (Chain-of-Thought)

• Mathematical & Logical Reasoning

• Complex Task Decomposition

Benchmark: MMLU, GSM8K, HumanEval (Code), MATH

Context Understanding

• Long-Context Handling (>100K Tokens)

• Information Retrieval aus Context

• Context-Faithful Generation (keine Halluzinationen)

Benchmark: Needle-in-Haystack, RULER, LongBench

Multimodal Capabilities

• Vision (Bild-Verständnis, OCR)

• Audio (Speech-to-Text, TTS)

• Cross-Modal Reasoning

Benchmark: MMMU, VQAv2, AudioCaps

Tool Use & Agentic Behavior

• Function Calling Accuracy

• Multi-Tool Orchestration

• Self-Correction & Iteration

Benchmark: Berkeley Function Calling, ToolBench

2. Performance-Metriken

Latenz

Time-to-First-Token (TTFT) und Tokens-per-Second (TPS)

Fast: <100ms TTFT, >50 TPS

Standard: 200-500ms TTFT, 20-40 TPS

Slow: >1s TTFT, <15 TPS

Durchsatz

Requests-per-Second (RPS) und Concurrent Users

Wichtig für: High-traffic Apps, Batch-Processing

Trade-off: Latenz vs Throughput (Batching)

Kosten-Effizienz

$ pro 1M Tokens, aber normiert auf Quality

Metrik: Performance / $ (z.B. MMLU-Score / Token-Cost)

Wichtig: Nicht nur Preis, sondern Value-for-Money

3. Safety & Alignment

RLHF & Constitutional AI

Modelle werden mit Reinforcement Learning from Human Feedback auf hilfreiche, harmlose und ehrliche Antworten trainiert. Reduziert toxische Outputs.

Refusal Behavior

Wie gut lehnt das Modell unsichere Anfragen ab? Balance zwischen Safety und Over-Refusal (zu strenge Ablehnung legitimer Fragen).

Wichtig: Für B2B/Enterprise kritisch. Testen Sie mit Ihrer spezifischen Use-Case Domain.

Anbieter-Kategorien

Technische und geschäftliche Unterschiede zwischen Anbietertypen

Closed-Source

Beispiele: OpenAI, Anthropic, Google (Gemini)

Höchste Quality (Frontier Models)

Managed Infrastructure, kein Ops-Overhead

Keine Modell-Weights, keine volle Kontrolle

Vendor Lock-in, Preis-/Policy-Änderungen

Open-Source

Beispiele: Meta (LLaMA), Mistral, DeepSeek

Volle Kontrolle über Weights & Deployment

Fine-Tuning, Distillation möglich

Self-Hosting Komplexität (GPUs, Ops)

Quality-Gap zu Frontier Models (wird kleiner)

Enterprise Platforms

Beispiele: Azure OpenAI, AWS Bedrock, Vertex AI

DSGVO-Compliance, EU Data Residency

SLAs, Enterprise Support, BAAs

Höhere Kosten als Direct API

Weniger Model-Optionen, langsamere Updates

Hybrid-Ansatz: Model Router / Gateway

Moderne Architekturen nutzen oft Model Routing: Einfache Queries → günstige Modelle, komplexe Reasoning → Frontier Models. Tools: LiteLLM, Portkey, OpenRouter.

Vorteil

60-80% Kostensenkung bei gleichbleibender Quality für gemischte Workloads

Implementation

Classifier entscheidet basierend auf Query-Komplexität welches Modell genutzt wird

Deployment-Optionen

Von Cloud-APIs bis On-Premise: Technische Trade-offs

Cloud API (Managed)

Technische Specs:

• REST/gRPC API, typisch HTTPS
• Serverless, auto-scaling
• Rate Limits: Tier-basiert (TPM, RPM)
• Latenz: ~200-500ms (Network + Inference)

Best for: Rapid Prototyping, variable Workloads, kein Ops-Team

Nicht geeignet: Höchste Datenschutz-Anforderungen, Air-Gapped Systems

On-Premise / Self-Hosted

Technische Specs:

• Eigene GPU-Infrastruktur (A100, H100)
• Inference Server: vLLM, TGI, TensorRT-LLM
• Latenz: 50-200ms (nur Inference, kein Network)
• Hardware: 1-8 GPUs je nach Modellgröße

Best for: DSGVO-kritisch, hohe Volumina, volle Kontrolle

Nicht geeignet: Kleine Teams ohne GPU-Expertise, variable Loads

Hybrid: Private Cloud / VPC Deployment

Azure OpenAI / AWS Bedrock

Managed Service, aber in Ihrer VPC/Subscription. EU Data Residency, SLAs.

Anyscale / Together AI (Private)

Dedicated Deployment in deren Infrastructure, aber logisch isoliert für Sie.

Kubernetes + Inference Server

Self-managed on AWS/GCP, volle Kontrolle, aber Cloud-Skalierung.

Modell-Auswahlprozess

Systematische Evaluation statt Modell-Namen raten

Decision Framework: 5-Schritt-Prozess

Use Case definieren

Fragen: Text-Generation? Code? Multimodal? Reasoning-Heavy? Latenz-kritisch? Batch vs. Real-time? DSGVO-relevant?

Constraints identifizieren

Hard Constraints: Budget (€/Monat), Latenz (<500ms?), Data Residency (EU?), On-Premise Required?

Benchmark auf Ihren Daten

Wichtig: Public Benchmarks (MMLU, HumanEval) sind Indikatoren, aber testen Sie mit Ihren Tasks. Erstellen Sie Eval-Set (50-100 Beispiele) aus realen Use Cases.

A/B-Testing in Production

Shadow Mode: Laufen Sie 2-3 Modelle parallel (ohne User-Impact), sammeln Sie Metriken. Entscheiden Sie basierend auf Quality + Cost + Latenz.

Kontinuierliches Monitoring

Metriken: Quality-Drift (durch Thumbs up/down), Latenz-P95, Cost-per-1K-Requests. Neue Modelle evaluieren (alle 3-6 Monate).

Beispiel: Customer Support Chatbot

Requirements:

• Latenz: <500ms (User erwartet schnelle Antwort)
• Sprachen: DE/EN
• Tool Use: Ticket-System-API, Knowledge Base
• DSGVO: Kritisch (Kundendaten)

Empfohlene Architektur:

• Azure OpenAI (EU-Residency) oder AWS Bedrock
• Standard-Tier Modell (nicht Flagship – zu teuer für Support)
• RAG mit Vector DB für Knowledge Base
• Function Calling für Ticket-API

Beispiel: Code-Generierung (Internal Tool)

Requirements:

• Latenz: Weniger kritisch (Entwickler warten 2-3s)
• Quality > Speed
• Proprietary Codebase (darf nicht in Training)
• Budget: Moderate Nutzung (~100 Requests/Tag)

Empfohlene Architektur:

• Frontier Model (bestes Reasoning für Code)
• Self-Hosted LLaMA 3 (70B+) als Alternative
• Codebase-Embeddings in Vector DB
• Kein Cloud-API (IP-Schutz)

Key Takeaways

Modellnamen sind irrelevant. GPT-7 ist nicht automatisch besser als GPT-6 für Ihren Use Case. Evaluieren Sie basierend auf Ihren Kriterien.

Benchmarks sind Indikatoren, keine Wahrheit. MMLU-Score sagt nichts über Performance in Ihrer Domain. Testen Sie mit realen Daten.

Deployment matters more than you think. Das beste Modell ist wertlos wenn es Ihre DSGVO-Anforderungen nicht erfüllt.

Model Routing ist der neue Standard. Nutzen Sie nicht ein Modell für alles – Router sparen 60-80% Kosten.

Open-Source schließt auf. Der Quality-Gap zu Closed-Source wird kontinuierlich kleiner. Evaluieren Sie Open-Source-Optionen.

Unsicher welches Modell für Ihren Use Case?

Wir helfen Ihnen bei der technischen Evaluation und dem Setup Ihrer KI-Infrastruktur.

Kostenlose Modell-Evaluation Zurück zu Grundlagen