Infraestructura compartida o dedicada para embedding y reranking: cómo elegir según la carga de trabajo

Request Profile: la forma importa más que el volumen

Cohere realizó un análisis sobre la elección entre shared (consumo por uso) y dedicated (infraestructura reservada) para embedding y reranking. El hallazgo principal: la gente suele comparar solo el precio por token y la cantidad de solicitudes por minuto, pero estas métricas casi no dicen nada sobre la elección correcta. La lógica es simple: Request Profile → Traffic Pattern → Utilization → Deployment Choice.

Un mismo modelo de embedding puede realizar trabajos completamente distintos. En un sitio de e-commerce, el embedding se usa de dos formas: indexar el catálogo (cientos de descripciones de productos a la vez, de unas 150 palabras, cerca de 200 tokens por texto) y procesar una consulta de búsqueda (una sola consulta breve, mientras el usuario mira un spinner de carga). El procesamiento por lotes optimiza el throughput y el costo; la consulta de búsqueda optimiza la capacidad de respuesta. Son requisitos opuestos, y una misma infraestructura no puede atender bien a ambos.

En el reranking se añade un parámetro crítico: el número de candidatos a reordenar. La búsqueda vectorial devuelve 50 productos, y el reranker reevalúa cada uno respecto a la consulta. El modelo compara la consulta contra cada candidato de forma independiente, por lo que el trabajo escala estrictamente con el número de candidatos. Un perfil típico: una consulta de 20 tokens más 50 documentos de 200 tokens cada uno equivale a unos 11,000 tokens por operación. Pasar de 20 a 100 candidatos, el usuario no notará nada, pero la carga crecerá de 4,400 a 22,000 tokens. Es una decisión sobre la profundidad de la búsqueda, no sobre escalar usuarios.

Traffic Pattern y latencia: qué determina la capacidad real

Dos aplicaciones con el mismo tráfico pico pueden tener costos de infraestructura completamente distintos. El tráfico estable (búsqueda global, flujo constante durante el día) hace que la capacidad dedicada sea más económica: la infraestructura se usa bien, sin tiempos muertos ni picos sin atender. El tráfico irregular (informes financieros, trabajos por lotes, picos en ventanas específicas) favorece la infraestructura compartida, porque no se paga por capacidad que está inactiva la mayor parte del tiempo.

La pregunta clave no es «¿cuál es el tráfico pico?», sino «¿qué tan predecible y constante es el uso de la capacidad?». Un servicio con 10,000 solicitudes por segundo durante 5 minutos al día tiene una economía completamente distinta a un servicio con 100 solicitudes por segundo de forma continua.

El rendimiento máximo de la GPU no equivale a la capacidad real de producción, porque distintas cargas de trabajo tienen distintos requisitos de latencia. La indexación por lotes puede operar al máximo (la finalización importa más que la velocidad). Las consultas de búsqueda requieren presupuestos estrictos de latencia (el retraso afecta la experiencia de usuario y los ingresos). El reranking, al expandir los candidatos, aumenta los documentos/seg pero reduce las búsquedas/seg. La infraestructura debe ofrecer un throughput que respete los requisitos de latencia, no solo alcanzar un pico de benchmark.

Punto de equilibrio y la economía de la elección

Cohere calculó los puntos de cruce económico usando una sola GPU NVIDIA A10 con precios estándar basados en consumo (sin descuentos, tráfico 24/7):

• Embedding de consulta (solicitud única, 8 tokens): equilibrio en ~decenas de miles de solicitudes/min • Embedding de catálogo (100 textos × 200 tokens, 20K por solicitud): equilibrio en ~20 solicitudes/min • Embedding de documento largo (100 textos × 1000 tokens, 100K por solicitud): equilibrio en ~4 solicitudes/min • Reranking (1 consulta + 50 documentos, 11K tokens): equilibrio en ~29 solicitudes/min

Un mismo modelo, un mismo precio, y el punto de equilibrio cambia cientos de veces según el tamaño de la solicitud. Un perfil de catálogo a 30 solicitudes/min parece modesto, pero ya está por encima del equilibrio de 20 solicitudes/min: dedicated ya es más económico. Cambia el tamaño de la solicitud, el número de candidatos, los requisitos de latencia o el patrón de tráfico, y el punto se desplazará drásticamente. Por eso no hay una respuesta universal: la elección entre shared y dedicated depende de la carga de trabajo específica, la latencia requerida y los patrones de tráfico, no de métricas destacadas como el precio por token o las RPM.