Monter une vraie IA à la maison, c'est vite une galère. Vous achetez une super machine puis vous collez dessus toute votre liste au père Noël (Chat local, reco vocale, génération d'image, RAG et compagnie) et vous voilà à empiler des dockers à n'en plus finir. Eh bien Light Heart Labs en a eu marre de ces bricolages et nous a pondu Dream Server, un outil qui câble tout ce petit monde à votre place !

Une seule commande et c'est parti mon kiki (Linux et macOS) :

curl -fsSL https://raw.githubusercontent.com/Light-Heart-Labs/DreamServer/main/dream-server/get-dream-server.sh | bash

Ou Windows :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
git clone https://github.com/Light-Heart-Labs/DreamServer.git
cd DreamServer
.\install.ps1

Ça va lancer le script qui va ensuite tout paramétrer tout seul et choisir le modèle d'IA qui collera le plus à votre matériel, et cela que vous ayez une RTX 4090, un Mac M4 avec mémoire unifiée ou encore une puce AMD Strix Halo voire un vieux PC sans GPU.

Edit : un lecteur m'a remonté un piège si vous êtes sous Linux configuré en français (ou n'importe quelle locale qui écrit les décimales avec une virgule). Le script génère tout seul les valeurs de votre fichier .env en suivant le format de nombres de votre système, et il vous colle des 16,0 au lieu de 16.0. Du coup l'install se vautre avec une erreur dans le genre COMFYUI_CPU_LIMIT: expected number, got '16,0'. La parade, confirmée par un des auteurs, c'est de relancer l'installeur en forçant la locale C (celle qui met des points à la place des virgules) :

LC_ALL=C ./install.sh

Ensuite, pendant que le LLM se télécharge à fond les ballons, un autre petit modèle de 1,5 milliards de paramètres en backup afin que vous puissiez quand même "discuter" avec votre Dreamserver.

Le rôle de Dreamserver c'est donc juste de prendre toutes les briques de l'IA pour vous en faire un truc clé en main. Open WebUI pour le chat, llama-server pour l'inférence, Whisper et Kokoro pour la voix, ComfyUI pour les images, Qdrant pour le RAG, SearXNG pour la recherche web sans mouchard, et bien sûr n8n pour brancher tout ça à vos automatisations.

Et une fois que c'est en route, suffit de lancer la commande dream et là vous pourrez tout faire.

Par exemple dream status pour visualiser l'état des services et du GPU, dream model swap T3 pour changer de "palier" sur votre matos, dream enable n8n pour activer une extension ou encore dream mode hybrid pour avoir de l'inférence en local avec possibilité de basculer sur une IA dans le cloud via une API.

Dreamserver reste un orchestrateur, et pas un moteur IA magique, donc si vous adorez tout assembler vous-même, vous n'avez clairement pas besoin de ça. Par contre, si vous vous en foutez, et que vous voulez juste votre IA qui tourne ce soir, ça vous fera gagner des heures de bidouille.

Faut dire qu'à mesure que l'IA devient une infrastructure de base, dépendre à 100% d'un abonnement cloud qui peut tripler ses tarifs ou couper votre accès du jour au lendemain, ça craint un peu. Donc je pense qu'on est tous bien contents d'avoir des solutions clé en main comme celle-ci.

Si ça vous tente, c'est sur le dépôt de Dream Server .

C'est la fin d'une époque. Le noyau Linux, le cœur du système qui pilote le matériel et les communications, s'apprête à supprimer le support d'AppleTalk, ce vieux protocole réseau qu'Apple utilisait dans les années 80 et 90 pour faire dialoguer ses Mac entre eux avant que TCP/IP, le langage commun d'internet, ne s'impose partout.

À l'époque, c'était plutôt malin: vous branchiez deux machines et une imprimante, et elles se trouvaient toutes seules, sans la moindre configuration, du plug-and-play avant l'heure à un moment où monter un réseau relevait encore du casse-tête réservé aux initiés.

Aujourd'hui, plus grand monde ne parle ce dialecte. Il en subsiste quelques traces dans Bonjour, la techno maison qui détecte automatiquement imprimantes et appareils sur un réseau local, mais le protocole d'origine, lui, est mort depuis longtemps.

Près de 4000 lignes de code vont donc disparaître avec la version 7.2 du noyau, et Apple avait lui-même enterré AppleTalk dès 2009, du temps de Mac OS X Snow Leopard. Autant dire que le préavis a été large.

