Kategorie: Tool-Tests

Acht verschiedene Erweiterungen bringt das neue Plugin-Paket Qwen-MM-Plugins für KI-Agenten mit. Das Projekt von Alibaba verleiht den Qwen-Modellen native multimodale Fähigkeiten – von Bild- und Videoanalyse über 3D-Modellierung bis zu Bildungsvideos.

Wer mit KI-Agenten arbeitet, kennt das Problem: Viele Modelle sind auf Text beschränkt. Separate APIs für Vision oder Audio existieren zwar, aber die Integration in bestehende Agenten ist oft mühsam. Die Qwen-MM-Plugins setzen genau hier an. Sie bündeln verschiedene multimodale Werkzeuge und machen sie über einheitliche Schnittstellen verfügbar – ohne dass du für jeden Einsatzzweck eine eigene Infrastruktur aufbauen musst.

Was sind die Qwen-MM-Plugins?

Die Qwen-MM-Plugins sind eine Sammlung von Erweiterungen, die die Fähigkeiten von Qwen-Modellen erweitern. Jede Erweiterung besteht aus zwei Teilen: einem Skill, der dem Modell mitteilt, welche Werkzeuge verfügbar sind, und einem optionalen MCP-Server, der die eigentlichen Werkzeuge bereitstellt. MCP steht für Model Context Protocol – ein offener Standard, der es KI-Modellen erlaubt, mit externen Tools zu kommunizieren. Dadurch können Agenten nicht nur Texte verarbeiten, sondern auch Bilder, Videos, 3D-Modelle und sogar CAD-Dateien.

Das Projekt richtet sich an Entwicklerinnen und Entwickler, die mit Qwen-Modellen arbeiten – sei es für Prototypen, interne Tools oder produktive Anwendungen. Die Plugins sind modular aufgebaut: Du installierst nur das, was du konkret brauchst, und sparst dir dadurch unnötigen Ballast. Das Repository enthält außerdem Kochbücher und Beispiele, die den Einsatz in der Praxis zeigen.

Bemerkenswert ist die Architektur. Die Plugins sind als native MCP-Server umgesetzt, die von vielen gängigen Agenten-Harnesses wie Claude Code, Codex oder Qwen Code direkt unterstützt werden. Du kannst die Werkzeuge also in deiner bevorzugten Umgebung nutzen, ohne auf proprietäre Schnittstellen angewiesen zu sein.

Die acht Capabilities im Überblick

Die Qwen-MM-Plugins umfassen acht verschiedene Capabilities, jede mit einem klaren Fokus. Die erste ist core – sie bietet lokale Ein- und Ausgabe für Bilder und Videos in dynamischer Auflösung. Du kannst damit Dokumente visualisieren, Bilder zuschneiden, Anmerkungen machen und Frames extrahieren. Diese Erweiterung ist die Basis für alle anderen, da sie den Umgang mit lokalen Dateien ermöglicht.

Die zweite Capability heißt api und bündelt Cloud-APIs für Medienverständnis. Dazu gehören Vision-Chat, OCR, Grounding, sowie Audio- und Videoverständnis mit Zeitstempeln. Wenn du Sprache transkribieren, Sprecher unterscheiden oder Ereignisse in Videos zählen willst, ist das hier abgedeckt. Aktuell wird DashScope als Provider unterstützt, was vor allem für Nutzer der Alibaba-Cloud interessant ist.

Die dritte Erweiterung, search, ermöglicht Websuche und umgekehrte Bildersuche, um Fakten zu überprüfen. Sie nutzt den Serper-Dienst und hilft Agenten, aktuelle Informationen abzurufen oder die Herkunft von Bildern zu klären. Die vierte, video-memory, ist ein hierarchischer Graph-Speicher für sehr lange Videos. Damit können Agenten Fragen über Inhalte beantworten, die viele Minuten oder Stunden dauern – ohne den Kontext zu verlieren.

Die restlichen Capabilities runden das Angebot ab: video-edit bietet Workflows für Videobearbeitung und -generierung, blender steuert eine laufende Blender-Instanz über Python – mit 22 Tools für Modellierung, Materialien, Beleuchtung und Rendering. freecad macht Ähnliches für FreeCAD und erlaubt parametrische CAD-Modellierung mit 14 Werkzeugen sowie STEP/STL-Import und FEM-Analyse. Schließlich gibt es noch edu-agent, das aus mathematischen oder naturwissenschaftlichen Problemstellungen Schritt-für-Schritt-Erklärvideos auf Chinesisch generiert – eine Erweiterung, die nur aus einem Skill ohne MCP-Server besteht.

Architektur: Skills und MCP-Server harmonisch kombiniert

Das architektonische Konzept ist einfach und flexibel. Jede Capability ist eine eigenständige Einheit, die du separat installieren kannst. Die Skills sind im Wesentlichen Beschreibungen, die dem Modell sagen: „Diese Werkzeuge existieren und so werden sie benutzt.“ Der MCP-Server liefert die eigentliche Funktionalität – er wird bei Bedarf über uvx gestartet, ein Tool, das Python-Pakete in isolierten Umgebungen ausführt. Dadurch entfällt die manuelle Installation von Abhängigkeiten via pip, was Zeit spart und Fehler vermeidet.

Ein weiterer Vorteil ist die Wiederverwendbarkeit. Da die Plugins auf dem standardisierten MCP-Protokoll basieren, funktionieren sie nicht nur mit Qwen-Modellen, sondern prinzipiell mit jedem Agenten, der dieses Protokoll unterstützt. Das Projekt nennt explizit Claude Code, Codex, Qoder, OpenClaw, Qwen Code und Gemini CLI als unterstützte Umgebungen. So kannst du dieselben Fähigkeiten in verschiedenen Tools nutzen, ohne jeweils eigene Implementierungen zu pflegen.

Gut gelöst ist die dynamische Auflösung beim Lesen von Bildern und Videos. Die Plugins skalieren jede Datei automatisch auf das Patch-Raster des Vision-Language-Modells – ein 4K-Screenshot mit winziger Schrift wird genauso detailreich erfasst wie ein kleines Thumbnail. Du musst keine manuelle Größenanpassung vornehmen, sondern einfach die Datei referenzieren und deine Frage stellen. Das macht die Arbeit mit gemischten Medien deutlich angenehmer.

Installation: So einfach geht’s

