Evitando Armadilhas Ocultas: Navegando Armadilhas Não Evidentes em ML no iOS

Você precisa de ML?

A aprendizagem de máquina é excelente em detectar padrões. Se você conseguir coletar um conjunto de dados limpo para sua tarefa, geralmente é apenas uma questão de tempo antes de você ser capaz de construir um modelo de ML com desempenho superhumano. Isso é especialmente verdadeiro em tarefas clássicas como classificação, regressão e detecção de anomalias.

Quando você estiver pronto para resolver alguns de seus problemas de negócios com ML, você deve considerar onde seus modelos de ML serão executados. Para alguns, faz sentido executar uma infraestrutura de servidor. Isso tem o benefício de manter seus modelos de ML privados, então é mais difícil para os concorrentes acompanharem. Além disso, os servidores podem executar uma variedade mais ampla de modelos. Por exemplo, os modelos GPT (tornados famosos com ChatGPT) atualmente requerem GPUs modernas, então os dispositivos de consumo estão fora de questão. Por outro lado, manter sua infraestrutura é bastante caro, e se um dispositivo de consumo pode executar seu modelo, por que pagar mais? Além disso, também pode haver preocupações de privacidade onde você não pode enviar dados do usuário para um servidor remoto para processamento.

No entanto, vamos supor que faz sentido usar os dispositivos iOS de seus clientes para executar um modelo de ML. O que pode dar errado?

Limitações da plataforma

Limites de memória

Os dispositivos iOS têm muito menos memória de vídeo disponível do que seus equivalentes de desktop. Por exemplo, o recente Nvidia RTX 4080 Ti tem 20 GB de memória disponível. Já os iPhones, por outro lado, têm memória de vídeo compartilhada com o resto da RAM em algo que chamam de “memória unificada”. Para referência, o iPhone 14 Pro tem 6 GB de RAM. Além disso, se você alocar mais da metade da memória, o iOS é muito provável que mate o aplicativo para garantir que o sistema operacional permaneça responsivo. Isso significa que você só pode contar com ter 2-3 GB de memória disponível para inferência de rede neural.

Os pesquisadores normalmente treinam seus modelos para otimizar a precisão sobre o uso de memória. No entanto, também há pesquisas disponíveis sobre como otimizar para velocidade e uso de memória, então você pode procurar por modelos menos exigentes ou treinar um você mesmo.

Suporte a camadas de rede (operações)

A maioria dos ML e redes neurais vem de frameworks de aprendizado profundo bem conhecidos e são então convertidos para CoreML com Core ML Tools. O CoreML é um motor de inferência escrito pela Apple (AAPL ) que pode executar vários modelos em dispositivos Apple. As camadas são bem otimizadas para o hardware e a lista de camadas suportadas é bastante longa, então isso é um excelente ponto de partida. No entanto, outras opções como Tensorflow Lite também estão disponíveis.

A melhor maneira de ver o que é possível com o CoreML é olhar para alguns modelos já convertidos usando visualizadores como Netron. A Apple lista alguns dos modelos oficialmente suportados, mas também há zoológicos de modelos impulsionados pela comunidade. A lista completa de operações suportadas está constantemente mudando, então olhar para o código-fonte do Core ML Tools pode ser útil como um ponto de partida. Por exemplo, se você deseja converter um modelo PyTorch, você pode tentar encontrar a camada necessária aqui.

Além disso, certas novas arquiteturas podem conter código CUDA manualmente escrito para algumas das camadas. Nesses casos, você não pode esperar que o CoreML forneça uma camada pré-definida. No entanto, você pode fornecer sua própria implementação se você tiver um engenheiro habilidoso familiarizado com a escrita de código GPU.

No geral, o melhor conselho aqui é tentar converter seu modelo para CoreML cedo, mesmo antes de treinar. Se você tiver um modelo que não foi convertido imediatamente, é possível modificar a definição da rede neural em seu framework de DL ou no código-fonte do conversor Core ML Tools para gerar um modelo CoreML válido sem a necessidade de escrever uma camada personalizada para inferência CoreML.

Validação

Bugs no motor de inferência

Não há como testar todas as combinações possíveis de camadas, então o motor de inferência sempre terá alguns bugs. Por exemplo, é comum ver convoluções dilatadas usarem muito mais memória com o CoreML, provavelmente indicando uma implementação mal escrita com um kernel grande preenchido com zeros. Outro bug comum é a saída do modelo incorreta para algumas arquiteturas de modelo.

Nesse caso, a ordem das operações pode ser um fator. É possível obter resultados incorretos dependendo de se a ativação com convolução ou a conexão residual vem primeiro. A única maneira real de garantir que tudo esteja funcionando corretamente é pegar seu modelo, executá-lo no dispositivo pretendido e comparar o resultado com uma versão de desktop. Para esse teste, é útil ter pelo menos um modelo semi-treinado disponível; caso contrário, o erro numérico pode se acumular para modelos mal inicializados aleatoriamente. Mesmo que o modelo final treinado funcione bem, os resultados podem ser bastante diferentes entre o dispositivo e o desktop para um modelo inicializado aleatoriamente.

Perda de precisão

O iPhone usa precisão de meia precisão extensivamente para inferência. Embora alguns modelos não tenham nenhuma degradação de precisão notável devido a menos bits na representação de ponto flutuante, outros modelos podem sofrer. Você pode aproximar a perda de precisão avaliando seu modelo no desktop com meia precisão e computando uma métrica de teste para seu modelo. Um método ainda melhor é executá-lo em um dispositivo real para descobrir se o modelo é tão preciso quanto pretendido.

Profiling

Os diferentes modelos de iPhone têm capacidades de hardware variadas. Os mais recentes têm unidades de processamento de Neural Engine aprimoradas que podem elevar o desempenho geral significativamente. Eles são otimizados para certas operações e o CoreML é capaz de distribuir inteligentemente o trabalho entre CPU, GPU e Neural Engine. As GPUs da Apple também melhoraram ao longo do tempo, então é normal ver desempenhos flutuantes em diferentes modelos de iPhone. É uma boa ideia testar seus modelos em dispositivos minimamente suportados para garantir a compatibilidade máxima e o desempenho aceitável para dispositivos mais antigos.

Também vale a pena mencionar que o CoreML pode otimizar algumas das camadas intermediárias e cálculos no local, o que pode melhorar drasticamente o desempenho. Outro fator a considerar é que, às vezes, um modelo que executa pior em um desktop pode, na verdade, fazer inferência mais rápida no iOS. Isso significa que vale a pena gastar algum tempo experimentando com diferentes arquiteturas.

Para uma otimização ainda maior, o Xcode tem uma ferramenta de instrumentos agradável com um modelo apenas para modelos CoreML que pode fornecer uma visão mais aprofundada do que está retardando a inferência do seu modelo.

Conclusão

Ninguém pode prever todas as armadilhas possíveis ao desenvolver modelos de ML para iOS. No entanto, existem alguns erros que podem ser evitados se você souber o que procurar. Comece a converter, validar e fazer o profiling de seus modelos de ML cedo para garantir que seu modelo funcione corretamente e atenda aos requisitos do seu negócio, e siga as dicas acima para garantir o sucesso o mais rápido possível.