Uma versão abreviada desta postagem apareceu no The New Stack em 19 de março de 2024.

Na inteligência artificial empresarial, existem dois tipos principais de modelos: discriminativo e generativo. Modelos discriminativos são usados para classificar ou prever dados, enquanto modelos generativos são usados para criar novos dados. Embora a IA generativa tenha dominado as notícias ultimamente, as organizações ainda buscam os dois tipos de IA. A IA discriminativa continua a ser uma iniciativa importante para as organizações que pretendem operar de forma mais eficiente e procurar fontes de receitas adicionais. Esses diferentes tipos de IA têm muito em comum, mas, ao mesmo tempo, existem diferenças significativas que devem ser levadas em consideração ao construir sua infraestrutura de dados de IA.

As organizações não devem construir uma infraestrutura dedicada apenas à IA e à IA, deixando cargas de trabalho como Business Intelligence, Data Analytics e Data Science à sua própria sorte. É possível construir uma infraestrutura de dados completa que suporte todas as necessidades da organização – Business Intelligence, Data Analytics, Data Science, IA discriminativa e IA Generativa.

Em outro post, apresentamos uma arquitetura de referência para um datalake moderno capaz de atender às necessidades de business intelligence, análise de dados, ciência de dados e IA/ML. Vamos revisar a arquitetura de referência moderna do Datalake e destacar os recursos que ela possui para oferecer suporte a cargas de trabalho de IA/ML.

O Datalake Moderno

Vamos começar definindo um Datalake Moderno, pois servirá de base para nossa arquitetura de referência. Esta arquitetura não é “reciclada”, mas reflete os primeiros princípios de engenharia que são amplamente aplicáveis. Um Datalake moderno é metade Data Warehouse e metade Data Lake e usa armazenamento de objetos para tudo. Usar o armazenamento de objetos para um Data Lake faz todo o sentido, pois o armazenamento de objetos é para dados não estruturados, que é o que um Data Lake deve armazenar. No entanto, usar armazenamento de objetos para um Data Warehouse pode parecer estranho – mas um Data Warehouse construído desta forma representa a próxima geração de Data Warehouses. Isso é possível graças às especificações de formato de tabela aberta (OTFs) de autoria da Netflix, Uber e Databricks, que facilitam o emprego do armazenamento de objetos em um data warehouse.

Os OTFs são Apache Iceberg, Apache Hudi e Delta Lake. Eles foram de autoria da Netflix, Uber e Databricks, respectivamente – porque não havia produtos no mercado que pudessem atender às suas necessidades de dados. Essencialmente, o que todos eles fazem (de maneiras diferentes) é definir um Data Warehouse que pode ser construído sobre armazenamento de objetos (MinIO). O armazenamento de objetos fornece a combinação de capacidade escalável e alto desempenho que outras soluções de armazenamento não conseguem. Por serem especificações modernas, elas possuem recursos avançados que os data warehouses antigos não possuem - como evolução de partição, evolução de esquema e ramificação de cópia zero. Finalmente, como o Data Warehouse é construído com armazenamento de objetos, você pode usar esse mesmo armazenamento de objetos para dados não estruturados, como imagens, arquivos de vídeo, arquivos de áudio e documentos.

Os dados não estruturados geralmente são armazenados no que a indústria chama de data lake. Usar um armazenamento de objetos como base para seu data lake e seu data warehouse resulta em uma solução capaz de armazenar todos os seus dados. O armazenamento estruturado reside no Data Warehouse baseado em OTF e o armazenamento não estruturado reside no Data Lake. A mesma instância do MinIO poderia ser usada para ambos.

Na MinIO, chamamos essa combinação de Data Warehouse baseado em OTF e Data Lake de Datalake Moderno e a vemos como a base para todas as suas cargas de trabalho de IA/ML. É onde os dados são coletados, armazenados, processados e transformados. Modelos de treinamento que usam IA discriminativa (aprendizado supervisionado, não supervisionado e por reforço) geralmente exigem uma solução de armazenamento que possa lidar com dados estruturados que podem residir no data warehouse. Por outro lado, se você estiver treinando Large Language Models (LLMs), deverá gerenciar dados ou documentos não estruturados em sua forma bruta e processada no Data Lake.

