Les 3 articles les plus chauds de la veille du 3 octobre 2026. 🔥

🔥 Top 3

1. I made my iPhone a second GPU for my 24 GB MacBook: Qwen 3.8 27B prefills 29–44% faster & my holds part of the CTX window.

Un iPhone utilisé comme second GPU, c’est l’expérience menée sur r/LocalLLaMA pour faire tourner un modèle Qwen 3.8 27B sur un MacBook équipé de seulement 24 Go de RAM.

Le principe : le Mac fait le gros du travail, le téléphone prend une partie de ce que le modèle garde en mémoire vive. Les prefills, c’est-à-dire la phase où le modèle lit et indexe l’intégralité de votre prompt avant de générer la première réponse, passent de 29 à 44 % plus vite selon la longueur de la demande.

La deuxième partie est plus surprenante : l’iPhone héberge une partie de la fenêtre de contexte (CTX). Ce terme désigne le volume de texte que le modèle peut examiner d’un coup, historique de conversation inclus. Un modèle de 27B quantifié, donc compressé pour tenir dans la RAM, occupe vite de la place, et 24 Go deviennent une contrainte réelle.

Le gain ne porte pas sur la vitesse de génération de chaque mot, mais sur le temps de préparation du contexte. Pour les usages qui empilent de gros documents, c’est là que se joue le confort réel.

La frontière entre appareil et GPU continue de bouger, et un smartphone devenu mémoire vive externe ouvre une piste concrète pour les machines aux ressources limitées.

🔗 www.reddit.com

2. A model guide for the GPT-6 family

OpenAI vient de mettre en ligne son guide des modèles de la famille GPT-6. Le document est écrit pour les équipes qui doivent choisir, régler et mettre en production leurs appels aux API, pas pour des chercheurs.

Le sujet le plus concret est le réglage de l’effort de raisonnement (le fameux reasoning effort). C’est le curseur qui indique au modèle combien de réflexion interne il doit effectuer avant de répondre. Le passer en mode élevé sur une requête simple revient à facturer la plus grosse machine de la famille pour une réponse courte. Le réglage par défaut n’est pas toujours le bon.

Le guide insiste aussi sur le choix du modèle, plutôt que sur le plus gros modèle disponible. Une tâche de synthèse rapide et une analyse de code complet n’ont pas besoin du même moteur. Les startups qui mesurent le coût par requête plutôt que l’effet de mode gardent un budget maîtrisé.

Autre point : OpenAI promeut les skills, des blocs de compétences réutilisables. Contrairement à un prompt réécrit à chaque fois, un skill reste stable et partageable entre plusieurs agents et plusieurs outils.

Reste une question ouverte : jusqu’où l’effort de raisonnement peut-il être réduit sur une tâche sensible sans que l’utilisateur s’en aperçoive ?

🔗 OpenAI

3. Prompt Engineering

Changer l’ordre des exemples que vous montrez à un modèle peut faire passer vos résultats du hasard au niveau des meilleures performances. Et pourtant, le modèle lui-même ne bouge pas d’un octet.

C’est l’idée que défend la chercheuse Lilian Weng dans sa synthèse sur le prompt engineering, aussi appelé in-context prompting. Le principe : diriger le comportement d’un LLM (le modèle de langage qui génère du texte) uniquement via les instructions qu’on lui envoie, sans réentraîner ses poids. Pour rappel, les « poids » sont les paramètres numériquement optimisés au cours de l’entraînement. Les modifier est coûteux. Le prompt, lui, change en une seconde.

Deux approches de base encadrent cette pratique. Le zero-shot consiste à poser la question directement, sans exemple. Le few-shot ajoute quelques démonstrations réussies : le modèle comprend alors mieux ce que vous attendez de lui. Ce coût des tokens (unités de calcul de texte) peut poser problème sur les longs prompts.

L’étude de Zhao et al. (2021) sur GPT-3 explique pourquoi le few-shot reste si imprévisible : le modèle reprend la majorité des étiquettes visibles, répète le dernier exemple vu, ou favorise les mots courants. Ajuster ces biais fait varier la performance de près de zéro à l’état de l’art.

Un constat qui n’a pas pris une ride : le prompt engineering est une science empirique, où l’expérience compte plus que la théorie. Le prochain facteur limitant sera-t-il la fenêtre de contexte plutôt que la qualité des exemples ?

🔗 lilianweng.github.io

📦 Le reste de la veille