![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
No paradigma atual de aprendizado de máquina, o desempenho e a capacidade são dimensionados com a computação, que é realmente um proxy para o tamanho do conjunto de dados e o tamanho do modelo ( Scaling Laws for Neural Language Models , Kaplan et. al.). Nos últimos anos, isso trouxe mudanças radicais em como o aprendizado de máquina e a infraestrutura de dados são construídos – a saber: a separação de armazenamento e computação, a construção de enormes data lakes nativos da nuvem cheios de dados não estruturados e hardware especializado que pode fazer multiplicação de matrizes muito rápido.
Quando um conjunto de dados de treinamento, ou mesmo um fragmento individual de um conjunto de dados, requer mais espaço do que o disponível na memória do sistema e/ou armazenamento local, a importância de desacoplar o armazenamento da computação se torna gritantemente evidente. Ao treinar em dados que residem no MinIO Object Store, não há limites para o tamanho dos seus dados de treinamento. Devido ao foco do MinIO na simplicidade e na taxa de transferência de E/S, é a rede que se torna o único fator limitante para a velocidade de treinamento e utilização da GPU.
Além de proporcionar o melhor desempenho de qualquer armazenamento de objetos, o MinIO é compatível com todas as estruturas modernas de aprendizado de máquina. O MinIO Object Store também é 100% compatível com a API S3, para que você possa executar cargas de trabalho de ML em seu armazenamento de objetos no local ou no dispositivo usando utilitários de conjunto de dados familiares, como o TorchData
Além do desempenho e da compatibilidade com a pilha de ML moderna, as escolhas de design do armazenamento de objetos, a saber (1) um namespace simples, (2) o encapsulamento de todo o objeto (e seus metadados) como a entidade lógica mais baixa e (3) APIs de verbos HTTP simples, são o que levaram o armazenamento de objetos a se tornar o padrão de fato para data lakes massivos não estruturados. Uma olhada na história recente do aprendizado de máquina mostra que os dados de treinamento (e, em certo sentido, as próprias arquiteturas de modelo) se tornaram menos estruturados e mais gerais. Costumava ser o caso de que os modelos eram predominantemente treinados em dados tabulares. Hoje em dia, há uma gama muito mais ampla, de parágrafos de texto simples a horas de vídeo. À medida que as arquiteturas de modelo e os aplicativos de ML evoluem, a natureza sem estado, sem esquema e, consequentemente, escalável do armazenamento de objetos só se torna mais crítica.
Devido às escolhas de design do MinIO Object Store, cada objeto pode conter metadados ricos e sem esquema sem sacrificar o desempenho ou exigir o uso de um servidor de metadados dedicado. A imaginação é realmente o único limite quando se trata de que tipo de metadados você deseja adicionar aos seus objetos. No entanto, aqui estão algumas ideias que podem ser particularmente úteis para objetos relacionados a ML:
Para pontos de verificação do modelo : valor da função de perda, tempo gasto no treinamento, conjunto de dados usado para o treinamento.
Para conjuntos de dados: nome dos arquivos de índice pareados (se aplicável), categoria do conjunto de dados (treinamento, validação, teste), informações sobre o formato do conjunto de dados.
Metadados altamente descritivos como estes podem ser particularmente poderosos quando combinados com a capacidade de indexar e consultar esses metadados de forma eficiente, mesmo em bilhões de objetos, algo que o
À medida que os modelos de aprendizado de máquina e seus conjuntos de dados se tornam ativos cada vez mais críticos, tornou-se igualmente importante armazenar e gerenciar esses ativos de uma forma tolerante a falhas, auditável e versionável.
Conjuntos de dados e os modelos que treinam neles são ativos valiosos que são produtos arduamente conquistados de tempo, esforço de engenharia e dinheiro. Consequentemente, eles devem ser protegidos de uma forma que não atrapalhe o acesso por aplicativos. As operações inline do MinIO, como verificação de bitrot e codificação de apagamento, juntamente com recursos como replicação multisite, ativa-ativa, garantem a resiliência desses objetos em escala.
Com a IA generativa em particular, saber qual versão de qual conjunto de dados foi usada para treinar um modelo específico que está sendo servido é útil ao depurar alucinações e outros comportamentos incorretos do modelo. Se os pontos de verificação do modelo forem versionados corretamente, fica mais fácil confiar em uma reversão rápida para uma versão servida anteriormente do ponto de verificação. Com o MinIO Object Store, você obtém esses benefícios para seus objetos imediatamente.
O MinIO Object Store é, fundamentalmente, um object store que você, ou sua organização, controla. Seja o caso de uso para prototipagem, segurança, regulamentação ou
Mas por que isso importa? Atraso de rede ou interrupções em repositórios de modelos de terceiros podem tornar os modelos lentos para serem servidos para inferência ou totalmente indisponíveis. Além disso, em um ambiente de produção onde os servidores de inferência estão escalando e precisam extrair pontos de verificação de modelo rotineiramente, esse problema pode ser exacerbado. Nas circunstâncias mais seguras e/ou críticas, é melhor evitar a dependência de terceiros pela Internet sempre que possível. Com o MinIO como um armazenamento de objetos de nuvem privada ou híbrida, é possível evitar esses problemas completamente.
Essas quatro razões não são de forma alguma uma lista exaustiva. Desenvolvedores e organizações usam o MinIO Object Storage para suas cargas de trabalho de IA por uma grande variedade de razões, que vão desde a facilidade de desenvolvimento até sua pegada super leve.
No início deste post, abordamos as forças motrizes por trás da adoção do armazenamento de objetos de alto desempenho para IA. Independentemente de as leis de dimensionamento se manterem ou não, o que certamente será verdade é que as organizações e suas cargas de trabalho de IA sempre se beneficiarão da melhor capacidade de transferência de E/S disponível. Além disso, podemos estar bastante confiantes de que os desenvolvedores nunca pedirão APIs que sejam mais difíceis de usar e software que não "simplesmente funcione". Em qualquer futuro em que essas suposições se mantenham, o armazenamento de objetos de alto desempenho é o caminho.
Para qualquer arquiteto e tomador de decisões de engenharia que esteja lendo isto, muitas das melhores práticas mencionadas aqui podem ser automatizadas para garantir que o armazenamento de objetos seja aproveitado de uma forma que torne seus fluxos de trabalho de IA/ML mais simples e escaláveis. Isso pode ser feito por meio do uso de qualquer um dos conjuntos de ferramentas MLOps modernos. O especialista em IA/ML Keith Pijanowski explorou muitas dessas ferramentas - pesquise em nosso blog por Kubeflow, MLflow e MLRun para obter mais informações sobre ferramentas MLOps. No entanto, se essas ferramentas MLOps não forem uma opção para sua organização e você precisar começar rapidamente, as técnicas mostradas nesta postagem são a melhor maneira de começar a gerenciar seus fluxos de trabalho de IA/ML com o MinIO.
Para desenvolvedores (ou qualquer pessoa curiosa 🙂), em uma futura postagem do blog, faremos um passo a passo completo sobre como adaptar uma estrutura de ML para aproveitar o armazenamento de objetos com o objetivo de dados de treinamento "sem limites" e utilização adequada da GPU.
Obrigado por ler, espero que tenha sido informativo! Como sempre, se você tiver alguma dúvida, junte-se a nós