1. Sem limites para dados não estruturados

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 Tubo de dados S3 . No caso em que recursos semelhantes aos do sistema de arquivos sejam exigidos pelo seu aplicativo de consumo, você pode até mesmo usar o MinIO com interfaces de arquivo de armazenamento de objetos como Ponto de montagem S3 ou S3FS . Em uma postagem futura do blog, usaremos o MinIO Python SDK em implementações personalizadas de algumas interfaces comuns do PyTorch e FairSeq (como Dataset e Task, respectivamente) para permitir dados de treinamento "sem limites" e alta utilização de GPU para treinamento de modelos.

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.

2. Metadados ricos para modelos e conjuntos de dados

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 Catálogo MinIO Enterprise oferece. Por exemplo, você pode consultar pontos de verificação de modelo que são marcados como “testados” ou pontos de verificação que foram treinados em um conjunto de dados específico.

3. Modelos e conjuntos de dados estão disponíveis, auditáveis e versionáveis

À 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.

4. Infraestrutura de serviço própria

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 fins econômicos , o controle é o fio condutor. Consequentemente, se os checkpoints de modelo treinados residem no armazenamento de objetos, isso lhe dá maior controle sobre a tarefa de servir modelos para inferência ou consumo.

Em um post anterior , exploramos os benefícios de armazenar arquivos de modelo no armazenamento de objetos e como servi-los diretamente com o framework de inferência TorchServe do PyTorch. No entanto, essa é uma estratégia totalmente independente de modelo e framework.

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.

Considerações Finais

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 Canal Slack ou deixe-nos uma mensagem em olá@min.io .