Über uns — das Instrument, das der Wissenschaft fehlte

Abstract

Scellis behandelt eine Berechnung als etwas, das du zusammensetzen, prüfen, teilen und erneut ausführen kannst. Eine kleine, stabile Engine läuft im Browser-Tab; jede Fähigkeit — Blöcke, Modelle, GPU-Code, Viewer, Konnektoren — kommt aus einem Katalog und läuft auf der Hardware, die du schon hast. Es gibt nichts zu installieren und nichts, was du hochladen müsstest. Menschen und Geräte können sich derselben Arbeit anschließen, und jedes committete Ergebnis lässt sich aus seinem Link erneut ausführen.

§1 · Warum es Scellis gibt

Der Umweg zwischen Frage und Antwort

Für die meisten Menschen bedeutet eine echte Berechnung immer noch einen Umweg. Ein Nachmittag verschwindet in einer Installation, die sich mit dem Betriebssystem streitet. Eine Cloud-Rechnung zählt jede GPU-Stunde. Die Rechtsabteilung sagt, die Daten dürfen das Haus nicht verlassen. Und — am leisesten und schädlichsten — ist das Ergebnis eines, das niemand sonst reproduzieren kann, weil die Umgebung, die es erzeugt hat, längst weg ist. Nichts davon ist Wissenschaft. Es ist die Steuer, die du zahlst, um überhaupt einen Computer anzufassen.

Scellis ist eine Wette auf eine Verschiebung, an der die meisten vorbeigelaufen sind. Der Browser wurde still und leise zur universellsten Laufzeitumgebung, die wir haben — und mit WebGPU zu einer echten Rechenplattform, die die Grafikkarte erreicht, die ohnehin schon in der Maschine vor dir steckt. Darin liegt die ganze Chance: Wenn Training, nicht nur Wiedergabe, in einem Tab laufen kann, war der Umweg über das Rechenzentrum nie zwingend. Berechnung bleibt standardmäßig lokal — kein Modus, den du erst einschaltest.

Abb. 1 — Der übliche Weg zu einer echten Berechnung ist eine Kette von Umwegen. Im Browser-Tab fällt sie in sich zusammen: Workflow zeichnen, auf der Grafikkarte trainieren, die ohnehin im Rechner steckt, einen Link teilen, der ihn exakt erneut ausführt — dein Team am selben Workflow, seine Geräte an derselben Aufgabe.

Was das bringt, ist täuschend einfach. Du öffnest einen Tab: keine Installation, keine Warteschlange, kein Upload. Du zeichnest einen Workflow, drückst auf Run, und er trainiert auf deiner eigenen GPU. Du teilst das Ergebnis als Link, und ein Kollege auf einem anderen Kontinent führt dieselbe Berechnung auf seiner Hardware erneut aus — reproduzierbar per URL, nicht per Screenshot. Und wenn eine Maschine nicht reicht, verteilt sich dieselbe Aufgabe auf die Geräte, die du erreichst. Die schwere Maschinerie ist immer noch da. Sie steht dir nur nicht mehr im Weg.

Wir bauen Scellis, weil Werkzeuge entscheiden, welche Wissenschaft einfach ist — und einfache Wissenschaft ist die, die tatsächlich passiert. Mach rigorose, reproduzierbare, teilbare Berechnung zum Weg des geringsten Widerstands, und es passiert mehr davon — von mehr Menschen, an mehr Orten. Das ist der ganze Ehrgeiz: keine schnellere GPU, sondern eine niedrigere Schwelle, mit der ganzen Plattform an dem einen Ort, den ohnehin alle offen haben.

§2 · Was wir bauen

Eine kleine Engine — und alles Übrige als Content

Die kompilierte Anwendung bringt fast nichts mit. Das ist der Punkt.

Was wir kompilieren und ausliefern, ist eine kleine Engine. Sie weiß, wie man einen gezeichneten Workflow in Code verwandelt, den deine Grafikkarte ausführen kann, wie man diesen Code gegen eine Referenzimplementierung prüft, ein Modell trainiert und die Regeln durchsetzt. Sie weiß bewusst nicht, was irgendein wissenschaftliches Fachgebiet ist. Alles Domänenförmige — Blöcke, Modelle, GPU-Code, Viewer, Datensätze, Konnektoren — ist Content aus einem Katalog, auf deinem Gerät zwischengespeichert und nie fest in ein App-Release eingebaut.

Diese eine Zeile ist die ganze Architektur. Weil Fähigkeit in Content steckt, kannst du genau das erstellen, was auch wir erstellen — bis hinunter zum GPU-Code und den Gradientenregeln — und die Engine kann deine Arbeit im Moment der Ausführung nicht von unserer unterscheiden. Du schreibst kein Plugin am Rand des Programms eines anderen. Eine fehlende Fähigkeit ist nie eine Warteschlange, in der du stehst; sie ist Content, den du — oder jemand vor dir — hinzufügen kann.

Das Ergebnis ist eine Plattform, die schneller wachsen kann, als ein einzelnes Team sie bauen könnte: Mehr Menschen erstellen mehr Content, die Basis wird fähiger, und es kommen mehr Menschen. Viele davon arbeiten gleichzeitig auf derselben Canvas, und viele Geräte können ihre Rechenleistung an einem Workflow bündeln. Wir halten die Engine klein und korrekt; alles, was darauf aufbaut, bleibt offen.

