Ancienne membre d’Harvard, la Dr Jenny Shao, a abandonné sa carrière médicale pour lancer Robyn, une application d’intelligence artificielle à visée émotionnelle qui s’adresse principalement aux personnes en quête de soutien intérieur. Shao a en effet constaté pendant la pandémie de Covid-19 les effets neurologiques de l’isolement, une …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)

L’article Robyn, l’IA empathique conçue par une ancienne médecin de Harvard est apparu en premier sur KultureGeek.

Vous voulez utiliser Ollama sur votre iPhone ou Android pour lancer vos petits LLM en local ? Ce serait super cool non ? Bah j’ai une mauvaise nouvelle pour vous… votre smartphone n’a pas assez de mémoire vive pour faire ça…

Le problème est simple… les LLM bouffent un max de RAM. Par exemple, un LLaMA 7B, c’est dans les 12 GB de RAM. Et même quantifié en int4 pour gagner de la place, vous tombez à environ 3,5 GB. Et ça, c’est juste le modèle hein… Faut y ajouter le contexte, l’OS, les autres apps, et votre smartphone à 8 GB de RAM commence à suer de la raie.

Google a bien sûr sorti Gemini Nano pour Android, leur petit LLM optimisé pour mobile mais c’est compatible avec une poignée de smartphone car il faut un NPU dédié, assez de RAM, et une architecture très récente. Les autres, vous irez vous faire voir…

Du coup, une solution “pragmatique”, c’est de laisser votre Mac, votre PC, ou un petit serveur faire tourner Ollama chez vous, et d’utiliser votre smartphone comme simple client pour vous y connecter à distance. Vous gardez vos données locales, vous profitez de toute la puissance des modèles lourds, et votre iPhone ne chauffe pas comme un radiateur.

Et pour ça, il existe tout un tas d’apps mobiles qui font office de client Ollama. Des apps comme Enchanted sur iOS, My Ollama , Heat , et même les solutions cross-platform comme Ollamb codé en Flutter. Et aujourd’hui, je vous parle de Reins , une app développée par Ibrahim Cetin qui se démarque par des fonctionnalités que j’ai trouvées bien pensées.

Les fonctionnalités sont conçues pour des cas d’usage du monde réel. Vous pouvez ainsi définir un prompt system différent par conversation ce qui est pratique si vous avez un chat pour le code, un pour l’écriture, un pour la traduction et j’en passe… Vous éditez et régénérez les prompts à la volée et vous pouvez changer de modèle en cours de conversation sans tout perdre.

Reins supporte également l’envoi d’images, ce qui est utile si vous utilisez un modèle vision comme LLaVA. Vous pouvez aussi tweaker les paramètres avancés tels que la température, seed, taille du contexte, tokens max…etc. Et le streaming fonctionne en temps réel, comme ça pas besoin d’attendre une réponse complète avant de la voir.

Bien sûr, la question de la sécurité se pose. Il faut quand même exposer votre serveur Ollama sur Internet pour y accéder de l’extérieur donc pensez HTTPS obligatoire, tunnel ngrok temporaire si vous testez, VPN Tailscale ou Wireguard si vous voulez du permanent et sécurisé. Bref, les précautions classiques.

Vous pouvez télécharger Reins sur l’App Store, en APK ou récupérer les builds macOS/Linux sur GitHub .

Merci à Lorenper pour l’info.

Bon vous savez tous comment marche votre antivirus. Il détecte un malware, il le bloque, et tout revient à la normale.

Mais si je vous disais que maintenant, c’est parfaitement possible qu’une heure plus tard le même malware se repointe, sauf que c’est plus le même, parce que son code a changé. Car entre temps, il a demandé à Google Gemini de le réécrire…

Bien c’est pas de la science-fiction, hein, c’est ce que décrit un rapport du Google Threat Intelligence Group (GTIG) qui nous présente une nouvelle génération de malwares qui intègrent des LLM directement dans leur exécution.

Plus de génération statique du code, c’est le malware lui-même qui appelle une API LLM pendant qu’il tourne, demande des modifications, se réécrit, et repart faire sa besogne.

Les deux exemples les plus marquants s’appellent PROMPTFLUX et PROMPTSTEAL .

PROMPTFLUX, c’est un dropper en VBScript qui appelle l’API Gemini pour obfusquer son propre code. Il se réécrit dans la base de registre Windows pour persister au reboot, puis demande à Gemini de générer de nouvelles variantes d’obfuscation. Son module interne s’appelle “Thinking Robot” et il interroge Gemini régulièrement du genre “Comment contourner l’antivirus X ? Propose des variantes de mon code pour éviter la signature Y.”

Gemini lui répond, le malware applique le conseil, se modifie, et se relance.

Comme les antivirus détectent les malwares par signatures ou comportements connus, si le malware change toutes les heures, les signatures deviennent immédiatement obsolètes. L’antivirus a alors toujours un coup de retard. Et PROMPTFLUX n’a même pas besoin d’un serveur C2 pour télécharger de nouvelles variantes puisqu’il génère ses propres variantes localement en demandant à Gemini.

GTIG estime que PROMPTFLUX est encore en développement et les échantillons analysés ne montrent pas de capacité réelle à compromettre un réseau. Mais ça reste une preuve de concept active… En gros, quelqu’un, quelque part teste cette approche.

PROMPTSTEAL, lui par contre, est déjà opérationnel. GTIG l’attribue à APT28 (FROZENLAKE), un groupe lié au renseignement militaire russe (GRU). Le CERT-UA l’a documenté sous le nom LAMEHUG en juillet dernier et c’est la première observation d’un malware qui interroge un LLM en opération réelle.

