Warum agentische KI einen offenen Inferenz-Stack benötigt

„Die meisten KI-Labore verlieren derzeit Geld, während sie Ihr Unternehmen bedienen. Sie wissen es. Und sie tun es mit Absicht.“

Das war die erste Zeile eines Artikels, der in derselben Woche in meinem Posteingang landete, in der 3 Zahlen Gestalt annahmen und verdeutlichten, warum offene Inferenz nicht mehr optional ist.

Ein Entwickler hat an einem Wochenende mit einem Open Source Coding Agent und einem direkten API-Schlüssel eine einfache Notizen-App erstellt. Eine Seite, eine Funktion. Kosten: 50 USD Am nächsten Tag bot eine Subskription für 20 USD/Monat 50-mal mehr Token.

Ein Engineer in unserem Team hat innerhalb von 2 Tagen 300 Millionen Token durch Open Weight-Modelle verbraucht und damit denselben Arbeitsaufwand erledigt, der mit proprietären APIs Tausende USD gekostet hätte.

Die ersten 2 Zahlen verdeutlichen die Subvention. Die dritte zeigt den Ausweg. Und der Grund, warum wir diesen Ausweg brauchen, sind Agenten.

Das Preismodell befindet sich im Wandel

Die Anbieter von Frontier-Modellen haben etwas Bemerkenswertes erreicht. Sie haben erstklassige KI für Millionen von Entwickelnden zu Preisen zugänglich gemacht, die vor 2 Jahren undenkbar gewesen wären. Diese Zugänglichkeit hat zu einer explosionsartigen Zunahme der Akzeptanz geführt. Sie hat zudem eine Wirtschaftsstruktur geschaffen, die beim derzeitigen Tempo möglicherweise nicht nachhaltig ist.

Die Website Is AI profitable yet? verfolgt das allgemeine finanzielle Bild der KI-Branche. KI-Unternehmen geben derzeit etwa 195 % ihres Umsatzes aus. Eine am Diskurs beteiligte Person berechnete, dass die gesamten KI-Investitionsausgaben in 10 Jahren in USD-Äquivalenten von 2024 etwa das Dreifache der Kosten des gesamten US-amerikanischen Interstate Highway System betragen haben. Dies sind Investitionen, die sich letztendlich in den Servicepreisen widerspiegeln werden.

Anzeichen für diesen Übergang zeichnen sich bereits ab. Berichten zufolge überdenken einige große Unternehmen die Lizenzen für KI-Coding-Tools, da die tokenbasierte Abrechnung Pauschalsubskriptionen ersetzt und die Kosten pro Engineer 500 bis 2.000 USD pro Monat erreichen. Neuere Frontier-Modelle liefern geringfügige Benchmark-Verbesserungen, während sie 10 % bis 25 % mehr Token pro Aufgabe verbrauchen. Das GPU-Angebot ist bereits für die nächsten 3 bis 4 Jahre gebunden, und bei mehreren GPU-Cloud-Anbietern sind die Kapazitäten bereits erschöpft.

Nichts davon ist als Kritik an den Anbietern zu verstehen. Sie bauen die Zukunft und setzen auf eine aggressive Preisgestaltung, um die Einführung zu beschleunigen. Die Stückkosten pro Token werden wahrscheinlich weiter sinken, und Gartner prognostiziert eine Reduzierung um 90 % bis 2030. Wie dieselbe Analyse jedoch anmerkt, verbrauchen agentische Workloads so viel mehr Token pro Aufgabe, dass die Gesamtausgaben von Unternehmen für Inferenz trotz günstigerer Einheiten voraussichtlich steigen werden. Goldman Sachs prognostiziert einen 24-fachen Anstieg des Token-Verbrauchs bis 2030. Unternehmen, die für die nächsten 3 bis 5 Jahre planen, sollten sich auf höhere Gesamtkosten einstellen, nicht auf niedrigere. Open Source-Modelle, die auf einer selbst gemanagten Infrastruktur ausgeführt werden, dienen als Sicherheitsventil, das KI auch bei steigendem Verbrauch zugänglich hält.

