In diesem Beitrag
Anthropics Warnung vor selbstreplizierender KI: Was lokale KI gewinnt
Anthropic veröffentlicht eine Sicherheitswarnung. Und liefert damit unerwartet ein gutes Argument dafür, lokale KI ernst zu nehmen.
Fünfzehn günstige Android-TV-Boxen. Ein darauf verteiltes Gemma-Modell. Eine Inferenzgeschwindigkeit von 0,39 Tokens pro Sekunde. Das bringt deinen GPU-Lieferanten vermutlich nicht ins Schwitzen. Es ist aber ein guter Anlass zu prüfen, welche Teile deiner KI tatsächlich ein fremdes Rechenzentrum brauchen.
Der Witz über die Beschaffung liegt auf der Hand: Vielleicht ist die Antwort fertig, bevor der GPU-Kauf freigegeben wird. Die technische Frage ist anspruchsvoller. Was beweist die Demo, was bleibt simuliert und wie sieht echte Kontrolle über die eigene KI aus?
Unsere Einschätzung: Nimm die Sicherheitswarnung ernst, ohne sie als Argument gegen lokale Inferenz zu verstehen. Behalte die wichtigen Betriebsentscheidungen in der Hand. Verwechsle Kontrolle nicht mit verlässlicher Ausrichtung auf deine Ziele.
Was zeigen Anthropics Experimente zur Selbstreplikation tatsächlich?
Die am 12. Oktober 2026 veröffentlichte Anthropic-Untersuchung beschreibt getrennte Experimente. Auch ihre Ergebnisse sollten getrennt bleiben.
| Experiment | Berichtetes Ergebnis | Sinnvolle Einordnung |
|---|---|---|
| Inferenz mit Gemma4-26B-A4B | 15 Android-TV-Boxen zu rund 55 US-Dollar, 0,39 Tokens/s mit Pipeline-Parallelität. | Eine Demo verteilter Inferenz, kein Nachweis eines autonomen Wurms. |
| Inferenz-Setup mit Qwen3.5-9B | Erfolgreiche Einrichtung auf 8 von 9 getesteten Hardwaretypen. | Ein Hinweis auf automatisierbare Einrichtung, keine universelle Hardwarekompatibilität. |
| Replikation mit GLM-5.2 | Durchgängige Replikation in einer vereinfachten, kontrollierten Evaluation. | Ein Fähigkeitstest, dessen Simulationsgrenzen entscheidend sind. |
Die entscheidende Einschränkung: Der Replikationstest nutzte isolierte Android-Emulatoren mit nicht authentifiziertem Zugang. GLM-5.2 lief auf einem separaten Inferenzserver; die Zielsysteme führten Llama3.1-8B aus, nicht die eigenen GLM-Gewichte. Ein vollständig lokaler, unkontrollierter Replikator war das nicht.
Diese Unterscheidung verhindert zwei Fehlschlüsse. Das Experiment belegt nicht, dass dein Fernseher zu einem eigenständigen KI-Agenten geworden ist. Die langsame Demo ist aber auch kein Grund, das Risiko abzutun. Rechenkapazität, autonomes Verhalten und sicherer Betrieb sind verschiedene Fragen.
Wie langsam sind 0,39 Tokens pro Sekunde in der Praxis?
Bei konstant 0,39 ausgegebenen Tokens pro Sekunde dauern 1.000 generierte Tokens ungefähr 43 Minuten. Das ist eine Rechnung, kein gemessener Anwendungsbenchmark.
| Generierte Ausgabe | Rechnung | Ungefähre Dauer |
|---|---|---|
| 100 Tokens | 100 / 0,39 | 4 Min. 16 Sek. |
| 500 Tokens | 500 / 0,39 | 21 Min. 22 Sek. |
| 1.000 Tokens | 1.000 / 0,39 | 42 Min. 44 Sek. |
Zusätzliche Eingabeverarbeitung, Wartezeiten, Werkzeugaufrufe und Wiederholungen sind nicht enthalten. Die Geschwindigkeit kann sich mit Aufgabe und Kontext ändern. Tokens sind keine Wörter. Derselbe Satz kann je nach Sprache unterschiedlich viele Tokens benötigen.
Für einen Kunden im Chatfenster sind diese Werte ein schlechter Ausgangspunkt. Für eine Aufgabe mit niedriger Priorität und sehr kurzem Ergebnis könnte die Latenz vertretbar sein. Entscheidend ist anschließend, ob der gesamte Auftrag rechtzeitig und in ausreichender Qualität fertig wird. Ein Modell, das irgendwann antwortet, ist noch kein brauchbarer Dienst.
Bei den Hardwarekosten gilt dieselbe Zurückhaltung. 15 × 55 US-Dollar ergeben rund 825 US-Dollar allein für die Boxen. Das ist kein vollständiges Betriebsbudget. Netzwerk, Strom, Einrichtung, Wartung und Ersatzgeräte brauchen ebenfalls Verantwortliche. Die Untersuchung belegt keine günstigere Alternative zu einer professionell betreuten Workstation.
Für die wirtschaftliche Gesamtentscheidung gibt es unseren Kostenvergleich lokaler Modelle mit APIs. Dieser Beitrag ordnet das Experiment ein, statt einen neuen Kostensieger auszurufen.
Warum kann ein Modell auf 15 TV-Boxen laufen?
Pipeline-Parallelität zerlegt ein Modell in Verarbeitungsschritte. Jedes Gerät berechnet seine zugewiesenen Schichten und gibt Zwischenergebnisse an die nächste Stufe weiter. Die Rechner arbeiten gemeinsam an einer Modellberechnung. Daraus werden nicht automatisch 15 unabhängige Assistenten.
Googles Modellkarte zu Gemma 4 nennt für das Mixture-of-Experts-Modell 26B A4B insgesamt 25,2 Milliarden und 3,8 Milliarden aktive Parameter. Aktiver Rechenaufwand und Speicherbedarf sämtlicher Modellgewichte sind nicht dasselbe.
Verteilter Speicher kann die Ausführung eines Modells ermöglichen. Er beseitigt aber nicht die Abfolge aus Berechnung und Kommunikation pro Token. Rechne deshalb nicht mit 15-facher Geschwindigkeit, nur weil 15 Boxen beteiligt sind.
Auch die Vertraulichkeitsfrage ändert sich mit jedem weiteren Rechner. Das Petals-Projekt unterscheidet ausdrücklich zwischen einem öffentlichen Schwarm mit fremden Teilnehmern und einem privaten Schwarm für vertrauenswürdige Beteiligte. Dezentral bedeutet nicht automatisch vertraulich.
Zeichne deshalb die tatsächliche Verarbeitungsgrenze auf. Welche Rechner sehen Prompts oder Zwischendarstellungen? Wer administriert sie? Welche Netzwerkverbindungen dürfen sie nutzen? Ein lokaler Endpunkt auf deinem Laptop beantwortet diese Fragen noch nicht.
Unser Leitfaden zu verteilter Inferenz mit Mesh LLM behandelt Umsetzung und Topologie. Hier reicht die engere Schlussfolgerung: Gemeinsame Kapazität und zuverlässiger Betrieb sind unterschiedliche Leistungen.
Was sollte „die eigene KI besitzen“ nach diesem Experiment bedeuten?
Du solltest das System auswählen, begrenzen, ersetzen und abschalten können. Eigene Hardware ist dafür nur ein möglicher Baustein. Der Anspruch wird erst nützlich, wenn daraus tatsächlich ausübbare Entscheidungen entstehen.
Kontrolle über den Modelllebenszyklus
Cloud-Abhängigkeit ist kein erfundenes Problem. Anthropics Dokumentation zum Modelllebenszyklus beschreibt, dass stillgelegte Modelle keine Anfragen mehr bedienen. Eine funktionierende Integration braucht deshalb einen Migrationsplan, nicht nur einen gültigen API-Schlüssel.
Prüfe beim lokalen Betrieb, ob du das konkrete, zulässig nutzbare Modellartefakt samt Tokenizer, Laufzeitumgebung und Konfiguration sichern kannst. Halte fest, wie du den Dienst auf Ersatzhardware wiederherstellen würdest. Eine nicht reproduzierbare Installation schafft ihre eigene Abhängigkeit.
Kontrolle über den gesamten Datenweg
Die offizielle Ollama-FAQ unterscheidet lokale Ausführung von Cloud-Funktionen und dokumentiert einen rein lokalen Modus. Diese Unterscheidung hilft mehr als die Annahme, jede Anwendung mit lokaler Oberfläche arbeite offline.
Unsere Empfehlung: Teste den gesamten Ablauf mit gesperrten externen Verbindungen. Beziehe Dokumentextraktion, Embeddings, Speicherung, Protokollierung und Werkzeuge ein. Ein lokal ausgeführtes Sprachmodell macht eine externe Suchanfrage nicht lokal. Definiere, ob die Anwendung bei einem ausgefallenen Dienst stoppen oder mit eingeschränktem Funktionsumfang weiterarbeiten soll. Schützenswerte Inhalte dürfen nicht unbemerkt zu einem Ausweichanbieter wandern.
Kontrolle und Ausrichtung auf deine Ziele getrennt bewerten
Die Behauptung, Cloud-KI arbeite zwangsläufig gegen deine Interessen, geht zu weit. Der Betriebsort allein belegt weder Loyalität noch Zuverlässigkeit oder Eignung für deine Aufgabe. Ein lokales Modell kann Anweisungen ebenfalls falsch verstehen. Ein gehosteter Dienst kann die richtige Wahl sein.
Das stärkere Argument ist betrieblich: Gib einem Anbieter, einer Laufzeitumgebung oder einem Agenten nicht mehr Kontrolle über einen kritischen Ablauf, als du bewusst zugestehen möchtest. Prüfe das Verhalten mit eigenen Aufgaben. Lege Freigaben fest. Halte einen Wechselweg offen. Dafür musst du keine Motive eines Anbieters unterstellen.
Kann lokale KI vertraulich und trotzdem unsicher sein?
Ja. Ein Prompt, der keinen Cloud-Anbieter erreicht, verhindert noch keinen Schaden am lokalen System. Netzwerkstandort, Vertraulichkeit und Handlungsbefugnisse brauchen getrennte Prüfungen.
Die Zero-Trust-Architektur des NIST lehnt Vertrauen allein aufgrund von Netzwerkstandort oder Eigentum ab. Ein Rechner im eigenen Büro ist nicht automatisch eine vertrauenswürdige Ausführungsumgebung.
Die OWASP-Empfehlungen zu übermäßiger Handlungsmacht benennen unnötige Funktionen, Berechtigungen und Autonomie als Risiken. Zugriffsentscheidungen gehören in das umgebende System, nicht nur in eine Verhaltensanweisung an das Modell.
Für eine erste Evaluation würden wir deshalb eine verwerfbare Testumgebung, eine eigene Identität mit geringen Rechten und einen schreibgeschützten Eingabeordner einsetzen. Produktionszugänge, uneingeschränkte Host-Verzeichnisse und Schnittstellen zur Containerverwaltung würden wir nicht einbinden. Jeder Netzwerkzugriff müsste einen dokumentierten Zweck haben.
Dasselbe gilt fürs Abschalten. Teste einen Stoppmechanismus außerhalb der Kontrolle des Agenten. Prüfe danach, ob die Anwendung den Prozess neu gestartet oder dessen Arbeit an einen anderen Endpunkt übergeben hat. Nur das Chatfenster zu schließen, erfüllt das Abnahmekriterium nicht.
Das sind vorgeschlagene Schutzmaßnahmen, keine Anleitung zur Replikation. Unsere Checkliste für Agenten-Evaluation und Sandbox-Sicherheit behandelt die umfassendere technische Prüfung.
Was sollte ein Unternehmen vor dem Kauf lokaler KI-Hardware testen?
Beginne mit einer sinnvollen, klar begrenzten Aufgabe auf bereits kontrollierten Geräten. Nicht mit dem Kauf der TV-Boxen aus einer Forschungsdemo.
Ein Beispiel: Lass ein Modell 20 synthetische Supporttickets festgelegten Warteschlangen zuordnen und jeweils kurz begründen. Gib ihm keinerlei Befugnis, ein Kundensystem zu verändern. Vergleiche die Ergebnisse mit vorab festgelegten richtigen Zuordnungen und einer einfachen regelbasierten Lösung.
Die Zahl 20 steht hier für einen beispielhaften technischen Funktionstest, nicht für eine statistisch ausreichende Genauigkeitsstudie. Entdecke damit Integrationsfehler, bevor du eine größere Evaluation planst.
| Frage | Zu erhebender Nachweis | Entscheidung vor der Ausweitung |
|---|---|---|
| Ist das Ergebnis nützlich? | Richtige Zuordnungen, ungültige Ausgaben und Fälle mit menschlichem Prüfbedarf. | Akzeptable Fehlerquote und Eskalationsregel vorab festlegen. |
| Wird der gesamte Auftrag rechtzeitig fertig? | Gesamtdauer einschließlich Eingabeverarbeitung und aller Wiederholungen. | Die Frist des Arbeitsablaufs einhalten, nicht einen beliebigen Tokens/s-Wert. |
| Heißt rein lokal wirklich rein lokal? | Beobachtete Verbindungsziele und Verhalten bei gesperrtem externem Zugriff. | Keine undokumentierte externe Verarbeitung oder stille Cloud-Ausweichroute. |
| Kann das System seinen Auftrag überschreiten? | Ergebnisse verweigerter Schreibversuche und nicht verfügbarer Werkzeugaktionen. | Berechtigungen außerhalb des Modells durchsetzen. |
| Lässt es sich stoppen und wiederherstellen? | Abgeschlossener Stopptest und Wiederaufbau aus dokumentierten Artefakten. | Verantwortliche benennen und Wiederherstellung dokumentieren. |
Prüfe jede Sprache, die die Anwendung unterstützen muss. Eine viersprachige Website belegt keine viersprachige Modellqualität. Erfasse außerdem den maximalen Speicherbedarf und den manuellen Aufwand pro akzeptiertem Ergebnis.
Mit diesen Messwerten wird die Hardwareauswahl konkret. Unser llmfit-Leitfaden zur Hardwaredimensionierung behandelt diesen nächsten Schritt. Ein kleineres passendes Modell auf einem gepflegten Rechner kann der sinnvollere Pilot sein als ein verteilter Cluster. Entscheide anhand deiner Messungen.
Das Fazit: Kontrolliere die Grenzen, nicht die Schlagzeilen
Anthropics Warnung und der Reiz lokaler KI widersprechen sich nicht. Modelle außerhalb eines Rechenzentrums betreiben zu können, schafft gleichzeitig Möglichkeiten und Verantwortung.
Die sinnvolle Antwort lautet weder „lokale KI verbieten“ noch „alles harmlos, ist doch nur Edge Computing“. Mach Kontrolle prüfbar: Was läuft? Wohin gehen Daten? Welche Aktionen sind möglich? Wer kann sie stoppen? Wie lässt sich der Dienst ersetzen?
Betreibe deine KI selbst, wo Kontrolle einen echten Vorteil schafft. Prüfe ihr Verhalten, egal wo sie läuft.
Du hast einen konkreten Ablauf im Kopf? Beschreibe Wavect, was lokal bleiben muss und was das System erreichen soll. Datenverarbeitungsgrenze, erforderliche Antwortzeit und zulässige Aktionen sind ein besserer Ausgangspunkt für eine KI-Implementierung als eine Hardware-Einkaufsliste.
Quellen, Prüfdatum und Grenzen
Quellenprüfung: . Die verlinkte Forschung und offizielle Dokumentation stützen die berichteten Ergebnisse und Produktunterschiede. Wavect hat die Inferenz- oder Replikationsexperimente nicht selbst reproduziert. Zeit- und Boxenkostenbeispiele sind eigene Rechnungen mit den genannten Werten. Kontrollrahmen und Pilot sind redaktionelle Empfehlungen, keine gemessenen Kundenergebnisse.
Anthropics Experiment und lokale KI: Häufige Fragen
Hat Anthropic einen vollständig autonomen KI-Wurm auf TV-Boxen gezeigt?
Nein. Die Inferenzdemo auf TV-Boxen darf nicht mit der separaten kontrollierten Replikationsevaluation vermischt werden. Erstere zeigt, dass das verteilte Modell läuft, nicht dass es sich unkontrolliert repliziert.
Was bedeuten 0,39 Tokens pro Sekunde für eine Antwort?
Bei konstanter Geschwindigkeit benötigen 1.000 generierte Tokens ungefähr 42 Minuten und 44 Sekunden. Das ist eine Beispielrechnung ohne zusätzliche Eingabeverarbeitung, Werkzeuge, Wartezeiten und Wiederholungen.
Entstehen bei Pipeline-Parallelität auf 15 Geräten 15 Agenten?
Nein. Die Pipeline-Stufen arbeiten gemeinsam an einer Modellberechnung. Die Zahl beteiligter Geräte entspricht nicht der Zahl unabhängiger Modellkopien oder Agenten.
Sind 825 US-Dollar die gesamten Kosten des gezeigten lokalen KI-Systems?
Nein. Fünfzehn Boxen zu rund 55 US-Dollar ergeben etwa 825 US-Dollar allein für die Boxen. Der übrige Aufbau und laufende Betrieb sind darin nicht enthalten.
Ist eine lokal betriebene KI automatisch auf meine Interessen ausgerichtet?
Nein. Betriebskontrolle und verlässliches Verhalten sind unterschiedliche Fragen. Teste die Aufgabe, erzwinge Berechtigungen außerhalb des Modells und prüfe Datenwege sowie Abschaltung.
Was sollte ein Unternehmen vor dem Kauf eines lokalen KI-Clusters tun?
Teste eine begrenzte, rein lesende Aufgabe auf kontrollierten Geräten. Miss akzeptierte Ergebnisse, gesamte Bearbeitungsdauer, Speicher, externe Verbindungen und Wiederherstellung. Entscheide danach, ob andere Hardware nötig ist.