Como auto-hospedar um LLM em um servidor GPU privado

Rodar um modelo de linguagem em hardware que você aluga é a única forma de ter certeza de que seus prompts não são registrados, retidos ou lidos por ninguém além de você. Toda API hospedada — por melhor que seja sua política de privacidade — recebe cada token que você envia, e essa política pode mudar sem que você tenha qualquer participação nisso. A auto-hospedagem desloca essa fronteira: os pesos ficam em um disco que você controla, a inferência acontece em VRAM que você alugou por hora, e nada sai da máquina a menos que você mande para algum lugar. O lado do software já ficou genuinamente fácil. O que ainda pega as pessoas de surpresa é dimensionar a placa antes de contratá-la, e lembrar que uma porta de inferência aberta é uma porta de inferência aberta.

O que a auto-hospedagem realmente oferece — e o que não oferece

Seja preciso quanto ao benefício, porque "IA privada" é um termo vendido de forma vaga. Um modelo na sua própria GPU muda algumas coisas por completo, e outras, nada.

• Seus prompts e as respostas ficam na máquina — sem registro do lado do provedor, sem janela de retenção, sem dataset construído a partir do que você perguntou.
• Sem conta, sem limite de requisições por chave, e sem camada de política entre você e os pesos. O modelo que você implantou é o modelo que você recebe.
• Custo previsível em volume. Passando de alguns milhões de tokens por dia, uma placa alugada sai mais barata que o preço por token, e o valor não muda quando um provedor revisa sua tabela.
• Não transforma um modelo fraco em um modelo forte. Um modelo de pesos abertos no seu próprio hardware continua sendo aquele modelo — a auto-hospedagem compra controle, não capacidade de ponta.
• Não esconde nada da hospedagem. Qualquer pessoa com acesso físico a uma máquina em funcionamento pode, em princípio, ler sua memória, o que é uma questão sobre a hospedagem, não sobre o modelo.

VRAM é o jogo inteiro: dimensionando um modelo para uma placa

Quase toda primeira tentativa fracassada é um erro de aritmética de VRAM. Pesos, KV cache e espaço de trabalho precisam caber na placa ao mesmo tempo, e não existe degradação suave — você recebe um erro de memória insuficiente poucos segundos depois de iniciar o carregamento. A regra prática funciona bem: em precisão de 16-bit, um modelo precisa de cerca de 2 GB de VRAM por bilhão de parâmetros, cerca de 1 GB em 8-bit, e cerca de 0.6 GB em 4-bit. Depois some o KV cache, que cresce com o tamanho do contexto e com as requisições simultâneas, e que é o que realmente pega em produção, e não em testes.

• Um modelo de 7B a 8B: cerca de 16 GB em FP16, ou confortavelmente abaixo de 8 GB em 4-bit. Essa é a classe que cabe em uma RTX A4000 16 GB com folga de sobra.
• Um modelo de 13B a 14B: aproximadamente 28 GB em FP16, cerca de 9 GB em 4-bit. Uma RTX 4090 24 GB roda o modelo quantizado com bastante contexto de sobra.
• Um modelo de 30B a 34B: cerca de 68 GB em FP16, perto de 20 GB em 4-bit — o lar natural de uma RTX 5090 32 GB.
• Um modelo de 70B: cerca de 140 GB em FP16, aproximadamente 40 GB em 4-bit. Isso significa uma A100 ou H100 80 GB, e em precisão total significa mais de uma placa.
• Contexto longo multiplica o KV cache, não os pesos. Uma janela de 128k tokens em um modelo grande pode exigir dezenas de gigabytes sozinha — planeje isso antes de contratar, não depois.

Escolhendo a GPU: da A4000 à H100, e quando a cobrança por hora vale mais que a mensal

Todos os planos da gama de servidores GPU entregam uma placa física inteira com toda a sua VRAM — sem particionamento MIG, sem compartilhamento de tempo — então o número na ficha técnica é o número que você realmente pode preencher. Combine a placa com o modelo que você pretende servir, não com o modelo que você talvez experimente algum dia.

