Inferência do Core ML no dispositivo: os padrões que realmente chegam à produção

O Core ML é o motor de inferência no dispositivo que acompanha todo aparelho Apple moderno. O framework despacha o trabalho para o Neural Engine quando ele está disponível, para a GPU quando não está e para a CPU como último recurso, escolhendo automaticamente o caminho mais rápido com base no modelo e no hardware¹. Em um iPhone recente, o resultado é uma inferência com latência que vai de menos de um milissegundo a algumas dezenas de milissegundos para a maioria dos tamanhos de modelo em produção, gratuita a cada chamada, sem ida e volta pela rede e sem exposição de dados a terceiros.

A fama do framework como “encanamento obscuro” está desatualizada. O Core ML sustenta há quase uma década recursos que rodam no dispositivo, da busca semântica do Fotos à maioria dos apps de terceiros que embarcam ML local, e continua sendo a superfície de produção de um modelo fixo e convertido em todos os sistemas até o iOS 11. A posição dele na pilha mudou na WWDC 2026: a Apple apresentou o Core AI como o framework de baixo nível que sustenta a Apple Intelligence no dispositivo e o apontou como a direção para novos trabalhos com redes neurais¹¹¹². Os padrões que fazem uma implantação do Core ML realmente chegar à produção, em vez de só funcionar na máquina de quem desenvolveu, seguem inalterados e continuam sendo um conjunto pequeno: conversão do modelo, orientação do despacho, orçamento de latência e quantização. Este artigo percorre cada um deles à luz da documentação da Apple e depois posiciona o Core ML na pilha pós-WWDC26.

TL;DR

• O Core ML executa arquivos .mlpackage e .mlmodel no Neural Engine, na GPU e na CPU do Apple Silicon. O despacho é automático, mas pode ser orientado por MLModelConfiguration.computeUnits².
• A conversão do modelo acontece pelo coremltools (PyTorch, TensorFlow, ONNX → Core ML). A conversão é uma tarefa de ferramental, não de tempo de execução; depois que o modelo é convertido e embarcado, o app o carrega e o executa.
• A arquitetura de memória unificada do Apple Silicon significa que os pesos do modelo não são copiados entre CPU, GPU e NE: a mesma memória atende as três³. É esse detalhe de arquitetura que torna possível uma inferência abaixo de um milissegundo.
• A quantização (INT8 e INT4 nas versões recentes do Core ML) reduz o tamanho do modelo e acelera a inferência no Neural Engine, com um custo mensurável de acurácia que depende do modelo. O coremltools 9.0 (novembro de 2025) acrescenta alvos de implantação para iOS 26, leitura e escrita do estado do modelo e entradas e saídas de modelo em int8¹³.
• A pilha mudou na WWDC 2026: a Apple posiciona o Core AI como o framework de inferência por trás da Apple Intelligence no dispositivo e como a superfície para novos trabalhos com redes neurais, enquanto o Core ML segue como camada de produção para modelos fixos já convertidos e para ML tradicional¹¹¹².

O modelo mental: três caminhos de computação, uma só memória

O Apple Silicon (Macs da linha M e iPhones da linha A a partir do A12 Bionic) traz três alvos de inferência:

Neural Engine. Um acelerador especializado em multiplicação de matrizes com baixa precisão. O mais rápido para as operações das quais os modelos de ML modernos dependem (convoluções, atenção, embeddings). O de menor consumo. Limitado a tipos de operação e formatos de tensor específicos; operações sem suporte caem camada a camada para a GPU ou a CPU.

GPU. Computação paralela de propósito geral por meio do Metal. Mais lenta que o Neural Engine para trabalho com formato de ML, porém mais rápida que a CPU. Cuida das operações que o Neural Engine não suporta.

CPU. O plano de recuo. Lenta para inferência de ML, mas sempre disponível, sempre capaz de executar qualquer operação e previsível.

A arquitetura de memória unificada significa que a mesma RAM física atende as três³. Os pesos de um modelo, carregados uma única vez, não são copiados quando o despacho muda de alvo. É esse fato de arquitetura que transforma o despacho entre vários alvos: em vez de um custo de cópia por camada, resta uma decisão de escalonamento por camada.

O MLModelConfiguration.computeUnits controla o despacho:

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all é o padrão e a escolha certa para quase todo app. O framework escolhe o caminho mais rápido a cada operação, e essa decisão por operação é melhor do que qualquer heurística que você escreveria à mão. O motivo raro para sobrescrever é forçar .cpuOnly para paridade em testes (um modelo se comporta de forma diferente em cada caminho e o teste precisa do caminho determinístico) ou forçar .cpuAndGPU para liberar o Neural Engine para outra tarefa concorrente.

