MLX no Apple Silicon: quando você precisa do seu próprio modelo, e não do da Apple

O framework Foundation Models da Apple te entrega um único modelo: o do sistema, lacrado, gratuito e atualizado no calendário da Apple. Para a maior parte do trabalho de linguagem on-device, essa é a ferramenta certa, e passar por cima dela é um erro. Mas há trabalhos que exigem um modelo escolhido por você: um LLM open-weight específico, uma versão que você fixa, um fine-tune treinado com seus próprios dados ou uma capacidade que o modelo do sistema não tem. Quando você precisa do seu próprio modelo rodando no dispositivo, a camada abaixo do Foundation Models é o MLX¹.

O MLX é o framework de arrays da Apple para machine learning no Apple Silicon, com uma API em Swift (MLX Swift) que você embute diretamente no app². Não é um framework de sistema que você chama; é uma biblioteca que você distribui com o app, junto com os pesos do modelo. Essa diferença é o trade-off inteiro, e entendê-la é o que permite decidir entre descer uma camada ou ficar onde a Apple te colocou.

TL;DR

• O MLX é um framework de arrays no estilo NumPy feito para o Apple Silicon, com avaliação preguiçosa, transformações de funções componíveis e backend em Metal².
• O modelo de memória unificada é o motivo de isso funcionar num celular. Os arrays vivem em um único pool de memória compartilhado entre CPU e GPU, então o MLX roda nos dois sobre os mesmos buffers, sem o imposto de cópia entre host e dispositivo³.
• Rode um LLM open-weight no dispositivo com LLMModelFactory, apontando para um modelo quantizado como mlx-community/Llama-3.2-3B-Instruct-4bit, e gere texto por meio de uma ChatSession⁴.
• Faça fine-tuning com adaptadores LoRA: treine um adaptador pequeno, distribua o adapters.safetensors e o load(into:) troca as camadas Linear do modelo base por LoRALinear em tempo de execução⁵.
• O custo de ter seu próprio modelo: tamanho do app (os pesos são grandes), pressão de memória, nenhuma integração com o sistema e a responsabilidade por cada atualização. O Foundation Models não tem nenhum desses custos porque quem paga é a Apple.

O que é o MLX, e por que o Apple Silicon torna isso possível

O MLX oferece arrays e operações com cara de NumPy, mais as transformações de que o machine learning precisa: diferenciação automática, vetorização e avaliação preguiçosa, que monta um grafo de computação e só o executa quando você lê um resultado². O projeto também anda no ritmo de um framework de pesquisa: o MLX chegou à versão 0.32.0 em julho de 2026 e o MLX Swift, à 0.31.6 na mesma semana, num ritmo de lançamentos de aproximadamente um a cada poucas semanas⁷. Fixe suas versões e conte com uma API que continua crescendo. Isso sozinho descreve uma dúzia de frameworks. O que faz o MLX rodar um modelo de bilhões de parâmetros num aparelho que cabe no bolso é o modelo de memória.

Numa GPU de desktop, os dados vivem na RAM do sistema e você os copia por um barramento até a memória separada da GPU para computar, e depois copia os resultados de volta. Essa cópia é o imposto, e para um modelo grande ela é brutal. O Apple Silicon tem memória unificada: um único pool endereçado diretamente por CPU, GPU e Neural Engine. O MLX foi construído em torno desse fato³. Um array não está “na CPU” nem “na GPU”; ele está na memória, e qualquer processador opera sobre ele ali mesmo. Sem cópias, sem imposto de barramento. Um modelo de 3 bilhões de parâmetros quantizado em 4 bits cabe em poucos gigabytes e roda sem as idas e voltas que tornariam o mesmo trabalho inviável numa máquina com GPU dedicada e memória equivalente. A decisão de hardware que a Apple tomou anos atrás é o motivo de a inferência on-device de um modelo de verdade ser viável, e a arquitetura de memória unificada baseada em tiles é o substrato sobre o qual o MLX se apoia.

Rodando um LLM no dispositivo

O caminho entre “quero um modelo específico” e texto na tela é curto. A camada de LLM do MLX Swift carrega um modelo quantizado do Hugging Face Hub e o executa⁴:

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

Para uma UI token a token, gere um stream e renderize os pedaços conforme eles chegam⁴:

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

