Le Cloud d'inférence d'IA frontalière pour les agents — Byung-Gon (Gon) Chun, FriendliAI

FrançaisالعربيةDeutschEnglishEspañolहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
AAI Engineer
컴퓨터/소프트웨어창업/스타트업AI/미래기술

스크립트

00:00:00Commençons. Bonjour à tous. Merci d'être venus. C'est la fin d'après-midi du dernier jour, donc je l'apprécie vraiment.
00:00:25Je suis Gon, fondateur et PDG de Friendly AI. Aujourd'hui, je veux parler de l'inférence agentique. Je vais d'abord détailler ce qui a changé, pourquoi c'est important et comment nous reconstruisons le cloud d'inférence pour les agents.
00:00:40Avant d'aller plus loin, laissez-moi vous présenter brièvement Friendly AI. Friendly AI est le cloud d'inférence IA de pointe pour les agents.
00:00:50À grande échelle, plus rapide, moins cher et plus fiable. Nous sommes issus d'une équipe de recherche de l'Université nationale de Séoul, et ces racines de recherche nous définissent toujours.
00:01:02Nous sommes l'équipe qui a inventé le lotissement continu, l'optimisation d'inférence devenue une norme industrielle, et nos travaux sur ORCA ont inspiré vLLM, un framework open source très utilisé.
00:01:15Aujourd'hui, nous opérons à l'échelle mondiale, basés à San Francisco avec une équipe à Séoul pour faire passer l'inférence de pointe à l'échelle.
00:01:24Comme vous le savez, 2026 est l'année où les agents passent massivement en production, et c'est porté par la rencontre de deux tendances.
00:01:33Premièrement, les agents connaissent une croissance exponentielle. Ils entraînent une adoption explosive dans le logiciel, les opérations et le travail intellectuel.
00:01:45Deuxièmement, les modèles open weight ont atteint l'état de l'art et rendent les agents rentables. Ils rivalisent en capacités avec les modèles fermés de pointe, permettant d'exécuter des agents très performants sur des modèles ouverts à un coût par token bien moindre.
00:02:00Laissez-moi vous prouver que les modèles open weight sont désormais assez puissants pour ces types de workflows d'agents réels.
00:02:13Ici, nous avons confié exactement la même tâche — créer un jeu de tower defense avec un agent de codage — à deux modèles.
00:02:19À gauche se trouve GLM 5.2, un modèle open weight fonctionnant sur Friendly AI. À droite, Opus 4.8 d'Anthropic.
00:02:29L'important n'est pas que les résultats soient identiques. L'important est que tous deux accomplissent la tâche à un niveau parfaitement exploitable.
00:02:38Pour de nombreux workflows d'agents, les modèles open weight ont franchi le seuil de qualité, mais l'aspect économique est très différent.
00:02:49Pour la même tâche, Opus 4.8 coûte environ 1,50 $. GLM 5.2 sur Friendly AI coûte 0,27 $, soit 5,6 fois moins cher.
00:03:03Voilà la promesse mentionnée plus tôt : les modèles open weight vous offrent des agents de pointe pour une fraction du prix.
00:03:12Mais le coût du modèle n'est qu'un élément. Pour rendre les agents vraiment rapides et fiables, la pile d'inférence elle-même doit évoluer.
00:03:22Examinons donc ce qui se passe réellement dans une charge de travail agentique.
00:03:28Voyons d'abord les changements de cette charge de travail. Auparavant, l'usage dominant était le chat.
00:03:34L'unité de base était la requête. Une personne pose une question, le modèle répond, et la personne lit la réponse.
00:03:41La latence mesurait le temps pour obtenir une réponse. Les agents sont différents : l'unité de base est la tâche.
00:03:49Une tâche peut nécessiter de nombreux appels au modèle, de nombreux appels d'outils et tourner en autonomie un certain temps.
00:03:58L'utilisateur ne se soucie donc pas vraiment de la latence d'une requête individuelle.
00:04:04Ce qui l'importe, c'est le moment où l'ensemble de la tâche est accompli.
00:04:08Cela signifie que nous devons optimiser pour des tâches, et pas seulement pour des requêtes individuelles.
00:04:16Analysons les charges agentiques de plus près. Un agent exécute une session composée de plusieurs tâches.
00:04:23Chaque tâche s'exécute généralement en boucle. D'abord elle planifie, ce qui implique un appel au LLM.
00:04:29Ensuite elle agit, parfois en appelant un outil. Puis elle observe le résultat et l'injecte à nouveau dans le contexte.
00:04:38Et elle répète cela jusqu'à ce que la tâche soit terminée.
00:04:41Nous alternons donc constamment entre l'inférence LLM et l'exécution d'un ou plusieurs outils non-LLM.
00:04:50Il y a donc un intervalle entre les appels LLM. Un agent peut aussi créer des sous-agents et les lancer en parallèle.
00:05:01Les entrées d'un agent diffèrent aussi beaucoup du chat. Ce graphique montre la répartition des longueurs de prompt et de complétion de nos agents de codage internes avec GLM 5.2 au quotidien.
00:05:15Elles sont bien plus longues. Elles croissent au fil de la tâche car chaque observation est ajoutée à la suite du contexte.
00:05:25Un motif important se dégage : des étapes d'agent consécutives partagent souvent un préfixe gigantesque.
00:05:32Si l'on recalcule ce même préfixe à chaque fois, on gaspille énormément de calcul pour un travail déjà effectué.
00:05:40C'est donc l'une des plus grandes opportunités dans l'inférence agentique.
00:05:46À quel point les agents sont-ils gourmands en tokens ?
00:05:49Prenons l'exemple d'une tâche à long terme comme de la recherche approfondie.
00:05:53Nous avons expliqué le framework Speculative Decoding dans vLLM à l'aide de Kilo Code avec GLM 5.2 sur Friendly AI.
00:06:02Il y a plusieurs étapes, chacune composée de sous-agents qui exécutent de multiples inférences et appels d'outils.
00:06:12Cela peut exécuter des dizaines voire des centaines d'étapes d'inférence, parfois sur plusieurs minutes ou heures.
00:06:19Et le contexte partagé ne cesse de grandir tout au long du processus.
00:06:23Pour l'utilisateur, ce qui compte n'est pas la latence d'un seul token ou d'un seul appel.
00:06:28Ce qui compte, c'est : quand ma tâche sera-t-elle terminée ?
00:06:35L'inférence agentique n'est donc pas du simple chat avec plus de requêtes.
00:06:39C'est un problème différent. Le contexte s'élargit avec le temps.
00:06:43L'utilisation d'outils s'intercale entre les appels au modèle.
00:06:46Le nombre d'appels au modèle dépend entièrement de l'entrée.
00:06:49On ne peut donc pas vraiment planifier autour d'un taux fixe de requêtes.
00:06:55Et la vraie métrique est la latence globale de la tâche, pas la latence d'une seule requête.
00:07:02Alors comment s'y prendre ? Laissez-moi vous présenter les principes d'ingénierie clés sous-jacents.
00:07:23Voici l'architecture technique expliquant notre approche.
00:07:27Nous avons construit la pile couche par couche autour des charges de travail agentiques.
00:07:33Il y a quatre piliers majeurs que je vais aborder aujourd'hui.
00:07:37Le préfixe caching, la gestion du cache Key-Value (KV), le routage sensible au cache et l'optimisation orientée agents.
00:07:48Et bien sûr, nous avons besoin en dessous d'optimisations de couche modèle, comme la sparse attention pour les contextes longs,
00:07:56des techniques de réduction d'erreurs, des kernels rapides, un service résilient, et plus encore.
00:08:02Dans cette présentation, je vais me concentrer sur ces quatre piliers.
00:08:05Commençons par le préfixe caching.
00:08:09Puisque les étapes d'un agent partagent un grand préfixe, nous calculons la valeur KV du préfixe une fois et la mettons en cache.
00:08:17Lors des étapes suivantes, nous réutilisons la valeur KV en cache et ne traitons que le nouveau suffixe.
00:08:23Lire depuis le cache coûte bien moins cher que de recalculer le préremplissage,
00:08:27ce qui améliore le temps jusqu'au premier token et réduit le calcul à chaque étape.
00:08:33Et plus la tâche de l'agent s'allonge, plus cela devient précieux.
00:08:41Mais la mise en cache ne fonctionne que si le cache KV rentre en mémoire et peut être déplacé efficacement.
00:08:48Nous avons donc besoin d'une gestion solide du cache KV.
00:08:52Nous utilisons une gestion de mémoire de type Google pour compacter plus de contextes actifs dans chaque mémoire GPU.
00:08:59Nous appliquons la quantification KV pour réduire l'empreinte mémoire.
00:09:04Nous exploitons le cache hiérarchique entre mémoire GPU, mémoire hôte et disque pour dépasser les limites des GPU.
00:09:13Nous utilisons aussi le cache distribué pour qu'un préfixe puisse être servi sur plusieurs répliques, pas seulement une instance.
00:09:26À l'échelle d'un cluster mondial, le routage devient crucial.
00:09:29Un équilibreur de charge naïf peut répartir les requêtes équitablement sur les clusters GPU, mais détruire la localité du cache.
00:09:38Un routeur sensible au cache à l'échelle mondiale agit plus intelligemment.
00:09:42Il envoie la requête à un pod disposant déjà du bon préfixe en cache, transformant un préremplissage lourd en simple accès cache.
00:09:51En même temps, il doit équilibrer la charge pour éviter qu'un pod ne devienne un goulot d'étranglement.
00:09:58Dans cet exemple, les deux requêtes de la tâche A vont vers le même pod par souci de localité de cache.
00:10:08L'élément suivant est l'optimisation orientée agents.
00:10:11Et c'est la nouvelle frontière de l'inférence d'agents.
00:10:16Aujourd'hui, la plupart des systèmes planifient chaque appel LLM comme s'il était indépendant.
00:10:21Ils ne comprennent pas vraiment que cet appel fait partie d'un programme d'agent plus vaste.
00:10:27Mais si l'optimiseur connaît le contexte au niveau de l'agent, il peut prendre de meilleures décisions.
00:10:33Par exemple, interrompre la bonne tâche, préremplir spéculativement le contexte d'une étape suivante probable ou mieux évincer le cache.
00:10:48L'objectif est de réduire la latence globale de la tâche, pas seulement de rendre un appel rapide en apparence.
00:10:58En combinant tous ces éléments, voici le résultat.
00:11:01Nous utilisons le même modèle, GLM 5.2, avec Kilo Code pour créer un jeu mobile simple.
00:11:07Nous avons exécuté la même tâche avec les API modèles de Friendly AI et d'un autre fournisseur d'inférence réputé.
00:11:14Comme vous le voyez, Friendly AI accomplit la tâche plus vite de bout en bout grâce à notre cloud pensé pour les agents.
00:11:24Qu'est-ce que cela permet de débloquer en pratique ?
00:11:29Une pile d'agents plus solide en production.
00:11:32Prenez un agent que vous appréciez déjà.
00:11:35Brancher des modèles open weight de pointe comme GLM 5.2, Minimax et Kimi hébergés sur Friendly AI.
00:11:43Le modèle vous offre des capacités de niveau état de l'art et une meilleure rentabilité.
00:11:49Friendly AI vous apporte la vitesse, la fiabilité et la performance globale nécessaires en production.
00:11:56Cette combinaison de qualité, vitesse, fiabilité et coût rend les agents réellement utiles et économiques en production.
00:12:06Friendly AI propulse aujourd'hui des équipes en production, des startups pure-player IA aux entreprises mondiales.
00:12:15J'aimerais en mettre deux en avant.
00:12:20Kilo est un outil de codage IA agentique très populaire servant des millions d'utilisateurs.
00:12:27LG est un groupe mondial dont les activités vont de l'électronique à la santé en passant par l'énergie.
00:12:35Des entreprises très différentes, mais ayant toutes le même besoin.
00:12:39Une inférence agentique rapide, fiable et économique.
00:12:45Ce témoignage de notre client Kilo résume tout.
00:12:50Au cours de l'année écoulée, Kilo Code a testé plusieurs fournisseurs d'inférence hébergeant des modèles ouverts et fermés.
00:12:56Lors d'un test comparatif de GLM 5 face à d'autres fournisseurs tiers et à l'usage direct du laboratoire G.AI,
00:13:05Friendly AI s'est révélé régulièrement sept fois plus rapide avec un taux d'erreur nettement inférieur.
00:13:12Aujourd'hui, Friendly AI est un composant clé de la pile de Kilo.
00:13:17Et vous pouvez l'utiliser selon la formule qui s'adapte à votre pile.
00:13:23L'API Modèle est le moyen le plus rapide de commencer.
00:13:26Les principaux modèles open weight de pointe via notre API serverless.
00:13:29Les endpoints dédiés vous offrent un déploiement isolé avec des SLA garantis pour vos charges de production.
00:13:36Et le BYOG (apportez votre propre GPU) vous permet d'exécuter Friendly AI sur votre propre infrastructure.
00:13:44La même pile, trois façons de la déployer.
00:13:49Pour conclure, voici trois points à retenir.
00:13:53D'abord, les modèles open weight de pointe rendent les agents en production soutenables économiquement.
00:13:59Ensuite, les agents ne se résument pas à du chat avec plus d'appels.
00:14:03L'inférence agentique exige d'optimiser la latence globale des tâches en relevant les défis évoqués.
00:14:10Enfin, Friendly AI est conçu comme un cloud d'inférence taillé pour ce monde.
00:14:16Une inférence agentique rapide, fiable et rentable.
00:14:23Merci d'avoir assisté à ma présentation.
00:14:25Si vous développez des agents, essayez les modèles open weight de pointe sur Friendly AI dès aujourd'hui.
00:14:30Vous pouvez vous lancer sur Friendly AI en quelques minutes.
00:14:34Et merci.
00:14:35Je reste disponible après la session.
00:14:37Merci.
00:14:38Merci.