Die Installation der Qwen-MM-Plugins ist dank eines geführten Installationsskripts unkompliziert. Ein einziger Befehl erledigt Installation, Konfiguration, Verifikation und Deinstallation für alle unterstützten Agenten-Harnesses. Das Skript nutzt die nativen Installationsmechanismen der jeweiligen Umgebung und schreibt eine gemeinsame Konfigurationsdatei unter ~/.qwen-mm-plugins/config, die sowohl GUI- als auch Terminal-Anwendungen lesen können. So konfigurierst du alles einmal und nutzt es überall.

Für Windows-Nutzer gibt es eine Besonderheit: Unterstützt wird nur WSL2 (Windows Subsystem for Linux) mit Ubuntu. Du musst das Repository im Home-Verzeichnis von WSL klonen, nicht unter einem gemounteten Windows-Laufwerk wie /mnt/c. Das ist eine pragmatische Einschränkung, die für die meisten Entwickler kein Hindernis darstellt, da WSL2 inzwischen zum Standard gehört.

Wer lieber manuell vorgeht oder einen weniger verbreiteten Agenten nutzt, kann die Plugins auch per Hand installieren. Dazu registriert man den Skill und den MCP-Server in der Konfiguration des jeweiligen Harnesses. Das Projekt enthält detaillierte Anleitungen für jeden unterstützten Agenten. Alternativ kann man den Agenten auch einfach bitten, die Installation vorzunehmen – die meisten modernen Agenten sind dazu in der Lage, wenn sie das Repository kennen.

Konfiguration und erste Schritte

Bevor du die API-basierten Werkzeuge nutzen kannst, musst du in der Regel API-Schlüssel hinterlegen. Für die Cloud-Dienste von DashScope benötigst du eine DASHSCOPE_API_KEY, für die Websuche eine SERPER_API_KEY. Die lokale Bild- und Videoverarbeitung kommt ohne Schlüssel aus – ein großer Vorteil, wenn du sensible Daten nicht an externe Dienste senden willst. Du kannst die Schlüssel als Umgebungsvariablen exportieren oder in der Konfigurationsdatei ablegen, die standardmäßig gelesen wird, falls keine Variable gesetzt ist.

Der Schnellstart ist denkbar einfach: Sobald eine Capability installiert ist, kannst du eine Datei in deinem Agenten referenzieren und eine Frage dazu stellen. Das Modell wählt automatisch das passende Tool aus. Du musst weder die genauen API-Kommandos kennen noch selbst Werkzeuge ansteuern. Genau das macht diese Plugins aus: Sie machen Multimodalität komplett transparent.

Ein Beispiel: Du zeigst deinem Agenten ein Foto eines defekten Bauteils und fragst nach der wahrscheinlichen Verschleißursache. Die Core-Erweiterung liest das Bild, die API-Erweiterung nutzt Vision-Language-Modelle für die Analyse, und wenn du noch eine Websuche anschließt, kann der Agent sogar aktuelle Reparaturhinweise von Herstellern abrufen. So kombiniert er verschiedene Fähigkeiten in einer einzigen Anfrage – etwas, das früher mehrere separate Systeme erforderte.

Einordnung: Warum das wichtig ist

Die Qwen-MM-Plugins sind mehr als nur eine weitere Tool-Sammlung. Sie zeigen, wie sich multimodale KI praktisch einsetzen lässt, ohne dass du dich in proprietäre Ökosysteme einladen musst. Der Ansatz, standardisierte MCP-Server zu verwenden, fördert Interoperabilität und senkt die Einarbeitungszeit erheblich. Für Entwickler bedeutet das: weniger eigene Integrationen, mehr Fokus auf die eigentliche Anwendung.

Beeindruckend ist die Bandbreite der Fähigkeiten – von einfacher Bildanalyse über komplexe 3D-Modellierung in Blender bis hin zu parametrischer Konstruktion in FreeCAD. Damit adressiert das Projekt nicht nur klassische Text-Agenten, sondern auch Branchen wie Ingenieurwesen, Architektur und Produktdesign, die bisher kaum von generativen KI-Modellen profitiert haben. Die niedrige Einstiegsschwelle und die modulare Architektur machen es leicht, erste Versuche zu starten und später in bestehende Workflows einzubetten.

Allerdings hat das Projekt auch Grenzen. Viele Erweiterungen sind noch als „TBD“ markiert, die Kochbücher fehlen teilweise. Das Projekt ist jung, und die Abhängigkeit von Cloud-APIs wie DashScope könnte für manche Nutzer eine Hürde darstellen. Trotzdem ist die Richtung klar – und sie ist vielversprechend. Wenn sich solche Plugins weiter etablieren, könnten multimodale Agenten bald so selbstverständlich sein wie Text-Chatbots. Die Qwen-MM-Plugins liefern dafür einen wichtigen Baustein.

Quelle: github.com

Ein Agent erhält einen Screenshot des Bildschirms, klickt auf Schaltflächen und tippt in Formulare. Diese Fähigkeit, Computer zu bedienen, hat sich im vergangenen Jahr rasant verbessert – und doch bleibt die Frage, ob sie in Unternehmen wirklich verlässlich eingesetzt werden kann.

Die Zahlen zeigen einen Sprung: Beim Benchmark OSWorld-Verified stieg die beste Punktzahl von 42 auf 85 Prozent. Menschliche Testpersonen kommen auf etwa 72 Prozent. Damit schlagen die besten Modelle inzwischen die Menschen. Doch im echten Geschäftsleben zählt mehr als ein Benchmark: ob ein Agent über Monate hinweg zuverlässig arbeitet, ohne dass ein Mensch jeden Schritt kontrolliert. Genau dort liegt die eigentliche Herausforderung.

Der Stand der Dinge: Daten und was sie wirklich bedeuten

Die OsWorld-Verified-Zahlen stammen vom Leaderboard llm-stats.com (Stand Juni 2026). Sie messen den Anteil abgeschlossener Aufgaben in einer kontrollierten Desktop-Umgebung. Vor einem Jahr lag der beste Wert bei 42 Prozent – heute sind es 85 Prozent. Das klingt beeindruckend, aber ein Geschäftsprozess ist nur dann erfolgreich, wenn jeder einzelne Schritt klappt. Wenn ein Agent 15 von 100 Aufgaben vermasselt, bleibt für einen Backoffice-Workflow ein erhebliches Risiko. Zudem arbeiten die Modelle in der Praxis anders als im Benchmark: Sie bekommen Screenshots und liefern Klicks und Tastatureingaben zurück, oft ergänzt um DOM- oder Accessibility-Daten. Die eigentliche Magie passiert jedoch im Rahmen darum herum – der Sandbox, der Orchestrierung, der Verifikation und Wiederholungslogik.

