Prática guia · 11 min de leitura

# Servindo o Llama 3.3 70B em um nó.

De uma máquina entregue há cinco minutos a um endpoint compatível com OpenAI respondendo requisições — com as duas flags que silenciosamente reduzem seu throughput pela metade e a que compromete sua máquina.

A resposta curta

- **Memória necessária:** 43 GB em 4 bits, 82 GB em FP8, 164 GB em BF16 — tudo em contexto de 8k
- **Máquina mais simples:** Uma placa de 80 GB. Sem sharding, sem interconexão, sem sincronização
- **Tempo até o primeiro token:** Menos de quinze minutos a partir da entrega, a maior parte baixando os pesos
- **O único erro:** Publicar a porta 8000 em um endereço público. Ela não tem autenticação

## O que você precisa

70 bilhões de parâmetros. Em 4 bits, isso são 35 GB de pesos; o cache KV adiciona 2.5 GB em um contexto de 8k para uma única requisição, e a sobrecarga de execução é de cerca de 15%. Tudo o mais decorre desses três números — o [guia de dimensionamento](https://gpuserver.io/pt/guides/vram-sizing) mostra de onde eles vêm.

**Memória necessária para o Llama 3.3 70B, por precisão e contexto**

| Precisão | Pesos | Total em 8k | Total em 32k | Total em 128k |
|---|---|---|---|---|
| BF16 / FP16 Qualidade de referência | 140 GB | 164 GB | 173 GB | 207 GB |
| FP8 Quase referência, Hopper e Blackwell | 70 GB | 82 GB | 86 GB | 103 GB |
| 4-bit (AWQ, GPTQ) Pesos menores, cache permanece em FP16 | 35 GB | 43 GB | 52 GB | 86 GB |

Observe a linha de 4 bits em 128k: os pesos encolhem para 35 GB, mas o cache não encolhe nada, porque AWQ e GPTQ quantizam apenas os pesos. Esse único fato decide a maior parte da escolha de máquina abaixo.

## Escolhendo o nó

As máquinas mais baratas do nosso catálogo que comportam este modelo em uma *única* placa, que é a configuração que você quer, se puder ter — sem sharding significa sem sincronização e uma coisa a menos para depurar.

**Nós que comportam o Llama 3.3 70B em uma placa**

| Nó | Precisão que cabe | Memória da placa | tok/s estimado | Por mês |
|---|---|---|---|---|
| [NVIDIA RTX A6000](https://gpuserver.io/pt/gpu/rtx-a6000) PCIe 5.0 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $286/mês |
| [2 × NVIDIA RTX A6000](https://gpuserver.io/pt/gpu/rtx-a6000) PCIe 5.0 ×16 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $597/mês |
| [NVIDIA L40S](https://gpuserver.io/pt/gpu/l40s) PCIe 5.0 · 864 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~11 | $714/mês |
| [NVIDIA A100 PCIe](https://gpuserver.io/pt/gpu/a100-80gb) PCIe 5.0 · 1,935 GB/s | 4-bit (AWQ, GPTQ) | 80 GB | ~25 | $1,091/mês |

O throughput é a geração de fluxo único, limitada pela largura de banda de memória, e deliberadamente conservadora. Com o processamento contínuo por lotes, o total *agregado* entre requisições simultâneas é várias vezes maior — esse é o objetivo do vLLM.

## Dez minutos de configuração

Nada aqui é específico da nossa empresa, exceto o endereço. O Docker, o NVIDIA Container Toolkit e uma pilha de drivers funcional já estão na máquina.

Confirme a máquina, depois dê aos pesos um lugar para ficar

```
$ ssh root@203.0.113.42
$ nvidia-smi --query-gpu=name,memory.total --format=csv

# Weights on the fast local NVMe, not the system volume.
$ mkdir -p /scratch/models
$ df -h /scratch

# A gated model needs a token. Skip if yours is open.
$ export HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxx
```

## Iniciando o servidor

Um container. A primeira execução baixa aproximadamente 40 GB de pesos quantizados, o que em uma porta 1 Gbit/s leva alguns minutos; toda reinicialização depois disso leva segundos.

vLLM, placa única, 4 bits

```
$ docker run -d --name vllm --restart unless-stopped \
    --gpus all --ipc=host \
    -v /scratch/models:/root/.cache/huggingface \
    -e HF_TOKEN="$HF_TOKEN" \
    -p 127.0.0.1:8000:8000 \
    vllm/vllm-openai:latest \
    --model casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.92

# Watch it load. "Application startup complete" is the signal.
$ docker logs -f vllm
```

Primeira requisição

```
$ curl -s http://127.0.0.1:8000/v1/models | head

$ curl -s http://127.0.0.1:8000/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{"model":"casperhansen/llama-3.3-70b-instruct-awq",
         "messages":[{"role":"user","content":"In one sentence: what is a KV cache?"}],
         "max_tokens":80}'
```

## As flags que importam

--max-model-len Defina-o para o contexto que você atende O vLLM reserva cache KV para o máximo declarado. Declarar 131072 quando você atende 8192 desperdiça dezesseis vezes a memória de que você precisa, e o sintoma é "concorrência insuficiente", não um erro.

--gpu-memory-utilization 0.90 to 0.95 A fração da placa que o vLLM pode reivindicar. Tudo o que ele não reivindica é desperdiçado; deixar o padrão de 0.90 em uma máquina dedicada custa concorrência real. Não ultrapasse 0.95.

--ipc=host Obrigatório, não opcional Sem isso, a memória compartilhada do container fica limitada a 64 MB. Em uma única placa, isso pode passar despercebido; em um modelo com sharding, o NCCL trava sem nenhum erro útil.

--tensor-parallel-size Somente quando o modelo não cabe Fazer sharding de um modelo que cabe em uma placa o torna *mais lento*. Veja o [guia de interconexão](https://gpuserver.io/pt/guides/nvlink-vs-pcie) — essa é a forma mais comum de fazer um nó caro ter desempenho pior que um barato.

--kv-cache-dtype fp8 Reduz seu cache pela metade Em Hopper e Blackwell. Dobra o contexto ou a concorrência que você consegue manter, com um custo de qualidade que geralmente não é mensurável. O ganho mais fácil desta lista.

--max-num-seqs Limite isso à sua concorrência real Deixar em 256 em uma máquina que atende oito usuários faz o vLLM planejar para 256 e aceitar requisições que não consegue comportar, o que aparece como picos de latência em vez de recusas.

## Sem publicar para o mundo todo

**A API compatível com OpenAI não tem autenticação por padrão.** Vinculado a `0.0.0.0` em um endereço público, é um servidor de inferência aberto, e scanners encontram esses em poucas horas. Note o `-p 127.0.0.1:8000:8000` no comando acima — esse endereço inicial é o que mantém isso fora da internet, e é o caractere mais frequentemente esquecido ao copiar um comando de outro lugar.

Acesse a partir da sua própria máquina por um túnel SSH — nenhuma porta aberta, nenhum certificado para gerenciar, nada para configurar errado:

Do seu notebook

```
$ ssh -N -L 8000:127.0.0.1:8000 root@203.0.113.42

# Now http://127.0.0.1:8000 on your laptop is the server.
```

Se realmente precisar ser público, coloque um proxy reverso na frente com TLS e uma chave de API, e restrinja também os endereços de origem no firewall. A [documentação](https://gpuserver.io/pt/docs#firewall) tem um conjunto mínimo de regras. Cautela redobrada é a postura correta para um endpoint que vai responder a qualquer um que perguntar.

## Aumentando o throughput

Na ordem que vale a pena tentar. As duas primeiras são gratuitas e costumam dar os maiores ganhos.

1. **Reduza `--max-model-len` para o seu contexto real.** Quase sempre o maior ganho isolado, e não custa nada que você estivesse usando.
2. **Aumente `--gpu-memory-utilization` para 0.95.** Esta é uma máquina dedicada; não há mais nada na placa para o qual deixar espaço.
3. **Ative o cache KV em FP8** se a placa for compatível. Dobra o que você consegue manter.
4. **Agrupe em lotes no lado do cliente.** O processamento contínuo por lotes só ajuda se as requisições chegarem de forma simultânea. Requisições uma de cada vez deixam a maior parte da placa ociosa, seja qual for a configuração.
5. **Só então, e apenas então, considere uma placa mais rápida.** A geração é limitada pela largura de banda de memória, então uma H200 a 4.800 GB/s é aproximadamente 2,4× uma H100 PCIe a 2.000 para o mesmo modelo — um ganho real, e o mais caro desta lista.

Meça antes e depois — não adivinhe

```
$ docker exec vllm python -m vllm.entrypoints.openai.api_server --help | head -1
$ docker exec vllm vllm bench serve \
    --model casperhansen/llama-3.3-70b-instruct-awq \
    --num-prompts 200 --request-rate 8

# And watch the card while it runs: if utilisation sits below 90%,
# the bottleneck is your client, not the GPU.
$ nvidia-smi dmon -s um
```

## Mantendo em funcionamento

Três coisas que vale a pena fazer no primeiro dia, porque as três são chatas de descobrir no décimo quarto.

### Política de reinicialização

`--restart unless-stopped` está no comando acima. Depois de uma reinicialização, o container volta e os pesos já estão em `/scratch`, então ele fica pronto em menos de um minuto.

### Observe a placa, não o processo

Uma GPU que caiu do barramento mantém um container com aparência saudável. `nvidia-smi -q -d PERFORMANCE` em uma verificação de integridade detecta isso; uma verificação de porta não.

### Os pesos não têm backup

Eles estão no seu NVMe local e em nenhum outro lugar. Tudo bem — eles podem ser baixados novamente. Seus adaptadores de fine-tuning não podem, então guarde-os em algum lugar fora da máquina.

E quando o prazo termina, os discos são apagados dentro de uma hora, sem período de tolerância. Tudo em `/scratch` vai junto. Isso é proposital — é a mesma garantia que assegura que a máquina que você recebeu não tinha dados de mais ninguém — mas significa que o último dia de um prazo não é o dia para começar a copiar as coisas de lá.

## Verifique este modelo contra cada nó que alugamos.

O configurador informa quais configurações o comportam em uma única placa, quais precisam dividi-lo, e quanto cada uma custa.

[Abrir o configurador](https://gpuserver.io/pt/configure) [Ler os guias](https://gpuserver.io/pt/guides)

## Outros guias

- [Prática · 10 min Fine-tuning de um modelo de 70B em uma placa QLoRA em uma única GPU de 48 GB: o que cabe, quanto custa por mês, e por que o fine-tuning completo exige outra categoria de máquina. Ler o guia](https://gpuserver.io/pt/guides/lora-finetune)
- [Pagamento · 8 min Pagando um servidor em cripto O que realmente acontece entre clicar em pagar e receber o root, qual moeda escolher, e os quatro erros que fazem perder dinheiro no primeiro pagamento. Ler o guia](https://gpuserver.io/pt/guides/pay-in-crypto)
- [Dimensionamento · 9 min Quanta VRAM um modelo realmente precisa A aritmética por trás de “será que cabe”: pesos, cache KV, e os dois pontos em que uma regra prática erra por um fator de três. Ler o guia](https://gpuserver.io/pt/guides/vram-sizing)

---

Fonte: https://gpuserver.io/pt/guides/serve-llama-70b/. Este arquivo é gerado a partir dos mesmos dados que o site; se um número aqui divergir de uma página, a página prevalece e este arquivo está desatualizado — a fonte canônica é https://gpuserver.io/.