Core ML vs MLX vs Foundation Models: como escolher o stack de IA no dispositivo da Apple

A Apple já oferece quatro formas distintas de rodar um modelo no hardware dos seus usuários, e escolher a errada custa uma reescrita. No M2 Max em que escrevo isto, o MLX sustenta 11.2 TFLOPS de matemática matricial fp16 e move dados a 351 GB/s de largura de banda medida em memória unificada¹. Para a maioria dos apps, esse poder é a escolha errada, porque o framework Foundation Models já embutido resolve a tarefa em seis linhas de Swift e sem somar um único megabyte ao download. Os quatro frameworks não são concorrentes. São quatro respostas diferentes para uma única pergunta: de quem é o modelo e quem cuida da execução?

TL;DR

• Foundation Models é o padrão. Se o LLM no dispositivo da Apple, um generalista de ~3B parâmetros, der conta da tarefa (resumir, extrair, classificar, gerar saída estruturada, chamar as suas ferramentas), você não envia nenhum peso de modelo, não paga custo de inferência e herda de graça cada melhoria do modelo que chega com o sistema.²
• Core ML serve para entregar o seu modelo treinado dentro de um app. É o único caminho com despacho de primeira classe para o Neural Engine, empacotamento compatível com a App Store e um contrato de compilação antecipada que troca flexibilidade por duração de bateria e previsibilidade.³
• MLX entra quando o modelo é o produto: pesquisa, fine-tuning, execução de LLMs de pesos abertos ou qualquer carga em que você precisa de controle direto sobre os tensores. É uma ferramenta de máquina de desenvolvimento e de app para Mac, não um veículo de distribuição no iOS.⁴
• Core AI (iOS 27) é o novo alicerce debaixo de tudo isso: um framework de execução de modelos de baixo nível, com tensores NDArray e escolha explícita das unidades de computação, para times que hoje forçam o Core ML a virar um runtime de tensores.
• A decisão costuma caber em uma pergunta: modelo embutido → Foundation Models; seu modelo no iOS → Core ML; seu modelo no seu Mac → MLX; controle no nível dos tensores no iOS → Core AI. O resto deste post trata dos 20% de casos em que essa heurística quebra.

A pergunta por trás da pergunta

Todo debate sobre “qual framework” que já acompanhei acaba se reduzindo a dois eixos. (Escrevi uma análise aprofundada de cada um deles: Foundation Models, Core ML, MLX, Core AI.)

Primeiro eixo: de quem são os pesos? O modelo embutido da Apple, um modelo que você treinou ou converteu, ou pesos abertos que você baixou de um hub. O Foundation Models só roda o modelo da Apple (mais os seus adaptadores no estilo LoRA).⁵ Core ML e MLX só rodam os pesos que você fornece. Esse único fato elimina metade do espaço de opções antes mesmo de o desempenho entrar na conversa.

Segundo eixo: quem é dono da execução? O Foundation Models esconde tudo: nada de tensores, nada de unidades de computação, nenhum gerenciamento de janela de contexto além de um objeto de sessão. O Core ML esconde quase tudo: você entrega um .mlmodelc compilado e sugere unidades de computação; o framework decide o despacho. O MLX não esconde nada: você escreve a matemática dos arrays, e a avaliação preguiçosa somada à memória unificada é todo o seu ferramental. O Core AI fica entre Core ML e MLX: tensores explícitos e escolha das unidades de computação, mas execução gerenciada pela Apple.

Coloque qualquer recurso real nesses dois eixos e o framework se escolhe sozinho.

Foundation Models: o padrão de zero megabyte

O framework que a maioria dos times deveria testar primeiro é o que não exige modelo nenhum. O Foundation Models expõe o LLM no dispositivo por trás do Apple Intelligence através de LanguageModelSession, e o recurso matador dele não é o modelo. É a geração guiada: você anota uma struct Swift com @Generable e o framework restringe a decodificação para que a saída do modelo seja o seu tipo, em vez de uma string que você analisa na base da fé.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

