Kategorie: Erklärer

Für MCP gibt es keine Admin-Konsole. Das ist die Kernaussage einer Analyse, die untersucht, welche MCP-Server Mitarbeiter auf ihren Laptops verbunden haben. Der Satz klingt beiläufig, beschreibt aber etwas Grundsätzliches: keine Lücke, die ein Anbieter gelassen hätte, sondern eine Eigenschaft des Protokolls. Damit fällt die erste Stelle weg, an der ein Sicherheitsteam normalerweise nachsieht.

Denn dort steht nichts. Kein SSO-Log, weil die meisten MCP-Server lokal starten und nie gegenüber etwas authentifizieren, das man kontrolliert. Kein Beschaffungseintrag, weil nichts beschafft wurde. Keine Admin-Konsole, weil das Protokoll keine definiert. Keine Netzwerksignatur, weil ein stdio-Server über eine Pipe zwischen zwei Prozessen auf derselben Maschine kommuniziert.

Was übrig bleibt: eine JSON-Datei im Home-Verzeichnis eines Entwicklers, von Hand bearbeitet. Die einzige Quelle der Wahrheit, und sie liegt auf einem Laptop. Daraus ergibt sich die Frage nach der Sichtbarkeit von MCP-Servern — unangenehmer, als sie zunächst klingt.

Wo die Konfiguration tatsächlich liegt

MCP wurde für einen lokalen Client entworfen, der im Auftrag eines einzelnen Nutzers einen lokalen Server startet. Daraus folgt, dass jeder Client seine eigene Konfiguration pflegt. Claude Desktop liest die claude_desktop_config.json aus dem Application-Support-Verzeichnis des Nutzers, Cursor liest .cursor/mcp.json auf Nutzer- oder Projektebene, Claude Code verwendet .mcp.json im Projekt zusammen mit einer Nutzerkonfiguration, und VS Code hält seine MCP-Einträge in den Editor-Einstellungen.

Client	Konfiguration
Claude Desktop	claude_desktop_config.json im Application-Support-Verzeichnis
Cursor	.cursor/mcp.json auf Nutzer- oder Projektebene
Claude Code	.mcp.json im Projekt plus Nutzerkonfiguration
VS Code / Copilot	MCP-Einträge in den Editor-Einstellungen

Wer drei dieser Clients parallel nutzt, hat drei getrennte Inventare, und keines weiß von den anderen. Eine einzelne Datei sagt dir also nur etwas über einen Client auf einer Maschine. Die organisatorische Frage verlangt dagegen alle Dateien, auf allen Maschinen, fortlaufend. Denn die Antwort ändert sich, sobald jemand eine Datei bearbeitet.

Der Servername grenzt nichts ein

Der häufigste Fehler beim ersten Inventarversuch: Servernamen sammeln und die Aufgabe für erledigt halten. Der Name ist ein Etikett, gewählt von dem, der die Konfiguration geschrieben hat. Er wird nicht validiert, nicht registriert und steht in keiner überprüfbaren Beziehung zu dem, was der Server tut. Ein Eintrag namens docs kann jede ausführbare Datei mit beliebigen Argumenten starten.

Die Autoren ordnen das in dieselbe Kategorie ein wie das, was sie bei Claude Code als namensgebundenes Vertrauen beschrieben haben: Was ein Nutzer bestätigt, und was tatsächlich läuft, verbindet nur eine Zeichenkette — und die kann ein Angreifer wählen. Wer den Servernamen als Identität behandelt, hält eine Behauptung für einen Beweis. Für die MCP-Sicherheit ist das der folgenreichste Denkfehler.

Was wirklich zählt: der aufgelöste Befehl

Vier Angaben entscheiden, ob ein Eintrag harmlos oder riskant ist. Die erste ist der Einstiegspunkt. Zeigt er auf /bin/bash, /bin/sh oder python -c, übergibt der Server dem verbundenen Agenten eine Shell auf dem Laptop. Kein subtiles Risiko, sondern in der Konfiguration offen sichtbar — vorausgesetzt, jemand liest sie.

Die zweite sind Paket und Version, die tatsächlich laufen. Die meisten MCP-Server starten über npx mit einem gleitenden Tag, das erst zur Startzeit aufgelöst wird. Ausgeführt wird also der Code, den die Registry zuletzt ausgeliefert hat — nicht der, den jemand geprüft hat. Beim Figma-MCP-Server wurde eine Schwachstelle in einem Patch-Release behoben, den die meisten Nutzer erhielten, ohne sich je dafür entschieden zu haben.

Die dritte sind die Zugangsdaten. API-Schlüssel und Tokens werden regelmäßig über Umgebungsvariablen in derselben Konfigurationsdatei an MCP-Server übergeben. Ein Inventar, das Servernamen erfasst, aber nicht, was ihnen übergeben wurde, lässt genau den Teil aus, den ein Sicherheitsteam am dringendsten braucht. Die vierte ist der Transport. stdio und HTTP haben unterschiedliche Angriffsflächen — das zeigen die drei CVEs des n8n-MCP-Servers: Alle drei setzten den HTTP-Multitenant-Modus voraus, keiner erreicht eine lokale stdio-Installation.

Warum das ein Endpoint-Problem ist

Man kann das als Identitätsproblem behandeln und mit Tokens und Scopes lösen wollen. Das hilft den entfernten, OAuth-gestützten Servern — erreicht aber die Mehrheit nicht, die aus lokalen, per Konfigurationsdatei gestarteten Prozessen besteht. Ebenso kann man es als Netzwerkproblem behandeln. Es scheitert aus demselben Grund, aus dem die Erkennung lokaler LLMs auf der Netzwerkebene scheitert: Ein stdio-Server spricht mit seinem Client über eine Pipe, und nichts überquert dabei eine Schnittstelle, die man beobachten könnte.

Die Konfigurationsdatei liegt auf dem Endpunkt. Der Prozess läuft dort. Die Zugangsdaten liegen dort. Jede Antwort, die den Endpunkt nicht liest, ist eine Schlussfolgerung aus Indizien — und so entstehen Zahlen, die selbstsicher falsch sind. MCP-Server-Sicherheitsrisiken erkennen heißt also, dort nachzusehen, wo die Deklaration steht.

Was ein echtes Inventar erfassen muss

