Lokale LLMs 7B vs 14B vs 32B: was reicht für was

Einordnung

Abschnitt 01

Die Open-Source-Modellfamilie — die Optionen

Die gängigen Open-Source-Modellfamilien erscheinen in mehreren Varianten. Die für KMU relevanten: 7B-Modell-Instruct (allgemeine Aufgaben, Standard-Triage). 14B-Modell-Instruct (mittelschwere Generierung, Brand-Voice-Texte). 32B-Modell-Instruct (komplexes Reasoning, Mehrschritt-Logik). Code-Varianten 7B/14B/32B (spezialisiert auf Code-Generierung). Mathe-Varianten 7B/72B (spezialisiert auf mathematische Probleme). Alle Modelle sind unter Apache 2.0-Lizenz, kommerzielle Nutzung explizit erlaubt. Bei DripBack nutzen wir die Instruct-Varianten als Standard, gelegentlich eine Code-Variante für interne Entwicklungs-Tools.

Abschnitt 02

Performance-Profile bei DripBack-Workloads

Richtwerte für die Performance-Profile (Q4-Quantisierung auf RTX 5080): 7B-Modell: First-Token-Latency 240 ms (Median), Throughput 78 Tokens/s, Memory-Footprint 5.2 GB VRAM. 14B-Modell: 380 ms, 42 Tokens/s, 9.4 GB VRAM. 32B-Modell (auf 2× RTX 5080 SLI): 700 ms, 18 Tokens/s, 19.8 GB VRAM. Bei Klassifikations-Tasks ist die Latenz wichtiger als der Throughput (kurze Antworten). Bei Generierungs-Tasks zählt der Throughput.

Abschnitt 03

Qualitäts-Vergleich auf realen Tasks

Qualitäts-Bewertung über drei DripBack-Standard-Tasks: (1) Mail-Triage: 7B erreicht 87% korrekte Klassifikation, 14B 91%, 32B 92%. Die Marginal-Verbesserung ab 14B ist gering. (2) Antwort-Drafting in Brand-Voice: 7B Score 6.8/10 (sachlich aber etwas roh), 14B 8.2/10 (deutlich natürlicher), 32B 8.5/10. Hier macht 14B den großen Sprung. (3) Mehrschritt-Reasoning (Beratungs-Frage mit 3 Logik-Schritten): 7B 62%, 14B 78%, 32B 89%. Hier ist 32B deutlich besser. Konsequenz: Modell-Wahl nach Task-Komplexität.

Abschnitt 04

Anwendungsfall zu Modell-Matrix

Empfehlung pro Anwendungsfall: Mail-Triage einfache Kategorien (E-Mail-Triage): 7B-Modell reicht. Mail-Triage mit komplexem Routing + Antwort-Draft (Steuer-Triage Pro): 14B-Modell. Schichtplan-Validierung mit Constraint-Erläuterung (Schichtplan-KI): 7B-Modell (eigentliche Logik in Or-Tools). Buchhaltung-Auto Kontierungs-Vorschlag (Buchhaltung-Auto): 14B-Modell (wegen Kontext-Verständnis). Anwalts-Research Argumentation (Anwalts-Research-KI): 32B-Modell (komplexes juristisches Reasoning). DSGVO-Audit Findings-Beschreibung (DSGVO-KI-Audit-Suite): 14B-Modell (gute Sprach-Qualität wichtig). Council-Review (Council-Review SaaS): 32B-Modell als einer der 5 Council-Mitglieder.

Abschnitt 05

Strom-Kosten pro Modell

Aus 24h-Monitoring in eigenen Test-Setups: 7B-Modell bei 50% Auslastung: rund 180 Watt mittlere Last. 14B-Modell bei 50%: rund 220 Watt. 32B-Modell (2× GPU): rund 380 Watt gesamt. Bei 18 Stunden täglich aktiv: 7B ~ 0.7 kWh/Tag = 21 kWh/Mo = rund 7 €/Mo Strom. 14B ~ 8 €/Mo. 32B ~ 14 €/Mo. Diese Marginal-Kosten sind so niedrig, dass die Modell-Wahl in der Praxis fast immer von der Qualitäts-Anforderung getrieben wird, nicht von Strom-Kosten.

