Kategorie: Tool-Tests

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

Liest du einen Blogbeitrag, eine Produktbeschreibung oder eine Nachricht, fragst du dich vielleicht: War da ein Mensch am Werk oder eine KI? Die Unsicherheit ist allgegenwärtig. ChatGPT, Claude und Co. schreiben Texte, die schwer zu erkennen sind, vor allem wenn sie nachbearbeitet wurden. Pangram hat sich genau darauf spezialisiert. Jetzt erscheint die vierte Generation seines KI-Detektors. Sie soll einiges besser machen.

Wer im Bereich KI-Erkennung arbeitet, kennt das Problem. Pangram-Modelle sollen herausfinden, ob ein Text von einer Maschine stammt. Bei rein generierten Texten funktioniert das inzwischen gut. Schwierig wird es, wenn Menschen KI-Inhalte umschreiben oder Teile selbst verfassen. Daran scheitern viele Detektoren. Pangram 4 soll diese Lücke schließen. Die Entwickler bezeichnen das Modell als das leistungsfähigste und genaueste, das sie je gebaut haben. Es ist sechsmal größer als der Vorgänger und erkennt menschlich überarbeitete KI-Texte deutlich besser.

Ein zentraler Fortschritt betrifft die Humanizer-Erkennung. Humanizer sind Tools, die KI-Text so umformulieren, dass er natürlicher wirkt. Für alle, die KI-Inhalte zuverlässig identifizieren wollen, sind sie ein Ärgernis. Pangram 4 erkennt in 98,83 Prozent der Fälle, dass in humanisierten Ausgaben KI steckt. Das ist ein beachtlicher Wert. Die Tester haben dreizehn gängige kommerzielle Humanizer geprüft. Der Detektor lässt sich also nicht so leicht austricksen. Auch gegen adversarial prompts ist er robust – also gegen Versuche, die Erkennung mit geschickten Formulierungen zu umgehen.

Pangram 4 ist nach Angaben der Entwickler das erste KI-Erkennungsmodell, das in einem einzigen Durchlauf unterscheidet, ob ein Text vollständig von einer KI stammt, nur von einer KI bearbeitet wurde oder eine Mischung aus menschlichen und KI-Anteilen enthält. Bisher waren dafür separate Modelle oder mehrstufige Verfahren nötig. Ein einzelner Durchlauf spart Zeit und reduziert Fehler. Besonders bei langen Dokumenten, in denen Menschen einzelne Absätze von einer KI schreiben lassen.

Zur Bewertung der Genauigkeit dienen zwei Kennzahlen: die False Positive Rate und die False Negative Rate. Die False Positive Rate zeigt, wie oft ein menschlicher Text fälschlich als KI-Text markiert wird. Pangram nennt hier 0,0041 Prozent. Von 24.000 Dokumenten wird also ungefähr eines falsch eingestuft. Die False Negative Rate gibt an, wie viele KI-Texte übersehen werden. Beim Vorgänger lag sie bei 1,99 Prozent, bei Pangram 4 bei 0,3396 Prozent. Das ist eine Verbesserung um knapp den Faktor sechs. Wer einen KI-Text unter dem Radar durchschmuggeln will, hat es deutlich schwerer.

Ein weiterer Punkt ist die Generalisierung. Ein gutes Detektionsmodell erkennt nicht nur die KI-Modelle, auf denen es trainiert wurde, sondern auch neue, unbekannte. Pangram 4 zeigt keine signifikante Korrelation zwischen dem Erscheinungsdatum eines Modells und seiner Erkennbarkeit. Alle getesteten Modelle werden mit einer False Negative Rate unter 0,7 Prozent erkannt. Ob älteres oder neuestes Modell – die Erkennung schlägt zuverlässig an. Das ist wichtig, denn ständig kommen neue KI-Modelle auf den Markt.

Und was kostet der Spaß? Pangram hat die Preisstruktur überarbeitet. Bisher wurde ein Scan pro 1.000 Wörter verrechnet, künftig pro 100 Wörter. Das klingt nach mehr Kosten, ist aber für kurze Dokumente günstiger. Ein Scan über 500 Wörter kostet jetzt fünf Credits, vorher zahlte man einen vollen Scan für 1.000 Wörter. Für sehr lange Dokumente wird es teurer. Die API-Preise ändern sich laut Unternehmensangaben auf 0,05 Dollar pro 100 Wörter. Für kurze Texte bedeutet das eine Preisänderung um das Ein- bis Zweifache, für lange Dokumente bis zum Zehnfachen.

Neu sind Bildscans. Jeder Plan enthält künftig eine bestimmte Anzahl davon, ohne dass der Preis steigt. Grund ist die zunehmende Verbreitung KI-generierter Bilder. Auch die monatlichen Kontingente wurden angepasst. Der Individual-Plan erlaubt 300.000 Wörter pro Monat plus 100 Bildscans, der Pro-Plan 1,5 Millionen Wörter und 500 Bildscans. Wer bisher mit 600 Scans zu je 1.000 Wörtern hantierte, hat nun mehr Flexibilität.