Conversão do modelo: a tarefa de ferramental

A maioria dos modelos de ML é treinada no PyTorch, no TensorFlow ou diretamente no Create ML da Apple. O Core ML aceita arquivos .mlpackage, o formato moderno introduzido no Xcode 13 que substitui o antigo .mlmodel⁴. A conversão acontece pelo coremltools, o pacote Python de código aberto da Apple⁵.

Uma conversão típica de PyTorch para Core ML segue três passos:

1. Carregar o modelo PyTorch treinado e colocá-lo em modo de inferência.
2. Traçar o modelo com um tensor de entrada de exemplo que corresponda ao formato de entrada de produção.
3. Converter o modelo traçado com o coremltools visando uma versão do iOS de destino.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

A conversão acontece uma única vez, em um ambiente de desenvolvimento, visando uma versão do iOS de destino (minimum_deployment_target). O .mlpackage gerado é o que entra no projeto do Xcode. O app em execução não roda o coremltools. A versão atual, coremltools 9.0, acrescenta alvos de implantação até o iOS 26, a capacidade de ler e escrever o estado do modelo (para modelos com estado, como decodificadores de transformers com cache KV), entradas e saídas de modelo em int8 e suporte a Python 3.13 e PyTorch 2.7¹³.

Há duas armadilhas práticas na conversão. Primeiro, entradas de formato dinâmico exigem tratamento explícito via ct.RangeDim, porque o formato estático assumido por padrão pelo Core ML produz erros pouco úteis quando o app de produção entrega tamanhos de entrada variáveis. Segundo, operações personalizadas do PyTorch sem equivalente no Core ML exigem ou uma camada personalizada do Core ML (código Swift que executa a operação ausente) ou uma mudança na arquitetura do modelo que remova a operação antes da conversão. Os dois casos são bem documentados⁵.

Orçamentos de latência que realmente valem

Três orçamentos de latência importam para apps que vão ao ar:

16 ms (interface ao vivo a 60 fps). Um filtro de câmera em tempo real, uma cena de AR que se atualiza a cada quadro, um analisador de áudio ao vivo. O orçamento inclui tudo: pré-processamento da imagem, inferência do modelo, pós-processamento e atualização da interface. Os modelos que cabem costumam ser pequenos (classe MobileNetV3, abaixo de 100 milhões de parâmetros) e rodam no Neural Engine.

100 ms (interface interativa). O usuário executa uma ação e espera pelo resultado: tocar para identificar, desenhar para reconhecer, ditar para transcrever. O orçamento é mais tolerante e comporta modelos maiores. Modelos de linguagem abaixo de 1 bilhão de parâmetros, transformers de visão pequenos e a maioria dos classificadores de nível de produção cabem com folga.

1 s ou mais (segundo plano ou lote). Indexação da fototeca, análise de documentos, aquecimento do modelo na abertura do app. Modelos maiores funcionam, mas a expectativa do usuário precisa ser ajustada com um indicador de progresso. O LLM no dispositivo do Foundation Models vive aqui, nas operações com janela de contexto maior.

Esses orçamentos são referências, não limites rígidos. O movimento certo é medir em um aparelho de destino usando os_signpost ou o template do Core ML no Instruments⁶, em vez de confiar em números teóricos vindos de outra máquina.

Quantização: quando menor é mais rápido

O Core ML dá suporte a vários níveis de quantização⁷:

• Float32 (precisão total). O padrão do treinamento. O maior, o mais preciso, o mais lento.
• Float16. Meia precisão. Menor e mais rápido na GPU e no NE; a perda de acurácia costuma ser desprezível em modelos bem condicionados.
• INT8. Quantização inteira de 8 bits com calibração. Cerca de 4x menor que Float32 e muitas vezes de 2-4x mais rápido no NE. A perda de acurácia varia; em modelos de visão, uma perda de acurácia top-1 abaixo de 1 % é alcançável com treinamento consciente de quantização.
• INT4 e abaixo. Quantização agressiva que as versões recentes do Core ML suportam para arquiteturas específicas (LLMs e grandes modelos de visão). O preço é uma perda de acurácia significativa; a técnica rende mais quando combinada com treinamento consciente de quantização adaptado ao modelo.