§3 · Prinzipien

Vier Zusagen, die die Technik hält

Keine Werte an der Wand — Eigenschaften des Systems, die meisten automatisch geprüft.

Prinzip	Was es bedeutet
Erweiterbarkeit	Fähigkeit wächst durch Content, nie durch ein Engine-Release. Der Kern bleibt bewusst klein; was du damit bauen kannst, nicht — selbst erstellte Kernels, Ops und Gradientenregeln laufen durch genau dieselben Prüfungen wie unsere.
Privatsphäre	Berechnung und Rohdaten bleiben durch Konstruktion auf deinem Gerät, nicht durch eine Richtlinie. Was das Gerät verlässt, ist ein deklarierter Effekt mit Zustimmung — nie stillschweigend — und Konnektor-Zugangsdaten sind auf dem Gerät verschlüsselt und werden nie synchronisiert.
Reproduzierbarkeit	Jeder committete Lauf hat eine content-adressierte Identität: Derselbe Link löst dieselben Eingaben erneut auf und führt dieselbe Berechnung erneut aus — über verschiedene GPUs hinweg innerhalb einer deklarierten Toleranz übereinstimmend, bitgenau auf dem Referenzpfad.
Ehrlichkeit statt falschem Trost	Wo die Plattform etwas nicht kontrollieren kann, sagt sie es. Grenzen werden veröffentlicht, Einbrüche werden angesagt statt versteckt, und jede Garantie wird zusammen mit der Grenze genannt, an der sie endet.

Diese letzte Zeile ist eine Regel, an die wir uns halten. Wir veröffentlichen eine Seite — ehrliche Grenzen — die in klarer Sprache auflistet, was Scellis genau nicht kann und wo jede Garantie endet. Ein Versprechen, das du prüfen kannst, ist mehr wert als eines, dem du vertrauen musst — und diese Grenze zu ziehen ist, wie sich ein Instrument seinen Platz in der Wissenschaft verdient.

§4 · Der Weg

Drei Meilensteine, der Reihe nach

Gemeinsam rechnen ist das Ziel — drei Meilensteine, jeder im selben Atemzug mit seinen ehrlichen Grenzen genannt, keiner auf ein Datum festgelegt.

01
Föderierte Netzwerke
Viele Standorte trainieren ein Modell, während die Rohdaten kein Gerät verlassen. Die ehrliche Grenze kommt im selben Atemzug: Modell-Updates verlassen das Gerät sehr wohl, und ein Update kann Informationen über die dahinterliegenden Daten preisgeben — deshalb sind bilanzierte Differential Privacy und Clipping hier eine stets aktive Untergrenze, keine Option, und das läuft in zugelassenen Konsortien, nie in einem offenen Pool von Fremden.
02
Crowdsourced Compute
Ungenutzte Laptops, Tablets und Handys verschmelzen zu einem Cluster, der jede Arbeitslast ausführt, die sich in unabhängige Teile zerlegen lässt — Parameter-Sweeps, Simulationen, Batch-Analysen, nicht nur Training. Nur Geräte im Vordergrund und am Netzteil tragen bei: Ein eingefrorener Hintergrund-Tab rechnet nicht, und wir tun nie so, als ob. Bei Arbeit, die sich sauber zerlegen lässt, ist die Beschleunigung nahezu linear; synchronisiertes Training wird vom langsamsten Teilnehmer gebremst.
03
Ein Markt für Rechenzeit
Flotten vermieten ungenutzte GPU-Zeit und werden für verifizierte Arbeit bezahlt — nur dedizierte, am Netzteil hängende Maschinen, bei denen ein Beitrag ausschließlich zählt, wenn die Verifikation besteht. Das ist ein Markt für Rechenzeit, nicht der Content-Marktplatz, auf dem Packs und Modelle verkauft werden; beides ist nie dasselbe. Freiwilliges Pooling und der fälschungssichere Nachweis jedes angenommenen Beitrags sind gebaut; der bepreiste Markt kommt als eine unteilbare Einheit mit seinen Betrugsbremsen — oder gar nicht.

Alle drei sind ein Mechanismus, keine drei Produkte: eine partitionierte, verifizierte Aufgabe unter drei Vertrauensregimen — deine eigenen Geräte, ein zugelassenes Konsortium, ein offener Pool von Fremden — die nie zu einem verschwimmen. Die Seite verteiltes Rechnen sagt genau, wie weit jedes reicht und wo es aufhört.

§5 · Wer es baut

Ein kleines Team, eine ungewöhnliche Kombination

Scellis wird in Deutschland von einem kleinen Team gebaut. Die Engine wurde von einer Person von Grund auf entworfen und geschrieben — einem Machine-Learning-Ingenieur an Helmholtz Munich und der Technischen Universität München — und das wissenschaftliche Urteil dahinter kommt von einem der meistzitierten Wissenschaftler Europas im maschinellen Lernen für die Wissenschaften, einem Leibniz-Preisträger. Das Erste ist der Grund, warum das System bis in die Grundfesten kohärent ist; das Zweite, warum seine Korrektheitsaussagen Fehlerbalken tragen.

Willst du die Mechanik statt der Geschichte, führt dich die Dokumentation vom ersten Workflow bis hinunter zu dem, was die Engine darunter tut — und die Feldnotizen zeigen die Plattform bei echter Arbeit. Wer sie baut, steht eine Seite weiter.