Alojamento para aplicações de IA: dimensionamento da CPU, da GPU e do armazenamento

Delimitar primeiro a carga de trabalho de IA

A escolha do hardware começa pela tarefa, e não por uma GPU. No que diz respeito à Inferência Um modelo existente processa os dados de entrada e gera, por exemplo, respostas. O ajuste fino adapta um modelo pré-treinado a dados adicionais ou a uma tarefa específica; por outro lado, o treino completo define os pesos do modelo no âmbito de um ciclo de treino próprio.

Estes objetivos resultam em perfis de carga diferentes: um serviço de chat tem de responder a pedidos, enquanto uma tarefa de treino processa dados durante um período de tempo mais longo e guarda resultados intermédios. Para Alojamento de IA Por isso, deves ter em conta se o que está em destaque é o tempo de resposta, as solicitações processadas, a duração da formação ou, por exemplo, os custos de uma determinada tarefa.

Registe a versão do modelo e o tempo de execução, bem como o número de parâmetros, a arquitetura, a precisão e uma quantização planeada. Anote também os comprimentos esperados de entrada e saída, as consultas simultâneas ou os tamanhos dos lotes, bem como a carga de pico. Desta forma, é possível comparar propostas e testes posteriores com base nas mesmas premissas, em vez de se limitar a comparar apenas os dados nominais do hardware.

No caso de um assistente de chat interno, uma única consulta curta pode ser processada sem problemas, enquanto várias conversas longas podem sobrecarregar a memória. A cache KV mantém estados adicionais durante a geração de texto; as suas necessidades dependem, entre outros fatores, do modelo e do processamento. Por isso, não planeies apenas para o diálogo médio, mas também para contextos longos e utilização em paralelo.

Regista também quais os dados que são tratados, onde podem ser armazenados e quais os níveis de disponibilidade e tempo de recuperação necessários. Estes objetivos operacionais influenciam a escolha entre um único servidor e uma arquitetura mais complexa. As hipóteses continuam a ser um ponto de partida: só uma análise com carga representativa poderá demonstrar se são viáveis.

CPU e RAM em fase de desenvolvimento

Mesmo que um modelo seja executado numa GPU, a CPU colabora ao longo do percurso dos dados. Pode receber pedidos, tokenizar texto, ler ficheiros e preparar os dados de entrada para o processamento do modelo. Se essa preparação for demasiado lenta, a GPU fica à espera de trabalho; um acelerador mais potente não resolve, necessariamente, esse estrangulamento.

O Memória de trabalho Dependendo da aplicação, ocupa espaço para componentes do modelo, dados preparados e caches de ficheiros. A isto acrescenta-se a memória necessária para os processos que carregam e convertem os dados de treino. Por isso, não planeies apenas o modelo em si, mas também o percurso desde o conjunto de dados até ao lote final, bem como reservas suficientes para picos de processamento.

O PyTorch-DataLoader pode utilizar vários workers para o processamento paralelo de dados. No entanto, os workers adicionais também ocupam memória; além disso, a área de memória partilhada pode ficar insuficiente. Por isso, aumente o seu número gradualmente e acompanhe os tempos de espera dos dados e as necessidades de memória, em vez de adotar um valor fixo como recomendação geral.

Um maior número de núcleos de CPU é especialmente útil nos casos em que as tarefas a realizar podem ser executadas em paralelo. Por outro lado, se os acessos ao armazenamento, uma única etapa de processamento ou a própria GPU limitarem o débito, os núcleos adicionais pouco poderão fazer. O comportamento da frequência de clock também pode ser relevante para consultas curtas; o artigo sobre o tema fornece mais informações a este respeito: Regulador da CPU em servidores de alojamento.

Para modelos pequenos ou pedidos pouco frequentes, a inferência por CPU é uma alternativa que vale a pena considerar em relação ao sistema de GPU permanentemente disponível. Compare ambas as variantes utilizando o mesmo modelo, a precisão adequada e o perfil de carga esperado. O que é decisivo é saber se a CPU consegue atingir o tempo de resposta exigido, mesmo em picos de carga, e quais são os custos efetivamente incorridos.

Compreender bem o que são a GPU e a VRAM

No caso de uma inferência totalmente residente na GPU, os pesos do modelo têm de ser armazenados na memória disponível da GPU. O Necessidades de VRAM Mas não fica por aí: o tempo de execução necessita de mais áreas para resultados intermédios e buffers temporários. Por isso, um mapa no qual os pesos cabem matematicamente não constitui, por si só, uma base segura para o funcionamento em produção.

Na geração de texto autorregressiva, acrescenta-se a cache KV. Esta armazena estados de chave e valor já calculados, para que possam ser reutilizados em etapas de geração subsequentes. Contextos longos e pedidos processados em simultâneo podem aumentar esta necessidade adicional de memória; a magnitude desse aumento depende do modelo e do processamento.