Ein brauchbares Inventar wird pro Maschine und pro Nutzer geführt und fortlaufend aktualisiert, nicht einmalig erfasst. Es verzeichnet: welche Agent-Clients installiert und aktiv sind; welche MCP-Server jeder Client deklariert; den aufgelösten Einstiegspunkt jedes Servers; Paket und tatsächlich laufende Version statt der nominell festgelegten; die über Umgebungsvariablen übergebenen Zugangsdaten und Geheimnisse; sowie den Transport und bei HTTP-Servern das, wogegen sie exponiert sind.

Diese Liste ist nicht exotisch. Es sind eine Handvoll Dateien und eine Prozesstabelle — genau die Daten, die ein Endpoint-Agent ohnehin für andere Zwecke erhebt. Die Lücke: Niemand hat ihm diese Fragen gestellt. Wer wissen will, welche MCP-Server Mitarbeiter verbunden haben, kommt an den MCP-Konfigurationsdateien nicht vorbei. Eine zentrale Registry, eine Admin-Konsole oder ein SSO-Log gibt es nicht. Und wie oft sich das ändert, gehört ebenfalls zur Antwort: Einen MCP-Server zu installieren ist eine Textbearbeitung mit anschließendem Client-Neustart. Kein Ticket, kein Beschaffungsschritt, kein Anmelderekord.

Einordnung

Ein einmalig erfasstes Inventar ist der Schnappschuss einer Konfiguration, die sich bereits geändert haben kann. MCP-Server-Inventarisierung muss deshalb dauerhaft laufen, keine einmalige Prüfung sein. Neue Infrastruktur braucht es dafür nicht — nur eine andere Frage an die bestehende Endpoint-Inventarisierung.

Die Analyse stammt von Repello AI und bewirbt am Ende das eigene Werkzeug Workstation Lens, das genau das leistet: die Dateien über die Flotte lesen, Einstiegspunkte auflösen, solche mit Shell-Verweis markieren und die real laufenden Versionen berichten. Diese Interessenlage sollte man beim Lesen im Kopf behalten. An der Struktur des Problems ändert sie nichts: Solange MCP keine organisatorische Kontrollebene definiert, bleibt die einzige verlässliche Aufzeichnung ein Textdokument in einem Home-Verzeichnis. MCP-Server ohne Admin-Konsole zu verwalten ist deshalb keine Notlösung, sondern der Normalfall. Man kann ihn schlecht oder gut betreiben — ignorieren lässt er sich nicht.

Quelle: repello.ai

„UK workers are showing they don’t want to wait for permission to use generative AI.“ Der Satz stammt von Hayley McKelvey, Chief AI Officer bei Deloitte UK. Er beschreibt etwas, das in vielen Unternehmen längst passiert ist, ohne dass es dort offiziell angekommen wäre. Eine neue Auswertung des Beratungsunternehmens zeigt: 63 Prozent der britischen Beschäftigten nutzen generative KI für ihre Arbeit.

Ein erheblicher Teil läuft an der offiziellen IT vorbei. 31 Prozent verwenden die Werkzeuge ohne Wissen des Arbeitgebers, 17 Prozent zahlen mindestens ein Abo selbst. Zusammen kommen sie auf rund 958 Millionen Pfund, die sie aus eigener Tasche für ihre Arbeit ausgeben. Wie es um die KI-Nutzung in Unternehmen steht, verraten die Strategiefolien also nicht. Eher die Kreditkartenabrechnungen der Mitarbeiter.

Für dieses Muster gibt es ein brauchbares Bild: Beschäftigte, die ihren eigenen Akkuschrauber zur Baustelle mitbringen. Nicht aus Trotz, sondern weil sie mit dem Gerät, das der Betrieb stellt, nicht rechtzeitig arbeiten können. Und wer sein eigenes Werkzeug mitbringt, entscheidet auch selbst, wofür er es einsetzt. Das ist Schatten-KI.

Was die Deloitte-Zahlen zeigen

Die Erhebung teilt die Nutzung in mehrere Kanäle. 46 Prozent der Befragten greifen zu kostenlosen KI-Tools, 34 Prozent nutzen externe Angebote, die ihr Arbeitgeber bezahlt, und 17 Prozent arbeiten mit intern entwickelten Lösungen. Die Gruppen überlappen sich, weil viele Beschäftigte mehr als ein Werkzeug parallel verwenden. Die einzelne Zahl ist weniger wichtig als die Richtung: Generative KI ist am Arbeitsplatz angekommen, bevor die meisten Unternehmen Regeln dafür hatten.

Auch das Verhältnis von offizieller und inoffizieller Nutzung sagt etwas. Ein knappes Drittel der KI-Nutzung findet ohne Wissen des Arbeitgebers statt. Das ist nicht automatisch Missbrauch. Es heißt zunächst nur, dass tatsächliche und dokumentierte Nutzung auseinanderfallen — und dass jede Risikoanalyse, die auf Freigaben und Freigabelisten beruht, ins Leere läuft.

Der eigene Werkzeugkasten: Warum Mitarbeiter KI-Tools selbst bezahlen

Die Motive für private Abos sind selten technischer Natur. Es sind Fristen. Wer bis Freitag eine Auswertung abgeben soll, hängt nicht drei Wochen in einem Freigabeprozess für Software, sondern bucht das Werkzeug für 20 Euro im Monat und arbeitet. Die Wartezeit zwischen Bedarf und Bereitstellung ist in vielen Häusern größer als der Betrag, um den es geht. Dort entsteht Schatten-KI: nicht als Angriff auf die IT, sondern als Umgehung von Wartezeiten.

Das zweite Motiv liegt offener zutage: Qualität. Kostenlose Versionen haben Grenzen, die man im Arbeitsalltag schnell merkt. Die bezahlte Variante eines KI-Tools verarbeitet längere Texte, antwortet schneller und liefert brauchbarere Ergebnisse. Wer generative KI für die Arbeit einsetzt und dabei an diese Grenzen stößt, zahlt lieber selbst, als auf eine Freigabe zu warten.

Das Werkzeug bleibt dann auch privat. Rechnung, Konto und in der Regel die Datenhoheit liegen beim Mitarbeiter. Für das Unternehmen heißt das: Die Arbeit wird erledigt, aber niemand weiß genau, womit. Der Handwerker hat geliefert — nur hat die Bauleitung nie gesehen, welcher Bohrer im Einsatz war.

Warum viele die Nutzung verschweigen

23 Prozent der Befragten nehmen an, dass ein Stigma an der KI-Nutzung hängt; 64 Prozent sorgen sich, ihre Vorgesetzten könnten glauben, KI könne ihre Arbeit erledigen. Diese Furcht ist rational. In Unternehmen, in denen KI vor allem als Rationalisierungsprojekt besprochen wird, ist es keine gute Idee, laut zu sagen, dass man einen Teil der eigenen Aufgaben bereits automatisiert hat. Wer schweigt, schützt seinen Arbeitsplatz.