Ein bezeichnendes Detail: Einer der größten Betreiber automatisierter Workflows – mit Millionen von Tasks pro Monat – konnte nicht sagen, welches Modell seine Agenten gerade ausführt. Der Anbieter tauscht die Modelle im Hintergrund aus, wie ein Cloud-Provider die Hardware wechselt. Sobald die Fähigkeiten eine gewisse Schwelle überschreiten, rückt das Modell in den Hintergrund. Was zählt, ist die Zuverlässigkeit des gesamten Systems.

Wo Computer-Use-Agenten heute schon produktiv arbeiten

Die praktischen Einsatzgebiete sind klar umrissen: Agenten übernehmen standardisierte, wiederholbare Aufgaben, bei denen sonst ein Mensch durch eine Benutzeroberfläche klickt. Typische Beispiele sind das Pflegen von CRM-Einträgen, das Abrufen von Daten aus Regierungs- oder Versicherungsportalen, die Verarbeitung von Aufträgen oder das Bearbeiten von IT-Tickets in ServiceNow. Entscheidend ist, dass der Pfad eindeutig und überprüfbar ist.

Ein konkretes Zahlenbeispiel: Eine CPG-Datenplattform wickelt 15 bis 20 Millionen automatisierte Portal-Interaktionen pro Monat ab. Ihre Agenten dienen als selbstheilender Fallback für handgeschriebene Scraper. Wenn ein Einzelhandelsportal sein Layout ändert, erkennt der Agent den Bruch, repariert die Automatisierung und sorgt dafür, dass die Daten weiterfließen – bevor ein Ingenieur überhaupt von dem Fehler erfährt. Ein globaler Systemintegrator berichtet von 27 aktiven Workflows, die täglich 1500 bis 2100 IT-Tickets bearbeiten, mit dem Ziel, 20 bis 25 Prozent des Personals auf höherwertige Aufgaben umzuschichten. Eine Agentur hat den gesamten Rekrutierungs-Workflow automatisiert: Nach einem Interview wird der Kandidat automatisch in das Bewerberverfolgungssystem eingetragen. Sie nutzen ein günstiges Nicht-Frontier-Modell, weil es „alles tut, was wir brauchen, und das gut“. Das Muster ist überall gleich: Je klarer die Regeln und je einfacher die Überprüfung, desto zuverlässiger funktioniert der Agent.

Die harte Realität: Wenn die Arbeit aus dem Rahmen fällt

Die größten Probleme treten auf, wenn ein Workflow mehrdeutig wird oder keine klare Erfolgskontrolle existiert. Ein Agent, der Zahlungsbedingungen aus Verträgen in ein ERP-System überträgt, könnte „net 60“ als „net 30“ lesen – der Fehler bleibt unentdeckt, bis eine Rechnung falsch rausgeht. Ebenso kritisch ist der Fall, in dem der Erfolg erst später sichtbar wird: Ein Agent reicht einen Versicherungsanspruch ein, der Bildschirm zeigt „erhalten“, die Aufgabe gilt als erledigt. Doch zwei Tage später meldet sich ein Sachbearbeiter telefonisch, weil eine Policennummer fehlt. Ein Mensch hätte das sofort geklärt, der Agent hat keinen Zugriff auf solche Nachzügler-Informationen. Der Prozess stockt still.

Diese Beispiele zeigen: Ein besseres Modell allein löst das Problem nicht. Die Lösung liegt in der Harness-Architektur – also in der Umgebung, die den Agenten umgibt und dafür sorgt, dass unerwartete Situationen erkannt und eskaliert werden. Genau hier setzen die Anbieter an, die in der Praxis erfolgreich sind. Sie bauen Systeme mit einer Feedback-Schleife, die auch subtile Fehler aufspürt, sei es durch Quervergleiche mit anderen Datenquellen oder durch manuelle Überprüfung an definierten Kontrollpunkten.

Infrastruktur schlägt Modell: Worauf Käufer wirklich achten

Im Gespräch mit Enterprise-Kunden wird deutlich: Das Modell ist selten das entscheidende Kriterium. „Die Modelle sind heute schon gut genug“, sagen sie. Entscheidend ist die Infrastruktur, die Skalierbarkeit, Sicherheit und nachweisbare Rendite bietet. Käufer interessiert nicht, ob ein bestimmtes Frontier-Modell eingesetzt wird, sondern ob die Lösung den Job zuverlässig und kosteneffizient erledigt. Deshalb entwerfen Architekten die Systeme mit Blick auf Fehlertoleranz.

Eine wiederkehrende Strategie: Der Agent führt den Workflow einmal aus, das System „cached“ ihn als deterministischen Code, und ab dann laufen alle weiteren Instanzen als preiswerte Skripte. Der Agent wird nur noch aktiv, wenn etwas schiefgeht – er diagnostiziert, repariert und erneuert den Cache. So sinken die Kosten pro Ausführung über die Zeit, und das System wird wirtschaftlich, selbst für Aufgaben mit hohem Volumen. Die Designphilosophie geht mit Unsicherheit um: Wo früher deterministischer Code einfach scheiterte, übernimmt der Agent die Flexibilität und passt sich an. Das ist „Design für den Fehlerfall“ in Reinkultur – und es erklärt, warum selbst ein mittelmäßiges Modell mit exzellenter Infrastruktur besser performt als ein Spitzenmodell ohne robustes Framework.

Der Markt fokussiert sich derzeit auf die niedrig hängenden Früchte: Workflows mit klaren Erfolgskriterien und überschaubarem Risiko. Die anspruchsvolleren Aufgaben – etwa komplexe Vertragsprüfungen oder Kundeninteraktionen mit emotionaler Komponente – bleiben vorerst menschlichen Spezialisten überlassen. Doch das Potenzial ist riesig: Jeder manuelle Klick in einem Altsystem ist ein Kandidat für die Automatisierung.

Kontext ist das neue Moat: Vom Klicken zum Verstehen

Für Gründer und Entwickler verschiebt sich der Fokus weg von der reinen Bedienung der Oberfläche. Früher musste man Selenium oder Playwright beherrschen, um einen Browser zu steuern – heute wird diese Schicht abstrahiert. Das eigentliche Know-how liegt plötzlich in der Kenntnis des spezifischen Unternehmenskontexts: die internen Abkürzungen, die bevorzugten Formulierungen, die Abhängigkeiten zwischen Abteilungen. Ein Agent, der ein SAP-System bedienen kann, ist austauschbar. Aber ein Agent, der weiß, wie die Buchhaltung in einem mittelständischen Maschinenbauer arbeitet, das ist ein echter Wettbewerbsvorteil.

