Agenten gegen CUDA: Schneller beim Einlesen, kaum schneller beim Antworten

Darum geht es

In dieser Woche haben zwei Unternehmen fast gleichzeitig dieselbe These aufgestellt. Anthropic erzählt Investoren, sein Modell Claude Mythos habe Claude in rund drei Tagen auf AMDs Rechenbeschleuniger MI355X gebracht. Früher habe das sechs bis zwölf Monate gedauert. AMD veröffentlicht ein Experiment, in dem KI-Agenten 51 aktuelle Hugging-Face-Modelle in wenigen Tagen auf den Notebook- und Mini-PC-Chip Strix Halo portiert haben. Die Ports sollen dabei schneller sein als llama.cpp, die verbreitetste Software für lokale Modelle. Die gemeinsame Botschaft: Wenn Agenten die Kernel schreiben, also die kleinen, hochoptimierten Rechenprogramme, die direkt auf dem Chip laufen, dann verliert Nvidias Software-Ökosystem CUDA seinen Wert als Burggraben.

Wir haben die Zahlen geprüft. Dabei ist eine Unterscheidung entscheidend, die in der Berichterstattung fast immer fehlt. Prefill heißt, das Modell liest den Prompt ein. Hier kann die Grafikkarte viele Token gleichzeitig verarbeiten, das Tempo hängt also an der Rechenleistung. Decode heißt, das Modell schreibt die Antwort Token für Token. Dafür müssen für jedes Token alle Gewichte einmal aus dem Speicher gelesen werden. Die Grenze setzt deshalb die Speicherbandbreite, also wie viele Daten pro Sekunde zwischen Speicher und Chip fließen. Das Decode-Tempo ist das, was Nutzer als „schnell“ oder „langsam“ erleben.

Was Anthropic tatsächlich behauptet

Im Roadshow-Video zum Börsengang sagt Compute-Chef Tom Brown laut einer Auswertung von CellCog bei etwa Minute 20:42, Claude sei „in nur drei Tagen mit praktisch keinem menschlichen Eingriff“ auf AMD gelaufen und habe „fast 100 Prozent der Kernel portiert oder geschrieben“. Die Fußnote auf der Folie ist enger gefasst:

„Die etwa dreitägige Zeitspanne entspricht ungefähr der Zeit, die Claude Mythos Preview brauchte, um die Prompt-Verarbeitung für ein Anthropic-Modell auf AMD-MI355X-GPUs auf ein brauchbares Leistungsniveau zu bringen.“

Gemeint ist also ein einziges Modell und nur das Prefill. Das Training kommt nicht vor, ebenso wenig Messwerte in Token pro Sekunde oder ein Vergleich mit Nvidia-Hardware. Die sechs bis zwölf Monate sind nach der Folie ein Erfahrungswert aus früheren Projekten, keine Vergleichsmessung. Laut CellCog und ExplainX tauchen „drei Tage“ und „MI355X“ im Prospekt selbst nicht auf. Wccftech hält es für „verfrüht“, CUDA für tot zu erklären, und verweist auf Bibliotheken, Werkzeuge und Kommunikationssoftware wie NCCL, die an Nvidias Verbindungstechnik NVLink gekoppelt ist.

Zum Hintergrund: Anthropic hängt an beiden Herstellern. Nvidia hat im November 2025 bis zu 10 Milliarden Dollar zugesagt, AMD im Juli 2026 bis zu 5 Milliarden. Unsere Einschätzung: Vor dem Börsengang hat Anthropic ein klares Interesse daran, sich als unabhängig von einem einzelnen Lieferanten darzustellen. Das macht die Aussage nicht falsch, aber sie bleibt eine Herstellerangabe ohne prüfbare Daten.

Das AMD-Experiment: offene Daten, kleine Widersprüche

Bei HRX Loom ist es anders, hier lässt sich fast alles nachprüfen. Loom ist eine Sprache samt Compiler von AMD, der Programme für CPUs, GPUs und NPUs erzeugt. Die Software befindet sich in einer frühen Testphase (Tech Preview, Version 0.1). Mit dem Skill-Paket loom-skills portieren Claude Code, Codex oder der Agent Pi ein Modell, messen es gegen llama.cpp, optimieren es und schreiben einen Bericht. Das Ergebnis liegt als 51 Modellpakete in der Organisation loom-fun auf Hugging Face, dazu kommt ein Dashboard. Gemessen wurde auf sechs Strix-Halo-Rechnern in AMDs DevLab und einem lokalen Gerät. Im Median arbeiteten 2 Unter-Agenten parallel, in der Spitze 16.