Zwei Drittel der Befragten sagen außerdem, ihrer Organisation fehle überzeugende Führung beim Thema generative KI. Das erklärt die Schatten-KI besser als jedes andere Ergebnis. Wo nicht klar ist, was erlaubt, was erwünscht und was verboten ist, entscheidet jeder für sich — und richtet sich nach dem, was die Aufgabe verlangt, nicht nach dem, was das Unternehmen will.

Wofür generative KI genutzt wird

Die drei häufigsten Anwendungsfälle sind unspektakulär. 43 Prozent nutzen KI-Tools zum Suchen von Informationen, ebenfalls 43 Prozent zum Formulieren von E-Mails, 31 Prozent zum Erstellen von Zusammenfassungen. Alltagsarbeit: Text, Recherche, Verdichtung. Für diese Tätigkeiten hätte bisher niemand eine eigene Abteilung bezahlt.

Fast die Hälfte der Befragten gibt an, nie eine formale Schulung zum sicheren und wirksamen Einsatz von KI erhalten zu haben. Paul Lee, Partner und Leiter der Industrieanalyse bei Deloitte UK, formuliert es so: „The story here isn’t that workers are using GenAI, it’s that they are using it despite limited training, patchy guidance and, in some cases, without their employer’s knowledge.“ Übersetzt: Die Geschichte ist nicht, dass Beschäftigte KI nutzen, sondern dass sie es trotz begrenzter Schulung, lückenhafter Vorgaben und teils ohne Wissen des Arbeitgebers tun.

Lee weist zusätzlich darauf hin, wie schnell generative KI Alltag geworden ist und wie einfach ihre aktuelle Rolle bleibt. Das klingt harmlos. Die Risiken fangen genau hier an — nicht weil die Aufgaben komplex wären, sondern weil in diesen einfachen Aufgaben die Geschäftsdaten stecken.

Risiken, die niemand sieht

Das britische National Cyber Security Centre (NCSC) hat erst kürzlich davor gewarnt, dass Unternehmen gegen nicht genehmigte KI-Nutzung vorgehen müssen. Genannt werden Datenlecks, der Verlust von geistigem Eigentum und die Gefahr, regulatorische Anforderungen zu verfehlen. Die Begründung ist knapp und schwer zu widerlegen: „You cannot manage what you do not know.“

Übersetzt heißt das: Man kann nicht steuern, was man nicht kennt. Wer nicht weiß, welche Tools mit welchen Kundendaten gefüttert werden, kann weder Datenschutz zusagen noch Haftung begrenzen. Die private Bezahlung macht es nicht besser, sondern schlechter, weil sie den Vorgang aus jeder Firmenrechnung heraushält — und damit aus jedem Audit.

Böswillig handelt dabei kaum jemand. Die Mitarbeiter erledigen ihre Arbeit. Der Schaden entsteht durch Sichtbarkeit, nicht durch Absicht: Was in einem privaten Abo passiert, taucht in keiner Richtlinie, keiner Voreinstellung und keinem Protokoll auf.

Was Unternehmen tun können

Hayley McKelvey von Deloitte UK zieht aus den Zahlen eine praktische Konsequenz. Unternehmen müssten ihren Leuten helfen, generative KI verantwortungsvoll zu nutzen, und zwar mit einem klar formulierten und allgemein verstandenen Ziel. Das heißt: klarmachen, warum KI im Betrieb eingesetzt werden soll, wie sie genutzt werden darf und woran Erfolg gemessen wird. Erst dann, so ihre Argumentation, entscheiden sich Beschäftigte bewusster und gehen Risiken kontrollierter an.

Der zweite Hebel ist schlichter, als es klingt: Bereitstellung. Wenn die Firma ein Werkzeug stellt, das sofort funktioniert, verschwindet der Anlass, ein privates zu buchen. Verbote allein lösen nichts, weil sie das Bedürfnis nicht beseitigen — sie verschieben es nur in den unsichtbaren Bereich. Ein Freigabeprozess, der zwei Wochen dauert, ist gegen ein Abo für 20 Euro im Monat chancenlos.

Die Deloitte-Studie zeigt nicht, dass Mitarbeiter heimlich KI lieben. Sie zeigt, dass sie ein Arbeitsmittel gefunden haben, das ihre Aufgaben schneller erledigt — und dass die Unternehmen mit der Bereitstellung nicht hinterherkommen. Schatten-KI am Arbeitsplatz ist damit weniger ein Disziplinproblem als ein Lieferproblem. Solange die Firma nicht liefert, liefert der Mitarbeiter selbst. Und zahlt dafür.

Quelle: itpro.com

Auf einem Monitor läuft eine Ausgabezeile durch: knapp 420 Tokens pro Sekunde, während der Kontext im Hintergrund der Millionengrenze entgegenwächst. Der Autor des Blogs zartbot hält das zunächst für eine gewöhnliche Nachjustierung — ein weiteres Flash-Modell, etwas schneller, etwas günstiger. Seine Einschätzung kippt erst, als die Ankündigung kommt, alle Pro-Modelle der V4-Reihe offline zu nehmen, und kurz darauf der technische Bericht „DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression“ vollständig vorliegt. Laut seiner Darstellung hätte das Modell eher DeepSeek-V5 heißen müssen, so tief greifen die Änderungen in die Architektur.

Was daran schwer wiegt, zeigt ein Bild aus dem Sitzungsalltag. Jedes Mal, wenn ein Sprachmodell Text verarbeitet, legt es für jedes Token eine Art Protokolleintrag an — Key und Value im Attention-Mechanismus. Dieses Protokoll wird bei jedem weiteren Schritt erneut gelesen. Der KV-Cache ist also nichts anderes als die fortlaufende Mitschrift einer Sitzung, und er wächst mit jedem Token mit. Solange ein Gespräch drei Absätze lang ist, fällt das nicht weiter auf.

Sobald aber ein Agent stundenlang Werkzeuge aufruft, Dateien liest und Zwischenergebnisse anhängt, wächst das Protokoll schneller als der eigentliche Inhalt. Wer über Serving-Kosten nachdenkt, landet genau hier: Der teuerste Posten ist dann nicht mehr die Rechenleistung pro Token, sondern das Bewegen und Aufbewahren dieser Mitschrift. Die Komprimierung ist deshalb kein Randdetail, sondern der eigentliche Zweck dieser Version.