Die langfristige Entwicklung ist klar: Computer-Use-Agenten werden zu einem Standardwerkzeug, so wie früher Makros oder Skripte. Die Differenzierung entsteht durch die Qualität der Integration – durch die Menge an Kontextwissen, das der Agent über den Prozess und das Unternehmen hat. Unternehmen, die dieses Wissen strukturieren und in ihre Agenten-Infrastruktur einbetten, werden ihre Effizienz dramatisch steigern. Wer es versäumt, riskiert, den Anschluss zu verlieren – denn die Konkurrenz findet gerade heraus, wie man mit weniger Klickarbeit und mehr Denkarbeit die Betriebskosten senkt.

Für dich als Entscheider heißt das: Wenn du über den Einsatz von Computer-Use-Agenten nachdenkst, lohnt es sich, nicht auf das neueste Modell zu schielen, sondern auf die Plattform und das Ecosystem, das den Agenten trägt. Frage nach den Referenzen, den Fehlerquoten, den Eskalationsmechanismen. Und sei dir bewusst: Der wahre Wettbewerbsvorteil liegt in deinem Firmenwissen, nicht in der KI-Technologie an sich. Diese Erkenntnis ist unspektakulär, aber sie entscheidet über den Unterschied zwischen einem Pilotprojekt und einem skalierenden Produktivsystem.

Quelle: a16z.com

Dein Abo-Limit ist erreicht – mitten in der Arbeit. Der Codex-Workflow läuft, dann die Meldung. Das passiert nicht nur bei intensiver Nutzung. Der Softwareentwickler Vincent Schmalbach hat beobachtet: GPT-5.6 Sol verbraucht im xhigh-Modus mehr als doppelt so viele Tokens pro Session wie sein Vorgänger GPT-5.5. Für alle, die mit OpenAI-Codex arbeiten, verändert das die Kostenrechnung grundlegend.

Was die Logs zeigen

Schmalbach verglich zwei gleich lange Zeitfenster von 14 Tagen aus seinen lokalen Logs. Die Sessions waren nicht identisch, aber mit 1.667 vor dem Wechsel und 1.715 nach dem Wechsel ähnlich genug für belastbare Rückschlüsse. Das Ergebnis: GPT-5.5 xhigh verbrauchte im Schnitt 7,30 Millionen Tokens pro Session, GPT-5.6 Sol xhigh dagegen 16,45 Millionen. Das ist ein Anstieg von 125 Prozent. Die Gesamtnutzung stieg von 12,17 Milliarden auf 28,22 Milliarden Tokens – ein Faktor von 2,32. Die Session-Anzahl wuchs nur um 2,9 Prozent. Gleiche Menge Arbeit kostet jetzt mehr als das Doppelte an Token-Kontingent.

Modell / Effort	Sessions	Tokens gesamt	Tokens pro Session
GPT-5.5 xhigh	1.667	12,17 Mrd.	7,30 Mio.
GPT-5.6 Sol xhigh	1.715	28,22 Mrd.	16,45 Mio.

Was heißt das konkret? Stell dir dein Token-Kontingent als Bankkonto mit festem monatlichem Abhebelimit vor. Mit GPT-5.5 gabst du etwa 7,3 Millionen Einheiten pro Session aus. Jetzt brauchst du für denselben Schritt 16,45 Millionen. Nach weniger als der Hälfte der Sessions ist das Konto leer. Schmalbach berichtet: Seine drei Abonnements hielten früher etwa eine Woche intensiver Arbeit aus. Mit GPT-5.6 Sol reicht ein Tag mittlerer Belastung, um alle Limits zu sprengen. Dazu hatte er auf jedem Account drei bis vier Guthaben-Resets („banked usage resets“) angespart – die sind jetzt aufgebraucht.

Gleicher Preis pro Token, höhere Rechnung

OpenAI listet für GPT-5.5 und GPT-5.6 Sol offiziell die gleichen Preise für Fresh-Input, Cached-Input und Output. Aber der Preis pro Token ist nicht das Problem. Bei gleichem Preis und 2,25-mal so vielen Tokens zahlst du effektiv 2,25-mal so viel für eine vergleichbare Mischung aus Eingabe und Ausgabe. Dazu kommt eine zusätzliche Cache-Write-Gebühr, die es bei GPT-5.5 nicht gab. Selbst bei konstanter Token-Zahl wäre die Rechnung teurer. Zusammen mit dem höheren Verbrauch wird die Kostensteigerung spürbar.

Woher der Mehrverbrauch kommt

Warum verbraucht GPT-5.6 Sol so viel mehr? Schmalbach liefert keine technische Erklärung. Die Beobachtung passt aber zu einem Trend bei neueren Sprachmodellen. Größere Kontextfenster, aufwendigere Reasoning-Ketten und umfangreichere Tool-Nutzung führen zu mehr generierten Tokens pro Modell. Im Codex-Workflow, wo das Modell Code liest, Pläne schreibt, Dateien ändert und Checks ausführt, summiert sich das schnell. Die Session-Zählung zeigt: Die Anzahl bleibt fast gleich, aber jede einzelne wird hungriger. Wie ein Auto, das auf derselben Strecke doppelt so viel Benzin verbraucht – ohne dass du schneller fährst.

Was du jetzt tun kannst

Für Nutzer von OpenAI-Abonnements oder der API ergeben sich konkrete Konsequenzen. Bei hohen Effort-Stufen wie xhigh solltest du dein Token-Budget neu kalkulieren. Bisherige Faustregeln, nach denen ein Abo eine bestimmte Anzahl Sessions abdeckt, gelten nicht mehr. Schmalbach nutzt seine Logs für solche Vergleiche – ein methodischer Ansatz, der sich lohnt. Du kannst ähnlich vorgehen: Protokolliere deine Sessions regelmäßig, um zu sehen, wo dein Kontingent bleibt. Dashboard-Ansichten mancher Anbieter sind weniger präzise als lokale Logs.

