Core AI: executando modelos no Apple silicon

A pilha de IA on-device da Apple tinha um degrau faltando. O Foundation Models entrega o LLM do sistema, lacrado e gratuito. O Core ML executa um modelo fixo já convertido, com o conversor tomando as decisões de hardware por você. O MLX traz um framework de arrays que você incorpora e um modelo que você seleciona. O iOS 27 adiciona o degrau abaixo de todos os três: o Core AI, um framework cujo resumo em uma linha é “Execute modelos de IA no seu app no Apple silicon.”¹ Ele é a superfície de execução de modelos, o lugar a que você recorre quando quer conduzir você mesmo a especialização, o caching e o agendamento de inferência, em vez de aceitar os padrões de uma camada superior.

Na sessão 324, a Apple posiciona o Core AI como o mesmo framework de inferência que alimenta o Apple Intelligence on-device, agora aberto para a inteligência do seu próprio app.¹⁵

O enquadramento importa porque o Core AI fica abaixo das abstrações que a maioria dos apps deveria usar. A Apple o descreve como projetado com o Apple silicon em mente, permitindo que seu app utilize as mais recentes arquiteturas de modelos e técnicas de inferência através da CPU, da GPU e do Neural Engine, com uma API em Swift que torna as tarefas comuns simples enquanto lhe dá mais controle sobre especialização de modelos, caching e desempenho de inferência quando necessário.¹ A tese deste post: recorra ao Core AI quando você tiver um modelo que queira executar com controle explícito sobre onde e como ele roda, e fique no Core ML ou no Foundation Models quando não tiver. O framework recompensa uma necessidade específica, não uma preferência padrão.

TL;DR / Principais conclusões

• O Core AI separa um AIModelAsset não especializado (inspecione a estrutura e os metadados de um modelo de forma barata) de um AIModel especializado (execute a inferência em um dispositivo), com o AIModelCache guardando os artefatos específicos do dispositivo e o AssetError para falhas em operações de asset.²³⁶⁴
• Os dados de inferência fluem através do NDArray, um array multidimensional de valores escalares, descrito por um NDArrayDescriptor que fixa a forma, o tipo escalar e as expectativas de layout de memória.⁵⁷
• Você direciona o hardware com o ComputeUnitKind (CPU, GPU ou Neural Engine) por meio das SpecializationOptions, e agenda trabalho assíncrono em um ComputeStream.⁸⁹¹⁰
• Uma InferenceFunction é dona dos pesos e dos buffers e executa a inferência; um InferenceFunctionDescriptor permite que você inspecione antes a assinatura de entrada, saída e estado dela. A função é Sendable, então você pode executá-la concorrentemente.¹⁴¹³
• Os modelos são carregados de um bundle .aimodel no disco, e o Core AI vem com ferramentas de preparação, conversão e depuração ao lado do framework. Recorra ao Core AI quando precisar de controle explícito sobre especialização e agendamento; caso contrário, fique no Core ML ou no Foundation Models.²¹

Duas palavras que comandam todo o design: asset e model

A primeira coisa que o Core AI pede que você internalize é que um modelo no disco e um modelo que executa inferência são objetos diferentes, e especializar um no outro é caro. O framework dá um tipo a cada um.

Um AIModelAsset é “um asset de modelo de origem não especializado.”² Você o cria a partir da URL de um bundle .aimodel no disco, e o usa para inspecionar um modelo sem pagar o custo da especialização. A Apple é explícita sobre por que essa divisão existe: um asset de modelo permite consultar informações do modelo sem realizar a especialização, que é uma operação cara. A partir de um asset você pode ler assinaturas de funções, descrições de entrada e saída, tipos de computação e de armazenamento, e metadados fornecidos pelo autor. O que você não pode fazer é executar inferência; um asset serve apenas para inspeção.²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

O AIModel é a outra metade: “um modelo especializado para executar inferência em um dispositivo.”³ Um AIModel representa um asset .aimodel especializado e otimizado para o hardware do dispositivo atual, e você cria um carregando o asset do disco.³ O asset responde o que é este modelo?; o model responde execute-o aqui, agora. A assimetria de custo entre os dois é o motivo pelo qual a API obriga você a nomear qual deles quer. Inspecionar uma centena de modelos candidatos para escolher um é barato se você só constrói assets; seria desastroso se cada inspeção especializasse.

A especialização produz artefatos específicos do dispositivo, e esses artefatos têm um lar: o AIModelCache, “um cache que armazena os artefatos do modelo especializado para inferência.”⁶ O cache guarda os artefatos otimizados e específicos do dispositivo que um modelo carrega para executar suas funções de inferência, e a Apple observa que cada entrada do cache contém um asset especializado formado a partir de um .aimodel ou .aimodelc específico e uma combinação de especialização.⁶ A leitura prática: a especialização não é algo que você queira repetir a cada inicialização. O cache é como o Core AI deixa o passo caro acontecer uma vez e o passo barato (carregar os artefatos em cache) acontecer dali em diante.