Fonte :

Esta postagem se concentra nas áreas da arquitetura de referência moderna do Datalake para AI/ML que oferecem suporte às diferentes cargas de trabalho de AI/ML. Essas áreas funcionais estão listadas abaixo. Uma representação visual do Modern Datalake é mostrada acima. As camadas nas quais essas áreas funcionais podem ser encontradas foram destacadas.

• IA discriminativa

  
  

  • Armazenamento para dados não estruturados
  • Armazenamento para dados semiestruturados
  • Ramificação de cópia zero no data warehouse

    
    

• IA generativa

  
  

  • Construindo um Corpus Personalizado com um Banco de Dados Vetorial
  • Construindo um pipeline de documentos
  • Geração Aumentada de Recuperação (RAG)
  • Ajustando modelos de linguagem grande
  • Medindo a precisão do LLM

    
    

• Operações de aprendizado de máquina

  
  

Esta postagem também analisa o estado atual das GPUs e como elas impactam sua infraestrutura de dados de IA. Também veremos alguns cenários que ilustram como construir sua infraestrutura e como não construí-la. Por fim, esta postagem apresenta algumas recomendações para construir sua própria infraestrutura de dados de IA.

• O estado atual das GPUs

  
  

  • O problema da GPU faminta
  • Sobrecarregando o armazenamento de objetos

    
    

• Uma história de duas organizações
• Um plano para construir sua infraestrutura de dados de IA

IA discriminativa

Os modelos discriminativos de IA requerem dados de todos os tipos para treinamento. Modelos para classificação de imagens e reconhecimento de fala utilizarão dados não estruturados na forma de imagens e arquivos de áudio. Por outro lado, modelos de detecção de fraudes e diagnóstico médico fazem previsões baseadas em dados estruturados. Vejamos as opções disponíveis no Modern Datalake para armazenar e manipular os dados necessários à IA discriminativa.

Armazenamento para dados não estruturados

Os dados não estruturados residirão no Data Lake, onde poderão ser usados para treinamento e teste de modelos. Conjuntos de treinamento que cabem na memória podem ser carregados antes do treinamento (antes do início do loop de época). No entanto, se o seu conjunto de treinamento for grande e não caber na memória, você terá que carregar uma lista de objetos antes do treinamento e recuperar os objetos reais enquanto processa cada lote em seu loop de época. Isso poderá sobrecarregar seu Data Lake se você não construí-lo usando uma rede de alta velocidade e unidades de disco de alta velocidade. Se você estiver treinando modelos com dados que não cabem na memória, considere criar seu Data Lake com uma rede de 100 GB e unidades NVMe.

Armazenamento para dados semiestruturados

Existem algumas opções disponíveis no Modern Datalake para armazenar arquivos semiestruturados, como arquivos Parquet, arquivos AVRO, arquivos JSON e até arquivos CSV. A coisa mais fácil a fazer é armazená-los em seu Data Lake e carregá-los da mesma forma que você carrega objetos não estruturados. Se os dados nesses arquivos semiestruturados não forem necessários para outras cargas de trabalho suportadas pelo Modern Datalake (Business Intelligence, Data Analytics e Data Science), então esta é a melhor opção.

Outra opção é carregar esses arquivos em seu Data Warehouse, onde outras cargas de trabalho podem utilizá-los. Quando os dados são carregados em seu Data Warehouse, você pode usar com seus dados.

Ramificação de cópia zero no data warehouse

