Melhores GPUs na Nuvem para Serviço e Implantação de LLM

O que o serviço de LLM realmente exige de uma GPU alugada

Servir um grande modelo de linguagem é uma carga de trabalho fundamentalmente diferente de treiná-lo. O treinamento é limitado pela taxa de transferência e tolerante à latência; o serviço é sensível à latência, limitado pela memória e com picos. Quando você aluga uma GPU para implantar um LLM por trás de uma API, o gargalo raramente é o FLOPS bruto. É quanto do modelo e seu cache KV você pode manter na VRAM, quão rápido essa memória transmite dados e quantas solicitações concorrentes você pode agrupar antes que os tokens por segundo por usuário colapsem.

O cache KV é a parte que a maioria das pessoas subestima. Cada solicitação ativa armazena as chaves e valores de atenção para seu contexto, e essa pegada cresce com o comprimento da sequência e o número de usuários concorrentes. Um modelo que cabe confortavelmente em repouso pode ficar sem memória no momento em que você envia tráfego real com prompts longos. É por isso que implantações de serviço frequentemente precisam de mais espaço na VRAM do que apenas os pesos do modelo sugerem.

Como dimensionar a GPU para o modelo

A primeira pergunta prática é se o modelo cabe em uma GPU ou precisa ser dividido entre várias. Ao ler a comparação acima em relação ao seu modelo, considere estes fatores:

• A capacidade da VRAM determina quais modelos cabem. Um modelo quantizado de 7B a 13B em FP8 ou INT8 pode ser servido a partir de um único acelerador de nível médio, enquanto um modelo de 70B em BF16 geralmente precisa de uma placa de alta memória ou de um nó multi-GPU. Os modelos muito grandes de classe fronteira efetivamente exigem múltiplas GPUs topo de linha conectadas.
• A largura de banda da memória define a velocidade de geração de tokens. A decodificação autorregressiva lê o conjunto completo de pesos para cada token produzido, então a memória classe HBM (como encontrada em placas de data center) gera tokens muito mais rápido do que placas de consumidor baseadas em GDDR no mesmo tamanho de modelo. Para chat interativo, a largura de banda muitas vezes importa mais que o poder de computação.
• As precisões suportadas determinam o quão agressivamente você pode reduzir o modelo. Placas com suporte a tensores FP8 e INT8 permitem servir modelos maiores com menos VRAM e maior taxa de transferência, desde que sua pilha de serviço e o esquema de quantização do modelo sejam compatíveis.
• O interconector importa quando um modelo abrange várias GPUs. O serviço paralelo por tensor troca ativações entre GPUs a cada camada, então links do tipo NVLink dentro de um nó oferecem latência materialmente melhor do que configurações somente PCIe. Para implantações em GPU única, o interconector é irrelevante.

Serviço em GPU única versus multi-GPU

Se seu modelo e seu pico de cache KV cabem em uma GPU, mantenha-o lá. O serviço em GPU única evita completamente a sobrecarga de comunicação entre dispositivos e é mais simples de operar. Só passe para paralelismo por tensor ou serviço multi-nó quando o modelo realmente não couber, porque cada GPU adicionada introduz custo de sincronização e complica o autoscaling. Quando precisar de múltiplas GPUs, prefira instâncias na lista acima que combinem placas de alta memória com um interconector rápido dentro do nó, em vez de juntar placas fracamente acopladas.

Recursos do provedor que importam para serviço, não para treinamento

Além do silício, o modelo operacional do provedor decide se uma implantação é viável. Ao analisar a comparação acima para uma carga de trabalho de serviço em vez de uma execução de treinamento, priorize de forma diferente:

