Guide pratique pour le déploiement des modèles fondamentaux de recherche en production

Chez Jina AI, notre mission est de fournir aux entreprises des solutions de recherche de haute qualité. Pour y parvenir, nous rendons nos modèles accessibles via différents canaux. Cependant, choisir le bon canal pour votre cas d'usage spécifique peut s'avérer délicat. Dans cet article, nous vous guiderons à travers le processus décisionnel et détaillerons les compromis, en vous donnant des conseils pratiques sur la meilleure façon d'accéder à nos modèles de recherche selon votre profil et vos besoins.

tagModèles de Recherche Fondamentaux de Jina

Nos Modèles de Recherche Fondamentaux

Nous faisons progresser les modèles de recherche depuis le premier jour. Découvrez l'évolution de nos modèles ci-dessous—survolez ou cliquez pour découvrir chaque étape.

Jina AI

Nos modèles de recherche fondamentaux incluent :

• Embeddings : Ils convertissent les informations sur les objets numériques en vecteurs d'embedding, capturant leurs caractéristiques essentielles.
• Rerankers : Ils effectuent une analyse sémantique approfondie des ensembles requête-document pour améliorer la pertinence de la recherche.
• Small language models : Ils incluent des SLM spécialisés comme ReaderLM-v2 pour des tâches spécifiques comme HTML2Markdown ou l'extraction d'informations.

Dans cet article, nous examinerons différentes options de déploiement pour jina-embeddings-v3, en comparant trois approches principales :

• Utilisation de l'API Jina
• Déploiement via un CSP comme AWS SageMaker
• Auto-hébergement sur un cluster Kubernetes sous licence commerciale

La comparaison évaluera les implications en termes de coûts et les avantages de chaque approche pour vous aider à déterminer l'option la plus adaptée à vos besoins.

tagMétriques de Performance Clés

Nous avons évalué cinq métriques de performance clés dans différents scénarios d'utilisation :

• Taux de Succès des Requêtes : Le pourcentage de requêtes réussies vers le serveur d'embedding
• Latence des Requêtes : Le temps nécessaire au serveur d'embedding pour traiter et renvoyer une requête
• Débit de Tokens : Le nombre de tokens que le serveur d'embedding peut traiter par seconde
• Coût par Token : Le coût total de traitement par unité de texte

Pour les embeddings Jina auto-hébergés sur des clusters Kubernetes, nous avons également examiné l'impact du dynamic batching. Cette fonctionnalité met en file d'attente les requêtes jusqu'à atteindre la taille maximale de lot (8 192 pour jina-embeddings-v3) avant de générer les embeddings.

Nous avons intentionnellement exclu deux facteurs de performance importants de notre analyse :

• Auto-scaling : Bien que crucial pour les déploiements cloud avec des charges variables, son efficacité dépend de nombreuses variables—efficacité matérielle, architecture réseau, latence et choix d'implémentation. Ces complexités dépassent notre portée actuelle. Notez que l'API Jina inclut la mise à l'échelle automatique, et nos résultats en tiennent compte.
• Quantization : Bien que cette technique crée des vecteurs d'embedding plus petits et réduise le transfert de données, les principaux avantages proviennent d'autres composants du système (stockage des données et calculs de distance vectorielle) plutôt que de la réduction du transfert de données. Comme nous nous concentrons sur les coûts d'utilisation directs des modèles, nous avons laissé la quantization hors de cette analyse.

Enfin, nous examinerons les implications financières de chaque approche, en considérant à la fois les coûts totaux de possession et les dépenses par token/requête.

tagConfiguration du Déploiement

Nous avons évalué trois scénarios de déploiement et d'utilisation avec jina-embeddings-v3 :

tagUtilisation de l'API Jina

Tous les modèles d'embedding de Jina AI sont accessibles via l'API Jina. L'accès fonctionne sur un système de tokens prépayés, avec un million de tokens gratuits pour les tests. Nous avons évalué les performances en effectuant des appels API via Internet depuis nos bureaux en Allemagne.

tagUtilisation d'AWS SageMaker

Jina Embeddings v3 est disponible pour les utilisateurs AWS via SageMaker. L'utilisation nécessite un abonnement AWS à ce modèle. Pour le code exemple, nous avons fourni un notebook qui montre comment s'abonner et utiliser les modèles Jina AI avec un compte AWS.