A configuração de quantização linear via coremltools.optimize.coreml.linear_quantize_weights aceita uma configuração global de operações que escolhe o modo de quantização (linear_symmetric ou linear) e um limiar de tamanho de peso abaixo do qual os pesos permanecem em precisão total. A conversão roda sobre um .mlpackage existente e produz um novo pacote quantizado; os dois podem seguir lado a lado no bundle, com o app decidindo qual carregar conforme a classe do aparelho.

A decisão de quantizar é feita modelo a modelo: um classificador pequeno pode não se beneficiar, já que sua computação já é barata; um modelo de linguagem grande se beneficia enormemente, porque sua computação é dominada por multiplicações de matrizes sobre os pesos quantizados. A abordagem certa é quantizar, medir a acurácia em um conjunto de teste reservado e publicar se a perda for aceitável para o caso de uso.

Os modelos prontos da Apple que dá para usar direto

A Apple oferece vários modelos do Core ML pré-treinados na página Core ML Models⁸. Categorias que vale conhecer:

• Classificação de imagens: MobileNetV2, ResNet50 e variantes do SqueezeNet, todos empacotados e prontos para entrar em um VNCoreMLRequest do framework Vision.
• Detecção de objetos: YOLOv3, MNIST e variantes do CenterNet.
• Estimativa de pose: PoseNet para pose corporal (uma alternativa de referência ao VNDetectHumanBodyPoseRequest do Vision).
• Segmentação semântica: DeepLabV3 para segmentação de imagens.
• Reconhecimento de texto: alternativas de OCR baseadas em ML ao reconhecimento embutido do Vision.

Para a maioria dos apps, os modelos pré-treinados da Apple cobrem as primitivas de percepção (classificar, detectar, segmentar) sem exigir treinamento próprio. Para tarefas de linguagem, o LLM do sistema no dispositivo fica inteiramente acima dessa camada: o framework Foundation Models o expõe por trás de uma API Swift de alto nível, offline e gratuita, sem nenhum arquivo de modelo para você embarcar ou converter.

Criptografia do modelo e considerações sobre a App Store

Um .mlpackage dentro do bundle do app pode ser lido por qualquer pessoa que descompacte o IPA. Para modelos que representam propriedade intelectual relevante, a Apple dá suporte à criptografia do modelo pelo fluxo Encrypt your Core ML model⁹: uma chave de criptografia é gerada pelo Xcode e gerenciada pelo CloudKit, o modelo no bundle fica criptografado e o Core ML o descriptografa no carregamento.

Para a maioria dos apps, criptografia é exagero. Um modelo treinado com dados comuns do ImageNet não é um diferencial competitivo; criptografá-lo acrescenta complexidade operacional sem proteger nada de valor. Reserve a criptografia para modelos que representem investimento real em dados de treinamento ou vantagem competitiva.

Privacidade no dispositivo: a vitória de arquitetura

O argumento de privacidade é direto. A inferência do Core ML acontece inteiramente no dispositivo. Os dados de entrada (imagens, áudio, texto) não saem do aparelho. O arquivo do modelo é local; a inferência é local; o resultado é local.

Para apps de setores regulados (saúde, finanças, educação), esse fato de arquitetura elimina toda uma classe de trabalho de conformidade. Não há operador de dados terceirizado para incluir em uma política de privacidade. Não há endpoint de API de modelo para avaliar em termos de segurança. Não há questão de residência dos dados, porque os dados nunca se movem.

O formato Privacy Manifest¹⁰ formaliza esse argumento para o envio à App Store: um app que usa o Core ML para inferência no dispositivo e nada mais pode declarar compartilhamento zero de dados com terceiros no caminho de inferência. O envio fica mais rápido, a revisão de privacidade fica mais curta e o rótulo de privacidade visível ao usuário fica mais limpo.

A conexão com o fluxo de trabalho de agentes

O Core ML combina com três padrões que este conjunto de artigos já tratou:

O VNCoreMLRequest do framework Vision. Modelos personalizados do Core ML passam pelo pipeline do Vision com pré-processamento automático. Esse padrão (tratado em Vision Framework) é o jeito certo de publicar um classificador ou detector de imagens próprio dentro de um app iOS.

O LLM no dispositivo do Foundation Models. O LLM de sistema da Apple Intelligence vive por trás do framework Foundation Models e, desde a WWDC 2026, a Apple identifica o Core AI como o framework de inferência que o sustenta¹¹. Os conceitos deste artigo continuam se transferindo direto: o despacho entre unidades de computação, os pesos quantizados e os orçamentos de latência governam o LLM de sistema do mesmo jeito que governam um modelo convertido por você. O artigo sobre o framework cobre a API do LLM; este cobre os padrões de inferência que estão embaixo.

