Una guía práctica para desplegar modelos fundacionales de búsqueda en producción

En Jina AI, nuestra misión es proporcionar a los usuarios empresariales soluciones de búsqueda de alta calidad. Para lograrlo, hacemos que nuestros modelos sean accesibles a través de varios canales. Sin embargo, elegir el canal adecuado para tu caso de uso específico puede ser complicado. En esta publicación, te guiaremos a través del proceso de toma de decisiones y analizaremos las ventajas y desventajas, brindándote orientación práctica sobre la mejor manera de acceder a nuestros modelos de búsqueda según tu perfil de usuario y necesidades.

tagModelos de Fundación de Búsqueda de Jina

Our Search Foundation Models

We've been moving the needle in search models since day one. Take a look at our model evolution below—hover or click to discover each milestone.

Jina AI

Nuestros modelos de fundación de búsqueda incluyen:

• Embeddings: Estos convierten información sobre objetos digitales en vectores de embedding, capturando sus características esenciales.
• Rerankers: Estos realizan un análisis semántico profundo de conjuntos de consultas y documentos para mejorar la relevancia de la búsqueda.
• Small language models: Estos incluyen SLM especializados como ReaderLM-v2 para tareas específicas como HTML2Markdown o extracción de información.

En esta publicación, examinaremos diferentes opciones de implementación para jina-embeddings-v3, comparando tres enfoques clave:

• Usando Jina API
• Implementando a través de CSP como AWS SageMaker
• Auto-alojamiento en un clúster de Kubernetes bajo una licencia comercial

La comparación evaluará las implicaciones de costos y ventajas de cada enfoque para ayudarte a determinar la opción más adecuada para tus necesidades.

tagMétricas Clave de Rendimiento

Evaluamos cinco métricas clave de rendimiento en diferentes escenarios de uso:

• Tasa de Éxito de Solicitudes: El porcentaje de solicitudes exitosas al servidor de embedding
• Latencia de Solicitud: El tiempo que tarda el servidor de embedding en procesar y devolver una solicitud
• Rendimiento de Tokens: El número de tokens que el servidor de embedding puede procesar por segundo
• Costo por Token: El costo total de procesamiento por unidad de texto

Para los embeddings de Jina auto-alojados en clústeres de Kubernetes, también examinamos el impacto del batching dinámico. Esta función pone en cola las solicitudes hasta alcanzar el tamaño máximo de lote (8,192 para jina-embeddings-v3) antes de generar embeddings.

Intencionalmente excluimos dos factores significativos de rendimiento de nuestro análisis:

• Auto-escalado: Si bien esto es crucial para implementaciones en la nube con cargas de trabajo variables, su efectividad depende de numerosas variables: eficiencia del hardware, arquitectura de red, latencia y elecciones de implementación. Estas complejidades están más allá de nuestro alcance actual. Ten en cuenta que Jina API incluye escalado automático, y nuestros resultados reflejan esto.
• Cuantización: Si bien esta técnica crea vectores de embedding más pequeños y reduce la transferencia de datos, los principales beneficios provienen de otros componentes del sistema (almacenamiento de datos y cálculos de distancia vectorial) en lugar de la reducción en la transferencia de datos. Ya que nos estamos enfocando en los costos directos de uso del modelo, hemos dejado la cuantización fuera de este análisis.

Finalmente, examinaremos las implicaciones financieras de cada enfoque, considerando tanto los costos totales de propiedad como los gastos por token/por solicitud.

tagConfiguración de Implementación

Evaluamos tres escenarios de implementación y uso con jina-embeddings-v3:

tagUso de Jina API

Todos los modelos de embedding de Jina AI son accesibles a través de Jina API. El acceso funciona con un sistema de tokens prepagados, con un millón de tokens disponibles gratis para pruebas. Evaluamos el rendimiento haciendo llamadas a la API a través de internet desde nuestras oficinas en Alemania.

tagUso de AWS SageMaker

Jina Embeddings v3 está disponible para usuarios de AWS a través de SageMaker. El uso requiere una suscripción de AWS a este modelo. Para código de ejemplo, hemos proporcionado un notebook que muestra cómo suscribirse y usar los modelos de Jina AI con una cuenta de AWS.