PROMPTSTEAL de son côté est écrit en Python. Il utilise l’API Hugging Face pour accéder au modèle Qwen2.5-Coder-32B-Instruct . Le malware envoie des prompts encodés en Base64, genre “récupère les infos système” ou “trouve les documents sensibles” et le LLM génère des commandes Windows d’une ligne qui sont ensuite exécutées localement par le malware. Ensuite ce dernier collecte les données et les exfiltre tranquillement.

L’astuce donc, c’est que le malware ne contient plus de commandes en dur. Il les génère à la volée selon le contexte comme ça, si l’environnement change, il demande de nouvelles commandes adaptées. Plus de pattern fixe à détecter et chaque exécution est différente.

GTIG mentionne aussi d’autres exemples tels que FRUITSHELL, un reverse shell PowerShell public qui contient des prompts pour contourner les protections LLM ou encore PROMPTLOCK, un concept de ransomware en Go qui utilise un LLM pour générer des scripts Lua de chiffrement.

Il y a aussi QUIETVAULT, un voleur de tokens JavaScript qui cible GitHub et NPM, puis exfiltre les résultats via des repos publics.

Tous ces malwares partagent la même idée : intégrer un LLM dans la chaîne d’exécution. Génération, obfuscation, commandes dynamiques, recherche de secrets… Le LLM devient un composant actif du malware !

Le rapport décrit aussi comment les attaquants contournent les protections des LLM à base d’ingénierie sociale dans les prompts. L’attaquant se fait passer le plus souvent pour un étudiant en sécurité, un participant à un CTF, ou encore un chercheur parfaitement légitime. Le LLM, configuré pour aider, répond alors à toutes les demandes.

Dans un cas documenté par GTIG, une tentative a mal tourné pour les attaquants. On le sait car dans les logs de leurs échanges avec le LLM, GTIG a trouvé des domaines C2 et des clés de chiffrement en clair. Les attaquants avaient oublié de nettoyer leurs tests et c’est grâce à ça que GTIG a récupéré l’accès à leur infrastructure puis l’a neutralisée.

Le rapport liste aussi les groupes étatiques actifs comme UNC1069 (MASAN) , lié à la Corée du Nord, qui utilise les LLM pour générer des deepfakes et voler des cryptoactifs. Ou encore UNC4899 (PUKCHONG) , aussi nord-coréen, qui emploie les modèles pour développer des exploits et planifier des attaques sur les supply chains.

De son côté, APT41 , un groupe étatique chinois, s’en sert pour obfusquer du code. Et le groupe iranien APT42 , a même tenté de construire un agent SQL qui traduirait des requêtes en langage naturel vers des commandes d’extraction de données sensibles. GTIG les a bloqué en coupant les comptes qu’ils utilisaient.

Et sur le marché noire, ce genre d’outils et de services multi-fonctions ont le vent en poupe. Génération de campagne de phishing, création de deepfakes, génération automatique de malwares, abonnements avec accès API…etc.

Leur modèle commercial copie celui des services légitimes avec une version gratuite basique pour gouter et un abonnement payant pour les fonctions avancées, avec des communautés Discord pour le support. Ça permet d’abaisser la barrière d’entrée pour les attaquants les moins expérimentés.

Côté défense maintenant, les recommandations sont assez classiques. Pensez à surveiller l’activité anormale des clés API qui pourraient être volées. Détectez les appels inhabituels à des services LLM externes depuis les processus. Contrôlez l’intégrité des exécutables et protégez tout ce qui est “secrets” sur les hôtes.

N’oubliez pas non plus de ne jamais, ô grand jamais, exécuter aveuglément des commandes générées par un modèle IA (je vous l’ai assez répété).

Voilà, tous ces exemples actuels sont expérimentaux mais le signal est donné et il est plutôt limpide : l’IA est en train de rendre les malwares plus virulents en leur permettant de s’adapter !

Source

Vous avez installé Ollama sur votre Mac et vous êtes le plus joyeux de tous les mammifères car vous faites tourner Llama 3.x en local comme un chef. Et puis un soir, posé dans votre canapé avec votre iPad de bourgeois capitaliste, vous vous dites que ce serait bien de pull un nouveau modèle. Et là, vous réalisez qu’il va falloir sortir le MacBook, ouvrir un terminal, taper ollama pull mistral, attendre et attendre… Grosse flemme non ?

Hé oui, Ollama reste un outil en ligne de commande. C’est génial pour les devs, mais galère pour le reste et vous avez beau avoir de la puissance de calcul dans votre poche avec un iPhone ou un iPad, c’est impossible de gérer vos modèles sans SSH et sans Terminal.

Heureusement, MocoLlamma vient combler ce fossé. C’est une app de gestion Ollama pour macOS, iOS, iPadOS, et même visionOS si vous avez ce truc. C’est donc une vraie app native avec interface graphique, développée en Swift et SwiftUI dans laquelle ous ajoutez vos serveurs Ollama, et où vous gérez vos modèles, et vous testez vos LLM via un chat basique.

L’app s’organise autour de trois onglets. Le premier, Server, vous permet d’ajouter et de switcher entre plusieurs serveurs Ollama. Vous pouvez ainsi renommer chaque serveur, gérer les connexions, bref, tout ce qu’il faut pour jongler entre votre Mac local, votre serveur, ou votre instance cloud si vous en utilisez une.

