ML Drift: migração de inferência local precisa de orçamento de memória e latência

O Google disponibilizou o ML Drift, motor de aceleração GPU do LiteRT, sob licença Apache 2.0, com suporte a OpenGL ES, OpenCL, Metal e WebGPU.[9] A empresa também deixará de atualizar o delegado GPU antigo do TensorFlow Lite e recomenda a migração para o novo acelerador.[9]

Para uma aplicação existente, a mudança de manutenção é um sinal mais concreto que qualquer percentual de desempenho. Minha recomendação é abrir uma avaliação de migração com critérios de aceitação, não trocar o runtime antes de medir a carga que importa.

O que muda para quem desenvolve

Em relação ao delegado legado, o projeto acrescenta virtualização de tensores, shaders unificados, operações personalizadas extensíveis e tensores de cinco dimensões.[9] Windows e Linux usam Dawn, implementação WebGPU do Chromium, enquanto macOS mantém um backend Metal nativo.[9] Há otimizações específicas para GPUs Arm, Intel e Qualcomm.[9]

Isso propõe uma camada de abstração sobre diferenças de APIs e hardware, mas não deve ser interpretado como equivalência de comportamento em todos os dispositivos. Para arquitetura de produto, eu manteria separado o contrato funcional do modelo e a escolha do mecanismo de execução. Assim, uma mudança de aceleração pode ser avaliada sem redefinir silenciosamente o resultado aceito.

Como aplicar

Selecione um modelo e um conjunto fixo de entradas representativas. Preserve a versão do modelo, a precisão utilizada e o tratamento das entradas. Compare a solução atual e a candidata nos mesmos dispositivos, com critérios definidos antes da medição.

O experimento deve registrar inicialização, latência após aquecimento, variação entre execuções, memória e consumo quando houver medição confiável. Confira também a qualidade das saídas, com tolerâncias explícitas quando a comparação numérica exata não for apropriada. Se uma operação necessária não funcionar como esperado, registre o impedimento em vez de excluir o caso do relatório.

Para aplicações com sessões longas, repita a carga por tempo suficiente para observar comportamento sustentado. Para uso eventual, dê peso ao tempo até o primeiro resultado. São objetivos diferentes e devem produzir decisões diferentes. Não há obrigação de escolher o candidato mais rápido em um único teste se ele piorar memória ou manutenção.

Cuidados e limites

Os números publicados são declarações do fornecedor em cargas específicas: testes com Gemma apontam overhead de memória 12% menor que outros frameworks comparados, e o YouTube Shorts registra redução de até 40% na latência média de quadros de efeitos de segmentação.[9] Não há comparação publicada com Core ML nos iPhones recentes no material reportado.[9]

Esses percentuais não são previsão para o seu modelo. Desenvolvedores podem consumir o caminho de alto nível do LiteRT, enquanto autores de runtimes podem usar a API C++ para grafos e shaders próprios.[9] Prefira o nível de controle que a aplicação precisa sustentar, não o que parece mais sofisticado.

Fonte

[9] Fonte: InfoQ