Warum Long-Horizon-Agenten den KV-Cache zum Engpass machen

Der Bericht beginnt mit einer nüchternen Beobachtung: Long-horizon-Agenten haben ultra-lange Kontexte von einem Sonderfall zu einer regulären Last gemacht. Solche Abläufe brauchen nicht nur effiziente Verarbeitung langer Sequenzen, sondern auch persistente Speicherung, Wiederverwendung und Übertragung großer KV-Caches. Damit wird Cache-Verwaltung von einem Implementierungsdetail zu einer Grundfähigkeit des Deployments. Rechenleistung, Speicher und Kommunikation werden dadurch stärker belastet.

Die Vorgängerarchitektur kombiniert eine Sparse Attention, die den gesamten Kontext abdeckt, mit einer Sliding-Window-Attention für das lokale Fenster. Das senkt die Rechenkosten langer Sequenzen spürbar. Was bleibt, ist die andere Hälfte des Problems: In langen Kontexten dominiert der globale KV-Cache, wird für Prefix-Reuse persistiert, belegt Host-Speicher und SSD-Kapazität und belastet zusätzlich die Interconnect-Bandbreite beim Verschieben. All das drückt den Durchsatz, erhöht die Deployment-Kosten und begrenzt am Ende, wie lang und wie breit Agenten überhaupt laufen können.

Die Schlussfolgerung im Bericht ist entsprechend schlicht: Der Key-Value-Footprint muss weiter runter, sonst lässt sich das Scaling nicht fortsetzen. Genau hier setzt DeepSeek-V4.1-Flash an. Das Modell hat 552 Milliarden Parameter, verarbeitet multimodal und unterstützt Kontexte bis eine Million Token. Entscheidend ist jedoch nicht die Größe, sondern was mit dem Cache passiert.

Causal Encoder-Decoder: Prefill läuft nur durch die halbe Tiefe

Die auffälligste Änderung betrifft die Arbeitsteilung im Netz. Das Modell hat insgesamt 40 Layer, aber nur die ersten 20 bilden den Encoder, die letzten 20 den Decoder. Der globale KV-Cache des Decoders entsteht, indem die finalen Hidden States des Encoders projiziert werden. Für den Prefill, also das Verarbeiten des eingegebenen Textes, müssen deshalb nur die ersten 20 Layer durchlaufen werden.

Bleib kurz beim Bild der Mitschrift: Bisher musste jede Etage des Hauses das komplette Protokoll selbst führen. Jetzt schreibt ein Vorzimmer die verbindliche Fassung, und die hinteren Etagen lesen daraus. Das klingt nach einer kleinen Umstellung, ist aber der Grund, warum die aktivierten Parameter im Prefill bei etwa 8 Milliarden liegen und im Decode bei etwa 16 Milliarden. Der Autor vergleicht den Ansatz mit der Idee hinter YOCO, also dem Gedanken, dass tiefe Schichten nicht zwingend einen eigenen, vollständigen Cache brauchen.

Für Agenten ist das die richtige Stelle zum Sparen. Diese Workloads sind input-dominiert: Ein langer Prompt mit Werkzeugausgaben kommt herein, die Antwort ist vergleichsweise kurz. Wenn der teure Teil des Vorwärtsdurchlaufs nur noch durch die halbe Tiefe muss, sinkt der Rechenaufwand genau dort, wo er am stärksten weh tut. Der Decode bleibt vollständig und damit qualitativ unbeschnitten.

CSA2: Kompression in vier Richtungen gleichzeitig

Die eigentliche KV-Cache-Komprimierung verteilt sich auf mehrere Dimensionen, die in der Praxis zusammenwirken. Zuerst die Kopfzahl, ähnlich wie bei GQA: Statt für jeden Attention-Kopf eigene Keys und Values zu halten, teilen sich die Köpfe eine gemeinsame latente Repräsentation. Dann die Blockbildung, wie sie aus CSA und HCA bekannt ist. Interessant ist, dass das Team die stark komprimierende HCA-Variante fallen lässt und stattdessen CSA weiterentwickelt — zu CSA2, das zusätzlich über Layer hinweg teilt.

In der Kanal-Dimension nutzt CSA2 einen 512-dimensionalen latenten Vektor, der die Keys und Values aller Attention-Köpfe gemeinsam repräsentiert. Davon entfallen 64 Dimensionen auf RoPE, der Rest auf NoPE. Die Query-Seite arbeitet mit einer Low-Rank-Projektion vom Rang 1280, die Ausgabeprojektion ist in acht Gruppen mit je Rang 1024 aufgeteilt. Übertragen auf die Mitschrift: Es gibt nicht mehr für jeden Zuhörer eine eigene Stenografie, sondern eine gemeinsame Chiffre, die alle lesen können.

In der Sequenz-Dimension fasst der Encoder zwei benachbarte Positionen über gelernte kanalweise Gewichte zu einem einzigen Cache-Eintrag zusammen. Der Decoder behält dagegen Einträge pro Position, weil dort die Auflösung gebraucht wird. In der Layer-Dimension teilen mehrere Schichten denselben globalen KV, sodass im gesamten Netz nur drei Encoder-Kopien und eine Decoder-Kopie übrig bleiben. In der Sprache des Bildes: Aus vielen Einzelheften werden wenige Sammelbände, und ein Teil der Einträge wird gleich doppelt belegt.

Dazu kommt eine numerische Optimierung, die in der Übersicht schnell untergeht: Der KV-Cache läuft in FP4, also mit vier Bit pro Wert. Zusammen mit dem Indexer-Aufwand ergibt das ein Speicherwachstum von rund 890 Byte pro Token. Unterm Strich steht laut Bericht ein Laufzeit-KV-Cache von etwa einem Viertel und ein persistenter KV-Cache von etwa einem Achtel des Vorgängers — eine vierfache Komprimierung, ohne dass die Aufgabenqualität darunter leiden soll.

Sparse Attention braucht einen Indexer, und der kostet selbst

Die Attention selbst kombiniert ein lokales Sliding Window von 128 Token mit globaler, sparse ausgewählter Aufmerksamkeit. Welche Positionen global berücksichtigt werden, entscheidet ein Indexer, der per Top-K 512 Kandidaten auswählt. Dieser Indexer ist selbst ein Teil des Modells mit eigenen Köpfen und Dimensionen, und er ist der Grund, warum die Kompression nicht nur den Haupt-Cache betrifft. Auch die Index-Strukturen müssen gespeichert, quantisiert und bewegt werden.