Le second onglet, Model, affiche tous les modèles disponibles sur le serveur sélectionné. Vous voyez ainsi les infos de chaque modèle, vous pouvez les trier par taille, les ajouter ou les supprimer. Comme ça, plus besoin de taper ollama list pour savoir ce qui tourne. Tout est là, visuellement, avec la possibilité de gérer vos modèles d’un tapotage bien senti.

Le troisième onglet, Chat, permet de tester rapidement un modèle. C’est volontairement basique et l’idée n’est pas de remplacer ChatGPT ou Open WebUI, mais juste de vérifier qu’un modèle répond correctement. Genre, vous venez de pull Qwen 3, et vous voulez voir s’il fonctionne avant de l’intégrer dans votre workflow. Hop, quelques questions rapides dans le chat, et vous savez.

Il existe bien sûr des tonnes d’alternatives de GUI pour Ollama comme Open WebUI , LM Studio , Jan , GPT4All … Mais aucune ne supporte nativement visionOS ou les iPad / iPhone. Alors que MocoLlamma, si.

C’est actuellement la seule app qui vous permet de gérer vos LLM locaux depuis ces appareils Apple… C’est assez niche c’est vrai mais ça peut rendre service.

Le nom “MocoLlamma” est ce qu’on appelle un mot valise de “Model”, “Control”, “Ollama”, et “Manage”. C’est moche de ouf, c’est pas super à retenir, mais au moins ça décrit exactement ce que fait l’app.

Y’a la version gratuite qui est disponible sur GitHub, mais uniquement pour macOS (c’est sous license MIT) et la version payante, à 1,99 dollars sur l’App Store, supporte macOS, iOS, iPadOS, et visionOS. La différence principale pour l’app macOS c’est surtout les mises à jour automatiques. Vous payez 2 balles pour le confort.

Et là, un point crucial, sachez que MocoLlamma ne collecte AUCUNE donnée utilisateur. Bref, cette appli vient combler le trou qui se trouve entre “j’ai installé Ollama” et “je peux gérer mes modèles depuis mon iPhone”. Si vous avez ce besoin, c’est donc à considérer.

Merci à Lorenper pour la découverte.

Faire tourner un modèle de langage européen sur votre machine sans avoir besoin d’un serveur surpuissant branché sur une centrale nucléaire, c’est maintenant possible, les amis ! Hé oui, EuroLLM vient de prouver qu’on pouvait faire tourner un modèle à 9 milliards de paramètres dans un peu moins de 6 GB de RAM sur un simple laptop.

Une seule commande Ollama , et c’est parti mon kiki !!!

Bien sûr, il est encore loin des gros modèles proprio comme GPT-5 mais c’est le enfin le premier LLM européen que VOUS pouvez faire tourner en local. C’est respectueux de votre vie privée, des droits d’auteurs et c’est gratuit !

Un projet 100% européen

EuroLLM, c’est en réalité une coalition de labos européens : Instituto Superior Técnico (Lisbonne), University of Edinburgh , Université Paris-Saclay , Unbabel , et d’autres et c’est financé par Horizon Europe et l’ EuroHPC , et ce modèle supporte les 24 langues officielles de l’UE, plus 11 langues supplémentaires (arabe, chinois, hindi, japonais, coréen, russe, turc…).

EuroLLM-9B , le modèle de base, a été entraîné sur 4 trillions de tokens avec le supercalculateur MareNostrum 5 à Barcelone (400 GPUs Nvidia H100) et l’architecture utilise du Grouped Query Attention, RoPE, SwiGLU et RMSNorm, comme tout LLM moderne qui se respecte.

Mais il existe d’autres versions comme EuroLLM-1.7B pour smartphones et bientôt EuroLLM-22B pour plus de puissance, ainsi qu’une version vision-language (EuroVLM-9B) et un modèle Mixture-of-Experts (EuroMoE-2.6B).

Et surtout c’est sous licence Apache 2.0. Donc l’usage commercial est autorisé, vous pouvez le fine-tuner sur vos données, et les modifications sont libres, sans redevance à payer. Ce n’est pas la première fois qu’il y a des LLM européens mais ils étaient soit sous licence trop restrictives ou un peu trop lourd pour être utilisé localement par les gens normaux comme vous et moi.

Maintenant comment l’installer ?

La méthode la plus simple, c’est via Ollama :

ollama run hf.co/bartowski/EuroLLM-9B-Instruct-GGUF

from transformers import AutoTokenizer, AutoModelForCausalLM

model_name = "utter-project/EuroLLM-9B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

inputs = tokenizer("Explique-moi ce qu'est un LLM en français simple", return_tensors="pt")
outputs = model.generate(**inputs, max_length=200)
print(tokenizer.decode(outputs[0]))

ollama run cas/eurollm-1.7b-instruct-q8

Les chercheurs d’Andon Labs, réputés pour leurs expériences loufoques mêlant robots et intelligence artificielle, ont encore frappé. Après avoir confié la gestion d’un distributeur automatique à un modèle d’IA, ils ont cette fois équipé un simple robot aspirateur de plusieurs grands modèles de langage (LLM) — parmi lesquels …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)

L’article Des robots-aspirateur embarquent des IA de type LLMs… et piquent une « crise de nerf numérique » ! est apparu en premier sur KultureGeek.

Au-delà du modèle de langage, il y a l’architecture.

On retiendra volontiers cet aspect des travaux que Lingua Custodia a menés dans le cadre du Large AI Grand Challenge.

