Intelligent Computing LINGJUN:Introdução ao Runtime Kit

Fatiamento de granularidade fina de poder de computação e memória da GPU

O Runtime Kit divide o poder de computação e a memória da GPU de recursos xPU, como GPUs, em granularidade fina. Várias cargas de trabalho podem compartilhar uma única placa de GPU, o que melhora a utilização dos recursos.

• Multiplexação por divisão de tempo (TDM): Compartilha o poder de computação da GPU alternando fatias de tempo, com percentuais de computação configuráveis em incrementos de 1%, de 1% a 100%. Vários contêineres podem executar na mesma placa, cada um dentro de sua própria cota de computação, sem interferir uns nos outros.

• Particionamento físico (MIG): Divide uma GPU física em várias instâncias independentes usando o NVIDIA MIG, uma tecnologia de particionamento no nível de hardware. Cada instância possui unidades de computação, memória da GPU e mecanismos de interrupção dedicados para isolamento no nível de hardware. O Runtime Kit aprimora o MIG nativo: as instâncias podem ser criadas dinamicamente e gerenciadas automaticamente, o poder de computação e a memória da GPU podem ser configurados de forma independente, e ele fornece uma interface unificada em diferentes hardwares.

• Dimensões independentes de memória da GPU e computação: A memória da GPU e o poder de computação são configurados de forma independente e combinados em qualquer proporção, sem alocação proporcional. Por exemplo, você pode alocar 50% do poder de computação com apenas 2 GiB de memória da GPU para um contêiner, e 30% do poder de computação com 8 GiB para outro, dependendo dos requisitos da sua carga de trabalho.

• Criação sob demanda: As instâncias de recursos são criadas dinamicamente quando os contêineres de carga de trabalho iniciam e recuperadas automaticamente quando os contêineres são destruídos. Não é necessário provisionamento estático; as instâncias seguem o ciclo de vida do contêiner.

• Restrições: Para o poder de computação, defina um número inteiro no intervalo de 1 a 100, representando uma porcentagem do poder de computação de uma única placa (deixe o campo em branco ou insira 0 para nenhum limite). A memória da GPU é especificada em GiB ou MiB, com uma granularidade mínima de 128 MiB no modo MiB. O TDM e o MIG não podem ser ativados na mesma placa ao mesmo tempo, mas placas diferentes no mesmo nó podem usar modos diferentes. Para PPUs, o TDM é o recomendado.

Isolamento de recursos e gerenciamento de falhas

Cada instância particionada possui um espaço de endereçamento de memória da GPU e uma cota de poder de computação independentes. O isolamento é fornecido em três níveis:

• Isolamento de memória da GPU: Aplica um limite estrito de memória da GPU em cada contêiner. Os programas dentro de um contêiner podem usar apenas a memória da GPU alocada, o que evita que as cargas de trabalho disputem a memória da GPU.

• Isolamento de poder de computação: Controla com precisão o poder de computação disponível para cada contêiner, evitando interferências entre contêineres que compartilham uma placa.

• Isolamento de falhas: Evita que erros de GPU em uma instância particionada, como falhas de memória da GPU ou erros de kernel, se espalhem para outros contêineres na mesma placa, limitando o impacto da falha quando várias cargas de trabalho compartilham uma GPU.

Monitoramento de integridade

O Runtime Kit monitora a integridade e o desempenho da GPU das seguintes formas:

• Coleta de métricas em vários níveis: Coleta métricas em três níveis (placa, contêiner/Pod e processo), abrangendo status, utilização, desempenho e integridade. Ele se integra a plataformas de monitoramento como o Prometheus, e um único componente coleta métricas para todas as instâncias heterogêneas.

• Verificações de integridade não intrusivas: Detecta falhas em instâncias de GPU em tempo real com quase nenhum impacto nas cargas de trabalho em execução. As falhas cobertas incluem placas perdidas, erros ECC incorrigíveis, vazamentos de memória da GPU, falhas de driver, falhas de NVLink e anomalias no modo de computação. Em treinamentos síncronos de grande escala, as placas com defeito são localizadas rapidamente e substituídas por meio do mecanismo de substituição em standby do bare metal Lingjun, o que restaura rapidamente o treinamento e reduz a taxa de falha no agendamento de jobs de GPU.

Agendamento com reconhecimento de topologia

Em cenários com múltiplas placas e múltiplos nós, a distância de comunicação entre os dispositivos afeta diretamente a eficiência do job. O Runtime Kit torna o agendamento ciente da topologia: os componentes coletam e relatam automaticamente a topologia do dispositivo e da rede. Após declarar os recursos da maneira padrão, o agendador seleciona automaticamente a combinação de dispositivos com os caminhos de comunicação mais curtos. Nenhuma configuração extra é necessária.