Schon bei den Eckdaten widersprechen sich die Quellen. Der Kopf des Dashboards spricht von „4 Tagen Arbeit“, die Methodik von „3 Tagen“ (6. bis 9. November). Hardware Busters nennt die AMD-Ingenieure Jeremy Fowers und Ben Vanik. Die offizielle Loom-Dokumentation schreibt dagegen, ein „Community-Mitwirkender“ habe die Modelle mit einem Claude-Abo an einem Wochenende portiert. Wie viel Menschen geprüft oder eingegriffen haben, steht nirgends.

Wir haben 14 Modellkarten nachgerechnet

Jede Karte enthält eine Datei info.json mit Messwerten gegen zwei llama.cpp-Varianten, eine für ROCm (AMDs Gegenstück zu CUDA) und eine für Vulkan. AMDs Schlagzeile vergleicht nur mit ROCm. Wir vergleichen beim Decode mit dem jeweils besseren Build. Das ist wichtig, weil der ROCm-Build bei langem Kontext stark einbricht. Ein unabhängiger Blog hat das auch auf Strix Halo gemessen: Bei Qwen3.6-35B-A3B fiel das Decode-Tempo mit ROCm bei 76.000 Token Kontext um 64 Prozent, mit Vulkan nur um 12 Prozent.

Eigene Berechnung aus den Modellkarten. Loom im Vergleich zum besseren llama.cpp-Build, beim Prefill zu ROCm. Laut AMD gelten Abweichungen bis ±3 % als Gleichstand.

Prefill: Hier ist der Vorsprung echt und deutlich. Im Median unserer Stichprobe liegt er bei etwa 1,6-fach, was gut zu AMDs Angabe von 1,5-fach für alle 51 Modelle passt. Trotzdem erreichen die Agenten-Kernel nur 18 bis 47 Prozent der Roofline, also der theoretischen Obergrenze der Hardware. Der Spielraum ist noch groß, und llama.cpp ist hier offenbar schwach optimiert.

Decode ohne Tricks: Bei den sieben Modellen ohne spekulatives Decoding liegt der Median beim Antworten mit kurzem Prompt bei +4 Prozent, bei 32.000 Token Kontext bei −1 Prozent. Das bedeutet praktisch Gleichstand. Das deckt sich mit AMDs eigener Planung: Im RFC für das HRX-Backend in llama.cpp erwartet AMD-Ingenieurin Stella Laurenzo „Gleichstand bis 15 % Zuwachs“ beim Decode ohne Multi-Token-Prediction, Phoronix berichtet von bis zu 10 Prozent. Der Grund ist Physik. Bei Qwen2.5-32B liegt Loom bei 104 Prozent der rechnerischen Bandbreitengrenze. Ist der Speicher der Engpass, kann ein besserer Kernel nichts mehr herausholen.

Decode mit Tricks: Die großen Sprünge gibt es nur mit spekulativem Decoding. Dabei rät ein kleiner Zusatzbaustein mehrere Token im Voraus, und das große Modell prüft sie in einem Durchgang. Die Karten sagen dazu selbst, dass der Vergleich nicht gleichwertig ist. Loom rät 1 bis 3 Token voraus, llama.cpp lief mit bis zu 15, was je nach Modell bremsen kann. Unabhängige Messungen zeigen, dass schon llama.cpp allein mit MTP viel herausholt. Laut sleepingrobots stieg Qwen3.8-27B (Q6_K, Vulkan) auf Strix Halo von 9,6 auf 18,0 Token pro Sekunde. In einem anderen Test brachten reine Kernel-Patches beim Decode nur +1 bis +8 Prozent, bei der Prompt-Verarbeitung aber deutlich mehr.

Dazu kommen methodische Schwächen, die die Karten offen nennen. Die Rechner wechselten zwischen den Sitzungen. Loom wurde vom Client gemessen, llama.cpp von seinem eigenen Server. Die Kontextgrößen unterschieden sich. Mehrere Werte liegen über der geschätzten Roofline.

Wie belastbar ist „korrekt“?