Die strategische Perspektive: Wenn du zwischen GPT-5.5 und GPT-5.6 Sol wählen kannst, wäge das Kosten-Nutzen-Verhältnis ab. GPT-5.6 Sol ist vermutlich leistungsfähiger. Aber wenn deine Aufgaben auch GPT-5.5 gut löst, sparst du durch die niedrigere Token-Menge Geld. Schmalbachs Daten zeigen: Der Wechsel verkürzt die Abo-Laufzeit von einer Woche auf einen Tag. Das ist keine Randerscheinung, sondern eine systematische Verschiebung. Die Cache-Write-Gebühr ist ein neuer Kostenfaktor. Wer häufig mit wechselnden Kontexten arbeitet, spürt sie besonders stark.

Ein weiterer Aspekt ist die Qualität der Ergebnisse. Wenn GPT-5.6 Sol bessere Pull Requests oder weniger Fehlversuche produziert, könnte der höhere Verbrauch gerechtfertigt sein. Schmalbach gibt keine Erfolgsquote an, aber er arbeitet intensiv mit dem Modell und dokumentiert die Kosten. Teste selbst, ob die Mehrkosten zu messbaren Verbesserungen führen. Wenn nicht, spricht das für GPT-5.5. Die Entscheidung hängt von deiner Nutzung ab – und davon, wie viel dir die zusätzliche Leistung wert ist.

Insgesamt: Bei intensiver Codex-Nutzung kannst du dich nicht mehr auf dein Abo verlassen, ohne den Verbrauch zu prüfen. GPT-5.6 Sol verbraucht pro Session mehr als doppelt so viele Tokens wie GPT-5.5. Das reduziert den effektiven Wert deines Kontingents um mehr als die Hälfte. Überdenke deinen Workflow, passe die Effort-Stufe an die Aufgabenkomplexität an und prüfe regelmäßig deine Logs. Die Token-Preise bleiben gleich, die Gesamtkosten steigen. Wer kalkuliert, kann trotzdem effizient arbeiten – blindes Vertrauen ins Abo-Modell ist nicht mehr angebracht.

Die Qual der Wahl: Welches KI-Modell passt wirklich?

Du kennst das sicher: Du stehst vor einem Regal voller Werkzeug. Da gibt es die teure Profi-Maschine, das günstige No-Name-Gerät und das Mittelklasse-Modell, das irgendwie gut aussieht. Ohne es auszuprobieren, weißt du nicht, ob es für deinen Arbeitsplatz taugt. Genauso geht es Entwicklern, die heute eine KI-Anwendung bauen. Sie haben eine Auswahl von Hunderten von Modellen, vom schlanken Open-Source-Modell bis zum gigantischen proprietären System. Die meisten treffen ihre Wahl nach Bauchgefühl, nach ein paar Beispielen auf einer Demo-Seite oder nach dem Preis. Das ist nicht unbedingt falsch, aber es ist kein systematischer Weg.

Der Blog-Autor von sebask.de hat sich deshalb einmal angeschaut, wie der Dienst OpenRouter mit einem neuen Tool namens Ori Eval das Problem löst. Die Idee ist so einfach wie überzeugend: Statt über Modelle zu raten, misst man ihre Leistung anhand der eigenen Aufgaben. Ori Eval ist ein Agent, der deinen Code durchsucht, die relevanten Stellen findet, Tests baut und dann Modelle gegeneinander antreten lässt. Das Ergebnis ist eine quantitative Antwort auf die Frage: Welches Modell ist das beste für genau dieses Projekt? Es geht nicht um abstrakte Benchmarks aus dem Internet, sondern um den konkreten Einsatz bei dir.

Ein Agent, der wie ein erfahrener Kollege arbeitet

Ori Eval ist keine klassische Software, die man nach einer Installation durchklickt. Es ist ein KI-Agent. Das klingt erstmal nach Modebegriff, bedeutet hier aber etwas Konkretes: Ori Eval übernimmt den gesamten Evaluationsprozess, von der Analyse deiner Codebasis bis zum fertigen Testbericht. Du musst also kein Experte für Machine-Learning-Evaluation sein. Der Agent führt dich durch den Prozess, wie es ein guter Senior-Entwickler tun würde. Er fragt nach deinen Zielen, schaut sich an, wo in deinem Projekt überhaupt Modelle zum Einsatz kommen, und schlägt dann vor, welche Stellen getestet werden sollten.

Der Ablauf beginnt damit, dass du deinem Coding-Agenten einen einfachen Befehl gibst: /spawn-ori-eval. Das funktioniert direkt über die OpenRouter-MCP-Integration. Der Agent holt sich dann die Anweisungen und installiert Ori Eval in deinem Projekt. Danach übernimmt Ori Eval das Steuer. Es scannt die Codebasis und findet jede Stelle, an der ein Modell aufgerufen wird. Es sieht also nicht nur, dass ein LLM benutzt wird, sondern auch wo, in welchem Kontext und mit welchem Modell. Das ist ein entscheidender Vorteil gegenüber manuellen Tests, bei denen man schnell mal einen Teil übersieht.

Die Prüfinstanz: Drei Dinge zählen

Was passiert eigentlich bei so einer Evaluation? Ori Eval prüft bei jedem Lauf drei Dinge. Erstens: Welche Tools hat der Agent aufgerufen? Zweitens: Welche Tools hat er vermieden? Und drittens: Wie gut ist die Qualität der Antwort? Das klingt technisch, ist aber im Kern einfach. Ein Agent, der zu viele unnötige Funktionen aufruft, kostet Zeit und Geld. Ein Agent, der wichtige Tool-Calls auslässt, liefert möglicherweise falsche Ergebnisse. Und die Antwortqualität lässt sich kaum an einer einzelnen Metrik festmachen. Deshalb nutzt Ori Eval einen LLM-as-a-Judge: Ein weiteres Modell bewertet die offenen Antworten anhand von Kriterien, die vorher mit dir zusammen festgelegt wurden. So entsteht ein Score, der reproduzierbar und vergleichbar ist.

Wer schon einmal versucht hat, KI-Modelle fair zu vergleichen, kennt das größte Problem: Die Umgebung muss gleich bleiben. Wenn der Test mal mit einer anderen Temperatur, mal mit einem anderen Kontextfenster läuft, sind die Ergebnisse wertlos. Ori Eval pinnt deshalb das Test-Harness und das benutzte Modell für den Judge. Das heißt: Jeder Lauf startet unter exakt denselben Bedingungen. Ändert sich das Ergebnis, liegt es am getesteten Modell und nicht an einem verrutschten Parameter. Diese Konsistenz ist das Fundament für verlässliche Aussagen. Der Autor betont, dass genau dieses Detail Ori Eval von vielen anderen Lösungen unterscheidet.

