Zum Inhalt springen
_CORE
AI & Agentic Systems Core Information Systems Cloud & Platform Engineering Data Platform & Integration Security & Compliance QA, Testing & Observability IoT, Automation & Robotics Mobile & Digital Banking & Finance Insurance Public Administration Defense & Security Healthcare Energy & Utilities Telco & Media Manufacturing Logistics & E-commerce Retail & Loyalty
Referenzen Technologien Blog Know-how Tools
Über uns Zusammenarbeit Karriere
CS EN DE
Lassen Sie uns sprechen

Fine-Tuning & Optimierung

Das richtige Modell für die richtige Aufgabe.

Fine-Tuning, Wissensdestillation, Inferenz-Optimierung. Weil GPT-4 für jede Anfrage zu nutzen ist wie mit dem LKW zum Bäcker zu fahren.

-70%
Kosten nach Optimierung
-5x
Latenz nach Optimierung
85-95%
Qualität vs. Baseline
<6 Monate
ROI typisch

Wann Fine-Tuning sinnvoll ist

Fine-Tuning ist nicht immer die richtige Antwort. Die meisten Probleme lassen sich mit besseren Prompts, besserem Kontext (RAG) oder besserer Orchestrierung lösen. Fine-Tuning ist in bestimmten Situationen sinnvoll:

Entscheidungsbaum

KI-Qualitätsproblem?
    │
    ├── Fehlendes Wissen → RAG (Kontext hinzufügen)
    │
    ├── Falsches Ausgabeformat → Prompt Engineering
    │
    ├── Inkonsistentes Verhalten → Few-Shot-Beispiele im Prompt
    │
    ├── Immer noch unzureichend? → Fine-Tuning
    │
    ├── Kosten senken → Destillation (großes → kleines Modell)
    │
    └── Regulierung (On-Premise) → Open-Source fine-tunen + lokal deployen

Konkrete Indikationen für Fine-Tuning

  1. Domänenspezifische Sprache — Modell versteht Ihre Terminologie auch mit Kontext nicht (Medizin, Recht, Spezialgebiet)
  2. Konsistentes Format — Sie brauchen immer die gleiche Ausgabestruktur (JSON-Schema, Tabelle, spezifisches Template)
  3. Kosten — GPT-4 für 10.000 Anfragen täglich ist teuer. Fine-getuntes Llama 8B für einen Bruchteil der Kosten.
  4. Latenz — großes Modell = langsam. Kleines fine-getuntes = schnell (<200ms)
  5. Datenresidenz — Daten dürfen Ihre Umgebung nicht verlassen. On-Premise = Open-Source + Fine-Tuning.

Wissensdestillation

Die häufigste Form von Fine-Tuning in der Praxis: großes Modell (GPT-4, Claude) lehrt kleines Modell (Llama 8B, Mistral 7B) eine spezifische Aufgabe.

Funktionsweise

┌──────────────────────────────────────────────────┐
│  LEHRER-MODELL (GPT-4, Claude)                    │
│  - Groß, teuer, langsam                          │
│  - Exzellente Qualität                           │
│  - Generiert Trainingsdaten für Schüler          │
└──────────────────┬───────────────────────────────┘
                   │ Synthetische Trainingsdaten
                   │ (1000-5000 Beispiele)
                   ▼
┌──────────────────────────────────────────────────┐
│  FINE-TUNING-PIPELINE                             │
│  - Datenbereinigung & Deduplizierung             │
│  - LoRA/QLoRA Fine-Tuning                        │
│  - Evaluierung gegen Lehrer                      │
│  - Iteration (3-5 Zyklen)                        │
└──────────────────┬───────────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────────┐
│  SCHÜLER-MODELL (Llama 8B, Mistral 7B)           │
│  - Klein, günstig, schnell                       │
│  - 85-95% Lehrerqualität in der Zieldomäne       │
│  - Produktions-Deployment (API oder On-Premise)   │
└──────────────────────────────────────────────────┘

Ergebnisse in der Praxis