Ein Detail: Welche Layer als Quellen dienen. Für den globalen Modus sind vier Schichten vorgesehen, für den Voll- plus Reindex-Modus acht, verteilt über die Tiefe des Netzes. Der Kandidatenpool wird aus einer bestimmten Schicht aufgebaut, die Kandidaten selbst werden blockweise verwaltet. Man merkt daran, wie stark diese Architektur inzwischen auf Speicherverhalten hin entworfen ist und nicht mehr allein auf Rechenoperationen.

Der Autor zeichnet die Beschreibung des Causal Encoder-Decoder in seinem Beitrag neu und kommt dabei zu einer Lesart, die deutlich einfacher zu greifen ist als der Originaltext. Er liest die Architektur als eine Art rekursiven Transformer: Q wird im Verlauf der Rekursion verändert, KV wiederverwendet. Wer diese Perspektive einmal hat, erkennt das Muster auch in der Cross-Layer-Kompression wieder — es ist ein Teilen und Weiterreichen, nicht bloß ein Wegwerfen von Information. Auf einen verwandten Aufsatz zu Schleifen und Transformer-Architekturen verweist er dabei ausdrücklich.

Was messbar ist: Durchsatz, Speicher und nahezu lineares Wachstum

Die Zahlen, die der Autor nennt, sind der Grund für seine Einschätzung. Er beobachtet knapp 420 Token pro Sekunde im Betrieb. Wichtiger noch ist das Verhalten über die Länge: Mit wachsendem Kontext steigt der Rechenaufwand im Bereich bis eine Million Token nahezu linear und liegt weit unter dem, was frühere Generationen benötigen. Genau das ist die Voraussetzung dafür, dass lange Agentenläufe nicht an der Komplexitätskurve scheitern.

Daneben stehen Bauteile, die einzeln weniger spektakulär sind, in Summe aber das Bild vervollständigen. Die Residualverbindungen laufen über mehrere Ströme, deren Mischmatrix per Sinkhorn-Iterationen nahe an eine doppelt stochastische Matrix herangeführt wird. Eine spekulative Decoding-Komponente arbeitet mit kleinen Draft-Blöcken, die aus dem Mittel der Residualströme parallele Vorschläge berechnen und über ein Konfidenzmaß entscheiden, wie viel verifiziert wird. Dazu kommen bedingter Speicher sowie ein Vision-Zweig, der Bilder mit Patchgröße 14 verarbeitet und über eine 3×3-Verdichtung auf rund ein Neuntel der Tokenzahl reduziert, mit maximal 1024 visuellen Token pro Bild.

Einordnung: Was das konkret bedeutet

Für den Betrieb ist die wichtigste Konsequenz die Verschiebung des Engpasses. Wenn der persistente KV-Cache auf ein Achtel schrumpft, passen deutlich mehr Prefixe dauerhaft auf die vorhandene SSD, und Prefix-Reuse wird von einer Optimierung zu einer Selbstverständlichkeit. Zusammen mit dem halbierten Prefill-Durchlauf senkt das die Kosten genau jener Last, die Agentenprodukte dominieren: viel Eingabe, wenig Ausgabe, viele Werkzeugaufrufe, sehr lange Sitzungen. Mehr parallele Agenten pro Knoten sind damit keine Frage besserer Hardware, sondern besserer Cache-Architektur.

Ein Vorbehalt bleibt. FP4 im KV-Cache und das Teilen von Keys und Values über Schichten hinweg sind bewusste Approximationen. Der Bericht behauptet hohe Qualität bei den Aufgaben, und der Autor bestätigt das aus seiner Nutzung — aber die Grenze verläuft pro Workload unterschiedlich. Wer feingranulare Numerik, seltene Randfälle oder exakte Reproduzierbarkeit braucht, sollte messen statt übernehmen. Der Indexer für die Sparse Attention fügt außerdem eigene Buchführung hinzu, die man in Speicherbudgets und Profiling einrechnen muss.

Das reicht über ein einzelnes Modell hinaus. Lange Zeit wurde Sprachmodell-Effizienz in FLOPs diskutiert; inzwischen entscheidet der Speicher, genauer: die Bewegung und Haltung von Zwischenzuständen. Für Systeme in dieser Phase zählen konkrete Kennzahlen: Byte an KV-Cache pro Token und pro Kontextlänge, Trefferquote bei Prefix-Reuse, Durchsatz pro GB HBM. DeepSeek-V4.1-Flash ist in dieser Lesart kein schnelleres Modell, sondern ein Beleg dafür, dass KV-Cache-Komprimierung inzwischen zu den Kernaufgaben im Systembau gehört.

Quelle: zartbot.github.io

Ein einziger HTTP-Header entscheidet, ob eine identische Anfrage erneut abgerechnet wird oder in Millisekunden aus dem Zwischenspeicher zurückkommt. Vier weitere Agent-Harnesses laufen nicht mehr über eigene Anbieter-Konten, sondern über eine gemeinsame Schnittstelle mit mehr als 500 Modellen. OpenRouter hat diese und einige weitere Änderungen zwischen April und September 2026 veröffentlicht. Die Teile hängen stärker zusammen, als die einzelnen Ankündigungen zeigen.

Wer KI-Modelle per API nutzt, kennt das Problem: Jeder Anbieter hat eigene Endpunkte, eigene Schlüssel, eigene Preise und eigene Eigenheiten bei den Parametern. OpenRouter will daraus einen einzigen Knotenpunkt machen. Du wählst ein Modell, ohne für jeden Anbieter einen eigenen Zugang zu brauchen. Die jüngsten Ankündigungen betreffen genau diesen Punkt aus verschiedenen Richtungen.

Response Caching: Ein Header, der Wiederholungen kostenlos macht

Response Caching ist der praktischste Baustein, und OpenRouter stellt es kostenlos bereit. Du setzt einen Header, X-OpenRouter-Cache mit dem Wert true, und jede identische Anfrage danach kommt aus dem Cache. Der erste Aufruf geht an den Modellanbieter und wird normal abgerechnet. Jeder weitere kostet keine Tokens mehr.

Die Zahlen sind deutlicher als das Konzept. Eine ungecachte Anfrage an Gemini 2.5 Flash dauert etwa 1,3 Sekunden, an Kimi K2.6 rund 4,6 Sekunden und an GPT-5.5 etwa 9,1 Sekunden. Treffer im Cache kommen in 80 bis 300 Millisekunden zurück. Das Nachschlagen selbst dauert im Schnitt 4 Millisekunden.