Vom Bug zum Testfall: Regressionen verhindern

Ein besonders nützliches Feature ist die Umwandlung von Bugs in Tests. Angenommen, dein Agent macht bei einer bestimmten Aufgabe einen Fehler. Bei Ori Eval reicht ein Handgriff: Du definierst dieses Fehlverhalten als Test. Der Test schlägt jetzt fehl, genau wie der Bug. Dann änderst du den Code oder das Modell so lange, bis der Test grün ist. Und von da an bleibt der Test in deiner Suite. Wenn jemand später eine Änderung vornimmt, die diesen Fehler wieder einführt, schlägt der Test im CI an und der Build bricht ab. So kommen Fehler nie zu deinen Nutzern. Das ist die gleiche Logik wie beim Test-Driven Development, nur eben für KI-Agenten.

Die Integration in die CI-Pipeline ist ebenso unkompliziert. Man fügt einen Schritt in den GitHub-Actions-Workflow ein und ruft ori eval auf. Da Ori Eval sich wie ein Unit-Test-Framework verhält, ist der Exit-Code entscheidend: Schlägt ein Test fehl, schlägt der Build fehl. Man sollte den Eval-Job allerdings als separaten, optionalen Job konfigurieren, weil echte Modellaufrufe Geld kosten. Aber gerade diese Kontrolle ist hilfreich. Neue Modelle erscheinen inzwischen fast wöchentlich. Mit einem geplanten monatlichen Lauf hast du immer den aktuellen Stand. Ori Eval kann dabei sogar deinen bisherigen Modelltreue-Bonus berücksichtigen: Du legst fest, ob das aktuelle Modell im Mix bleiben soll oder ob nur neue Kandidaten zugelassen sind.

Zugriff auf alle OpenRouter-Modelle

Ein weiterer Punkt, der Ori Eval auszeichnet, ist die Anbindung an OpenRouter. Viele Evaluations-Tools sind auf die Modelle eines einzelnen Anbieters beschränkt. Ori Eval hat dagegen Zugriff auf das gesamte Modellangebot von OpenRouter. Das bedeutet: Du kannst ein günstiges Modell mit einem teuren vergleichen, ohne deine Infrastruktur umzubauen. Der Agent schlägt dir selbst eine Liste von Modellen vor, die zu deinen Kriterien passen. Du kannst etwa einen Preisdeckel setzen oder verlangen, dass dein jetziges Modell in der Auswahl bleibt. Die Entscheidung, welches Modell getestet wird, trifft also nicht jemand anderes für dich, sondern gemeinsam mit dir.

Auch die Preisfrage spielt eine Rolle. Der Autor weist darauf hin, dass OpenRouter nicht nur die neuesten Flagship-Modelle auflistet, sondern auch viele ältere oder kleinere Modelle, die oft ein besseres Preis-Leistungs-Verhältnis haben. Ori Eval ist explizit darauf ausgelegt, genau solche Modelle zu finden. Wenn du zum Beispiel nur einfache Klassifikationen machst, brauchst du kein 100-Milliarden-Parameter-Modell. Ein schlankes Modell reicht, läuft schneller und kostet weniger. Die Evaluationsergebnisse zeigen dir das in Zahlen.

Datenschutz und Login: So bleibt es sicher

Kritische Gemüter fragen sich bei solchen Tools sofort, was mit ihren Daten passiert. Ori Eval bietet hier eine klare Antwort: Du entscheidest, ob deine Daten in die Evaluierung einfließen. Der Agent fragt dich vor jedem Lauf, ob deine Daten verwendet werden sollen. Für die interaktive Nutzung muss man sich einmalig mit ori login anmelden. Dabei öffnet sich der Browser bei OpenRouter, und die Zugangsdaten werden gespeichert. Ein händisches Eintippen von API-Schlüsseln ist also nicht nötig. Für CI-Umgebungen nutzt man stattdessen die Umgebungsvariable OPENROUTER_API_KEY, die aus einem Secret der Repository-Einstellungen stammt. Diese Trennung zwischen interaktiver und automatisierter Nutzung ist durchdacht.

Die Netell-basierten Testdateien liegen als normale .eval.ts-Dateien vor. Sie werden mit bun test ausgeführt. Das bedeutet: Deine Evaluation ist reiner Code, den du versionieren, reviewen und weiterentwickeln kannst. Du bist also nicht an ein proprietäres Format gebunden. Der Autor erklärt, dass das ein großer Vorteil ist, weil Evaluationen damit überprüfbar und reproduzierbar bleiben. Du kannst sogar den Judge-Mechanismus an deine Bedürfnisse anpassen. Die Standard-Einstellung ist bereits vorkalibriert, aber wer will, kann eigene Kriterien festlegen und Mindestpunktzahlen definieren. Das geht so weit, dass du für jede Testfrage eigene Gold-Antworten hinterlegst, gegen die neue Modelle bewertet werden.

Wer sollte Ori Eval nutzen?

Man könnte meinen, so ein Tool sei nur etwas für große Unternehmen mit dedizierten ML-Teams. Das Gegenteil ist der Fall. Ori Eval ist für alle gedacht, die eine App mit KI-Funktionen bauen, egal ob Solo-Entwickler, Startup oder Konzern. Du musst kein Experte für Evaluationsmethoden sein. David gegen Goliath funktioniert hier: Der Agent übernimmt die Komplexität. Er stellt die richtigen Fragen, schlägt Testfälle vor und erklärt, warum er bestimmte Modelle ausgewählt hat. Das erinnert an einen erfahrenen Kollegen, der dir über die Schulter schaut und nicht einfach eine Lösung hinknallt, sondern dir zeigt, wie man zu der Lösung kommt.

Viele Teams wählen ihr KI-Modell nach dem Prinzip „Das größte, das wir uns leisten können“. Das ist verständlich, aber oft verschwenderisch. Ori Eval setzt auf eine andere Herangehensweise: Das beste Modell ist nicht das mit den meisten Parametern oder dem höchsten Leaderboard-Punktestand. Es ist das Modell, das bei deinen Daten, deinen Aufgaben und deinen Randbedingungen am besten abschneidet. Und genau das misst das Tool. Es schaut auf deine Codebasis, nicht auf generische Benchmarks. Man könnte sagen: Ori Eval ist der TÜV für deine KI-Modelle – seriös, gründlich und ergebnisorientiert.

Was bleibt: Geerdete Einordnung