Ferramentas de App Intents que usam ML local. Um AppIntent que executa um classificador local de imagem ou de texto devolve resultados estruturados à Apple Intelligence sem ida e volta pela rede. É essa combinação que torna uma “Apple com agentes” de fato privada: as ferramentas do agente rodam localmente porque o framework permite.

Quando a inferência na nuvem é a escolha certa

O teto do Core ML é a computação do aparelho. Três casos em que a nuvem está certa:

Modelos grandes demais para embarcar. Um LLM de 70 bilhões de parâmetros não cabe no bundle de um app. Para cargas nessa escala, a inferência na nuvem (ou a execução no dispositivo com pesos transmitidos por streaming, que é outro padrão) é a ferramenta certa.

Estado compartilhado entre dispositivos durante a inferência. Modelos que precisam ler ou escrever em um banco de dados compartilhado durante a inferência (sistemas de recomendação com filtragem colaborativa sobre bilhões de registros). O modelo puramente local do Core ML não se encaixa.

Iteração rápida do modelo. Um time que publica atualizações de modelo todo dia se beneficia da inferência no servidor, porque as liberações não exigem ciclos de revisão da App Store. O padrão do Core ML de embarcar o modelo no app acrescenta atrito à cadência de novas versões do modelo; esse trade-off é real.

O padrão: a nuvem vence em escala e velocidade de iteração; o Core ML vence em latência, custo e privacidade.

Onde o Core ML fica depois da WWDC 2026

A WWDC 2026 redesenhou o mapa embaixo deste artigo sem invalidá-lo. A Apple apresentou o Core AI, um framework do iOS 27 cujo resumo é “Run AI models in your app on Apple silicon”, e afirmou na sessão 324 que o Core AI é o framework de inferência que sustenta a Apple Intelligence no dispositivo, agora aberto a apps de terceiros¹¹. Onde o conversor do Core ML toma por você as decisões de hardware e de otimização, o Core AI entrega as alavancas: especialização explícita do modelo, um cache de artefatos gerenciado, direcionamento de unidades de computação e fluxos de computação assíncronos. A análise completa está em Core AI: executando modelos no Apple silicon.

O sinal de direção é mais forte do que a documentação sozinha sugere. No group lab de machine learning da WWDC 2026, um engenheiro do Core AI disse que a Apple está pedindo a todo mundo que trabalha com redes neurais que migre para o Core AI daqui em diante, com o Core ML permanecendo no lugar, mas voltado ao aprendizado de máquina tradicional, como árvores de decisão¹². Essa declaração é uma paráfrase de um lab, não uma política publicada, mas combina com o formato do lançamento: o Core AI ficou com o ferramental novo, os formatos novos e a carga da Apple Intelligence.

A leitura prática para um app que é publicado hoje:

• As implantações existentes do Core ML continuam funcionando. Nada no iOS 27 marca o caminho do .mlpackage como obsoleto, e o coremltools 9.0 trouxe capacidades novas (alvos de iOS 26, modelos com estado, entrada e saída em int8) tão recentemente quanto novembro de 2025¹³.
• O Core ML continua sendo a única opção abaixo do iOS 27 e a opção pragmática para um modelo fixo e convertido quando os padrões do conversor são exatamente o que você quer.
• Trabalhos novos com redes neurais que mirem o iOS 27 ou superior deveriam avaliar o Core AI primeiro, sobretudo onde você consegue nomear a especialização, o cache ou o controle de escalonamento de que precisa.
• As outras camadas não se movem. O LLM de sistema continua atrás do Foundation Models, e o MLX continua sendo o framework de arrays embutível para modelos de pesos abertos e ajustes finos próprios. Core ML versus Core AI é uma pergunta sobre a camada de execução do seu modelo, não sobre essas outras peças.

O que esse padrão significa para apps de iOS 26 em diante

Três conclusões.

1. Escolha o Core ML por padrão para qualquer modelo que caiba no bundle e produza, a cada chamada, um resultado sobre o qual o usuário possa agir. Classificação de imagens, detecção de objetos, classificação de áudio, reconhecimento de gestos, geração de embeddings e tarefas de linguagem de pequeno a médio porte. O despacho automático do framework e a NPU do Apple Silicon entregam de graça uma inferência que vai de menos de um milissegundo a algumas dezenas de milissegundos.