Quando operações de asset dão errado (um bundle ausente, um .aimodel malformado, um arquivo ilegível), o Core AI expõe um AssetError, “um erro que ocorre durante operações de asset de modelo.”⁴ Trate-o como você trata qualquer fronteira de I/O: o asset vive no disco, operações de disco falham, e o sistema de tipos lhe diz exatamente onde colocar o catch.

Tensores: NDArray e seu descriptor

A inferência move números para dentro e números para fora, e o contêiner do Core AI para esses números é o NDArray, “um array multidimensional de valores escalares usado para inferência de modelos.”⁵ Se você já trabalhou com o ndarray do NumPy, com arrays do MLX ou com MLMultiArray, o formato da ideia é familiar: um bloco n-dimensional de escalares com um layout definido. Um NDArray armazena seus dados em um layout definido por sua forma e pelo restante de suas propriedades descritivas.⁵

O tipo companheiro é o NDArrayDescriptor, “uma descrição da forma, do tipo escalar e das expectativas de layout de memória de um array.”⁷ Um descriptor é o contrato. O enquadramento da Apple é direto: o descriptor contém as expectativas para um valor de array que você fornece a uma função de inferência, e a maioria das expectativas é estrita. Se o descriptor especifica um tipo escalar .float32, o array que você fornece precisa usar .float32.⁷ Você não adivinha a forma e o tipo que uma função quer; você pergunta ao descriptor da função e se conforma a ele.

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

A lição de design aqui espelha a divisão asset/model. O Core AI consistentemente coloca um objeto de descrição barato à frente de um objeto de valor caro. Você lê o descriptor para conhecer o contrato e então aloca o NDArray que o satisfaz, em vez de alocar primeiro e descobrir uma incompatibilidade no momento da inferência. Para entradas de imagem especificamente, o Core AI também define um ImageDescriptor, “uma descrição das dimensões e do formato de pixel de uma imagem,” para que a entrada de pixels de um modelo de visão receba o mesmo tratamento descriptor-first.¹¹

Escolhendo onde a inferência roda

O Apple silicon tem três lugares para computar: CPU, GPU e Neural Engine. A razão de o Core AI existir, em vez de apenas o Core ML, é que o Core AI deixa você dizer qual deles o framework deve direcionar, em vez de inferi-lo.

O ComputeUnitKind é “um tipo de unidade de computação de hardware disponível para inferência de modelos.”⁸ Você usa os tipos de unidade de computação com as opções de especialização para controlar qual hardware o framework direciona ao especializar um modelo, e por padrão a especialização usa todas as unidades de computação disponíveis no dispositivo.⁸ O padrão é a resposta certa para a maior parte do trabalho, e esse é justamente o ponto: você só o sobrescreve quando tem um motivo (um caminho sensível à latência que você quer fixar no Neural Engine, uma passada de depuração que você quer forçar para a CPU, um pipeline pesado em GPU que você está coordenando com outro trabalho de GPU).

Você passa essa intenção através das SpecializationOptions, a estrutura que carrega as escolhas feitas no momento da especialização.⁹ A especialização é o passo caro de antes, e as SpecializationOptions são onde vivem o direcionamento de unidade de computação e as demais decisões de especialização. Como uma entrada de cache é indexada por um asset específico e uma combinação de especialização, mudar suas opções muda qual artefato em cache você recebe de volta, o que fecha o ciclo entre direcionamento e caching.⁶

O agendamento é o outro eixo do “como ele roda”, e o Core AI o modela como um ComputeStream, “um fluxo de trabalho a ser executado de forma assíncrona.”¹⁰ Um compute stream é o que você fornece para codificar trabalho no fluxo, e a Apple observa que múltiplas inferências codificadas no mesmo fluxo são serializadas conforme necessário com base nos valores lidos e escritos.¹⁰ Duas implicações se seguem. Primeiro, um stream é seu primitivo de ordenação: codifique inferências dependentes em um único stream e o Core AI as sequencia por dependência de dados. Segundo, o trabalho é assíncrono por padrão, então o stream também é como você mantém a thread chamadora livre enquanto o Neural Engine ou a GPU faz o trabalho.

Funções de inferência: a coisa que de fato executa

Um .aimodel carregado não é um único chamável. Os modelos expõem funções nomeadas (um encoder, um decoder, uma vision tower, um passo de prefill versus um passo de decode), e a unidade de execução do Core AI é a InferenceFunction: “uma função que realiza inferência sobre valores de entrada e produz valores de saída.”¹⁴

