O que é um acelerador distribuído para armazenamento na nuvem? (pré-visualização)

Acelerador distribuído para armazenamento na cloud (DACS) é uma cache distribuída e read-through que acelera o carregamento de modelos a partir do Armazenamento de Blobs do Azure para inferência de IA no Azure Kubernetes Service (AKS). Utiliza discos NVMe locais entre nós de cache para manter os dados lidos frequentemente próximos do processamento da GPU. Os DACS também podem acelerar o carregamento de conjuntos de dados para cargas de trabalho de treino que leem repetidamente os mesmos dados. Armazenamento de Blobs do Azure continua a ser a fonte duradoura e autoritária para ficheiros de modelo e conjuntos de dados.

Ativas e geres o DACS através do Azure Container Storage, que instala a extensão gerida do DACS e gere o seu ciclo de vida no AKS. O DACS não é um volume persistente, uma StorageClass, nem um substituto do Armazenamento de Blobs do Azure. Para criar volumes persistentes Kubernetes, veja O que é o Azure Container Storage?

Importante

O DACS está em pré-visualização. As funcionalidades de pré-visualização são fornecidas sem um acordo de nível de serviço, não sendo recomendadas para cargas de trabalho de produção. Algumas funcionalidades podem ser limitadas ou não suportadas. Para mais informações, consulte Termos Suplementares de Utilização para Microsoft Azure Previews.

Quando usar o acelerador distribuído para armazenamento na cloud

O DACS foi concebido para cargas de trabalho de inferência de IA intensivas em leitura que carregam repetidamente os mesmos dados do modelo a partir do Armazenamento de Blobs do Azure. Considere o DACS quando a sua carga de trabalho tem uma ou mais destas características:

  • Os pods de inferência esperam por ficheiros de modelos grandes antes de poderem servir pedidos.
  • Adicionar nós da GPU provoca downloads repetidos dos dados do modelo.
  • Reinicios de pod, substituição de nós ou atualizações contínuas recuperam repetidamente os mesmos dados do modelo.
  • Múltiplas cargas de inferência reutilizam um conjunto de ficheiros de modelo armazenados no Armazenamento de Blobs do Azure.
  • O cluster AKS tem um pool de nós Linux com discos NVMe locais que pode dedicar a servidores de cache.

Para treino, considere o DACS quando os workers reutilizam partes do conjunto de dados ao longo de épocas ou tarefas. Os benefícios da cache dependem da reutilização de dados, do tamanho do conjunto de trabalho e se as leituras encontram cache fria ou quente.

O DACS suporta clusters com até 100 nós. Não fornece armazenamento persistente para saídas de treino ou checkpoints. Cache KV, cache de imagem de contentor, acesso a ficheiros partilhados de uso geral e origens Blob que não sejam do Azure não fazem parte desta pré-visualização.

Como funciona o acelerador distribuído para armazenamento em nuvem

O DACS adiciona uma camada de cache NVMe local ao cluster à qual as cargas de trabalho acedem através de uma integração de cliente suportada. O cliente pode ler o Armazenamento de Blobs do Azure diretamente em casos de falhas de cache ou quando recorre a um mecanismo de fallback.

Diagrama de arquitetura que mostra um cliente de carga de trabalho AKS a ler os acessos à cache de servidores NVMe distribuídos, a ler o Armazenamento de Blobs em caso de falhas da cache ou contingência, e a preencher a cache. Um controlador gerido separado reconcilia os recursos da cache.

Ler o caminho

  1. Uma aplicação solicita um intervalo modelo-dados através de uma integração DACS suportada.
  2. O cliente descobre os servidores de cache e determina qual detém o bloco solicitado.
  3. Num hit de cache, o cliente lê o chunk do NVMe do servidor de cache que detém o chunk.
  4. Num cache miss, o cliente lê o chunk do Armazenamento de Blobs do Azure e preenche a cache de forma assíncrona. A leitura pode terminar antes de o preenchimento terminar, por isso uma leitura repetida imediata também pode falhar.
  5. Se a cache não estiver disponível, o cliente recorre ao Armazenamento de Blobs do Azure.