A documentação do Transformers 4.48.2 descreve, entre outras coisas, a quantização da cache e a deslocamento como formas de poupar VRAM. No entanto, o benefício depende da implementação e da carga; o processamento adicional ou as transferências de dados podem reduzir a velocidade. Por isso, analise em conjunto o consumo de memória e o tempo de resposta, em vez de considerar automaticamente a poupança de memória como um ganho de desempenho.

Durante o treino, o cálculo de inferência é ainda menos suficiente. Para além dos pesos, há necessidades de memória para gradientes, estados do otimizador e ativações armazenadas. A dimensão destas componentes depende, entre outros fatores, do otimizador, da precisão e do método de treino; sequências mais longas ou lotes maiores podem, em particular, aumentar a memória necessária para as ativações.

Para uma execução totalmente residente na GPU, a VRAM disponível deve ter capacidade para armazenar os pesos e os dados de execução necessários. Os métodos híbridos podem manter partes do processamento ou dos pesos do modelo fora da GPU; a sua adequação e os custos das transferências de dados dependem do tempo de execução. Isto deve ser distinguido da deslocalização da cache KV descrita no Transformers 4.48.2.

Analise em conjunto o modelo, o tempo de execução e o paralelismo previsto e verifique os picos de memória sob uma carga representativa. O facto de haver memória suficiente para o modo de execução escolhido não é, por si só, garantia do tempo de resposta ou da utilização dos recursos pretendidos.

Calcular o espaço de armazenamento do modelo de forma aproximada

Um primeiro cálculo de memória parte do número de parâmetros do modelo e do formato em que os seus pesos são efetivamente armazenados. Este cálculo fornece um limite mínimo para essa quantidade de memória, mas ainda não constitui um dimensionamento completo do servidor GPU. Em particular, não indica quanta memória uma solicitação concreta necessita em tempo de execução.

Exemplo ilustrativo de cálculo, não se trata de uma medição: Sete mil milhões de parâmetros multiplicados por dois bytes resultam em 14 mil milhões de bytes para os pesos. Dividido por 1 073 741 824 bytes por GiB, isso equivale a cerca de 13,0 GiB. O pressuposto é que todos os pesos em consideração sejam, de facto, representados de forma uniforme com dois bytes por parâmetro; outros formatos ou representações adicionais alteram o cálculo.

Não estão incluídos o Cache KV para a geração de texto, buffers temporários e sobrecarga de execução. Especialmente em contextos longos, a cache pode aumentar consideravelmente; o número de pedidos processados simultaneamente também é relevante para a reserva necessária. A documentação do cache do Transformers 4.48.2 descreve ainda métodos que podem poupar memória, mas que, dependendo do método, podem comprometer a velocidade.

No que diz respeito ao treino, o cálculo do peso está longe de ser suficiente. A documentação do Transformers 4.35.0 estima, para uma configuração exemplar de precisão mista com AdamW, 18 bytes por parâmetro, além das ativações. Este valor inclui outros componentes, como gradientes e estados do otimizador; as ativações dependem, entre outros fatores, do comprimento da sequência e do tamanho do lote.

Os 18 bytes não constituem um multiplicador geral para todos os treinos: os otimizadores, a precisão e os métodos de treino podem alterar as necessidades. Por isso, nem este número nem os 13,0 GiB constituem uma recomendação para um determinado tamanho de VRAM. Para a escolha, são determinantes o tempo de execução concreto e os picos de memória esperados sob uma carga representativa.

Comparar cargas de trabalho e pontos de estrangulamento

Os mesmos pesos de modelo podem gerar requisitos muito diferentes, dependendo da tarefa. A tabela apresenta possíveis pontos de verificação, não constituindo uma classificação nem garantindo a existência de gargalos. O recurso que, na realidade, constitui o limitador depende, entre outros fatores, do modelo, do pipeline de dados, da paralelização e da carga.

No caso de um assistente de chat interno, o modelo e a geração são apenas uma parte do planeamento. Defina um comprimento máximo de entrada, um comprimento esperado de saída e o número de utilizadores simultâneos. Em seguida, é possível verificar se o tempo de resposta se mantém aceitável em picos de carga e se os pesos, a cache e o buffer cabem simultaneamente na memória disponível.

Uma pesquisa de documentos com resposta generativa tem um percurso de dados mais longo: os documentos são importados e preparados, são geradas representações de embedding, é efetuada uma pesquisa num índice e os conteúdos relevantes são transmitidos ao modelo de linguagem. A importação e a pesquisa podem ter requisitos de CPU, RAM e armazenamento diferentes dos da geração. Por isso, vale a pena registar separadamente os tempos e as necessidades de memória destas etapas.

