Amazon SageMaker AI permite deploy de modelos de decisão com llama.cpp

A Amazon SageMaker AI agora permite o deploy de modelos de decisão com llama.cpp e SemIf, oferecendo uma solução gerenciada para servir modelos quantizados em infraestrutura de CPU ou GPU. Isso é especialmente útil para aplicações que precisam de scores sobre um conjunto fixo de escolhas em vez de texto livre.

Com o uso do AWS Deep Learning Container (DLC) para llama.cpp, é possível servir completions de chat compatíveis com a OpenAI por meio do SageMaker AI InvokeEndpoint. Além disso, é possível estender o mesmo runtime com SemIf, que retorna probabilidades sobre opções declaradas sem decodificar um token de resposta.

A figura 1 mostra dois caminhos de deploy a partir do mesmo modelo empacotado. O caminho de geração de texto usa o AWS DLC para llama.cpp e retorna respostas geradas por meio da API compatível com a OpenAI. O caminho de decisão estruturada constrói uma imagem filha que substitui o servidor padrão por um adaptador SemIf e retorna probabilidades para opções declaradas.

Para o caminho padrão, é necessário empacotar o modelo como model.tar.gz no Amazon Simple Storage Service (Amazon S3) e referenciar a imagem DLC publicada diretamente. O contêiner encontra o primeiro arquivo .gguf em /opt/ml/model, mapeia POST /invocations para llama-server em /v1/chat/completions e passa variáveis de ambiente SM_LLAMA_CPP_* para argumentos de llama.cpp.

Já o caminho de decisão estruturada usa o AWS CodeBuild para construir uma imagem filha e armazená-la no Amazon Elastic Container Registry (Amazon ECR). A imagem filha mantém as bibliotecas compiladas CPU ou CUDA do DLC, enquanto substitui o ponto de entrada com um adaptador compatível com o SageMaker.

O AWS DLC para llama.cpp aceita o esquema de completions de chat da OpenAI. É possível enviar uma matriz de mensagens com papel e conteúdo, além de controles de geração como max_tokens e stream. A resposta usa a matriz de escolhas compatível com a OpenAI. Já o SemIf usa um esquema de decisão restrito em vez de mensagens de chat.

A resposta retorna IDs de opção, probabilidades e logits de opção brutos na mesma ordem, junto com prompt, tempo e metadados de modelo fixados. Com IDs de opção estáveis, a aplicação pode aplicar limiares, fallbacks e verificações de política sem parsear prosa gerada.

O uso desse padrão é recomendado quando a aplicação define as escolhas permitidas no momento da solicitação e precisa de um modelo para interpretar o contexto não estruturado. Exemplos incluem roteamento de um caso para uma fila, extração de um valor de um conjunto conhecido, atribuição de prioridade de incidente, verificação de resultado de política ou seleção de ação de agente.

É importante manter a autorização e as regras de negócios determinísticas fora do modelo e validar as probabilidades do modelo antes de tratá-las como confiança operacional. Além disso, é recomendado usar o caminho de geração de texto padrão do SageMaker AI quando é necessário completions de chat compatíveis com a OpenAI por meio do InvokeEndpoint.

A remoção da geração de token de resposta não remove a inferência do modelo. O modelo ainda processa o estado completo, a pergunta e as descrições de opção antes de o SemIf ler os logits finais. É importante manter os prompts focados e avaliar o modelo selecionado com decisões rotuladas da aplicação antes do uso em produção.

Os benchmarks aplicam-se à extensão SemIf, não ao endpoint de geração de texto. O tamanho do modelo, a quantização, o comprimento do prompt, o tempo de execução e a contagem de threads de CPU afetam cada decisão. Para quantificar esses trade-offs, foi enviado o mesmo conjunto de tarefas públicas JevBench serialmente para um endpoint de CPU e um endpoint de GPU.

Em comparação com a configuração de CPU, o endpoint de GPU foi 4,9 vezes mais rápido em p50 e 32,2 vezes mais rápido em p95. A amostra usa a funcionalidade de pools de instâncias do SageMaker AI para listar os tipos de instâncias de GPU compatíveis em ordem de prioridade, para que o SageMaker possa selecionar uma alternativa quando a primeira preferência não está disponível.

O pool ordenou g6e, g6, g5 e, em seguida, g4dn. O SageMaker selecionou ml.g6e.xlarge, e os logs de inicialização confirmaram que o llama.cpp offloadou todas as 34 camadas do modelo para um NVIDIA L40S. As imagens de CPU e GPU usaram compilações diferentes de llama.cpp e produziram previsões diferentes em seis tarefas difíceis.

Trate a diferença de precisão de uma resposta como variação de tempo de execução, não como evidência de que o offload de GPU melhora a qualidade do modelo. Modelos menores reduziram a latência mediana, mas os candidatos 2B e 0,8B alcançaram 66,7% e 58,4% de precisão. A amostra, portanto, mantém o modelo 4B Q4_K_M como padrão de qualidade.

Essas medições incluem latência de rede e não são garantias de serviço. É recomendado benchmarkar a configuração completa do modelo e da infraestrutura contra as próprias decisões. Use CPU para trabalhos de fundo, offline ou de baixa taxa de transferência que não são sensíveis à latência e podem tolerar segundos de tempo de resposta. Use GPU para decisões interativas, prompts longos ou trabalhos com alvos de latência de cauda apertada. Mantenha as descrições de estado e opção concisas e agrupe decisões que compartilham o mesmo estado em uma única solicitação.