Os dados do modelo são divididos em blocos e distribuídos por servidores de cache. Um anel de hash consistente mapeia blocos para servidores sem dependência centralizada do caminho dos dados. Os servidores de cache podem transferir dados via Ethernet ou InfiniBand, dependendo do tamanho da máquina virtual (VM) do Azure selecionado e da topologia do cluster.

Implantação gerida

Ative os DACS através do Azure Container Storage usando o CLI do Azure com o distributedAccelerator valor. Este passo instala a extensão gerida separada distributedaccelerator . A extensão implanta o controlador DACS e o DaemonSet de pré-requisito NVMe em kube-system e regista a definição de recurso personalizada da Cache. Os pré-requisitos descobrem, formatam e montam discos NVMe locais em nós de cache rotulados. Utilize unidades de disco dedicadas à memória cache; não instale um chart de pré-requisitos separado. A extensão não cria automaticamente pods de servidor de cache.

Depois de verificar que os pré-requisitos NVMe geridos estão prontos em cada nó de cache rotulado, crie um recurso Cache para definir o número de servidores, capacidade, limites de recursos e nós elegíveis. O controlador reconcilia os pods do servidor de cache e publica informações de descoberta para os clientes. O controlador gere os recursos; não é um proxy para as leituras de dados da aplicação. Veja o quickstart para instalação e provisionamento de cache.

Note

Os clientes concorrentes podem recuperar independentemente os mesmos dados em falta quando a cache está fria. A população coordenada de cold-cache não está disponível nesta pré-visualização. Use o prefetch para preencher os dados selecionados do modelo antes do início dos pods de inferência.

Principais benefícios

  • Carregamento de modelos quentes mais rápido: Servir frequentemente os chunks de modelo lidos do NVMe local ou peer em vez de os recuperar repetidamente do Armazenamento de Blobs do Azure.
  • Expansão horizontal e recuperação mais rápidas: Deixe que nós novos ou de substituição reutilizem dados do modelo já armazenados em cache no cluster.
  • Redução de leituras repetidas de blobs: Mantenha o modelo ativo a funcionar na cache e use o pré-carregamento antes dos eventos de escala planeados.
  • Cache baseado em intervalos: Armazene em cache apenas os blocos que cobrem os intervalos de bytes solicitados, em vez de materializar todos os ficheiros de modelo na íntegra.
  • Integração flexível de aplicações: Use o BlobFuse2, o cliente nativo de Python, ou o Run:ai Model Streamer para ligar a carga de trabalho à cache.
  • Alternativa segura: Mantenha o Armazenamento de Blobs do Azure como fonte duradoura de verdade quando os dados não estão armazenados em cache ou a cache não está disponível.

Integrações de cliente

A quantidade de alteração na aplicação depende da integração:

Integração Utilizar quando Alteração da candidatura
BlobFuse2 através do driver CSI do Azure Blob A sua aplicação lê dados Blob através dos caminhos do sistema de ficheiros Linux. Configurar um volume BlobFuse2 de apenas leitura; manter o código de leitura de ficheiros existente.
Cliente nativo de Python Pretende operações explícitas da cache síncronas ou assíncronas. Importa e invoca o cliente DACS.
Run:ai Model Streamer A sua aplicação utiliza o Run:ai Model Streamer para carregar os dados do modelo. Configure a integração do DACS para o fluxo de trabalho de carregamento de modelos.

Para a configuração do sistema de ficheiros e os resultados medidos do armazenamento Standard, consulte Use distributed accelerator for cloud storage with BlobFuse2. Para configuração de clientes Python e exemplos, veja Usar acelerador distribuído para armazenamento na cloud com o cliente Python.

O acesso de origin do Direct Hugging Face não é suportado. Coloque os dados do modelo no Armazenamento de Blobs do Azure antes de usar o acelerador distribuído para armazenamento em cloud.