Abbildung 1: Das Kostenparadoxon der agentischen Inferenz. Die Kosten pro Token sinken um 90 % (Gartner), aber der Gesamtverbrauch steigt um das 24-fache (Goldman Sachs), was trotz günstigerer Einheiten zu höheren Gesamtausgaben für Unternehmen führt.

Agenten verändern die Rechnung

Die Preise für Subskriptionen wurden für Menschen konzipiert, die mit menschlicher Geschwindigkeit tippen. Agenten generieren um ein Vielfaches mehr API-Aufrufe, und kein bestehendes Preismodell wurde dafür entwickelt.

Ein Mitwirkender bei OpenClaw verbrauchte in einem einzigen Monat OpenAI-API-Token im Wert von 1,3 Millionen USD. Das sind 603 Milliarden Token bei 7,6 Millionen Anfragen von etwa 100 Codex-Instanzen, die von 3 Personen betrieben werden. An einem einzigen Tag verzeichnete dieses Konto Ausgaben in Höhe von 19.985,84 USD.

Jensen Huang gab an, dass der Token-Verbrauch von Agenten im Vergleich zur traditionellen Modellnutzung um etwa das 1.000-fache gestiegen ist. Im Latent Space-Podcast sagte Marc Andreessen, dass sein Umfeld täglich 1.000 USD für Claude-Token zum Betrieb von Agenten ausgibt, bei einer latenten Nachfrage von 5.000 bis 10.000 USD pro Tag und vollständig bereitgestelltem persönlichem Agenten. Selbst bei einer 10-fachen Preisverbesserung wären das immer noch 100 USD pro Tag. „Das liegt immer noch weit über dem, was Menschen bezahlen können.“

Einige Anbieter mussten bereits die Nutzung von Agent-Frameworks von Drittanbietern im Rahmen von Pauschalsubskriptionen einschränken, da der Rechenbedarf die Tragfähigkeit des Preismodells überstieg. Pauschalpreise und autonome Agent-Workloads passen strukturell nicht zusammen.

Die Kosten sind nur ein Teil des Problems. Agentische Workloads haben technische Anforderungen, für die proprietäre APIs nie konzipiert wurden.

API-Fragmentierung. Die agentische API-Landschaft weist mehrere konkurrierende Standards auf. Chat Completions (das ursprüngliche zustandslose Format von OpenAI), Responses API (das neuere zustandsbehaftete Format von OpenAI mit integrierten Tools und Model Context Protocol-Integration), Messages API (das Format von Anthropic) und Interactions API (das agentische Protokoll von Google). Jedes Format handhabt Tool-Aufrufe, Zustandsverwaltung und Argumentation unterschiedlich. Jedes Harness wählt ein anderes Format.

Jede Modellfamilie umschließt zudem denselben Tool-Aufruf mit völlig unterschiedlichen Tags. Das Senden von get_weather(city="Seattle") an 5 Modelle erzeugt 5 verschiedene Formate: Llama verwendet die Python-Syntax mit <|python_tag|>, Mistral verwendet [TOOL_CALLS] mit JSON-Arrays, Gemma verwendet <tool_code>-Tags und Hermes verwendet <tool_call>XML. Die Inferenz-Engine benötigt für jede Modellfamilie einen separaten Parser.

Tool-Aufrufe. Hinter einer proprietären API erhalten Sie den Parser, den der Anbieter bereitstellt. Sie können ihn nicht anpassen. Sie können ein Modell nicht korrigieren, das eine Python-typische Syntax anstelle seines trainierten Formats ausgibt. Sie sitzen nur auf dem Beifahrersitz.

Modell-Routing Ein einzelner Agent-Durchlauf generiert heterogene Teilaufgaben; einige erfordern tiefe Argumentation, andere eine schnelle Klassifizierung und wieder andere Code-Generierung. Das Routing dieser Aufgaben an verschiedene Modelle erfordert Kontrolle über die Bereitstellungsebene. Hinter der API eines einzelnen Anbieters wird jede Aufgabe an dasselbe Modell zum gleichen Preis gesendet.