Dois detalhes carregam quase todo o peso prático. Primeiro, o 4bit no identificador do modelo não é enfeite opcional: a quantização é o que faz o modelo caber na memória e rodar em velocidade utilizável no dispositivo. Você distribui pesos de 4 bits (ou menos), não em precisão total. Segundo, os pesos são grandes mesmo quantizados, então é uma decisão deliberada empacotá-los no app (imediato, mas com um download pesado) ou baixá-los na primeira execução (binário enxuto, mas com espera e um caminho de falha para tratar). O Foundation Models nunca coloca essa questão porque o modelo já está no aparelho. Com o MLX, os pesos são problema seu.

Fine-tuning: um adaptador LoRA, não um modelo novo

O motivo para trazer seu próprio modelo raramente é o modelo base em si; é ensinar a ele o seu domínio. Fazer fine-tuning completo de um modelo de bilhões de parâmetros no dispositivo não é o caminho. LoRA (low-rank adaptation) é o caminho: você treina um conjunto pequeno de pesos adaptadores que ajustam o comportamento do modelo base, deixando a base intacta. O adaptador tem megabytes, não gigabytes⁵.

O MLX Swift carrega um adaptador treinado a partir de um diretório com adapter_config.json e adapters.safetensors, e o aplica a um modelo já carregado num container⁵:

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

O load(into:) substitui as camadas Linear padrão do modelo por camadas LoRALinear, que incorporam os deltas de baixo posto do adaptador, de modo que a inferência passa a refletir o seu fine-tune. Como o modelo vive dentro do container, você aplica o adaptador via container.update, e pode trocar adaptadores a quente em tempo de execução (unload(from:) de um, load(into:) de outro) para dar comportamentos diferentes a um mesmo modelo base em cada recurso. O padrão espelha o que a Apple oferece para o modelo do sistema por meio dos adaptadores personalizados do Foundation Models: a diferença é que aqui o modelo base, o pipeline de treinamento e o resultado são seus, em vez de adaptar um modelo que você não consegue enxergar.

A decisão: Foundation Models, MLX ou nuvem

São três camadas, e escolher errado custa capacidade ou uma pilha de trabalho evitável.

• Foundation Models quando o modelo do sistema dá conta da tarefa. Gratuito, privado, zero pesos para distribuir, zero memória para gerenciar e integração com o sistema que sai de graça. O padrão é começar aqui. As tarefas de linguagem on-device para as quais a Apple o construiu (resumir, classificar, extrair, reescrever, saída estruturada) pertencem a esta camada, ponto final.
• MLX quando você precisa de um modelo que o sistema não oferece: um LLM open-weight específico, uma versão fixada que não muda debaixo dos seus pés a cada atualização do sistema operacional, um fine-tune de domínio ou uma arquitetura (um modelo de visão e linguagem, um modelo não textual) fora do escopo do Foundation Models. Você paga em tamanho do app, memória e responsabilidade, e compra controle.
• Nuvem quando o modelo realmente precisa ser grande: raciocínio de fronteira, análise de contexto longo, qualquer coisa que os maiores modelos fazem e que um modelo on-device de poucos bilhões de parâmetros não consegue. On-device não substitui um modelo de fronteira; é outro ponto da curva.

A leitura honesta: o MLX é um passo para baixo dado de propósito, por um motivo específico, e não um padrão melhor. Se você não sabe nomear a capacidade que falta no Foundation Models para o seu recurso, você não precisa do MLX, e distribuí-lo significa carregar gigabytes de pesos e um orçamento de memória que você não era obrigado a ter.

O iOS 27 acrescenta uma quarta camada a esse mapa. O Core AI é o framework de sistema da Apple para rodar um modelo fornecido por você, com controle explícito sobre especialização, cache e agendamento de unidades de computação. Ele se sobrepõe ao MLX no nível “seu modelo, no dispositivo”, mas vindo da direção oposta: o Core AI é uma superfície de execução gerenciada pelo sistema para um .aimodel já preparado, enquanto o MLX é uma biblioteca que você embute, com seu próprio loop de treinamento, quantização e iteração dentro dela. Se a sua necessidade é rodar rápido um modelo convertido sob gestão do sistema, o Core AI disputa a vaga; se a sua necessidade é experimentar, fazer fine-tuning ou ser dono do pipeline inteiro, o MLX continua sendo a ferramenta.⁶

Quando não recorrer ao MLX