Ein Hinweis für alle, die Pangram nutzen: Die dritte Version bleibt noch zwei Monate aktiv, die Abschaltung ist für den 30. September 2026 geplant. Anfragen ohne explizite Modellangabe laufen weiterhin an Pangram 3, mit dem alten Abrechnungssystem. Bestandskunden haben so Zeit, sich umzustellen. Wer sofort mit Pangram 4 arbeiten will, wählt das Modell in den Einstellungen oder konfiguriert die API entsprechend.

Wie alle KI-Detektoren hat auch Pangram Einschränkungen. Das Unternehmen verweist auf technische Details und den Modellkatalog. Jeder, der mit solchen Systemen arbeitet, weiß: hundertprozentige Sicherheit gibt es nicht. Kurze Texte, stark umgangssprachliche Inhalte oder viele Zitate können Probleme bereiten. Pangram 4 arbeitet jedoch deutlich zuverlässiger. Die Kombination aus niedrigen False-Positive-Raten und robuster Erkennung bei humanisierten Texten macht das Tool im Alltag brauchbar.

Wenn du ein Tool brauchst, das zuverlässig zwischen menschlicher und KI-Autorschaft unterscheidet, schau dir Pangram 4 an. Es ist teurer für lange Dokumente, dafür präziser und erkennt auch knifflige Fälle. Die Bildscans sind ein Bonus, der den Preis teilweise aufwiegt. Die klare Abschaltungsansage für Pangram 3 gibt Planungssicherheit. Kein Detektor ist perfekt. Die Zahlen des Unternehmens klingen vielversprechend, die Praxis muss es zeigen.

Quelle: pangram.com

Stell dir vor, du arbeitest an einer Anwendung, die plötzlich mit einem Large Language Model (LLM) erweitert werden soll. Dein Team implementiert eine Chat-Funktion auf GPT-Basis oder eine Suchfunktion mit semantischem Textverständnis. Die ersten Prototypen laufen im Labor. Kaum ist die Funktion in Produktion, stolpert ihr über unerklärliche Latenzen, halluzinierende Antworten oder explodierende API-Kosten. Dieses Szenario kennen viele Entwicklungsteams. Datadog hat ein spezielles Paket geschnürt: das „Developer Toolkit for the AI Era“. Es bietet einen Fahrplan, um KI-Features von der ersten Codezeile bis zur stabilen Auslieferung zu begleiten.

Wir schauen uns an, was in diesem Toolkit steckt und warum es mehr ist als eine Sammlung von PDFs. Datadog adressiert ein grundlegendes Problem: Klassische DevOps-Werkzeuge sind nicht für die Besonderheiten von KI-Modellen ausgelegt. Ein Sprachmodell ist kein normaler Service – es verhält sich probabilistisch, seine Leistung hängt vom Prompt-Design ab, die Kosten pro Aufruf sind oft nichtlinear. Hier setzt das Toolkit an.

Warum ein eigenes Toolkit für KI?

Datadog argumentiert: Entwickler, die KI-Funktionen bauen, müssen zwei Welten verbinden – traditionelle Softwareentwicklung (Code, Tests, Deployment-Pipelines) und die Welt der KI-Modelle (Prompt Engineering, Token-Limits, Fine-Tuning). Bisher gab es kein integriertes Werkzeug, das beide Seiten abdeckt. Das Toolkit soll diese Lücke schließen, indem es CI/CD-Pipelines, Testoptimierung, Feature Flags und Observability in einen gemeinsamen Kontext stellt. Es geht nicht um eine weitere Plattform, sondern um Best Practices und konkrete Tools, die auf Datadogs bestehendem Produktportfolio aufsetzen.

Stell dir vor, du bist Bauleiter für ein Hochhaus. Bisher konntest du Statik und Baufortschritt nur getrennt überwachen. Das Toolkit gibt dir einen Bauplan und eine gemeinsame Echtzeit-Ansicht für beides – du siehst, wie sich jede Änderung am Stahlträger auf die Betonarbeiten auswirkt. Genauso hilft Datadog dabei, den Zusammenhang zwischen Code-Änderungen, Tests, Freischaltung neuer Funktionen und dem Live-Verhalten der KI-Modelle zu erkennen.

Die drei Säulen des Toolkits

Das Developer Toolkit für das KI-Zeitalter besteht aus drei zentralen Ressourcen, die Datadog auf einer Landingpage zum Download anbietet. Sie decken den gesamten Lebenszyklus einer KI-Funktion ab.

1. Product Briefs: CI Pipeline Visibility und Test Optimization

Der erste Baustein sind Product Briefs – kurze fachliche Übersichten. Sie zeigen, wie CI Pipeline Visibility und Test Optimization funktionieren. Datadog erklärt, wie Teams End-to-End-Auslieferungsmetriken erhalten und sauberere, schnellere Pipelines aufbauen. Konkret geht es darum, Engpässe in der Build- und Testphase zu identifizieren, die bei KI-Projekten auftreten: Lange Modell-Downloads, ressourcenintensive Benchmarks oder Training kleinerer Modelle in CI-Runnern. Pipeline-Visibility lokalisiert diese Flaschenhälse, die Testoptimierung priorisiert genau die Tests, die für die aktuelle Codeänderung relevant sind – statt den gesamten Regressionssatz durchlaufen zu lassen. Das spart Zeit und Geld, besonders da KI-Modelle oft nur auf bestimmten Hardware-Typen laufen.