• Agendamento de topologia de múltiplas placas intra-nó: Para solicitações de múltiplas placas, o agendador prefere a combinação de placas com a interconexão mais próxima. Isso entra em vigor automaticamente quando você solicita 2, 4 ou 8 placas, selecionando placas dentro do mesmo grupo de topologia. Também suporta afinidade conjunta entre GPUs e adaptadores de rede RDMA (Remote Direct Memory Access): os dispositivos são agrupados por proximidade na ordem PCIe Switch → NUMA Node → CPU Socket → Cross-Socket, para que GPUs e adaptadores RDMA dentro do mesmo domínio PCIe sejam alocados como um grupo.

• Agendamento de topologia gang entre nós: Para treinamento distribuído em múltiplos nós, o agendador trata os Pods sob o mesmo JobSet como um grupo de agendamento e atribui nós com base na afinidade de topologia de rede, colocando os membros do grupo em nós com a menor distância de rede. O agendamento dentro do grupo é do tipo "tudo ou nada", o que evita que alguns membros retenham recursos enquanto aguardam outros ficarem prontos.

Para saber como declarar e usar esses recursos, consulte Topology-aware scheduling (PPU).

Inferência online

Os services de inferência são limitados por metas de RT e níveis de tráfego online flutuantes, portanto, a utilização da GPU geralmente é baixa. O Runtime Kit permite implantar várias instâncias de inferência em uma única placa de GPU para aumentar a taxa de transferência. Em um caso real, a divisão de uma única placa em duas instâncias quase dobrou a taxa de transferência sem alteração no consumo de recursos.

Treinamento offline

Para treinamento offline, o Runtime Kit melhora a eficiência e a confiabilidade dos clusters de treinamento de duas maneiras.

Maior utilização por placa: Alguns jobs de treinamento, como ajuste fino em pequena escala e pré-processamento de dados, ocupam apenas parte do poder de computação de uma única placa. O Runtime Kit executa vários jobs de treinamento em uma placa de GPU ao mesmo tempo, usando fatiamento de granularidade fina para colocar os recursos ociosos em uso.

Recuperação rápida de falhas em grandes clusters: As verificações de integridade não intrusivas monitoram o status de cada GPU em tempo real com quase nenhum impacto nas cargas de trabalho, permitindo que as placas com defeito sejam localizadas rapidamente. Combinado com o mecanismo de substituição em standby do bare metal Lingjun, isso permite que os jobs de treinamento sejam retomados com tempo de inatividade mínimo do cluster.

Desenvolvimento e testes

O desenvolvimento de algoritmos, a depuração e os experimentos geralmente precisam de pouco poder de computação e deixam a GPU ociosa na maior parte do tempo, mas cada desenvolvedor precisa de um ambiente isolado e livre de interferências. O Runtime Kit divide uma placa de GPU em várias instâncias para que vários desenvolvedores possam trabalhar ao mesmo tempo: cada instância possui suas próprias cotas de poder de computação e memória da GPU, além de isolamento de falhas, para que os ambientes de desenvolvimento não afetem uns aos outros. Mais desenvolvedores são suportados sem a adição de placas, o que reduz o custo dos ambientes de desenvolvimento e teste.

Arquitetura de entrega em duas camadas

O Runtime Kit é entregue em duas camadas que se conectam por meio de uma interface gRPC unificada:

Sob essa arquitetura, a equipe do Alibaba Cloud Lingjun fornece e atualiza continuamente as capacidades da camada de recursos, enquanto os componentes da camada de contêiner são open source e podem ser adaptados aos seus próprios padrões de plataforma. A interface gRPC unificada é o único limite de integração entre as duas camadas e a base da compatibilidade com versões anteriores.

Componentes open source

Dois caminhos de uso

• Caminho 1: Usar os componentes pré-compilados diretamente. Para começar, execute um script de implantação que instala o conjunto em uma única etapa, e os componentes ficam prontos para uso após a implantação, sem desenvolvimento personalizado. Neste caminho, você precisa rastrear apenas a versão do conjunto. Para implantação e gerenciamento de versões, consulte Deployment and release guide. Para solicitações e uso de recursos, consulte User guide. Se você não precisar de personalização, comece por este caminho: os componentes pré-compilados são lançados e mantidos oficialmente pelo Alibaba Cloud Lingjun e contam com suporte técnico. Se encontrar problemas, reporte-os por meio de canais como o rastreador de problemas do repositório open source.

• Caminho 2: Construir sobre o código open source. Se necessário, modifique políticas de agendamento, modelos de monitoramento e outras partes para corresponder aos seus padrões de plataforma e adaptar as capacidades da camada de contêiner conforme necessário. A única restrição é que as capacidades subjacentes devem, em última análise, ser acessadas por meio da interface gRPC unificada para preservar a compatibilidade da interface. Para acesso ao source e personalização, consulte Customize open source components. Para o protocolo de interface, consulte gRPC API reference.

Para responsabilidade sobre problemas e canais de suporte, consulte Deployment and release guide.