Autopilot: Automatizando o Gerenciamento de Infraestrutura para GenAI

O que é o Autopilot

As operações de machine learning (MLOps) frequentemente envolvem processos complexos e manuais que consomem tempo e recursos. O Autopilot da Truefoundry visa eliminar esses encargos operacionais, permitindo que os desenvolvedores se concentrem exclusivamente na escrita de código e os cientistas de dados a aprimorar seus modelos. O Autopilot lida automaticamente com a otimização de recursos e correções de confiabilidade e garante um fluxo de trabalho sem atritos com mínima intervenção humana.

Por que precisamos disso

As preocupações operacionais de qualquer ciclo de vida de desenvolvimento de software podem ser divididas em três estágios diferentes -

1. Dia 0 – Design e Planejamento: Definir arquitetura, estratégias de provisionamento, políticas de segurança e estruturas de escalonamento antes da implantação.
2. Dia 1 – Implantação e Implementação: Configurar infraestrutura, implantar aplicações, configurar observabilidade e estabelecer pipelines de CI/CD.
3. Dia 2 – Operações e Manutenção: Monitorar continuamente, escalar recursos automaticamente, aplicar patches de segurança e gerenciar incidentes.

Esses processos foram implementados em três fases diferentes, levando de responsabilidades fragmentadas à eficiência impulsionada pela automação.

Fase 1: Separação de Desenvolvimento e Operações

Esta é a fase em que uma equipe geralmente começa. As três fases das operações geralmente envolvem o seguinte nesta etapa.

• Dia 0: Desenvolvedores focam no design da aplicação, enquanto as equipes de operações lidam com infraestrutura e segurança.
• Dia 1: Desenvolvedores empacotam e preparam as aplicações para implantação, enquanto a equipe de operações foca no provisionamento de recursos e na sua configuração.
• Dia 2: As operações gerenciam escalabilidade, monitoramento e patches de segurança, enquanto os desenvolvedores ainda solucionam problemas.

Essa separação de responsabilidades cria atrito desnecessário entre as equipes de Desenvolvimento e Operações. O problema é agravado ao dificultar o compartilhamento de contexto devido ao vocabulário compartilhado limitado em alguns casos.

Para uma única aplicação, isso pode se traduzir em um cronograma de lançamento inicial de várias semanas, com cada operação subsequente do "dia 2" levando alguns dias, e os inevitáveis problemas de alinhamento entre as equipes de operações e desenvolvimento.

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

Fase 2: Criação de plataforma interna

Na fase 2, uma organização adota uma plataforma interna que permite à equipe de desenvolvimento configurar e controlar a maioria das alavancas operacionais conforme julgar adequado. A equipe de operações assume mais um papel de fiscalização e padronização, usando a plataforma como a camada para orquestrá-lo.

Esta fase apresenta algumas desvantagens -

• Para os desenvolvedores, esta fase significa tomar muitas decisões nas etapas iniciais com contexto limitado ou expertise relevante. Isso leva a um aumento na carga cognitiva e a um planejamento de recursos subótimo.
• Essa abordagem se manifesta como uma explosão do espaço de operações para a equipe de operações. Uma equipe típica pode encontrar um aumento multifacetado no número de serviços e nos custos de infraestrutura com a série de decisões subótimas tomadas.

Embora inicialmente ganhemos velocidade, isso é compensado pela explosão na complexidade do trabalho de uma equipe de desenvolvimento, o que é inevitavelmente seguido por um choque de interesses entre as duas equipes.

Fase 3: Automatizando a plataforma

Na terceira fase, a própria plataforma começa a automatizar todas as preocupações operacionais. Isso elimina a necessidade de muitas decisões serem tomadas nas três etapas da operação.

Isso significa que as 3 etapas operacionais podem ser alcançadas no próprio dia 0, com quase nenhuma escolha operacional por parte das equipes de desenvolvimento ou de operações. É isso que o Autopilot tenta fazer.

Por que agora

Embora a necessidade de mais automação seja evidente há bastante tempo, um sistema como o Autopilot se torna ainda mais essencial no cenário atual com os seguintes novos paradigmas entrando em jogo

Microsserviços

Com a ampla adoção da arquitetura de microsserviços, o número de serviços em uma organização passou por uma explosão cambriana. Essa conveniência de levar mudanças ou novos serviços para produção tem o lado negativo de uma supervisão mais difícil. Autopilot é um sistema que pode otimizar esses serviço de forma confiável.

Sistemas Agênticos

Sistemas agênticos são sistemas que executam tarefas de forma autônoma. Eles precisam de uma estratégia de implantação robusta e autossuficiente com uma infraestrutura de suporte flexível o suficiente para escalar para cima e para baixo dinamicamente, conforme necessário. Agentes de IA de ponta atuais dependem de uma infraestrutura adaptável e eficiente para funcionar de forma otimizada. São sistemas dinâmicos que necessitam de diferentes níveis de envolvimento humano. A ampla implementação de tais sistemas só é possível com um sistema onde todos os aspectos operacionais são automatizados, e é aí que o Autopilot entra.

