§ Über uns
Das Instrument, das der Wissenschaft gefehlt hat.
Scellis ist eine browser-native, local-first Plattform für wissenschaftliches Rechnen: Du zeichnest einen Workflow, und die Engine kompiliert ihn zu Code, der auf der Grafikkarte trainiert, die ohnehin in deinem Rechner steckt — dein Team am selben Workflow, seine Geräte als nächster Meilenstein an derselben Aufgabe, jedes Ergebnis darauf gebaut, aus einem Link erneut zu laufen. Das ist die Geschichte, warum wir sie bauen.
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 können sich derselben Arbeit schon live anschließen, Geräte an derselben Aufgabe sind im aktiven Aufbau, und ein fertiger Lauf reist schon als Link ohne Login, der seine eingefrorenen, per Hash adressierten Metriken und Abbildungen trägt — der Link, der einen ganzen committeten Workflow erneut ausführt, wird gerade noch ins Studio eingebunden.
§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.
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: Heute trägt er die eingefrorenen, per Hash adressierten Metriken und Abbildungen des fertigen Laufs, und er wird gerade so eingebunden, dass ein Kollege auf einem anderen Kontinent dieselbe Berechnung auf seiner Hardware erneut ausführt — reproduzierbar per URL, nicht per Screenshot. Und wenn eine Maschine nicht reicht, soll sich dieselbe Aufgabe auf die Geräte verteilen, die du erreichst — daran bauen wir gerade. 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 dass viele Geräte ihre Rechenleistung an einem Workflow bündeln, ist im Aufbau. 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 ist darauf gebaut, dieselben Eingaben erneut aufzulösen und dieselbe Berechnung erneut auszuführen — über verschiedene GPUs hinweg innerhalb einer deklarierten Toleranz übereinstimmend, bitgenau auf dem Referenzpfad. Das erneute Ausführen aus dem Link im Studio wird gerade noch eingebunden. |
| 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 als stets aktive Untergrenze ausgelegt, keine Option — eine Untergrenze, die noch nicht in Kraft ist —, 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. Beitragen ist auf ein Gerät im Vordergrund und am Netzteil ausgelegt: Ein eingefrorener Hintergrund-Tab rechnet nicht, und wir tun nie so, als ob. Bei Arbeit, die sich sauber zerlegen lässt, ist die Beschleunigung erwartungsgemäß nahezu linear — ein Modell, noch keine Messung über Browser hinweg; 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. Der Koordinator für freiwilliges Pooling und der fälschungssichere Nachweis jedes angenommenen Beitrags sind gebaut und getestet, auch wenn noch kein Browser gepoolte Arbeit Ende zu Ende ausgeführt hat; 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.