Metrik GPT-4 (Lehrer) Fine-getuntes Llama 8B Differenz
Qualität (domänenspezifisch) 95% 89% -6%
Latenz P95 2,5s 180ms 14x schneller
Kosten pro Anfrage $0,03 $0,002 15x günstiger
Datenresidenz Cloud (US/EU) On-Premise

Typischer Break-even: Ab 1000+ Anfragen/Tag amortisiert sich Fine-Tuning in 2-3 Monaten.

LoRA & QLoRA Fine-Tuning

Was ist LoRA

Low-Rank Adaptation (LoRA) ist eine effiziente Fine-Tuning-Methode, die das gesamte Modell nicht verändert. Stattdessen fügt sie kleine Adaptionsmatrizen (typischerweise 0,1-1% der Parameter) zu bestehenden Schichten hinzu. Vorteile:

  • Schnelles Training — Stunden statt Tage
  • Geringe Anforderungen — 1 GPU reicht (24GB VRAM für 7B-Modell mit QLoRA)
  • Modularität — mehrere LoRA-Adapter für verschiedene Anwendungsfälle möglich
  • Sicherheit — Basismodell bleibt unverändert, Adapter ist eine kleine Datei

Unsere Trainings-Pipeline

  1. Datensammlung — echte Produktionsdaten + synthetische vom Lehrermodell
  2. Datenbereinigung — Deduplizierung, Qualitätsfilterung, Formatstandardisierung
  3. Hyperparameter-Suche — Rang, Alpha, Lernrate, Epochen
  4. Training — LoRA/QLoRA, Gradient Checkpointing, Mixed Precision
  5. Evaluierung — gegen Baseline (Lehrer + Basismodell), Golden Dataset
  6. Iteration — erreicht die Qualität den Schwellenwert nicht, wird iteriert (mehr Daten, andere Hyperparameter)
  7. Merge & Deploy — LoRA in Basismodell mergen, quantisieren, deployen

Qualität der Trainingsdaten

Qualität > Quantität. Unsere Regeln:

  • Diversität — gesamten Bereich der Anwendungsfälle abdecken, nicht nur einfache Fälle
  • Grenzfälle — explizit schwierige Beispiele einbeziehen
  • Negative Beispiele — Beispiele, bei denen die richtige Antwort „Ich weiß nicht” oder Eskalation ist
  • Konsistenz — gleicher Stil, Format, Detailgrad
  • Validierung — Domänenexperte validiert 100% der Trainingsdaten

Inferenz-Optimierung

Fine-Tuning ist die halbe Geschichte. Die andere Hälfte ist, wie man das Modell effizient in der Produktion bereitstellt.

Quantisierung

Reduzierung der Berechnungspräzision von FP16 auf INT8 oder INT4:

Methode Größe (7B-Modell) Qualität Geschwindigkeit
FP16 14 GB 100% (Baseline) 1x
INT8 (GPTQ) 7 GB 99,5% 1,3x
INT4 (AWQ) 3,5 GB 98% 1,8x
INT4 (GGUF) 4 GB 97% 1,5x (CPU!)

Für die meisten Produktionsanwendungsfälle ist INT8 der Sweet Spot — minimaler Qualitätsverlust, signifikante VRAM-Reduktion und Beschleunigung.

Batching & KV-Cache

Continuous Batching: Gleichzeitige Verarbeitung mehrerer Anfragen. Das Framework (vLLM, TGI) batchet Anfragen automatisch und teilt den KV-Cache zwischen ihnen. Durchsatz 3-5x höher als naive sequenzielle Verarbeitung.

KV-Cache-Optimierung: PagedAttention (vLLM) verwaltet Speicher für den KV-Cache effizient. Eliminiert Fragmentierung, ermöglicht höhere Batch-Größe.

Spekulative Dekodierung

Ein kleines Draft-Modell (z.B. Llama 1B) generiert Kandidaten-Token, das große Modell verifiziert sie in einem Forward Pass. 2-3x Beschleunigung für Aufgaben mit vorhersehbarer Ausgabe (strukturierter Text, Code).

Inferenz-Stack für die Produktion