Bien que les modèles soient également disponibles sur Microsoft Azure et Google Cloud Platform, nous avons concentré nos tests sur AWS. Nous attendons des performances similaires sur les autres plateformes. Tous les tests ont été effectués sur une instance ml.g5.xlarge dans la région us-east-1.

tagAuto-hébergement sur Kubernetes

Nous avons construit une application FastAPI en Python qui charge jina-embeddings-v3 depuis HuggingFace en utilisant la bibliothèque SentenceTransformer. L'application inclut deux endpoints :

• /embed : Prend des passages de texte en entrée et renvoie leurs embeddings
• /health : Fournit une surveillance de base de la santé

Nous avons déployé cela comme un service Kubernetes sur Amazon Elastic Kubernetes Service, en utilisant une instance g5.xlarge dans us-east-1.

Avec et Sans Dynamic Batching

Nous avons testé les performances dans un cluster Kubernetes dans deux configurations : Une où chaque requête était traitée immédiatement à sa réception, et une où le dynamic batching était utilisé. Dans le cas du dynamic batching, le service attend jusqu'à ce que MAX_TOKENS (8192) soient collectés dans une file d'attente, ou qu'un timeout prédéfini de 2 secondes soit atteint, avant d'invoquer le modèle et de calculer les embeddings. Cette approche augmente l'utilisation du GPU et réduit la fragmentation de la mémoire GPU.

Pour chaque scénario de déploiement, nous avons effectué des tests en faisant varier trois paramètres clés :

• Taille de lot : Chaque requête contenait soit 1, 32, ou 128 passages de texte à encoder
• Longueur des passages : Nous avons utilisé des passages de texte contenant 128, 512, ou 1 024 tokens
• Requêtes concurrentes : Nous avons envoyé 1, 5, ou 10 requêtes simultanément

tagRésultats des Tests

Le tableau ci-dessous est un résumé des résultats pour chaque scénario d'utilisation, moyennés sur tous les paramètres des trois variables ci-dessus.

tagTaux de Succès des Requêtes

Les taux de succès dans nos tests vont de près de 99,9 % pour SageMaker à un modeste 56-58 % pour les solutions auto-hébergées, soulignant pourquoi une fiabilité à 100 % reste insaisissable dans les systèmes de production. Trois facteurs clés contribuent à cela :

• L'instabilité du réseau cause des échecs inévitables même dans les environnements cloud
• La contention des ressources, en particulier la mémoire GPU, conduit à des échecs de requêtes sous charge
• Les limites de timeout nécessaires signifient que certaines requêtes doivent échouer pour maintenir la santé du système

tagTaux de Succès par Taille de Lot

Les grandes tailles de lot causent fréquemment des erreurs de mémoire insuffisante dans la configuration Kubernetes auto-hébergée. Sans dynamic batching, toutes les requêtes contenant 32 ou 128 éléments par lot ont échoué pour cette raison. Même avec le dynamic batching implémenté, le taux d'échec pour les grands lots est resté significativement élevé.

Bien que ce problème puisse être facilement résolu par l'auto-scaling, nous avons choisi de ne pas explorer cette option ici. L'auto-scaling entraînerait des augmentations de coûts imprévisibles, et il serait difficile de fournir des informations exploitables étant donné le grand nombre d'options de configuration d'auto-scaling disponibles.

tagTaux de réussite par niveau de concurrence

La concurrence — la capacité à gérer plusieurs requêtes simultanément — n'a eu ni un impact fort ni constant sur les taux de réussite des requêtes dans les configurations Kubernetes auto-hébergées, et seulement un effet minimal sur AWS SageMaker, au moins jusqu'à un niveau de concurrence de 10.

tagTaux de réussite par longueur de token

Les longs passages avec un nombre élevé de tokens affectent à la fois la Jina Embedding API et Kubernetes avec batching dynamique de manière similaire aux grands lots : à mesure que la taille augmente, le taux d'échec augmente considérablement. Cependant, alors que les solutions auto-hébergées sans batching dynamique échouent presque invariablement avec de grands lots, elles fonctionnent mieux avec des passages longs individuels. Quant à SageMaker, les longueurs de passage importantes - comme la concurrence et la taille des lots - n'ont eu aucun impact notable sur les taux de réussite des requêtes.