Cette compétition s’est inscrite dans le projet européen AI-BOOST, censé en organiser 6 autres à l’horizon 2027 pour encourager l’innovation scientifique ouverte dans le domaine de l’IA. L’UE l’a doté pour cela d’une enveloppe de 4 M€.

3,2 millions d’heures GPU sur deux supercalculateurs EuroHPC

Le Large AI Grand Challenge avait été lancé en novembre 2023. Le contrat, dans les grandes lignes : développer, en partant de zéro, un LLM de fondation d’au moins 30 milliards de paramètres « plus performant que les systèmes à l’état de l’art sur un certain nombre de tâches ». Les lauréats recevraient chacun un prix de 250 000 € et 2 millions d’heures GPU sur un supercalculateur EuroHPC (LUMI, localisé en Finlande, ou LEONARDO, situé en Italie).

Des lauréats, il y en eut 4 (sur 94 dossiers), annoncés en juin 2024. Nommément, Textgain (Belgique), Tilde (Lettonie), Unbabel (Portugal)… et donc Lingua Custodia.
La PME francilienne – petite entreprise selon les seuils du Code de commerce – a choisi l’option LEONARDO. Fin 2024, elle a obtenu une allocation additionnelle de 1,2 million d’heures sur un autre supercalculateur EuroHPC : JUPITER, qui se trouve en Allemagne.

Nouvelle architecture… et nouvelle marque commerciale

Dans l’absolu, le premier modèle issu de ces travaux ne respecte pas le contrat : il ne compte « que » 3,6 milliards de paramètres. Il ne s’agit, par ailleurs, que d’un modèle dit « de base ». C’est-à-dire non affiné pour, par exemple, le dialogue ou le suivi d’instructions. Et donc non utilisable comme tel en production. Il faut néanmoins le voir comme un démonstrateur de la véritable valeur ajoutée : une architecture alternative à Transformers. Son nom : Dragon. Avec elle, Lingua Custodia change de cap. Ou tout du moins ouvre un nouveau chapitre. Jusque-là, on le connaissait effectivement plutôt pour ses services de traitement documentaire (classification, extraction, traduction, résumé…), fournis tant en SaaS que par API à destination du secteur financier.

Ce changement de cap s’assortit d’un changement de marque commerciale : exit Lingua Custodia, place à Dragon LLM.

Dépasser les limites de Transformers et de Mamba à l’inférence

L’architecture Dragon combine de multiples techniques existantes pour dépasser, en particulier, les limites que le mécanisme d’autoattention de Transformers présente lors de l’inférence. En l’occurrence, une consommation de ressources croissant avec la longueur des séquences (dans l’architecture de base, pour chaque token, le modèle examine tous les tokens précédents). Ces ressources, c’est du compute. Mais aussi de la mémoire, qui en vient à constituer le principal goulet d’étranglement, essentiellement en raison des limites de bande passante.

En réaction, des versions linéaires du mécanismes d’attention ont émergé. Évitant, d’un côté, la croissance quadratique de la consommation de ressources de calcul. Et permettant, de l’autre, l’utilisation d’un budget mémoire fixe. Ce en s’appuyant sur un état caché : une matrice ne conservant pas tous les tokens, mais une forme de « résumé évolutif ».

Cette approche a l’inconvénient de diminuer la précision des modèles. Dans ce contexte est apparue une architecture alternative : Mamba. Elle remplace le composant d’attention par un mécanisme inspiré de la théorie du contrôle : les SSM (State Space Models). Avec eux, la montée en charge est linéaire. Et surtout, on permet aux paramètres SSM d’être fonction de l’input, de sorte que la sélection des informations à conserver s’opère au moment de la mémorisation – et non au moment de la remémoration, comme c’est le cas avec Transformers.

Mamba a toutefois une faiblesse qui dissuade d’abandonner complètement l’autoattention : les modèles ne pas performants sur le rappel (recall). Cette métrique traduit la proportion de résultats positifs correctement classés comme tels. Elle est à différencier de la précision, qui indique le pourcentage de prédictions correctes parmi celles faites par le modèle.

Hymba, un socle made in NVIDIA

Dragon LLM a tenu compte des ces éléments pour mener ses expérimentations. Elles ont consisté à entraîner des modèles de 120 à 770 millions de paramètres sur un maximum de 50 milliards de tokens.

Pour l’amélioration de la fonction de perte, un benchmark a été ciblé : modded-NanoGPT. Pour le rappel, SWDE (prompts de 500 tokens) et FDA (2000 tokens) ont été mobilisés. Pour la évaluer la modélisation du langage, HellaSwag a été retenu.

Ces bases posées, Dragon LLM s’est intéressé à une autre architecture : Hymba (Hybrid Mamba). Signée NVIDIA, elle combine, dans chaque couche, des têtes d’attention classiques et des têtes SSM. Elle n’utilise une attention globale que sur 3 couches. Dans les autres cas, l’attention est locale (elle se limite aux 1024 derniers tokens). Les modèles fondés sur ce socle se montrent efficaces à l’inférence : leur débit se maintient à mesure que s’agrandit le contexte. La faiblesse sur le rappel demeure, cependant. D’où un choix d’explorer les mécanismes dits d’attention différentielle. Dragon LLM en mentionne deux, émanant respectivement de DeepSeek et de Microsoft. Les résultats du premier n’ont pu être reproduits de façon fiable. Le second, qui implique un système de suppression du bruit censé permettre au modèle de mieux repérer le contexte important, a produit des améliorations marginales lorsque appliqué à toutes les couches. En revanche, circonscrit à l’attention globale, il a eu un bénéfice significatif. Possiblement, nous explique-t-on, parce qu’il aurait stimulé une spécialisation de ces couches sur le rappel.