A engenharia de recursos é uma técnica para melhorar conjuntos de dados usados para treinar um modelo. Um recurso muito inteligente que os data warehouses baseados em OTF possuem é a ramificação de cópia zero. Isso permite que os dados sejam ramificados da mesma forma que o código pode ser ramificado em um repositório Git. Como o nome sugere, esse recurso não faz uma cópia dos dados - em vez disso, utiliza a camada de metadados do formato de tabela aberta usado para implementar o Data Warehouse para criar a aparência de uma cópia exclusiva dos dados. Os cientistas de dados podem experimentar uma ramificação - se seus experimentos forem bem-sucedidos, eles poderão mesclar sua ramificação novamente na ramificação principal para uso de outros cientistas de dados. Se o experimento não for bem-sucedido, o branch poderá ser excluído.

IA generativa

Todos os modelos, sejam eles pequenos modelos construídos com Scikit-Learn, redes neurais personalizadas construídas com PyTorch ou TensorFlow, ou modelos de linguagem grande baseados na arquitetura Transformer, exigem números como entradas e produzem números como saídas. Este simples fato impõe alguns requisitos adicionais à sua infraestrutura de IA/ML se você estiver interessado em IA generativa, onde as palavras devem ser transformadas em números (ou vetores, como veremos). Uma solução de IA generativa fica ainda mais complicada se você quiser usar documentos privados que contenham o conhecimento proprietário da sua empresa para aprimorar as respostas produzidas pelos LLMs. Esse aprimoramento pode ser na forma de Geração Aumentada de Recuperação ou Ajuste Fino de LLM.

Esta seção discutirá todas essas técnicas (transformar palavras em números, RAG e ajuste fino) e seu impacto na infraestrutura de IA. Vamos começar discutindo como construir um Corpus Personalizado e onde ele deve residir.

Criando um Corpus Personalizado com um Banco de Dados Vetorial

Se você leva a IA generativa a sério, seu corpus personalizado deve definir sua organização. Deve conter documentos com conhecimentos que ninguém mais possui e conter apenas informações verdadeiras e precisas. Além disso, seu corpus customizado deve ser construído com um banco de dados vetorial. Um banco de dados vetorial indexa, armazena e fornece acesso aos seus documentos juntamente com suas incorporações vetoriais, que são as representações numéricas dos seus documentos. (Isso resolve o problema numérico descrito acima.)

Bancos de dados vetoriais facilitam a pesquisa semântica. Como isso é feito requer muita base matemática e é complicado. No entanto, a pesquisa semântica é conceitualmente fácil de entender. Digamos que você queira encontrar todos os documentos que discutam qualquer coisa relacionada à “inteligência artificial”. Para fazer isso em um banco de dados convencional, você precisaria pesquisar todas as abreviações, sinônimos e termos relacionados possíveis de “inteligência artificial”. Sua consulta seria mais ou menos assim:

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

A pesquisa manual por similaridade não é apenas árdua e propensa a erros, mas a pesquisa em si é muito lenta. Um banco de dados vetorial pode receber uma solicitação como abaixo e executar a consulta com mais rapidez e precisão. A capacidade de executar consultas semânticas com rapidez e precisão é importante se você deseja usar a Geração Aumentada de Recuperação.

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

Outra consideração importante para seu corpus personalizado é a segurança. O acesso aos documentos deve respeitar as restrições de acesso aos documentos originais. (Seria lamentável se um estagiário pudesse obter acesso aos resultados financeiros do CFO que ainda não foram divulgados para Wall Street.) Dentro do seu banco de dados de vetores, você deve configurar uma autorização para corresponder aos níveis de acesso do conteúdo original. Isso pode ser feito integrando seu banco de dados Vector à solução de gerenciamento de identidade e acesso da sua organização.

Basicamente, os bancos de dados vetoriais armazenam dados não estruturados. Portanto, eles devem usar seu Data Lake como solução de armazenamento.

Construindo um pipeline de documentos

Infelizmente, a maioria das organizações não possui um único repositório com documentos limpos e precisos. Em vez disso, os documentos são espalhados pela organização em vários portais de equipe em vários formatos. Conseqüentemente, a primeira etapa na construção de um corpus personalizado é construir um pipeline que pegue apenas documentos que foram aprovados para uso com IA generativa e coloque-os em seu banco de dados vetorial. Para grandes organizações globais, esta poderia ser potencialmente a tarefa mais difícil de uma solução de IA generativa. É comum que as equipes tenham documentação em formato rascunho em seus portais. Também pode haver documentos que sejam reflexões aleatórias sobre o que poderia ser. Esses documentos não devem fazer parte de um corpus personalizado, pois não representam o negócio com precisão. Infelizmente, filtrar esses documentos será um esforço manual.

