Cohere: hacer rerank de 100 candidatos en lugar de 20 eleva la carga de 4,4 a 22 mil tokens

Cohere ha publicado un análisis práctico sobre cómo elegir entre la inferencia shared con pago por consumo y la inferencia dedicated con capacidad reservada para los modelos Embed y Rerank. El autor, el solutions architect Payal Singh, parte de una idea sencilla: comparar tarifas no tiene sentido hasta que se entiende cómo usa la aplicación el modelo. Una sola llamada de embeddings con 100 descripciones de producto de ~200 tokens supone unos 20 mil tokens. Una consulta de búsqueda de un comprador ocupa unas pocas palabras. Para la facturación, ambas son una «solicitud»; para el hardware, son cargas completamente distintas.

Un modelo, dos perfiles

Cohere recurre al ejemplo de una tienda online. Primero hay que indexar el catálogo: cada descripción pasa por el modelo y se guarda su vector. La primera vez es un trabajo enorme; después llega un flujo de lotes pequeños a medida que se actualiza el surtido. La aplicación envía los productos en grupos, unas 100 descripciones por llamada, y ningún usuario espera el resultado. Lo importante es completar la tarea, no completarla rápido, así que se optimizan el throughput y el coste por unidad de trabajo.

Una consulta como «waterproof trail running shoes» funciona al revés. Es corta, y la persona está mirando el indicador de carga. Aquí importa la capacidad de respuesta, y se paga con un peor price-performance. En esencia, se pide a un mismo modelo que haga dos trabajos distintos. Una infraestructura ajustada para lotes grandes no necesariamente ofrecerá el tiempo de respuesta necesario con miles de solicitudes pequeñas y sensibles a la latencia.

Rerank: la profundidad de la lista actúa como multiplicador

El reranker tiene su propia geometría. La búsqueda vectorial devuelve, por ejemplo, 50 candidatos, y el modelo evalúa cada par «consulta — documento» de forma independiente. La consulta se procesa de nuevo para cada candidato, por lo que el trabajo crece en proporción directa a su número.

Una llamada típica, según la estimación de Cohere: una consulta de unos 20 tokens más 50 productos de ~200 tokens. El resultado es del orden de 11 mil tokens por búsqueda. Si se aumenta la profundidad de la lista, el panorama cambia sin un solo usuario nuevo:

• 20 candidatos: unos 4 400 tokens por búsqueda;
• 50 candidatos: unos 11 000 tokens;
• 100 candidatos: unos 22 000 tokens.

El número de búsquedas y la experiencia de usuario siguen igual, pero se necesita cinco veces más cómputo. Por eso Cohere propone tratar la profundidad del retrieval como una decisión de infraestructura, y no solo como un ajuste de calidad.

Conclusiones de los key takeaways

De las tesis del material se desprende la siguiente lógica:

• la request shape pesa más que el volumen de solicitudes: unas pocas llamadas grandes a Embed pueden consumir más compute que miles de consultas de búsqueda cortas, por lo que el RPM como única métrica para planificar la capacidad no es fiable;
• la inferencia dedicated suele ser más económica con una carga estable y predecible, mientras que el modelo consumption-based encaja mejor con un tráfico variable o con picos;
• el punto de equilibrio depende del tamaño de la solicitud, del volumen de tokens y del número de candidatos en rerank, y no solo del precio de la infraestructura;
• el throughput máximo no equivale a la capacidad de producción realmente disponible: hay que cumplir los requisitos de latency y, al mismo tiempo, mantener el coste dentro de límites razonables.

Cómo abordar la elección en la práctica

El orden de pasos es el que propone la propia Cohere: perfil de la solicitud, después patrón de tráfico, luego utilización y, solo al final, la elección del despliegue. Empiece midiendo los tamaños reales de las solicitudes: cuántos documentos hay en un lote de indexación, cuántos tokens tienen de media y cuántos candidatos se envían al reranker. Después, separe la carga en dos tipos: de fondo (indexación, recálculos por lotes) e interactiva (búsqueda, donde el usuario espera). La primera a menudo puede mantenerse en modo shared si es irregular. La segunda, con un flujo estable, es candidata a capacidad dedicada.

Por separado, recalcule el coste al cambiar la profundidad del reranking: pasar de 20 a 100 candidatos puede desplazar el punto de equilibrio. Y pruebe la capacidad con la latencia objetivo, no con el máximo de throughput de la ficha técnica. En el fragmento disponible, esta parte del material se interrumpe en la sección sobre patrones de tráfico, por lo que Cohere no aporta aquí umbrales concretos para cambiar de un modo a otro.