Si bien los modelos también están disponibles en Microsoft Azure y Google Cloud Platform, enfocamos nuestras pruebas en AWS. Esperamos un rendimiento similar en otras plataformas. Todas las pruebas se ejecutaron en una instancia ml.g5.xlarge en la región us-east-1.

tagAuto-alojamiento en Kubernetes

Construimos una aplicación FastAPI en Python que carga jina-embeddings-v3 desde HuggingFace usando la biblioteca SentenceTransformer. La aplicación incluye dos endpoints:

• /embed: Toma pasajes de texto como entrada y devuelve sus embeddings
• /health: Proporciona monitoreo básico de salud

Lo implementamos como un servicio de Kubernetes en Amazon's Elastic Kubernetes Service, usando una instancia g5.xlarge en us-east-1.

Con y Sin Batching Dinámico

Probamos el rendimiento en un clúster de Kubernetes en dos configuraciones: Una donde procesaba inmediatamente cada solicitud cuando la recibía, y otra donde usaba batching dinámico. En el caso del batching dinámico, el servicio espera hasta que se recolectan MAX_TOKENS (8192) en una cola, o se alcanza un tiempo límite predefinido de 2 segundos, antes de invocar el modelo y calcular los embeddings. Este enfoque aumenta la utilización de la GPU y reduce la fragmentación de la memoria de la GPU.

Para cada escenario de implementación, realizamos pruebas variando tres parámetros clave:

• Tamaño del lote: Cada solicitud contenía 1, 32 o 128 pasajes de texto para embedding
• Longitud del pasaje: Usamos pasajes de texto que contenían 128, 512 o 1,024 tokens
• Solicitudes concurrentes: Enviamos 1, 5 o 10 solicitudes simultáneamente

tagResultados del Benchmark

La tabla siguiente es un resumen de resultados para cada escenario de uso, promediando todas las configuraciones de las tres variables anteriores.

tagTasa de Éxito de Solicitudes

Las tasas de éxito en nuestras pruebas varían desde el casi perfecto 99.9% de SageMaker hasta el modesto 56-58% de las soluciones auto-alojadas, destacando por qué la confiabilidad del 100% sigue siendo difícil de alcanzar en sistemas de producción. Tres factores clave contribuyen a esto:

• La inestabilidad de la red causa fallos inevitables incluso en entornos cloud
• La contención de recursos, especialmente la memoria GPU, lleva a fallos de solicitudes bajo carga
• Los límites de tiempo de espera necesarios significan que algunas solicitudes deben fallar para mantener la salud del sistema

tagTasa de Éxito por Tamaño de Lote

Los tamaños de lote grandes frecuentemente causan errores de memoria insuficiente en la configuración auto-alojada de Kubernetes. Sin batching dinámico, todas las solicitudes que contenían 32 o 128 elementos por lote fallaron por esta razón. Incluso con el batching dinámico implementado, la tasa de fallos para lotes grandes siguió siendo significativamente alta.

Si bien este problema podría resolverse fácilmente mediante el auto-escalado, hemos optado por no explorar esa opción aquí. El auto-escalado conduciría a aumentos de costos impredecibles, y sería difícil proporcionar conclusiones prácticas dado el gran número de opciones de configuración de auto-escalado disponibles.

tagTasa de Éxito por Nivel de Concurrencia

La concurrencia — la capacidad de manejar múltiples solicitudes simultáneamente — no tuvo un impacto fuerte ni consistente en las tasas de éxito de las solicitudes en las configuraciones de Kubernetes auto-alojadas, y solo un efecto mínimo en AWS SageMaker, al menos hasta un nivel de concurrencia de 10.

tagTasa de Éxito por Longitud de Token

Los pasajes largos con alto número de tokens afectan tanto a la API de Embedding de Jina como a Kubernetes con batch dinámico de manera similar a los lotes grandes: a medida que aumenta el tamaño, la tasa de fallos aumenta sustancialmente. Sin embargo, mientras que las soluciones auto-alojadas sin batch dinámico casi invariablemente fallan con lotes grandes, tienen un mejor rendimiento con pasajes largos individuales. En cuanto a SageMaker, las longitudes de pasaje largas - al igual que la concurrencia y el tamaño del lote - no tuvieron un impacto notable en las tasas de éxito de las solicitudes.