Abschnitt 06

Cloud-Pricing-Vergleich

Im Vergleich zu Cloud-LLMs: 7B-Modell lokal: rund 0.02 € Strom pro 1000 Calls. Anbieter A · Kleinmodell: 0.80 € input / 4 € output pro 1M Tokens = bei 1000 Calls á 500 Tokens etwa 0.30 € pro 1000 Calls. Anbieter B · Mini: 0.15 € input / 0.60 € output pro 1M = etwa 0.05 € pro 1000 Calls. Anbieter B · Multimodal: rund 0.50 € pro 1000 Calls. Für hohe Volumen (>1500 Calls/Tag) ist lokales Open-Source-Modell wirtschaftlicher als Cloud, bei niedrigem Volumen (<300 Calls/Tag) ist Cloud effizienter. Bei DSGVO-/§203-Anforderungen ist lokales Open-Source-Modell oft alternativlos, unabhängig von Volumen.

Abschnitt 07

Hybrid-Routing-Strategie

Die wirtschaftlich beste Architektur ist Hybrid-Routing: 80% der Anfragen via lokales Open-Source-Modell, 15% via Cloud-Klein-/Mittelklasse, 5% via Cloud-Frontier. Bei DripBack lebt diese Logik in llm_router.py. Anfrage-Komplexität wird via Pre-Klassifikator (lokales 7B-Modell) bestimmt, dann an passendes Modell geroutet. Sensible Daten (Patient, Mandant) gehen NIE an Cloud, sondern bleiben lokal. Diese Strategie reduziert Cloud-Kosten gegenüber Cloud-only-Setup um 70-85%, mit gleichem oder besserem Qualitäts-Profil.

Abschnitt 08

Hardware-Kosten pro Modell

Mindest-Hardware für jedes Modell: 7B-Modell: 1× RTX 5080 16GB ausreichend (3.500-4.500 € Custom-Server). 14B-Modell: 1× RTX 5080 16GB ausreichend, aber Headroom eng. Für parallele Workloads: 1× RTX 4090 24GB oder 5090 32GB besser (5.500-7.500 € Custom-Server). 32B-Modell: 2× RTX 5080 SLI oder 1× RTX 5090 32GB (8.000-10.000 € Custom-Server). Bei höchsten Qualitäts-Anforderungen: 2× RTX 5090 für ein 72B-Modell (15.000+ €). Für die meisten KMU reicht 1× RTX 5080 mit einem 14B-Modell als Maximum.

Abschnitt 09

Wann Cloud-LLMs trotzdem sinnvoll sind

Drei Konstellationen, in denen Cloud-LLMs trotz Self-Hosting-Möglichkeit gewählt werden: (1) Sehr seltene aber komplexe Anfragen (z.B. 1× pro Woche eine 50-Seiten-Vertrag-Analyse) — ein Cloud-Frontier-Modell ist hier effizienter als eigenes 70B-Modell zu hosten. (2) Brand-Voice-Texte mit höchstem Anspruch — Anbieter A · Mittelklasse ist messbar besser als 14B-Modell für deutsche Marketing-Texte. (3) Multi-Step-Code-Refactoring — Anbieter A · Frontier ist die Premium-Lösung. Bei DripBack haben wir für solche Edge-Cases Cloud-Fallback eingebaut, aktiviert via konfigurierbarer Schwelle.

Abschnitt 10

Modell-Update-Strategie

Open-Source-Modelle werden regelmäßig aktualisiert. Standard-Empfehlung: minor-Update (z.B. 2.5.1 → 2.5.2) wird automatisch eingespielt im Wartungs-Fenster. Major-Update (z.B. 2.5 → 3.0) wird zuerst in Test-Umgebung evaluiert, dann nach 30 Tagen produktiv. Bei DripBack betreuen wir Customer mit kontinuierlichem Modell-Update-Service: monatlich Test, vierteljährlich produktive Migration. Dies stellt sicher, dass die Modell-Qualität nicht über die Zeit absinkt (sondern eher steigt mit besseren Modell-Versionen).