Um pipeline de documentos também deve converter os documentos em texto. Felizmente, algumas bibliotecas de código aberto podem fazer isso para muitos dos formatos de documentos comuns. Além disso, um pipeline de documentos deve dividir os documentos em pequenos segmentos antes de salvá-los no banco de dados vetorial. Isto se deve às limitações no tamanho do prompt quando esses documentos são usados para a Geração Aumentada de Recuperação, que será discutida em uma seção posterior.

Ajustando modelos de linguagem grande

Quando ajustamos um modelo de linguagem grande, treinamos um pouco mais com as informações do corpus customizado. Esta pode ser uma boa maneira de obter um LLM específico de domínio. Embora esta opção exija computação para realizar o ajuste fino em seu corpus personalizado, ela não é tão intensiva quanto treinar um modelo do zero e pode ser concluída em um período de tempo modesto.

Se o seu domínio incluir termos não encontrados no uso diário, o ajuste fino poderá melhorar a qualidade das respostas do LLM. Por exemplo, projectos que utilizem documentos de investigação médica, investigação ambiental e qualquer coisa relacionada com as ciências naturais podem beneficiar de ajustes finos. O ajuste fino pega o vernáculo altamente específico encontrado em seus documentos e os incorpora aos parâmetros paramétricos do modelo. As vantagens e desvantagens do ajuste fino devem ser compreendidas antes de decidir sobre esta abordagem.

Desvantagens

• O ajuste fino exigirá recursos de computação.
• A explicabilidade não é possível.
• Periodicamente, você precisará fazer ajustes finos com novos dados à medida que seu corpus evolui.
• As alucinações são uma preocupação.
• A segurança em nível de documento é impossível.

  
  

Vantagens

• O LLM possui conhecimento de seu corpus personalizado por meio de ajuste fino.
• O fluxo de inferência é menos complicado que o RAG.

  
  

Embora o ajuste fino seja uma boa maneira de ensinar um LLM sobre a linguagem do seu negócio, ele dilui os dados, uma vez que a maioria dos LLMs contém bilhões de parâmetros, e seus dados estarão espalhados por todos esses parâmetros. A maior desvantagem do ajuste fino é que a autorização em nível de documento é impossível. Depois que um documento é usado para ajuste fino, suas informações passam a fazer parte do modelo. Não é possível restringir esta informação com base nos níveis de autorização do usuário.

Vejamos uma técnica que combina seus dados personalizados e dados paramétricos no momento da inferência.

Geração Aumentada de Recuperação (RAG)

A Geração Aumentada de Recuperação (RAG) é uma técnica que começa com a pergunta sendo feita - usa um banco de dados vetorial para casar as perguntas com dados adicionais e, em seguida, passa a pergunta e os dados para um LLM para criação de conteúdo. Com o RAG, nenhum treinamento é necessário porque educamos o LLM enviando-lhe trechos de texto relevantes de nosso corpus de documentos de qualidade.

Funciona assim usando uma tarefa de resposta a perguntas: um usuário faz uma pergunta na interface de usuário do seu aplicativo. Seu aplicativo responderá à pergunta - especificamente as palavras nela contidas - e, usando um banco de dados vetorial, pesquisará em seu corpus de documentos de qualidade trechos de texto que sejam contextualmente relevantes. Esses trechos e a pergunta original são enviados ao LLM. Todo esse pacote - pergunta mais trechos (contexto) é conhecido como prompt. O LLM usará essas informações para gerar sua resposta. Isso pode parecer uma coisa boba de se fazer - se você já sabe a resposta (os trechos), por que se preocupar com o LLM? Lembre-se, isso está acontecendo em tempo real e o objetivo é gerar texto – algo que você pode copiar e colar em sua pesquisa. Você precisa do LLM para criar o texto que incorpora as informações do seu corpus personalizado.