Antes de chamar uma, você a inspeciona. O InferenceFunctionDescriptor é “uma descrição da assinatura de uma função de inferência,” e você usa um descriptor para inspecionar os nomes e tipos das entradas, saídas e estados de uma função antes de executar a inferência.¹³ Os estados são o detalhe que vale a pena pausar: uma função com estado é como um modelo stateful (uma KV cache em um loop de decode de transformer, por exemplo) mantém informação entre chamadas, e o descriptor lhe diz que uma função tem estados antes de você tentar conduzi-la.

A própria InferenceFunction é dona dos recursos que a inferência precisa, incluindo os pesos do modelo e os buffers intermediários. Você carrega uma função a partir de um modelo e chama run(inputs:states:outputViews:) para realizar a inferência.¹⁴ A assinatura de run é nomeada na própria discussão da Apple, então as três coisas que uma chamada precisa ficam explícitas: os valores de entrada, os valores de estado e os output views que você quer que sejam escritos.

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

Duas propriedades tornam a função agradável sob carga. Ela é Sendable, então você pode executá-la concorrentemente a partir de múltiplas tasks, e a Apple observa que ela aloca automaticamente buffers intermediários adicionais conforme necessário para dar suporte a essa concorrência.¹⁴ Você não serializa as chamadas atrás de um lock para proteger um espaço de rascunho compartilhado; a função gerencia seus próprios buffers por chamador concorrente. Essa é uma diferença significativa em relação a APIs nas quais um único handle de inferência é efetivamente single-threaded.

Os valores que fluem através de run são instâncias de InferenceValue, “um valor que uma função de inferência aceita como entrada ou produz como saída.”¹² Um InferenceValue encapsula ou um NDArray ou um pixel buffer, e você recupera um resultado após a inferência usando sua propriedade value.¹² O wrapper é o que permite que uma única assinatura de run carregue tanto entradas de tensor quanto entradas de imagem sem sobrecargas separadas: um modelo de texto passa valores baseados em NDArray, um modelo de visão passa valores baseados em pixel buffer, e a função lê o descriptor para saber qual ela espera.

Quando recorrer ao Core AI

A parte mais difícil do Core AI não é a API. É saber que você deveria estar aqui afinal, em vez de uma camada acima. A árvore de decisão honesta:

• Foundation Models quando o modelo de sistema da Apple dá conta da tarefa. Resumir, classificar, extrair, reescrever, saída estruturada: isso pertence ao Foundation Models, que não lhe custa pesos, nem orçamento de memória, nem passo de especialização. Se o seu recurso se encaixa, pare aí. Descer ao Core AI para reimplementar o que o modelo de sistema já faz é trabalho desperdiçado.
• Core ML quando você tem um modelo fixo e já convertido e quer que o conversor tome as decisões de hardware e otimização por você. O Core ML direciona o Neural Engine com energia e latência apertadas para um modelo de produção lacrado, e ele não lhe pede nada sobre especialização ou agendamento. Se você não quer pensar em direcionamento de unidade de computação ou compute streams, esse é o sinal para ficar no Core ML.
• MLX quando você quer um framework de arrays de nível de pesquisa que você incorpora e itera: seu próprio loop de treinamento, modelos open-weight quantizados, fine-tunes com LoRA, experimentação rápida. O MLX é uma biblioteca que você distribui com os pesos, não uma superfície de execução de modelos de sistema. Ele vence em flexibilidade e velocidade de iteração.
• Core AI quando você tem um modelo para executar e quer os handles explícitos do framework: um AIModelAsset que você inspeciona antes de se comprometer, SpecializationOptions que fixam unidades de computação, um AIModelCache que você gerencia, um ComputeStream no qual você agenda, e InferenceFunctions que você chama concorrentemente. Você recorre aqui quando os padrões das camadas superiores são justamente o que está no seu caminho, e você consegue nomear qual padrão precisa sobrescrever.

O fio condutor por toda a pilha: cada camada abaixo troca um padrão por um handle. O Foundation Models lhe entrega tudo e não pede nada. O Core AI lhe entrega as alavancas e pede que você saiba qual puxar. Se você não consegue nomear o controle de especialização, caching ou agendamento que precisa, então você ainda não precisa do Core AI.

Uma declaração de um lab da WWDC 2026 afia onde fica a linha entre Core AI e Core ML para trabalho novo. Parafraseado de uma gravação transcrita localmente do WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab, um engenheiro do Core AI no painel disse que a Apple está pedindo a todos que trabalham com redes neurais que migrem para o Core AI daqui em diante, com o Core ML permanecendo em uso, mas focado em machine learning tradicional, como árvores de decisão, e tudo que é novo indo para o Core AI.¹⁶ Leia isso como um sinal de direção-de-viagem vindo das pessoas que constroem o framework, e não como uma política documentada: se você está recorrendo a uma rede neural em um projeto novo, o lab enquadrou o Core AI como a superfície sobre a qual construir.