No ajuste fino, é possível Acumulação de gradiente permitem um tamanho de lote efetivo maior, embora apenas lotes individuais mais pequenos sejam processados em simultâneo. Os gradientes de várias etapas são acumulados antes de os parâmetros serem atualizados. Isto pode ajudar quando a memória é limitada, mas não garante um aumento da taxa de processamento; as etapas de processamento adicionais podem demorar tempo.

A alimentação de dados também merece uma análise à parte: se o pré-processamento ou o carregamento ficarem aquém do processamento do modelo, uma GPU mais potente não ajuda necessariamente. Por outro lado, um pipeline de dados rápido não pode substituir uma VRAM insuficiente. Por isso, compare alternativas com as mesmas entradas e um perfil de carga compreensível.

Planear o armazenamento e as ligações da GPU

Para o planeamento do armazenamento, vale a pena distinguir entre o tipo de dados e o acesso: os conjuntos de dados de treino são lidos repetidamente e os pesos do modelo são carregados antes da utilização. Ambos necessitam de uma fonte fiável a partir da qual possam ser novamente disponibilizados após uma mudança de servidor. A capacidade, por si só, não é suficiente; o tempo de carregamento e os padrões de acesso também influenciam o funcionamento.

Os dados de trabalho temporários podem ser armazenados num NVMe local, caso seja necessária uma área de trabalho rápida. Verifique junto do fornecedor se esses dados resistem a reinicializações e a mudanças de host. Por outro lado, os pontos de verificação e as cópias de segurança requerem um plano de armazenamento cuidadosamente planeado e um processo de recuperação comprovado; um diretório temporário local não constitui, por si só, uma cópia de segurança independente.

O armazenamento partilhado ou baseado em objetos pode facilitar a distribuição e a conservação de conjuntos de dados, pesos e pontos de verificação. O que é decisivo é saber se a aplicação suporta o tipo de acesso escolhido e se os dados podem ser carregados e recuperados dentro do prazo previsto. Uma área de trabalho local adicional pode ser útil, mas não substitui o armazenamento permanente.

Armazenamento GPUDirect permite, nas condições adequadas de hardware, software e sistema de ficheiros, um caminho de dados mais direto entre o armazenamento e a memória da GPU. Isto é particularmente interessante quando a entrada e a saída se encontram no caminho crítico e a aplicação utiliza o caminho suportado. Se a CPU tiver de descodificar ou pré-processar os dados primeiro, isso pode limitar os benefícios.

No caso de várias GPUs, é necessário distinguir entre replicação e divisão. A replicação disponibiliza cópias do modelo para distribuir os pedidos; não transforma automaticamente áreas separadas de VRAM numa memória partilhada. A documentação relativa ao vLLM 0.20.1 descreve este tipo de disponibilização paralela de dados; daí não decorre qualquer conclusão sobre quaisquer outras versões de tempo de execução.

Por outro lado, o paralelismo tensorial e em pipeline distribuem partes do processamento e geram necessidades de comunicação. Para tal, verifica as ligações entre as GPUs e, no caso de vários servidores, a topologia da rede e o suporte oferecido pelo modelo e pelo ambiente de execução. A documentação do vLLM 0.8.5 aborda estas estratégias para o serviço distribuído; as suas orientações específicas estão ligadas à versão.

Detetar pontos de estrangulamento sob carga

Uma comparação significativa começa com um documento perfil de carga. Registe a versão do modelo, a precisão, a variante concreta de hardware e a versão do ambiente de execução. Indique os comprimentos típicos e máximos do contexto, os comprimentos das saídas, bem como o número de pedidos simultâneos. Desta forma, será possível verificar posteriormente uma alteração na infraestrutura nas mesmas condições.

Na inferência, meça o tempo até ao primeiro token e a velocidade de geração. Registe também os erros e os tempos de resposta sob carga normal e durante os picos previstos. Uma taxa de processamento média elevada não é suficiente se as consultas individuais demorarem demasiado tempo ou falharem devido a contextos longos ou a um elevado nível de paralelismo.

Para o treino e o ajuste fino, os passos ou exemplos processados por unidade de tempo são um bom ponto de partida. Além disso, observa quanto tempo o pipeline de dados demora a receber o lote seguinte. Os PyTorch-DataLoaders podem preparar dados com vários workers; as suas necessidades de memória e a carga sobre a memória partilhada também devem ser tidas em conta na avaliação.

Registe os picos de utilização da memória da GPU e da RAM, bem como a utilização do armazenamento e os tempos de espera. Num sistema NVIDIA existente, o comando de leitura mostra nvidia-smi dependendo do dispositivo e do controlador, entre outros, o estado da GPU e a utilização da memória. Não altera nenhuma configuração produtiva, mas não substitui nenhuma medição da aplicação.

