Por trás da arquitetura do Slack AI: Como a transição para o Amazon Bedrock resolve gargalos de GenAI
Um olhar técnico sobre roteamento híbrido, custos ociosos e gestão de tokens em aplicações de IA corporativa em larga escala.
A engenharia do Slack detalhou a saída de instâncias dedicadas no AWS SageMaker para uma arquitetura flexível no Amazon Bedrock. O caso revela padrões de infraestrutura essenciais para equilibrar latência e custo em projetos de LLM.
A infraestrutura por trás de soluções de inteligência artificial corporativa raramente é um caminho linear. A engenharia do Slack abriu recentemente o capô de como escalou o Slack AI, detalhando uma transição complexa do AWS SageMaker para uma arquitetura híbrida no Amazon Bedrock. Para quem constrói no ecossistema Salesforce, especialmente desenhando integrações com o Agentforce, Data Cloud ou Einstein Trust Layer, os bastidores dessa migração revelam o verdadeiro custo de colocar GenAI em produção de forma escalável.
O projeto começou em 2023 utilizando instâncias dedicadas no AWS SageMaker. A escolha fazia sentido técnico e de conformidade legal. A equipe de engenharia utilizou uma estratégia de VPC em escrow para garantir um ambiente zero-knowledge, onde os dados da empresa ficassem blindados e os pesos proprietários dos modelos não pudessem ser acessados externamente. No entanto, o custo operacional dessa decisão arquitetural logo se tornou um gargalo. Gerenciar a infraestrutura exigia planejamento de capacidade manual, lidar com escassez de GPUs potentes no mercado e absorver a latência de inicialização. Para garantir que as requisições dos usuários fossem atendidas de forma instantânea em horários de pico, a equipe precisava manter um hardware ocioso considerável.
Outro problema grave que afetou diretamente a evolução do produto foi a defasagem de modelos. Como os provedores de nuvem priorizavam lançar novos LLMs e atualizações diretamente em serviços gerenciados, como o Amazon Bedrock, o Slack AI enfrentava um tempo de espera artificial até que esses mesmos modelos estivessem disponíveis e otimizados para sua infraestrutura dedicada no SageMaker. Em um mercado onde a qualidade da IA dita a vantagem competitiva, esse atraso tornou-se insustentável.
A migração para o Amazon Bedrock representou uma mudança de paradigma, abstraindo o gerenciamento pesado de hardware. A engenharia deixou de monitorar instâncias individuais de GPU e passou a dimensionar a operação através de Model Units, focando exclusivamente na taxa de transferência em tokens por minuto. A transição foi desenhada para ter impacto zero em produção, apoiada em uma fundação robusta de testes de carga e uso extensivo de feature flags, garantindo o redirecionamento gradual e seguro de tráfego.
Apesar dos ganhos operacionais, a otimização financeira exigiu refinamento adicional. Mesmo utilizando o modelo de capacidade provisionada do Bedrock, a ociosidade persistia. A operação global do Slack AI possui picos colossais durante o horário comercial dos Estados Unidos, acompanhados de vales profundos durante as madrugadas e finais de semana globais. Pagar por capacidade dedicada contínua apenas para sustentar esses picos inflava os custos. Além disso, contratos de capacidade reservada geralmente exigem compromissos prolongados, travando a agilidade da equipe de homologar e trocar rapidamente o tráfego para LLMs recém-lançados.
A maturidade arquitetural foi alcançada com a implementação de uma estratégia de roteamento híbrido. A equipe classificou e separou o tráfego por perfil de consumo e tolerância à latência. Funcionalidades críticas, como pesquisas interativas e resumos de canais solicitados pelos usuários, permaneceram em infraestrutura de capacidade dedicada para garantir respostas imediatas. Em contrapartida, tarefas de explosão assíncrona, como a geração noturna do recurso Recap, foram redirecionadas para instâncias sob demanda. Para proteger a resiliência de toda a operação, foi implementado um padrão de transbordo, o spillover. Se um pico repentino estourar o limite da capacidade provisionada, as requisições excedentes escoam automaticamente para endpoints sob demanda, evitando quedas de serviço.
Para profissionais desenhando arquiteturas no ecossistema Salesforce, a lição prática é irrefutável. A adoção de inteligência artificial não se resume à escolha do modelo ou desenho do prompt. Quando implementamos chamadas externas de LLM via integrações personalizadas ou desenhamos automações pesadas no Flow baseadas em IA, tratar todo o volume de processamento com a mesma prioridade de infraestrutura é a forma mais rápida de estourar os limites da organização. Separar cargas de trabalho síncronas de assíncronas e estabelecer padrões de fallback dinâmico são requisitos não-negociáveis para arquiteturas escaláveis.
Projetos corporativos de IA geralmente falham na fase de escalabilidade devido a custos ocultos de infraestrutura e latência. A arquitetura adotada pelo Slack AI ilustra padrões de transbordo e roteamento híbrido que solucionam problemas reais de quem está conectando LLMs externos ao Salesforce ou desenhando ações customizadas para o Agentforce.
Uma análise técnica focada em extrair os padrões arquiteturais de infraestrutura do case do Slack AI para apoiar decisões de arquitetos desenhando integrações de GenAI no ecossistema Salesforce.
- Classifique suas chamadas de IA antes de qualquer coisa. Separe explicitamente o que é síncrono (resposta em tempo real para o usuário no Slack ou em um componente LWC) do que é assíncrono (sumarizações em lote, geração de relatórios, enriquecimento de registros). Essa divisão define toda a sua estratégia de roteamento e custo.
- Para fluxos síncronos, priorize capacidade provisionada. Se você está acionando modelos via Einstein AI ou chamadas diretas a provedores externos (AWS Bedrock, OpenAI) a partir de Flows ou Apex, configure limites de latência aceitáveis e garanta que o provedor tenha capacidade reservada — não dependa de throughput sob demanda para interações de usuário em tempo real.
- Desloque cargas assíncronas para o caminho certo.
- Sumarizações em lote, análise de histórico de conversas e geração de insights consolidados devem sair do fluxo síncrono imediatamente.
- Use Apex Queueable ou Batch Apex para orquestrar essas chamadas fora do horário de pico.
- Se o volume justificar, roteie via MuleSoft para desacoplar o Salesforce da latência do provedor de IA e centralizar o controle de retry e throttling.
- Implemente padrões de fallback explícitos. Não assuma disponibilidade do provedor principal. Desenhe um fallback definido: se a chamada ao modelo primário falhar ou exceder o timeout configurado, o sistema deve ter um comportamento degradado gracioso — seja um modelo secundário, uma resposta cacheada ou uma mensagem de fallback estruturada para o usuário.
- Monitore consumo de tokens como métrica de custo operacional. Instrua sua equipe a tratar tokens como unidade de custo, não apenas como detalhe técnico. Estabeleça alertas e dashboards no Salesforce (via Platform Events ou integração com observabilidade externa) para identificar onde o consumo está concentrado e onde a otimização de prompt pode reduzir custo sem comprometer qualidade.
- Documente o contrato de cada integração de IA. Para cada ponto de chamada — Flow, Apex, MuleSoft, Agentforce — registre: modelo utilizado, latência esperada, comportamento de fallback e responsável pela revisão periódica de custos. Arquitetura de IA sem governança vira dívida técnica rapidamente.
O uso de capacidade estritamente sob demanda em serviços de nuvem traz o risco inerente de indisponibilidade regional em momentos de pico geral. Concentrar toda a operação em um único provedor sem redundância expõe a solução a falhas de serviço massivas.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.