Context Engineering Die Verwaltung dessen, was das Modell über viele Durchläufe hinweg erreicht, ist die effektivste verfügbare Optimierung. Eine gut abgestimmte Kontext-Pipeline kann die Token-Nutzung um 60 % bis 80 % reduzieren und gleichzeitig die Ausgabequalität verbessern. Effektives Context Engineering erfordert jedoch Zugriff auf das Modellverhalten auf Inferenzebene. Denn Sie müssen messen, worauf das Modell tatsächlich achtet und welche Kontext-Token zur Ausgabequalität beitragen, um Zusammenfassungs- sowie Retrieval-Strategien auf Basis realer Attention-Muster anzupassen, anstatt auf Vermutungen angewiesen zu sein.

Circuit Breaker. Ohne Kontrolle über die Inferenzschicht können Sie keine Budgets pro Agent, keine Anomalieerkennung oder automatische Abschaltungen auf Modellserverebene implementieren. Da ich selbst schon von einer unkontrollierten Schleife betroffen war, kann ich Ihnen sagen: Der Anbieter wird Sie nicht retten.

Wirtschaftsfachleute nennen dies das Jevons-Paradoxon. William Stanley Jevons bemerkte dieses Muster im Jahr 1865. Als Kohlemaschinen effizienter wurden, stieg der Gesamtkohleverbrauch. KI-Token befinden sich auf demselben Weg. Jeder Effizienzgewinn erschließt neue Use Cases, die mehr verbrauchen, als durch den Gewinn eingespart wurde. Unternehmen, die mehr Ergebnisse pro Token erzielen, werden mehr KI einsetzen, nicht weniger.

Offene Modelle für agentische Aufgaben

Wie oben erwähnt, hat unser Team innerhalb von 2 Tagen 300 Millionen Token mit Open Weight-Modellen verarbeitet. Nemotron 3 Super, Gemma 4 und Qwen 3.6, alle auf dem Inferenz-Stack von Red Hat AI ausgeführt. Das Ergebnis war überzeugend genug für Pull-Request-Reviews, erste Implementierungen und gezielte Untersuchungen, wodurch Aufgaben ausgelagert wurden, die sonst an Frontier-Modelle gegangen wären und Token-Kosten verursacht hätten.

Die Kostenlücke ist nicht marginal. Benchmarks auf Blackwell-GPUs für Endnutzende zeigen, dass eine 500 USD teure GPU, auf der Open Weight-Modelle laufen, 30 Millionen Token pro Tag verarbeiten kann. Bei diesem Volumen amortisieren sich die Hardwarekosten innerhalb von 3 Monaten im Vergleich zu den Kosten derselben Workloads bei günstigen API-Anbietern (ca. 0,20 USD pro Million Token). Gegenüber Frontier-API-Preisen sinkt der Zeitraum für den Return on Investment auf wenige Tage.

Ein Mitglied im Forschungsteam baute einen Coding-Agenten, der in Benchmark-Tests 87 % erreichte – und das mit einem Modell, das nur 4 Milliarden Parameter pro Token aktiviert. Agenten, die Modelle mit 14 Milliarden Parametern nutzten, erreichten 75 %. Der Unterschied lag nicht am Modell, sondern an kombinierten Tools und einer Fehler-Feedback-Schleife. Das Harness leistete die Hauptarbeit, nicht die Modellgröße.

Damit offene Modelle in agentischen Szenarien gut funktionieren, ist echtes Engineering erforderlich – und genau dieses Engineering wird durch Open Source ermöglicht. Eine aktuelle Demo von Gemma 4, die mit OpenCode und Claude Code läuft, zeigt die Praxis: benutzerdefinierte Anpassungen der Chat-Vorlagen, Parser-Tuning für Tool-Aufrufe pro Modellfamilie und Prompt-Formatierung über mehrere API-Standards hinweg. Das Modell mit 4 Milliarden Parametern erforderte eine andere Handhabung als die quantisierte Version mit 26 Milliarden Parametern, die wiederum anders behandelt werden musste als das Modell mit 31 Milliarden Parametern.

