TrueFoundry: Balanço de fim de ano de 2023

À medida que 2023 chega ao fim, é hora de refletir sobre a jornada da TrueFoundry ao longo do último ano. Esta reflexão não é apenas uma celebração das nossas conquistas, mas também um reconhecimento dos desafios que superamos, uma valorização das oportunidades que nos foram apresentadas e dos aprendizados que abraçamos. Em vez de focar nos detalhes operacionais, vamos guiá-lo por uma jornada cronológica de aprendizados e percepções indexada à nossa tese sobre MLOps — e como as coisas se desenrolaram na realidade. 

Eu sou pessoalmente um entusiasta do espaço, por isso considero a analogia tradicional de startups como foguetes bastante apropriada. Se eu tivesse que descrever os prazos imaginando que estamos construindo um foguete, então— 2022 foi o ano de montar o motor e fazer um voo de teste, enquanto 2023 foi quando traçamos o curso para as estrelas e garantimos os propulsores para a nossa odisseia cósmica! Estou muito animado para guiá-lo pela nossa jornada de 2023, mas antes, deixe-me contextualizar sobre a TrueFoundry e o início do ano de 2023. 

TrueFoundry e o ano de 2022

A TrueFoundry está construindo uma PaaS agnóstica à nuvem no Kubernetes, que padroniza o treinamento e a implantação de modelos de Machine Learning usando APIs prontas para produção e amigáveis para desenvolvedores. 

Em 2022, dedicamos tempo à construção da nossa equipe, desenvolvendo a camada de infraestrutura da plataforma em diferentes provedores de nuvem e trabalhamos em estreita colaboração com nossos primeiros parceiros de design. Desenvolvemos a camada central de implantação de serviços e construímos as experiências impulsionadas por UI, CLI e Python-SDK, e experimentamos a alegria do nosso primeiro dólar de cliente! Percebemos que vender no espaço de MLOps é difícil porque a maioria das empresas havia construído “algo que funcionava” e a resistência à mudança era muito alta. 

Por outro lado, havíamos realmente validado os problemas que estávamos resolvendo— 

• Modelos de Machine Learning não estavam chegando à produção
• Implantações de ML eram atrasadas devido a transferências de modelos 
• Cientistas de dados enfrentavam grandes problemas de gerenciamento de infraestrutura
• A adoção de K8s no mundo de ML era mínima
• Modelos de Machine Learning seguindo um pipeline de implantação diferente do software full-stack estava muito problemático 
• As empresas estavam gastando 2 a 10 vezes mais do que o necessário ao trabalhar com Machine Learning

A essa altura, havíamos identificado que estávamos resolvendo um grande problema com um enorme impacto econômico, mas o desafio era: este não era um problema urgente na mente do cliente. Nosso aprendizado com este episódio: 

Resolver um grande problema é fundamental para a sustentabilidade, mas você não pode fabricar urgência – o cliente e o mercado decidirão isso. É o equivalente no mundo dos negócios às leis da física. Não lute contra isso – continue procurando! 

Iniciando 2023

Com isso, iniciamos 2023, com múltiplos experimentos de GTM para executar com base em nossos aprendizados ao trabalhar com parceiros de design. Apresentando alguns exemplos concretos dos experimentos que realizamos: 

1. Hipótese multi-nuvem: 84% das empresas são multi-nuvem e executar cargas de trabalho em múltiplos fornecedores de nuvem é realmente difícil. Embora isso representasse um enorme desperdício de tempo e custo organizacionalmente, não conseguimos encontrar um único ponto de contato de forma repetível que tivesse isso como seu problema principal.
2. Cargas de trabalho de ML impulsionadas por K8s: O mundo do software full-stack já havia começado a colher os benefícios da escala do K8s e do ecossistema ao seu redor, e estava claro que o ML apenas veria isso acentuado. Embora tenhamos encontrado algumas equipes que tinham a migração para K8s como prioridade, isso sempre ficava em segundo plano em comparação com o trabalho voltado para o usuário de nossos clientes. 
3. Otimização de Custos: Percebemos que a maioria de nossos parceiros de design economizou 40-50% dos custos de infraestrutura em nuvem ao trabalhar com nossa plataforma e visamos as organizações que tinham a redução de custos como meta para o ano. É claro que isso ressoou, mas notamos que a equipe encarregada de reduzir custos era principalmente DevOps, e sua missão incluía a redução de custos pontual e tinha pouco ou nenhum controle sobre os fluxos de trabalho dos desenvolvedores, o que faria o problema ressurgir. 

Ok, então, uma série de experimentos parcialmente bem-sucedidos ou falhos, através dos quais notamos ainda mais a prevalência dos problemas que estávamos tentando resolver, mas ainda não conseguimos encontrar nosso caminho para identificar: uma persona de cliente específica, com o mesmo problema exato que é urgente e que pode ser identificada externamente de forma repetível. 

Isso aconteceu até que todos no mundo quiseram trabalhar com LLMs e fomos apresentados a uma oportunidade que surgiu no momento certo. 