2. eBook: LLM-Anwendungen, Agents und Retrieval Pipelines beobachten

Das zweite Element ist ein eBook zur Observability von KI-Anwendungen. Es befasst sich mit der Überwachung von LLM-Anwendungen, Agents und RAG-Pipelines – Systemen, die Wissen aus einer Datenbank abrufen, um die Antworten eines Sprachmodells zu verbessern. Entwickler müssen verstehen, wie sich ein Modell im produktiven Betrieb verhält: Wie oft antwortet es mit Halluzinationen? Wie lange dauert ein durchschnittlicher LLM-Aufruf? Wie viele Tokens werden verbraucht? Observability für KI bedeutet, Metriken und Logs nicht nur aus der Infrastruktur zu sammeln, sondern auch aus Prompt-Output, Modell-Latenz und Kostenabrechnungen großer API-Anbieter wie OpenAI oder Anthropic. Das eBook zeigt, wie man diese Daten mit Datadog strukturiert erhebt und alarmiert.

3. On-Demand Webinar: Best Practices für Software Delivery im KI-Zeitalter

Der dritte Bestandteil ist ein aufgezeichnetes Webinar zur modernen Softwareauslieferung unter KI-Bedingungen. CI-Pipeline und Feature-Flag-Management dürfen nicht zum Flaschenhals werden. Feature Flags sind besonders wichtig: Sie erlauben, eine KI-Funktion nur für eine Teilmenge der Nutzer freizuschalten, etwa um die Antwortqualität eines neuen Modells gegen das alte zu testen (A/B-Testing). Im Webinar wird erklärt, wie man CI Visibility, Test Optimization und Feature Flags kombiniert. Ein zentraler Punkt: KI-Funktionen lassen sich nicht wie normale Code-Änderungen testen. Null- und Schwellwerttests sind oft ungeeignet, weil das Modell keine deterministischen Ergebnisse liefert. Man braucht Metriken wie „Antwort akzeptiert“ oder „durchschnittliche Bewertung der Nutzer“. Die Kombination aus schnellen Tests und graduellem Rollout mit Feature Flags minimiert Risiken.

Was das Toolkit konkret enthält (und was nicht)

Wer das Toolkit herunterlädt, erhält die drei Ressourcen nach dem Ausfüllen eines Formulars. Es handelt sich um Wissen und Leitfäden, die auf Datadogs Produkten basieren, nicht um Software. Wer bereits Kunde ist, kann die beschriebenen Funktionen – CI Pipeline Visibility, Test Optimization, Feature Flags, AI Impact, GPU Monitoring etc. – direkt in der Plattform nutzen. Das Toolkit zeigt, wie man sie gezielt für KI-Workloads konfiguriert. Für Neueinsteiger dient es als Einstiegspunkt, um zu verstehen, welche Observability und Steuerung für KI-Anwendungen nötig sind. Es ist kein Allheilmittel, aber eine Roadmap für Teams, die ihren KI-Entwicklungsprozess professionalisieren wollen.

Datadog hat in den letzten Jahren viele KI-spezifische Features eingebaut, etwa GPU-Monitoring und AI Impact, das die Nutzung von KI-Coding-Assistenten wie Cursor oder GitHub Copilot mit den Auslieferungskennzahlen des Teams verknüpft. Das Toolkit bündelt dieses Wissen, sodass Entwickler nicht jede Funktion einzeln erkunden müssen. Es ist ein Kurzstudium in „KI im Produktionsbetrieb“.

Fazit: Ein pragmatischer Baukasten für eine neue Herausforderung

Datadogs Developer Toolkit for the AI Era ist mehr als die Summe seiner Teile. Es adressiert ein echtes Problem: Die Einführung von KI in Softwareprojekte scheitert oft an fehlenden Werkzeugen, um Qualität, Kosten und Sicherheit zu managen. Die drei Ressourcen – Product Briefs, eBook, Webinar – liefern eine solide Basis, um die Lücke zwischen Code und Modellverhalten zu schließen. Sie richten sich an Entwickler, DevOps-Ingenieure und Teamleads, die nicht nur „irgendwie KI“ einbauen, sondern nachhaltig und zuverlässig liefern müssen.

Wertvoll ist die Kombination aus schnelleren, sauberen Pipelines und kontrollierter Feature-Freigabe mit Echtzeit-Observability der KI-Outputs. Wer das umsetzt, kann Fehler früh erkennen, Risiken isolieren und die Leistung seiner KI-Funktionen messbar verbessern. Das ist keine Werbung – das ist harte Software-Engineering-Arbeit, für die Datadog einen handlungsorientierten Leitfaden anbietet. Wenn du mit KI-Features in Produktion kämpfst, lohnt ein Blick auf dieses Toolkit. Es ersetzt nicht die eigene Experimentierfreude, aber es kann verhindern, dass du die gleichen Fehler zweimal machst.

Quelle: datadoghq.com