Core AI: executando modelos no Apple Silicon

Faltava um degrau na pilha de IA no dispositivo da Apple. O Foundation Models entrega o LLM do sistema, lacrado e gratuito. O Core ML executa um modelo convertido e fixo, com o conversor tomando as decisões de hardware por você. O MLX oferece um framework de arrays que você incorpora e um modelo que você escolhe. O iOS 27 acrescenta o degrau abaixo dos três: o Core AI, um framework cujo resumo de uma linha é “Run AI models in your app on Apple silicon”.¹ É a camada de execução de modelos, o lugar ao qual você recorre quando quer conduzir você mesmo a especialização, o cache e o agendamento da 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 move a Apple Intelligence no dispositivo, agora aberto para a inteligência do seu próprio app.¹⁵

Esse enquadramento importa porque o Core AI fica abaixo das abstrações que a maioria dos apps deveria usar. A Apple o descreve como projetado tendo o Apple silicon em mente: ele permite que o seu app use as arquiteturas de modelos e as técnicas de inferência mais recentes na CPU, na GPU e no Neural Engine, com uma API em Swift que simplifica as tarefas comuns e, quando necessário, dá mais controle sobre a especialização do modelo, o cache e o desempenho da inferência.¹ A tese deste artigo: recorra ao Core AI quando 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 for o caso. 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 (inspecionar a estrutura e os metadados de um modelo a baixo custo) de um AIModel especializado (executar inferência em um dispositivo), com o AIModelCache guardando os artefatos específicos do dispositivo e o AssetError para falhas em operações com assets.²³⁶⁴
• Os dados de inferência passam pelo 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ê escolhe o hardware com ComputeUnitKind (CPU, GPU ou Neural Engine) por meio de SpecializationOptions, e agenda o trabalho assíncrono em um ComputeStream.⁸⁹¹⁰
• Uma InferenceFunction é dona dos pesos e dos buffers e executa a inferência; um InferenceFunctionDescriptor permite inspecionar antes a assinatura de entradas, saídas e estados. A função é Sendable, então você pode executá-la de forma concorrente.¹⁴¹³
• Os modelos são carregados de um bundle .aimodel em disco. O ferramental em torno do framework agora está documentado: o pacote Python coreai-torch converte modelos PyTorch, a CLI coreai-build compila .aimodel em assets .aimodelc por arquitetura antecipadamente, e o app Core AI Debugger, um medidor de depuração no Xcode e um modelo do Instruments cobrem a inspeção e o profiling.¹⁷ 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 sustentam todo o design: asset e modelo

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

Um AIModelAsset é “an unspecialized source model asset”.² Você o cria a partir da URL de um bundle .aimodel em disco e o usa para inspecionar um modelo sem pagar o custo da especialização. A Apple é explícita sobre o motivo dessa separação: 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ê lê 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 consegue 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: “a specialized model for running inference on a device”.³ 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 modelo responde execute-o aqui, agora. A assimetria de custo entre os dois é a razão pela qual a API obriga você a dizer qual dos dois quer. Inspecionar cem modelos candidatos para escolher um sai barato se você só constrói assets; seria ruinoso se cada inspeção especializasse.

A especialização produz artefatos específicos do dispositivo, e esses artefatos têm um lar: o AIModelCache, “a cache that stores the specialized model artifacts for inference”.⁶ 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 de uma combinação de especialização.⁶ A leitura prática: especialização não é algo que você queira repetir a cada inicialização. O cache é a forma como o Core AI deixa o passo caro acontecer uma vez e o passo barato, carregar os artefatos em cache, acontecer daí em diante.

Quando operações com assets dão errado (um bundle ausente, um .aimodel malformado, um arquivo ilegível), o Core AI expõe um AssetError, “an error that occurs during model asset operations”.⁴ Trate-o como qualquer fronteira de entrada e saída: o asset vive em disco, operações de disco falham, e o sistema de tipos diz exatamente onde colocar o catch.

Tensores: NDArray e seu descritor

