Die Frage „Welches Modell ist das beste?“ führt bei Unternehmensprojekten selten zu einer guten Architektur. Entscheidend ist, welches Modell eine klar definierte Aufgabe mit ausreichender Qualität, vertretbaren Kosten und passendem Datenschutz erfüllt. In vielen Projekten ist die richtige Antwort keine einzelne Modellfamilie, sondern ein kontrollierter Hybridbetrieb.
Mit Datenklassen beginnen
Bevor Benchmarks verglichen werden, sollten die verarbeiteten Informationen klassifiziert werden. Öffentliche Produkttexte haben einen anderen Schutzbedarf als unveröffentlichter Quellcode, Personalakten, juristische Dokumente oder Details zu einer noch offenen Schwachstelle.
Eine einfache Einteilung kann so aussehen:
| Datenklasse | Beispiel | Möglicher Modellbetrieb |
|---|---|---|
| öffentlich | veröffentlichte Dokumentation | externe API möglich |
| intern | Prozesswissen ohne Personenbezug | vertraglich geprüfte API oder lokal |
| vertraulich | Quellcode, Verträge, Kundendaten | lokal oder stark kontrolliert |
| besonders kritisch | Zugangsdaten, Schwachstellen, Geheimnisse | nicht an das Modell oder streng isoliert lokal |
Die Klassifizierung ersetzt keine Datenschutzprüfung. Sie schafft aber eine technische Regel, die Anwendungen tatsächlich durchsetzen können. Ein Nutzer sollte nicht bei jeder Anfrage selbst entscheiden müssen, ob ein Dokument eine externe Umgebung verlassen darf.
Qualität an der eigenen Aufgabe messen
Öffentliche Benchmarks zeigen allgemeine Fähigkeiten unter bestimmten Bedingungen. Sie sagen wenig darüber aus, ob ein Modell die internen Abkürzungen, Dokumentstruktur oder Werkzeugverträge eines konkreten Produkts beherrscht. Deshalb braucht die Auswahl einen eigenen Eval-Datensatz.
Gemessen werden können:
- fachliche Richtigkeit und Vollständigkeit,
- Quellenbindung und zulässige Ablehnungen,
- strukturierte Ausgabe und Tool-Calling,
- Latenz und Durchsatz,
- Kontextgröße und Speicherbedarf,
- Kosten pro erfolgreicher Aufgabe.
Ein günstiger Lauf ist teuer, wenn er häufig manuell korrigiert werden muss. Umgekehrt ist das stärkste Modell unwirtschaftlich, wenn ein kleineres lokales Modell den eng begrenzten Prozess zuverlässig erfüllt.
Was lokale Inferenz wirklich bedeutet
Ein Modell auf eigener Hardware verhindert zunächst nur, dass Eingaben für die Inferenz an einen externen Modellanbieter gesendet werden. Sicherheit entsteht erst durch den gesamten Betrieb:
- Modellartefakte und Container stammen aus nachvollziehbaren Quellen.
- API und Administrationsoberfläche sind nicht öffentlich erreichbar.
- Nutzer, Dienste und Projekte erhalten getrennte Rechte.
- Prompts, Ausgaben und Logs werden passend zur Datenklasse gespeichert oder verworfen.
- Werkzeuge und Datenquellen des Modells sind zusätzlich autorisiert.
- Updates, Monitoring und Kapazitätsgrenzen sind geregelt.
Lokale Inferenz ist also kein einzelner Datenschutzschalter. Sie ist ein eigenes System, das betrieben und überprüft werden muss.
Frontier-Modelle sinnvoll einsetzen
Externe Frontier-Modelle bieten häufig hohe allgemeine Qualität, große Kontexte und neue Fähigkeiten ohne eigene GPU-Bereitstellung. Für öffentliche oder ausreichend bereinigte Aufgaben können sie Entwicklung und Verarbeitung erheblich beschleunigen.
Vor dem Einsatz werden Vertragsbedingungen, Datenstandort, Aufbewahrung, Training mit Kundendaten, Unterauftragsverarbeiter und technische Löschmöglichkeiten geprüft. API-Zugangsdaten gehören in einen serverseitigen Secret Store, nicht in Browser oder mobile App. Kosten- und Rate-Limits verhindern unkontrollierte Nutzung.
Hybridbetrieb als klare Route
In einem Hybridmodell entscheidet eine serverseitige Policy anhand von Aufgabe und Datenklasse. Öffentliche Zusammenfassungen können ein externes Modell nutzen. Vertrauliche Codeanalyse wird an eine lokale Inferenzroute geschickt. Besonders kritische Geheimnisse werden vor jeder Modellverarbeitung entfernt.
Die Route muss beobachtbar sein. Für jeden Lauf sollte nachvollziehbar bleiben, welche Modellklasse, welche Datenquellen und welche Richtlinie verwendet wurden. Ein stiller Fallback vom lokalen auf ein externes Modell wäre ein Datenschutzfehler, auch wenn die Antwort fachlich gut ist.
Eigene Hardware wirtschaftlich einordnen
Lokale Systeme verursachen Anschaffung, Strom, Wartung und Kapazitätsplanung. Dafür bieten sie kontrollierbare Datenwege, vorhersagbare Nutzungskosten und die Möglichkeit, Modelle für interne Aufgaben dauerhaft bereitzustellen. Eine Workstation mit viel RAM und mehreren GPUs deckt kompakte und mittelgroße Modelle sowie parallele Evaluationen ab. Systeme mit großem einheitlichem Speicher erweitern den möglichen Modell- und Kontextumfang.
Entscheidend ist nicht die beeindruckendste Modellgröße. Quantisierung, Batch-Größe, Kontext und gewünschter Durchsatz bestimmen, was praktisch funktioniert. Vor einer Architekturentscheidung wird mit echten Aufgaben gemessen.
Eine Entscheidungsmatrix statt Modellreligion
Jeder Kandidat läuft gegen dasselbe Testset und dieselben Betriebsgrenzen. Die Gewichtung wird vor dem Test festgelegt:
| Kriterium | Messung | Beispielgewicht |
|---|---|---|
| Aufgabenqualität | Anteil bestandener Referenzfälle, kritische Fehler separat | 35 % |
| Datenschutz | zulässige Datenklassen und tatsächlicher Datenweg | Ausschlusskriterium |
| Latenz | p50 und p95 pro vollständiger Aufgabe | 15 % |
| Durchsatz | erfolgreiche Aufgaben pro Minute bei Ziellast | 10 % |
| Kosten | Infrastruktur und API-Kosten pro erfolgreicher Aufgabe | 20 % |
| Betrieb | Updates, Monitoring, Ausfallroute und benötigtes Wissen | 20 % |
Quantisierte und unquantisierte Varianten gelten als eigene Kandidaten. Ein automatischer Fallback darf nur in eine Route mit gleicher oder strengerer Datenfreigabe erfolgen. Diese Matrix macht auch eine hybride Entscheidung erklärbar: nicht „Modell A ist besser“, sondern „Route A erfüllt Aufgabe und Schutzklasse zu diesen Kosten“.
Für wissensbasierte Systeme liefert der Leitfaden zu RAG-Evals die Qualitätsmetriken. Bei autonomen Abläufen ergänzt AI-Agenten absichern die Kontrolle von Werkzeugen, Budgets und Freigaben.
Quellen und Vertiefung
- NIST AI Risk Management Framework
- BSI: Generative AI Models
- OWASP Top 10 for LLM Applications
- European Commission: AI Act
Fazit
Die Modellwahl folgt Aufgabe und Schutzbedarf. Frontier-Modelle können Geschwindigkeit liefern, lokale Modelle schaffen kontrollierte Datenwege, und ein sauberer Hybridbetrieb verbindet beide Optionen. Qualität und Datenschutz müssen dabei als technische Regeln messbar sein, nicht nur als Zusage im Projektgespräch.