Servidor cloud para hosting LLM na Europa: guia de IA RGPD

Servidor cloud para hosting LLM na Europa: guia de IA RGPD

Servidor cloud para hosting LLM na Europa: guia de IA RGPD

O auto-hospedagem de um grande modelo de linguagem oferece controle total sobre quais dados entram no modelo, onde sao processados e quem pode acessa-los. Para empresas europeias, isso não e apenas um argumento de custo - e um requisito de conformidade. Qualquer prompt contendo dados pessoais de residentes da UE deve ser processado sob jurisdição da UE conforme o RGPD.

Por que a jurisdição da UE importa para o hosting LLM

Quando usuários interagem com um LLM - fazendo perguntas, resumindo documentos - esses prompts frequentemente contem nomes, enderecos de e-mail e outros dados pessoais. Envia-los a uma API hospedada nos EUA significa que os dados pessoais saem da jurisdição da UE a cada solicitação.

A auto-hospedagem em um servidor cloud DCXV da UE significa que toda a inferência permanece dentro das fronteiras da UE. Para aplicações de saude, juridicas e financeiras na Europa, a infraestrutura LLM auto-hospedada na UE e o caminho prático para a conformidade com o RGPD.

Escolhendo tamanho do modelo e quantização

  • Modelos 7B (Q4, ~4 GB VRAM) - resumo, classificação, Q&A sobre documentos
  • Modelos 13B (Q4, ~8 GB VRAM) - melhor raciocínio, melhor seguimento de instrucoes
  • Modelos 34B (Q4, ~20 GB VRAM) - qualidade próxima ao GPT-3.5
  • Modelos 70B (Q4, ~40 GB VRAM) - classe GPT-4 para muitas tarefas

Especificações mínimas para hosting LLM

  • Servico CPU (7B Q4) - 16 vCPU, 32 GB RAM, 200 GB NVMe SSD
  • GPU entrada (7B-13B, RTX 4090) - 8 vCPU, 32 GB RAM, 24 GB VRAM, 500 GB NVMe
  • GPU médio (34B Q4, A100 40 GB) - 16 vCPU, 64 GB RAM, 40 GB VRAM, 1 TB NVMe
  • GPU alto (70B Q4, A100 80 GB) - 16 vCPU, 128 GB RAM, 80 GB VRAM, 2 TB NVMe

Configuração recomendada da DCXV

Os servidores cloud da DCXV fornecem servidores EU com GPU para hosting LLM:

  • Servidor GPU, 24 GB VRAM - modelos 7B-13B para copilotos SaaS
  • Servidor GPU, 80 GB VRAM - modelos 70B para APIs de produção
  • Servidor CPU, 32-64 GB RAM - modelos 7B via llama.cpp para processamento em segundo plano

Contate sales@dcxv.com para disponibilidade de GPU.

Comandos de configuração rápida

# Opcao 1: Ollama (mais simples)
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
ollama pull llama3.1:8b

# Expor na rede privada:
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama
# Opcao 2: vLLM para GPU de alto throughput
pip install vllm

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 10.0.0.5 --port 8000 \
  --gpu-memory-utilization 0.90

Qual runtime de serviço escolher

Os comandos acima mostram duas formas de servir os mesmos pesos, e a escolha não é sobre qualidade - todos executam o mesmo modelo. É sobre o que acontece quando a segunda requisição chega antes da primeira terminar:

Runtime Requisições simultâneas Onde funciona melhor Escolha quando
Ollama Em fila, uma por vez CPU ou uma única GPU Ferramentas internas, um usuário, a montagem mais rápida
llama.cpp Em fila, com um lote pequeno CPU, pesos GGUF Nenhuma GPU, ou trabalho em lote durante a noite
vLLM Lotes contínuos Somente GPU Muitos usuários compartilham uma GPU e a vazão importa
TGI Lotes contínuos Somente GPU Você já está na pilha do Hugging Face

A diferença é maior do que parece. Uma GPU que atende uma requisição por vez passa a maior parte do tempo esperando memória, então um runtime que agrupa requisições pode atender várias vezes mais usuários no mesmo cartão sem mudar nada no modelo. É por isso que os números de CPU e os de GPU abaixo não são a mesma medição escalada, mas tipos de trabalho de formatos diferentes.

Desempenho esperado

vLLM no RTX 4090, Llama 3.1 8B FP16:

  • Geração (solicitação única) - 80-120 tokens/s
  • Throughput em lote (8 concorrentes) - 400-700 tokens/s
  • Tempo ate o primeiro token - 150-300 ms

Estas são expectativas para hardware desta classe, não medições do nosso próprio laboratório. Use-as como ponto de partida para o dimensionamento e meça a sua própria carga: os números reais dependem dos seus dados, das suas consultas e do seu tuning muito mais do que do fornecedor.

Conclusão

A auto-hospedagem de LLMs em infraestrutura da UE e o caminho mais confiável para IA em conformidade com o RGPD em produção.

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda
networkingcloudinfrastructure

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda

A Starlink Mini 2 chegou, mas os planos normais ficam atrás de CGNAT. Contámos 990.208 IPv4 para 12+ milhões de clientes e comparamos quatro formas de acesso.

Protestos contra centros de dados na Europa: o que fazer
clouddedicatedinfrastructure

Protestos contra centros de dados na Europa: o que fazer

A 6 de novembro, centenas entraram na obra da Microsoft em Amesterdão. Os números da rede neerlandesa, a latência medida a hubs da UE e o que fazer agora.

EUA rejeitam centros de dados 45 a 1: lições para clientes
clouddedicatedinfrastructure

EUA rejeitam centros de dados 45 a 1: lições para clientes

47 votações sobre centros de dados nos EUA, o lado restritivo venceu em 45. Recontamos os dados brutos e explicamos o que muda para quem aluga servidores.

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24
ipv4pricingcloud

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24

A AWS cobra $0.005 por hora por IPv4 público, $43.80 por ano. O BYOIP não paga isso: quando um /24 comprado ou alugado compensa, com uma verificação de ROA.

Sair do VMware após a Broadcom: guia de migração verificado
clouddedicatedinfrastructure

Sair do VMware após a Broadcom: guia de migração verificado

A Broadcom acabou com licenças perpétuas, cortou parceiros e escondeu o VDDK. Como mover VMs para KVM, Proxmox ou Hyper-V, com datas e uma conversão OVA testada.