AnyLanguageModel 1.0 faz apps iOS e macOS rodarem IA sem internet

A Hugging Face publicou nesta terça-feira (20 de outubro) a versão 1.0 do AnyLanguageModel, biblioteca Swift↳Swift13 conteúdosSwift 6: Segurança na Corrida de Dados — AtoresDev (Back & Front) · jan 2025Swift no Server-Side: o crescimento do Swift além do iOSDev (Back & Front) · mai 2026IA e Machine Learning com SwiftDev (Back & Front) · out 2025Ver tudo em Dev (Back & Front) → que funciona como substituto direto do Foundation Models, o framework de IA generativa↳IA generativa81 conteúdosIA Generativa: 5 alternativas para começar a usar em 2025AI · jan 2025Gartner Revela o Futuro da IA GenerativaAI · jul 2024IA Generativa: Pesquisa global aponta Brasil como segundo país mais otimista com a tecnologiaAI · mar 2024Ver tudo em AI → da Apple apresentado para iOS, macOS e visionOS. O lançamento veio acompanhado das versões 1.0 do swift-huggingface e do swift-xet, bibliotecas de apoio para baixar modelos do Hub dentro de apps Swift com mais velocidade.

O projeto nasceu em novembro de 2025, um ano antes deste 1.0, a partir de uma demanda recorrente: desenvolvedores queriam testar modelos locais nos apps, mas não queriam reescrever a camada de inferência cada vez que trocassem de provedor. A proposta do AnyLanguageModel é resolver isso com uma única interface que cobre modelo do sistema, modelos open-weight rodando no dispositivo e APIs hospedadas, todos com a mesma sessão de código.

O que muda ao trocar duas palavras no import

A mecânica central do framework é deliberadamente simples. Em vez de import FoundationModels, o app escreve import AnyLanguageModel, e o restante do código de sessão, prompts, streaming, continua igual. Isso significa que um app já escrito contra o Foundation Models da Apple troca de provedor sem reescrever a lógica de conversação.

Na prática, esse é o tipo de desacoplamento que muda decisão de arquitetura, não só linha de código. Um time pode prototipar com o modelo do sistema (gratuito, offline, mas limitado em capacidade), e depois trocar para um modelo maior via Hugging Face Inference Providers só nas features que exigem mais raciocínio, sem duplicar a camada de prompt.

Como rodar modelo local de verdade no dispositivo

O ponto mais relevante do anúncio para quem constrói app Apple é a maturidade dos modelos pequenos que já cabem num iPhone. A Hugging Face lista no post três exemplos de modelos open-weight entre os mais baixados do Hub hoje:

• Gemma 4 E2B, do Google, em formato GGUF, cerca de 3,4 GB em quantização Q4_0 com quantization-aware training;
• LFM2.5 2.6B, da Liquid AI, também em GGUF, cerca de 1,7 GB em Q4_K_M;
• Qwen3.8 27B, da Alibaba, convertido para MLX, cerca de 16 GB em 4 bits.

Os dois primeiros cabem num iPhone. O Qwen3.8 27B já exige um Mac com pelo menos 32 GB de memória unificada para rodar com folga. Selecionar o modelo MLX é uma linha de código:

let model = MLXLanguageModel(modelId: "mlx-community/Qwen3.8-27B-4bit")

Esse recorte de hardware é o dado concreto que separa "roda local de verdade" de "roda local em laboratório". Um app que mira iPhone comum fica restrito aos modelos na faixa de 2 a 3 bilhões de parâmetros; um app que assume Mac como plataforma primária já pode brincar com modelos na casa dos 20 bilhões. A Hugging Face brinca que o GLM-5.3, da Z.ai, cabe em cerca de 1,5 TB em BF16 e só roda razoavelmente em quatro Mac Studios no limite de memória, o que deixa claro onde termina o território do "local" e começa o da nuvem.

Quando faz sentido sair do dispositivo