2. Quantize de forma agressiva enquanto a perda de acurácia for aceitável. INT8 costuma ser seguro; INT4 é apropriado para modelos grandes em que a economia de tamanho importa. Meça a acurácia em um conjunto reservado em vez de supor que a quantização é sempre segura.

3. Combine com Vision e Foundation Models para pipelines totalmente locais. O Core ML é o motor; o Vision é a API de percepção acima dele; o Foundation Models é o LLM acima dele. O artigo sobre o Vision e o artigo sobre o Foundation Models deste conjunto cobrem as superfícies de nível mais alto.

O conjunto completo sobre o ecossistema Apple: os App Intents tipados; os servidores MCP; a questão do roteamento; o Foundation Models; a distinção entre LLM de tempo de execução e LLM de ferramental; as três superfícies; o padrão da fonte única da verdade; Dois servidores MCP; os hooks para desenvolvimento Apple; as Live Activities; o contrato de execução do watchOS; as entranhas do SwiftUI; o modelo mental espacial do RealityKit; a disciplina de schema no SwiftData; os padrões do Liquid Glass; a publicação multiplataforma; a matriz de plataformas; o framework Vision; os Symbol Effects; sobre o que me recuso a escrever. O eixo central é a série sobre o ecossistema Apple. Para um contexto mais amplo de iOS com agentes de IA, veja o guia de desenvolvimento de agentes no iOS.

Perguntas frequentes

Como o Core ML decide entre Neural Engine, GPU e CPU?

O Core ML examina cada operação no grafo do modelo e a despacha para o alvo mais rápido que a suporte. O Neural Engine cuida das operações suportadas (a maior parte das multiplicações de matrizes, das convoluções e da atenção) com a menor latência e o menor consumo. A GPU cuida das operações que o NE não suporta. A CPU cuida do resto. A decisão é por operação, automática, e melhor do que uma heurística escrita à mão.

Devo sempre usar .computeUnits = .all?

Quase sempre. O despacho automático do framework é bem calibrado. Mude para .cpuOnly ao testar paridade de saída (o mesmo modelo devolve resultados ligeiramente diferentes no NE e na CPU por causa do arredondamento em ponto flutuante) ou para .cpuAndGPU para liberar o Neural Engine para uma tarefa concorrente.

Qual é a diferença prática entre .mlpackage e .mlmodel?

O .mlpackage é o formato moderno introduzido no Xcode 13. Ele suporta metadados armazenados, várias variantes de modelo para a compilação como ML Program (mlprogram) e a cadeia de ferramentas posterior ao iOS 13. O .mlmodel é o formato legado. Os dois ainda carregam pelo MLModel; o desenvolvimento novo deve usar .mlpackage.

Qual é o tamanho máximo de um modelo do Core ML no bundle de um app?

Não existe um limite fixo, mas o tamanho dos bundles da App Store é limitado a 4 GB para download e tem limites práticos para instalação pelo ar. O LLM do sistema no dispositivo contorna a questão por completo: o sistema operacional o distribui, e os apps chegam a ele pelo Foundation Models sem embarcar nada. Para modelos embarcados no app, abaixo de 100 MB é confortável; de 100 a 500 MB é viável com uma estratégia de carregamento na abertura; acima de 500 MB, o melhor caminho é o download em segundo plano com BGProcessingTask ou recursos sob demanda.

Devo usar Core ML ou Core AI para um modelo novo?

Abaixo do iOS 27, o Core ML é a única opção. No iOS 27 ou superior, a direção declarada pela Apple é o Core AI para redes neurais, com o Core ML seguindo para aprendizado de máquina tradicional e implantações existentes¹¹¹². Se você tem um modelo fixo e convertido e os padrões do conversor atendem, o Core ML ainda vai bem; se precisa de controle explícito sobre especialização, cache ou escalonamento, é exatamente esse controle que o Core AI existe para oferecer.

Como saber se a quantização prejudicou a acurácia do meu modelo?

Reserve um conjunto de teste, execute a inferência no modelo Float32 original e no modelo quantizado, compare as métricas (acurácia top-1 para classificadores, F1 para detectores, perplexidade para modelos de linguagem, BLEU para tradução etc.) e decida com base nos requisitos de acurácia da aplicação. O treinamento consciente de quantização (treinar o modelo com a quantização simulada na função de perda) costuma recuperar a maior parte da acurácia perdida.

Referências