Natürlich ist auch ein so gutes Tool kein Allheilmittel. Evaluationen kosten Zeit und Geld, und sie bilden immer nur den Ausschnitt ab, den du testest. Doch das ist kein Widerspruch. Im Gegenteil: Der bewusste Umgang mit diesen Kosten ist Teil des Konzepts. Du entscheidest, wie oft du läufst und welche Modelle du testest. Die Ergebnisse geben dir eine klare Handlungsgrundlage. Du weißt am Ende nicht nur, welches Modell gewinnt, sondern auch warum. Das schützt vor Bauchentscheidungen, die später teuer werden können.

Für alle, die schon länger mit KI arbeiten, ist Ori Eval ein logischer nächster Schritt. Die Branche professionalisiert sich. Anstatt jeden Monat manuell zu prüfen, ob ein neues Modell besser ist, überlässt man das einem Agenten, der es zuverlässig und dokumentiert erledigt. Der Autor von sebask.de sieht darin die Zukunft der Modellauswahl: systematisch, reproduzierbar und immer auf dem aktuellen Stand. Wer einmal mit echten Zahlen gesehen hat, wie viel besser das richtige Modell für den eigenen Anwendungsfall ist, möchte nicht mehr zurückraten. Ori Eval liefert genau diese Zahlen.

Quelle: openrouter.ai

Du kennst das vielleicht: Du stellst einer KI eine Frage, und es dauert ein paar Sekunden, bis die Antwort eintrudelt. Manche Antworten kommen sofort, andere brauchen gefühlt eine Ewigkeit. Was du dabei nicht siehst, ist das komplexe Zusammenspiel aus Modellgröße, Hardware und Software, das hinter den Kulissen stattfindet. In der KI-Welt geht es aktuell nämlich nicht nur um schlauere Modelle, sondern auch um die Frage, welche Hardware sie überhaupt stemmen kann. Ein Beitrag des Unternehmens Wafer wirft dabei ein Schlaglicht auf einen Aspekt, der oft übersehen wird: den Speicher. Und der könnte sich als entscheidender Vorteil erweisen.

Doch bevor wir in die Details eintauchen: Was ist eigentlich ein großes KI-Modell? Stell dir ein gigantisches Netzwerk aus Millionen, ja Milliarden von Zahlen vor. Diese Zahlen, die man Parameter nennt, bestimmen, wie das Modell Texte versteht und generiert. Je mehr Parameter, desto leistungsfähiger ist das Modell in der Regel – aber auch desto größer ist der Speicherbedarf. Die Spitzenmodelle, die du aus ChatGPT und Co. kennst, haben oft hunderte Milliarden Parameter. Und die Open-Source-Szene hat in letzter Zeit mächtig aufgeholt: Modelle wie DeepSeek V4-Pro oder GLM5.2 erreichen fast das Niveau kommerzieller Top-Modelle. Der neue Star heißt allerdings Kimi K3 – und der ist ein echtes Schwergewicht.

Kimi K3 bringt stolze 2,8 Billionen Parameter auf die Waage. Das sind mehr als doppelt so viele wie bei GLM5.2 und fast doppelt so viele wie bei DeepSeek V4-Pro. Um ein solches Modell überhaupt zu laden, brauchst du mehr als 1,5 Terabyte VRAM – und das, bevor du überhaupt den sogenannten KV-Cache berücksichtigst, der für ein Modell mit 1 Million Token Kontext nötig ist. Zur Einordnung: Selbst eine Node mit acht NVIDIA B200-GPUs, die jeweils 192 GB Speicher haben, reicht dafür nicht aus. Man müsste also zwei Nodes zusammenschließen, was wiederum enorme Datenmengen zwischen den Rechnern hin- und herschickt. Genau hier kommt ein anderer Hersteller ins Spiel: AMD.

Der MI355X von AMD hat nämlich 288 GB Speicher pro GPU. Damit kann eine einzelne Node mit acht dieser Beschleuniger das komplette Modell aufnehmen – samt Kontext. Und das zu einem deutlich günstigeren Preis: Laut Wafer kostet der MI355X im Durchschnitt etwa 2,4-mal weniger pro GPU als ein NVIDIA B300 und etwa 1,7-mal weniger als ein B200. Auf dem Papier also ein klarer Preis-Leistungs-Sieg. Doch in der Praxis gibt es seit Jahren einen Haken: AMDs Software-Unterstützung. Kernel und Inferenz-Frameworks waren lange nicht so ausgereift wie NVIDIAs CUDA-Ökosystem. Deshalb galt es als riskant, ernsthafte KI-Workloads auf AMD zu betreiben. Doch wie der Blogbeitrag zeigt, könnte sich das gerade ändern.

Ein Benchmark mit Überraschungen

Das Team von Wafer hat Kimi K3 auf einer MI355X-Node zum Laufen gebracht und vermessen. Die Ergebnisse sind beachtlich. Bei einem typischen Benchmark mit 1.024 Eingabe-Token und 400 Ausgabe-Token erreicht die AMD-Node eine aggregierte Durchsatzrate von 952 Token pro Sekunde pro Node. Im Einzelstream schafft sie immerhin 118 Token pro Sekunde. Zum Vergleich: Eine Zwei-Node-Konfiguration mit B200-GPUs, die ebenfalls Kimi K3 serviert, kommt auf gerade einmal 498 Token pro Sekunde über alle 16 GPUs verteilt – also etwa 249 Token pro Sekunde pro Node. Die AMD-Lösung ist also fast viermal schneller im aggregierten Durchsatz pro Node. Und selbst die deutlich teureren B300-GPUs liegen mit 1.568 Token pro Sekunde zwar vorn, aber bei 2,4-fachem Preis wirtschaftet die AMD-Node deutlich besser: Auf jeden ausgegebenen Dollar kommen 48 Token pro Sekunde beim MI355X, aber nur 33 beim B300. Der B200 fällt mit gerade einmal 7 Token pro Dollar komplett ab.

Diese Zahlen zeigen etwas Wichtiges: Bei riesigen Modellen wird der Speicher zum Flaschenhals. NVIDIA hat mit der B200-Serie zwar enorme Rechenleistung, aber nicht genug Speicher, um ein Modell wie Kimi K3 in einer einzelnen Node zu halten. Die cross-node Kommunikation, die bei einer Zwei-Node-Lösung nötig ist, kostet wertvolle Zeit auf dem kritischen Pfad der Dekodierung. AMD hat dagegen genau auf diese Kapazität gesetzt – und damit einen praktischen Vorsprung. Natürlich ist das nur ein einzelner Benchmark, aber er veranschaulicht einen Trend: Speicherkapazität und Speicherbandbreite werden für KI-Inferenz immer entscheidender, nicht nur nackte Rechenleistung.