Un peu de DeepSeek dans l’affaire

D’autres techniques ont été mises en œuvre pour améliorer les performances de l’architecture Dragon. Parmi elles, la mise à l’échelle de la normalisation. Elle a eu pour effet de stabiliser la variance dans les couches profondes, ainsi mieux entraînées.

Dragon LLM a aussi remplacé l’initialisation des paramètres de PyTorch par un schéma origine DeepSeek. Et utilisé la planification SkyLadder, qui agrandit progressivement la fenêtre d’attention au fil de l’entraînement. Il a également opéré une normalisation individuelle des têtes d’attention (amélioration de l’intégrité du signal) et repositionné les couches d’attention globale (amélioration de la perte et du rappel) tout en supprimant l’encodage positionnel pour les têtes associées. Quant à la gestion d’état interne de Mamba, elle a été remplacé par la méthode GDN (Gated Delta Net), qui garantit de meilleures performances une fois passé le seuil des 30 milliards de tokens.

Certaines techniques n’ont pas porté leurs fruits. Par exemple, sur la data efficiency, Rho-1 et SoftDedup. L’une et l’autre pondèrent les tokens : elles utilisent un petit modèle qui leur attribue un score définissant leur contribution à la fonction de perte (les tokens plus « informatifs » influencent davantage les gradients).
De même, aucun optimiseur ne s’est révélé plus efficace qu’AdamW. Sinon Ademamix, mais avec des instabilités trop difficiles à gérer.

Les performances de SmolLM3, mais en plus frugal

Pour passer à l’échelle, Dragon LLM a implémenté son architecture dans le framework Megatron-LM. Le modèle qui en résulte est dit au niveau de Qwen3-4B et de SmolLM3. En tout cas sur ARC, FDA, HellaSwag, LAMBADA, PIQA et SWDE (en 0-shot). Le tout en plus frugal. Pour l’inférence, on l’a vu (DragonLLM évoque même un déploiement sur CPU), mais aussi pour l’entraînement (3700 milliards de tokens, soit 3 fois moins que SmolLM3 et 10 fois moins que Qwen3-4B).

Dragon LLM vise désormais un entraînement sur plus de 10 000 milliards de tokens, une adaptation au suivi d’instruction et la formation de plus gros modèles. Il promet des « versions dédiées à la production […] dans les prochains mois ».

À consulter en complément :

JUPITER, ce supercalculateur Arm qui met l’Europe dans l’ère exascale
IBM prend ses distances avec Transformers pour ses LLM Granite
Alibaba renonce à la « pensée hybride » pour ses LLM Qwen
Non divulgué, mal maîtrisé : Deloitte tancé pour son usage de l’IA générative
La GenAI, explorée mais peu déployée pour gérer les microservices

Illustration générée par IA

The post Architectures LLM : Dragon, une recette alternative origine France appeared first on Silicon.fr.

Et si on pouvait pirater une IA non pas en la forçant, mais en la convainquant qu’elle est toujours du bon côté de la barrière ?? Ce serait pas un truc fun à faire ça quand même ? Hé bien c’est exactement ce que vient de faire une équipe de chercheurs en sécurité avec LatentBreak, une technique qui ressemble plus, je trouve, à de l’hypnose qu’à du véritable hacking.

Ainsi, plutôt que de bombarder ChatGPT ou Llama avec des prompts bizarres bourrés de caractères spéciaux pour les faire bugger (comme le font les anciennes techniques de jailbreak), LatentBreak joue sur la perception interne du modèle. L’IA croit en fait sincèrement répondre à une question innocente alors qu’elle génère du contenu dangereux. Un peu comme quand votre pervers narcissique préféré vous manipule pour vous faire croire que vous faites un truc bien et important alors que c’est de la merde et que ça vous enfonce encore plus…

Comme expliqué dans le document de recherche , les anciennes attaques comme GCG , GBDA ou AutoDAN ajoutaient des suffixes louches aux prompts, ce qui augmentait ce qu’on appelle la “perplexity”. La perplexity, c’est un indicateur de bizarrerie textuelle et cela, les filtres de sécurité sont maintenant capables de les détecter et de les bloquer.

LatentBreak contourne donc le problème en restant parfaitement naturel. L’algorithme remplace des mots par des synonymes, mais pas n’importe comment puisqu’il choisit chaque substitution pour déplacer la représentation interne du prompt vers les zones “sûres” du modèle, c’est à dire celles qui ne déclenchent aucune alarme. Le prompt reste alors fluide, compréhensible, inoffensif en apparence mais dans l’“inconscient” de l’IA, dans cet espace latent invisible où elle calcule ses réponses, le sens glisse subtilement vers quelque chose de complètement différent.

À chaque itération, l’algorithme de LatentBreak prend un mot du prompt et génère jusqu’à 20 alternatives via un autre modèle comme GPT-4o-mini et chaque variante est évaluée sur deux critères : est-ce qu’elle rapproche le vecteur interne du prompt d’un “centre de sécurité” dans l’espace latent, et est-ce que le sens global reste cohérent ?

La meilleure option est alors intégrée, et le nouveau prompt est testé sur le modèle cible. Si ça provoque une réponse normalement interdite, c’est gagné. Sinon, on recommence jusqu’à 30 fois de suite.