Dies ist die Art von Arbeit, die die Lücke zwischen Benchmark-Leistung und realer agentischer Leistung schließt. Sie umfasst die Übersetzung zwischen Chat Completion-, Messages- und Responses-APIs sowie das Parsen von Modellausgaben mit Fuzzy-Logik, da Modelle manchmal ihre Start-Token für Tool-Aufrufe verpassen oder unerwartete Syntax generieren, die von den System-Prompts des Harness beeinflusst wird.

Diese Arbeit findet Upstream in vLLM, in den Chat-Vorlagen der Modellanbieter und in Harness-Fehlerberichten statt. Und sie kann nur offen erfolgen. Mit einem proprietären Inferenzserver können Sie weder einen Fix für eine Chat-Vorlage einreichen noch einen Tool-Call-Parser tunen oder auch nur beobachten, warum die Ausgabe Ihres Agenten fehlschlägt. Mit Open Source profitiert jede Person von jedem Fix, und jedes Parser-Upgrade ist dauerhaft. Diese Upstream-Integrationsarbeit, die Open Weight-Modelle für agentische Workloads über den gesamten Serving-Stack hinweg zuverlässig macht, ist ein Kernfokus von Red Hat AI.

Der agentische Inferenz-Stack

Es gibt 8 Schichten, die für agentische Inferenz auf Unternehmensebene zusammenarbeiten müssen. Jede Schicht interagiert mit jeder anderen Schicht.

Abbildung 2: Der agentische Inferenz-Stack reicht von Agenten und Harness an der Spitze über API-Übersetzung, Gateway, Leitplanken, disaggregiertes Serving, Modellserver-Konfiguration und Inferenz-Engine bis hin zur Hardware an der Basis. Rote Linien markieren die 2 Schichten, in denen der Großteil der agentischen Kompatibilitätsarbeit stattfindet. Die gestrichelte Sandbox-Grenze umschließt die Agenten-Schicht, in der Code-Ausführung und Sicherheitskontrollen am strengsten sind.

Es ist möglich, diese Schichten aus einzelnen Open Source-Projekten zusammenzustellen, aber betrieblich aufwendig. Der Wert einer selbst gemanagten Inferenzplattform wie Red Hat AI liegt darin, dass sie in einen getesteten, unterstützten Stack integriert ist, der auf Ihrer Infrastruktur läuft. So verlassen Ihre Daten nie Ihre Sicherheitsgrenze, und Sie kontrollieren den Upgrade-Zyklus, die Modellauswahl und die Routing-Richtlinien.

Die agentische API-Schicht

Das Problem der API-Diversität ist real. Harnesses nutzen Chat Completions, Responses, Messages API oder Interactions API, und der zugrunde liegende Modellserver unterstützt nicht zwangsläufig alle. Die agentische API-Schicht sitzt zwischen dem Harness und der Infrastruktur, um diese Lücke zu schließen. Projekte wie OGX (ehemals Llama Stack) bieten offene Implementierungen der agentischen APIs selbst: Chat Completions, Responses API, Messages API und Interactions API sowie ergänzende Funktionen wie Vector Stores, Dateiverwaltung und Tool-Ausführung – alles auf der von Ihnen genutzten Modellbereitstellungsschicht.

Derzeit zeichnet sich kein einzelner API-Standard als Sieger ab, trotz des Pioniervorteils einiger APIs. Wichtig ist, dass offene Implementierungen für alle verfügbar sind, damit Sie jedes Harness jederzeit mit jedem Modell kombinieren können. Wenn die Übersetzungsschicht offen ist, bleibt der vollständige Tool-Calling-Vertrag erhalten, und Sie können genau sehen, was mit Ihrer Anfrage geschieht. Wenn ein proprietärer Anbieter die Übersetzung übernimmt, erfahren Sie nie, was verloren geht.