tagLatence des requêtes

Tous les tests de latence ont été répétés cinq fois à des niveaux de concurrence de 1, 5 et 10. Le temps de réponse est la moyenne sur cinq tentatives. Le débit des requêtes est l'inverse du temps de réponse en secondes, multiplié par la concurrence.

tagJina API

Les temps de réponse dans la Jina API sont principalement influencés par la taille du lot, quel que soit le niveau de concurrence. Bien que la longueur du passage affecte également les performances, son impact n'est pas simple. En règle générale, les requêtes contenant plus de données - que ce soit par des tailles de lots plus importantes ou des passages plus longs - prennent plus de temps à traiter.

Concurrence 1 :

Concurrence 5 :

Concurrence 10 :

Pour les requêtes individuelles (taille de lot de 1) :

• Les temps de réponse restent relativement stables, variant de 600 à 800 ms environ, quelle que soit la longueur du passage
• Une concurrence plus élevée (5 ou 10 requêtes simultanées) ne dégrade pas significativement les performances par requête

Pour les lots plus importants (32 et 128 éléments) :

• Les temps de réponse augmentent considérablement, avec une taille de lot de 128 prenant environ 4 à 6 fois plus de temps que les requêtes individuelles
• L'impact de la longueur du passage devient plus prononcé avec des lots plus importants
• À haute concurrence (10) et grands lots (128), la combinaison conduit à des temps de réponse significativement plus longs, atteignant près de 18 secondes pour les passages les plus longs

Pour le débit :

• Les petits lots obtiennent généralement un meilleur débit lors de l'exécution de requêtes concurrentes
• À une concurrence de 10 avec une taille de lot de 1, le système atteint son débit le plus élevé d'environ 15 requêtes/seconde
• Les lots plus importants montrent systématiquement un débit plus faible, descendant à moins d'une requête/seconde dans plusieurs scénarios

tagAWS SageMaker

Les tests AWS SageMaker ont été effectués avec une instance ml.g5.xlarge.

Concurrence 1 :

Concurrence 5 :

Concurrence 10 :

Différences principales par rapport à l'API Jina :

• Performance de base : SageMaker est significativement plus rapide pour les petites requêtes (éléments uniques, passages courts) - environ 200 ms contre 700-800 ms pour Jina.
• Comportement à l'échelle :
  • Les deux services ralentissent avec des lots plus importants et des passages plus longs
  • SageMaker montre un ralentissement plus drastique avec des lots importants (128) et des passages longs (1024 tokens)
  • À haute concurrence (10) avec une charge maximale (lot 128, 1024 tokens), SageMaker prend ~26s contre ~18s pour Jina
• Impact de la concurrence :
  • Les deux services bénéficient d'une concurrence accrue pour le débit
  • Les deux maintiennent des modèles de débit similaires à travers les niveaux de concurrence
• SageMaker atteint un débit de pointe légèrement supérieur (17 req/s contre 15 req/s) à une concurrence de 10

tagCluster Kubernetes auto-hébergé

Les tests d'auto-hébergement ont été effectués sur le Service Kubernetes Elastic d'Amazon avec une instance g5.xlarge.

Concurrence 1 :

Concurrence 5 :

Concurrence 10 :

Lorsque des requêtes de plus de 16 384 tokens ont été soumises, notre configuration auto-hébergée a échoué avec des erreurs serveur, généralement des erreurs de mémoire insuffisante. Cela était vrai indépendamment des niveaux de concurrence. Par conséquent, aucun test avec plus de données n'est affiché.

Une concurrence élevée a augmenté les temps de réponse de manière globalement linéaire : les niveaux de concurrence de 5 ont pris environ cinq fois plus de temps pour répondre que 1. Les niveaux de 10, dix fois plus longtemps.

Le traitement par lots dynamique ralentit les temps de réponse d'environ deux secondes pour les petits lots. Cela est attendu car la file d'attente de traitement par lots attend 2 secondes avant de traiter un lot incomplet. Cependant, pour des tailles de lots plus importantes, il apporte des améliorations modérées du temps de réponse.

tagDébit de tokens