tagLatencia de Solicitud

Todas las pruebas de latencia se repitieron cinco veces en niveles de concurrencia de 1, 5 y 10. El tiempo de respuesta es el promedio de cinco intentos. El rendimiento de solicitudes es el inverso del tiempo de respuesta en segundos, multiplicado por la concurrencia.

tagJina API

Los tiempos de respuesta en la API de Jina están principalmente influenciados por el tamaño del lote, independientemente del nivel de concurrencia. Si bien la longitud del pasaje también afecta el rendimiento, su impacto no es directo. Como principio general, las solicitudes que contienen más datos - ya sea a través de tamaños de lote más grandes o pasajes más largos - tardan más en procesarse.

Concurrencia 1:

Concurrencia 5:

Concurrencia 10:

Para solicitudes individuales (batch size de 1):

• Los tiempos de respuesta se mantienen relativamente estables, entre 600-800ms, independientemente de la longitud del pasaje
• Una mayor concurrencia (5 o 10 solicitudes simultáneas) no degrada significativamente el rendimiento por solicitud

Para lotes más grandes (32 y 128 elementos):

• Los tiempos de respuesta aumentan sustancialmente, con un batch size de 128 tomando aproximadamente 4-6 veces más que las solicitudes individuales
• El impacto de la longitud del pasaje se vuelve más pronunciado con lotes más grandes
• Con alta concurrencia (10) y lotes grandes (128), la combinación lleva a tiempos de respuesta significativamente más largos, alcanzando casi 18 segundos para los pasajes más extensos

Para el rendimiento:

• Los lotes más pequeños generalmente logran mejor rendimiento al ejecutar solicitudes concurrentes
• Con concurrencia 10 y batch size 1, el sistema alcanza su mayor rendimiento de aproximadamente 15 solicitudes/segundo
• Los lotes más grandes muestran consistentemente menor rendimiento, cayendo a menos de 1 solicitud/segundo en varios escenarios

tagAWS SageMaker

Las pruebas de AWS SageMaker se realizaron con una instancia ml.g5.xlarge.

Concurrencia 1:

Concurrencia 5:

Concurrencia 10:

Diferencias clave vs Jina API:

• Rendimiento Base: SageMaker es significativamente más rápido para solicitudes pequeñas (elementos individuales, pasajes cortos) - alrededor de 200ms vs 700-800ms para Jina.
• Comportamiento de Escalado:
  • Ambos servicios se ralentizan con lotes más grandes y pasajes más largos
  • SageMaker muestra una desaceleración más dramática con lotes grandes (128) y pasajes largos (1024 tokens)
  • Con alta concurrencia (10) con carga máxima (batch 128, 1024 tokens), SageMaker toma ~26s vs ~18s de Jina
• Impacto de la Concurrencia:
  • Ambos servicios se benefician de una mayor concurrencia para el rendimiento
  • Ambos mantienen patrones de rendimiento similares a través de los niveles de concurrencia
  • SageMaker alcanza un rendimiento máximo ligeramente superior (17 req/s vs 15 req/s) con concurrencia 10

tagClúster Kubernetes Auto-Alojado

Las pruebas de auto-alojamiento se realizaron en el Elastic Kubernetes Service de Amazon con una instancia g5.xlarge.

Concurrencia 1:

Concurrencia 5:

Concurrencia 10:

Cuando se recibieron solicitudes con más de 16,384 tokens, nuestra configuración auto-alojada falló con errores del servidor, típicamente por falta de memoria. Esto fue cierto independientemente de los niveles de concurrencia. Como resultado, no se muestran pruebas con más datos que eso.

La alta concurrencia aumentó los tiempos de respuesta de manera aproximadamente lineal: los niveles de concurrencia de 5 tardaron aproximadamente cinco veces más en responder que 1. Niveles de 10, diez veces más.

El procesamiento por lotes dinámico ralentiza los tiempos de respuesta en aproximadamente dos segundos para lotes pequeños. Esto es esperado porque la cola de procesamiento espera 2 segundos antes de procesar un lote incompleto. Sin embargo, para tamaños de lote más grandes, aporta mejoras moderadas en el tiempo de respuesta.