Uma baixa utilização da GPU, por si só, não indica um problema nem na CPU nem no armazenamento. Compare-a ao longo do tempo com os tempos de espera dos dados, o histórico de pedidos e a ocupação da memória e, sempre que possível, altere apenas um parâmetro relevante por comparação. Documente também os limites do teste, por exemplo, se ainda faltarem picos de carga raros ou entradas particularmente longas.

Operar a infraestrutura de IA de forma fiável

O planeamento operacional inclui uma combinação verificável de variante de GPU, controlador, framework e tempo de execução do modelo. Antes de efetuar atualizações, verifica quais as versões que são compatíveis entre si e como podes voltar à combinação anterior em caso de problemas. No caso de percursos de dados específicos, como o GPUDirect Storage, o hardware, o software e o sistema de ficheiros têm de ser adequados à utilização prevista.

Defina quem tem permissão para ler ou alterar modelos, dados de treino, registos e interfaces de gestão. No caso de dados sensíveis, é também necessário verificar se o local de armazenamento, a transmissão de dados e o período de conservação estão em conformidade com os requisitos de proteção de dados. Verifique estes aspetos para todos os serviços envolvidos, e não apenas para o servidor onde o modelo está a ser executado.

A Ponto de controlo regista um estado de treino para uma eventual retomada posterior. Planeia quais os estados de que o teu software de treino necessita para esse efeito, com que frequência devem ser guardados e durante quanto tempo devem ser mantidos. Os pesos do modelo para entrega e os pontos de verificação para a continuação têm finalidades diferentes e devem ser identificados em conformidade.

O armazenamento local de trabalho não é automaticamente permanente e não substitui uma cópia de segurança independente. Informe-se junto do fornecedor sobre o que acontece aos dados locais em caso de reinício, substituição do servidor ou término do contrato. Guarde os dados necessários independentemente do ambiente de trabalho e teste a recuperação na prática, incluindo o tempo necessário até que os dados estejam novamente operacionais.

No caso de tarefas distribuídas, a monitorização abrange, além das GPUs individuais, também os nós, as ligações de rede e o progresso de toda a aplicação. Planeie a partir de que ponto guardado uma tarefa deve reiniciar após uma falha e quais os recursos que têm de estar disponíveis para o efeito. Se partes do modelo estiverem distribuídas por vários servidores, as respetivas ligações também influenciam o funcionamento; as indicações da documentação do vLLM 0.8.5 estão, neste contexto, ligadas à versão.

Selecionar o modelo de alojamento e o servidor GPU

No caso de trabalhos pontuais, pode ser disponibilizado um Servidor com GPU pode fazer sentido: pagas de acordo com as condições específicas da oferta pela disponibilização necessária, em vez de manter capacidade disponível de forma permanente. Compara também os prazos de implementação, a disponibilidade na data pretendida, bem como os custos relativos aos dados armazenados e à transmissão de dados.

Em caso de carga uniforme, compensa optar por infraestrutura reservada a longo prazo. Esta pode oferecer maior controlo sobre o tempo de execução e o percurso dos dados, mas exige um planeamento próprio para atualizações, monitorização e recuperação. Um serviço de inferência gerido assume parte desta operação; por outro lado, verifica quais os modelos, configurações e percursos de dados que estão efetivamente disponíveis nesse serviço.

Para a seleção da infraestrutura de aprendizagem automática, são necessárias informações sobre a variante específica da GPU no que diz respeito à: capacidade de VRAM, largura de banda de memória, formatos de cálculo suportados e formato físico. Não aplique valores máximos de uma família de produtos a todas as variantes sem os ter verificado. Compare os dados de desempenho apenas com as respetivas condições de teste e com o modelo previsto, em vez de tomar decisões baseadas apenas num valor máximo teórico.

O tipo de escalabilidade também faz parte da oferta: as instâncias replicadas podem distribuir os pedidos, enquanto a divisão do modelo requer suporte por parte do tempo de execução e da topologia da ligação. A documentação do vLLM aborda o paralelismo de dados na versão 0.20.1 e o serviço distribuído na versão 0.8.5; estas afirmações não devem ser aplicadas a outras versões sem verificação prévia.

Defina primeiro o modelo e o perfil de carga, depois faça uma estimativa da capacidade de armazenamento e do caminho dos dados e solicite propostas adequadas. Em seguida, verifique o tempo de resposta, os erros e os requisitos de recursos utilizando pedidos representativos ou dados de treino. Encontrará mais aspetos para a avaliação em Hospedagem em GPU para aplicações web. Sem esta comparação de cargas de trabalho, não é possível estabelecer uma recomendação geral relativamente à GPU.