SageMaker versus Bedrock não é uma comparação técnica. É uma pergunta sobre se sua organização emprega pessoas cujo trabalho é ser dona de modelos. Se você tem um time que treina, avalia, e carrega o plantão de um artefato de modelo, o SageMaker descreve um trabalho que eles já fazem. Se você não tem esse time, e a maioria das empresas que lança recursos de IA não tem, o Bedrock não é uma solução de compromisso. É uma leitura correta do seu organograma.

A comparação costuma ser feita como uma matriz de recursos: controle, custo por token, escolha de modelo, fine-tuning, latência. Essas linhas são reais, mas são consequência. Cada uma delas se resolve de forma diferente dependendo de quem se espera que carregue a coisa às 3 da manhã, e isso é um fato organizacional, não técnico.

O que cada um realmente pede de você

Tire o marketing e os dois serviços fazem exigências muito diferentes.

O Bedrock pede que você seja dono de chamadas. Você recebe uma API, um ID de modelo, e uma fatura. Você é responsável por prompts, recuperação, avaliação de saídas, e custo. Você não é responsável por capacidade, hardware, atualizações de modelo, ou o deployment dos pesos. A unidade de trabalho é uma requisição.

O SageMaker pede que você seja dono de artefatos. Você recebe infraestrutura para treinar, ajustar, hospedar, e monitorar um modelo pelo qual você é responsável. Você é dono da linhagem dos dados de treino, do arcabouço de avaliação que aprova um release, da frota de instâncias do endpoint, da política de autoscaling, da detecção de drift, e da decisão de lançar uma nova versão. A unidade de trabalho é uma versão de modelo, e versões de modelo têm donos, changelogs, e rollbacks.

Essa segunda lista é um trabalho. Não uma tarefa, um trabalho permanente, com plantão anexado. A pergunta é se esse trabalho existe na sua empresa hoje.

O argumento da topologia de time

Classifique organizações reais em três formatos.

Times de produto consumindo inteligência

O time entrega uma funcionalidade. Ninguém tem "modelo" no cargo. A parte de IA do roadmap é "resumir o ticket" e "extrair estes campos". Para esse formato, o Bedrock é a resposta e não é nem perto de disputado. Entregar a esse time um endpoint SageMaker entrega a eles uma superfície operacional que eles não vão manter: o monitor de drift que ninguém lê, o endpoint dimensionado durante um lançamento e nunca revisto, o pipeline de treino que quebra quando a única pessoa que o entendia muda de time. O modo de falha do SageMaker num time de produto não é um modelo ruim. É um modelo sem dono.

Um time de plataforma servindo times de produto

Aqui o time de plataforma é dono de um gateway, de quotas, de infraestrutura de avaliação, e de atribuição de custo, enquanto times de produto são donos de prompts e funcionalidades. O instinto do time de plataforma é achar que ser dono de modelos é o próximo passo natural. Geralmente não é. A coisa valiosa que eles fornecem é a costura entre times de produto e inferência: roteamento, chaves, orçamentos, avaliações, auditoria. Essa costura vale a pena construir sobre o Bedrock, e é exatamente o formato que descrevi em LLM Gateways: Why Every Platform Team Builds One Eventually. Adicionar SageMaker significa adicionar "nós rodamos os modelos" a um time que já é o gargalo de outros seis times.

Um time de ML que já é dono de modelos

O time tem um pipeline de treino, um feature store, um registro de modelos, e um endpoint existente pelo qual eles recebem alertas. Para eles o SageMaker não é uma carga nova, é a carga que já carregam, agora ferramentada. O movimento interessante aqui geralmente não é escolher, é admitir que vão rodar os dois: SageMaker para os modelos que são o produto, Bedrock para o trabalho genérico de linguagem ao redor. Ninguém deveria fazer fine-tuning de um modelo para escrever resumos de commit numa empresa que também roda um modelo de ranking de verdade.

As razões que realmente forçam o SageMaker

Três, na minha experiência, e todas são específicas.

  • O modelo é o produto, ou o seu diferencial. Score de fraude, ranking, previsão, qualquer coisa em que seus pesos codificam algo que um concorrente não consegue comprar. Você não pode terceirizar aquilo que está vendendo.
  • Os pesos ou os dados não podem sair de uma fronteira que você controla de um jeito que uma API de inferência gerenciada não consegue satisfazer, e você leu o requisito de verdade em vez de apenas repeti-lo. Esse é reivindicado com muito mais frequência do que sobrevive ao escrutínio.
  • Você precisa de um modelo que ninguém serve por você, um checkpoint de peso aberto específico ou uma variante adaptada ao domínio, e você mediu uma lacuna real contra as opções hospedadas em vez de presumir uma.

Note o que não está na lista: custo. Auto-hospedar é mais barato por token em utilização alta e constante e consideravelmente mais caro em tudo o mais, porque você paga por uma instância independente de ela servir tráfego, e porque agora você está pagando salários para planejamento de capacidade. O argumento do custo é um argumento de utilização disfarçado, e ele precisa de um número anexado para valer.

Como a decisão geralmente vai por água abaixo

A falha comum é uma arquitetura escolhida para uma organização aspiracional. Um time escolhe o SageMaker porque um slide de roadmap diz que vão construir modelos proprietários no ano que vem. Eles constroem o pipeline, lançam um fine-tune, o headcount para o time de ML nunca chega, e dois anos depois um engenheiro de produto está nervosamente ajustando o tipo de instância de um endpoint que ninguém consegue explicar. A tecnologia estava bem. A organização que ela pressupunha nunca apareceu.

A falha inversa existe mas é mais branda e mais fácil de corrigir. Um time no Bedrock descobre uma necessidade genuína de ser dono de um modelo, e migra aquela única carga de trabalho. Migrar uma carga de trabalho de uma API gerenciada para um artefato próprio é um projeto. Aposentar uma plataforma de ML sem dono é uma escavação arqueológica.

O teste

Faça uma pergunta na revisão de design: quem recebe o alerta quando a qualidade deste modelo regride, e o que essa pessoa faz a respeito?

Se a resposta nomeia uma pessoa, descreve um conjunto de avaliação que aprova um rollback, e o gestor dessa pessoa concorda, o SageMaker está disponível para você. Se a resposta é "a gente vê isso" ou nomeia um time que ainda não existe, você acabou de descobrir que sua organização consome inteligência em vez de produzi-la. Construa para isso. Não é uma ambição menor, é uma ambição precisa, e a restrição que amarra esses times quase nunca é propriedade de modelo. É avaliação, uma disciplina que você precisa de qualquer forma e que eu diria ser o pré-requisito real para os dois caminhos.

A conclusão

Escolha o SageMaker quando um time é dono de artefatos de modelo como responsabilidade permanente, com plantão e um conjunto de avaliação por trás. Escolha o Bedrock quando sua organização consome saída de modelo para construir funcionalidades, o que é a maioria das organizações, na maior parte do tempo. O modo de falha de errar isso não é um benchmark ruim. É infraestrutura sem dono, que apodrece em silêncio até falhar ruidosamente. Escolha pelo organograma que você tem.

Leia isto a seguir

A versão de time de plataforma desse argumento, sobre quem é dono de clusters e pipelines em vez de modelos, está em ercan.cloud. O hub está em ercanermis.com.