Essa é a integração inteira. Sem etapa de download, sem decisões de quantização, sem comportamento térmico para antecipar; o sistema agenda o modelo, compartilha ele entre todos os apps do aparelho e o atualiza a cada versão. A chamada de ferramentas deixa o modelo invocar funções que você define, o que já basta para construir recursos genuinamente agênticos sem servidor algum.²

A restrição é simétrica: o modelo é um generalista de ~3B parâmetros. Ele resume, extrai, classifica e entrega bem saída estruturada; não faz conhecimento de mundo em domínio aberto, nem análise de documentos com contexto longo, nem nada do que um modelo de fronteira faz. Quando o modelo embutido não basta, a resposta da Apple são os adaptadores (fine-tunes no estilo LoRA que você treina com o toolkit da Apple sobre o modelo base), mas um adaptador é um compromisso: você o retreina toda vez que a Apple atualiza o modelo base.⁵ Minha análise completa, incluindo gerenciamento de sessão e os modos de falha que os revisores encontram, está no mergulho profundo em Foundation Models.

Escolha quando: a tarefa tiver forma de linguagem, o modelo embutido passar na sua régua de qualidade e entregar zero peso importar. Isso cobre mais recursos do que a maioria dos times imagina; teste antes de recorrer a qualquer coisa abaixo.

Core ML: seu modelo, execução da Apple

O Core ML responde a outra pergunta. Você já tem um modelo (um classificador de visão, um modelo de embeddings, um pipeline de fala, um LLM destilado) e ele precisa rodar dentro de um app iOS, na bateria, dentro dos limites de tamanho da App Store, ainda este ano.

O contrato é de compilação antecipada. Você converte os pesos com coremltools, o modelo compila para .mlmodelc e, em tempo de execução, o framework despacha entre Neural Engine, GPU e CPU; a ANE é justamente a parte que nada mais nesta lista te dá no iOS hoje. A etapa de conversão é onde mora a engenharia de verdade: cobertura de operadores, quantização (paletização, linear de 8/4 bits, esparsidade; o stack de otimização do coremltools é realmente profundo⁶) e as dicas de unidade de computação que decidem se o seu modelo roda a 2 watts ou a 8. Os padrões que de fato sobrevivem à produção (dicas de despacho, orçamentos de latência, a escada de quantização) são o assunto do pilar sobre Core ML.

O que o Core ML não faz também pesa na decisão: ele não treina, não faz fine-tuning e não te entrega tensores no meio do grafo. É um eletrodoméstico de inferência. Times que precisam de “rodar meu grafo E cutucar os resultados intermediários” historicamente contorceram o Core ML até virar um runtime de tensores; essa contorção é exatamente o que o Core AI agora existe para absorver.

Escolha quando: os pesos forem seus, o alvo for iOS/iPadOS (ou multiplataforma dentro da Apple) e bateria, tamanho ou ANE importarem. Ou seja: quase todo recurso com modelo próprio já entregue na plataforma.

MLX: a máquina de pesquisa dentro do seu Mac

O MLX é o estranho no ninho: um framework de arrays de código aberto do grupo de pesquisa em ML da Apple, e não um framework do sistema.⁴ Ele parece o NumPy, avalia de forma preguiçosa e trata a memória unificada do Apple silicon como o recurso que ela é: nenhuma cópia de host para dispositivo, porque não existe memória de dispositivo separada.

Os números desta máquina deixam o argumento concreto. Um M2 Max sustenta 11.2 TFLOPS de matmul fp16 em 4096×4096 e 351 GB/s de largura de banda de streaming medida sob o MLX sem nenhum ajuste¹: o suficiente para rodar interativamente modelos de pesos abertos quantizados de 30B parâmetros, fazer fine-tuning de modelos de 7B com LoRA de um dia para o outro e iterar em treinos que, de outra forma, significariam alugar GPUs na nuvem. Com o ecossistema mlx-lm, a maioria dos modelos abertos está a um pip install e um download de distância.