Isso é mais complicado do que o ajuste fino. No entanto, a autorização do usuário pode ser implementada, uma vez que os documentos (ou trechos de documentos) são selecionados do banco de dados vetorial no momento da inferência. As informações contidas nos documentos nunca passam a fazer parte dos parâmetros paramétricos do modelo. As vantagens e desvantagens do RAG estão listadas abaixo.

Desvantagens

• O fluxo de inferência é mais complicado.

  
  

Vantagens

• O LLM possui conhecimento direto do seu corpus customizado.
• A explicabilidade é possível.
• Nenhum ajuste fino é necessário.
• As alucinações são significativamente reduzidas e podem ser controladas examinando os resultados das consultas ao banco de dados vetorial.
• A autorização pode ser implementada.

Operações de aprendizado de máquina (MLOps)

Para compreender melhor a importância dos MLOps, é útil comparar a criação de modelos com o desenvolvimento de aplicações convencionais. O desenvolvimento convencional de aplicativos, como a implementação de um novo microsserviço que adiciona um novo recurso a um aplicativo, começa com a revisão de uma especificação. Quaisquer novas estruturas de dados ou alterações nas estruturas de dados existentes são projetadas primeiro. O design dos dados não deve mudar após o início da codificação. O serviço é então implementado e a codificação é a principal atividade deste processo. Testes unitários e testes ponta a ponta também são codificados. Esses testes provam que o código não apresenta falhas e implementa corretamente a especificação. Eles podem ser executados automaticamente por um pipeline de CI/CD antes da implantação de todo o aplicativo.

Criar um modelo e treiná-lo é diferente. Uma compreensão dos dados brutos e da previsão necessária é o primeiro passo. Os engenheiros de ML precisam escrever algum código para implementar suas redes neurais ou configurar um algoritmo, mas a codificação não é a atividade dominante. A experimentação repetida é a atividade principal. Durante a experimentação, o design dos dados, o design do modelo e os parâmetros usados serão todos alterados. Após cada experimento, são criadas métricas que mostram o desempenho do modelo durante o treinamento. As métricas também são geradas para o desempenho do modelo em relação a um conjunto de validação e um conjunto de teste. Essas métricas são usadas para comprovar a qualidade do modelo. Quando um modelo estiver pronto para ser incorporado a uma aplicação, ele precisará ser empacotado e implantado.

MLOps, abreviação de Machine Learning Operations, é um conjunto de práticas e ferramentas destinadas a abordar essas diferenças. O rastreamento de experimentos e a colaboração são os recursos mais associados aos MLOPs, mas as ferramentas de MLOPs mais modernas do setor hoje podem fazer muito mais. Por exemplo, eles podem fornecer um ambiente de tempo de execução para seus experimentos e podem empacotar e implantar modelos quando estiverem prontos para serem integrados a um aplicativo. Abaixo está um superconjunto de recursos encontrados nas ferramentas MLOps atualmente. Esta lista também inclui outras coisas a serem consideradas, como suporte e integração de dados.

1. Suporte de um grande player - as técnicas e recursos de MLOps estão em constante evolução. Você quer uma ferramenta que seja apoiada por um grande player, garantindo que a ferramenta esteja em constante desenvolvimento e aprimoramento.

   
   

2. Integração moderna do Datalake – Os experimentos geram muitos dados estruturados e não estruturados. Idealmente, isso poderia ser armazenado no Data Warehouse e no Data Lake. No entanto, muitas ferramentas MLOps já existiam antes dos formatos de tabela aberta que deram origem ao Modern Datalake, portanto, a maioria terá uma solução separada para seus dados estruturados.

   
   

3. Acompanhamento de experimentos - acompanhe os conjuntos de dados, modelos, hiperparâmetros e métricas de cada experimento. O rastreamento de experimentos também deve facilitar a repetibilidade.

   
   