핵심 요약

L'optimisation de l'inférence pour les agents IA exige de réarchitecturer le cloud autour de la latence globale des tâches grâce au préfixe caching, à la gestion hiérarchique du cache KV et au routage distribué.

하이라이트

  • Les modèles open weight de pointe comme GLM 5.2 réduisent les coûts d'exécution des agents d'un facteur 5,6 par rapport à des modèles fermés comme Opus 4.8 pour une tâche de codage équivalente.

  • FriendliAI est à l'origine du lotissement continu (continuous batching) via les travaux sur ORCA, une innovation d'optimisation devenue une norme industrielle qui a inspiré le framework vLLM.

  • L'inférence pour les agents diffère du chat traditionnel car l'unité de base passe de la requête individuelle à la tâche complète composée de plusieurs boucles d'appels LLM et d'outils.

  • Le réemploi des calculs via le préfixe caching évite de recompiler le contexte accumulé à chaque étape consécutive d'une tâche d'agent.

  • Dans un test comparatif sur l'agent de codage Kilo Code, FriendliAI a obtenu un débit sept fois plus rapide que les autres fournisseurs d'inférence tiers et le laboratoire d'origine du modèle GLM 5.

타임라인

Origines de FriendliAI et émergence des agents en production

  • L'équipe de recherche de l'Université nationale de Séoul à l'origine de FriendliAI a créé le lotissement continu et l'architecture ORCA.
  • L'année 2026 marque le passage massif des agents IA en phase de production commerciale.
  • La convergence entre la croissance des agents et la maturité des modèles open weight transforme l'économie du logiciel.

