Blas nicht länger nur über Rechenleistung—das Nadelöhr dezentraler KI ist das Hosting der „dreckigen Arbeit“
Letzten Monat wollte ich fünf vertikale Kleinstmodelle im Batch auf eine dezentrale Plattform ausrollen. Ergebnis: Geschraubt bis 2 Uhr nachts—und am Ende lag der Grund dafür, dass es komplett abgestürzt ist, an einem einzigen Buchstaben: In den Umgebungsvariablen stimmte die Groß-/Kleinschreibung nicht. In dem Moment habe ich es verstanden: Ganze drei Tage, 80% der Zeit waren dabei, die Plattform als „menschlicher Adapter“ anzupassen. Echtes Business-Testing waren am Ende keine zwei Stunden. In diesem Bereich fehlt nicht die Rechenleistung, sondern eine Hosting-Pipeline, die dich „blind übergeben lässt, automatisch durchreicht“
Als ich dann die HACA-Architektur von OpenGradient auseinandergenommen habe, dachte ich mir: Da ist wirklich jemand an vorderster Linie operativ mitgegangen. Er hat etwas getan, das extrem unsexy ist, aber rettet Leben: Er hat das Modell so verpackt, dass es zu einer standardisierten Pipeline wird. Der Kern ist diese Adaptionsebene—so wie ich es verstehe, bildet sie die Operatoren verschiedener Frameworks wie PyTorch und ONNX hart auf einen einheitlichen Zwischen-Output (IR) ab. Das ist wie ein „Universalübersetzer“: Du gibst ihm jedes Format, und er macht daraus die allgemeine Sprache, die die Plattform versteht. Die Scheduling-Schicht ist noch cleverer: Sie zerlegt den Berechnungsgraphen automatisch anhand der Modellparametergröße—bei großen Modellen auf High-VRAM-Karten, bei kleinen auf Knoten mit geringer Rechenleistung. Ich muss keine Modelle manuell auswählen. Und das Plug-in-Design bedeutet: Wenn künftig etwa Mamba als neue Architektur kommt, hängt man einfach ein Plug-in dran, und die darunterliegende Scheduling-Engine muss gar nicht geändert werden. Das spart uns als Team, das viele Modelle im Batch laufen lässt, nicht nur Zeit—sondern auch Haare. #OPG
Natürlich nicht so tun, als wäre das Magie. Wenn man gleichzeitig über hundert Modelle anhängt, wird der Speicheraufwand und die Lizenzprüfung natürlich gnadenlos entlarvt—die offiziellen Stellen haben bisher auch noch keine perfekte Lösung dafür. Das muss man weiter im Blick behalten: $OPG
Aber mein Urteil ist ziemlich klar: Die Plattformen, die jeden Tag nur Benchmark-Daten abscannen, werden innerhalb von zwei Jahren sehr wahrscheinlich von Infrastruktur mit starken Hosting-Fähigkeiten „niedergedrückt“ werden. Der Grund ist simpel—Rechenleistung kann man mit Geld stapeln, aber „standardisiertes Batch-Hosting“ ist eine Aufgabe, die Empathie mit Entwicklern braucht. OpenGradient liegt mit der Richtung richtig. Wenn das nächste Schritt bei Storage und Lizenzen wirklich landet, schneide ich mein Hauptmodell sofort dorthin um. Investieren ist genauso: Nicht an PPT glauben—glaub an die „nicht nervöse“ Erfahrung, wenn du es wirklich selbst ausrollst. Genau das ist die harte Wahrheit für das Überdauern über den Zyklus hinweg. @OpenGradient
Letzten Monat wollte ich fünf vertikale Kleinstmodelle im Batch auf eine dezentrale Plattform ausrollen. Ergebnis: Geschraubt bis 2 Uhr nachts—und am Ende lag der Grund dafür, dass es komplett abgestürzt ist, an einem einzigen Buchstaben: In den Umgebungsvariablen stimmte die Groß-/Kleinschreibung nicht. In dem Moment habe ich es verstanden: Ganze drei Tage, 80% der Zeit waren dabei, die Plattform als „menschlicher Adapter“ anzupassen. Echtes Business-Testing waren am Ende keine zwei Stunden. In diesem Bereich fehlt nicht die Rechenleistung, sondern eine Hosting-Pipeline, die dich „blind übergeben lässt, automatisch durchreicht“
Als ich dann die HACA-Architektur von OpenGradient auseinandergenommen habe, dachte ich mir: Da ist wirklich jemand an vorderster Linie operativ mitgegangen. Er hat etwas getan, das extrem unsexy ist, aber rettet Leben: Er hat das Modell so verpackt, dass es zu einer standardisierten Pipeline wird. Der Kern ist diese Adaptionsebene—so wie ich es verstehe, bildet sie die Operatoren verschiedener Frameworks wie PyTorch und ONNX hart auf einen einheitlichen Zwischen-Output (IR) ab. Das ist wie ein „Universalübersetzer“: Du gibst ihm jedes Format, und er macht daraus die allgemeine Sprache, die die Plattform versteht. Die Scheduling-Schicht ist noch cleverer: Sie zerlegt den Berechnungsgraphen automatisch anhand der Modellparametergröße—bei großen Modellen auf High-VRAM-Karten, bei kleinen auf Knoten mit geringer Rechenleistung. Ich muss keine Modelle manuell auswählen. Und das Plug-in-Design bedeutet: Wenn künftig etwa Mamba als neue Architektur kommt, hängt man einfach ein Plug-in dran, und die darunterliegende Scheduling-Engine muss gar nicht geändert werden. Das spart uns als Team, das viele Modelle im Batch laufen lässt, nicht nur Zeit—sondern auch Haare. #OPG
Natürlich nicht so tun, als wäre das Magie. Wenn man gleichzeitig über hundert Modelle anhängt, wird der Speicheraufwand und die Lizenzprüfung natürlich gnadenlos entlarvt—die offiziellen Stellen haben bisher auch noch keine perfekte Lösung dafür. Das muss man weiter im Blick behalten: $OPG
Aber mein Urteil ist ziemlich klar: Die Plattformen, die jeden Tag nur Benchmark-Daten abscannen, werden innerhalb von zwei Jahren sehr wahrscheinlich von Infrastruktur mit starken Hosting-Fähigkeiten „niedergedrückt“ werden. Der Grund ist simpel—Rechenleistung kann man mit Geld stapeln, aber „standardisiertes Batch-Hosting“ ist eine Aufgabe, die Empathie mit Entwicklern braucht. OpenGradient liegt mit der Richtung richtig. Wenn das nächste Schritt bei Storage und Lizenzen wirklich landet, schneide ich mein Hauptmodell sofort dorthin um. Investieren ist genauso: Nicht an PPT glauben—glaub an die „nicht nervöse“ Erfahrung, wenn du es wirklich selbst ausrollst. Genau das ist die harte Wahrheit für das Überdauern über den Zyklus hinweg. @OpenGradient