Os limites são igualmente concretos. Sem Neural Engine: o MLX programa a GPU (e a CPU), não a ANE. Sem história de distribuição no iOS: dá para embutir tecnicamente, mas a distribuição dos pesos, o comportamento térmico e as diretrizes de revisão fazem dele a ferramenta errada; o MLX é para o seu Mac, os Macs dos seus usuários e o seu ciclo de pesquisa. E ninguém gerencia a execução por você: pressão de memória, escolhas de quantização e agendamento das avaliações são responsabilidade sua. O pilar sobre MLX trata de quando “meu próprio modelo, não o da Apple” vale essa responsabilidade.

Escolha quando: você estiver treinando ou fazendo fine-tuning, rodando LLMs de pesos abertos localmente ou construindo ferramentas nativas de Mac em que o controle do modelo é o produto. Se a sua máquina do dia a dia é um Mac com Apple silicon e RAM de verdade, o MLX a transforma em uma estação de trabalho de ML legítima.

Core AI: o novo alicerce

O iOS 27 acrescentou a camada que faltava à Apple: o Core AI, um framework de execução de modelos de baixo nível com tensores NDArray, uma separação entre asset e modelo, escolha explícita das unidades de computação e funções de inferência chamáveis.⁷ É o que você usa quando o contrato do Core ML, “me dê um modelo compilado, receba previsões”, fica rígido demais: pipelines que intercalam matemática de tensores com chamadas ao modelo, pré e pós-processamento próprio que pertence à ANE, grafos multimodelo com buffers compartilhados.

Dois esclarecimentos poupam a maioria dos leitores de uma curva errada. O Core AI não é uma alternativa ao Foundation Models (nessa camada continua não existindo um LLM embutido; você traz os assets compilados). E não é o MLX no iOS: sem treinamento, sem autograd, sem ciclo eager de pesquisa. É a casa de máquinas do Core ML com a escotilha aberta. Se você nunca brigou com a abstração do Core ML, não precisa do Core AI; no momento em que você já entregou acrobacias com MLMultiArray ou encadeou modelos por meio de conversões desnecessárias, já precisa. O modelo de tensores e a API de escolha estão cobertos no pilar sobre Core AI.

Os casos que realmente viram discussão

“Precisamos de um LLM, mas o nosso, ou um maior.” O Foundation Models não consegue carregar pesos externos, ponto final. Um LLM pequeno destilado via Core ML funciona e te dá a ANE; um modelo aberto quantizado via MLX funciona no Mac. Seja honesto sobre a alternativa que ninguém no time do dispositivo quer dizer em voz alta: se a tarefa exige qualidade de fronteira, a resposta é uma chamada de servidor, e as camadas no dispositivo cuidam do fallback e dos subconjuntos sensíveis à privacidade.

“Queremos um stack só para iPhone e Mac.” Foundation Models e Core ML são multiplataforma dentro do ecossistema da Apple; o MLX, na prática, é só para Mac. Times que entregam um app profissional de Mac mais um companheiro para iOS costumam ficar com MLX no Mac (modelos grandes, pesos fornecidos pelo usuário) e Core ML ou Foundation Models no iOS: mesmo recurso, dois motores e uma admissão honesta de que os aparelhos são diferentes.

“Já temos um pipeline em Core ML; o Core AI é um alvo de migração?” Só onde o pipeline dói. O Core AI absorve as bordas com cara de tensor; o núcleo de modelo compilado que funciona hoje continua funcionando. Migrar em bloco uma implantação saudável de Core ML não compra nada.

“SwiftData ou App Intents mudam alguma coisa nisso?” São adjacentes, não sobrepostos: a sua camada de modelos alimenta recursos que o App Intents expõe ao sistema, e tudo o que você persiste obedece às regras de esquema do SwiftData. Os frameworks tratados aqui decidem como a inferência roda, não como o app ao redor dela é construído.

Uma árvore de decisão

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

Pontos principais