tagRendimiento de Tokens

El rendimiento de tokens aumenta con tamaños de lote más grandes, longitudes de pasaje más largas y niveles de concurrencia más altos en todas las plataformas. Por lo tanto, solo presentaremos resultados en niveles de uso alto, ya que los niveles más bajos no proporcionarían una indicación significativa del rendimiento en el mundo real.

Todas las pruebas se realizaron con un nivel de concurrencia de 10, con 16,384 tokens por solicitud, promediado sobre cinco solicitudes. Probamos dos configuraciones: tamaño de lote 32 con pasajes de 512 tokens, y tamaño de lote 128 con pasajes de 128 tokens. El número total de tokens permanece constante en ambas configuraciones.

Rendimiento de tokens (tokens por segundo):

Bajo condiciones de alta carga, la API de Jina supera significativamente a las alternativas, mientras que las soluciones auto-alojadas probadas aquí muestran un rendimiento sustancialmente menor.

tagCostos Por Millón de Tokens

El costo es posiblemente el factor más crítico al elegir una solución de embedding. Si bien calcular los costos de modelos de IA puede ser complejo, aquí hay un análisis comparativo de diferentes opciones:

tagJina API

El servicio sigue un modelo de precios basado en tokens con dos niveles prepagados:

• $20 por 1 mil millones de tokens ($0.02 por millón) - Una tarifa de entrada ideal para prototipado y desarrollo
• $200 por 11 mil millones de tokens ($0.018 por millón) - Una tarifa más económica para volúmenes mayores

Vale la pena mencionar que estos tokens funcionan en toda la suite de productos de Jina, incluyendo lectores, reordenadores y clasificadores zero-shot.

tagAWS SageMaker

Los precios de SageMaker combinan los costos por hora de la instancia con las tarifas de licencia del modelo. Usando una instancia ml.g5.xlarge:

• Costo de instancia: $1.408/hora (Este de EE.UU.) o$1.761/hora (Frankfurt UE)
• Licencia de jina-embeddings-v3: $2.50/hora
• Costo total por hora: $3.908-$4.261 dependiendo de la región

Con un rendimiento promedio de 15,044 tokens/segundo (54.16M tokens/hora), el costo por millón de tokens varía entre $0.0723 y$0.0788.

tagAutoalojamiento con Kubernetes

Los costos de autoalojamiento varían significativamente según la elección de infraestructura. Usando la instancia g5.xlarge de AWS EC2 como referencia:

• Costo de instancia: $1.006/hora (Este de EE.UU.) o$1.258/hora (Frankfurt UE)
• Licencia de jina-embeddings-v3: $5000/trimestre ($2.282/hora)
• Costo total por hora: $3.288-$3.540 dependiendo de la región

A 2,588 tokens/segundo (9.32M tokens/hora), el costo por millón de tokens es de $0.352-$0.379. Si bien la tarifa por hora es menor que SageMaker, el rendimiento reducido resulta en costos más altos por token.

Consideraciones importantes para el autoalojamiento:

• Los costos fijos (licencias, infraestructura) continúan independientemente del uso
• El alojamiento local aún requiere tarifas de licencia y costos de personal
• Las cargas de trabajo variables pueden impactar significativamente la eficiencia de costos

tagConclusiones Principales

La API de Jina emerge como la solución más rentable, incluso sin considerar los tiempos de inicio en frío y asumiendo un rendimiento óptimo para las alternativas.

El autoalojamiento podría tener sentido para organizaciones con infraestructura robusta existente donde los costos marginales del servidor son mínimos. Además, explorar proveedores en la nube más allá de AWS podría ofrecer mejores precios.

Sin embargo, para la mayoría de las empresas, especialmente las PYMES que buscan soluciones llave en mano, la API de Jina ofrece una eficiencia de costos inigualable.

tagConsideraciones de Seguridad y Privacidad de Datos

Al elegir una estrategia de implementación para modelos de embedding, los requisitos de seguridad y privacidad de datos pueden jugar un papel decisivo junto con las consideraciones de rendimiento y costo. Ofrecemos opciones de implementación flexibles para adaptarse a diferentes necesidades de seguridad:

tagProveedores de Servicios en la Nube