Le plus étonnant, c'est ce qui a déclenché le grand ménage. Ce n'est pas vraiment l'abandon par les utilisateurs, mais une vague de correctifs générés par intelligence artificielle qui a fini par saturer la liste de diffusion des développeurs réseau.

Depuis quelques mois, des outils basés sur des grands modèles de langage, balancent automatiquement des "corrections" de bugs sur du code que personne n'avait réclamé, pour un protocole que plus aucun matériel ne fait tourner.

Et chaque proposition, même inutile, mobilise un humain qui doit la lire, la tester et vérifier qu'elle ne casse rien ailleurs, du temps précieux soustrait au vrai travail de mainteneurs déjà débordés par les contributions légitimes.

C'est Jakub Kicinski, qui supervise toute la pile réseau du noyau, qui a fini par trancher: plutôt que de faire éplucher par ses équipes des patchs pondus en série par des machines pour réparer une techno morte, il a préféré retirer AppleTalk d'un seul geste.

Et il n'en est pas à son coup d'essai. Au cycle précédent, pour Linux 7.1, il avait déjà passé à la trappe ARCnet, l'ISDN, la radio amateur et toute une collection de vieux pilotes réseau oubliés, soit près de 138 000 lignes effacées d'un coup, dans ce qu'il a lui-même baptisé la "LLM-pocalypse".

Le code d'AppleTalk ne finit quand même pas tout à fait à la poubelle, puisqu'il rejoint AX.25 et la radio amateur dans un dépôt GitHub mis de côté, pour les rares curieux qui voudraient encore bidouiller avec.

Bref, c'est une première: des contributions automatisées qui font retirer du code encore fonctionnel. L'IA ne crée pas toujours. Parfois, elle déblaie.

Source : Phoronix

Des chercheurs de l'université de Californie à San Diego, épaulés par Google, viennent de prouver un truc contre-intuitif : un Pixel mis au rebut il y a trois ans tient encore tête à un serveur professionnel sur certains calculs, au point qu'on peut en assembler un vrai data center au lieu de le foutre à la poubelle.

L'idée a été posée sur le blog de recherche de Google . Une fois l'appareil ouvert, les chercheurs retirent tout ce qui ne sert plus, l'écran, la batterie au lithium, les caméras et la coque, jusqu'à ne garder que la carte mère et sa puce, ce qu'on appelle un SoC, le processeur qui faisait tourner Android avant qu'on le bascule sur une distribution Linux des plus classiques.

Ce système, le même qui anime déjà l'immense majorité des serveurs de la planète, libère la puce des limites pensées pour un mobile, à commencer par ce bridage qui met les applications en pause dès qu'elles passent à l'arrière-plan. Ensuite, il suffit de relier ces cartes mères entre elles via Kubernetes, l'outil que les géants du web emploient déjà pour piloter les milliers de machines de leurs centres de données comme un seul gros ordinateur.

Le plus déroutant arrive là. Sur la plupart des tests ne mobilisant qu'un seul cœur, un Pixel Fold de 2023 dépasse un serveur ASUS RS720A-E11 pourtant équipé de deux gros processeurs AMD, le genre de bête qu'on retrouve dans les baies des entreprises.

Le serveur empile bien plus de cœurs en parallèle, si bien qu'il faut réunir entre 25 et 50 téléphones pour rivaliser avec son débit total. Mais bon. Dès lors que vous ramassez ces appareils gratuitement au lieu d'acheter du silicium neuf, l'équation se renverse.

Le vrai argument est écologique, puisque près de la moitié des émissions de carbone d'un smartphone sur toute sa vie part dans sa seule fabrication, surtout dans l'assemblage de la carte mère et du processeur, ce fameux carbone gris déjà cramé avant même que l'appareil ne s'allume.

On change pourtant de mobile tous les trois ou quatre ans, en balançant une puissance de calcul encore largement bonne à servir, pendant que les entreprises font fabriquer des serveurs flambant neufs pour les mêmes tâches. Le gâchis est énorme.

L'équipe a pour l'instant fait tourner une grappe de 20 téléphones, qui a encaissé sans broncher le pic de rendu des devoirs d'une classe de plus de 75 étudiants avec une latence plus basse que les services cloud du commerce. Elle prépare déjà un cluster d'environ 2 000 Pixel pour la rentrée, capable d'absorber une centaine de cours d'informatique en même temps pour une fraction du prix du cloud habituel.