┌──────────────────────────────────────────────────┐
│  LOAD BALANCER (nginx, envoy)                     │
│       │                                           │
│       ▼                                           │
│  API GATEWAY (Rate Limiting, Auth, Routing)       │
│       │                                           │
│       ▼                                           │
│  INFERENZ-SERVER (vLLM / TGI / Triton)           │
│  - Continuous Batching                            │
│  - KV-Cache-Management                           │
│  - Quantisiertes Modell                          │
│  - GPU-Autoscaling                               │
│       │                                           │
│       ▼                                           │
│  MONITORING (Latenz, Durchsatz, GPU-Auslastung)  │
└──────────────────────────────────────────────────┘

Modellauswahl-Leitfaden

Anwendungsfall Empfohlenes Modell Warum
Allgemeiner Assistent GPT-4 / Claude Höchste Qualität, kein Fine-Tuning nötig
Domänen-QA (hohes Volumen) Fine-getuntes Llama 8B Niedrige Kosten, niedrige Latenz
Code-Generierung Fine-getuntes CodeLlama / DeepSeek Code-Spezialisierung
Dokumentenextraktion Fine-getuntes Mistral 7B Strukturierte Ausgabe, Konsistenz
Embedding/Retrieval Nomic / BGE / domänengetunt Retrieval-Qualität in Ihrer Domäne
On-Premise (Regulierung) Llama / Mistral + LoRA Keine Daten in die Cloud

Optimierungsprozess

Phase 1: Analyse (1 Woche)

  • Audit des bestehenden KI-Systems (Modelle, Kosten, Qualität, Latenz)
  • Identifikation von Optimierungsmöglichkeiten
  • Kosten-Nutzen-Analyse Fine-Tuning vs. Prompt Engineering vs. Modellwechsel

Phase 2: Experimentierung (2-3 Wochen)

  • Trainingsdaten-Sammlung & -Vorbereitung
  • Fine-Tuning-Experimente (3-5 Konfigurationen)
  • Evaluierung gegen Baselines
  • Inferenz-Optimierung (Quantisierung, Batching)

Phase 3: Produktion (1-2 Wochen)

  • Deploy des optimierten Modells (Shadow-Modus → A/B-Test → vollständiger Rollout)
  • Monitoring-Einrichtung
  • Leistungsvalidierung auf Produktions-Traffic

Phase 4: Iteration (fortlaufend)

  • Kontinuierliche Feedback-Datensammlung
  • Periodisches Re-Training (vierteljährlich oder bei Drift)
  • Evaluation neuer Modelle (neue Basismodelle)

Häufig gestellte Fragen

Prompt Engineering ist immer der erste Schritt — schneller und günstiger. Fine-Tuning lohnt sich wenn: eine spezifische Domäne konsistentes Verhalten erfordert, Sie Latenz/Kosten senken müssen (kleineres Modell), oder On-Premise betreiben müssen (Regulierung). Wir analysieren Ihren Anwendungsfall und empfehlen den optimalen Ansatz.

Für LoRA-Fine-Tuning typischerweise 500-5000 qualitativ hochwertige Beispiele. Für Wissensdestillation generieren wir synthetische Daten vom großen Modell — definieren Sie einfach Domäne und Anwendungsfälle. Qualität > Quantität — 500 perfekte Beispiele > 5000 durchschnittliche.

Ja, das ist einer der Hauptanwendungsfälle. Wir fine-tunen Llama, Mistral, Qwen auf Ihren Daten, optimieren (Quantisierung, KV-Cache), deployen auf Ihrer Infrastruktur. Keine Daten verlassen Ihre Umgebung.

Rigorose Evaluierung: Golden Dataset (200+ Paare), A/B-Test gegen Baseline, Regressionstests auf allgemeine Fähigkeiten. Das fine-getunte Modell muss in Ihrer Domäne besser sein und darf bei allgemeinen Aufgaben nicht mehr als 5 % nachlassen.

Haben Sie ein Projekt?

Lassen Sie uns darüber sprechen.

Termin vereinbaren