Bei Tests und Agent-Wiederholungen zählt das. Wenn ein Agent eine Aufgabe mehrfach mit demselben Kontext startet, weil ein Werkzeug fehlgeschlagen ist, zahlst du sonst jedes Mal für denselben Prompt. Mit Cache kostet nur der erste Durchlauf. Offen bleibt, wie eng „identisch“ definiert ist: Ein wechselnder Zeitstempel im Prompt reicht, um den Treffer zu verhindern.

Vier weitere Harnesses am Modell-Router

Vier weitere Ori-Harnesses laufen jetzt über die Plattform: Cline, Kilocode, ohmypi und Muse Code. Ein Harness steuert ein Modell, organisiert Werkzeugaufrufe, Dateizugriffe und Schleifen. Statt für jeden Harness einen eigenen Anbieter-Zugang zu pflegen, greifst du auf denselben Pool aus mehr als 500 Modellen zu. Das Modell wechselst du pro Durchlauf, nicht pro Werkzeug.

Die Aufrufe sind einheitlich. Beispiele aus der Ankündigung: „ori kilo –model openai/gpt-6-astra“ oder „ori muse –model anthropic/claude-fable-5.1“. Der Parameter reasoning-effort wird auf das native Flag des Harness abgebildet, alles andere läuft unverändert durch. Du lernst eine Schreibweise und findest sie in vier Werkzeugen wieder.

Wichtiger als die Zahl der Harnesses ist, dass die Modellwahl aus dem Werkzeug herausgezogen wird. Funktioniert dieselbe Zeile in Cline, Kilocode, ohmypi und Muse Code, wird der Harness austauschbar und das Modell zur Stellschraube. Das ist die Aufgabe eines Modell-Routers: Er sitzt zwischen Werkzeug und Anbietern und nimmt dir die Kopplung ab.

Classifiers: KI-Inferenz nach Aufgabe und Abteilung sortieren

In der Beta steckt ein Werkzeug namens Classifiers. Damit taggst du KI-Inferenz in deinem Workspace nach Aufgabentyp, Abteilung, Agent-Komplexität oder einem anderen Merkmal und filterst anschließend Logs oder visualisierst die eigene Aktivität. Ein Classifier besteht aus vier Teilen: einer Taxonomie mit bis zu acht Dimensionen, einem Klassifizierungs-Prompt, einem Modell für die Einordnung und einer Sampling-Rate. Sechs Vorlagen sind mitgeliefert, damit du nicht bei null anfängst.

Für den Betrieb zählt der Zeitpunkt: Die Klassifizierung läuft asynchron nach jeder Anfrage und fügt dem Inferenzpfad keine Latenz hinzu. Ein Beispiel aus der Ankündigung zeigt die interne Nutzung gruppiert nach Aufgabenfamilie und Modell, dominiert von Analyse und Coding. Die Etiketten werden also erst nach dem Versand aufgeklebt.

Nützlich wird es, wenn du die Gruppierung umdrehst. Statt zu fragen, welche Aufgaben anfallen, fragst du, welches Modell welche Aufgabe am stärksten abbekommt. So siehst du, ob ein teures Frontier-Modell Arbeit erledigt, die ein günstigeres ebenso gut könnte. Automatisch passiert nichts, aber für die nächste Entscheidung über Preise und Modelle hast du Daten.

Fusion API für KI-Modelle: Mehrere Antworten werden zusammengeführt

Die Fusion API geht anders vor. Statt ein einzelnes Modell zu befragen, schickt sie eine Anfrage an ein Panel aus mehreren Modellen und führt die Antworten zusammen. OpenRouter nennt Fusion das intelligenteste zusammengesetzte Modell am Markt, mit Fable-Niveau zum halben Preis. Getestet wurde an 100 schwierigen Rechercheaufgaben, drei Beobachtungen fallen auf.

Erstens schneiden Panels durchweg besser ab als einzelne Modelle. Zweitens lässt sich Leistung jenseits der Frontier-Modelle erreichen, wenn das Panel aus Frontier-Modellen besteht. Drittens können Panels aus günstigen Modellen teurere Einzelmodelle überholen, ohne deren Kosten zu erzeugen. Interessant ist die Zerlegung: Etwa drei Viertel des Gewinns stammen aus der Zusammenführung, nur ein Viertel aus der Vielfalt der Modelle.

Das verändert die Frage beim Modellvergleich. Nicht mehr nur: Welches einzelne Modell liefert die beste Antwort? Sondern: Welche Kombination aus Modellen und Zusammenführung ergibt das beste Verhältnis? Ein Panel ist kein Zaubermittel, es kostet mehr Aufrufe pro Anfrage. Die werden über die Plattform gebündelt abgerechnet, nicht über mehrere Anbieterkonten.

Discover-Seite und Aliase: OpenRouter KI-Modelle vergleichen ohne Handbuch

Die neue Discover-Seite bündelt den Blick auf den Markt. Opus 5 führt die Gesamtwertung an, GPT 5.6 Sol liegt beim Coding vorne. Dazu kommt eine wachsende Liste von Routern, die weitere Modelle auffinden helfen. Angezeigt werden unter anderem das beste Verhältnis von Wert zu Preis und die schnellsten Modelle über den ganzen Markt.

Für den Alltag sind zwei Funktionen wichtiger als die Ranglisten. Aliase verhindern, dass du eine neue Version verpasst, weil du noch auf einem festen Modellnamen sitzt. Und die Filter für kostenlose Modelle zeigen, was gerade nichts kostet. Damit vergleichst du KI-Modelle per API, ohne für jede Aktualisierung die eigene Konfiguration anzufassen.

OpenRouter beschränkt sich nicht mehr auf Sprachmodelle. Die Discover-Seite führt auch Bild-, Video- und Audiomodelle an einem Ort zusammen und erlaubt einfache visuelle Vergleiche. Ein separater Beitrag beschreibt einen Skill namens create-agent-tui, mit dem sich ein eigener Agent-Harness samt Terminal-Oberfläche bauen lässt. Die Plattform will nicht nur Anfragen weiterleiten, sondern auch das Drumherum mitliefern.

Was die Bündelung für den Alltag bedeutet

Vier Harnesses teilen sich einen Modellpool, ein Header macht Wiederholungen kostenlos, Classifiers ordnen die Nutzung nachträglich ein, Fusion bündelt mehrere Modelle zu einer Antwort. Jede Funktion löst ein Problem, das erst durch die Bündelung entsteht: Wie behältst du bei 500 Modellen und wechselnden Anbietern den Überblick?