LLMs agregaram a demanda para nós. Todos queriam trabalhar com LLMs e todos agora enfrentavam “urgentemente” os mesmos problemas que estávamos tentando resolver.  

Uniformidade de LLMOPs, MLOPs e DevOps

Considerando alguns desses problemas aqui no contexto de LLMs: 

• Da demonstração à produção: Literalmente, qualquer um poderia escrever alguns prompts e fazer uma demonstração sofisticada baseada em GPT-4. Todo cientista de dados concordaria que construir um RAG rápido usando Langchain é como algumas horas de trabalho. O desafio é fazer com que essas demonstrações se tornem prontas para produção, o que exige juntar muitas peças de forma confiável. É preciso construir fluxos de trabalho que facilitem para os cientistas de dados pensar nessas aplicações em um ambiente de produção desde o início. 
• A100s — onde estão vocês?: Não conhecemos um único desenvolvedor que trabalhou com LLMs na sua infraestrutura que não tenha reclamado da indisponibilidade de GPUs, especialmente A100s. Como aumentar a probabilidade de eles conseguirem essas GPUs? Exponha-os a múltiplas nuvens ou data centers — mas é um problema lidar com uma arquitetura multi-nuvem se você não tiver as ferramentas certas. 
• Hospedagem de modelos de código aberto: Hospedar esses grandes modelos de linguagem exige um acompanhamento próximo da infraestrutura, o que aumenta a dependência das equipes de Ciência de Dados na equipe de infraestrutura. Se pudéssemos criar a plataforma certa onde as equipes de DS fossem razoavelmente “infra independentes” — esse problema seria minimizado para casos de uso relativamente simples, como a hospedagem de modelos prontos para uso.
• Trabalhos de ajuste fino de longa duração- A maioria dos nossos clientes está realizando ajuste fino de LLMs e alguns também estão fazendo pré-treinamento. Ora, estes são trabalhos caros e de longa duração onde não se pode dar ao luxo de desperdiçar muitos ciclos de GPU devido a erros humanos. Boas práticas de registro (logging), monitoramento e rastreamento de experimentos são cruciais aqui. Por exemplo, se você não salvar os pontos de verificação do modelo por padrão e seu trabalho de treinamento for interrompido dois dias após o início da execução, isso é um enorme desperdício de tempo e recursos. 
• Monitoramento de Custos- LLMs não são baratos para treinar, nem baratos para executar. Muitas empresas estão com economia unitária negativa atualmente ao atender seus usuários usando LLMs, assumindo que um dia os custos diminuirão. A dependência de plataformas de nuvem como o Sagemaker, que cobram um prêmio sobre as instâncias EC2 e raramente utilizam instâncias spot, agrava ainda mais o problema. Além disso, há pouca ou nenhuma visibilidade dos custos de infraestrutura para os desenvolvedores que são os proprietários dos serviços. Embora este problema pareça mais acentuado no caso dos LLMs, toda a lógica mencionada acima é fundamental para todo software. 
• DBs Vetoriais e Gerenciamento de Segredos: Para construir aplicações baseadas em LLM, os desenvolvedores se viram lidando com múltiplas aplicações, como diferentes DBs Vetoriais, Label Studio e uma variedade de serviços de API. Cada um deles exige tempo para configurar e infraestrutura para permitir o compartilhamento de chaves de API em toda a organização com o nível certo de monitoramento. Cientistas de dados não se sentem equipados com as ferramentas certas para lidar com isso e a única solução é “desacelerar, até que soluções seguras sejam implementadas”. 

Estes são alguns exemplos, mas existem muitos outros casos de uso semelhantes – como a configuração de inferência assíncrona, notebooks com suporte a GPU, unidade de armazenamento compartilhada entre notebooks, tempos de inicialização a frio de grandes contêineres Docker, etc., que as empresas consideraram difíceis de resolver. 

Acontece que todos os nossos clientes que nos procuram para LLMs e que já usufruem de funcionalidades como a redução da dependência dos Cientistas de Dados na Infraestrutura, a poupança de custos ou a escalabilidade de aplicações entre provedores de nuvem (evitando o aprisionamento tecnológico), percebem que o mesmo é aplicável a outros modelos de Machine Learning que não são LLMs. Realisticamente, isso também se aplica ao restante da pilha de software. Vemos esta polinização cruzada de casos de uso para clientes que começaram a nos usar para implantar software ou modelos clássicos de ML e agora estão a ver benefícios com LLMs. 

Conclusão

Isto reforça a nossa crença de que o tempo que dedicamos à construção da nossa infraestrutura central – com a perspectiva convicta de que ML é software e deve ser implantado de forma semelhante, que o K8s prevalecerá a longo prazo e que as empresas desejarão evitar o aprisionamento tecnológico (seja de nuvem ou de outros fornecedores de software) – está a valer a pena para nós e para os nossos clientes. 

Para concluir, usando a analogia do foguete – 

Se 2023 foi o ano em que mapeamos o território e preparamos os propulsores, aguardamos um 2024 onde acenderemos os boosters para impulsionar este foguete!!!

Desejando a todos um muito Feliz Ano Novo em nome de toda a equipa TrueFoundry! Bem-vindo 2024.