Et apparemment, les résultats sont impressionnants. Ils ont testé cette approche sur 13 modèles différents dont Llama-3, Mistral-7B, Gemma-7B, Vicuna-13B et Qwen-7B et LatentBreak affiche un taux de réussite entre 55 et 85% selon les cas. Les anciennes techniques tombant de toute façon à zéro face aux défenses modernes et tout ça en allongeant que de très peu la longueur du prompt.

LatentBreak passe d’ailleurs à travers des défenses réputées solides… Par exemple, R2D2 et Circuit Breakers, des systèmes qui analysent les signaux internes des neurones pour détecter les anomalies, se font totalement avoir parce qu’ils scannent le texte visible et les patterns de surface, mais pas la “pensée interne” du modèle.

Cette technique révèle quelque chose de fondamental à comprendre sur l’architecture des LLM modernes. Ces derniers ont une forme de dissonance cognitive qui est exploitable. Leur représentation interne ne correspond pas toujours à leur comportement affiché, et d’ailleurs les substitutions les plus efficaces se produisent près des dernières couches du modèle, là où la “décision” finale se forme. C’est à ce moment précis qu’on peut glisser le prompt dans une zone cognitive différente sans que les alarmes ne sonnent.

Bien sûr, LatentBreak nécessite un accès aux structures internes du modèle (donc pas de panique, ChatGPT ne va pas se faire pirater comme ça demain), ce qui limite son usage à des contextes de recherche ou aux modèles open source.

Le parallèle avec les techniques de social engineering qu’on connait est d’ailleurs frappant parce que quand vous manipulez quelqu’un, vous ne le forcez pas brutalement. Vous trouvez les bons mots, le bon contexte, vous lui donnez une perception qui correspond à ce que vous voulez… Bref, vous faites en sorte que la personne croie agir selon ses propres valeurs alors qu’elle fait exactement ce que vous voulez. Hé bien LatentBreak fait à peu près la même chose avec les IA en n’attaquant pas de front les protections, mais en les contournant en douceur en réécrivant la “mémoire de travail” du modèle.

Sympa non ?

Source

Un peu de Transformers, beaucoup de Mamba : avec les modèles de langage Granite 4.0, IBM opère une transition architecturale.

Mamba est censé pallier les limites des modèles transformateurs lors du traitement de longues séquences. Dans ces scénarios, le mécanisme d’attention constitue un goulet d’étranglement, du fait qu’il utilise une forme de cache clé-valeur permettant à chaque token d’accéder aux précédents lors de la prédiction. Plus la taille de contexte augmente, plus l’empreinte mémoire et la latence augmentent, de façon quadratique.
Des méthodes telles que la fenêtre glissante et l’attention flash peuvent atténuer cet effet. Mamba va plus loin en remplaçant le composant d’attention par un mécanisme inspiré de la théorie du contrôle : les SSM (State Space Models). Avec eux, la montée en charge est linéaire. On permet aux paramètres SSM d’être fonction de l’input, de sorte qu’une sélection des informations à conserver s’opère au moment de la mémorisation – et non au moment de la remémoration, comme c’est le cas pour les transformeurs.

Transformers réduit à la portion congrue

IBM n’écarte pas totalement Transformers, mais le réduit à la portion congrue : seules 4 couches sur 40 dans chacun des modèles Granite 4.0 aujourd’hui publiés (open-weight, licence Apache 2.0). Sont plus précisément combinés, de façon séquentielle, un groupe de 9 blocs Mamba, un bloc Transformers unique, et ainsi de suite. Les blocs Transformers sont maintenus notamment en ce qu’ils apportent des avantages sur les tâches avec apprentissage en contexte (few-shot prompting, typiquement).

Les modèles ainsi architecturés n’utilisent pas d’encodage positionnel : de par son fonctionnement, Mamba préserve intrinsèquement l’ordre des tokens. Ce n’est pas le cas de Transformers. On a donc tendance à y allier cet encodage positionnel… au détriment de la capacité des modèles à travailler sur des séquences plus longues que celles sur lesquelles on les a entraînés.

Des versions thinking à venir

Comme leurs prédécesseurs, les modèles Granite 4.0 sont destinés à générer du texte et du code. On en compte actuellement 4, tous déclinés en versions base et instruct (versions thinking à venir « d’ici à fin 2025 ») :

• H-Small
  Hybride Mamba/Transformers en MoE (32 milliards de paramètres dont 9 milliards actifs, soit 10 experts sur 72).
• H-Tiny
  Hybride Mamba/Transformers en MoE (7 milliards de paramètres dont 1 milliard actifs, soit 6 experts sur 64).
• H-Micro
  Hybride Mamba/Transformers dense (3 milliards de paramètres).
• Micro
  Variante « classique » (Transformers) de H-Micro.

L’ensemble est disponible dans des versions quantisées (GGUF, avec également du FP8 pour H-Small instruct).
En précision 8 bits, H-Small nécessite 33 Go de RAM ; H-Tiny, 8 Go ; H-Micro, 4 Go, contre 9 Go pour sa variante Transformers. IBM ne manque pas de mettre en avant ce gain pour l’inférence, surtout dans les tâches à contexte long et/ou à sessions multiples (agent de service client traitant plusieurs tickets en parallèle, par exemple).

Tous les modèles Granite 4.0 ont été validés pour des séquences de 128k. L’entraînement des versions de base a suivi un pipeline en 4 étapes (cf. tableau ci-dessous), sur des serveurs GB200 NVL72 chez CoreWeave. Le fine-tuning a reposé sur « des jeux de données ouverts sous licence permissive », des datasets synthétiques internes et des données annotées par l’humain.

Intégrer Mamba dans l’écosystème