Software ist der Schlüssel – und die Hölle

Dass die MI355X von Haus aus mit Kimi K3 klar kommt, ist ein Fortschritt. Aber der Weg zu den guten Zahlen war nicht frei von Hindernissen. Das Team von Wafer musste ein Problem mit dem spekulativen Decoding lösen. Dabei geht es um eine Technik, die mehrere Token gleichzeitig vorhersagt und dadurch die Antwortgeschwindigkeit erhöht. Kimi K3 bringt zwar keine eigenen Entwurfs-Tensoren mit, aber ein externes Modell namens RadixArk diente als Entwurfsmodell. Unter CUDA funktionierte das sofort, unter ROCm, der AMD-Softwareplattform, gab es jedoch einen Fehler. Die Ursache: Ein bestimmter Kernel, der für die Neuberechnung von Wahrscheinlichkeiten zuständig ist, war im ROCm-Build nicht definiert. Statt eines komplexen Kernels war die Lösung überraschend simpel: eine einzelne PyTorch-Funktion, die das Sortieren, Ausblenden und Neu-Skalieren übernimmt. Kein maßgeschneiderter Kernel, nur eine fehlende Import-Zuordnung. Das zeigt, wie schnell man bei AMD auf unerwartete Hürden stößt – und wie trivial die Lösungen manchmal sind.

Noch interessanter war das Prefill-Problem. Bevor ein Modell eine Antwort generieren kann, muss es die Eingabe verarbeiten – das nennt man Prefill. Bei langen Kontexten, etwa 172.000 Token, kann das sehr lange dauern. Auf dem MI355X dauerte ein solcher Cold-Prefill zunächst 51 Sekunden, während eine B300 die gleiche Aufgabe in 23 Sekunden erledigte. Ein kräftiger Unterschied. Doch auch hier war die Ursache ein Software-Problem: Das schnelle MLA-Prefill-Kernel von AITER wollte nicht geladen werden, weil die Anzahl der Attention-Heads pro Rang nicht ins Schema passte. Statt der erwarteten 4, 8 oder 16 Heads hatte das Modell bei Tensor Parallelism mit 8 GPUs nur 12 Heads pro Rang. Die Lösung: einfach auf 16 Heads mit Nullen auffüllen, den schnellen Kernel verwenden und die überflüssigen Heads wieder verwerfen. Ergebnis: Die Prefill-Geschwindigkeit stieg von etwa 4–7.000 auf 13.000 Token pro Sekunde. Das ist eine Verbesserung um das Zwei- bis Dreifache.

Diese Optimierungen mögen technisch klingen, aber sie haben eine unmittelbare Wirkung für alle, die KI nutzen. Denn die Zeit bis zum ersten Token – also die Wartezeit, bevor überhaupt ein Zeichen erscheint – ist das, was Anwender am deutlichsten spüren. Ein Modell, das aggregiert tausende Token pro Sekunde verarbeitet, nützt wenig, wenn der Nutzer eine halbe Minute auf den ersten Satz warten muss. Genau diese Verzögerung hat Wafer mit den Optimierungen behoben. Und das ist letztlich das eigentliche Kunststück: Nicht die Hardware allein macht den Unterschied, sondern die Fähigkeit, die vorhandene Software an die eigenwilligen Gegebenheiten anzupassen.

Warum das für die KI-Welt wichtig ist – auch für dich

Du fragst dich jetzt vielleicht: Was hat das alles mit mir zu tun? Nun, KI-Modelle wie Kimi K3 sind die Motoren hinter vielen Anwendungen, die wir täglich nutzen – von Chatbots über Code-Assistenten bis hin zu automatisierten Textsystemen. Wenn solche Modelle günstiger und schneller auf AMD-Hardware betrieben werden können, sinken die Kosten für die Anbieter. Und das spürst du im Preis, in der Antwortgeschwindigkeit und vielleicht auch in der Verbreitung von Open-Source-KI. Denn je günstiger die Inferenz wird, desto eher lassen sich große Modelle in viele Produkte integrieren.

Der Beitrag von Wafer endet mit einer provokanten Frage: Ist der CUDA-Moat tot? CUDA, die Programmierschnittstelle von NVIDIA, galt lange als uneinholbarer Vorteil – wie ein Burggraben, den niemand überqueren kann. AMD hat mit ROCm eine Alternative, aber sie war nie so ausgereift. Die Erfahrungen mit Kimi K3 zeigen jedoch, dass sich die Lücke schließt. Nicht von heute auf morgen, aber stetig. Und gerade bei Modellen, die so groß sind, dass sie nur mit viel Speicher laufen, hat AMD einen echten Trumpf in der Hand.

Man sollte allerdings nicht in Euphorie verfallen. Ein einzelner Benchmark beweist noch keinen Gesamtsieg. Es gibt sicherlich viele Workloads, bei denen NVIDIA weiterhin klar führt. Und die Software-Unterstützung für AMD wird noch eine Weile ein Flickenteppich bleiben. Doch die Richtung stimmt: Die KI-Welt wird vielseitiger, offener und preiswerter. Genau davon profitieren am Ende alle – auch die, die nie etwas von Tensor-Kernen oder Attention-Heads gehört haben. Für alle, die sich zum ersten Mal mit dem Thema beschäftigen: KI ist nicht nur eine Frage cleverer Algorithmen, sondern auch eine Frage des Speichers und der intelligenten Ausnutzung von Hardware. Dass ausgerechnet der Speicher zum entscheidenden Vorteil werden könnte, ist eine Erkenntnis, die noch vor ein paar Jahren kaum jemand erwartet hätte.

Für die Zukunft bedeutet das: Wir dürfen gespannt sein, wie sich die Wafer-Prognose bewahrheitet. SOTA – also der neueste Stand der Technik – auf AMD ist offenbar nicht mehr fern. Wer also in den nächsten Monaten eine KI-Anwendung entwickelt oder betreibt, sollte AMD nicht mehr länger ignorieren. Die Softwarelücken sind da, aber sie sind überwindbar. Und wenn der Preisvorteil so deutlich bleibt, wird sich der Markt in eine Richtung bewegen, die mehr Wettbewerb und mehr Innovation bedeutet. Genau das, so scheint es, ist der eigentliche Gewinn.

Quelle: wafer.ai