Wie man das richtige KI-Modell für die Aufgabe wählt (und nicht für den Hype)

Die häufigste Frage lautet: „Welches KI-Modell ist das beste?“. Das ist die falsche Frage – wie „Welches Auto ist das beste?“, ohne zu sagen, ob man Zement transportiert oder auf der Rennstrecke fährt. Die bessere Frage: Welches Modell für diese konkrete Aufgabe, bei meinen Kosten und meinen Daten?

Modelle unterscheiden sich im Profil, nicht in der „allgemeinen Intelligenz“. Eines startet die Antwort in 0,4 s, ist aber kleiner. Ein anderes hat ein Kontextfenster von einer Million Token, antwortet aber langsam. Ein drittes schreibt hervorragend Code, fasst aber schlecht zusammen. Die Wahl „eines für alles“ bedeutet, dass man für einfache Aufgaben mit Leistung überzahlt und bei schwierigen an Qualität mangelt.

Deshalb setzen wir nicht auf ein Modell, sondern auf einen Router, der über eine ganze Flotte verfügt und daraus das passende Werkzeug für das Problem auswählt.

Zuerst benenne die Aufgabe, dann wähle die Modellklasse. In der Praxis reichen einige Kategorien:

• Gespräch / Assistent auf Wissensbasis – ein Instruct-Modell mit guter Balance zwischen Qualität und Latenz.
• Schlussfolgerung – ein „denkendes“ Modell (siehe unten), bewusst eingesetzt, wo Treffsicherheit der Entscheidung zählt.
• Code – ein auf Programmierung spezialisiertes Modell; Durchsatzleistung zählt, da Antworten oft lang sind.
• Schnell / günstig / Klassifizierung – ein kleines, blitzschnelles Modell für Intent-Routing, Tagging, Feldextraktion.
• Vision – ein multimodales Modell, das Bild und Text gemeinsam versteht.
• Zusammenfassen – ein nicht-„denkendes“ Modell, das kondensiert, statt zu philosophieren.

Diese Aufgaben→Modell-Map pflegen wir als konkrete Routing-Matrix – jede Aufgabe hat ein Haupt- und ein Backup-Modell. Sieh dir an, welches Modell was übernimmt, im Modellatlas, und wie wir sie zu fertigen Systemen zusammenbauen – im Abschnitt wie wir es bauen.

Modellnamen suggerieren Geschwindigkeit und Qualität, die nicht vorhanden sind. „Flash“, „pro“, „large“ sind Marketing, keine Messung. Aus unseren eigenen Messungen: Ein Modell mit „flash“ im Namen schafft manchmal 0,6 Token pro Sekunde (sehr langsam), während ein großes „671B“-Modell 45 Token pro Sekunde liefert (sehr schnell). Würden wir dem Namen vertrauen, hätten wir das Gegenteil gewählt.

Deshalb wählen wir jedes Modell durch Messung aus: Zeit bis zum ersten Token (TTFT), Durchsatzleistung (Token/s), reales Kontextfenster und ob das Modell überhaupt Inhalt im jeweiligen Modus zurückgibt. Die Zahlen auf den Modellseiten stammen vom Live-Router, nicht aus Datenblättern.

Einige moderne Modelle sind „denkende“ Modelle: Bevor sie antworten, führen sie interne Schlussfolgerungen durch. Das ist mächtig bei schwierigen Entscheidungen – und teuer sowie langsam bei einfachen Aufgaben. Schlimmer noch: Wenn man sie „zwangsweise“ für normalen Chat einsetzt, können sie das gesamte Budget für Schlussfolgerungen verbrennen und eine leere Antwort zurückgeben.

Die Regel ist einfach: Den Schlussfolgerungsmodus nur für Aufgaben aktivieren, die ihn wirklich erfordern (Analyse, Schrittplanung für Agenten, schwierige Entscheidungen). Für Gespräche, Übersetzungen, Code und Zusammenfassungen ausschalten – schneller, günstiger und mit garantiertem Inhalt. Der Router übernimmt das automatisch für dich.

Die Auswahl hängt nicht nur von der Qualität ab:

• Kosten – die Cloud rechnet nach GPU-Laufzeit ab, daher ist ein langsameres/größeres Modell eine teurere Antwort. Das günstigste Modell, das die Aufgabe bewältigt, gewinnt.
• Sensible Daten – wenn du regulierte Daten (RODO) verarbeitest, halte einen Teil der Verarbeitung lokal; Embeddings lokal berechnen und PII maskieren, bevor etwas in die Cloud geht.
• Zuverlässigkeit – ein einzelnes Modell kann vorübergehend überlastet sein; daher hat jede Aufgabe eine Backup-Kette, keinen einzelnen Ausfallpunkt.

Wenn du das konkret für deinen Fall durchgehen möchtest, haben wir einen interaktiven Stack-Auswahlassistenten – ein paar Fragen und eine Empfehlung für die Schichten, inklusive Modelle.

Das folgende Beispiel startet ein Modell über unseren sicheren Sandbox – denselben wie im Playground: PII maskiert, keine Retention, dieselben Limits. Stelle eine Frage zur Modellauswahl und sieh dir die Antwort an.

Kein einzelnes. Am besten ist ein Router, der für jede Aufgabe das günstigste Modell auswählt, das sie bewältigen kann – Gespräche, Schlussfolgerungen, Code, Vision und Zusammenfassungen haben unterschiedliche Profile, daher unterschiedliche Modelle. Die Wahl „eines für alles“ führt entweder zu Überzahlung bei einfachen Aufgaben oder zu Qualitätsmängeln bei schwierigen.

Durch Messung, nicht durch den Namen. Prüfe die Zeit bis zum ersten Token, Durchsatzleistung (Token/s), reales Kontextfenster und ob das Modell im jeweiligen Modus Inhalt zurückgibt. Namen wie „flash“ oder „large“ können irreführend sein – manchmal ist ein „flash“-Modell langsamer als ein großes Modell.

Nur bei Aufgaben, die wirklich Schlussfolgerungen erfordern – Analyse, Planung, schwierige Entscheidungen. Für Gespräche, Übersetzungen und Zusammenfassungen den Schlussfolgerungsmodus ausschalten: Er ist langsamer, teurer und kann eine leere Antwort liefern, wenn die Aufgabe ihn nicht braucht.

Kann man, aber es lohnt sich selten. Ein Modell für alles bedeutet, dass man für einfache Aufgaben mit Leistung überzahlt und bei schwierigen Kompromisse bei der Qualität eingeht. Ein Router mit mehreren Modellen ist günstiger und zuverlässiger, und die Komplexität übernimmt die Schicht, nicht du.