Para times de app que entregam recursos: - Prototipe primeiro contra o Foundation Models; seis linhas de Swift são o experimento mais barato possível, e “o modelo embutido já basta” é a surpresa mais comum. - Orce o tempo de conversão para Core ML separadamente do tempo de inferência; a cobertura de operadores e a quantização são onde as semanas vão embora.

Para engenheiros de ML: - Um Mac com Apple silicon e 64GB+ é uma bancada real de fine-tuning sob o MLX; meça antes de alugar GPUs na nuvem. Os números de 11.2 TFLOPS / 351 GB/s citados acima saíram de um chip de notebook de duas gerações atrás.¹ - A ANE segue sendo a vantagem defensável do Core ML e, agora, do Core AI. Se o consumo de bateria por inferência importa, nenhum caminho por GPU compete.

Para arquitetos: - Trate os quatro frameworks como camadas, não como rivais: Foundation Models para recursos de linguagem, Core ML para modelos próprios entregues, Core AI para as bordas de tensores, MLX para o Mac e o laboratório. Implantações mistas são a norma em apps sérios, não um sinal de alerta. - A propriedade do modelo é o centro de custo de longo prazo: a Apple mantém os pesos do Foundation Models, você mantém os de todo o resto. Coloque isso na conta da escolha.

Perguntas frequentes

Qual framework da Apple devo usar para rodar um modelo no dispositivo?

A decisão costuma caber em uma pergunta. Modelo embutido: use Foundation Models; seu modelo no iOS: use Core ML; seu modelo no seu Mac: use MLX; controle no nível dos tensores no iOS: use Core AI. Coloque o recurso em dois eixos, de quem são os pesos que ele roda e quem é dono da execução, e o framework se escolhe sozinho. Trate os quatro como camadas, não como rivais; implantações mistas são a norma em apps sérios.

O Foundation Models consegue rodar os meus próprios pesos de modelo?

Não. O Foundation Models só roda o modelo embutido da Apple no dispositivo, um generalista de aproximadamente 3B parâmetros, mais os seus adaptadores no estilo LoRA. Ele não consegue carregar pesos externos, ponto final. Se você precisa do seu próprio LLM, um modelo pequeno destilado via Core ML funciona e te dá o Neural Engine, e um modelo aberto quantizado via MLX funciona no Mac. Se a tarefa exige qualidade de fronteira, a resposta é uma chamada de servidor.⁵

Posso entregar o MLX dentro de um app iOS?

Não de forma realista. O MLX é um framework de arrays de código aberto do grupo de pesquisa em ML da Apple, e não um framework do sistema, programa a GPU e a CPU sem nenhum acesso ao Neural Engine, e a distribuição dos pesos, o comportamento térmico e as diretrizes de revisão fazem dele a ferramenta errada para um bundle iOS. O MLX é para o seu Mac, os Macs dos seus usuários e o seu ciclo de pesquisa.⁴

Qual é a diferença entre Core ML e Core AI?

O Core ML é inferência com compilação antecipada: você entrega um .mlmodelc compilado, sugere unidades de computação e o framework decide o despacho. O Core AI, acrescentado no iOS 27, é essa mesma casa de máquinas com a escotilha aberta: tensores NDArray, separação entre asset e modelo e escolha explícita das unidades de computação. Ele continua sem treinar e sem trazer um LLM embutido. Se você nunca brigou com a abstração do Core ML, não precisa dele.⁷

Quão rápido é um M2 Max para machine learning local?

No M2 Max em que escrevo isto, o MLX sustenta 11.2 TFLOPS de matmul fp16 em 4096×4096 e 351 GB/s de largura de banda de streaming medida, sem nenhum ajuste. Isso já dá para rodar interativamente modelos de pesos abertos quantizados de 30B parâmetros e fazer fine-tuning de modelos de 7B com LoRA de um dia para o outro. Meça antes de alugar GPUs na nuvem; esses números saíram de um chip de notebook de duas gerações atrás.¹

Referências