Le débit de tokens augmente avec des tailles de lots plus importantes, des longueurs de passage plus longues et des niveaux de concurrence plus élevés sur toutes les plateformes. Par conséquent, nous ne présenterons que les résultats à des niveaux d'utilisation élevés, car les niveaux inférieurs ne fourniraient pas d'indication significative des performances en conditions réelles.

Tous les tests ont été effectués avec un niveau de concurrence de 10, avec 16 384 tokens par requête, moyennés sur cinq requêtes. Nous avons testé deux configurations : taille de lot 32 avec des passages de 512 tokens, et taille de lot 128 avec des passages de 128 tokens. Le nombre total de tokens reste constant dans les deux configurations.

Débit de tokens (tokens par seconde) :

Dans des conditions de charge élevée, l'API Jina surpasse significativement les alternatives, tandis que les solutions auto-hébergées testées ici montrent des performances nettement inférieures.

tagCoûts par million de tokens

Le coût est sans doute le facteur le plus critique lors du choix d'une solution d'embedding. Bien que le calcul des coûts des modèles d'IA puisse être complexe, voici une analyse comparative des différentes options :

tagJina API

Le service suit un modèle de tarification basé sur les tokens avec deux niveaux prépayés :

• 20 $pour 1 milliard de tokens (0,02$ par million) - Un tarif d'entrée idéal pour le prototypage et le développement
• 200 $pour 11 milliards de tokens (0,018$ par million) - Un tarif plus économique pour les volumes plus importants

Il est à noter que ces tokens fonctionnent sur l'ensemble de la suite de produits Jina, y compris les lecteurs, les reclasseurs et les classificateurs zero-shot.

tagAWS SageMaker

La tarification SageMaker combine les coûts horaires des instances avec les frais de licence du modèle. En utilisant une instance ml.g5.xlarge :

• Coût de l'instance : 1,408 $/heure (US Est) ou 1,761$/heure (UE Francfort)
• Licence jina-embeddings-v3 : 2,50 $/heure
• Coût horaire total : 3,908-4,261 $ selon la région

Avec un débit moyen de 15 044 tokens/seconde (54,16M tokens/heure), le coût par million de tokens varie de 0,0723 $à 0,0788$.

tagAuto-hébergement avec Kubernetes

Les coûts d'auto-hébergement varient considérablement selon votre choix d'infrastructure. En prenant comme référence l'instance g5.xlarge d'AWS EC2 :

• Coût de l'instance : 1,006 $/heure (US Est) ou 1,258$/heure (UE Francfort)
• Licence jina-embeddings-v3 : 5000 $/trimestre (2,282$/heure)
• Coût horaire total : 3,288-3,540 $ selon la région

À 2 588 tokens/seconde (9,32M tokens/heure), le coût par million de tokens s'élève à 0,352-0,379 $. Bien que le taux horaire soit inférieur à SageMaker, le débit réduit entraîne des coûts par token plus élevés.

Considérations importantes pour l'auto-hébergement :

• Les coûts fixes (licences, infrastructure) continuent indépendamment de l'utilisation
• L'hébergement sur site nécessite toujours des frais de licence et des coûts de personnel
• Les charges de travail variables peuvent avoir un impact significatif sur l'efficacité des coûts

tagPoints clés

L'API Jina s'avère être la solution la plus rentable, même sans tenir compte des temps de démarrage à froid et en supposant un débit optimal pour les alternatives.

L'auto-hébergement peut être pertinent pour les organisations disposant déjà d'une infrastructure robuste où les coûts marginaux des serveurs sont minimes. De plus, l'exploration de fournisseurs cloud autres qu'AWS pourrait offrir de meilleurs prix.

Cependant, pour la plupart des entreprises, en particulier les PME à la recherche de solutions clés en main, l'API Jina offre une efficacité des coûts inégalée.

tagConsidérations sur la sécurité et la confidentialité des données

Lors du choix d'une stratégie de déploiement pour les modèles d'embedding, les exigences en matière de sécurité et de confidentialité des données peuvent jouer un rôle décisif aux côtés des considérations de performance et de coût. Nous proposons des options de déploiement flexibles pour répondre à différents besoins de sécurité :

tagFournisseurs de services cloud