Semântica da cache

Compreenda estes comportamentos antes de implementar o acelerador distribuído para armazenamento na cloud:

  • Durabilidade: Os dados em cache são efémeros e não são replicados para durabilidade. Perder um nó de cache pode remover os chunks armazenados nesse nó; os dados em falta são recuperados novamente do Armazenamento de Blobs do Azure.
  • Fonte fiável: o Armazenamento de Blobs do Azure continua a ser a referência autorizada. Não utilize DACS como a única cópia de ficheiros de modelo ou conjuntos de dados. Prefira caminhos Blob imutáveis e versionados para atualizações de modelos.
  • Expulsão: A cache expulsa dados quando os limiares de capacidade são atingidos. Os dados removidos da cache são recuperados novamente a pedido.
  • Alternativa: Falta de configuração de descoberta ou uma cache indisponível pode fazer com que o cliente leia diretamente do Armazenamento de Blobs do Azure. Verifique os acessos na cache do cliente e se o contador de pedidos bem-sucedidos do servidor aumenta, em vez de tratar uma leitura bem-sucedida do Blob como prova de cache. Consulte Verificar o caminho do pedido DACS.
  • Identidade: As cargas de trabalho utilizam identidades Microsoft Entra ou uma assinatura de acesso partilhado (SAS) para aceder ao Armazenamento de Blobs do Azure. Use a função de menor privilégio exigida pela carga de trabalho.
  • Rede: O tráfego da cache permanece dentro da rede do AKS. O acesso ao endpoint Azure Blob deve ser permitido para falhas de cache e contingência.
  • Limite de confiança: Use DACS dentro de um cluster fidedigno. A cache não isola locatários que não confiam mutuamente entre si.

Projeto open-source

O DACS é um projeto de código aberto desenvolvido em colaboração entre a Azure AI Platform e o Armazenamento do Azure. O projeto disponibiliza a sua implementação de cache para inspeção, experimentação e contribuições da comunidade, de modo a reduzir leituras repetidas de dados sem substituir o armazenamento durável.

O repositório Azure DACS inclui o servidor de cache, um cliente nativo C/C++, adaptadores Python, um wrapper Rust, gráficos e controlador Kubernetes, e exemplos de implementação. Consulte o repositório README para orientações de compatibilidade e configuração open-source, e utilize as suas orientações de contribuição para partilhar problemas reproduzíveis, medições de carga de trabalho e melhorias.

O projeto open-source e a pré-visualização gerida pelo Azure têm diferentes âmbitos de implementação e suporte. Para a experiência gerida do AKS, siga o guia de início rápido do Azure; as opções de implementação a partir de repositórios não são funcionalidades automaticamente suportadas pela versão gerida.

Suporte e limitações para pré-visualizações

A tabela seguinte resume o âmbito inicial de pré-visualização.

Area Escopo da pré-visualização
Orchestrator AKS
Carga de trabalho Principalmente carregamento de modelos de inferência; leituras repetidas de conjuntos de dados para treino
Origem Armazenamento de Blobs do Azure
Cache de multimédia NVMe local em nós de cache Linux
Scale Até 100 nós
Arquitetura da CPU x64 e Arm64
Network Ethernet; InfiniBand em tamanhos de VM suportados
Aquecimento População sob demanda e prefetch
Coordenação de cold-read As leituras a frio simultâneas não são coordenadas
Installation Extensão separada gerida por DACS ativada através do CLI do Azure
Upgrade Aplicam-se as orientações específicas da versão sobre compatibilidade e atualização
Price Sem custos de software DACS; Azure VM, Armazenamento de Blobs e taxas de rede continuam a aplicar-se

Quando usar outra opção de armazenamento

Utilize outra opção de armazenamento do Azure quando a sua carga de trabalho precisar de capacidades fora do âmbito do DACS:

Passos seguintes

  • Última atualização a