O AnyLanguageModel não tenta empurrar tudo para o dispositivo. A lista de provedores hospedados suportados na 1.0 cresceu bastante ao longo do ano: Chat Completions e Responses da OpenAI, Open Responses para qualquer endpoint compatível, Messages API da Anthropic (com opções de thinking adaptativo), Gemini API do Google, Ollama, Private Cloud Compute (disponível a partir do OS 27) e Hugging Face Inference Providers, incluindo outros endpoints compatíveis com OpenAI como o OpenRouter, via base URL customizada.

O exemplo que a própria Hugging Face dá no post usa justamente Inference Providers para rodar um modelo grande demais para qualquer dispositivo Apple:

let model = OpenAILanguageModel(
    baseURL: URL(string: "https://router.huggingface.co/v1/")!,
    apiKey: ProcessInfo.processInfo.environment["HF_TOKEN"]!,
    model: "openai/gpt-oss-120b",
    apiVariant: .chatCompletions
)

O ponto de atenção aqui é segurança: a 1.0 trocou a forma de passar a chave de API de string fixa para closure, o que permite que o app busque um token de curta duração no próprio servidor do desenvolvedor em vez de embutir uma chave permanente no binário. O README do projeto detalha quando vale deixar o usuário trazer sua própria chave e quando vale rotear a requisição por um proxy, decisão que normalmente é negligenciada em protótipos e vira dor de cabeça em produção.

Paridade de recursos entre local e hospedado

Um ano atrás, o recorte comum era: modelo local faz o básico, modelo hospedado tem os recursos avançados. A versão 1.0 reduz essa distância em três frentes específicas:

Tool calling agora funciona com todos os provedores, local ou hospedado, o que é o que viabiliza construir um agente que decide chamar função sem se importar se o modelo por trás é o do sistema ou um endpoint remoto.

Guided generation, o equivalente a forçar saída estruturada, também passou a valer para todo provedor, inclusive com tipos @Generable aninhados e arrays deles, recurso útil para quem extrai dados estruturados de texto livre.

Suporte a imagem chegou usando a sintaxe do Foundation Models da versão 27 do sistema operacional da Apple, válida inclusive quando o app usa o modelo do sistema em iOS, macOS e visionOS 27.

Há também uma mudança sutil em como o framework trata raciocínio (reasoning): blocos de thinking agora fazem parte do transcript da conversa e são automaticamente omitidos da requisição quando o app troca para um provedor que não sabe reproduzir esse histórico. Isso evita erro silencioso quando um dev alterna de Anthropic para um modelo local no meio de uma sessão de testes.

O que ainda não está resolvido

O AnyLanguageModel também passou a rodar em Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, o que abre a possibilidade de usar o mesmo código de sessão num servidor, não só no app cliente, algo que a Hugging Face cita de passagem mas não detalha em exemplo. Vale ressalva: multiplataforma de código não significa multiplataforma de desempenho, modelo MLX continua sendo recurso de silício Apple.

No OS 27, o framework também passou a aceitar qualquer modelo que implemente o protocolo LanguageModel do Foundation Models, incluindo os chamados Core AI models da própria Apple, o que sugere que a Apple está deixando a porta aberta para terceiros plugarem modelos próprios no ecossistema do sistema operacional, não só a Hugging Face.

Para quem já tem app rodando em versão anterior, a atualização é via Swift Package Manager:

dependencies: [
    .package(
        url: "https://github.com/huggingface/AnyLanguageModel",
        from: "1.0.0",
        traits: ["MLX"]
    )
]

O post da Hugging Face recomenda conferir as notas de migração do AnyLanguageModel, do swift-huggingface e do swift-xet antes de subir a versão major, já que mudanças como a de API keys por closure exigem ajuste de código, não só de número de versão. A equipe sinaliza que o próximo passo da família de ferramentas é expandir a mesma abordagem para "modelos que decidem e modelos que ouvem", o que aponta para agentes e modelos de voz como próxima fronteira, sem detalhar prazo.

Fonte: Hugging Face Blog