Hospedagem de LLM em uma GPU dedicada dimensionada para o modelo que você quer rodar

Hospedar um LLM significa executar um modelo de linguagem grande em um servidor que você controla, em vez de chamar a API de outra pessoa. Conosco, isso significa alugar um servidor físico inteiro com GPU dedicada própria, acesso root e um sistema operacional novo, e então instalar o modelo e o runtime que quiser. É de nível de produção no sentido simples: a GPU é só sua e as versões são suas para escolher.

Pegue a contagem de parâmetros e multiplique pelos bytes por parâmetro, que é 2 para 16 bits, 1 para 8 bits e 0,5 para 4 bits. Um modelo de 7–8B tem cerca de 16 GB de pesos em 16 bits, 8 GB em 8 bits e 5 GB em 4 bits. Um modelo de 70B tem cerca de 140 GB, 70 GB e 38 GB. Isso são apenas os pesos, então planeje de 25 a 50 por cento a mais por cima para o runtime, as ativações e o cache que guarda a conversa.

Em 4 bits os pesos têm cerca de 38 GB, então com espaço para servir você precisa de uma GPU com 64 GB ou mais: uma GPU, uma máquina. Em 8 bits os pesos têm 70 GB, o que só as nossas maiores GPUs individuais comportam, e apenas para um usuário por vez, então planeje mais de uma GPU se for atender tráfego. Em 16 bits nenhuma GPU individual que instalamos comporta isso e vira uma montagem multi-GPU que orçamos. A tabela acima nomeia as GPUs exatas, e os preços estão em servidores dedicados com GPU.

Porque os pesos não estão sozinhos na memória da GPU. O runtime e seus buffers também ficam lá, e cada token de uma conversa deixa uma entrada no cache chave-valor para não ser recalculado. Esse cache cresce com o comprimento do contexto e de novo com cada requisição atendida ao mesmo tempo, então um modelo que cabe por pouco comporta aproximadamente uma conversa curta. Dimensione a GPU em uma vez e um quarto a uma vez e meia os pesos.

Qualquer um. Você tem root em um sistema operacional limpo, sem nenhum serviço de inferência nosso no caminho. vLLM é a escolha usual para atender tráfego real, llama.cpp para memória apertada ou GPUs mais antigas, e TGI e SGLang rodam sem alterações. Ollama é o caminho mais rápido para um modelo respondendo em uma porta. vLLM e Ollama oferecem ambos um endpoint compatível com OpenAI, então o código cliente existente só precisa de uma nova URL base.

Depende de quanto você usa. Uma API cobra por token e não custa nada ociosa; seu próprio servidor custa o mesmo todo mês e nada a mais quando está ocupado. Tráfego constante, agentes que rodam o dia todo, tarefas em lote e qualquer coisa com regras de privacidade tendem a sair na frente em máquina própria, enquanto um modelo chamado dez vezes por dia não. Os valores mensais para essa conta estão em servidores dedicados com GPU.

Não publicamos um número, porque o modelo, a quantização, a versão do runtime, o tamanho do lote, os comprimentos do prompt e da resposta e o número de usuários simultâneos podem cada um mudá-lo várias vezes. Ler o prompt é limitado pela aritmética e escrever a resposta pela largura de banda da memória, e o processamento em lote distribui o custo entre as requisições até o cache encher. Diga-nos seu modelo, a quantização e os usuários esperados e compartilharemos o que realmente vimos.

Não. Cada servidor físico tem um cliente, e seu sistema operacional vê a GPU completa diretamente. Nenhuma camada de máquina virtual, fatiamento MIG, perfil vGPU ou compartilhamento de tempo fica entre você e ela, então nenhum outro trabalho a compartilha e a carga de mais ninguém pode mudar sua latência.

Então é uma montagem multi-GPU, que orçamos em vez de vender pelo checkout, porque quantas GPUs cabem depende da largura delas e do orçamento de energia do chassi. Duas GPUs dão a soma da memória delas apenas se o runtime dividir o modelo entre as duas, o que todo runtime sério consegue fazer com algum custo em velocidade. Nossa página multi-GPU mostra como isso fica, e o DGX Spark oferece 128 GB de memória compartilhada em uma máquina.

Sim, e planeje muito mais memória do que para servir o mesmo modelo. O treinamento mantém os pesos, os gradientes e o estado do otimizador para cada parâmetro que atualiza, mais as ativações para a passada reversa, então um modelo que serve facilmente em uma GPU pode ser várias vezes grande demais para ajuste fino completo ali. Métodos eficientes em parâmetros como LoRA precisam de apenas uma fração dessa memória extra, e é por isso que a maioria dos ajustes finos em nossas máquinas usa um.

Sim. As GPUs AMD Instinct estão entre as GPUs de maior memória que instalamos e costumam ser o melhor valor por gigabyte, mas seu software precisa suportar ROCm em vez de CUDA. A maioria dos runtimes de inferência atuais suporta, e algumas ferramentas ao redor deles ainda não. Diga-nos seu runtime antes de pedir e verificaremos para você.