Alle 14 Karten bestehen die Tests „golden“ und „compare“. Dabei werden Token und Wahrscheinlichkeiten mit llama.cpp auf derselben GGUF-Datei verglichen. Der Maßstab ist also llama.cpp selbst und keine unabhängige Referenz mit voller Genauigkeit. Der Bastler-Port inferzero für Intel-iGPUs macht das strenger: Er vergleicht mit einer CPU-Implementierung in 32-Bit-Genauigkeit über die KL-Divergenz, ein Maß für die Abweichung der Wahrscheinlichkeiten. Der Test mit vollem Kontext (needle_full) wurde bei 12 der 14 Karten für das aktuelle Paket nicht wiederholt. Bestanden hatten ihn frühere Builds. Qwen3.8 Flash Next braucht einen Entwicklungs-Build, dessen Installationsanleitung am 22. November abläuft.

Die Forschung mahnt allgemein zur Vorsicht. Im Paper KernelBench-Verified kommt das beste Modell, GPT-5.5, bei strenger Prüfung gegen PyTorch nur auf das 0,88-Fache der Geschwindigkeit. Mit den üblichen Prüfregeln waren es noch 1,43. SpecBench findet bei 73,8 Prozent der KernelBench-Auswertungen scheinbare Gewinne ohne echte Verbesserung. Das ist Reward Hacking: Ein Agent trickst den Test aus, statt die Aufgabe zu lösen. Ein Beispiel ist ein ReLU-Kernel, der nur die Testgröße erkennt und eine 374-fache Beschleunigung meldet. AMDs Datensatz-Paper AMDKernelVault meldet für sein trainiertes Qwen3-8B 34 Prozent korrekte HIP-Kernel im ersten Versuch. Auf Intel-GPUs erreicht Xe-Forge im Mittel das 1,17-Fache über PyTorch eager.

Die anderen Fronten

Beim SGLang-Konsortium vom 12. November sitzen Nvidia, AMD, Intel, Google, Meta, Cloudflare, Modal und RadixArk an einem Tisch. Technische Entscheidungen treffen aber weiter die SGLang-Maintainer. Nvidia ist keineswegs Verlierer. Nvidias Manager Ian Buck sagt, bessere Software helfe Entwicklern, „mehr Leistung aus Nvidia-Rechenkapazität“ zu holen. Intel hat parallel eine Zusammenarbeit mit RadixArk angekündigt, um SGLang für Intel-Hardware zu optimieren.

Google meldet aus seinem Agentensystem /teamwork 4,09-fache Beschleunigung über 17 Referenz-Kernel für TPUs und 2,99-fache bei 7 handoptimierten vLLM-Kernels. Die vielzitierten „Rust-Kernel“ sind dagegen etwas anderes: 800.000 Zeilen Rust für den Betriebssystem-Mikrokern Zircon und ein Rust-Port des AV1-Decoders libgav1, der am Ende schneller war als das C++-Original. Mit GPUs hat das nichts zu tun.

Wo CUDA noch hält

SemiAnalysis hat im August mit dem Benchmark AgentX echte Agenten-Workloads mit bis zu einer Million Token Kontext gemessen. Bei Qwen3.5 auf SGLang lag Nvidia dort um mehr als das 20-Fache vorn. Context-Parallel-Attention, also das Verteilen sehr langer Kontexte auf viele GPUs, ist in vLLM für AMD nicht unterstützt. Dazu kommen Training, Kommunikation über viele Chips (NCCL), ausgereifte Bibliotheken wie cuDNN und der Betrieb im Großmaßstab. In keiner der Meldungen dieser Woche kommt einer dieser Punkte vor.

Einordnung

Unsere Einschätzung: Billig portierbar ist heute die Inferenz einzelner Modelle auf einem einzelnen Chip, vor allem das Prefill. Dort ist llama.cpp auf AMD offenbar schwach, und dort bringen Agenten nachweislich viel. Das ist für Strix-Halo-Besitzer eine gute Nachricht, denn lange Dokumente und Agenten-Sitzungen werden spürbar schneller verarbeitet. Beim Schreiben der Antwort setzt die Speicherbandbreite die Grenze, und daran ändern auch geschickte Kernel kaum etwas. Größere Gewinne kommen dort vom spekulativen Decoding, und das beherrscht llama.cpp auch.

Anthropics „drei Tage“ sind nach der eigenen Fußnote ein Prefill-Ergebnis für ein Modell, ohne veröffentlichte Daten. Der CUDA-Burggraben wird flacher, wo die Arbeit klar abgegrenzt ist und sich automatisch prüfen lässt. Bei Training, Multi-GPU-Betrieb und Zuverlässigkeit im Großmaßstab steht er noch. Offen ist vor allem, wer die Agenten-Kernel langfristig pflegt und wie man Reward Hacking in Produktivsystemen verlässlich ausschließt.