Du musst nicht sofort alles umstellen. Der Response Cache ist der günstigste Einstieg, weil er bei wiederholten Anfragen greift. Der Wechsel zwischen Harnesses lohnt sich, sobald du mehr als ein Werkzeug parallel betreibst. Classifiers und Fusion sind eher etwas für Teams, die Kosten und Qualität messen wollen.

Die Modellwahl findet jetzt zur Laufzeit statt, nicht in der Konfiguration. Du bindest dich nicht an einen Anbieter, sondern an eine Schnittstelle, und tauschst dahinter nach Bedarf. Das ist unbequem für Anbieter, die auf Wechselkosten gesetzt haben, und bequem für alle, die Modelle nach Preis und Aufgabe auswählen. Ob das im Dauerbetrieb stabil bleibt, zeigt sich an Ausfallzeiten und Preisen, nicht an Ankündigungen.

Quelle: threadreaderapp.com

„Training ist die Nachricht von gestern“, sagt Matt Kimball, leitender Data-Center-Analyst bei Moor Insights & Strategy. Der Satz beschreibt ganz gut, was gerade passiert: Im Rechenzentrum hat das Gespräch die Seite gewechselt. IT-Chefs (CIOs) wollen nicht mehr über den nächsten Trainingslauf reden, sondern über KI-Inferenz, also den Betrieb fertig trainierter Modelle. Auffällig ist das, weil die Branche seit etwa 2020 an einer einzigen Frage gearbeitet hat: Wie groß kann ein Modell werden?

Die Zahlen, mit denen dieser Wettlauf gemessen wurde, sind bekannt. Die größte Version von GPT-3 beantwortete 2020 auf einem gängigen Wissens- und Reasoning-Benchmark 43,9 Prozent der Fragen korrekt. Vier Jahre später erreichte GPT-4o im selben Test 88,7 Prozent, das Niveau menschlicher Expertinnen und Experten. Größere Modelle waren also tatsächlich die Antwort. Mit dem Erfolg hat sich nur die Frage verschoben: Wenn Modelle gut genug für den täglichen Einsatz sind, wird nicht mehr das Training zum Engpass, sondern die Nutzung – und damit die Hardware, auf der sie läuft.

Warum 2026 zum Jahr der KI-Inferenz wird

Nvidia-Chef Jensen Huang hat diesen Wechsel auf der GTC 2026 als „Wendepunkt der Inferenz“ bezeichnet, und die Analysefirmen ziehen mit. Der Grund ist zunächst banal: Sprachmodelle sind nützlich geworden, also werden sie benutzt. Dazu kommt eine zweite Entwicklung, die den Rechenbedarf vervielfacht. Viele der heute marktrelevanten Systeme sind Reasoning-Modelle. Sie beantworten eine Anfrage nicht in einem Durchlauf, sondern mehrfach, indem sie sich selbst neu abfragen – bekannt als Chain of Thought. Bei hohem Reasoning-Aufwand entsteht bis zu zwanzigmal so viel Text wie bei geringem oder ohne.

Und dann ist da noch die agentische KI. Sie läuft nicht als Antwort auf eine Frage, sondern rund um die Uhr, autonom auf ein vom Nutzer definiertes Ziel hin. Ein solcher Agent fragt sich permanent selbst, prüft Zwischenergebnisse, verwirft Ansätze, versucht es erneut. Aus einem kurzen Austausch mit einem Menschen wird Dauerlast. Für Rechenzentren ist das der Unterschied zwischen einem Taxi, das pro Fahrt abgerechnet wird, und einem Bus im Linienbetrieb. Die Nachfrage nach KI-Inferenz-Hardware ist damit keine Spitze mehr, sondern ein Grundrauschen, das nie ganz abschaltet.

KI-Inferenz vs. Training: zwei Probleme für dieselben Chips

Ein untrainiertes Modell gleicht einem Haufen Scrabble-Steine auf dem Tisch. Statt einzelner Buchstaben zeigen die Steine Wortfragmente, sogenannte Tokens. Alles, was man zum Schreiben fast beliebiger Texte braucht, liegt bereit – nur ergibt nichts davon einen Sinn. Training ist das Sortieren dieses Haufens mit einem Ratespiel im industriellen Maßstab: Das Modell sieht echten Text, das nächste Token ist verdeckt, und es muss vorhersagen, was kommt. Nach jeder Schätzung wird das richtige Token aufgedeckt, mit der Vorhersage verglichen, und aus der Differenz berechnet das System seine Treffsicherheit. Dieses Spiel läuft nicht über einen Satz, sondern über Milliarden Passagen.

Weil dabei über Backpropagation ständig alle Parameter nachjustiert werden, ist Training extrem rechenintensiv. Deshalb sind in den vergangenen Jahren immer größere Rechenzentren entstanden. Irgendwann entscheidet der Ersteller, dass weiteres Training den Aufwand nicht mehr rechtfertigt. Die Parameter frieren ein, aus dem Spiel wird ein vortrainiertes Modell, ein kurzes Fine-Tuning setzt Feinheiten obendrauf, dann wird ausgeliefert. Danach beginnt die Inferenz. An dieser Stelle liegt ein verbreiteter Denkfehler.

Man könnte annehmen, KI-Inferenz sei billiger, weil die rechenintensive Backpropagation wegfällt. Sudeep Bhoja, Gründer und CTO des Inferenz-Hardware-Herstellers d-Matrix, widerspricht dem. Die Modelle seien autoregressiv, die nächste Ausgabe hänge von der vorherigen ab. Um das nächste Token zu erzeugen, müssen alle Gewichte und der gesamte Kontext gelesen werden – Prompts, bisherige Antworten, hochgeladene Dateien. Es ist also nicht weniger Rechnung, sondern vor allem viel Datenverkehr, und der wiederholt sich mit jedem einzelnen Token.

Prefill und Decode: der Speicher als Engpass

Ein Sprachmodell arbeitet in zwei Phasen, die sich stark unterscheiden. Die erste, Prefill, ist das Lesen der Eingabe. Alle Tokens werden gleichzeitig verarbeitet, das Modell berechnet, wie jedes Token mit allen anderen zusammenhängt – die sogenannte Attention, das Kernmerkmal der Transformer-Architektur. Ergebnis sind Schlüssel- und Wertvektoren, die fast alle Modelle in einem Zwischenspeicher ablegen, dem KV-Cache. Er beginnt klein, kann aber auf Dutzende Gigabyte anwachsen, weil er die gesamte Konversation als Notizzettel mitführt. Prefill lässt sich gut parallelisieren, weshalb Grafikchips hier stark sind: Pixelberechnung ist ebenfalls massiv parallel, die Architektur passt zufällig gut dazu.

