Por que a localização dos dados importa mais que a velocidade da GPU em RAG

Onde seus dados moram pode valer mais que a sua GPU

Quando uma equipe tenta acelerar um pipeline de RAG (retrieval-augmented generation) em produção, a decisão mais comum é comprar uma GPU mais rápida. Mas há um fator que costuma pesar mais que o chip: a distância física entre a GPU e o banco de dados que guarda os vetores, documentos e metadados. Se o modelo roda em um datacenter e o banco está em outra região — ou em outro provedor —, buscar embeddings à distância pode anular boa parte do ganho de qualquer upgrade de hardware.

Este é o argumento central de um artigo conceitual da DigitalOcean, que usa como exemplo um app RAG rodando em GPU Droplets com embeddings no Managed PostgreSQL com pgvector. A questão-chave não é qual GPU é mais rápida, mas se GPU, servidor de aplicação e banco estão próximos o bastante para não perderem tempo com latência de rede.

Uma GPU mais rápida não encurta uma viagem de rede

Produzir uma única resposta num pipeline RAG envolve várias etapas: transformar a pergunta em embedding, buscar no índice vetorial, filtrar por metadados, puxar os documentos, rerankear candidatos, montar o prompt, enviar tudo pela rede e só então gerar a resposta. Uma GPU melhor acelera apenas as etapas que rodam nela. As outras — busca, lookups de metadados, transferência de rede — continuam iguais.

Uma única requisição a um banco remoto envolve resolução de DNS, abertura de conexão TCP, negociação TLS, a viagem pela rede, roteamento entre provedores, fila no banco, execução da consulta e o envio dos resultados de volta. Reutilizar conexões elimina parte do custo repetido, mas não encurta a distância.

Em fluxos agênticos, o problema se multiplica. Um pipeline agêntico de RAG pode repetir o ciclo de busca, análise e nova busca várias vezes antes de responder. Cada chamada remota sequencial paga a penalidade de rede — e como cada uma precisa terminar antes da próxima começar, o custo total é N × k, onde k é o número de chamadas. A GPU, por outro lado, só é acelerada uma vez.

Latência vem da física, não do software

Um pedido não viaja mais rápido que o sinal que o carrega. A luz se move mais devagar em fibra óptica do que no ar, e na prática os dados não seguem em linha reta: passam por switches, roteadores, firewalls, gateways e a fronteira entre provedores. Isso impõe um piso de atraso que nenhum ajuste de software contorna.

Vale distinguir largura de banda de latência. Banda é quanto dado se move por segundo; latência é quanto tempo leva para o dado chegar. Pedidos a bancos vetoriais dependem mais de latência: um embedding de consulta tem poucos kilobytes, e o que atrasa não é o volume, mas o tempo de ida e volta, a fila no banco e a própria busca.

A latência de cauda agrava o cenário. A mediana pode parecer boa enquanto os 5% ou 1% mais lentos disparam, por congestão, mudança de rota ou backlog no banco. Como o modelo não começa a gerar até o dado chegar, o tempo até o primeiro trecho útil é uma métrica mais honesta de velocidade real do que o desempenho bruto da GPU.

Como medir de verdade

O teste correto muda a localização do banco mantendo todo o resto fixo: mesmo tipo de GPU, mesma versão do PostgreSQL, mesmos dados, mesmos embeddings, mesmo índice (HNSW ou IVFFlat), mesmas consultas, mesmas conexões. Compare pelo menos três cenários: mesmo datacenter, região diferente e uma plataforma concorrente. Rode os testes em ordem aleatória e reporte conexões frias e quentes separadamente.

Um sinal revelador: se o tempo que o app mede para recuperação é muito maior do que o banco reporta para si mesmo, a diferença é o atraso externo — abertura de conexão, ida e volta na rede, empacotamento de resultados. Afinar o índice HNSW pode tirar alguns dos 6 ms que o banco gasta, mas não recupera os outros 69 ms que ficam no caminho.

Quando a localização importa (e quando não)

Nem todo app precisa dessa atenção. Apps interativos que dependem de recuperação, serviços com meta rígida de velocidade e sistemas agênticos com chamadas repetidas devem priorizar a localização dos dados. Já ferramentas internas de baixo tráfego, processamento em lote noturno e cenários com uma única recuperação seguida de geração longa podem focar em throughput e custo — a penalidade de rede não se acumula quando só acontece uma vez.

A recomendação prática: coloque GPU e banco na mesma região, use conexões persistentes e rede privada, e meça o tempo de ponta a ponta a partir da máquina que roda o modelo. Para a maioria dos sistemas RAG em produção, o caminho mais rápido para uma resposta mais rápida não é uma GPU mais veloz — é uma distância menor até os seus dados.