Infraestrutura compartilhada ou dedicada para embedding e reranking: como escolher com base na carga de trabalho

Request Profile: a forma importa mais do que o volume

A Cohere fez uma análise sobre a escolha entre shared (consumo por uso) e dedicated (infraestrutura reservada) para embedding e reranking. A principal descoberta: as pessoas costumam comparar apenas o preço por token e o número de requisições por minuto, mas essas métricas quase nada dizem sobre a escolha certa. A lógica é simples — Request Profile → Traffic Pattern → Utilization → Deployment Choice.

O mesmo modelo de embedding pode realizar trabalhos completamente diferentes. Em um site de e-commerce, o embedding é usado de duas formas: indexação do catálogo (centenas de descrições de produtos de uma vez, cerca de 150 palavras, aproximadamente 200 tokens por texto) e processamento de uma consulta de busca (uma única consulta curta, enquanto o usuário observa um spinner de carregamento). O processamento em lote otimiza throughput e custo; a consulta de busca otimiza a responsividade. São requisitos opostos, e uma única infraestrutura não consegue atender bem a ambos.

No reranking, soma-se um parâmetro crítico: o número de candidatos a serem reclassificados. A busca vetorial retorna 50 produtos, e o reranker reavalia cada um em relação à consulta. O modelo compara a consulta com cada candidato de forma independente, então o trabalho escala estritamente com o número de candidatos. Um perfil típico: uma consulta de 20 tokens mais 50 documentos de 200 tokens cada equivale a cerca de 11.000 tokens por operação. Ao passar de 20 para 100 candidatos, o usuário não percebe nada, mas a carga sobe de 4.400 para 22.000 tokens. É uma decisão sobre profundidade de busca, não sobre escalar para mais usuários.

Traffic

Pattern e latência: o que determina a capacidade real

Duas aplicações com o mesmo tráfego de pico podem ter custos de infraestrutura completamente diferentes. O tráfego estável (busca global, fluxo constante ao longo do dia) torna a capacidade dedicated mais econômica: a infraestrutura é bem utilizada, sem tempo ocioso e sem picos não atendidos. O tráfego instável (relatórios financeiros, jobs em lote, picos em janelas específicas) favorece a infraestrutura shared, porque você não paga por capacidade que fica ociosa a maior parte do tempo.

A pergunta-chave não é "qual é o tráfego de pico?", e sim "quão previsível e constante é o uso da capacidade?". Um serviço com 10.000 requisições por segundo durante 5 minutos por dia tem uma economia completamente diferente de um serviço com 100 requisições por segundo de forma contínua.

O throughput máximo da GPU não equivale à capacidade real de produção, porque cargas de trabalho diferentes têm requisitos de latência diferentes. A indexação em lote pode operar no máximo (a conclusão importa mais do que a velocidade). Consultas de busca exigem orçamentos estritos de latência (o atraso afeta a experiência do usuário e a receita). O reranking, ao expandir os candidatos, aumenta documentos/seg mas reduz buscas/seg. A infraestrutura precisa entregar throughput que respeite os requisitos de latência, não apenas atingir um pico de benchmark.

Ponto de equilíbrio e a economia da escolha

A Cohere calculou os pontos de cruzamento econômico usando uma única GPU NVIDIA A10 com preços padrão baseados em consumo (sem descontos, tráfego 24/7):

• Embedding de consulta (requisição única, 8 tokens): equilíbrio em ~dezenas de milhares de req/min • Embedding de catálogo (100 textos × 200 tokens, 20 mil por requisição): equilíbrio em ~20 req/min • Embedding de documento longo (100 textos × 1000 tokens, 100 mil por requisição): equilíbrio em ~4 req/min • Reranking (1 consulta + 50 documentos, 11 mil tokens): equilíbrio em ~29 req/min

Um mesmo modelo, um mesmo preço, e o ponto de equilíbrio muda centenas de vezes dependendo do tamanho da requisição. Um perfil de catálogo a 30 req/min parece modesto, mas já está acima do ponto de equilíbrio de 20 req/min — dedicated já é mais econômico. Mude o tamanho da requisição, o número de candidatos, os requisitos de latência ou o padrão de tráfego, e o ponto se deslocará drasticamente. Por isso não há resposta universal: a escolha entre shared e dedicated depende da carga de trabalho específica, da latência exigida e dos padrões de tráfego — não de métricas de destaque como preço por token ou RPM.