A inferência move números para dentro e para fora, e o contêiner do Core AI para esses números é o NDArray, “a multidimensional array of scalar values used for model inference”.⁵ 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 pela sua forma e pelo restante de suas propriedades descritivas.⁵

O tipo companheiro é o NDArrayDescriptor, “a description of an array’s shape, scalar type, and memory layout expectations”.⁷ Um descritor é o contrato. A formulação da Apple é direta: o descritor contém as expectativas para um valor de array que você fornece a uma função de inferência, e a maioria dessas expectativas é estrita. Se o descritor especifica o tipo escalar .float32, o array que você fornecer precisa usar .float32.⁷ Você não adivinha a forma nem o tipo que uma função quer; você pergunta ao descritor da função e se ajusta 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 separação entre asset e modelo. O Core AI coloca de forma consistente um objeto de descrição barato na frente de um objeto de valor caro. Você lê o descritor para conhecer o contrato e então aloca o NDArray que o satisfaz, em vez de alocar primeiro e descobrir uma incompatibilidade na hora da inferência. Para entradas de imagem em particular, o Core AI também define um ImageDescriptor, “a description of an image’s dimensions and pixel format”, de modo que a entrada em pixels de um modelo de visão recebe o mesmo tratamento com o descritor em primeiro lugar.¹¹

Escolhendo onde a inferência roda

O Apple silicon tem três lugares para calcular: CPU, GPU e Neural Engine. A razão de o Core AI existir, e não apenas o Core ML, é que o Core AI deixa você dizer qual deles o framework mira, em vez de deduzir isso.

ComputeUnitKind é “a type of hardware compute unit available for model inference”.⁸ Você usa os tipos de unidade de computação junto com as opções de especialização para controlar qual hardware o framework mira 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 queira fixar no Neural Engine, uma passagem de depuração que queira forçar na CPU, um pipeline pesado em GPU que esteja coordenando com outro trabalho de GPU).

Você transmite essa intenção por meio de SpecializationOptions, a estrutura que carrega as escolhas feitas no momento da especialização.⁹ A especialização é o passo caro mencionado antes, e é em SpecializationOptions que moram a escolha de unidades de computação e as demais decisões de especialização. Como uma entrada de cache é indexada por um asset e uma combinação de especialização específicos, mudar suas opções muda qual artefato em cache você recebe de volta, o que fecha o ciclo entre a escolha de hardware e o cache.⁶

O agendamento é o outro eixo do “como isso roda”, e o Core AI o modela como um ComputeStream, “a stream of work to be run asynchronously”.¹⁰ Um stream de computação é o que você fornece para codificar trabalho nele, e a Apple observa que várias inferências codificadas no mesmo stream são serializadas conforme necessário, com base nos valores lidos e escritos.¹⁰ Duas implicações se seguem. Primeira, um stream é a sua primitiva de ordenação: codifique inferências dependentes em um stream e o Core AI as sequencia por dependência de dados. Segunda, o trabalho é assíncrono por padrão, então o stream também é a maneira de manter livre a thread chamadora enquanto o Neural Engine ou a GPU faz o trabalho.

Funções de inferência: o 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 torre de visão, um passo de prefill em contraste com um de decode), e a unidade de execução do Core AI é a InferenceFunction: “a function that performs inference on input values and produces output values”.¹⁴

Antes de chamar uma, você a inspeciona. InferenceFunctionDescriptor é “a description of an inference function’s signature”, e você usa um descritor para inspecionar os nomes e os tipos das entradas, das saídas e dos estados de uma função antes de executar a inferência.¹³ Os estados são o detalhe em que vale a pena parar: uma função com estado é o modo como um modelo com estado — um cache KV no laço de decode de um transformer, por exemplo — mantém informação entre chamadas, e o descritor avisa que uma função os tem antes de você tentar operá-la.

A própria InferenceFunction é dona dos recursos de 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 é citada na própria explicação da Apple, então as três coisas de que uma chamada precisa ficam explícitas: os valores de entrada, os valores de estado e as views de saída que você quer que sejam escritas.

