Inférence d'IA distribuée : ce que les opérateurs de télécommunications doivent savoir

Tous les opérateurs de télécommunications mettent actuellement en œuvre l'IA. Les cas d'utilisation incluent les robots de service client, les copilotes d'exploitation réseau et les solutions AIaaS (AI-as-a-service) gérées pour les clients d'entreprise externes et d'autres. 

L'aspect délicat réside dans la corrélation entre le cas d'utilisation et l'analyse de rentabilité, où le facteur clé est le coût de l'accélérateur d'IA, qu'il s'agisse d'un processeur graphique (GPU), d'une unité de traitement de tenseur (TPU) ou d'un processeur neuronal (NPU). Le coût par inférence détermine si ces accélérateurs d'IA améliorent ou érodent les marges bénéficiaires ; pour limiter les coûts, le modèle d'IA sélectionné est aussi important que la manière dont vous le déployez et le servez à une échelle géographique distribuée.

Dans un article récent, des collaborateurs de Red Hat se sont penchés sur les défis de déploiement de l'inférence en tant que problème d'architecture défini par le trafic et l'échelle, et pas seulement par la taille du modèle. Cet article de blog résume leurs conclusions.

Effets du coût par inférence sur les profits et pertes

Chaque requête d'IA comporte deux tâches distinctes, sur le même matériel : 

• Elle commence par lire l'invite ou l'entrée, qu'il s'agisse d'un historique de facturation, d'un ticket d'incident, d'un journal réseau ou de tout autre élément à traiter. 
• Elle génère ensuite la réponse à cette entrée, un token à la fois.

La phase de lecture détermine le temps d'attente de l'utilisateur pour le premier mot ; la phase d'écriture détermine si la conversation est fluide ou si elle présente des interruptions fréquentes. Les deux phases nécessitent des profils de ressources et des optimisations différents et, lorsqu'elles partagent les ressources de l'accélérateur d'IA, elles entrent en concurrence.

Cette tension affecte les profits et pertes différemment selon les cas d'utilisation de l'IA et les types de charges de travail. Par exemple, avec les chatbots de service client, le coût de l'assistance par contact augmente lorsque les robots s'interrompent et que les sessions sont transférées à des agents. Les offres d'IA pour les entreprises encourent des pénalités liées aux contrats de niveau de service (SLA) lorsqu'elles ne respectent pas les engagements de latence. La marge sur les produits d'IA B2B s'érode lorsque le coût par requête dépasse le prix prévu au contrat. 

La plupart des erreurs de déploiement sont des erreurs de compromis et surviennent lorsqu'une équipe optimise un indicateur qui ne correspond pas à la valeur vendue par son produit. L'examen de certaines manières spécifiques dont l'IA génère des revenus peut illustrer le déploiement approprié pour chaque type de charge de travail.

Service client

Le service client est le cas le plus parlant. Le trafic du service client consiste en des milliers de sessions de chat courtes et simultanées qui réutilisent les mêmes informations tarifaires et de politique dans chaque appel. Les collaborateurs de Red Hat ont pu identifier les points suivants à partir des tests de performance vLLM de Red Hat :

• Le fractionnement et le dimensionnement correct des pools de lecture et d'écriture ont permis de réduire les coûts de 25 à 40 % pour ce profil de trafic.
• Le routage sensible au cache, l'approche d'ordonnancement mise en œuvre par le projet open source llm-d, a permis de générer deux à trois fois plus de tokens par GPU et de diviser par trois à cinq le coût par token lorsque la réutilisation des invites est élevée.

Les systèmes de production ne connaîtront pas ce niveau d'amélioration, mais la tendance s'est confirmée pour chaque charge de travail mesurée. Avec des dizaines de millions d'interactions d'assistance par mois, réduire les coûts d'inférence de seulement quelques points peut permettre d'économiser suffisamment pour financer le prochain cycle de produit sans nouvelles dépenses d'investissement (CapEx) en accélérateurs.

Exploitation réseau

L'exploitation réseau présente un profil opposé : il y a peu d'utilisateurs et les documents traités sont très longs. L'analyse d'incident relit constamment les mêmes runbooks, enregistrements de topologie et manuels de fournisseurs ; le principal levier de coût consiste donc à mettre en cache ce qui a déjà été traité. Le résultat est un délai de diagnostic plus court et moins de transferts vers des ingénieurs seniors.

IA gérée vendue aux entreprises

La vente d'IA aux entreprises ajoute un troisième profil : de nombreux clients, des SLA à plusieurs niveaux et une demande irrégulière. Deux mécanismes peuvent protéger la marge dans ces scénarios :

• Le modèle en cascade envoie les requêtes courantes vers un petit modèle et ne transfère que les plus complexes, ce qui réduit les coûts de cluster de 40 à 60 % lorsque les requêtes simples dominent.
• Le contrôle d'admission lié aux objectifs de niveau de service (SLO) rejette les requêtes qui enfreindraient un SLA au lieu de les mettre en file d'attente jusqu'à l'échec, ce qui protège la crédibilité du contrat en cas de charge.

Comme l'indique le tableau 1, ces trois cas d'utilisation peuvent servir de modèle pour les niveaux de tarification or, argent et bronze, au lieu de forcer les clients à parier sur un seul pool d'accélérateurs d'IA partagé. Toutefois, deux contraintes supplémentaires complètent le tableau pour les opérateurs de télécommunications et illustrent la manière dont les services d'IA peuvent être adaptés à des clients spécifiques. 

