LLM indisponible dans votre région ? Découvrez comment Snowflake révolutionne l’inférence interrégionale !

La disponibilité régionale des modèles de langage de grande taille (LLMs) peut offrir un avantage concurrentiel significatif. Plus les entreprises ont un accès rapide, plus elles peuvent innover rapidement. Celles qui doivent attendre risquent de prendre du retard.

Cependant, le développement de l’IA progresse si rapidement que certaines organisations n’ont d’autre choix que de patienter jusqu’à ce que les modèles soient accessibles dans leur région, souvent en raison de défis liés aux ressources, de biais centrés sur l’Occident et de barrières multilingues.

Pour surmonter cet obstacle majeur, Snowflake a annoncé aujourd’hui la disponibilité générale de l’inférence interrégionale. Grâce à un simple paramètre, les développeurs peuvent traiter des demandes sur Cortex AI dans une autre région, même si un modèle n’est pas encore disponible dans leur région d’origine. De nouveaux LLMs peuvent être intégrés dès qu’ils sont disponibles.

Les organisations peuvent désormais utiliser des LLMs de manière privée et sécurisée aux États-Unis, dans l’UE et dans la région Asie-Pacifique et Japon (APJ) sans frais supplémentaires de sortie de données.

« L’inférence interrégionale sur Cortex AI vous permet de vous intégrer sans effort au LLM de votre choix, quelle que soit sa disponibilité régionale », explique Arun Agarwal, responsable des initiatives de marketing produit IA chez Snowflake, dans un article de blog de l’entreprise.

Traverser les régions en une seule ligne de code

Pour permettre la traversée des données, l’inférence interrégionale doit d’abord être activée — les paramètres sont désactivés par défaut — et les développeurs doivent spécifier les régions pour l’inférence. Agarwal précise que si les deux régions fonctionnent sur Amazon Web Services (AWS), les données traverseront ce réseau mondial de manière privée et resteront sécurisées grâce à un cryptage automatique au niveau physique.

Si les régions concernées sont sur différents fournisseurs de cloud, le trafic traversera Internet public via un transport sécurisé par un protocole de sécurité de transport mutuel (MTLS). Agarwal a noté que les entrées, sorties et invites générées par le service ne sont pas stockées ni mises en cache ; le traitement de l’inférence se produit uniquement dans l’interrégion.

Pour exécuter l’inférence et générer des réponses dans le périmètre sécurisé de Snowflake, les utilisateurs doivent d’abord définir un paramètre au niveau du compte pour configurer où l’inférence sera traitée. Cortex AI sélectionne ensuite automatiquement une région pour le traitement si un LLM demandé n’est pas disponible dans la région d’origine.

Par exemple, si un utilisateur définit un paramètre sur « AWS_US », l’inférence peut être traitée dans les régions est ou ouest des États-Unis ; ou, si une valeur est définie sur « AWS_EU », Cortex peut diriger vers le centre de l’UE ou le nord-est de l’Asie-Pacifique. Agarwal souligne qu’actuellement, les régions cibles ne peuvent être configurées que dans AWS, donc si l’inférence interrégionale est activée dans Azure ou Google Cloud, les demandes seront toujours traitées dans AWS.

Agarwal évoque un scénario où Snowflake Arctic est utilisé pour résumer un paragraphe. Alors que la région source est AWS U.S. est, la matrice de disponibilité des modèles dans Cortex identifie qu’Arctic n’est pas disponible là-bas. Grâce à l’inférence interrégionale, Cortex dirige la demande vers AWS U.S. ouest 2. La réponse est ensuite renvoyée à la région source.

« Tout cela peut être réalisé avec une seule ligne de code », écrit Agarwal.

Les utilisateurs sont facturés en crédits pour l’utilisation du LLM consommé dans la région d’origine (et non dans l’interrégion). Agarwal a noté que la latence aller-retour entre les régions dépend de l’infrastructure et de l’état du réseau, mais Snowflake s’attend à ce que cette latence soit « négligeable » par rapport à la latence d’inférence des LLMs.