4. Facilite a colaboração - permita que os membros da equipe visualizem os resultados de todos os experimentos executados por todos os engenheiros de ML.

   
   

5. Model Packaging - Empacote o modelo de forma que seja acessível a partir de outros ambientes de programação.

   
   

6. Model Serving - Implantação de modelos nos ambientes formais de uma organização. Você não precisará disso se tiver encontrado uma maneira de incorporar seus modelos em um pipeline de CI/CD existente.

   
   

7. Registro de Modelo - Mantenha todas as versões de todos os modelos.

   
   

8. Funções sem servidor – Algumas ferramentas fornecem recursos que permitem que o código seja anotado de forma que uma função ou modelo possa ser implantado como um serviço em contêiner para a execução de experimentos em um cluster.

   
   

9. Capacidades de pipeline de dados - Algumas ferramentas MLOps visam fornecer recursos completos de ponta a ponta e possuem recursos que permitem construir pipelines para recuperar e armazenar seus dados brutos. Você não precisará disso se já tiver um pipeline de dados.

   
   

10. Capacidades de pipeline de treinamento - A capacidade de orquestrar suas funções sem servidor em um gráfico acíclico direcionado. Também permite o agendamento e execução de pipelines de treinamento.

O impacto das GPUs na sua infraestrutura de dados de IA

Uma cadeia é tão forte quanto seu elo mais fraco – e sua infraestrutura de IA/ML é tão rápida quanto seu componente mais lento. Se você treinar modelos de aprendizado de máquina com GPUs, seu elo mais fraco pode ser sua solução de armazenamento. O resultado é o que chamamos de “problema de GPU faminta”. O problema de Starving GPU ocorre quando sua rede ou solução de armazenamento não consegue fornecer dados de treinamento à sua lógica de treinamento com rapidez suficiente para utilizar totalmente suas GPUs. Os sintomas são bastante óbvios. Se você monitorar suas GPUs, notará que elas nunca chegam perto de serem totalmente utilizadas. Se você instrumentou seu código de treinamento, notará que o tempo total de treinamento é dominado por IO.

Infelizmente, há más notícias para aqueles que estão lutando com esse problema. As GPUs estão ficando mais rápidas. Vejamos o estado atual das GPUs e alguns avanços feitos com elas para entender como esse problema só vai piorar nos próximos anos.

O estado atual das GPUs

As GPUs estão ficando mais rápidas. Não apenas o desempenho bruto está melhorando, mas a memória e a largura de banda também estão aumentando. Vamos dar uma olhada nessas três características das GPUs mais recentes da Nvidia, o , o e a .

GPU	DESEMPENHO	MEMÓRIA	LARGURA DE BANDA DE MEMÓRIA
A100	624 TFLOPS	40 GB	1.555 GB/s
H100	1.979 TFLOPS	80 GB	3,35 TB/s
H200	1.979 TFLOPS	141 GB	4,8 TB/s

Vale a pena destacar algumas observações comparativas sobre as estatísticas acima. Primeiro, o H100 e o H200 têm o mesmo desempenho (1.979 TFLOPS), que é 3,17 vezes maior que o A100. O H100 tem o dobro de memória que o A100 e a largura de banda da memória aumentou na mesma quantidade - o que faz sentido, caso contrário, a GPU morreria de fome. O H200 pode lidar com impressionantes 141 GB de memória e sua largura de banda de memória também aumentou proporcionalmente em relação às outras GPUs.

Vamos examinar cada uma dessas estatísticas com mais detalhes e discutir o que elas significam para o aprendizado de máquina.

Desempenho - Um teraflop (TFLOP) equivale a um trilhão (10^12) de operações de ponto flutuante por segundo. Isso é um 1 com 12 zeros depois (1.000.000.000.000). É difícil equiparar TFLOPs à demanda de IO em gigabytes, pois as operações de ponto flutuante que ocorrem durante o treinamento do modelo envolvem matemática simples de tensores, bem como primeiras derivadas contra a função de perda (também conhecida como gradientes). No entanto, comparações relativas são possíveis. Olhando para as estatísticas acima, vemos que o H100 e o H200, ambos com desempenho de 1.979 TFLOPS, são três vezes mais rápidos – potencialmente consumindo dados 3 vezes mais rápido se todo o resto puder acompanhar.