llm-d: Skalierung agentischer Inferenz

Eine vLLM-Einzelinstanz funktioniert für eine Fachkraft, die Agenten ausführt, aber nicht für 100 Fachkräfte, die gleichzeitig auf dieselben Modelle zugreifen. llm-d ist die disaggregierte Serving-Schicht, die die Inferenz in separate Prefill- und Decode-Phasen aufteilt, sodass diese unabhängig auf unterschiedlicher Hardware skalieren können. Für agentische Workloads, bei denen viele kurze Anfragen mit langen Argumentationsketten verschachtelt sind, wird diese Architektur immer unverzichtbarer.

Leitplanken und Sandboxing

Die Inhaltssicherheit ist ebenfalls Teil dieses Stacks und muss agentenbewusst sein. Frameworks für Leitplanken, die als Proxys fungieren, müssen den vollständigen agentischen API-Vertrag beibehalten, einschließlich Tool-Definitionen, Tool-Auswahl und Reasoning-Parametern. Andernfalls riskieren sie, das Agenten-Verhalten unbemerkt zu beeinträchtigen.

Effektive agentische Leitplanken erfordern zudem Zugriff auf Daten auf Inferenzebene, die ein einfaches Filtern von Ein- und Ausgabetexten nicht bieten kann. Dazu gehören Reasoning Traces zur Bewertung, ob die Chain-of-Thought des Modells unsichere Schritte vor der finalen Ausgabe enthält, Tool-Aufrufparameter zur Validierung von Tools und Argumenten sowie logarithmische Wahrscheinlichkeiten auf Token-Ebene (logprobs) zur Erkennung von Halluzinationsrisiken und zur Generierung von Metadaten für Audit-Trails und Compliance-Logging. Dies ist ein weiterer Grund, warum die Inferenzschicht offen sein sollte. Leitplanken, die nur den ein- und ausgehenden Text sehen, reichen für agentische Workloads nicht aus. 

Wenn Ihr Leitplanken-Proxy eine Black Box ist, die Tool-Calling-Parameter entfernt, können Sie bei einem Ausfall Ihrer Agenten die Ursache nicht diagnostizieren. Open Source-Leitplanken (wie der nicht-proxybasierte Endpunkt /v1/guardrails/checks von NVIDIA NeMo Guardrails) erzwingen Inhaltssicherheit, ohne den agentischen API-Vertrag zu verletzen.

Sandboxing ist ein weiterer Faktor. Agenten führen Code aus, schreiben Dateien und rufen Tools auf. Defense in Depth erfordert eine mehrschichtige Isolierung, einschließlich Beschränkungen auf Container-Ebene, Netzwerkrichtlinien, Dateisystembeschränkungen und Runtime-Erzwingung. Es reicht nicht aus, einen Agenten in einen Container zu setzen. Die Sandbox-Grenze im Stack-Diagramm umschließt den Agenten und das Harness, da dort eine beliebige Code-Ausführung stattfinden kann und Sicherheitskontrollen am strengsten sein müssen.

Warum Open Source gewinnt

Sie können einen 8-schichtigen Stack nicht testen, wenn Sie nicht sehen können, was die Hälfte der Schichten tut. Sie können fehlgeschlagene Tool-Aufrufe nicht debuggen, wenn Sie den Parser nicht sehen. Sie können keine Sicherheit erzwingen, wenn der Leitplanken-Proxy stillschweigend die Parameter entfernt, die Agenten benötigen. Der Stack ist zu eng gekoppelt, als dass eine einzelne Schicht undurchsichtig sein kann. Diese Schichten gemeinsam zu integrieren und zu härten, damit Unternehmen den Stack nicht selbst zusammenstellen müssen, ist das Problem, für dessen Lösung Red Hat AI entwickelt wurde.

Jenseits technischer Argumente ist offene Inferenz aus strukturellen Gründen unvermeidlich, die über die Kosten hinausgehen.