// 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 de forma concorrente a partir de várias tarefas, e a Apple observa que ela aloca automaticamente buffers intermediários adicionais conforme necessário para sustentar essa concorrência.¹⁴ Você não serializa chamadas atrás de um lock para proteger um espaço de rascunho compartilhado; a função gerencia os próprios buffers para cada chamador concorrente. Essa é uma diferença relevante em relação a APIs em que um único handle de inferência é, na prática, de thread única.

Os valores que passam por run são instâncias de InferenceValue, “a value that an inference function accepts as input or produces as output”.¹² Um InferenceValue envolve ou um NDArray ou um buffer de pixels, e você recupera um resultado após a inferência usando a propriedade value dele.¹² É esse invólucro que permite a uma única assinatura de run carregar entradas tensoriais e entradas de imagem sem sobrecargas separadas: um modelo de texto passa valores apoiados em NDArray, um modelo de visão passa valores apoiados em buffer de pixels, e a função lê o descritor para saber qual deles espera.

Quando recorrer ao Core AI

A parte mais difícil do Core AI não é a API. É saber que você deve estar aqui, e não 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, produzir saída estruturada: isso pertence ao framework Foundation Models, que não custa pesos, nem orçamento de memória, nem passo de especialização. Se o seu recurso se encaixa ali, pare por ali. Descer até o Core AI para reimplementar o que o modelo de sistema já faz é trabalho jogado fora.
• Core ML quando você tem um modelo convertido e fixo e quer que o conversor tome as decisões de hardware e otimização por você. O Core ML mira o Neural Engine com consumo e latência apertados para um modelo de produção fechado, e não exige nada de você em matéria de especialização ou agendamento. Se você não quer pensar em escolha de unidades de computação nem em streams de computação, esse é o sinal para ficar no Core ML.
• MLX quando você quer um framework de arrays de nível de pesquisa que incorpora e sobre o qual itera: o seu próprio laço de treinamento, modelos de pesos abertos quantizados, ajustes finos com LoRA, experimentação rápida. O MLX é uma biblioteca que você distribui junto com os pesos, não uma camada de execução de modelos do sistema. Ele ganha em flexibilidade e em velocidade de iteração.
• Core AI quando você tem um modelo para executar e quer as alavancas explícitas 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 InferenceFunction que você chama de forma concorrente. Você chega aqui quando os padrões das camadas superiores são exatamente o que está no seu caminho, e você consegue nomear qual padrão precisa sobrescrever.

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

Uma declaração feita em um lab da WWDC 2026 afia onde fica a linha entre Core AI e Core ML para o trabalho novo. Parafraseado a partir 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 no lugar, porém voltado ao aprendizado de máquina tradicional, como árvores de decisão, e com tudo o que é novo indo para o Core AI.¹⁶ Leia isso como um sinal de direção vindo de quem constrói o framework, e não como uma política documentada: se você vai recorrer a uma rede neural em um projeto novo, o lab apresentou o Core AI como a camada sobre a qual construir.

Como um modelo chega ao Core AI

O framework é a metade de tempo de execução de um fluxo de trabalho maior e, desde os betas de junho, a Apple publicou a metade de ferramental por completo.¹⁷ O pipeline funciona assim.

Converter. Você começa com um arquivo .aimodel, seja convertido de um modelo de origem com o pacote coreai-torch (as Core AI PyTorch Extensions da Apple para Python), seja já preparado nesse formato.¹⁷ O .aimodel entra no seu target do Xcode como qualquer outro recurso, aparece na fase de build Compile Sources e ganha um visualizador de modelo no Xcode que mostra parâmetros, tamanho de armazenamento, metadados e o grafo de operações. Uma dependência do sistema de build para conhecer logo de início: a integração de modelos do Core AI exige o Metal Toolchain, que o Xcode não instala por padrão, e sem ele builds que contêm arquivos .aimodel falham com um erro de compilador Metal ausente.¹⁷

