VIDRAFT stellt ViKernel Desktop als Demo vor: Betriebssystem und Kill-Switch sollen in der Modelldatei stecken
Die erste öffentliche Demo v0.1 liegt auf Hugging Face. Wie das Konzept technisch umgesetzt ist, bleibt offen. Ob es hält, hat bislang niemand unabhängig geprüft.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- VIDRAFT veröffentlichte die öffentliche Demo ViKernel Desktop v0.1 auf Hugging Face.
- Laut VIDRAFT sind ROM, RAM und eine xPU-Chip-Schaltung direkt in die Modellgewichte eingebaut.
- Die Demo zeigt in der Menüleiste Kernel-Zustand, Boot-Integrität und den Kopf der Audit-Kette.
- Laut Beschreibung sind Boot-Integrität, Policy-Engine, unveränderliche Audit-Kette und Kill-Switch gewichtsresident.
- Das 46-Mio-Parameter-Modell VKORE-46M-NPU wurde als Proof of Concept ausschließlich auf Inference-NPUs vortrainiert.
VIDRAFT bettet ROM, RAM und xPU-Schaltung in Modellgewichte ein
VIDRAFT hat mit ViKernel Desktop eine erste öffentliche Demo (v0.1) auf Hugging Face veröffentlicht. Sie ist als Space unter FINAL-Bench/ViKernel-Desktop erreichbar. Nach Angaben des Herstellers sollen ROM, RAM und eine xPU-Chip-Schaltung direkt in die Gewichte eines Modells eingebaut sein. Darauf laufe ein Secure OS. Das Betriebssystem wäre damit Teil der Modelldatei und läuft nicht daneben. Das Projekt nennt sich „Weight-Native OS“ und beschreibt einen Kill-Switch im Modell.
Die Demo zeigt in der Menüleiste den Kernel-Zustand, die Boot-Integrität und den Kopf der Audit-Kette. Daneben stehen die Bedienelemente KILL und RESUME. Ein Panel stellt dar, was in einer einzelnen Modelldatei enthalten sein soll.
Das Unternehmen gilt als koreanisches Startup. Laut einem Bericht auf dev.to hat es das 46-Millionen-Parameter-Modell VKORE-46M-NPU als Proof of Concept ausschließlich auf Inference-NPUs vortrainiert, ohne NVIDIA-GPUs.
Vier Kontrollen sollen mit der Datei wandern, der Kill-Switch gilt für alle
Laut Beschreibung sind vier Eigenschaften gewichtsresident: Boot-Integrität, Policy-Engine, unveränderliche Audit-Kette und Kill-Switch. Sie sollen mit der Modelldatei wandern. Externe Wrapper, Proxys oder Prompt-Filter lassen sich abtrennen. Die Kontrollen sollen dagegen auch dann erhalten bleiben, wenn ein umgebender Container verworfen wird. Das ist die Darstellung des Herstellers. Belegt ist sie nicht.
Zur Kill-Switch-Logik heißt es in einem Text, der VIDRAFT als Partner nennt: Den Halt kann jeder auslösen. Danach wird jede Aktionsanfrage abgelehnt, unabhängig von ihrem Inhalt. Fortgesetzt werden kann nur mit einem signierten Operator-Schlüssel. Der Kill-Switch sei eine Schaltung und kein Verhalten. Die Beschreibung richtet sich an Betreiber agentischer Systeme, in denen Modelle Werkzeuge aufrufen, Dateien schreiben und Anfragen senden. Der Partnertext ist im vorliegenden Material abgeschnitten. Die Erläuterung, wie der Schalter durchgesetzt wird, fehlt deshalb.
Unverifiziert: Hardware oder kodierte Schaltung, und kein unabhängiger Test
Belegt ist, dass die Demo existiert und was der Hersteller behauptet. Ob die Kontrollen halten, ist nicht belegt. VIDRAFT versichert, sie ließen sich weder durch Kopieren der Gewichte entfernen noch durch Adversarial Prompting umgehen. Eine Prüfung dazu liegt nicht vor.
Auch die Begriffe sind uneinheitlich. Eine Zusammenfassung spricht von einem hardware-level Kill-Switch. Die Herstellerquelle beschreibt dagegen eine in die Gewichte verdrahtete Schaltung aus ROM, RAM und xPU-Chip-Schaltung. Physische Hardware nennt das Material nicht. Format, Loader und Hardware-Bezug sind nicht offengelegt.
Prüfen ließe sich der Anspruch so: Gewichte kopieren, verändern oder neu quantisieren und testen, ob Kill-Switch, Policy und Audit-Kette erhalten bleiben. Ebenfalls denkbar sind Red-Teaming mit Prompt-Angriffen und die Offenlegung der Implementierung.



