AWS mostra como rodar o llama.cpp no SageMaker e obter probabilidades por opção

O AWS Machine Learning Blog publicou um guia passo a passo para implantar modelos de decisão no Amazon SageMaker AI com o motor llama.cpp. A arquitetura tem duas camadas. Primeiro, sobe-se um endpoint baseado no AWS Deep Learning Container oficial para llama.cpp, que expõe chat completions compatíveis com a API da OpenAI. Depois, o runtime é estendido com a biblioteca SemIf, e o modelo passa a retornar probabilidades para opções declaradas previamente, em vez de texto gerado. Tudo isso funciona tanto em CPU quanto em GPU.

O material é prático: trata-se de um tutorial, não do anúncio de um novo produto. Ainda assim, mostra como a AWS propõe resolver um dos cenários corporativos mais comuns — classificação e tomada de decisão com modelos pequenos, sem uma infraestrutura pesada de GPU.

Como o stack é montado

O llama.cpp é um motor de inferência open source em C/C++ que executa modelos quantizados no formato GGUF e não exige GPU. Por isso, é popular onde se precisa de endpoints baratos e previsíveis. A AWS empacotou o motor em um Deep Learning Container próprio, para que a equipe não precise montar a imagem manualmente nem lidar com dependências.

Os principais elementos da solução, segundo a descrição da AWS:

• Plataforma: Amazon SageMaker AI, com endpoints gerenciados de inferência.
• Runtime: AWS Deep Learning Container para llama.cpp.
• Interface: chat completions compatíveis com a API da OpenAI, ou seja, clientes e SDKs existentes se conectam sem reescrita.
• Extensão: SemIf, que retorna probabilidades para as opções declaradas.
• Hardware: CPU ou GPU, a critério do desenvolvedor.

A compatibilidade com o formato da OpenAI resolve um problema prático de migração. Se o aplicativo já consome uma API de chat, migrar para um endpoint próprio se resume a trocar o endereço e a chave.

Por que probabilidades em vez de texto?

Um modelo de decisão responde a uma pergunta com um conjunto finito de desfechos: aprovar ou recusar uma solicitação, encaminhar um ticket para o faturamento ou para o suporte técnico, marcar uma mensagem como violação ou deixá-la passar. Uma LLM comum devolve uma string que precisa ser interpretada. O formato da resposta varia, o modelo acrescenta explicações e, às vezes, inventa uma opção que não está na lista.

Pelo que a descrição indica, o SemIf resolve esse problema no nível do runtime. O desenvolvedor declara as opções válidas e recebe de volta uma distribuição de probabilidades sobre elas. Dá para escolher a de maior valor, mas o ponto mais interessante é outro: surge um limiar de confiança. Se a melhor opção atinge 0,92, a ação é executada automaticamente. Se atinge 0,48, o caso vai para uma pessoa. Isso transforma o modelo de linguagem em um componente com calibração mensurável, que pode ser integrado a um processo de negócio convencional.

Para os engenheiros, isso também facilita os testes. As probabilidades podem ser registradas em log, comparadas entre versões do modelo e usadas para construir métricas, algo impossível com texto arbitrário.

O que o anúncio não diz

A breve descrição não traz benchmarks, preços, lista de modelos compatíveis nem detalhes de implementação do SemIf. Não está claro como as probabilidades são calculadas: pelos logits dos primeiros tokens das opções ou de outra forma. Disso depende o grau de confiança que se pode ter nelas em opções longas ou compostas. Também não há comparação entre CPU e GPU em latência e custo por requisição. Esses dados terão de ser levantados pela própria equipe.

Por onde começar

Uma sequência prática para a equipe que quiser testar a abordagem:

• Escolha uma tarefa restrita, com 3–10 desfechos, como o roteamento de chamados.
• Pegue um modelo pequeno quantizado em GGUF e suba-o em uma instância com CPU. É o ponto de partida mais barato.
• Monte uma amostra rotulada e meça o quanto as probabilidades do SemIf correspondem à precisão real. Ajuste os limiares para decisão automática e para escalonamento.
• Só depois compare com uma instância de GPU em latência e preço por mil requisições.

Se a calibração for ruim, é melhor descobrir isso antes da produção. Se for boa, a equipe terá um endpoint gerenciável, com uma API familiar e uma economia clara.