Estamos vendo hoje um interessante cabo de guerra de infraestrutura, onde as nuvens de GPU estão sendo puxadas em duas direções. Para que a economia da IA funcione, o mercado empresarial precisa dividir hardware caro em unidades menores e compartilháveis e entregá-lo aos clientes sob demanda, semelhante à forma como as CPUs são distribuídas na infraestrutura de nuvem pública. Porém, quanto mais os provedores pressionam as GPUs para que se comportem como uma infraestrutura de nuvem elástica, mais eles se deparam com a realidade de que esse hardware de GPU nunca foi construído para uso multilocatário seguro, recuperação rápida de falhas ou isolamento limpo entre cargas de trabalho. Essa tensão está a tornar-se um dos problemas operacionais definidores do mercado de infraestruturas de IA.
Quando um jogador inicia o Steam ou a Epic Games Store em seu laptop, ele não precisa se preocupar com qual GPU está sendo agendada, como a memória será dividida ou com qualquer limite de segurança ou problemas de atribuição de hardware em seu PC. Para os PCs de consumo, essas questões não ficam apenas ocultas, mas são irrelevantes.
Mas para as equipes de TI atuais que gerenciam cargas de trabalho de IA orientadas por GPU em sistemas distribuídos, esses tipos de alocações e partições precisam ser gerenciados manual e cuidadosamente. Isso inclui decidir qual GPU atribuir a cada carga de trabalho, como dividir a memória, como isolar tarefas e como maximizar a utilização desse hardware tão caro. É por isso que você ouviu tanto sobre os temas de infraestrutura de IA do “Dia 2” no evento GTC da Nvidia este ano.
O gargalo do hardware legado
As GPUs foram originalmente desenvolvidas para acelerar a renderização gráfica e realizar computação local por meio de shaders a serviço da renderização gráfica. Seu design pressupõe um ambiente de computação confiável no qual um único aplicativo controla o dispositivo. Quando um usuário executa um aplicativo em uma GPU, ele acelera essa carga de trabalho específica.
Mas embora as GPUs sejam otimizadas para rendimento e, portanto, tenham milhares de núcleos simples projetados para executar a mesma instrução em grandes conjuntos de dados, esse paradigma de design cria várias limitações técnicas importantes em relação à alternância de contexto e ao isolamento de memória. As GPUs foram projetadas para produzir pixels, não para executar aplicativos de IA confidenciais de vários locatários usando o mesmo hardware.
Como resultado, a infraestrutura de GPU hoje se comporta menos como uma infraestrutura de nuvem elástica e mais como dispositivos de hardware cuidadosamente gerenciados.
O paradoxo do particionamento
A infraestrutura de IA atual exige que as GPUs se comportem como recursos de nuvem elásticos e compartilhados. À medida que as cargas de trabalho de inferência começam a superar as execuções de treinamento em larga escala, a capacidade de dividir e compartilhar hardware caro entre vários locatários em tempo real, mantendo ao mesmo tempo uma tolerância a falhas aceitável, não é mais opcional.
Os fornecedores de hardware introduziram novas abordagens para dividir as GPUs em várias fatias de computação isoladas. Outras estruturas abordam o particionamento por meio de agendadores e tempos de execução de contêineres. Mas o particionamento de recursos é apenas uma fatia do bolo geral de operações da GPU.
Atualmente, não existe um modelo operacional amplamente adotado e entre fornecedores para alcançar isso com segurança em escala. A maioria dos provedores enfrenta a necessidade de dedicar um único cliente a uma máquina física (desperdiçando assim a capacidade disponível) ou de aceitar os riscos de segurança de multilocação atualmente sem uma solução conhecida. O atual desafio de engenharia passou da camada de modelo para a camada de infraestrutura. O sucesso agora depende da capacidade de lançar rapidamente novas cargas de trabalho e de conter rapidamente falhas de hardware para que uma única falha de GPU não derrube todas as cargas de trabalho em execução no servidor.
Código e locatários não confiáveis
A grande maioria dos modelos atuais de programação de GPU baseia-se na ideia de que o driver tem controle total sobre a proteção da memória e que nenhum usuário agirá de forma maliciosa. Infelizmente, essa suposição desmorona completamente em um ambiente de nuvem onde uma VM ou contêiner pode deixar para trás restos de dados na memória que outra VM ou contêiner pode acessar. Especialmente considerando que a forma como as GPUs executam o código costuma ser completamente opaca.
Uma única carga de trabalho defeituosa ou uma única falha de driver defeituosa em um ambiente de GPU compartilhado também pode derrubar todas as cargas de trabalho (trabalho) que estavam sendo executadas no mesmo servidor, aumentando a quantidade de danos causados por uma falha operacional.
Atualmente, existem opções imaturas para inspeção de tempo de execução ou auditoria comportamental, limitando a visibilidade e o controle das equipes de segurança. Os drivers de GPU fornecem uma grande superfície de ataque e telemetria geralmente limitada do hardware. Nestes ambientes partilhados, incorporações, pesos, prompts e tokens são agora todos pontos de dados sensíveis, criando pontos cegos significativos para aqueles que tentam proteger a propriedade intelectual.
O alto custo das partidas a frio
A verdadeira restrição em muitas nuvens de GPU não é o desempenho do modelo, mas a eficiência operacional. No momento, as operações de GPU parecem tempos de ativação de locatário de 30 minutos, taxas de inatividade de 70% e engenheiros depurando continuamente pilhas de infraestrutura. As nuvens GPU atuais estão paralisadas não devido a modelos inferiores, mas porque a camada de infraestrutura que sustenta essas nuvens nunca foi projetada para suportar um grau de escala tão alto.
Uma inicialização a frio de 30 minutos é uma limitação fundamental no modelo de negócios moderno de IA. As nuvens de GPU que podem aumentar as cargas de trabalho em segundos acabarão vencendo aquelas que não o fazem. A multilocação é o único meio viável de produzir economia unitária suficiente para tornar esse hardware muito caro viável no longo prazo.
Preenchendo a lacuna de orquestração
As equipes de plataforma estão começando a reconhecer que as GPUs exigem uma camada operacional especializada entre o hardware e as cargas de trabalho. As operadoras precisam de um modelo operacional unificado que ofereça suporte a vários fornecedores de hardware e modelos de GPU. Os provedores de nuvem precisam de um método para dividir e compartilhar servidores com segurança entre os locatários e para evitar falhas em cascata, ao mesmo tempo em que lançam rapidamente novas cargas de trabalho.
As empresas procuram cada vez mais executar aplicações sensíveis de IA com garantias de isolamento mais fortes e, por isso, recorrem a novas categorias de software concebidas especificamente para gerir o “trabalho sujo” da orquestração de hardware.
A corrida para tornar as GPUs mais operacionais
Antes de o Kubernetes padronizar a orquestração de contêineres, o setor debatia constantemente a eficiência do agendamento de contêineres e do empacotamento de contêineres entre clusters. Essas preocupações operacionais foram eventualmente automatizadas e incorporadas em camadas de infraestrutura que tornaram as complexidades invisíveis para o usuário final.
Uma evolução semelhante está ocorrendo hoje em torno das GPUs. Embora as equipes da plataforma continuem discutindo sobre estratégias de posicionamento e ajuste de memória, essas decisões provavelmente serão automatizadas dentro de cinco a 10 anos. À medida que a infraestrutura de IA evolui, a camada mais valiosa pode não ser as GPUs em si, mas as camadas operacionais que as tornam seguras, elásticas e compartilháveis de forma eficiente. Portanto, os vencedores na corrida da IA não serão necessariamente apenas aqueles que possuem mais silício, mas aqueles que possuem os melhores modelos operacionais para tornar esse silício seguro e elástico.
–
Fórum de Nova Tecnologia oferece um local para líderes de tecnologia — incluindo fornecedores e outros colaboradores externos — explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Enviar tudo consultas para [email protected].