Pour les entreprises travaillant déjà avec les principaux fournisseurs cloud, nos offres sur les places de marché cloud (comme AWS Marketplace, Azure, et GCP) fournissent une solution naturelle pour le déploiement dans les cadres de sécurité préexistants. Ces déploiements bénéficient de :

• Contrôles de sécurité et conformité hérités de votre relation avec le CSP
• Intégration facile avec les politiques de sécurité et les règles de gouvernance des données existantes
• Nécessite peu ou pas de changements aux accords de traitement des données existants
• Alignement avec les considérations de souveraineté des données préexistantes

tagAuto-hébergement et déploiement local

Les organisations ayant des exigences de sécurité strictes ou des obligations réglementaires spécifiques préfèrent souvent un contrôle physique complet sur leur infrastructure. Notre option d'auto-hébergement permet :

• Un contrôle total sur l'environnement de déploiement
• Le traitement des données entièrement dans votre périmètre de sécurité
• L'intégration avec les contrôles et la surveillance de sécurité existants

Pour obtenir une licence commerciale pour nos modèles CC-BY-NC, vous devez d'abord obtenir une licence auprès de nous. N'hésitez pas à contacter notre équipe commerciale.

tagService API Jina

Pour les startups et PME cherchant à équilibrer sécurité et commodité par rapport aux coûts, notre service API fournit une sécurité de niveau entreprise sans ajouter de charge opérationnelle :

• Certification SOC2 assurant des contrôles de sécurité robustes
• Conformité RGPD complète pour le traitement des données
• Politique de rétention zéro des données - nous ne stockons ni ne journalisons vos requêtes
• Transmission de données chiffrée et infrastructure sécurisée

Les offres de modèles de Jina AI permettent aux organisations de choisir la stratégie de déploiement qui s'aligne le mieux avec leurs exigences de sécurité tout en maintenant l'efficacité opérationnelle.

tagChoisir votre solution

L'organigramme ci-dessous résume les résultats de tous les tests empiriques et tableaux que vous avez vus :

Commencez par considérer vos besoins en sécurité et la flexibilité que vous pouvez sacrifier pour les satisfaire.

Ensuite, considérez comment vous prévoyez d'utiliser l'IA dans votre entreprise :

1. Indexation hors ligne et cas d'utilisation non sensibles au temps qui peuvent utiliser de manière optimale le traitement par lots.
2. Utilisations sensibles à la fiabilité et à l'évolutivité comme la génération augmentée par récupération et l'intégration LLM.
3. Utilisations sensibles au temps comme la recherche et la récupération en ligne.

Considérez également votre expertise interne et l'infrastructure existante :

1. Votre stack technique est-elle déjà fortement dépendante du cloud ?
2. Disposez-vous d'une grande opération IT interne capable d'auto-héberger ?

Enfin, considérez vos volumes de données attendus. Êtes-vous un utilisateur à grande échelle qui prévoit d'effectuer des millions d'opérations utilisant des modèles d'IA chaque jour ?

tagConclusion

L'intégration de l'IA dans les décisions opérationnelles reste un territoire inexploré pour de nombreux départements IT, car le marché manque de solutions clés en main établies. Cette incertitude peut rendre la planification stratégique difficile. Notre analyse quantitative vise à fournir des conseils concrets sur l'incorporation de nos modèles de recherche fondamentaux dans vos flux de travail et applications spécifiques.

En termes de coût unitaire, l'API Jina se distingue comme l'une des options les plus économiques disponibles pour les entreprises. Peu d'alternatives peuvent égaler notre prix tout en offrant des fonctionnalités comparables.

Nous nous engageons à fournir des capacités de recherche qui sont non seulement puissantes et conviviales, mais aussi rentables pour les organisations de toutes tailles. Que ce soit via les principaux fournisseurs cloud ou des déploiements auto-hébergés, nos solutions s'adaptent même aux exigences d'entreprise les plus complexes qui vont au-delà des simples considérations de coût. Cette analyse décompose les différents facteurs de coût pour aider à éclairer votre prise de décision.

Étant donné que chaque organisation a ses propres exigences uniques, nous reconnaissons qu'un seul article ne peut pas couvrir tous les scénarios. Si vous avez des besoins spécifiques non couverts ici, n'hésitez pas à nous contacter pour discuter de la meilleure façon de soutenir votre mise en œuvre.