• Tempo de inicialização a frio e configuração tornam-se preocupações de primeira classe. Um endpoint de serviço que escala para zero entre picos de tráfego paga o custo de inicialização a frio a cada escala para cima, então o provisionamento rápido e o cache de imagem afetam diretamente a latência final.
• Granularidade de cobrança muda a economia do tráfego com picos. Cobrança por segundo ou por minuto é adequada para endpoints com autoscaling que ligam e desligam instâncias; cobrança grosseira por hora penaliza esse padrão.
• Confiabilidade sob demanda em vez de spot geralmente é a escolha certa. Instâncias interrompíveis ou spot são excelentes para treinamento e jobs em lote, mas arriscadas para um endpoint voltado ao usuário, onde uma retomada no meio da solicitação derruba o tráfego ao vivo. Spot ainda pode servir bem para inferência em lote não interativa.
• Armazenamento persistente e carregamento rápido do modelo reduzem a dor de reinício. Pesos de vários gigabytes que recarregam do armazenamento a frio a cada reinício adicionam minutos de tempo de inatividade; volumes em cache ou anexados encurtam isso.
• Rede e saída de dados afetam o custo em escala. Inferência de alta taxa pode mover muitos dados para fora; verifique os termos de saída antes de se comprometer com uma implantação de alto tráfego.

Lote versus tempo real, e onde o custo recai

Decida cedo para qual modo você está otimizando. Serviço interativo em tempo real valoriza baixo tempo para o primeiro token e taxas constantes de tokens por usuário, o que favorece memória de alta largura de banda e tamanhos modestos de lote. Inferência em lote ou offline valoriza o throughput total e pode agrupar grandes lotes em hardware mais barato ou interrompível, trocando latência por solicitação por custo muito melhor por token. Muitas equipes executam ambos: um nível responsivo sob demanda para usuários ao vivo e um nível em lote com suporte spot para geração em massa.

Quanto ao custo do aluguel, o serviço abrange todo o espectro. Um modelo pequeno quantizado em uma placa de nível médio é barato e amplamente disponível; modelos de fronteira em nós multi-GPU de alta memória são escassos, mais caros e às vezes com capacidade limitada durante picos de demanda. Como as tarifas mudam constantemente e variam por região e compromisso, trate a comparação ao vivo acima como a fonte da verdade em vez de qualquer valor fixo, e compare instâncias por VRAM, classe de largura de banda, interconector e modelo de cobrança juntos, e não apenas pelo preço de capa.

Perguntas frequentes

Quanto VRAM eu preciso para servir um LLM?

Orce os pesos do modelo na precisão escolhida mais uma folga substancial para o cache KV, que cresce com o comprimento do contexto e usuários concorrentes. Como guia aproximado, modelos pequenos e médios quantizados servem a partir de uma única placa de nível médio, enquanto modelos grandes em precisão maior precisam de uma placa de alta memória ou várias GPUs. Sempre dimensione para a concorrência máxima, não para ocioso.

GPUs spot ou interrompíveis são adequadas para servir LLM?

Para endpoints interativos em tempo real voltados ao usuário, geralmente não, porque uma retomada pode derrubar solicitações ao vivo e forçar reinícios a frio. Instâncias spot são bem adequadas para inferência offline ou em lote, onde interrupções apenas atrasam o throughput em vez de quebrar uma sessão interativa. Muitas equipes mantêm capacidade sob demanda para tráfego ao vivo e usam spot para jobs em massa.

Por que a largura de banda da memória importa mais que o poder de computação para serviço?

A decodificação token a token lê os pesos do modelo da memória para cada token gerado, então a velocidade de geração é limitada por quão rápido a GPU transmite a memória, e não pelo pico de FLOPS. É por isso que placas de data center equipadas com HBM produzem tokens mais rápido que placas de consumidor que mantêm o mesmo modelo, e por que a largura de banda é uma coluna chave para comparar acima.

Devo servir em uma GPU ou dividir entre várias?

Use uma única GPU sempre que o modelo e seu pico de cache KV couberem, pois isso evita comunicação entre dispositivos e simplifica a escala. Passe para paralelismo multi-GPU por tensor somente quando o modelo realmente não couber, e quando fizer isso, escolha instâncias que combinem placas de alta memória com um interconector rápido dentro do nó.