Wie ich ein Deep-Learning-Framework in Rust von Grund auf neu entwickelte

Die Entwicklung eines eigenen Deep-Learning-Frameworks ist eine ambitionierte Aufgabe, die nicht nur technisches Know-how, sondern auch Disziplin und Ausdauer erfordert. Ein Softwareentwickler hat genau das getan und in mehreren Phasen ein Framework in Rust von Grund auf neu aufgebaut. Der Prozess begann mit einer kritischen Bestandsaufnahme: Der ursprüngliche Code funktionierte zwar technisch, war aber weder wartbar noch für andere Entwickler nutzbar. Doch statt das Projekt aufzugeben, setzte er sich klare Ziele und durchlief systematisch mehrere Entwicklungsphasen – mit beeindruckenden Ergebnissen.

Von 142 Warnungen zu einem sauberen Build

Der erste Schritt bestand darin, die Codebasis von Grund auf zu bereinigen. Ein einfacher Befehl reichte aus, um das Ausmaß des Problems zu offenbaren: cargo build --release --all-targets spuckte 142 Warnungen aus. Doch statt sich von der Menge überfordern zu lassen, analysierte der Entwickler die Ursachen systematisch. Viele Warnungen entstanden durch redundante Moduldeklarationen in der Hauptdatei, die dazu führten, dass der gesamte Code mehrfach kompiliert wurde. Die Lösung war simpel, aber effektiv: Die Modulimports wurden durch direkte Abhängigkeiten ersetzt, wodurch sofort rund 100 falsch-positive Warnungen verschwanden.

Die verbleibenden Warnungen betrafen echte Probleme wie veraltete Funktionen, ungenutzte Variablen und inkonsistente Initialisierungen. Besonders auffällig war eine Funktion namens rotate_half, die in der RoPE-Implementierung (Rotary Position Embedding) lediglich einen Cosinus-Bias hinzufügte – eine unvollständige Lösung, die später korrigiert werden musste. Der Entwickler kommentierte den Code entsprechend, um zukünftige Nutzer vor Fehlinterpretationen zu warnen:

/// **STUB-IMPLEMENTIERUNG.** Die vollständige RoPE-Implementierung erfordert Slice- und Concat-Operationen, \
/// um die head_dim in Paare zu unterteilen. Der aktuelle Code fügt lediglich `cos` als Bias hinzu — \
/// dies ist **mathematisch nicht korrekt** für RoPE und muss vor der Produktivnutzung behoben werden.
fn rotate_half(&self, x: &Tensor, _seq_offset: usize) -> Tensor {
    // Implementierung...
}

Nach Abschluss dieser Phase war der Build-Prozess frei von Warnungen – ein wichtiger Meilenstein für die Stabilität des Frameworks.

Ein API-Design, das Entwickler nicht enttäuscht

Die größte Herausforderung bestand jedoch nicht in der Codebereinigung, sondern in der Neugestaltung der API. Der ursprüngliche Ansatz erforderte, dass Nutzer Parameterformen manuell über HashMaps zuweisen mussten – ein fehleranfälliger und unübersichtlicher Prozess. Die Lösung war eine deklarative API, bei der Layer ihre eigenen Forminformationen verwalten. Jede Schicht registriert sich nun automatisch im GraphContext und übernimmt die Verantwortung für ihre Parameterinitialisierung.

Die neue API vereinfacht die Nutzung erheblich. Statt komplexer String-Vergleiche wie if name.contains("w_q") zu nutzen, können Entwickler nun dimensionsbasiert arbeiten:

pub fn new(ctx: &Rc<RefCell<GraphContext>>, name: &str, in_f: usize, out_f: usize) -> Self {
    let weights = Tensor::new_parameter_with_shape(
        ctx,
        &format!("{name}.weights"),
        vec![in_f, out_f],
        Initializer::XavierUniform,
    );
    // ...
}

Hinter den Kulissen verwaltet der GraphContext nun eine Metadatenbank für Parameter, die Form, Datentyp und Initialisierungsmethode speichert. Zwei neue Methoden ergänzen das System:

• ctx.build_shape_map(&input_shapes) – führt die Forminferenz durch
• ctx.init_parameters(&mut runtime_data) – initialisiert die Gewichte

Die Auswirkungen auf die Codequalität waren dramatisch. Ein Beispielprojekt reduzierte sich von 275 auf 190 Zeilen, während die Lesbarkeit erhalten blieb. Die manuelle Formverwaltung entfiel vollständig – ein entscheidender Schritt für die Nutzbarkeit des Frameworks.

GPU-Berechnungen endlich vollständig umgesetzt

Ein häufiges Missverständnis betraf die GPU-Unterstützung. Die Dokumentation behauptete zwar „✅ GPU-Backend“, doch in der Praxis scheiterten viele Operationen mit Fehlermeldungen wie:

thread 'main' panicked: UnimplementedOperation("node type not supported on GPU: LayerNorm { input: 0, gamma: 10, beta: 11, eps: 1e-5 }")

Die Ursache lag darin, dass LayerNorm nicht als zusammengesetzte Operation, sondern als spezialisierter Knotentyp implementiert war – für den es bisher keine WGSL-Shader gab. Dies erforderte die Entwicklung von vier separaten Shadern:

• LayerNorm (Vorwärtsberechnung) – ein Worker pro Zeile
• LayerNormBackward (Rückwärtsberechnung) – zwei Reduktionsdurchläufe pro Zeile

Die Rückwärtsberechnung war besonders anspruchsvoll, da sie die Formel dx = inv_std * (dy·γ - mean(dy·γ) - x_norm·mean(dy·γ·x_norm) implementieren musste. Die Entwicklung dieser Shader war ein kritischer Schritt, um die GPU-Unterstützung tatsächlich nutzbar zu machen.

Ein Framework reift zur ersten stabilen Version heran

Nach sechs Entwicklungsphasen, mehreren Versionssprüngen (v0.2.0 → v0.3.1) und unzähligen Codezeilen war das Ergebnis ein Framework, das nicht nur technisch funktioniert, sondern auch für andere Entwickler attraktiv ist. Die Version 0.3.1 umfasst:

• Eine vollständig bereinigte Codebasis ohne Warnungen
• Eine intuitive, deklarative API mit integrierter Formverwaltung
• Vollständige GPU-Unterstützung durch spezialisierte Shader
• Standardisierte Initialisierungsmethoden wie Xavier, Kaiming und Normalverteilung
• Beispielprojekte, die die Nutzung demonstrieren

Die nächste Version (v0.5) wird sich auf Performance-Optimierungen konzentrieren – ein Schritt, der bewusst aufgeschoben wurde, um zunächst eine stabile und nutzbare Basis zu schaffen. Für Entwickler, die nach einer Rust-basierten Alternative zu etablierten Frameworks suchen, könnte dies der Beginn einer vielversprechenden Reise sein.

Die Entwicklung eines Deep-Learning-Frameworks ist ein Marathon, kein Sprint. Doch wer wie dieser Entwickler Disziplin, Systematik und eine klare Vision verfolgt, kann am Ende nicht nur ein funktionierendes Produkt, sondern auch eine Community von Nutzern und Mitentwicklern aufbauen.