Reste à rester lucide. Ces puces ont peu de mémoire, donc on les cantonne aux tâches légères, la correction automatisée ou les carnets de code, loin de l'entraînement d'un gros modèle d'IA.

Mais voir une montagne d'e-déchets se muer en salle de classe numérique, ça donne sacrément envie d'y croire. Surtout vu le nombre de Pixel qui dorment au fond de nos tiroirs, même moi j'en ai deux qui traînent pour tout vous dire.

Source : Techspot

Si vous faites tourner un petit serveur gratuit chez Oracle, je vous invite prestement, comme dirait Godefroy, à aller vérifier votre compte. Car oui mes amis, Oracle vient de diviser par deux son offre "Always Free" sur les machines ARM, et ils l'ont fait sans prévenir personne. Bouuuuuh ! Cela veut dire que leur fameuse bécane gratuite à 4 cœurs ARM (Ampere A1) et 24 Go de RAM, celle que la moitié de la communauté self-hosting fait tourner pour héberger son site web, son VPN ou son petit lab , est officiellement passée à 2 OCPU et 12 Go de mémoire .

La tristesse m'envahit... snif.

Cela veut donc dire que si vous avez une instance configurée en 4 OCPU / 24 Go, vous êtes dorénavant au-dessus de la limite gratuite. Vous devrez donc rapidement la redimensionner à 2 OCPU / 12 Go, et ça, ça prend 5 à 10 minutes.

Pour ce faire, il faudra vous rendre sur l'affreux dashboard d'Oracle Cloud. Vous ouvrez alors votre instance, Actions puis More actions puis Edit. Vous dépliez la ensuite la section Shape du VM.Standard.A1.Flex, vous mettez 2 OCPU et 12 Go, vous sauvegardez et vous validez le reboot comme des bonhommes, lol.

Ouais, faut redémarrer le VPS, puis se reconnecter dessus en SSH, et c'est réglé. Le guide de Viren070 détaille ce redimensionnement vers 2 OCPU pas à pas si vous voulez être un peu plus tenu par la main.

Et si vous ne touchez à rien parce que balek frrr ??? Et bien si votre compte est en Pay-As-You-Go, tout ce qui dépassera la nouvelle limite gratuite risque de vous être facturé, d'après les retours d'utilisateurs qui ont contacté le support Oracle. Et si vous êtes sur un compte purement gratuit, c'est l'instance elle-même qui peut être stoppée ou récupérée par Oracle. Bref, dans les deux cas, mieux vaut s'en occuper soi-même que de découvrir le problème en mode facture surprise ou disparition de serveur.

Je trouve quand même que le plus gênant dans cette histoire, c'est le silence d'Oracle. Ils n'ont fait aucune annonce ni aucun mail aux clients. Les gens s'en sont rendus compte simplement parce que la page de doc a changé... D'ailleurs, au moment où j'écris ces lignes, le simulateur de coûts d'Oracle affiche encore 0 € pour une instance 4 OCPU / 24 Go, ce qui me laisse penser que la facturation réelle pourrait se déclencher possiblemenet un peu plus tard.

Personne ne sait exactement quand le couperet tombera en fait et c'est ça le souci...

Petite précaution au passage, si vous redimensionnez, sur ARM, Oracle est en permanence à court de capacité... Donc quand vous éteignez votre instance pour la reconfigurer, rien ne vous garantit que vous récupérerez vos cœurs au reboot. Ils peuvent très bien partir à quelqu'un d'autre donc si vous tenez plus à votre machine qu'à vos propres gosses, passez le compte en Pay-As-You-Go avant de la redimensionner. Cela vous permettra de réduire le risque de le voir se faire dégommer.

Et voilà comme un bout d'offre "Always Free" (ce qui veut dire en français, "Toujours gratuit", je me permets de le souligner en toute subtilité QUAND MÊME) vient de prendre fin... Après c'est un peu logique parce que 4 cœurs ARM offerts à vie, c'était plutôt généreux dans le monde dans lequel on vit.

Mais bon, diviser leur offre par deux sans prévenir, en laissant notamment les comptes Pay-As-You-Go se prendre potentiellement une claque en facture alors qu'ils n'ont pas été prévenu, c'est pas un move que la communauté des adorateur du grand Oracle va apprécier je pense...

Bref, si vous avez une instance ARM chez Oracle, allez la vérifier maintenant parce que 5 petites minutes de resize aujourd'hui valent mieux qu'une facture surprise demain...

Source