Compilar antecipadamente, opcionalmente. A especialização acontece automaticamente quando você cria um AIModel, e em modelos grandes esse custo de primeiro carregamento é real. A ferramenta de linha de comando coreai-build move a parte mais cara, a compilação do modelo, para a sua máquina de build: ela converte .aimodel em assets .aimodelc, um por arquitetura de dispositivo (compilar MyModel.aimodel produz MyModel.<arch>.aimodelc), e em tempo de execução o app escolhe o asset correspondente ao dispositivo atual, de modo que o Core AI pula a etapa de compilação.¹⁷ A compilação antecipada mira o piso de hardware da Apple Intelligence: iPhone ou iPad com A17 Pro ou posterior, Macs com M1 ou posterior e o Apple Vision Pro com M2.¹⁷

Depurar e fazer profiling. Três ferramentas cobrem a observabilidade: o Core AI Debugger, um app de macOS independente para inspecionar o grafo de operações de um modelo, executá-lo em um dispositivo e comparar as saídas com uma execução de referência; um medidor de depuração do Core AI no Xcode, que monitora ao vivo o carregamento, a especialização e a atividade de inferência durante uma sessão de depuração; e um instrumento do Core AI, um modelo do Instruments que faz o profiling dos tempos de execução na CPU, na GPU e no Neural Engine.¹⁷

O formato de tempo de execução descrito antes se encaixa nesse fluxo sem alterações: o modelo preparado é carregado como um AIModelAsset para inspeção, especializado em um AIModel e executado por suas InferenceFunction, com o AIModelCache guardando os artefatos especializados para que o passo caro aconteça uma única vez.¹²³⁶¹⁴

Perguntas frequentes

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 “Run AI models in your app on Apple silicon”.¹ Ele executa a inferência de modelos na CPU, na GPU e no Neural Engine por meio de uma API em Swift que simplifica as tarefas comuns e, quando você precisa, dá controle sobre a especialização do modelo, o cache e o desempenho da inferência.¹ Ele fica abaixo do Foundation Models e do Core ML como camada de execução de modelos.

Qual é a diferença entre AIModelAsset e AIModel?

AIModelAsset é um asset de origem não especializado que você cria a partir da URL de um bundle .aimodel em disco; você o usa para inspecionar assinaturas de funções, descrições de entrada e saída, tipos de computação e de armazenamento e metadados de um modelo sem especializar, porque a especialização é cara, e um asset não pode executar inferência.² 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 separação permite inspecionar barato e especializar apenas quando você se compromete.

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

Você controla a escolha de hardware com ComputeUnitKind por meio de SpecializationOptions. Um tipo de unidade de computação nomeia um tipo de unidade de hardware disponível para inferência, e você o usa para controlar qual hardware o framework mira ao especializar um modelo; por padrão, a especialização usa todas as unidades de computação disponíveis no dispositivo.⁸⁹ Você só sobrescreve o padrão 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 executá-la?

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 um InferenceFunctionDescriptor, que descreve os nomes e os tipos das entradas, das saídas e dos estados da função, depois carrega a função a partir de um AIModel e chama run(inputs:states:outputViews:).¹³¹⁴ A função é Sendable e aloca buffers intermediários automaticamente para sustentar a concorrência, de modo que várias tarefas 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 convertido e fixo e quer que o conversor tome as decisões de hardware e otimização por você. Recorra ao Core AI quando quiser controle explícito sobre especialização (SpecializationOptions, ComputeUnitKind), cache (AIModelCache) e agendamento (ComputeStream) de que as camadas superiores cuidam por você.⁸⁹⁶¹⁰ Se você não consegue nomear o controle de que precisa, fique uma camada acima.

O cluster completo do Ecossistema Apple: MLX no Apple Silicon para o framework de arrays que você incorpora quando quer o seu próprio modelo e o seu próprio laço de treinamento; o TBDR e a memória unificada do Apple Silicon para o substrato de hardware que faz o compartilhamento entre CPU, GPU e Neural Engine funcionar; a inferência no dispositivo 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 ponto central está na Série Ecossistema Apple. Para um contexto mais amplo de iOS com agentes de IA, veja o guia de desenvolvimento de agentes no iOS.

Referências