O LiteRT entrou de vez em “modo produção”, com as capacidades avançadas de aceleração já integradas ao stack oficial e liberadas para todos os desenvolvedores. A proposta é bem direta: levar a IA moderna para rodar localmente, no aparelho, com desempenho e fluxo de trabalho mais simples do que era comum na era do TFLite.
Na prática, o LiteRT se posiciona como um salto em relação ao que o TensorFlow Lite (TFLite) representava para ML “clássico”. A ideia é repetir a mesma facilidade de antes, só que agora para modelos mais avançados e casos de uso mais exigentes.
- Mais rápido: até 1,4x mais performance em GPU do que o TFLite e com aceleração moderna em NPU.
- Mais simples: um fluxo unificado para acelerar em GPU e NPU em plataformas “edge”.
- Mais poderoso: caminho mais forte para rodar GenAI com modelos abertos como Gemma.
- Mais flexível: suporte de primeira linha a PyTorch e JAX via conversão de modelos.
O recado por trás disso tudo é bem claro: menos dependência da nuvem e mais IA funcionando no próprio dispositivo, com mais velocidade e menor latência 🔥
Quem quiser ler o texto original do anúncio pode acessar: https://goo.gle/4bTwIPa
Aceleração em GPU agora é multiplataforma (e mais “esperta”)
Um dos pontos centrais do LiteRT é que o suporte de GPU deixa de ficar preso a um cenário mais limitado e passa a ser completo em Android, iOS, macOS, Windows, Linux e Web. Isso muda o jogo porque, em vez de ficar no CPU inference (que é mais lento), o app pode escalar para aceleração de hardware de forma mais consistente.
Esse alcance maior vem com suporte robusto a OpenCL, OpenGL, Metal e WebGPU, usando o motor de GPU de próxima geração chamado ML Drift. No Android, ainda tem um detalhe prático: o LiteRT prioriza automaticamente OpenCL quando disponível para desempenho máximo e cai para OpenGL quando precisa cobrir mais aparelhos.
Em eficiência, o ganho médio citado é de cerca de 1,4x mais rápido do que o delegate legado de TFLite GPU, reduzindo latência em vários modelos.
Além do “puro desempenho”, entram otimizações que atacam a latência ponta a ponta, como execução assíncrona e interoperabilidade de buffers com zero-copy. A ideia aqui é reduzir trabalho desnecessário no CPU e acelerar o pipeline inteiro, algo crucial em usos em tempo real como segmentação de fundo e reconhecimento de fala (ASR).
Segundo o anúncio, em situações práticas essas otimizações podem chegar a até 2x de melhora (exemplo mencionado: o app de amostra de segmentação).
Exemplo com a nova CompiledModel API em C++ (com foco em GPU)
Um ponto importante é que o LiteRT traz uma API mais moderna para a “nova geração” de IA on-device: a CompiledModel API. O exemplo abaixo mostra o fluxo básico para compilar para GPU, criar buffers de entrada com zero-copy (embrulhando um buffer OpenGL) e executar o modelo.
// 1. Create a compiled model targeting GPU in C++.
auto compiled_model = CompiledModel::Create(env, "mymodel.tflite",
kLiteRtHwAcceleratorGpu);
// 2. Create an input TensorBuffer that wraps the OpenGL buffer (i.e. from
image pre-processing) with zero-copy.
auto input_buffer = TensorBuffer::CreateFromGlBuffer(env, tensor_type,
opengl_buffer);
std::vector<TensorBuffer> input_buffers{input_buffer};
auto output_buffers = compiled_model.CreateOutputBuffers();
// 3. Execute the model.
compiled_model.Run(inputs, outputs);
// 4. Access model output, i.e. AHardwareBuffer.
auto ahwb = output_buffer[0]->GetAhwb();
C++
O que esse fluxo deixa evidente é a tentativa de “tirar atrito” do caminho: compilar mirando hardware acelerado, reduzir cópias de memória com zero-copy e executar com uma interface pensada para desempenho.
NPU: o caminho unificado para fugir da fragmentação
Se CPU e GPU cobrem muita coisa, a NPU é descrita como a chave para uma experiência realmente fluida e rápida em IA moderna. Só que existe um problema clássico: muita variação de SoC e de implementação de NPU no mercado, o que vira um labirinto de compiladores e runtimes diferentes.
O LiteRT tenta resolver isso oferecendo um workflow unificado de implantação em NPU, abstraindo detalhes de SDKs específicos de fornecedores e lidando melhor com a fragmentação entre variantes de SoC.
O processo simplificado apresentado é basicamente este (em três passos):
- AOT Compilation para os SoCs alvo (opcional): usar a biblioteca Python do LiteRT para pré-compilar o modelo .tflite.
- Deploy via Google Play for On-device AI (PODAI) no Android: para entregar automaticamente modelo e runtime para dispositivos compatíveis.
- Inferência com o LiteRT Runtime: delegação para NPU com fallback robusto para GPU ou CPU quando necessário.
Também fica claro que o LiteRT quer se adaptar a cenários diferentes oferecendo duas abordagens:
- AOT compilation: melhor para modelos complexos e quando você já sabe quais SoCs vai mirar. O foco é reduzir custo de inicialização e memória no start, entregando uma experiência de “iniciar instantaneamente”.
- On-device compilation: melhor para distribuir modelos menores e para muitos ambientes diferentes, sem preparação prévia; em troca, o custo da primeira inicialização tende a ser maior.
No anúncio, as primeiras integrações consideradas “production-ready” citadas são com MediaTek e Qualcomm. E tem números bem chamativos: em alguns casos, a NPU chega a velocidades de até 100x mais rápidas do que CPU e 10x mais rápidas do que GPU.
O texto ainda menciona que o suporte de NPU está sendo expandido para mais hardware, com promessa de novidades futuras.
GenAI com modelos abertos: uma pilha integrada para reduzir o “tranco” do deploy
Modelos abertos dão flexibilidade, mas colocar isso para rodar bem no dispositivo costuma ser trabalhoso: conversões, “lowering”, inferência, benchmark… tudo dá trabalho e custa engenharia. O LiteRT propõe um stack integrado para isso, com três peças principais:
- LiteRT Torch Generative API: módulo em Python para criar e converter modelos de transformadores em PyTorch para os formatos LiteRT-LM/LiteRT, com blocos otimizados para execução em edge.
- LiteRT-LM: camada de orquestração em cima do LiteRT para lidar com complexidades específicas de LLMs; é descrita como infraestrutura já “testada em batalha” e usada para o deployment do Gemini Nano em produtos do Google, incluindo Chrome e Pixel Watch.
- LiteRT Converter & Runtime: motor base para conversão, execução e otimização com aceleração em CPU, GPU e NPU.
Para mostrar impacto, o anúncio cita benchmarks do Gemma 3 1B em um Samsung Galaxy S25 Ultra, comparando LiteRT com llama.cpp. Os resultados destacados foram:
- Até 3x mais rápido no CPU
- Até 7x mais rápido no GPU para decode (limitado por memória)
- Até 19x mais rápido no GPU para prefill (limitado por computação)
- NPU ainda adiciona mais 2x sobre GPU no prefill
Também foi listado um conjunto de modelos “open-weight” com versões já otimizadas e pré-convertidas para deploy imediato, incluindo a família Gemma (como Gemma 3 nas variantes 270M e 1B, Gemma 3n, EmbeddingGemma e FunctionGemma), além de Qwen, Phi, FastVLM e outros.
Esses modelos são mencionados como disponíveis na comunidade do LiteRT no Hugging Face, com exploração interativa via app Google AI Edge Gallery em Android/Play e iOS.
Suporte amplo a frameworks: PyTorch, TensorFlow e JAX
Outro ponto que o anúncio bate bastante é: o deploy não deveria depender do framework usado no treinamento. Por isso, o LiteRT afirma oferecer conversão “suave” a partir de PyTorch, TensorFlow e JAX.
- PyTorch: com a biblioteca LiteRT Torch, a promessa é converter modelos direto para .tflite em um passo, evitando traduções intermediárias complexas e já habilitando aceleração avançada.
- TensorFlow e JAX: segue o suporte forte ao ecossistema TensorFlow e um caminho confiável para modelos JAX via jax2tf.
A mensagem aqui é acelerar o caminho “pesquisa → produção” em qualquer ambiente, mantendo o runtime e as otimizações do LiteRT como base para rodar bem em CPU, GPU e NPU.
Compatibilidade e “pé no chão”: manter o que funcionava no .tflite
Mesmo com a expansão de capacidades, o LiteRT reforça que continua usando o formato .tflite como base: um arquivo único e portátil para manter compatibilidade entre Android, iOS, macOS, Linux, Windows, Web e IoT.
Para não quebrar quem já está em produção, o anúncio destaca dois caminhos de execução:
- A interpreter API: mantendo modelos existentes rodando com alcance amplo e estabilidade.
- A CompiledModel API: a interface moderna para destravar o potencial de aceleração em GPU e NPU na “nova geração” de IA.
O que fica de resumo (e para onde isso aponta) ✅
No fim das contas, o anúncio posiciona o LiteRT como um “centro” para IA on-device: mais performance, suporte multiplataforma forte, workflow mais direto para GPU/NPU, e um stack mais pronto para GenAI com modelos abertos como Gemma.
A conclusão é simples: se a tendência é levar mais IA para rodar localmente, o LiteRT está sendo apresentado como a base universal para isso — com a promessa de manter compatibilidade do mundo .tflite e, ao mesmo tempo, abrir caminho para aceleração moderna e casos de uso em tempo real. 🚀