• O modelo do sistema já faz isso. Releia as tarefas do Foundation Models. Se a sua está na lista, pare por aqui.
• Você não tem como bancar os pesos. Um modelo pequeno quantizado ainda é um arquivo grande. Se o tamanho do app ou o download na primeira execução for uma restrição real para seus usuários, essa restrição sozinha pode decidir a questão.
• Você precisa do caminho de menor consumo do Neural Engine para um modelo fixo. Para um modelo conhecido e já distribuído, que não muda, o Core ML e seu conversor miram no Neural Engine com o menor consumo e a menor latência, e no iOS 27 o Core AI é a direção declarada da Apple para novos trabalhos de redes neurais, com controle explícito de especialização. O MLX brilha em flexibilidade e iteração em nível de pesquisa; os frameworks de sistema brilham num modelo de produção fechado. São ferramentas diferentes, e “ML on-device” não é uma decisão só.
• Você não vai fazer a manutenção. Ter seu próprio modelo significa ser dono das atualizações, da segurança e do drift dele. A Apple atualiza o modelo do sistema por você. Se você não tem gente para cuidar de um modelo, não adote um.

A habilidade que o MLX recompensa é o comedimento: saber quando usá-lo. O framework é genuinamente notável: um modelo de linguagem de verdade, ajustado ao seu domínio, rodando inteiramente no dispositivo, sem servidor e sem custo por token, sobre um hardware cuja arquitetura de memória foi feita exatamente para isso. Vale recorrer a essa capacidade quando você já nomeou o motivo. Recorra a ela sem motivo e você terá trocado o modelo gratuito, mantido e integrado da Apple por uma cópia mais pesada e sem manutenção que agora é sua. O discernimento é o trabalho inteiro.

FAQ

O que é o framework MLX da Apple?

O MLX é um framework de arrays para machine learning no Apple Silicon, com uma API no estilo NumPy, transformações de funções componíveis (diferenciação automática, vetorização), computação preguiçosa e backend em Metal². O MLX Swift é a API em Swift para embuti-lo em apps, permitindo rodar e fazer fine-tuning dos seus próprios modelos no dispositivo.

Como o MLX usa a memória unificada do Apple Silicon?

Os arrays do MLX vivem em memória compartilhada, então as operações rodam na CPU ou na GPU sem copiar dados entre pools de memória separados³. É exatamente essa propriedade de transferência zero que torna a arquitetura de memória unificada do Apple Silicon eficiente para executar modelos no dispositivo.

Dá para rodar um LLM open-weight no dispositivo com o MLX?

Dá. O LLMModelFactory.shared.loadContainer(from:using:configuration:) carrega um modelo quantizado como mlx-community/Llama-3.2-3B-Instruct-4bit do Hugging Face Hub; a ChatSession te dá respond(to:) para chamadas únicas, e container.generate(input:parameters:) transmite eventos .chunk(text) para saída incremental⁴.

Como faço fine-tuning de um modelo com o MLX?

Com um adaptador LoRA, em vez de um modelo novo. O LoRAContainer.from(directory:) carrega um adaptador de um diretório com adapter_config.json e adapters.safetensors; aplicado via container.update, ele troca as camadas Linear do modelo por camadas LoRALinear e permite trocar adaptadores a quente em tempo de execução⁵.

MLX, Foundation Models ou Core ML: qual usar?

Comece pelo Foundation Models quando o modelo do sistema da Apple dá conta da tarefa (gratuito, privado, zero pesos para distribuir)¹. Recorra ao MLX só quando precisar de um modelo que o sistema não oferece: um LLM open-weight específico, uma versão fixada, um fine-tune de domínio ou uma arquitetura fora do escopo do Foundation Models. Use o Core ML para um modelo de produção fechado que precisa do caminho de menor consumo do Neural Engine, o Core AI no iOS 27 quando quiser execução gerenciada pelo sistema para o seu próprio modelo, com controle explícito de especialização e agendamento, e a nuvem quando o modelo realmente precisar ser de escala de fronteira.

Quando não devo recorrer ao MLX?

Quando o modelo do sistema já resolve, quando você não tem como distribuir gigabytes de pesos, quando um modelo fixo seria melhor atendido pelo caminho de menor consumo do Neural Engine via Core ML, ou quando você não tem gente para cuidar das atualizações, da segurança e do drift de um modelo. O MLX é um passo para baixo dado de propósito, por um motivo nomeado, e não um padrão melhor.