• RTX A4000 16 GB a $89/mo — 8 vCPU e 64 GB de RAM. Suficiente para um assistente quantizado de 7B a 13B, um serviço de embeddings, ou um pipeline de classificação rodando o dia inteiro.
• RTX 4090 24 GB a $189/mo — 16 vCPU, 128 GB e 2 TB NVMe. O melhor custo-benefício por token para modelos de 13B a 34B em 4-bit, e a escolha usual para um endpoint pequeno de produção.
• RTX 5090 32 GB a $279/mo — 24 vCPU e 192 GB. Esses 8 GB extras costumam ser a diferença entre um modelo de 34B que cabe com contexto de verdade e um que não cabe.
• A100 80 GB a $690/mo — 32 vCPU, 256 GB e 4 TB NVMe. Largura de banda HBM2e e memória suficiente para um 70B em 4-bit com uma janela longa, ou para servir com batching pesado.
• H100 80 GB a $1190/mo — 48 vCPU, 384 GB, 8 TB NVMe e uma porta de 10 Gbps. Suporte a FP8 e largura de banda HBM3 fazem dela a única escolha sensata para throughput sério ou para treinamento.

A cobrança é por hora ou mensal, a partir do mesmo saldo pré-pago, e isso muda a conta mais do que as pessoas esperam. Uma avaliação que leva duas tardes em uma H100 custa as horas que rodou, não um mês. Um endpoint de chat que precisa responder às três da manhã pede uma máquina mensal. Se você precisa de várias placas em uma máquina, ou de uma GPU ao lado de bastante armazenamento local, um servidor dedicado é o formato mais adequado — e o caso geral de pagar em cripto está coberto em alugar um servidor GPU com criptomoeda.

Passo a passo: de uma recarga em cripto a um endpoint em funcionamento

1. 01Crie uma conta com um e-mail descartávelUm e-mail e uma senha. Sem nome, telefone ou documento, para que nada do nosso lado vincule o modelo que você roda a você.
2. 02Recarregue seu saldo em criptoAlimente um saldo pré-pago com Bitcoin, Monero ou qualquer uma das 8 moedas disponíveis. Nunca expira nem é congelado.
3. 03Implante uma instância de GPU em uma imagem CUDAEscolha a placa, uma região e uma imagem pronta para CUDA com drivers recentes e PyTorch. A máquina fica pronta em minutos.
4. 04Confirme que a placa está visível antes de baixar qualquer coisaUma única chamada a nvidia-smi mostra a GPU, a versão do driver e a VRAM livre. É uma verificação de dez segundos que evita uma hora de confusão.
5. 05Baixe os pesos para o NVMe localTraga o modelo para o disco da própria instância, em vez de uma unidade de rede. Os pesos chegam a dezenas de gigabytes, e você vai carregá-los mais de uma vez.
6. 06Inicie o servidor vinculado ao localhostSuba o vLLM ou o Ollama em 127.0.0.1, confirme uma completion localmente, e só então decida como vai alcançá-lo de fora.

vLLM, Ollama ou llama.cpp: escolhendo a stack de inferência

Três stacks cobrem quase todos os casos, e a escolha certa depende de quantas requisições o endpoint vai receber, não de qual é tecnicamente mais impressionante.

• Ollama — o caminho mais curto do zero a um endpoint funcionando. Um único comando baixa um modelo quantizado e o serve atrás de uma API compatível com a OpenAI. Ideal para um único usuário, um protótipo, ou um assistente privado.
• vLLM — a resposta para produção. Continuous batching e paged attention permitem que uma única placa sirva muitas requisições simultâneas com um throughput várias vezes maior que o de um loop ingênuo. Essa é a diferença entre um endpoint para você e um endpoint para uma aplicação.
• llama.cpp — o pragmático. Quantizações GGUF de até 4-bit e abaixo, offload para CPU das camadas que não couberem, e o menor piso de memória dos três. É o que faz um modelo grande demais rodar, de qualquer jeito, em uma placa pequena demais.
• TGI, SGLang e TensorRT-LLM são ainda mais rápidos em cenários específicos. Recorra a eles depois de medir um gargalo, não antes.

As três expõem uma rota de chat completions compatível com a OpenAI, então um código de aplicação escrito para uma API comercial geralmente só precisa de uma troca de URL base, e nada mais. Essa compatibilidade é o motivo prático pelo qual a auto-hospedagem deixou de ser um projeto e passou a ser uma escolha de configuração.

Mantendo o endpoint privado: nunca exponha a porta de inferência

