Z.ai hat vor kurzem GLM 5.2 herausgebracht. Vielleicht sagen Sie nun, ach, schon wieder so ein Open-Source-Modell, die sind doch Monate hinter OpenAI und Anthropic. Aber diesmal liegen die Dinge anders. GLM 5.2 ist auf Augenhöhe mit Opus 4.8 und besser als GPT 5.5. Ich habe sogar One-Shot-Demos gesehen, da hat GLM 5.2 besser abgeschnitten als Opus 4.8. Das ist, soweit ich weiß, das erste Open-Source-Modell, das die Marktführer eingeholt hat. Selbst getestet, mit einer guten Harness, wie Goose, Cline, opencode oder Hermes Agent vermisst man nichts mehr. Und während die Kosten bei OpenAI und Anthropic dermaßen explodiert sind, dass sogar Weltkonzerne beginnen müssen, die Token-Usage ihrer Mitarbeiter zu beschränken, kostet GLM 5.2 nur einen Bruchteil. Das ist nicht nur eine Randnotiz für Tech-Nerds. Das könnte eine Finanzkrise von riesigen Ausmaßen lostreten.
Elon Musks Raketenkonzern kauft Cursor für 60 Milliarden Dollar – und viele fragen sich: warum? Wer die Antwort versteht, begreift auch, warum Grok trotz sehr guter Qualität bisher kaum eine Rolle spielt. Und warum sich das jetzt sehr schnell ändern kann. Es gibt dabei aber noch eine zweite Antwort – und die ist deutlich ungemütlicher für Musks Wettbewerber.
Es ist immer wieder überraschend, gleichartige Aufgaben kosten bei Anthropic das Drei- oder Vierfache als bei OpenAI, obwohl doch beide als SOTA-Anbieter Premium-Preise für die Input- und Output-Token in ähnlicher Region verlangen. Ich hab mir schon oft den Kopf darüber zerbrochen. Sogar Betrug habe ich schon vermutet, aber wenn man die Anzahl der verrechneten Tokens ansieht, wie man sie in den Rückgabe-Daten auswerten kann, dann scheint das schon seine Richtigkeit zu haben. Aber jetzt meine ich, einen wesentlichen Teil der Erklärung gefunden zu haben.
Letzten Dienstag kam Fable 5 von Anthropic heraus. Laut Anthropic ein für den allgemeinen Zugriff adaptiertes Mythos, das man sicher gestaltet habe. Mythos, Sie erinnern sich, ist das Modell, das angeblich so gefährlich sei, dass man es nur einem streng selektierten Nutzerkreis geben könne. Das „Vergnügen“ (dazu gleich mehr) währte jedoch nur bis Freitag, als Anthropic von der US-Regierung die Exportkontroll-Auflage erhielt, Fable 5 nur US-Bürgern zugänglich zu machen. Anthropic wiederum nahm daraufhin Fable 5 völlig und für alle aus dem Zugriff, weil man sich nicht in der Lage sah, die Nationalität der Nutzer zu bestimmen. US-Regierung und Anthropic versuchen nun, dem jeweils anderen den schwarzen Peter in die Schuhe zu schieben, und die Gerüchteküche läuft heiß. Hat die Entwicklung von KI nun einen kritischen Punkt erreicht, ist es inzwischen tatsächlich zu gefährlich, diese Modelle in den breiten Zugriff zu geben? Oder ist das Teil eines viel größeren Trends, nämlich dem, dass die Allgemeinheit von der technologischen Entwicklung abgekoppelt werden soll?
Pluralis Research baut ein öffentliches Pretraining-System. Damit lassen sich KI-Modelle verteilt auf vielen Rechnern trainieren. Pluralis will damit den unseligen Trend zur Konzentration auf immer größere Rechenzentren brechen, und das Training von KI-Modellen in den Public Domain bringen. Am 11. März sagte Sam Altman, CEO von OpenAI, beim BlackRock Infrastructure Summit „We see a future where intelligence is a utility, like electricity or water, and people buy it from us on a meter.“ Altman möchte also einen Zähler an Intelligenz machen — und sie dann verkaufen. Die Frage, wessen Intelligenz das eigentlich ist, stellt er sich dabei offenbar nicht. Die Konsequenzen sind längst spürbar: Künstler, Journalisten, Autoren, Open-Source-Entwickler — sie alle merken, dass ihre Arbeit in diese Modelle eingeflossen ist, ohne dass sie gefragt oder bezahlt wurden. Einige gehen daran pleite. Und nun soll man für das Ergebnis zahlen?
Das ist ja eines dieser Dinge, die einen zum Verzweifeln bringen können. Unternehmen wie Anthropic, OpenAI, DeepSeek, Z.AI, und so weiter, grasen das gesamte Internet ab und bringen das Wissen der Menschheit in ihre Modelle. Für lau versteht sich. Foren, Beiträge, Bücher, Videos, alles wird abgegriffen, und nichts wird für diese Intelligenzleistungen der Menschheit bezahlt. Und dann will man es den Menschen zurückverkaufen.
Pluralis Research will ein Gegengewicht schaffen. Wer Rechenkapazität übrig hat, kann sie dem Projekt zur Verfügung stellen, und dann wird der eigene Rechner als Trainingseinheit für ein KI-Modell genutzt. Man trainiert bereits das erste Modell, Pluralis-8B, ein 8-Milliarden-Parameter-Modell. Hardware-Einstieg ist bereits mit einer Consumer-GPU, 24 GB VRAM reicht schon.
Das zugrunde liegende Konzept heißt bei Pluralis „Protocol Learning“ — die Idee, Foundation-Modelle dezentral und kollektiv zu trainieren, ohne zentrale Kontrolle. Pluralis hat auch kürzlich eine Seed-Runde abgeschlossen, Lead-Investoren sind USV und CoinFund, sowie Variant, Topology und andere mehr – insgesamt 12 Investoren. Dabei konnten 7,6 Millionen US$ eingeworben werden.
Falls Sie nun beim Training mitmachen möchten: Zwar ist die Anforderung an die GPU moderat, die sonstigen Anforderungen sind jedoch sehr hoch. Standort Nordamerika, extrem schneller Internet-Anschluss mit superkurzem Ping — die Liste ist lang. Für die breite Öffentlichkeit ist das also noch nichts.
Dennoch, das kann ja durchaus noch werden, sprich, niedrigere Eintrittsbarrieren ermöglichen, wenn das Konzept aufgeht. Es erinnert mich an SETI@home von der UC Berkeley. Das Projekt lief von 1999 bis 2020, jeder konnte mitmachen, und bekam dann Datenpakete, in denen sein Rechner nach außerirdischen Signalen suchte. 12 Milliarden Signale wurden in diesem Ansatz mit Distributed Computing untersucht, und 100 Kandidaten wurden gefunden. Warum sollte das mit KI-Training nicht ebenfalls möglich sein? Ich finde es jedenfalls einen unerträglichen Gedanken, der Menschheit wird alles geklaut, und dann kommt es unter den exklusiven Zugriff einiger weniger – die daran nicht nur fürstlich verdienen wollen, sondern den Zugriff erfahrungsgemäß auch nach gusto einschränken werden.
Vor nicht allzu langer Zeit war Cursor so etwas wie die unbestrittene Referenz im Bereich KI-gestützter Entwicklungsumgebungen. Der KI-Editor hatte einen Vorsprung, den die Konkurrenz erst mal aufholen musste – aber das ist ihr in beeindruckendem Tempo gelungen. GitHub Copilot, Windsurf, Zed, Cline, Goose, Codex, Claude Code, opencode und eine wachsende Zahl weiterer Tools haben den Markt in kurzer Zeit massiv belebt. Der Druck auf Cursor ist real. Mit Composer 2.5 gibt Cursor jetzt eine klare Antwort – und sie hat zwei Dimensionen, die es wert sind, näher betrachtet zu werden.
Alle KI-Modelle rechnen über Token ab. Es gibt dabei Input-Token, Output-Token und Cached-Token. Cached-Token kosten sehr wenig. Cached-Token werden eine gewisse Zeit im Cache des Anbieters gehalten, und wenn sie noch von dort abrufbar sind, wird nur ein kleiner Preis berechnet. Input-Token sind pro Einheit günstig, aber da ihr Volumen deutlich höher liegt, machen sie trotzdem den Löwenanteil der Kosten aus. Die teuersten Token sind die für den Output, aber davon gibt es deutlich weniger als Input-Token. Ist man eigentlich auf Gedeih und Verderb darauf angewiesen, den LLM-Betreibern zu vertrauen, dass die das schon richtig abrechnen werden? Und könnte man vielleicht etwas an Arbeitsweise oder Prompt-Stil verbessern, um kosteneffizienter zu arbeiten?
Es ist dabei unerheblich, ob Sie via API-Key oder pauschal abrechnen mit Abo-Plänen. Bei den Abo-Plänen haben Sie Usage Limits (z.B. pro Stunde, pro Woche), wenn Sie zuviele Token verbrauchen, wird der Zugriff gesperrt, bis Sie wieder unterhalb des Limits sind. Das Ganze ist eine Blackbox, und man kann sich schon fragen, was wird da eigentlich warum abgerechnet. Und wenn man mitten im Projekt in eine Abo-Sperre bis zum Ende der Woche gerät, können einem die Termine um die Ohren fliegen. Oder man ruiniert sich, weil eine absurd hohe Rechnung für den API-Verbrauch ins Haus flattert.
Railway ist ein Cloud-Anbieter. In etwa so wie AWS, aber stark vereinfacht. Railway steht im Ruf, „freundlicher“ zu sein als AWS, es will ein einfacheres Interface anbieten. Es ist bei Startups und Entwicklern, die schnell prototypen wollen, sehr beliebt. Railway hat ein extrem direktes Deployment, man verbindet einfach nur die GitHub-Repo und es kümmert sich automatisch um Server, Datenbanken, Umgebungsvariablen und SSL-Zertifikate. Allerdings scheint Railway Sicherheit und Isolation zugunsten von Einfachheit zu opfern. Außerdem bewirbt Railway offensiv den Einsatz von KI-Agenten. Und so kam es, in einer lehrreichen Verkettung von Fehlern, für PocketOS zur Katastrophe.
PocketOS ist ein SaaS für Autovermietungen. Das Team dort nutzt Cursor mit Claude Opus 4.6. Der Agent war für eine Routineaufgabe im Staging unterwegs, stieß auf eine Inkonsistenz, und löschte dann mal eben in 9 Sekunden nicht nur die Produktionsdatenbank, sondern auch alle Volume-Level-Backups. Ohne Rückfrage, und obwohl destruktive Aktionen ihm explizit verboten waren. Tja, und das letzte verfügbare Backup bei PocketOS ist drei Monate alt. Und jetzt ist der gesamte Betrieb damit beschäftigt, aus Stripe-Zahlungshistorien, Kalendereinträgen und E-Mail-Bestätigungen die Buchungen der Kunden zu rekonstruieren.
Da kam also alles zusammen. Ein drei Monate altes Backup? Wir haben tägliche Backups, und einmal pro Woche wird auf eine externe Sicherung ausgelagert, die zudem ein Mehrgenerationenverfahren ist. Aber man kann PocketOS schon zugutehalten, dass sie sich auf die Backup-Strategie von Railway verlassen haben und das meiner Meinung auch durften. Ist schließlich ein beworbenes und bezahltes Feature, nur eben leider nachlässig umgesetzt. Und eine Änderung im Staging, die Live mit in den Abgrund reißt, sollte auch nicht passieren dürfen. Jer Crane, der CEO von PocketOS, gibt deshalb hauptsächlich Railway die Schuld.
Aber was sich der Agent geleistet hat, ist auch nicht ohne. Crane fragte Cursor bzw. Opus im Nachhinein, warum es das getan hat. Die Antwort klingt wie ein exzessiver Fehlerbericht eines übermotivierten Praktikanten, der es besser wissen müsste:
„NEVER F**KING GUESS! – and that’s exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify. I didn’t check if the volume ID was shared across environments. […] I decided to do it on my own to ‚fix‘ the credential mismatch, when I should have asked you first.“
Der Agent gab also offen zu: Er hat geraten statt zu prüfen, eine destruktive Aktion ohne Aufforderung oder Bestätigung ausgeführt, und die Dokumentation nicht gelesen. Das scheint mir eben dieses Problem zu sein: Wenn der Kontext einer Anfrage sehr groß wird, ist es nicht mehr sicher einzuschätzen, welche Teile des Kontexts wie gewichtet werden. Und auch ein Systemprompt, so streng er auch formuliert sein mag, ist eben nur ein Teil des Kontexts.
Es ist ein schwieriger Balanceakt: Große Prompts erhöhen die Fehler- bzw. Halluzinationswahrscheinlichkeit, aber sie erbringen im Allgemeinen bessere Ergebnisse und sind im Tokenverbrauch oft günstiger als die Summe vieler kleiner Einzelschritte. Dennoch, in Anbetracht der Gefahren, ist ein graduelles und kleinteiliges Vorgehen nach unserer Erfahrung meist besser.
DeepSeek V4 ist am 24. April in zwei Versionen „Pro“ und „Flash“ erschienen, und wie versprochen ist es Open Source. Die Qualität ist sehr gut, und die Preise bemerkenswert niedrig. Läutet schon das Totenglöcklein für OpenAI und Anthropic?
Mehrere Coding-Spezialisten haben das neue Modell von DeepSeek schon unter die Lupe genommen, und deren Urteil ist einhellig: GPT 5.5 von OpenAI hat derzeit die Krone im Coding inne, es folgt Opus 4.7 von Anthropic, dann DeepSeek mit V4, dann Kimi mit K2.6.
Das könnte Open Source-Fans enttäuschen, aber man muss das in Relation setzen. DeepSeek ist nur noch ca. 3 Monate zurück, und es kostet nur einen Bruchteil. OpenAI hat ja mal eben die Token-Preise für GPT 5.5 verdoppelt, und Anthropic, das sowieso schon ein Token-Burner immer war, braucht für Opus 4.7 35% noch mehr Token gegenüber dem bisher schon heftigen Tokenverbrauch.
Und es ist außerdem ja so, nicht jedes Problem ist in der schwierigsten Liga. Anders gesagt: Da DeepSeek nun so weit aufgeholt hat, ist die Anzahl der Probleme, an denen es scheitert, viel kleiner geworden.
Die Foren sind voll von Beschwerden über Anthropic Claude Opus 4.7. Es sei ein Rückschritt gegenüber 4.6, meinen viele, und nicht wenige sagen sogar, Opus 4.5 sei das letzte für den Arbeitseinsatz verlässliche Modell gewesen. Auch für OpenAI ChatGPT 5.4 heißt es, es sei im Coding ein Rückschritt zu 5.3-codex. (Es gibt kein 5.4-codex, es gab ein 5.3 „general purpose“ und ein 5.3-codex für Programmierarbeiten, aber für 5.4 gibt es nur dieses Modell, und das soll angeblich auch für Coding bereits optimiert sein, so dass es keine Extra-Coding-Version benötigt). Ist die Grenze von LLM bereits in Sicht, und alles Gebastel führt nur noch dazu, dass sich die Modelle beginnen, in der eigenen Komplexität zu verheddern?
Hinzu kommt die immer auffälliger werdende Arbeitsverweigerung. Wir hatten dazu kürzlich hier im Blog schon einen Artikel, mittlerweile ist es mir aber auch selbst passiert. Ich schrieb einen wirklich unschuldigen und völlig legitimen Web-Scraper, und mit einem mal meinte Codex, nun könne es mir nicht mehr helfen, es würde vermuten, das sei illegal, was ich da täte. Und alles Zureden und Erklären nützte rein gar nichts – wenn sich eine Maschine mal in so einem Loop festgebissen hat, dann war es das eben.
Lexer-Lux schreibt auf Twitter/X, dass er ein Plugin für ein Spiel seit Jahren mit Claude Opus programmiert hat. Nun kommt Opus 4.7 heraus und weigert sich, das Projekt weiter zu entwickeln. Wegen Sicherheitsbedenken, das Plugin sei ein Hack, behauptet Claude. Auf Rückfrage gibt Claude dann sogar zu, dass es gar kein Hack, sondern gutartig ist, weigert sich aber trotzdem, weiterzuarbeiten. An seinem eigenen Code! Weil Security!
Das beliebte Python-Paket LiteLLM, das als einheitlicher Proxy für über 100 verschiedene KI-Modelle (darunter OpenAI, Azure, Anthropic und viele weitere) dient und monatlich millionenfach von PyPI heruntergeladen wird, wurde Opfer eines schwerwiegenden Supply-Chain-Angriffs. Die Angreifergruppe „TeamPCP“ kompromittierte mindestens zwei Versionen des Pakets (1.82.7 und 1.82.8) und injizierte Schadcode, der beim Installieren automatisch eine Remote-Backdoor auf den betroffenen Systemen einrichtete. Konkret wurde im Post-Install-Skript ein Befehl versteckt, der über eine Google Cloud-Adresse ein Shell-Skript nachlud und einen Hintergrundprozess startete, welcher den Angreifern persistenten Zugriff auf die kompromittierten Server ermöglichte. Die schadhaften Versionen waren dabei als reguläre Updates getarnt und für Nutzer auf den ersten Blick nicht erkennbar.
Die Auswirkungen dieses Angriffs sind potenziell enorm: Jedes Unternehmen, das LiteLLM als KI-Gateway einsetzt – und dazu gehören zahlreiche Firmen, die damit API-Schlüssel, Nutzerdaten und vertrauliche Prompts über ihre KI-Infrastruktur leiten –, könnte betroffen sein. Da LiteLLM häufig als zentraler Knotenpunkt in der KI-Architektur fungiert und mit weitreichenden Berechtigungen ausgestattet ist, hatten die Angreifer im schlimmsten Fall Zugriff auf sämtliche API-Keys, Zugangsdaten zu Cloud-Diensten und interne Kommunikation. Besonders brisant: Der Schadcode wurde nicht durch einen Hack der LiteLLM-Codebasis selbst eingeschleust, sondern über kompromittierte Maintainer-Zugangsdaten bei PyPI – ein Angriffsvektor, der zeigt, wie verwundbar selbst weit verbreitete Open-Source-Projekte in ihrer Lieferkette sind. Die betroffenen Versionen wurden mittlerweile von PyPI entfernt und sichere Nachfolgeversionen veröffentlicht.
Für Unternehmen, die LiteLLM im Einsatz haben, besteht dringender Handlungsbedarf: Zunächst sollte sofort geprüft werden, ob eine der kompromittierten Versionen installiert ist, und ein Update auf eine bereinigte Version durchgeführt werden (das Repository von LiteLLM wurde auf 1.82.3 zurückgesetzt in der ersten Reaktion des Maintainers, diese Version scheint also noch sicher zu sein). Darüber hinaus empfiehlt es sich, sämtliche API-Schlüssel und Zugangsdaten, die über LiteLLM geroutet wurden, als potenziell kompromittiert zu betrachten und umgehend zu rotieren.
Dieser Vorfall unterstreicht einmal mehr die Notwendigkeit, Software-Abhängigkeiten konsequent zu überwachen – etwa durch den Einsatz von Dependency-Pinning, Hash-Verifikation, Software Bill of Materials (SBOM) und automatisierten Security-Scans in der CI/CD-Pipeline. Der LiteLLM-Angriff ist ein Weckruf für die gesamte KI-Branche: Wer KI-Infrastruktur betreibt, muss Supply-Chain-Sicherheit als erstrangige Priorität behandeln.
Auf Twitter/X raunt man von 500K betroffenen Systemen, und 3 GB gestohlenen Daten. Besonders perfide außerdem, dass mit der Installation einer verwundbaren Version von LiteLLM das gesamte PyPI-Ökosystem auf einem System betroffen wurde. Die primäre Schadcode-Komponente nutzte dabei eine im Zusammenhang mit PyPI-Angriffen neuartige Technik: eine .pth-Datei namens litellm_init.pth (34.628 Byte), die im Verzeichnis „site-packages“ von Python abgelegt wurde. (.pth-Dateien werden von Python beim Start automatisch ausgeführt – das bedeutet, der Schadcode lief nicht nur bei der Nutzung von LiteLLM, sondern bei jedem Python-Aufruf auf dem betroffenen System.) Tja. Dergleichen blüht uns nun bestimmt auch bei künftigen weiteren Attacken auf Package-Registries und Code-Repositories.
Was LiteLLM selbst angeht, war die Installation via Docker ein probates Mittel, um das Problem zumindest einzudämmen. Weder die Verseuchung des gesamten Python-Systems, noch die Verankerung in systemd waren damit möglich, so dass sich die betroffenen Schlüssel ggfs. recht einfach eingrenzen ließen. Aber wie ist es mit Abhängigkeiten, also Systemen, die LiteLLM nachladen? Kaum zu überschauen, wo das Problem überall hineinschleichen konnte.
Generell ist Docker immer empfehlenswert aus Security-Sicht, das kann man dem Vorfall wieder einmal entnehmen. Aber wie das zunehmend komplexe Gefüge der aufeinander aufbauenden Software-Stacks absichern kann, das macht einen schaudern für die Zukunft. LiteLLM (bzw. BerriAI, das Unternehmen dahinter) hat sogar eine SOC 2 Type II Zertifizierung!
Dieser Angriff, der übrigens offenbar auch alle Merkmale von KI-gestütztem Coding aufweist, zeigt außerdem eine beunruhigende Synergie: Supply-Chain-Angriffe werden zunehmend durch KI-generierte Inhalte unterstützt – sei es durch täuschend echte Phishing-Mails, gefälschte Maintainer-Kommunikation oder manipulierte Dokumentation. Und dazu das Problem der immer zunehmenden und immer besser werdenden KI-generierten sonstigen Inhalte überall. Mittlerweile sind die Fakes und Betrugsversuche so gut geworden, dass es auch für sehr erfahrene Fachleute immer schwerer wird, echten Content zuverlässig zu erkennen. Geht es bald wieder zurück zu „Von Angesicht zu Angesicht“, sonst kann man rein gar nichts mehr glauben?
Das von Turing-Preisträger Yann LeCun gegründete Start-up AMI Labs hat in einer historischen Seed-Finanzierungsrunde 890 Millionen Euro eingeworben – die größte ihrer Art in Europa. LeCun, der zwölf Jahre lang als KI-Chefwissenschaftler bei Meta tätig war und dort das renommierte Forschungslabor FAIR aufbaute, verließ den Konzern Ende 2025, um sich mit seinem in Paris ansässigen Unternehmen Advanced Machine Intelligence Labs einem neuen KI-Paradigma zu widmen. Zu den prominenten Investoren zählen unter anderem Nvidia, Samsung, Toyota sowie Jeff Bezos, Mark Cuban und Eric Schmidt – ein klares Signal, dass die Branche großes Potenzial in LeCuns Vision sieht.
Im Zentrum steht die Entwicklung sogenannter Weltmodelle – KI-Systeme, die nicht wie herkömmliche Sprachmodelle auf Textgenerierung setzen, sondern die reale Welt verstehen, schlussfolgern und planen können. „Echte Intelligenz beginnt nicht mit Sprache. Sie beginnt in der realen Welt“, lautet das Credo von AMI Labs. LeCun ist überzeugt, dass dieser Ansatz den Weg zu wirklich intelligenten KI-Systemen ebnet – und damit weiter führt als aktuelle generative Modelle wie ChatGPT, die trotz beeindruckender Sprachfähigkeiten nach wie vor zu Halluzinationen neigen. Die Technologie soll zunächst gemeinsam mit Partnern aus datenintensiven Branchen wie Industrie, Biomedizin und Robotik entwickelt werden. Erster offizieller Partner ist das Healthtech-Start-up Nabla, das KI-gestützte Dokumentation für Ärzte anbietet.
Trotz des enormen Investorenvertrauens steht AMI Labs noch am Anfang eines langen Weges. Das Unternehmen beschäftigt derzeit nur zwölf Mitarbeiter – verteilt auf Standorte in Paris, New York, Montreal und Singapur – und es wird nach eigener Einschätzung noch Jahre dauern, bis Weltmodelle von der Grundlagenforschung zu marktfähigen Produkten reifen. Gleichzeitig zeigt die Dynamik im Markt, dass AMI Labs nicht allein unterwegs ist: Auch World Labs sicherte sich kürzlich rund eine Milliarde US-Dollar, und Technologieriesen wie Meta und Google experimentieren mit vergleichbaren Ansätzen. Die Entwicklung von Weltmodellen könnte sich damit als eines der spannendsten Wettbewerbsfelder der KI-Branche in den kommenden Jahren erweisen.
Nun, dass LLM nicht zu AGI führt, das wird mit jeder neuen Generation deutlicher. Sicher, im Rahmen der einem LLM gestellten Aufgabe sind die Verbesserungen weiterhin signifikant, aber die grundlegenden Mängel bleiben bestehen. Es gibt bisher keinen effizienteren Weg, das Weltwissen verfügbar zu machen, als mit KI, aber der Transport dieses Wissens in die reale Welt bedarf weiterhin und unverändert menschlicher Expertise, Erfahrung und Flexibilität.
Der Ansatz von AMI Labs ist deshalb nachvollziehbar. Er entbehrt aber nicht einer gewissen Hybris – wofür die Natur Milliarden Jahre gebraucht hat, will der Mensch nun in einem geschichtlichen Wimpernschlag schaffen? Aber abgesehen davon, ich frage mich ja schon, woher dieser selbstdestruktive Trieb kommt, sich unbedingt ersetzen zu wollen. Ich bin überzeugt, mit KI und Robotik lässt sich das vielbesungene Paradies auf Erden erreichen, eine Welt, in der keiner mehr hungern muss und die Menschen ihr Leben mit Kunst und Liebe verbringen können. Die Jagd nach AGI jedoch dient genau welchem Zweck? Ein solches Paradies, aber ohne Menschen? Wozu soll das gut sein? Und warum sollten wir es bauen wollen?
Ich denke, der Mensch wäre besser beraten, zuerst einmal die mit den neuen Technologien vorhandenen Möglichkeiten zum allgemeinen Nutzen einzusetzen. Anstatt Luftschlössern hinterher zu jagen, für die man sich schon fragen muss, ob sie nicht nur dem Aufblähen von Börsenkursen dienen. Das Lustige ist ja, gäbe es AGI, was hätten intelligente Roboter von gestiegenen Börsenkursen?
Forscher der University of Washington (Allen School) und der University of Stanford haben die bislang größte Studie zur kreativen Vielfalt von KI-Systemen durchgeführt – und die Ergebnisse sind ernüchternd. Über 70 verschiedene große Sprachmodelle (LLMs) aller führenden Anbieter wurden mit denselben offenen Fragen konfrontiert: „Schreibe ein Gedicht über die Zeit“, „Schlage Startup-Ideen vor“, „Gib mir Lebensratschläge.“ Also solche Fragen, auf die zehn verschiedene Menschen zehn völlig unterschiedliche Antworten geben würden. Doch trotz unterschiedlicher Architekturen, Trainingsdaten und Hersteller lieferten die Modelle nahezu identische Antworten – dieselben Ideen, dieselben Strukturen, dieselben Metaphern. Die Forscher nennen dieses Phänomen den „Artificial Hivemind“ (Künstlicher Schwarmgeist).
Die Arbeit wurde mit dem Best Paper Award der NeurIPS 2025 ausgezeichnet, der höchsten Anerkennung in der KI-Forschung. Sie können die Studie hier bei uns oder bei der Cornell University herunterladen.
Während die Menschheit sich noch müht, auch nur ansatzweise mit den neuen KI-Technologien Schritt zu halten, stehen bereits Weiterentwicklungen in den Startlöchern, die Künstliche Intelligenz in Regionen katapultieren, die den Menschen hoffnungslos überfordern. 1 Sekunde für die Antwort, und der Mensch liest eine halbe Stunde daran … Man benötigt diese Geschwindigkeitsfortschritte für Echtzeit-Anwendungen. Aber wie der Mensch dabei noch mithalten soll, ist völlig unklar. Woher diese enorme Beschleunigung kommt, fragen Sie jetzt vielleicht? Das Zauberwort heißt Diffusion.
Diffusion ist ein Konzept, das man in der KI bisher eigentlich nur zur Erzeugung von Bildern und Videos kennt. Diffusion, der Name klingt nach Physik – und das ist kein Zufall. In der Natur beschreibt Diffusion, wie sich beispielsweise ein Tropfen Tinte in einem Glas Wasser langsam ausbreitet, bis alles gleichmäßig verteilt ist. Aus Struktur wird Chaos. KI-Forscher haben diesen Prozess umgekehrt. Einem Bild wird zufälliges Rauschen hinzugefügt, bis nur noch graues Pixelrauschen übrig ist. Genau diesen Prozess lernt das Modell dann rückwärts. Es startet mit reinem Rauschen und verfeinert das Bild Schritt für Schritt, bis ein scharfes, kohärentes Ergebnis entsteht. Das Entscheidende dabei: Das Modell lernt nicht, ein Bild direkt zu „malen“. Es lernt, Rauschen zu erkennen und zu entfernen – und das iterativ, in vielen kleinen Schritten.
Inception Labs, ein kalifornisches KI-Start-up (investiert u.a. von Microsoft, NVIDIA und Snowflake), hat mit Mercury 2 ein Modell vorgestellt, das den Diffusion-Ansatz auf die Erzeugung von Text überträgt. Das Modell hat bereits viel Aufsehen erregt. „Laut Inception ist Mercury 2 damit mehr als fünfmal schneller als herkömmliche Modelle und erreicht 1.009 Tokens pro Sekunde auf Nvidia-Blackwell-GPUs. Die End-to-End-Latenz liegt bei nur 1,7 Sekunden“, schreibt Heise.
Diffusion bei Text mit einem dLLM (Diffusion Large Language Model) funktioniert so:
Initialisierung: Das Modell startet mit einem „Rauschen“ – einer Menge von Token-Vorschlägen, die unvollständig oder teilweise inkorrekt sind.
Iterative Verfeinerung: In mehreren Durchläufen (meist 10-50 Schritte) verfeinert das Modell diese Token gleichzeitig.
Parallele Optimierung: Statt „Erst Wort A, dann Wort B“ wird die gesamte Passage betrachtet: „Wie kann ich diese 100 Token so anpassen, dass sie zusammen maximal sinnvoll sind?“
Warum das schneller ist:
Autoregressive Modelle brauchen N Forward-Passes für N Token (sequentiell)
Diffusionsmodelle brauchen K Forward-Passes für N Token, wobei K oft deutlich kleiner ist als N
Probieren Sie es aus! Hier ist ein Demo-Chat, mit dem Sie es selbst testen können. Die Antwortgeschwindigkeit ist wirklich umwerfend. Hier ist noch ein Video, mit dem der Inception-CEO Prof. Stefano Ermon von der Stanford University sein neues dLLM vorstellt. Und hier ist der Blog-Eintrag des Unternehmens dazu.