Memória GPU - Também conhecida como RAM de vídeo ou RAM gráfica. A memória da GPU é separada da memória principal do sistema (RAM) e foi projetada especificamente para lidar com as tarefas intensivas de processamento gráfico executadas pela placa gráfica. A memória da GPU determina o tamanho do lote ao treinar modelos. No passado, o tamanho do lote diminuía quando a lógica de treinamento passava de uma CPU para uma GPU. No entanto, à medida que a memória da GPU alcança a memória da CPU em termos de capacidade, o tamanho do lote usado para treinamento da GPU aumentará. Quando o desempenho e a capacidade de memória aumentam ao mesmo tempo, o resultado são solicitações maiores, onde cada gigabyte de dados de treinamento é processado mais rapidamente.

Largura de banda de memória - Pense na largura de banda de memória da GPU como a “rodovia” que conecta a memória e os núcleos de computação. Ele determina quantos dados podem ser transferidos por unidade de tempo. Assim como uma rodovia mais larga permite que mais carros passem em um determinado período de tempo, uma largura de banda de memória maior permite que mais dados sejam movidos entre a memória e a GPU. Como você pode ver, os projetistas dessas GPUs aumentaram a largura de banda da memória para cada nova versão proporcional à memória; portanto, o barramento de dados interno do chip não será o gargalo.

Turbine o armazenamento de objetos para treinamento de modelo

Se você estiver enfrentando o problema de Starving GPU, considere usar uma rede de 100 GB e unidades NVMe. A usar MinIO com essa configuração alcançou 325 GiB/s em GETs e 165 GiB/s em PUTs com apenas 32 nós de SSDs NVMe prontos para uso.

À medida que o mundo da computação evoluiu e o descobrimos que as configurações do servidor geralmente vêm com 500 GB ou mais de DRAM. Quando você está lidando com implantações maiores, mesmo aquelas com unidades NVMe ultradensas, o número de servidores multiplicado pela DRAM nesses servidores pode aumentar rapidamente - geralmente até muitos TB por instância. Esse pool DRAM pode ser configurado como um pool compartilhado distribuído de memória e é ideal para cargas de trabalho que exigem IOPS massivas e desempenho de taxa de transferência. Como resultado, construímos o MinIO Cache para permitir que nossos clientes Enterprise e Enterprise Lite configurem sua infraestrutura para aproveitar esse pool de memória compartilhada para melhorar ainda mais o desempenho das principais cargas de trabalho de IA, como treinamento de GPU, mantendo simultaneamente a persistência total.

Uma história de duas organizações

Como experimento mental conclusivo, vamos contar a história de duas organizações que adotam abordagens muito diferentes em sua jornada de IA/ML. A organização nº 1 tem uma cultura de “Melhorias Iterativas”. Eles acreditam que todas as grandes iniciativas podem ser divididas em projetos menores e mais gerenciáveis. Esses projetos menores são então programados de forma que cada um se baseie nos resultados do projeto anterior para resolver problemas cada vez mais complexos. Eles também gostam desses pequenos projetos organizados de forma que cada um agregue valor ao negócio. Eles descobriram que projetos que tratam apenas de melhoria de infraestrutura ou modernização de software, sem quaisquer novos recursos para o negócio, não são muito populares entre os executivos que controlam os orçamentos. Consequentemente, eles aprenderam que solicitar dispositivos de armazenamento e clusters de computação sofisticados para uma prova de conceito de IA generativa não é a melhor maneira de orquestrar melhorias de infraestrutura e novos recursos de software. Em vez disso, eles começarão pequenos, com produtos de infraestrutura que podem ser dimensionados à medida que crescem - e começarão com modelos simples de IA para que possam implementar suas ferramentas de MLOPs e descobrir como trabalhar com equipes de DevOps e pipelines de CI/CD existentes.