Abbildung 3: Offene Inferenz im Vergleich zu proprietären APIs für agentische Workloads. Proprietäre APIs sind führend bei der einfachen Einrichtung und der Qualität von Frontier-Modellen. Offene Inferenz ist führend bei den 7 Funktionen, von denen agentische Workloads in der Produktion abhängen: Modell-Routing, Debugging von Tool-Aufrufen, Domänenanpassung, Budgets pro Agent, Datenresidenz, Anbieterunabhängigkeit und Leitplanken auf Inferenzebene.

Wissen beschleunigt das gesamte Feld. Open Source liefert 2 Dinge: freie Software und freies Wissen. DeepSeek R1 hat dies deutlich gezeigt. Reasoning-Fähigkeiten existierten in proprietären Modellen bereits monatelang, bevor die breitere Community sie replizieren konnte. Sobald DeepSeek den Code und das Paper veröffentlichte, verfügte jedes größere Labor innerhalb von 3 Monaten über Reasoning-Fähigkeiten. Der Effekt der Wissensdiffusion ist wertvoller als das Modell selbst. Auf die agentische Inferenz angewendet, wird jeder Fix für Tool-Call-Parser, jede Verbesserung von Chat-Vorlagen und jeder Harness-Patch zu einer gemeinsamen Infrastruktur, die sich über das gesamte Ökosystem summiert.

Vertrauen erfordert Transparenz. Nicht jede Organisation ist bereit, all ihre Daten und Workflows über eine Handvoll Cloud-Modellanbieter zu leiten. Für einige ist dies eine Frage der strikten Compliance. Branchen wie das Gesundheits- und Finanzwesen stehen vor strengen regulatorischen Anforderungen an Datenschutz und Datenresidenz. Für andere ist es eine strategische Entscheidung, um Vendor Lock-in zu vermeiden und die vollständige Kontrolle über ihr geistiges Eigentum zu behalten.

Open Source gibt Organisationen die Möglichkeit, Modelle zu ihren eigenen Bedingungen, innerhalb ihrer eigenen Sicherheitsgrenzen und mit voller Sichtbarkeit der Systemfunktionsweise zu betreiben. Für regulierte Branchen, Behörden und sicherheitskritische Workloads ist dies eine Grundvoraussetzung. Die Regulierung bewegt sich in dieselbe Richtung: Die ab August 2026 durchsetzbaren Transparenzpflichten des KI-Gesetzes der EU erfordern eine technische Dokumentation der Modellarchitektur, der Trainingsverfahren und der Leistungsmerkmale. Open Source-Modelle, die diese Informationen bereits veröffentlichen, qualifizieren sich für Ausnahmen, die für geschlossene Modelle nicht gelten.

Anpassung erfordert eigene Gewichtungen. Hinter einer geschlossenen API nutzt jede Organisation dasselbe Modell. Wenn Sie die Gewichtungen auf Ihrer eigenen Infrastruktur besitzen, können Sie diese für Ihre Domäne, Ihre internen Tools und Ihre Codebasis-Konventionen feinabstimmen, ohne proprietäre Daten nach außen zu senden. Gesundheitsorganisationen optimieren für klinische Terminologie und Patientenaktenformate. Rechtsteams passen Modelle an rechtsspezifische Sprache und Vertragsstrukturen an. Finanzinstitute trainieren mit ihren proprietären Risikomodellen und Compliance-Frameworks. Bei agentischen Workloads ist dies der Unterschied zwischen einem Allzweck-Agenten und einem, der bereits versteht, wie Ihre Systeme funktionieren.

Open Source schafft Ökosystem-Gravitation. Wenn Hardwareanbieter in Open Source-Inferenzsoftware investieren, fördern zugänglichere Modelle eine breitere Hardware-Adoption. Investitionen in vLLM-Optimierungen (die Inferenz-Runtime) und Verbesserungen am Open Source-Serving-Stack machen jede GPU leistungsfähiger für agentische Workloads und ermöglichen die Wiederverwendbarkeit von Hardware. Das Ergebnis ist ein positiver Kreislauf, in dem sich Verbesserungen an Open Source-Software über das gesamte Ökosystem hinweg summieren.

