Flux Engine bauen: eine Runtime für jedes Produkt
Ein Blick hinter die Architekturentscheidungen unserer gemeinsamen On-Device-Inference-Runtime — und auf die Zwänge, die sie geformt haben.
Eine Runtime, kein Wrapper
Eine App on-device zu bauen ist schwer. Fünf zu bauen ist schwerer. Fünf zu bauen, die ein gemeinsames technisches Fundament teilen, im Gleichschritt Updates ausliefern und nie bei der Akkulaufzeit zurückfallen — das ist ein Runtime-Problem.
Flux Engine ist unsere Antwort. Eine dünne, meinungsstarke Schicht über den besten Open-Source-Runtimes ihrer Spuren — Sprache (whisper.cpp / faster-whisper), Vision (llama.cpp / mlx-vlm), Language (llama.cpp / MLC-LLM, executorch unter Android) — koordiniert von einem einzigen Scheduler, der weiß, was gerade im Speicher liegt, was der Nutzer tut und wie viel das Gerät noch tragen kann.
Die drei Zwänge
1. Cold-Start-Latenz
Modelle leben die meiste Zeit auf der Platte. Der Nutzer nicht. Flux Engine wärmt das wahrscheinlich nächste Modell anhand des App-Nutzungsmusters und eines kleinen On-Device-Klassifikators vor. Der Klassifikator selbst ist ein 50 KB großes MLP — günstig genug, um bei jedem Aufwachen zu laufen.
2. Anhaltender Durchsatz auf kleinen NPUs
Wir starten nie parallele Lasten, die um denselben Beschleuniger streiten. Der Scheduler ist warteschlangenbasiert, prioritätsbewusst und tritt zugunsten der Vordergrund-App hart zurück. ASR-Streams haben Vorrang vor Hintergrundzusammenfassungen; Tap-to-Translate hat Vorrang vor einem Hintergrund-Indexierungslauf.
3. Sanftes Degradieren bei wenig Speicher
Wenn der Nutzer ein 4K-Video schneidet, OOM-en wir sein Telefon nicht für eine Zusammenfassung. Die Engine meldet ein weiches Signal "verbleibende Kapazität", an das sich Produkte halten — Features können auf ein kleineres Modell fallen, in den Hintergrund vertagt werden oder ein "fertig, sobald das Gerät abgekühlt ist" anzeigen.
Was Flux Engine wirklich exponiert
Eine Handvoll C++-Abstraktionen und dünne Swift / Kotlin / Rust-Bindings:
FluxSession— langlebige Inference-Session, an Modell + Gerät gebunden.FluxStream— inkrementelle Ausgabe, mitten im Token abbrechbar.FluxBudget— geräteabhängiger Kapazitätsbericht.FluxRouter— wählt das passende Modell anhand von Geräteklasse, Akku, Thermikzustand und Produktpräferenz.
Mehr nicht. Fünf Primitive. Jedes Flux*-Produkt baut darauf auf.
Was uns das bringt
Ein Bugfix, ein Performance-Gewinn, eine Quantisierungsverbesserung — fünf Produkte werden gleichzeitig besser. Ein Regressionsfix im Scheduler — fünf Produkte hören gleichzeitig auf, den Akku zu spiken. Der ökonomische Fall für eine gemeinsame Runtime ist in einem Team unserer Größe erdrückend.
Was wir falsch gemacht haben
- Wir haben in den ersten sechs Monaten zu viel in einen Graph-Compiler investiert. Hand-getunte Modell-Loader gewannen.
- Wir haben zu wenig in Profiling investiert. Im neunten Monat neu geschrieben.
- Wir nahmen ein einheitliches Quantisierungsschema über Produkte hinweg an. Heute liefern wir Mischungen pro Produkt aus.