Estudo de Caso

Para um dos usuários da plataforma Truefoundry, o custo dos clusters de desenvolvimento era um grande problema. Com cerca de 200 serviços implantados, este era um caso típico de múltiplos serviços com pequenas ineficiências se acumulando para criar um aumento massivo no custo total. Qualquer tentativa de otimização de custos teria que ser feita no nível de serviço individual. Essa exigência extrema de trabalho levou ao agravamento do estouro de custos e nunca se tornou uma prioridade.

Após ativar o piloto automático, para este cliente, eles conseguiram uma economia de custos de 1500$ em apenas 2 clusters. Além disso, mais de 50 correções relacionadas à confiabilidade foram aplicadas onde as cargas de trabalho estavam com falta de CPU ou enfrentavam problemas relacionados à escassez de memória.

‍

O que o Piloto Automático pode fazer atualmente

‍

Otimização de CPU, Memória e Armazenamento

O Piloto Automático automatiza a configuração de CPU e memória para uma aplicação. Ele faz isso analisando duas fontes de entrada -

• Uso Histórico: O Piloto Automático analisa o uso histórico de uma aplicação para retornar com uma configuração ótima para o futuro.
• Ajustes em Tempo Real: O Piloto Automático também reage a alertas e outras fontes de eventos para realizar mitigações em tempo real e resolver um problema logo no início. Isso leva a uma melhoria no MTTR e previne proativamente muitos problemas que, de outra forma, se tornariam muito maiores.

Saúde do Cluster

O Piloto Automático também cuida da saúde e do custo dos componentes individuais instalados em um cluster, como Istio, ArgoCD, Carpenter, etc. A falha de qualquer um desses componentes pode levar a consequências desastrosas para as cargas de trabalho em execução nesse cluster. O Piloto Automático garante que esses componentes estejam funcionando de forma otimizada em termos de custo, enquanto continuam a operar, procurando proativamente por picos de recursos e os contabilizando.

Capacidade do nó

Indo além dos serviços, o piloto automático também otimiza a infraestrutura que suporta os serviços em execução. Isso significa recomendar a capacidade de nó ideal para uma aplicação. Isso é feito levando em consideração as métricas da aplicação, o ambiente e outros fatores.

Autoescalonamento

Muitas equipes de desenvolvimento optam por escalar suas aplicações para a carga máxima que se espera que uma aplicação enfrente. Isso gera muitos custos extras quando essas réplicas adicionais não estão em uso. Uma solução óbvia é implementar o autoescalonamento, mas mesmo isso não é aplicável quando os padrões de tráfego são imprevisíveis. O Piloto Automático analisa as métricas históricas de cada serviço e gera uma recomendação para habilitar ou desabilitar o autoescalonamento com base na natureza histórica da aplicação.

‍

O que vem a seguir

Embora já observemos muitos ganhos em custo e confiabilidade usando o piloto automático em produção, muito mais precisa ser feito para concretizar a visão completa de automação estabelecida anteriormente. Alguns dos aspectos de preocupação operacional que valem a pena automatizar a seguir são -

• Autoescalonamento periódico - Prever e implementar o autoescalonamento periódico, levando em consideração o tráfego histórico, pode nos permitir habilitar o autoescalonamento mesmo para cargas de trabalho com picos.
• Recomendação de desligamento automático - Filtrar e desligar serviços ou cargas de trabalho que não estão em uso pode levar a economias massivas de custos
• Auto-benchmarking — Embora a estimativa dos recursos de um serviço já seja possível, uma estimativa melhor pode ser feita executando os benchmarks com tráfego real ou simulado e observando as métricas de negócios afetadas. O Autopilot busca automatizar esse processo, que pode ser muito demorado para a maioria das equipes de desenvolvimento.
• Otimização da infraestrutura do cluster - A utilização da CPU do cluster em toda a indústria é de 10% em média link . Embora a má configuração de aplicações para CPU seja uma parte significativa disso, uma grande parte também são as ineficiências na distribuição de carga na infraestrutura subjacente. Isso pode se manifestar na forma de muitos nós subutilizados, muitos nós pequenos desperdiçando espaço em daemonsets, etc. Corrigir as configurações de provisionamento de infraestrutura e aproveitar ferramentas como o karpenter no nível da nuvem pode ajudar muito a melhorar esse aspecto.

Conclusão

O Autopilot da Truefoundry é uma ferramenta transformadora na evolução do MLOps, abordando desafios operacionais críticos em todo o ciclo de vida do desenvolvimento de software. O Autopilot permite que as equipes se concentrem na inovação em vez da sobrecarga operacional, automatizando a otimização de recursos, o gerenciamento da saúde do cluster e o autoescalonamento. À medida que a adoção de microsserviços e sistemas agentivos continua a crescer, a necessidade de tal automação torna-se cada vez mais urgente. Com suas capacidades atuais e um roteiro ambicioso, o Autopilot está pronto para revolucionar a forma como as organizações abordam a eficiência operacional, a confiabilidade e a otimização de custos.

‍