Projetando o Flux Engine: um runtime para todo produto

Um runtime, não um wrapper

Construir um app no dispositivo é difícil. Construir cinco é mais difícil. Construir cinco que compartilhem uma fundação técnica coerente, lancem updates no mesmo passo e nunca regridam em bateria — esse é problema de runtime.

Flux Engine é a nossa resposta. Uma camada fina e opinativa por cima dos melhores runtimes open source de cada faixa — voz (whisper.cpp / faster-whisper), visão (llama.cpp / mlx-vlm), linguagem (llama.cpp / MLC-LLM, executorch no Android) — coordenada por um único scheduler que sabe o que está em memória, o que o usuário está fazendo e o quanto o dispositivo aguenta.

As três restrições

1. Latência de cold start

Os modelos vivem em disco a maior parte do tempo. O usuário não. Flux Engine pré-aquece o modelo mais provável de ser chamado a seguir, com base nos padrões de uso do app e em um pequeno classificador no dispositivo. O classificador em si é um MLP de 50 KB — leve o bastante para rodar a cada wake.

2. Throughput sustentado em NPUs pequenas

Nunca disparamos cargas paralelas que disputam o mesmo acelerador. O scheduler é baseado em filas, sabe prioridades e cede o passo à app em primeiro plano. Stream de ASR tem prioridade sobre um resumo em background; tap-to-translate tem prioridade sobre uma passagem de indexação.

3. Degradação graciosa quando há pouca memória

Se o usuário está editando vídeo 4K, não vamos derrubar o telefone com OOM por causa de um resumo. O motor reporta um sinal soft de "capacidade restante" que os produtos respeitam — podem cair para um modelo menor, adiar para o background, ou exibir "pronto quando o aparelho esfriar".

O que o Flux Engine realmente expõe

Um punhado de abstrações C++ e bindings finos em Swift / Kotlin / Rust:

• FluxSession — sessão de inferência de vida longa atrelada a modelo + dispositivo.
• FluxStream — saída incremental, cancelável no meio do token.
• FluxBudget — relatório de capacidade ciente do dispositivo.
• FluxRouter — escolhe o modelo certo baseado em faixa do dispositivo, bateria, estado térmico e preferência do produto.

É isso. Cinco primitivas. Cada produto Flux* se constrói em cima disso.

O que isso nos dá

Um bug fix, um ganho de performance, uma melhora de quantização — cinco produtos melhoram ao mesmo tempo. Um fix de regressão no scheduler — cinco produtos param de bater pico de bateria ao mesmo tempo. A conta econômica de um runtime compartilhado, para uma equipe do nosso tamanho, é esmagadora.

O que erramos

• Investimos demais num compilador de grafos nos primeiros seis meses. Os loaders ajustados a mão venceram.
• Investimos de menos em profiling. Reescrevemos no nono mês.
• Assumimos um esquema único de quantização para todos os produtos. Hoje entregamos misturas por produto.