
As GPUs são a manchete, mas muito trabalho real acontece antes e depois da etapa da GPU. Downloads, pré-processamento, empacotamento, orquestração, colagem de API e “fazer com que funcione de forma confiável” geralmente são tarefas de CPU. Pagar os preços da GPU enquanto trabalha com a CPU é uma das maneiras mais fáceis de queimar créditos sem nenhum benefício.
Ligado Computação com Hivenet, você pode iniciar uma máquina virtual (VM) sem uma GPU. Você obtém a mesma forma de “servidor Linux real”, apenas alimentado por vCPUs em vez de GPUs.
Se você ainda está decidindo se quer mesmo uma VM, comece aqui: [[Interlink: VM ou contêiner: como escolher em 60 segundos]]. Se sua pergunta for “Preciso de uma GPU VM?” este ajuda: Máquina virtual GPU: o que é e quem realmente precisa de uma.
Uma VM vCPU é uma máquina Linux completa sem GPUs conectadas. Você escolhe um sistema operacional, se conecta por SSH, instala pacotes com sudo, executa serviços em segundo plano e mantém um ambiente de sistema que se comporta como um servidor normal.
Essa parte do “controle total do sistema operacional” é a razão para usar uma VM, mesmo para cargas de trabalho somente de CPU. Se você não precisa de controle do sistema operacional, uma instância de contêiner geralmente é a escolha mais simples.
Use uma VM vCPU quando precisar de um ambiente em formato de servidor, mas sua carga de trabalho não se beneficia da aceleração da GPU.
Exemplos comuns:
Preparação de dados e ETL que alimentam o trabalho da GPU posteriormente.
O download de conjuntos de dados, a conversão de formatos, a extração de arquivos, a limpeza de textos, o redimensionamento de imagens, a fragmentação de documentos e a criação de entradas de treinamento/inferência geralmente estão vinculados à CPU.
Executando “serviços de suporte” para sua pilha de IA.
Isso inclui APIs leves, filas de tarefas, agendadores, proxies reversos e ferramentas internas que coordenam as tarefas da GPU. Se a GPU estiver ociosa durante a execução do serviço, mantenha-o na vCPU.
Inferência de CPU para cargas de trabalho pequenas ou sem latência crítica.
Alguns modelos e tarefas funcionam bem na CPU, especialmente quando a taxa de transferência e a latência não são rígidas. Se o desempenho for aceitável na vCPU, não compre uma GPU por hábito. Se não for aceitável, troque. Simples
Construções, empacotamento e tarefas semelhantes à CI.
Compilar dependências, criar rodas, empacotar artefatos, criar imagens de contêineres, executar testes ou preparar pacotes implantáveis geralmente é um trabalho de CPU. Se o Docker fizer parte do fluxo de trabalho, uma VM geralmente é mais fácil: Execute o Docker da maneira normal em uma VM de computação.
Uma máquina de “bancada de trabalho” de longa duração.
Se você quer um ambiente consistente ao qual pode continuar recorrendo (cadeias de ferramentas, scripts, serviços), mas não precisa de uma GPU conectada o tempo todo, as VMs vCPU são uma base prática.
Se tudo isso soar como “Quero um servidor Linux que eu controle”, uma VM vCPU é uma boa opção.
Use uma instância de contêiner (mesmo em vCPU) quando sua meta for “executar essa carga de trabalho” e você não quiser gerenciar o sistema operacional.
Os contêineres geralmente são a escolha certa para:
Se seu contêiner continuar bloqueando você, esse é o sinal para migrar para uma VM: Quando vale a pena mudar de uma instância de contêiner para uma VM.
Use uma GPU quando a carga de trabalho realmente se beneficiar dela, especialmente para cargas de trabalho modernas de computação acelerada por GPU.
Isso normalmente inclui:
Se você não tiver certeza se a GPU vale a pena, essa é a abordagem simples: execute primeiro um pequeno teste na vCPU. Se o desempenho claramente não for bom o suficiente, mude para a GPU com confiança.
Divida seu funil.
Coloque as etapas mais pesadas da CPU na vCPU (preparação, orquestração, downloads, empacotamento). Ative as GPUs somente para as etapas mais exigentes da GPU (treinamento, inferência pesada), incluindo Cargas de trabalho de IA comuns para pequenas e médias empresas. Desligue a instância da GPU assim que terminar.
Essa é a mesma lógica do nosso artigo de preços, apenas aplicado de forma prática: Preços de VMs com GPU em nuvem: o que você realmente está pagando.
Se você precisa do Docker para sua pilha de CPU, não esconda as instruções em uma postagem de blog. Use o tutorial de documentos: Instalar o Docker em uma VM de computação. Para fornecedores que pensam no lado da oferta desse modelo, nossa entrevista com O primeiro fornecedor certificado de GPU da Hivenet mostra como a capacidade da GPU pode mudar da mineração para a IA.
CPU versus GPU não muda a forma como você acessa a máquina nem expõe os serviços.
Se você estiver testando uma interface de usuário de forma privada, o encaminhamento de portas SSH geralmente é o caminho mais limpo. Se você precisar de um link público, use HTTPS. Se você precisar de conexões diretas com o cliente, use TCP ou UDP.
Parar/iniciar é útil, mas não trate uma instância interrompida como armazenamento de longo prazo.
Se você não tem uma preferência, o Ubuntu geralmente é a opção menos surpreendente. Se você se preocupa mais com estabilidade ou ferramentas mais novas, o Debian e o Fedora podem fazer sentido.
Se você está pagando por GPUs enquanto trabalha com a CPU, uma VM vCPU é a solução mais fácil. Inicie uma pequena VM vCPU, execute as etapas da CPU lá e abra as GPUs somente quando você realmente precisar delas.