Um servidor de inferência sem autenticação é o equivalente moderno de um banco de dados aberto. Scanners encontram IPs novos em questão de horas, e um endpoint exposto significa que outra pessoa está gastando as suas horas de GPU — ou lendo tudo o que a sua aplicação envia por ali.

Se o endpoint realmente precisa ser público — um produto, e não um assistente privado — encerre o TLS em um proxy reverso, exija um token bearer que você rotaciona, e limite a taxa de requisições por chave. Colocar esse proxy em uma VPS pequena e separada, deixando a máquina GPU alcançável só pelo túnel, é o arranjo mais limpo. É o mesmo raciocínio de hospedar um site sem KYC: a máquina voltada para a internet deve guardar o mínimo possível.

Fine-tuning: quando uma tarde em uma placa alugada vale mais que uma fatura mensal

Fine-tuning é o argumento mais forte a favor de alugar em vez de assinar. Uma execução de LoRA ou QLoRA em um modelo de 7B a 13B — alguns milhares de exemplos, um punhado de épocas — termina em horas em uma 4090 e custa exatamente as horas que rodou. O adaptador que sai disso tem algumas centenas de megabytes, então você pode guardar o checkpoint, destruir a instância, e depois carregar esse adaptador em uma placa menor para servir. Fine-tunes completos de um modelo de 70B são outro orçamento e pedem uma A100 ou H100 com espaço para o estado do otimizador, mas ainda assim se medem em dias, não em um contrato.

O fluxo de trabalho que a cobrança por hora permite é simples: implante, treine, copie o adaptador para fora da máquina, destrua-a. Você paga pelo processamento que usou e não fica nenhuma placa ociosa no meio do caminho. Mantenha o dataset no NVMe da instância enquanto trabalha e retire-o de lá quando terminar — nada que você deixa em uma máquina alugada deveria ser a única cópia.

O trade-off honesto de privacidade de uma GPU que você não possui

A auto-hospedagem remove o vazamento maior e mais concreto: um terceiro que recebe cada prompt, guarda por alguma janela de retenção, e decide por conta própria o que fazer com ele. Em uma placa alugada, o modelo e os seus dados vivem dentro de uma máquina que responde só à sua chave. O que alugar não consegue remover é a hospedagem em si. Qualquer pessoa com acesso físico a um servidor em funcionamento pode, em princípio, ler sua memória, e a criptografia de disco completo em uma máquina remota protege você contra um disco roubado, não um em funcionamento.

Então a pergunta útil não é "a hospedagem consegue ver isso" e sim "a hospedagem sabe quem eu sou". A hospedagem sem KYC responde exatamente isso: um e-mail e uma senha, sem verificação, nada em arquivo para vazar ou para uma intimação exigir. Pagar a partir de um saldo em cripto remove o banco. Até onde levar o lado do pagamento é uma escolha de modelo de ameaça — o Bitcoin é pseudônimo, não anônimo, então moedas rastreadas até uma exchange verificada ainda levam a algum lugar, enquanto recarregar em Monero fecha essa brecha no nível do protocolo.

Erros que silenciosamente desperdiçam horas de GPU

• Dimensionar só pelos pesos e esquecer o KV cache, de modo que o modelo carrega sem problemas e depois trava na primeira requisição longa.
• Servir em FP16 em uma placa que rodaria o mesmo modelo em 4-bit com três vezes mais contexto, por causa de uma preocupação com qualidade que ninguém realmente mediu.
• Baixar quarenta gigabytes de pesos para uma unidade de rede, e depois ficar se perguntando por que cada reinício leva vinte minutos.
• Deixar o servidor vinculado a 0.0.0.0 "só para testar do meu notebook", o que em um IP público é encontrado no mesmo dia.
• Pagar mensalidade por uma placa que fica ociosa vinte horas por dia, quando a carga de trabalho sempre foi um job em lote.
• Fazer benchmark com uma requisição de cada vez, concluir que o vLLM não vale a complicação, e não perceber que toda a vantagem dele aparece sob concorrência.

Nenhuma dessas é uma falha exótica. É o que acontece quando a placa é escolhida antes do modelo. Decida o modelo e a quantização primeiro, faça a conta de VRAM com honestidade, mantenha a porta fechada, e um LLM auto-hospedado é uma das coisas menos exigentes que você pode deixar rodando.