Michael JohnsonDois serviços podem enviar o mesmo número de solicitações a um modelo e, ainda assim, gerar cargas muito diferentes. No guia da Cohere sobre Embed e Rerank, publicado em 9 de outubro, a empresa propõe escolher entre processamento compartilhado e dedicado conforme o formato das solicitações, o padrão da carga e os requisitos de latência. Trata-se de uma análise prática de infraestrutura, não do anúncio de uma nova tarifa ou produto.
Para equipes que desenvolvem mecanismos de busca e RAG, essa conclusão importa no planejamento da indexação e das consultas dos usuários: o número de chamadas, por si só, descreve mal o volume de computação. Um lote de documentos para gerar embeddings pode consumir mais recursos do que muitas consultas de busca curtas.
Por que as solicitações por minuto podem enganar
Os embeddings convertem textos em representações numéricas que o mecanismo de busca usa para correspondência semântica. Na indexação inicial de um catálogo, o aplicativo pode enviar grandes lotes de descrições; na busca cotidiana, o modelo recebe uma consulta curta. Essas tarefas têm requisitos diferentes: o processamento em lote costuma ser avaliado pela taxa de transferência e pelo custo, enquanto a busca é avaliada pelo tempo de resposta ao usuário.
No Rerank, há outro parâmetro importante: quantos candidatos o sistema envia ao modelo para reordenar. No exemplo da Cohere, uma consulta curta é comparada com 50 documentos; a empresa estima que esse processamento envolva cerca de 11 mil tokens. Aumentar o número de candidatos amplia o volume de trabalho, mesmo que a frequência das buscas dos usuários permaneça a mesma.
O que os cálculos da Cohere mostram
O artigo apresenta pontos de equilíbrio econômico aproximados para migrar do pagamento por consumo para a capacidade dedicada: cerca de 20 solicitações por minuto para indexar em lote 100 textos com aproximadamente 200 tokens cada; cerca de quatro para documentos mais longos; e cerca de 29 para o cenário de Rerank descrito. Para embeddings de consultas de busca curtas, os autores estimam um limiar de dezenas de milhares de solicitações por minuto.
Esses números foram calculados com base em premissas específicas: uma GPU NVIDIA A10 dedicada, operação em plena utilização 24 horas por dia, os tamanhos de solicitação indicados e as tarifas publicadas. A Cohere explica ainda que os gráficos e os limiares mudam conforme a duração da operação, a configuração do hardware, os descontos e o volume de documentos. É melhor encará-los como uma ilustração do método de cálculo, não como parâmetros universais.
A lógica da escolha, porém, pode ser aplicada para além desses exemplos específicos. Uma carga contínua e previsível pode aproveitar melhor a capacidade reservada; picos curtos, separados por longos períodos de inatividade, costumam ser mais adequados ao pagamento pelo consumo efetivo. Na busca interativa, também é preciso verificar a latência sob a carga esperada: a taxa de transferência máxima do hardware não garante o tempo de resposta desejado durante a operação.
Como aplicar a análise à sua busca
Antes de comparar opções, meça alguns aspectos do tráfego real: tokens e documentos por solicitação, tamanho dos lotes de indexação, candidatos enviados para reordenação, duração dos picos e latência desejada. Em seguida, calcule o custo considerando o padrão de uso efetivo, não apenas o número médio de solicitações. Para ter uma visão completa, confira as tarifas e condições atuais de implantação na página de preços da Cohere: modelos dedicados e processamento por consumo são cobrados de maneiras diferentes.
Em uma busca híbrida, faz sentido avaliar cada etapa separadamente: a reindexação do catálogo em segundo plano, as consultas curtas dos usuários e a reordenação dos candidatos. Esse cálculo ajuda a determinar se uma infraestrutura única é justificável ou se vale mais a pena executar diferentes partes do pipeline com modelos de implantação distintos. A conclusão prática da publicação da Cohere é simples: primeiro, meça o trabalho de cada solicitação; só então escolha como pagar e alocar recursos.