Les travaux académiques sur ORCA ont jeté les bases des moteurs d'inférence modernes comme vLLM. La montée en puissance des modèles open weight offre désormais des performances comparables aux modèles propriétaires fermés, ce qui permet de déployer des workflows agentiques complexes à un coût d'infrastructure nettement inférieur.

Viabilité économique des modèles open weight pour les agents

  • Le modèle open weight GLM 5.2 exécuté sur FriendliAI accomplit une tâche de développement logiciel pour 0,27 $contre 1,50$ sur Opus 4.8.
  • Les modèles ouverts atteignent un seuil de qualité suffisant pour remplacer les modèles fermés sur les tâches autonomes.

Un test comparatif basé sur la création d'un jeu de tower defense montre que GLM 5.2 et Opus 4.8 génèrent tous deux un résultat directement exploitable. L'écart financier représente une réduction de coût de 82 % en faveur du modèle ouvert hébergé sur une infrastructure optimisée.

Changement de paradigme : de la requête à la tâche

  • L'unité de mesure de la performance passe de la latence d'une requête unique à la durée totale d'accomplissement d'une tâche.
  • Les agents alternent entre génération de texte et exécution d'outils, créant des pauses et des variations de charge imprévisibles.
  • La taille du contexte croît de manière cumulative à mesure que les observations des outils s'ajoutent à l'historique.