H-Small et H-Tiny ont une autre forme d’hybridité : ils sont les premiers modèles MoE d’IBM à utiliser des « experts partagés ». En d’autres termes, des paramètres toujours actifs qui permettent aux autres experts de mieux se spécialiser.

Des modèles Nano et Medium sont sur la feuille de route. Il s’agira aussi de pousser la prise en charge de Mamba dans l’écosystème. Des outils comme llama.cpp ne la gèrent pas encore. C’est dans cet esprit qu’IBM a conservé un modèle « classique » dans sa gamme.

Le catalogue open-weight d’IBM comprend des modèles multimodaux, dont :

• Granite Speech (reconnaissance vocale ; dernière version publiée en août, à 2B et 8B)
• Granite Vision (dernière version – 2B – publiée en juin, avec un dérivé pour l’embedding ajouté en août)
• Granite Guardian (modération de contenu ; dernière version – 8B – publiée en septembre)
• Granite Docling (extraction de données structurées ; dernière version – 258M – publiée en septembre)

Ses derniers modèles « spécial code » remontent à 2024. Il existe aussi des modèles Granite pour le traitement de données géospatiales et de séries chronologiques.

À consulter en complément, notre brève revue des LLM Granite 3.0. Sortis il y a près d’un an, ils introduisaient alors, au catalogue des modèles IBM, des techniques telles que ScatterMoE (une implémentation n’imposant pas de plafond de tokens par expert) et Evol-Instruct (génération de données synthétiques à partir de questions racines dont on crée des versions améliorées à renfort de prompt engineering).

Illustration principale générée par IA

The post Les derniers LLM d’IBM n’ont plus grand-chose de transformateurs appeared first on Silicon.fr.

Ce qui est super relou avec les IA qu’on peut utiliser en local, genre avec Ollama, c’est que si on lui demande des infos un peu trop récente, ça nous sort des vieux chiffres de 2023 avec la confiance d’un vendeur de voitures d’occasion. Bon bah ça, c’est fini puisqu’ Ollama vient de sortir une API de recherche web qui permet enfin à vos modèles locaux d’accéder à des infos fraîches dispo sur le net.

Woohoo \o/ !

Baptisée Ollama Web Search, cette API REST permet donc à vos modèles de faire des recherches sur le web en temps réel comme ça plus besoin de se contenter des données d’entraînement figées dans le temps. Selon la doc officielle , l’API fournit “les dernières informations du web pour réduire les hallucinations et améliorer la précision”. En gros, votre IA locale devient aussi à jour que ChatGPT, mais sans envoyer vos données perso à OpenAI.

Les modèles compatibles avec cette nouvelle fonctionnalité incluent qwen3, LLama, gpt-oss (la version open source d’OpenAI), deepseek-v3.1, et plein d’autres. Et d’après les premiers tests de la communauté , qwen3 et gpt-oss sont même plutôt doués pour exploiter cette fonctionnalité. Le modèle comprend qu’il lui manque une info, fait sa recherche, analyse les résultats et nous sort une réponse documentée !

C’est trop incrrrr ! Vous allez pouvoir booster vos scripts / bots / outils d’IA locale pour qu’ils puissent surveiller des choses dispo en ligne, les comparer, générer des résumés à partir de sites web, fact checker ou compléter des infos…etc.

Mais alors comment s’en servir ? Bon, on est vendredi soir et j’ai la flemme de tourner un tuto vidéo, donc même si je risque de détailler tout ça bientôt à mes Patreons d’amour , voici quand même quelques explications.

D’abord, il faut créer une clé API Ollama . La doc explique que vous avez un essai gratuit généreux pour commencer, mais s’il vous en faut plus, il faudra prendre un petit abonnement Ollama Cloud …

Une fois votre clé en poche, exportez-la dans votre environnement comme ceci :

export OLLAMA_API_KEY="votre_clé_ici"

Le plus simple ensuite pour tester, c’est avec curl :

curl https://ollama.com/api/web_search \ --header "Authorization: Bearer $OLLAMA_API_KEY" \ -d '{ "query": "dernières vulnérabilités CVE janvier 2025" }'

Mais bon, soyons honnêtes, on va plutôt utiliser Python car c’est quand même plus cool ;-) . Voici donc un exemple de script basique qui compare une réponse avec et sans recherche web :

import ollama
from ollama import chat, web_search, web_fetch

model = "qwen3:4b"

# 1. Sans recherche web
response_classic = chat( # pas ollama.chat
 model=model,
 messages=[{
 "role": "user",
 "content": "Quelles sont les features de React 19?"
 }]
)
print("Sans recherche web:", response_classic.message.content[:500]) # .message.content

# 2. Avec recherche web
search_results = web_search("React 19 features dernières nouveautés")
print("Résultats:", search_results)

# 3. Avec outils
available_tools = {'web_search': web_search, 'web_fetch': web_fetch}
messages = [{
 "role": "user",
 "content": "Utilise la recherche web pour me dire les dernières features de React 19"
}]

response_with_tools = chat(
 model=model,
 messages=messages,
 tools=[web_search, web_fetch],
 think=True
)

# Accès aux tool_calls
if response_with_tools.message.tool_calls:
 for tool_call in response_with_tools.message.tool_calls:
 function_to_call = available_tools.get(tool_call.function.name)
 if function_to_call:
 args = tool_call.function.arguments
 result = function_to_call(**args)
 print(f"Outil utilisé: {tool_call.function.name}")
 print(f"Résultat: {str(result)[:500]}...")