Die zweite Phase, Decode, ist das Gegenstück. Hier entsteht die Antwort Token für Token, jeder Schritt greift auf den KV-Cache zu und schreibt neue Vektoren hinein. Das Problem: Für jedes einzelne Token muss das gesamte Modell aus dem Speicher gelesen werden, dazu Dutzende bis Hunderte Gigabyte Parameter. Die Datenmenge übersteigt regelmäßig die Bandbreite, die die Hardware liefern kann. Deshalb stehen Teile eines Inferenz-Beschleunigers still, während sie auf Nachschub warten. Forscher haben gemessen, dass Nvidia H100 beim Betrieb quelloffener LLMs zwischen 50 und 80 Prozent der Zeit untätig sind.

Shahriar Rabii, früher Leiter der Silicon-Entwicklung bei Meta und Mitgründer des Start-ups Majestic Labs, bringt das Dilemma auf eine knappe Formel: Mit dem GPU-Ansatz überprovisioniere man Rechenleistung und hungere beim Speicher. Genau das treibt derzeit den Speicherausbau. Wer heute über KI-Chips spricht, spricht in Wahrheit über Datenbewegung – und über die Frage, wie teuer ein einzelnes erzeugtes Token am Ende ist.

Zwei Wege aus dem Engpass: stapeln oder verlängern

d-Matrix und Majestic Labs verfolgen dasselbe Ziel mit entgegengesetzten Mitteln. d-Matrix setzt bei seinem Beschleuniger Raptor auf Nähe: Der Rechenchip wird direkt auf einen DRAM-Die gestapelt, statt Speicher rund um den Prozessor zu legen. Bhoja zufolge schrumpfen die Wege, die Daten zurücklegen müssen, von Millimetern auf Mikrometer. Das ist wie beim Hochhausbau – vertikal zu gehen erlaubt mehr Inhalt auf gleicher Grundfläche. Übliche High Bandwidth Memory dagegen wird als Stapel am Rand der GPU platziert, was für Training hervorragend funktioniert, für Inferenz aber Mengen und Bandbreiten begrenzt.

Majestic geht den umgekehrten Weg und verlängert die Strecke. Über eine proprietäre Kupferverbindung und einen Aggregator-Chip will das Unternehmen Speicherstapel anbinden, die nicht direkt neben dem Prozessor sitzen. Rabii nennt eine Reichweite von etwa einem Meter – statt der zwei bis drei Millimeter, die ein HBM-Interface zulässt. Damit ließen sich bis zu 128 Terabyte DRAM in einem einzigen Rack unterbringen, deutlich mehr als die rund 20 Terabyte HBM3E, die Nvidias GB300 NVL72 bietet. Beide Firmen nutzen dabei Standard-DRAM statt HBM, auch aus Kostengründen: Laut dem Speicheranalysten Jim Handy ist HBM zwei- bis dreimal so teuer.

Die HBM-Anbieter bleiben dennoch aktiv. HBM4 ist in Produktion und soll in Nvidias Vera-Rubin-GPU zum Einsatz kommen, die für die zweite Hälfte 2026 erwartet wird. Hoshik Kim, Leiter der Speichersystem-Forschung bei SK Hynix, verspricht sich davon eine Verdopplung der maximalen Bandbreite und mehr Speicher pro Stapel. Der Wettbewerb läuft also nicht zwischen richtig und falsch, sondern zwischen zwei Antworten auf dieselbe Frage: Wie bekommt man möglichst viele Daten möglichst schnell an möglichst viele Rechenwerke?

Nvidia, Cerebras und Trainium: Allianzen statt Alleingänge

Die großen Player setzen auf mehrere Chiparten gleichzeitig. Nvidias GPUs und Amazons Trainium-Beschleuniger, ursprünglich fürs Training entworfen, bleiben für Prefill stark. Für Decode braucht es andere Hardware, und dort entstehen die ungewöhnlichen Bündnisse. Amazon Web Services teilt die Inferenz auf: Trainium übernimmt den rechenintensiveren Teil, während Cerebras mit seiner Wafer-Scale-Engine den speicherlastigen Teil abdeckt – Chips von der Größe eines Esstellers, auf denen Speicher und Recheneinheiten nebeneinander liegen, um Bandbreite zu maximieren.

Auch Nvidia hat sich extern bedient und laut Berichten Schlüsselpersonal sowie geistiges Eigentum des Inferenz-Start-ups Groq übernommen, in einem umstrittenen Geschäft im Volumen von rund 20 Milliarden US-Dollar. Ein weiteres Signal: Anthropic zahlt einem Wettbewerber mehr als eine Milliarde Dollar pro Monat für gemietete Rechenleistung. Solche Summen sind kein Ausdruck von Bequemlichkeit, sondern von Knappheit. Wer KI-Inferenz in großem Stil anbietet, kann sich derzeit die falsche Chip-Mischung nicht leisten.

Was das für den Blick auf KI-Inferenz bedeutet

Die naheliegende Schlussfolgerung wäre, dass ein Hersteller als Sieger hervorgeht. Danach sieht es nicht aus. Die Hardware für KI-Inferenz differenziert sich gerade in mehrere Nischen, weil die Arbeitslast selbst zerfällt: Prefill skaliert über parallele Rechenleistung, Decode über Speicherbandbreite, Reasoning-Modelle erhöhen das Datenvolumen, agentische KI verlängert die Laufzeit. Wer heute Inferenz-Beschleuniger für LLMs plant, sollte deshalb nicht nach der höchsten Rechenleistung fragen, sondern nach dem eigenen Lastprofil. Lange Kontexte, viele gleichzeitige Nutzer und dauerhaft laufende Agenten stellen andere Anforderungen als ein Chatbot mit kurzen Antworten.

Für den Alltag der meisten Unternehmen heißt das: Die Frage verschiebt sich von der Technik zur Rechnung. Entscheidend wird, wie viel Speicher pro Beschleuniger verfügbar ist, wie teuer die Datenbewegung ausfällt und was am Ende ein einzelnes Token kostet. Der Aufwand in der KI-Landschaft verlagert sich damit von der Forschung an größeren Modellen zum Betrieb – und die Hardware, die diesen Betrieb trägt, wird gerade neu gebaut.

Quelle: spectrum.ieee.org