Cohere: rerank de 100 candidatos em vez de 20 eleva a carga de 4,4 mil para 22 mil tokens

A Cohere publicou uma análise prática sobre como escolher entre inferência shared, com pagamento por consumo, e inferência dedicated, com capacidade reservada, para os modelos Embed e Rerank. O autor do texto, o solutions architect Payal Singh, parte de uma ideia simples: comparar tabelas de preços não faz sentido enquanto não estiver claro como o aplicativo usa o modelo. Uma única chamada de embeddings com 100 descrições de produtos de ~200 tokens cada consome cerca de 20 mil tokens. Uma consulta de busca de um cliente tem poucas palavras. Para a cobrança, as duas são "requisições"; para o hardware, são cargas completamente diferentes.

Um modelo, dois perfis

A Cohere usa o exemplo de uma loja virtual. Primeiro é preciso indexar o catálogo: cada descrição passa pelo modelo e o vetor é armazenado. Na primeira vez, o trabalho é grande; depois, vem um fluxo de lotes pequenos conforme o sortimento é atualizado. O aplicativo envia os produtos em blocos, com cerca de 100 descrições por chamada, e nenhum usuário fica esperando. O que importa é concluir o trabalho, não concluí-lo rápido, então a otimização recai sobre o throughput e o custo por unidade de trabalho.

A consulta de busca "waterproof trail running shoes" funciona ao contrário. Ela é curta, e a pessoa está olhando para o indicador de carregamento. Aqui o que conta é a capacidade de resposta, e o preço é um price-performance pior. Na prática, pede-se a um mesmo modelo que faça dois trabalhos distintos. Uma infraestrutura ajustada para lotes grandes não necessariamente entrega o tempo de resposta desejado diante de milhares de requisições pequenas e sensíveis à latência.

Rerank: a profundidade da lista funciona como multiplicador

O reranker tem uma geometria própria. A busca vetorial devolve, digamos, 50 candidatos, e o modelo avalia cada par "consulta — documento" de forma independente. A consulta é processada de novo para cada candidato, por isso o trabalho cresce em proporção direta ao número deles.

Uma chamada típica, segundo estimativa da Cohere: consulta de cerca de 20 tokens mais 50 produtos de ~200 tokens. O resultado é da ordem de 11 mil tokens por busca. Se a profundidade da lista aumenta, o quadro muda sem que apareça um único usuário novo:

• 20 candidatos: cerca de 4 400 tokens por busca;
• 50 candidatos: cerca de 11 000 tokens;
• 100 candidatos: cerca de 22 000 tokens.

O número de buscas e a experiência do usuário continuam os mesmos, mas é preciso cinco vezes mais computação. Por isso, a Cohere sugere tratar a profundidade do retrieval como uma decisão de infraestrutura, e não apenas como um ajuste de qualidade.

Conclusões dos key takeaways

Dos pontos principais do material, emerge a seguinte lógica:

• o request shape pesa mais que o volume de requisições: algumas chamadas grandes de Embed podem consumir mais compute que milhares de consultas de busca curtas, e por isso o RPM como única métrica para planejar capacidade não é confiável;
• a inferência dedicated costuma ser mais econômica com carga estável e previsível, enquanto o modelo consumption-based se adapta melhor a tráfego variável ou com picos;
• o ponto de equilíbrio depende do tamanho da requisição, do volume de tokens e do número de candidatos no rerank, e não apenas do preço da infraestrutura;
• o throughput máximo não equivale à capacidade realmente disponível em produção: é preciso cumprir os requisitos de latency e, ao mesmo tempo, manter o custo em patamar razoável.

Como abordar a escolha na prática

A ordem de passos é a que a própria Cohere propõe: perfil da requisição, depois padrão de tráfego, depois utilização e só então a escolha do tipo de implantação. Comece medindo os tamanhos reais das requisições: quantos documentos há em um lote de indexação, quantos tokens em média, quantos candidatos seguem para o reranker. Em seguida, separe a carga em segundo plano (indexação, recálculos em lote) e interativa (busca, em que o usuário espera). A primeira muitas vezes pode ficar no modo shared, se for irregular. A segunda, com fluxo estável, é candidata à capacidade dedicada.

Recalcule o custo separadamente quando a profundidade do reranking mudar: passar de 20 para 100 candidatos pode deslocar o ponto de equilíbrio. E teste a capacidade sob a latência-alvo, não pelo throughput máximo de especificação. Nesta parte, o trecho disponível do material é interrompido na seção sobre padrões de tráfego, e por isso a Cohere não apresenta aqui limites concretos para alternar entre os modos.