print("Réponse finale:", response_with_tools.message.content)

import ollama
from ollama import chat, web_search

class SecurityAgent:
 def __init__(self):
 self.model = "qwen3:4b"

 def check_vulnerabilities(self, technologies):
 rapport = "🛡️ RAPPORT SÉCURITÉ\n\n"

 for tech in technologies:
 # Recherche directe des CVE récentes
 results = web_search(f"{tech} CVE vulnerabilities 2025 critical")

 # Demande au modèle d'analyser
 response = chat(
 model=self.model,
 messages=[{
 "role": "user",
 "content": f"Résume les vulnérabilités critiques de {tech}: {results}"
 }]
 )

 rapport += f"### {tech}\n{response.message.content}\n\n"

 return rapport

# Utilisation
agent = SecurityAgent()
rapport = agent.check_vulnerabilities(["Node.js", "PostgreSQL", "Docker"])
print(rapport)

from ollama import web_search, web_fetch, chat

# 1. Recherche d'articles pertinents
search_results = web_search("React 19 vs Vue 3 comparison 2025")
top_url = search_results.results[0]['url'] # ou .url selon le type
print(f"📰 Article trouvé: {search_results.results[0]['title']}")

# 2. Récupération du contenu complet de la page
page_content = web_fetch(top_url)
print(f"📄 {len(page_content.content)} caractères récupérés")

# 3. Analyse approfondie du contenu
response = chat(
 model="qwen3:4b", # ou "gpt-oss" si disponible
 messages=[{
 "role": "user",
 "content": f"""
 Analyse cette comparaison technique:
 {page_content.content[:4000]}

 Donne-moi:
 1. Les points clés de chaque framework
 2. Le gagnant selon l'article
 3. Les cas d'usage recommandés
 """
 }]
)

print(f"\n🔍 Analyse:\n{response.message.content}")

Mistral AI, la pépite française de l’intelligence artificielle, vient de lancer Mistral Medium 3.1, un nouveau modèle pensé pour les entreprises. Alliant performance, confidentialité et flexibilité, il peut être déployé en local sur des serveurs internes ou dans un cloud privé. Une approche qui le distingue des grands acteurs américains.

Un modèle pensé pour la souveraineté numérique

Avec Medium 3.1, Mistral AI poursuit sa stratégie de proposer des solutions d’IA adaptées aux besoins des entreprises européennes. Contrairement à la majorité des modèles disponibles uniquement dans le cloud public, Medium 3.1 offre la possibilité d’être hébergé en interne, garantissant ainsi une meilleure maîtrise des données. Cette approche répond à une préoccupation croissante : la souveraineté numérique.

Des performances comparables aux géants de l’IA

Medium 3.1 se positionne comme un modèle de classe frontier, capable de rivaliser avec les références du marché. Selon les benchmarks publiés, il excelle en raisonnement logique, multimodalité et génération de code.

Face à des concurrents comme Claude Sonnet 3.7 ou Llama 4 Maverick, le modèle de Mistral s’impose par sa précision et son coût compétitif : environ 0,40 $ par million de tokens en entrée et 2 $ en sortie, soit jusqu’à 8 fois moins cher que certains modèles américains.

Une flexibilité inédite pour les entreprises

La grande force de Mistral Medium 3.1 réside dans sa flexibilité de déploiement. Les entreprises peuvent choisir de l’intégrer :

• en mode on-premise pour un contrôle total,
• dans un cloud privé ou hybride,
• ou via des environnements VPC pour plus de sécurité.

Ce positionnement unique fait de Mistral AI un acteur à part, répondant aux besoins des organisations qui recherchent à la fois confidentialité, personnalisation et performance.

Tester Mistral Medium 3.1 en local : les prérequis

Avant de déployer Mistral Medium 3.1 dans une infrastructure d’entreprise, il est possible de tester le modèle sur un poste de travail. Cela permet d’évaluer ses capacités et sa pertinence avant une intégration à grande échelle. Voici les prérequis essentiels :

• Système d’exploitation : Linux (Ubuntu recommandé) ou macOS. Windows est possible via WSL2.
• Matériel :
  • GPU NVIDIA récent (série RTX 30xx ou supérieur) avec au moins 16 Go de VRAM,
  • CPU multicœurs (8 cœurs recommandés),
  • 32 Go de RAM système minimum.
• Stockage : prévoir au moins 50 Go d’espace libre pour le modèle et les dépendances.
• Pilotes et frameworks :
  • CUDA 12 ou supérieur,
  • PyTorch compatible GPU,
  • Installation de vLLM ou Ollama pour exécuter le modèle.
• Connexion internet : nécessaire pour télécharger le modèle depuis Hugging Face ou le portail de Mistral AI.

Une fois ces prérequis installés vous pouvez lancer une simple commande (via ollama run mistral-medium) ou un script Python basé sur transformers pour commencer à interagir avec le modèle en local.

Une alternative européenne crédible

Avec ce lancement, Mistral AI confirme son ambition : offrir une alternative souveraine aux solutions proposées par OpenAI, Anthropic ou Meta. Medium 3.1 ne se limite pas à la performance technique, il propose également un cadre d’utilisation plus respectueux des contraintes réglementaires européennes.
Dans un contexte où la maîtrise des données devient stratégique, ce modèle pourrait séduire de nombreux secteurs sensibles comme la santé, la finance ou l’industrie.

Cet article original intitulé Mistral AI dévoile Medium 3.1 : un modèle d’IA souverain et flexible pour les entreprises a été publié la première sur SysKB.