Como um modelo chega ao Core AI

O framework é a metade de runtime de um fluxo de trabalho maior. A Apple observa que o Core AI inclui ferramentas adicionais para preparação, integração e depuração de modelos ao lado do framework: você prepara seus modelos para o Apple silicon, os converte para o formato .aimodel, e usa um app companheiro que dá suporte a visualização e depuração numérica.¹ A descrição dos nomes dessas ferramentas no fact-sheet está truncada, então confirme os nomes exatos das ferramentas e sua invocação na documentação do Core AI da Apple, em vez de confiar em qualquer reconstrução.¹ O que está verificado é o formato do pipeline: um modelo de origem é preparado, convertido para .aimodel, carregado como um AIModelAsset para inspeção, especializado em um AIModel e executado por suas InferenceFunctions, com o AIModelCache guardando os artefatos especializados para que o passo caro aconteça uma vez.¹²³⁶¹⁴

FAQ

O que é o framework Core AI da Apple?

O Core AI é o framework de baixo nível do iOS 27 para executar modelos de IA no Apple silicon, resumido pela Apple como “Execute modelos de IA no seu app no Apple silicon.”¹ Ele executa a inferência de modelos através da CPU, da GPU e do Neural Engine por meio de uma API em Swift que torna as tarefas comuns simples enquanto lhe dá controle sobre especialização de modelos, caching e desempenho de inferência quando você precisa.¹ Ele fica abaixo do Foundation Models e do Core ML como uma superfície de execução de modelos.

Qual é a diferença entre AIModelAsset e AIModel?

O AIModelAsset é um asset de origem não especializado que você cria a partir da URL de um bundle .aimodel no disco; você o usa para inspecionar as assinaturas de funções, as descrições de entrada e saída, os tipos de computação e de armazenamento e os metadados de um modelo sem especializar, porque a especialização é cara, e um asset não pode executar inferência.² O AIModel é o modelo especializado e otimizado para o hardware do dispositivo atual que de fato executa a inferência; você cria um carregando o asset do disco.³ A divisão permite que você inspecione de forma barata e especialize apenas quando se compromete.

Como o Core AI escolhe entre a CPU, a GPU e o Neural Engine?

Você controla o direcionamento de hardware com o ComputeUnitKind por meio das SpecializationOptions. Um tipo de unidade de computação nomeia um tipo de unidade de computação de hardware disponível para inferência, e você o usa para controlar qual hardware o framework direciona ao especializar um modelo; por padrão a especialização usa todas as unidades de computação disponíveis no dispositivo.⁸⁹ Você sobrescreve o padrão apenas quando tem um motivo específico, como fixar um caminho sensível à latência em uma unidade de computação.

O que é uma InferenceFunction e como eu a executo?

Uma InferenceFunction realiza inferência sobre valores de entrada e produz valores de saída, sendo dona dos pesos do modelo e dos buffers intermediários.¹⁴ Você inspeciona primeiro a assinatura dela por meio de um InferenceFunctionDescriptor, que descreve os nomes e tipos das entradas, saídas e estados da função, depois carrega a função de um AIModel e chama run(inputs:states:outputViews:).¹³¹⁴ A função é Sendable e aloca buffers intermediários automaticamente para dar suporte à concorrência, então múltiplas tasks podem executá-la ao mesmo tempo.¹⁴

Devo usar o Core AI em vez do Core ML ou do Foundation Models?

Use o Foundation Models quando o modelo de sistema dá conta da tarefa, e o Core ML quando você tem um modelo fixo e convertido e quer que o conversor tome as decisões de hardware e otimização por você. Recorra ao Core AI quando você quer controle explícito sobre especialização (SpecializationOptions, ComputeUnitKind), caching (AIModelCache) e agendamento (ComputeStream) que as camadas superiores lidam em seu nome.⁸⁹⁶¹⁰ Se você não consegue nomear o controle que precisa, fique uma camada acima.

O cluster completo do Apple Ecosystem: MLX no Apple Silicon para o framework de arrays que você incorpora quando quer seu próprio modelo e loop de treinamento; TBDR e memória unificada do Apple Silicon para o substrato de hardware que torna o compartilhamento entre CPU/GPU/Neural Engine viável; Inferência on-device com Core ML para a camada de modelo fixo acima do Core AI; e Foundation Models para o LLM de sistema lacrado da Apple no topo da pilha. O hub está na Apple Ecosystem Series. Para um contexto mais amplo de iOS com agentes de IA, veja o guia de iOS Agent Development.

Referências