GPT-5.4 Mini/Nano in LiteLLM

Um die neuen GPT-5.4 Modelle in meine bestehenden Tools zu integrieren und gleichzeitig die API-Kosten im Griff zu behalten, habe ich mein KI-Setup rund um das LLM-Gateway LiteLLM überarbeitet. Anstatt Modellnamen hart in Skripte zu codieren, setze ich auf eine zentrale Abstraktionsschicht.

Modell-Klassen und Kosten-Forecast

In LiteLLM habe ich GPT-5.4 Nano in meine "Cheap"-Klasse und GPT-5.4 Mini als "Mid-Tier" konfiguriert. Ein Neustart des Gateways reichte, damit alle meine Prototypen die neuen, effizienteren Modelle nutzen.

Um die Ausgaben bei solchen Experimenten zu überwachen, reichte mein reines Rückblick-Monitoring nicht mehr aus. Ich habe mein Skript um eine dynamische Monatsprognose erweitert: (Bisherige Kosten / Vergangene Tage) * Monatstage. Das System warnt mich nun mit einem 24-Stunden-Cooldown, sobald die Prognose 100% oder 120% meines festgesetzten Budgets erreicht. So erkenne ich frühzeitig, wenn ein Prototyp zu teuer skaliert.

Routing-Tücken bei Reasoning-Modellen

Beim Multi-Model-Routing fielen mir plötzlich hohe Fehlerraten auf. Die Analyse der Gateway-Logs zeigte: Es lag nicht an überlasteten Modellen, sondern an einem Kompatibilitäts-Bug. Neuere Modelle nutzen oft interne "Thinking"- oder "Reasoning"-Prozesse. Leitet das Gateway eine solche Unterhaltung an ein anderes Modell (z.B. Mistral) weiter, lehnt dessen API die Anfrage ab, weil sie das Format nicht versteht. Ähnliches passierte bei spezifischen Tool-Calls von Anthropic. Das Gateway muss diese anbieterspezifischen Meta-Daten erst sauber herausfiltern.

Meine wichtigsten Learnings: * Nutze Alias-Namen (model-cheap, model-smart) in einem Gateway, um Modelle im Hintergrund auszutauschen, ohne eine Zeile Code in deinen eigentlichen Produkten zu ändern. * Beim nahtlosen Wechsel zwischen verschiedenen APIs musst du Schnittstellen-Fehler einkalkulieren, da Features wie Thinking-Tokens oder Tool-Calls oft nicht 1:1 zwischen den Anbietern übertragbar sind.