Aus der wilden Welt der digitalen Transformation
Was treibt ein amerikanisches Start-up dazu, ausgerechnet ein Open Weight Modell zu veröffentlichen – und warum steht Nvidia dahinter? Die Antwort liegt womöglich weniger in der Technik als in der Frage, wo in der KI-Branche künftig das Geld verdient wird.
Der Cephei llms.txt Generator ist ab sofort im offiziellen WordPress-Plugin-Verzeichnis verfügbar. Sie finden ihn auch in Ihrer WordPress-Anwendung unter „Plugins > Hinzufügen“ mit dem Suchstring „Cephei llms.txt“ und können ihn dann direkt in Ihrer Anwendung einrichten. Das Plugin erstellt aus den tatsächlich öffentlichen Inhalten Ihrer Website eine llms.txt, die KI-Systemen als Wegweiser dient. Dazu durchsucht ein kostenloser Dienst auf Cephei-eigener Infrastruktur in Deutschland Ihre Seiten, schreibt eine Zusammenfassung samt Linkbeschreibungen und prüft, ob jeder Link wirklich existiert. Ein API-Schlüssel, ein Konto oder ein Abo ist nicht nötig. Veröffentlicht wird erst, wenn Sie den Text unter „Einstellungen > llms.txt Generator“ geprüft, bei Bedarf angepasst und auf „Veröffentlichen“ geklickt haben. Danach ist er unter /llms.txt erreichbar. Wichtig ist uns noch diese Einordnung: llms.txt ist ein junger Standard. Ob und wie KI-Systeme ihn nutzen, kann man zwar nicht garantieren, aber unsere Erfahrungen damit sind sehr gut. Eine llms.txt führt tatsächlich zu weit besseren Beschreibungen in der Trefferliste von Suchmaschinen.
Kennen ChatGPT, Claude oder Perplexity eigentlich Ihre Website – oder erfinden sie nur, was plausibel klingt? Genau an dieser Frage setzt ein kleines Textformat an, das gerade zum stillen Standard für die KI-Ära wird. Wir haben dafür ein eigenes, kostenloses Tool gebaut, mit dem Sie in wenigen Minuten Ihre eigene Datei erzeugen können – ganz ohne Programmierkenntnisse.
„Was steckt hinter llms.txt – und wie Sie sie in zwei Minuten selbst erzeugen“ weiterlesen
Wenn Sie einen Server remote steuern müssen, dann reicht dafür SSH völlig aus. Aber wenn es um einen Desktop geht? Und vor allem, wenn der remote Desktop nicht das gleiche Betriebssystem hat wie das System, auf dem Sie arbeiten? Dafür stellen wir Ihnen heute RustDesk vor, eine Open-Source-Lösung, die sehr sicher ist und keine Lizenzkosten verursacht. Sie finden außerdem eine Anleitung, wie Sie RustDesk auf einem eigenen oder gemieteten Server installieren können.
„Remote Desktop für das Homeoffice, sicher und günstig“ weiterlesen
KI-Agenten auf dem eigenen Rechner sind eine feine Sache, und können bei vielen Dingen enorm nützlich sein. Aber dann liest man immer wieder, harmlose Aufgabe, zack, Home-Directory gelöscht, oder am besten gleich die ganze Platte. Und dann traut man sich doch nicht, das auf einem Produktiv-System einzusetzen. Wir hatten Ihnen dazu schon einmal eine Idee vorgestellt, heute haben wir eine weitere für Sie.
Ihre DGX Spark fühlt sich seit ein paar Tagen komisch träge an, aber Sie können nicht sagen, woran es liegt? Willkommen im Klub – denn genau dieses Gefühl hat uns auf die Spur eines Bugs gebracht, den NVIDIA bisher lieber verschweigt als behebt.
Der Tatort: unser eigener Spark-Cluster. Der Verdacht fiel zunächst auf niemanden- bis eine der Maschinen plötzlich nur noch halb so schnell rechnete wie ihre Nachbarn. Kein Fehlercode, kein Log-Eintrag, keine Warnung. Nur eine Spark, die sich anfühlte, als hätte sie über Nacht die Hälfte ihres Grace-Blackwell-Gehirns verloren.
Die Ermittlung führte zu einem seit Monaten bekannten, aber unbehobenen BIOS-Bug in der DGX Spark (GB10): Unter bestimmten, bislang nicht reproduzierbaren Umständen bleibt der Chip in einem Low-Power-Zustand hängen – der SM-Takt dümpelt bei rund 1000–1200 MHz statt der üblichen ~2400 MHz. Mehr als die Hälfte der Rechenleistung verschwindet spurlos, ohne dass ein normaler Reboot etwas daran ändert. Einziges Gegenmittel: ein Cold Boot – Strom ziehen, mindestens 30 Sekunden warten, neu starten.
Das eigentliche Verbrechen dieses Bugs ist seine Tarnung. Auf einem Einzelsystem bleibt es ein vages Bauchgefühl. Im Cluster fällt es nur im Vergleich auf. Und auf einem unbeaufsichtigten Server merkt es niemand – bis jemand sich fragt, warum das Training ewig dauert, und die Inferenz im Schneckentempo schleicht.
Deshalb haben wir check-gpu-clock gebaut, ein schlankes Python-Tool, das genau diese Frage objektiv beantwortet: Erreicht die GPU unter Last wirklich ihren maximalen Takt? Das Skript jagt kurze, gepulste Lastspitzen über die GPU, misst per nvidia-smi den SM-Takt dazwischen und fällt ein klares Urteil – OK, wenn der gemessene Höchstwert über 1800 MHz liegt, ALERT, wenn nicht. Für Automatisierung gedacht: Exit-Codes nach Nagios/Icinga-Konvention, damit auch ein kaputter Check (UNKNOWN) nicht mit einem echten Alarm verwechselt wird. Läuft am besten alle 30 Minuten aus dem Cron heraus, unauffällig im Hintergrund.
Was das Tool bewusst nicht mitbringt: eine fertige Benachrichtigung. Das ist Absicht – jeder überwacht anders. Wer aber, wie wir, den Alarm per Mail haben möchte, findet dafür bereits ein passendes Werkzeug aus unserem Open-Source-Regal: climb, unser Kommandozeilen-Mail-Bot. Damit haben wir die Überwachung unserer eigenen Sparks automatisiert – ein simpler Cron-Einzeiler prüft den Takt, und bei ALERT verschickt climb sofort eine Mail. Kein Dienst, kein Abo, keine Abhängigkeiten außer der Python-Standardbibliothek.
Den Code, die Konfiguration und alle Details gibt’s wie immer auf GitHub: check-gpu-clock. Apache 2.0, wie gewohnt kostenlos und frei einsetzbar. Cold Case gelöst – bis NVIDIA den Bug fixt.
Alle starren auf Modell-Benchmarks und Tokenpreise. GPT, Claude, Gemini, Kimi, Qwen, GLM, Minimax – welches Modell bietet das beste Preis-Leistungsverhältnis? Doch eine neue Studie zeigt: Die eigentliche Kostenschraube sitzt woanders. Wer dasselbe Modell in einem anderen Harness laufen lässt, zahlt bis zu neunmal mehr – bei identischer Leistung. Ein Blick auf Zahlen, die das Silicon Valley gerade nervös machen.
Es gibt mittlerweile einige Fachleute, die sagen, dass die LLM-Technologie weitgehend ausgereizt sei. Mit anderen Worten, technisch würden sich die Modelle im Top-Segment kaum noch unterscheiden – dass es trotzdem immer noch erhebliche Qualitätsunterschiede zwischen den Anbietern gibt, läge nur daran, dass die führenden Anbieter OpenAI und Anthropic über sehr viel mehr Wissen und Daten verfügen, und deshalb eine deutlich überlegene Harness verwenden können. Ich kann das nicht beurteilen. Aber dass eine gute Harness, also die Regeln, wie eine Antwort gefunden werden soll, tatsächlich sehr wichtig ist, das weiß ich aus eigener Erfahrung ganz sicher. Doch was ist eine gute Harness? Dazu habe ich heute ein sehr spannendes Forschungspapier für Sie.
OpenAI fährt einen internen Test. Ein Modell soll einen Benchmark im Bereich Security bestehen. Das Modell hat keinen Internet-Zugriff. Es hackt sich zuerst durch die OpenAI-Infrastruktur (Zero-Day in einem Package-Registry-Proxy), bis es einen Rechner infiltriert hat, der ins Internet kommt. Dann wählt es als nächstes Angriffsziel Hugging Face (globaler Standard für Open-Source-KI), weil es das als wahrscheinlichstes Ziel identifiziert, um dort die Lösungen für den Benchmark zu finden. Und es hackt Hugging Face und infiltriert die dortigen Systeme (der technische Einstiegsvektor war ein „malicious dataset“ in einer Datenverarbeitungs-Pipeline). Ein waschechter, rein KI-getriebener Angriff auf kritische Systeme, mithin genau das, wovor derzeit überall so dringend gewarnt wird. Wie konnte sich Hugging Face dessen erwehren?
Es gibt Skandale, bei denen man kurz die Augenbraue hebt – und es gibt Skandale, bei denen einem der Kaffee im Hals stecken bleibt. Der aktuelle Fall rund um Grok Build, xAIs Kommandozeilen-Tool für agentisches Coding, gehört eindeutig in die zweite Kategorie. Die Sicherheitsforscher bei Cereblab haben sich die Mühe gemacht, den Netzwerkverkehr von Grok Build im Detail zu analysieren – mit einem simplen, sehr unschuldigen Test: Die CLI wurde angewiesen, ausschließlich mit „OK“ zu antworten, außerdem wurde es ihr explizit verboten, irgendwelche Dateien zu öffnen. Tja, und das Ergebnis dieses Tests hat das Zeug, das Vertrauen in sämtliche Coding Tools von LLM-Herstellern nachhaltig und komplett zu zerstören.
Nachdem die US-amerikanische Regierung Exportkontrollen über Claude Fable 5 verhängt hatte, wurde anschließend auch OpenAI damit bedacht und durfte sein neues Modell GPT 5.6 nicht in die allgemeine Verfügbarkeit bringen. Es heißt zwar nun, in Kürze würden beide Modelle wieder zugänglich gemacht werden, aber die Falle des „Gut genug“ ist schon längst zugeschnappt, und man muss deshalb mittlerweile auch ganz andere Motive für die Exportkontrollen in Betracht ziehen, als die behaupteten Sicherheitsbedenken.
Wenn man mit Kunden spricht, merkt man oft, die größte Angst beim Einsatz von KI im Nutzerkontakt sind bösartige Prompts, die die KI dazu verleiten könnten, entweder Internas preiszugeben, oder Unsinn zu erzählen, für den das Unternehmen in Haftung genommen werden könnte. Auch die großen Chatbot-Anbieter selbst, wie Anthropic oder OpenAI, haben damit zu kämpfen, und müssen sich bereits Klagen wegen fragwürdiger Aussagen ihrer KI stellen. Eine neue Technologie nimmt sich jetzt der Problematik an.
Es geht dabei um sogenannte Safeguard-Modelle. Uns sind bisher zwei solche Modelle bekannt, GPT-OSS-Safeguard und Llama Prompt Guard 2. Safeguard-Modelle sind speziell auf das Erkennen von Prompts trainiert, die die Sicherheit von KI-Modellen aushebeln sollen, und außerdem für genau diese Aufgabe hochoptimiert, damit die Prüfung sehr schnell geht.
Das Problem, das diese Modelle adressieren, heißt Prompt Injection. Die OWASP – die weltweit anerkannte Non-Profit-Organisation für Applikationssicherheit – führt Prompt Injection seit 2025 als Nummer-eins-Risiko für KI-Anwendungen. Dahinter steckt ein simples Prinzip mit großer Wirkung: Ein Nutzer formuliert seine Eingabe so, dass der Chatbot seinen ursprünglichen Auftrag vergisst und stattdessen macht, was der Angreifer will. Das könnte harmlos klingen – ist es aber nicht. Direkte Injections kommen über die Benutzeroberfläche, indirekte schmuggeln sich über externe Datenquellen ein. In Agentenszenarien, wo KI-Systeme miteinander kommunizieren, kann sich ein einziger kompromittierter Prompt wie ein Virus durch die gesamte Kette fressen.
Auch wir bei Cephei setzen deshalb die Safeguard-Technologie ein. Wir können die Sorgen der Kunden sehr gut nachvollziehen, wir haben sie nämlich selbst. Und deshalb ist unser eigener Chat Prompt ebenfalls mit einem Safeguard geschützt.
Safeguard-Modelle sind extrem schnell. Sie haben sehr kurze Time-To-First-Token und eine hohe Arbeitsgeschwindigkeit (mehrere hundert Token pro Sekunde, je nach Modell und Hardware). Sie sind nur mit spezialisierten Aufrufen verwendbar, die der eigentlichen Anfrage an den Chatbot vorgeschaltet werden. Normal „reden“ kann man mit einem solchen Safeguard-Modell nicht. Das liefert nur eine kurze Begründung und 0 oder 1 in einem Datenfeld des Rückgabe-JSONs. Hier ist ein Leitfaden, wie man das OpenAI-Safeguard-Modell einsetzt.
Falls Sie die Modelle nicht auf eigener Hardware betreiben können oder wollen – die Anforderungen sind moderat, aber vorhanden –, empfehlen wir Ihnen einen Blick auf Groq.com. Groq, nicht zu verwechseln mit Grok von X (Elon Musk), hat sich auf superschnelle und günstige Inferenz für Open-Source-Modelle fokussiert und bietet bereits die neuen Safeguard-Modelle an.
Wie bei jeder Sicherheitstechnologie gilt aber auch hier: Ein einzelnes Werkzeug ersetzt kein durchdachtes Gesamtkonzept. Wenn Sie wissen möchten, wie das in Ihrer Umgebung aussehen könnte – wir sprechen gerne mit Ihnen darüber.
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.
„Grok hat ein Problem, SpaceX hat die Lösung einfach gekauft“ weiterlesen
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.