IA souveraine avec capacité de cloud bursting

Les règles de souveraineté exigent que les données des abonnés restent dans leur pays d'origine. Le modèle qui répond le mieux à ce besoin est une infrastructure de référence sur site conforme aux exigences réglementaires avec un cloud bursting qui reste inactif entre les pics. Un plan de contrôle unique tel que Red Hat OpenShift AI maintient les deux environnements alignés de sorte que la conformité ne dépende pas uniquement de la rigueur de la configuration.

Edge computing

S'agissant de la périphérie du réseau, avec environ 100 sessions simultanées ou moins, la bonne réponse est un modèle par accélérateur sans mise en commun complexe.  Les requêtes complexes doivent être transmises via le réseau de collecte de sorte que les dépenses de transport suivent la complexité plutôt que le volume.

Tableau 1. Comment les types de charges de travail mènent à des résultats commerciaux concrets

Voici les questions que les fournisseurs doivent se poser lorsqu'ils envisagent chacun de ces cas d'utilisation :

• Service client : Quel est le coût actuel d'une conversation d'assistance entièrement automatisée, et quel changement unique fait le plus varier ce chiffre ? Une bonne réponse cite le coût par contact traité mesuré sur le trafic réel, avec un levier testé et ses chiffres avant et après.
• Exploitation réseau : Combien de temps un ingénieur attend-il pour obtenir une réponse utile à partir des enregistrements d'incident, et les mêmes documents sont-ils retraités à chaque fois ? Une bonne réponse montre la fréquence à laquelle les runbooks et les enregistrements de site sont récupérés depuis le cache plutôt que relus, ainsi que la tendance du délai de première réponse.
• Services B2B : Quel SLA d'entreprise cède en premier en cas de pic de charge, et la solution réside-t-elle dans davantage de matériel ou un meilleur routage ? Une bonne réponse identifie le niveau critique lors d'un test de charge et montre qu'une solution de routage ou d'admission a été tentée avant une demande d'achat.
• Souveraineté et pics : Quelle capacité reste inutilisée entre les pics de demande uniquement pour satisfaire aux règles de résidence des données ? Une bonne réponse indique l'utilisation de base et une architecture permettant un débordement sans coût en dehors des périodes de pointe.
• Périphérie et terrain : Quelle part des requêtes sur le terrain remonte vers un cluster central, et quel est le coût de ce transport ? Une bonne réponse indique le taux de résolution local par site, le transfert étant réservé aux requêtes que le modèle sur site ne peut pas traiter.

Parcours d'investissement

Une fois qu'un cas d'utilisation de l'IA a été établi, l'étape suivante consiste à le construire de manière efficace et rentable. L'ordre importe plus que la destination. Chaque étape est déclenchée par une mesure, et non par une date de feuille de route, et chacune est rentabilisée avant que la suivante ne commence :

1. Commencer par un nœud : Exécutez une seule instance de service sur du trafic réel, assistance ou réseau, pendant une semaine. Cette base de référence sert de mesure pour chaque décision ultérieure ; le trafic de laboratoire synthétique sera trompeur.
2. Ajouter le routage intelligent : Une deuxième réplique fournit moins de 1,8 fois le débit d'une seule. Cet écart signifie que les requêtes arrivent sur des serveurs qui doivent relire un contexte qu'un autre serveur possède déjà. Il s'agit d'un gaspillage de routage et non d'un manque de capacité ; corrigez donc ce problème avant d'acheter du matériel.
3. Séparer les pools de lecture et d'écriture : Ne le faites que lorsque les mesures montrent qu'une phase prive l'autre de ressources au point de justifier la complexité opérationnelle ajoutée.
4. Adopter la grille multiclient : Lorsque plusieurs produits et clients B2B partagent la plateforme, les mécanismes qui protègent les SLA à plusieurs niveaux justifient leur complexité. En dessous de cette échelle, ils représentent un effort inutile.

Chaque étape réinitialise la base de référence ; la stratégie d'inférence d'IA est une série de paris mesurés, et non une validation d'architecture ponctuelle. Les opérateurs de télécommunications appliquent déjà cette méthode avec le spectre sans fil : allouer de la capacité aux produits qui offrent un retour sur investissement (ROI), mesurer en continu et récupérer ce qui reste inutilisé. Les accélérateurs d'IA méritent la même rigueur.

Conclusion

L'inférence d'IA distribuée détermine si les produits d'IA des opérateurs de télécommunications conservent leur marge. Rien de ce qui a été exposé dans cet article de blog n'exige un engagement budgétaire risqué : chaque mécanisme est une étape mesurée qui fait ses preuves sur le trafic du opérateurs de télécommunications avant que la suivante ne commence, et le tableau 1 indique où regarder en premier.

Lorsque vous serez prêt à mettre cela en œuvre pour votre portefeuille de services client, réseau ou B2B, présentez vos données de trafic à votre équipe de compte Red Hat. vLLM, llm-d et Red Hat OpenShift AI sont les outils avec lesquels nous appliquons ce modèle avec les opérateurs de télécommunications aujourd'hui, et la discussion progresse plus vite lorsqu'elle part de vos besoins plutôt que d'un plan générique.