Contrairement au chat classique où une interaction se résume à une question et une réponse, un agent exécute une boucle autonome de planification, d'action et d'observation. Les contextes s'étendent sur des dizaines de milliers de tokens partagés entre des étapes successives, ce qui rend la gestion classique du taux de requêtes inadaptée.

Les quatre piliers de l'architecture d'inférence agentique

  • Le préfixe caching réutilise les clés-valeurs déjà calculées pour traiter uniquement le nouveau suffixe à chaque étape.
  • La gestion hiérarchique du cache KV exploite la mémoire GPU, la mémoire hôte et le disque pour dépasser les limites physiques de la VRAM.
  • Le routage mondial dirigé par le cache achemine les requêtes vers les pods GPU qui possèdent déjà les préfixes en mémoire.

L'architecture repose sur quatre axes principaux : la mise en cache des préfixes, l'optimisation mémoire du cache KV (quantification et compactage de style Google), le routage intelligent préservant la localité des données, et une planification consciente du contexte global de l'agent. Ces mécanismes évitent les re-calculs coûteux lors de la phase de préremplissage (prefill).

Résultats en production et options de déploiement

  • FriendliAI réduit le temps d'exécution complet des tâches de développement sur des outils comme Kilo Code.
  • L'infrastructure est déployable via API Serverless, endpoints dédiés ou sur propre matériel via la formule BYOG (Bring Your Own GPU).
  • Kilo Code enregistre une vitesse d'exécution sept fois supérieure à celle des autres hébergeurs de modèles.

L'implémentation de la pile sur des cas d'usage réels montre des gains de vitesse significatifs sur des projets d'ingénierie logicielle autonome. Des organisations allant des startups aux grands groupes comme LG exploitent ces modèles via trois modes de déploiement adaptés aux contraintes de sécurité et de volume de chaque entreprise.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기