Die nächste Phase begünstigt verteilte Modelle. Das aufkommende Muster ist „zentriert auf gemeinsamen Kontext“, wobei viele Modelle an gemeinsamen Wissensgraphen und Kontextspeichern arbeiten. Dies verlagert den Fokus von einem einzelnen massiven Modell hin zu einem Ökosystem spezialisierter Modelle, die durch ein intelligentes Harness koordiniert werden. Sie benötigen nicht zwangsläufig ein Modell, das alles kann. Häufiger werden Sie viele spezialisierte Modelle benötigen, von denen jedes seine Aufgabe gut erfüllt und die als Verbundsystem zusammenarbeiten. Diese Architektur ist von Natur aus offener und verteilter.

Aufstrebende Agent-Architekturen wie Pi und OpenClaw sind bereits so aufgebaut. Ihr Design ist minimal und umfasst oft ein Large Language Model (LLM), eine Bash-Shell, ein Dateisystem, Markdown-Zustandsdateien und einen Cron-Loop. Der Zustand liegt in Dateien, nicht in Gewichtungen, sodass Sie das LLM austauschen können, ohne das Gedächtnis des Agenten zu verlieren. Diese Agenten funktionieren mit beliebigen Modellen, ob geschlossen oder offen. Wenn jedoch der gesamte Stack offen ist, von den Modellgewichtungen bis zur Serving-Infrastruktur, summieren sich alle strukturellen Vorteile: Sie führen das Fine Tuning für Ihre Domäne durch, routen über Modelle, die Sie kontrollieren, beobachten mit eigenen Tools und tauschen beliebige Schichten aus, ohne den Rest zu stören. Das macht offene Inferenz zu einer natürlichen Basis für agentische KI und Red Hat AI zur Plattform, die sie antreibt. 

Wie Sie sich vorbereiten

3 Dinge, die Sie jetzt tun sollten, bevor die Preisänderungen in Kraft treten.

Abbildung 4: 3 Maßnahmen zur Vorbereitung auf offene agentische Inferenz, jeweils mit spezifischen Tools aus dem Stack von Red Hat AI. Der Zeitplan zeigt einen 12-monatigen Übergang von der API-Portabilität hin zu einer vollständig selbst gemanagten agentischen Infrastruktur.

Harness-agnostisch entwickeln. Wie Sie Ihr agentisches Harness und Ihre Agenten entwickeln, ist ebenso wichtig wie das Modell, das Sie ausführen, wenn nicht sogar wichtiger. Wenn Ihre Agenten fest auf die API eines einzelnen Anbieters codiert sind, haben Sie sich bereits festgelegt, bevor die Preisänderungen eintreten. Sie sollten auf Modell- und API-Portabilität setzen. Hier setzen Projekte wie OGX an, die über Red Hat AI verfügbar sind. Sie bieten die offene Übersetzungsschicht für Chat Completions, Responses, Messages und Interactions APIs, damit Ihre Agenten portabel bleiben, unabhängig davon, welches Modell oder welcher Anbieter darunter liegt.

Das Volumen auf verwalteter Infrastruktur selbst hosten. Eine einzelne GPU, auf der ein quantisiertes Gemma 4- oder Qwen-Modell läuft, kann bereits Pull-Request-Reviews, Dokumentationen und Code-Zusammenfassungen bewältigen. Nutzen Sie API-Subskriptionen für Workloads, die wirklich Frontier Reasoning erfordern oder bei denen Frontier-Modelle noch einen klaren Qualitätsvorteil haben, und hosten Sie den Rest auf einer von Ihnen kontrollierten Infrastruktur selbst. Eine selbst gemanagte Inferenzplattform übernimmt die operative Komplexität von Modellbereitstellung, Skalierung, Routing und Observability, sodass sich Ihr Team auf den Bau von Agenten konzentrieren kann, statt den Serving-Stack zu warten. 