Para empresas que ya trabajan con principales proveedores de la nube, nuestras ofertas en el marketplace de la nube (como AWS Marketplace, Azure, y GCP) proporcionan una solución natural para la implementación dentro de marcos de seguridad preexistentes. Estas implementaciones se benefician de:

• Controles de seguridad y cumplimiento heredados de su relación con el CSP
• Integración lista con políticas de seguridad existentes y reglas de gobierno de datos
• Requiere poco o ningún cambio en los acuerdos existentes de procesamiento de datos
• Alineación con consideraciones preexistentes de soberanía de datos

tagAutoalojamiento e Implementación Local

Las organizaciones con requisitos estrictos de seguridad u obligaciones regulatorias específicas a menudo prefieren el control físico completo sobre su infraestructura. Nuestra opción de autoalojamiento permite:

• Control total sobre el entorno de implementación
• Procesamiento de datos completamente dentro de su perímetro de seguridad
• Integración con el monitoreo y controles de seguridad existentes

Para obtener licencias comerciales para nuestros modelos CC-BY-NC, primero necesita obtener una licencia de nosotros. No dude en contactar a nuestro equipo de ventas.

tagServicio de API de Jina

Para startups y PYMES que intentan equilibrar la seguridad y la conveniencia frente a los costos, nuestro servicio de API proporciona seguridad de nivel empresarial sin agregar sobrecarga operativa:

• Certificación SOC2 que garantiza controles de seguridad robustos
• Cumplimiento total del GDPR para el procesamiento de datos
• Política de retención cero de datos - no almacenamos ni registramos sus solicitudes
• Transmisión de datos encriptada e infraestructura segura

Las ofertas de modelos de Jina AI permiten a las organizaciones elegir la estrategia de implementación que mejor se alinee con sus requisitos de seguridad mientras mantienen la eficiencia operativa.

tagEligiendo Tu Solución

El diagrama de flujo a continuación resume los resultados de todas las pruebas empíricas y tablas que has visto:

Primero, considera tus necesidades de seguridad y cuánta flexibilidad puedes sacrificar para cumplirlas.

Luego, considera cómo planeas usar la IA en tu empresa:

1. Indexación offline y casos de uso no sensibles al tiempo que pueden usar procesamiento por lotes de manera óptima.
2. Usos sensibles a la confiabilidad y escalabilidad como la generación aumentada por recuperación e integración con LLM.
3. Usos sensibles al tiempo como búsqueda y recuperación en línea.

También, considera tu experiencia interna e infraestructura existente:

1. ¿Tu stack tecnológico ya depende en gran medida de la nube?
2. ¿Tienes una gran operación de TI interna capaz de autoalojamiento?

Por último, considera tus volúmenes de datos esperados. ¿Eres un usuario a gran escala que espera realizar millones de operaciones usando modelos de IA cada día?

tagConclusión

La integración de IA en las decisiones operativas sigue siendo territorio inexplorado para muchos departamentos de TI, ya que el mercado carece de soluciones llave en mano establecidas. Esta incertidumbre puede hacer que la planificación estratégica sea desafiante. Nuestro análisis cuantitativo tiene como objetivo proporcionar una guía concreta sobre cómo incorporar nuestros modelos de base de búsqueda en tus flujos de trabajo y aplicaciones específicas.

En cuanto al costo por unidad, la API de Jina se destaca como una de las opciones más económicas disponibles para las empresas. Pocas alternativas pueden igualar nuestro precio mientras ofrecen funcionalidad comparable.

Estamos comprometidos a ofrecer capacidades de búsqueda que no solo sean potentes y fáciles de usar, sino también rentables para organizaciones de todos los tamaños. Ya sea a través de los principales proveedores de la nube o implementaciones autoalojadas, nuestras soluciones se adaptan incluso a los requisitos empresariales más complejos que van más allá de las consideraciones puramente de costo. Este análisis desglosa los diversos factores de costo para ayudar a informar tu toma de decisiones.

Dado que cada organización tiene sus propios requisitos únicos, reconocemos que un solo artículo no puede abordar todos los escenarios. Si tienes necesidades específicas no cubiertas aquí, no dudes en contactarnos para discutir cómo podemos apoyar mejor tu implementación.