A organização nº 2 tem uma cultura de “Objetos Brilhantes”. Quando a ideia mais recente entra na indústria, ela primeiro enfrenta o desafio de maior perfil para demonstrar o seu poder técnico. Eles descobriram que esses projetos são altamente visíveis tanto interna quanto externamente. Se algo quebrar, pessoas inteligentes sempre poderão consertar.

A Organização nº 1 estruturou seu primeiro projeto construindo uma parte de sua infraestrutura de dados de IA enquanto trabalhava em um modelo de recomendação para seu principal site de comércio eletrônico. O modelo de recomendação foi relativamente simples de treinar. É um modelo discriminativo que utiliza conjuntos de dados que já existem em um compartilhamento de arquivos. No entanto, no final deste projeto, a equipe também construiu um pequeno (mas escalonável) Modern Datalake, implementou ferramentas de MLOPs e implementou algumas práticas recomendadas para treinamento e implantação de modelos. Mesmo que o modelo não seja complicado, ele ainda adicionou muitas eficiências ao seu site. Eles usaram esses resultados positivos para obter financiamento para seu próximo projeto, que será uma solução generativa de IA.

A organização nº 2 criou um chatbot para seu site de comércio eletrônico que respondia às perguntas dos clientes sobre os produtos. Os modelos de linguagem grande são bastante complicados - a equipe não estava familiarizada com ajuste fino ou geração aumentada de recuperação - portanto, todos os ciclos de engenharia deste projeto se concentraram em avançar rapidamente em uma curva de aprendizado acentuada. Quando o modelo foi concluído, produziu bons resultados - nada de espetacular. Infelizmente, ele teve que ser carregado manualmente nos ambientes de pré-produção e produção porque não havia ferramentas de MLOps para implantá-lo. Isso causou um pequeno atrito com a equipe de DevOps. O modelo em si também teve alguns problemas de estabilidade na produção. O cluster em que estava sendo executado não tinha computação suficiente para uma carga de trabalho generativa de IA. Houve algumas chamadas de gravidade um, que resultaram em um aprimoramento de emergência no cluster para que o LLM não falhasse em condições de tráfego intenso. Após o projeto, uma retrospectiva determinou que eles precisavam aumentar sua infraestrutura se quisessem ter sucesso com a IA.

Um plano para construir sua infraestrutura de dados de IA/ML

O conto acima é uma narrativa simples de duas circunstâncias extremas. A construção de modelos de IA (discriminativos e generativos) é significativamente diferente do desenvolvimento de software convencional. Isso deve ser levado em consideração ao colocar em fila um esforço de IA/ML. O gráfico abaixo é uma representação visual da história contada na seção anterior. É uma comparação lado a lado da abordagem AI Data Infrastructure First versus a abordagem Model First. Como a história acima mostrou – cada um dos blocos abaixo para a primeira abordagem de infraestrutura não precisa ser um projeto independente. As organizações devem procurar formas criativas de fornecer IA enquanto a sua infraestrutura está a ser construída - isto pode ser feito através da compreensão de todas as possibilidades da IA, começando de forma simples, e depois escolhendo projetos de IA de complexidade crescente.

Conclusão

Esta postagem descreve nossa experiência em trabalhar com empresas para construir uma arquitetura de referência moderna do Datalake para IA/ML. Identifica os componentes principais, os principais blocos de construção e as compensações das diferentes abordagens de IA. O elemento fundamental é um data lake moderno construído sobre um armazenamento de objetos. O armazenamento de objetos deve ser capaz de fornecer desempenho em escala - onde a escala é de centenas de petabytes e muitas vezes de exabytes.

Seguindo esta arquitetura de referência, prevemos que o usuário será capaz de construir uma infraestrutura de dados flexível e extensível que, embora voltada para IA e ML, terá o mesmo desempenho em todas as cargas de trabalho OLAP. Para obter recomendações específicas sobre os componentes, não hesite em entrar em contato comigo em .