Apple Foundation Models

O que é o Foundation Models Framework da Apple

• API Swift padrão (incluída no iOS/macOS/watchOS/iPadOS/visionOS 27) para modelos de linguagem.
• Suporta ambos:
  • O pequeno modelo on-device da Apple (SystemLanguageModel).
  • Modelos na nuvem conectados por meio de um protocolo comum LanguageModelSession / LanguageModel (por exemplo, Claude, Gemini).
• A mesma API lida com streaming, chamada de ferramentas e saída estruturada; os apps podem trocar de modelo mudando um único construtor.

Detalhes da integração com Claude

• Claude é exposto como um pacote Swift que implementa o protocolo LanguageModel da Apple.
• As solicitações do dispositivo vão diretamente para api.anthropic.com; a Apple não está no caminho da rede e não vê prompts nem respostas.
• O Claude por meio deste framework é apenas na nuvem; offline, apenas o modelo on-device da Apple de cerca de 3B de parâmetros continua funcionando.
• O uso é cobrado em uma conta Anthropic normal, com o preço padrão da API.

On-device vs nuvem e preocupações com armazenamento

• O tamanho atual do modelo on-device da Apple é limitado (cerca de 3B de parâmetros); o Claude é muito maior e continua no servidor.
• Alguns querem cache compartilhado, em nível de sistema, de modelos locais de terceiros para evitar que cada app baixe sua própria cópia; outros observam que a Apple hoje só deduplica modelos do sistema.
• Há debate sobre se um único modelo padrão on-device, otimizado, é melhor para a UX e para os recursos do que muitos modelos específicos por app.

Modelo de negócio, lock-in e controle da UX

• Muitos veem isso como a Apple comoditizando provedores de LLM enquanto mantém o controle sobre a UX geral e a marca (“Apple Intelligence” como a camada visível).
• Há especulação sobre futuras divisões de receita no estilo “Intelligence Store” ou cortes de 30% em assinaturas de apps com IA, mesmo que a cobrança da API não passe diretamente pela Apple.
• Alguns temem que a Apple possa mais tarde favorecer ou trocar provedores sem que os usuários percebam, reforçando o lock-in da plataforma.

Experiência do desenvolvedor e chaves de API

• Para desenvolvimento, o SDK pode usar uma chave de API direta; para produção, a documentação recomenda fortemente o uso de proxy via backend do desenvolvedor, que injeta credenciais.
• Isso evita enviar chaves nos apps, mas levanta preocupações sobre o acesso do proxy aos prompts e dados dos usuários.
• Alguns comentaristas não gostam de UX baseada em tokens e custo variável para o usuário final; assinaturas ou modelos locais são vistos como mais amigáveis.

Comoditização dos modelos e competição

• A discussão no thread debate se os modelos de fronteira estão se tornando “commodities” intercambiáveis ou se ainda há diferenças qualitativas substanciais.
• Há visões mistas sobre quais laboratórios estão à frente, mas existe amplo consenso de que:
  • A maioria dos casos de uso em apps não precisa do desempenho absoluto de fronteira.
  • APIs unificadas em nível de sistema operacional empurrarão muitos apps para modelos padrão “bons o bastante”, com as fronteiras na nuvem reservadas para tarefas mais pesadas.