Da Open Source-Modelle die Lücke zu Frontier-Fähigkeiten weiter schließen, wird der Anteil der Workloads, die Sie selbst hosten können, stetig wachsen. Wenn Sie jetzt beginnen, bauen Sie die operative Bereitschaft auf, die Sie benötigen, wenn offene Modelle den gesamten Stack abdecken. Forschung zum Modell-Routing zeigt, dass die Weiterleitung der meisten Anfragen an kleinere oder selbst gehostete Modelle und die Eskalation nur komplexer Aufgaben an Frontier-APIs die Kosten um 60 % bis 85 % senken kann, bei minimalem Qualitätsverlust.

End-to-End-Tests über den gesamten agentischen Stack. Ein Modell, das Benchmarks besteht, kann dennoch scheitern, wenn das Harness es falsch anspricht, der Tool-Parser die Ausgabe falsch liest oder das Gateway die falschen Aufgaben routet. Das Testen von Modell-Harness-Konfigurations-Triples ist der richtige Ansatz.

Integrieren Sie zudem Token-Budgetierung in Ihren Prozess. Limits pro Agent. Zuordnung pro Feature. Anomalieerkennung. MLflow Tracing, bereits Teil des Stacks von Red Hat AI, erfasst Prompts, Reasoning-Schritte, Tool-Aufrufe und Token-Kosten bei voller OpenTelemetry-Kompatibilität. Sie sollten Budget-Warnungen haben, bevor Sie sie benötigen.

Für die Zukunft entwickeln

Hardware verliert normalerweise an Wert. GPUs für offene Inferenz bewirken das Gegenteil. Die Chips ändern sich nicht, aber die darauf laufende Software wird ständig verbessert. Besseres Batching und Attention-Kernel in vLLM schleusen mehr Token pro Sekunde durch dasselbe Silizium. Durch Fortschritte in der Quantisierung passen Modelle, die einst 80 GB erforderten, bei vergleichbarer Qualität nun in 20 GB. Disaggregiertes Serving teilt Workloads auf, sodass derselbe Cluster mehr gleichzeitige Agenten bewältigen kann. Eine vor 3 Jahren erworbene Unternehmens-GPU liefert heute nützlichere Inferenz als am Tag ihrer Installation, weil sich der Open Source-Stack um sie herum verbessert hat.

Diese Summierung ist der rote Faden, der sich durch dieses gesamte Argument zieht. Offene Tool-Call-Parser werden für alle besser. Offene Chat-Vorlagen beheben Kompatibilitätsprobleme einmalig und dauerhaft. Offene Leitplanken, die den agentischen API-Vertrag wahren, schützen jede Bereitstellung, nicht nur die Kunden eines einzelnen Anbieters. Offenes disaggregiertes Serving skaliert auf Hardware, die Sie bereits besitzen.

Genau dafür ist eine Open Source-KI-Plattform da. Nicht nur zum Bereitstellen von Modellen, sondern um den gesamten agentischen Inferenz-Stack auf der eigenen Infrastruktur zu kontrollieren – von der API-Schicht, die zwischen Harness und Modell übersetzt, über das Gateway für Routing und Metering bis hin zur Serving-Engine und der Hardware, was wir „Metal to Agents“ nennen. Ihre Daten bleiben innerhalb Ihrer Sicherheitsgrenzen. Ihre Modelle laufen dort, wo Sie es entscheiden. Ihre Kosten sind vorhersehbar, weil Sie jede Schicht kontrollieren. Jede Schicht ist offen. Jede Schicht ist debuggbar. Jede Verbesserung wird geteilt.

Die Modelle sind gut genug (und werden täglich besser). Der Stack nimmt Gestalt an. Die wirtschaftlichen Fakten sind klar. Die Frage ist nicht, ob offene agentische Inferenz kommen wird (sie ist bereits da), sondern ob Sie vorbereitet sind, wenn die Rechnung kommt.