Amazon SageMaker AI ganha API compatível com OpenAI: como plugar seu código no endpoint da AWS trocando só a URL

Resumo: A AWS liberou nos endpoints de inferência em tempo real do Amazon SageMaker AI um caminho compatível com a API da OpenAI. Na prática, quem já usa OpenAI SDK, LangChain ou Strands Agents pode chamar modelos hospedados no SageMaker trocando apenas a URL do endpoint — sem SigV4, sem cliente customizado, sem reescrita de código. O suporte cobre o padrão /openai/v1/chat/completions com streaming, autentica com bearer tokens gerados no próprio SageMaker e chega para 14 regiões, incluindo São Paulo. É um dos anúncios mais práticos da rodada de agentes que a AWS empilhou no Summit de Nova York.

O que mudou no endpoint do SageMaker

Historicamente, invocar um modelo no SageMaker significava usar o SDK boto3, assinar cada requisição com SigV4 e adaptar o cliente à interface InvokeEndpoint. Isso funciona bem em pipelines internos, mas cria fricção quando o time já padronizou tudo na API da OpenAI, hoje o “esperanto” de facto dos frameworks de LLM. A novidade é a exposição de um caminho /openai/v1 no próprio endpoint: o SageMaker recebe uma requisição no formato de Chat Completions, repassa ao contêiner do modelo e devolve a resposta exatamente como veio — inclusive com streaming token a token.

A autenticação é resolvida com bearer tokens de duração limitada, criados por chamada do próprio painel do SageMaker. O aplicativo cliente passa a viver como se estivesse falando com um servidor OpenAI: base_url apontando para o endpoint da AWS, api_key igual ao token temporário, e o restante do código intocado.

Como isso encaixa com o Bedrock

A leitura estratégica é importante: o Bedrock continua sendo a porta principal para modelos gerenciados (Claude, Llama, Nova, Mistral, Cohere e agora os pesos abertos da OpenAI), enquanto o SageMaker AI segue como o espaço para modelos customizados, fine-tunes específicos e cargas em GPU dedicada. A compatibilidade OpenAI aparece nos dois lados — no Bedrock via AgentCore e agora também no SageMaker — porque o padrão virou requisito de mercado. Para quem já testa gpt-oss no AWS, dá para construir fluxos híbridos, hospedando o modelo aberto no SageMaker e usando Bedrock Guardrails na saída.

Por que importa

O ganho está no atrito zero. Um time que já tem um agente escrito com langchain-openai ou com o Strands SDK precisa alterar duas linhas para trocar o provedor. Isso corta dias de retrabalho em migrações, viabiliza estratégias multi-cloud reais (mesmo agente rodando parte no Azure Foundry, parte no SageMaker, parte no OpenAI direto) e reduz a chance de o custo variável de inferência ficar preso a um único fornecedor. Para produtos que já tinham fallback de modelo, é a peça que faltava para tratar o SageMaker como mais um “modelo” na lista.

Status no Brasil

A região South America (São Paulo) entrou na leva inicial, o que é raro em lançamentos de IA da AWS — em geral, o Brasil pega os recursos meses depois. Isso muda o cálculo para bancos, seguradoras e fintechs brasileiras que já treinam modelos próprios (ou fazem fine-tuning de modelos abertos) e precisam de latência baixa para clientes locais. Também simplifica o compliance: rodar o endpoint em SP com autenticação por token curto ajuda a atender requisitos de LGPD e a política de dados sensíveis do Bacen, sem depender de proxies estrangeiros.

Riscos e limitações

Compatibilidade parcial: a interface é a de Chat Completions. Recursos avançados que a OpenAI publicou depois (Responses API, Assistants, Realtime) não estão espelhados; código que dependa deles ainda precisa de camada de adaptação. Token de curta duração: facilita segurança, mas exige um serviço de renovação — não é um drop-in de “gere uma chave e esqueça”. Contêiner responsável: a AWS repassa o que vem do contêiner do modelo. Se o servidor de inferência que roda dentro do SageMaker não implementar bem streaming, function calling ou tool use, a experiência degrada. Observabilidade dividida: logs ficam entre CloudWatch (rede/latência) e o contêiner (payload); auditoria completa exige juntar as duas pontas.

Análise SWOT econômica

Como usar hoje

Em código Python com o SDK oficial, basta apontar o cliente para a URL do endpoint:

from openai import OpenAI
client = OpenAI(base_url="https://runtime.sagemaker.us-east-1.amazonaws.com/endpoints/meu-endpoint/openai/v1", api_key=SAGEMAKER_BEARER_TOKEN)
resp = client.chat.completions.create(model="meu-modelo", messages=[{"role":"user","content":"olá"}], stream=True)

Para produção, vale automatizar a renovação do bearer token via IAM/STS, ativar métricas de latência por rota e considerar o AgentCore do Bedrock para adicionar guardrails e busca web sem sair da AWS.

Conclusão prática

A movimentação da AWS transforma o SageMaker AI em mais um alvo trivial para qualquer stack pensada para OpenAI. Para times brasileiros que estavam adiando pilotos por medo de reescrever integrações, esse é o gatilho: em duas linhas de código, dá para colocar um modelo customizado atrás do mesmo cliente que já rodava com gpt. O maior valor não é técnico, é de portabilidade — e portabilidade, em uma corrida de preços e qualidade que muda de mês em mês, virou vantagem competitiva.

Fonte original: AWS Machine Learning Blog — Announcing OpenAI-compatible API support for Amazon SageMaker AI endpoints.