Qwen 3.5 vise l’IA locale utile sans appel cloud. Le sujet n’est pas seulement la performance, mais le bon compromis entre taille du modèle, mémoire, quantification, confidentialité et usages réels sur smartphone ou ordinateur modeste.
Qwen 3.5, c’est quoi ?
Qwen 3.5 est un modèle de langue open-weight d’Alibaba conçu pour fonctionner localement sur du matériel grand public, notamment smartphones, tablettes et ordinateurs portables modestes. Open-weight signifie que les poids du modèle, c’est-à-dire les paramètres appris pendant l’entraînement, sont accessibles et réutilisables selon une licence donnée. Ce n’est pas exactement la même chose qu’un logiciel open source complet, où tout le code, les données et la méthode d’entraînement seraient forcément publiés.
Un modèle de langue, ou LLM pour Large Language Model, est un système entraîné à prédire et générer du texte. Concrètement, il découpe les phrases en morceaux appelés tokens, puis estime la suite la plus probable. Cette mécanique simple en apparence permet de résumer un document, reformuler un texte, répondre à des questions, aider à écrire un email, expliquer un concept ou assister sur du code.
Qwen 3.5 s’inscrit dans la famille Qwen d’Alibaba, aux côtés de Qwen 2.5, Qwen 3 et de variantes multimodales capables de traiter autre chose que du texte, par exemple des images avec les modèles de type vision-langage. Son intérêt principal est clair : réduire l’écart entre les modèles puissants dépendants du cloud et les modèles utilisables hors ligne, directement sur votre machine.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Exécuter un modèle en local veut dire que les calculs se font sur l’appareil, sans envoi systématique de vos données à un serveur distant. Les bénéfices sont très concrets :
- Confidentialité : Les prompts et documents peuvent rester sur l’appareil.
- Hors connexion : Le modèle peut répondre sans accès Internet, selon l’application utilisée.
- Coût : Il n’y a pas de facturation à la requête comme avec beaucoup d’API cloud.
- Latence : Le temps de réponse peut être plus stable, à condition que le matériel suive.
Local ne veut pas dire magique. La qualité dépend de la taille du modèle, de la mémoire disponible, de la quantification, de l’application utilisée et du type de tâche. La quantification consiste à compresser les poids du modèle, par exemple en 4 bits ou 8 bits, pour réduire la mémoire nécessaire au prix d’une perte éventuelle de précision. Pour des usages courants, Qwen 3.5 vise donc l’efficacité plutôt que la course au modèle géant.
Les références utiles pour vérifier ces points sont la documentation officielle Qwen et le dépôt QwenLM sur GitHub, les fiches modèles Hugging Face quand elles existent, ainsi que la documentation d’Ollama, LM Studio et llama.cpp pour l’inférence locale, les modèles quantifiés et le format GGUF utilisé pour exécuter efficacement des LLM sur CPU et GPU grand public.
Que veut dire open-weight ?
Open-weight signifie une chose simple : les poids entraînés du modèle sont publiquement accessibles et téléchargeables. Concrètement, vous pouvez exécuter le modèle localement, le tester, l’adapter et le déployer sans dépendre uniquement d’une API, c’est-à-dire une interface facturée à l’usage par un fournisseur externe.
Il ne faut pas confondre open-weight, open source et modèle fermé. Un modèle open-weight donne accès aux poids, donc aux paramètres appris pendant l’entraînement. Mais cela ne veut pas dire que tout est ouvert. Les données d’entraînement, le code complet d’entraînement, les filtres appliqués, les choix d’architecture ou les détails exacts du pré-entraînement peuvent rester privés.
Un modèle open source complet va plus loin. Il publie normalement le code, les scripts, la documentation, parfois les jeux de données ou au moins leur description, avec une licence permettant de comprendre, modifier et redistribuer le système. À l’inverse, un modèle fermé reste accessible via une API ou une application, sans accès direct aux poids ni à l’infrastructure.
Pour les développeurs, les équipes data et les entreprises, la différence est très concrète. Un modèle open-weight permet souvent plus de contrôle :
- Exécuter le modèle sur vos propres serveurs ou machines locales.
- Limiter l’envoi de données sensibles à un fournisseur tiers.
- Intégrer le modèle dans des workflows internes sans quota imposé par une API externe.
- Tester des optimisations, de la quantification ou du fine-tuning selon ce que la licence autorise.
Le fine-tuning consiste à réentraîner ou ajuster un modèle existant sur des données spécifiques, par exemple des tickets support, des documents juridiques ou une base produit. L’objectif est d’améliorer ses réponses dans un domaine précis. Ce n’est pas magique : il faut des données propres, des compétences techniques, une évaluation sérieuse et un cadre de sécurité pour éviter les réponses fausses, les fuites d’information ou les comportements non souhaités.
Open-weight ne veut pas dire “gratuit pour tout faire”. Avant un usage business, il faut lire la licence, vérifier les droits commerciaux, tester les performances réelles, mesurer les risques de fuite de données et documenter les usages autorisés.
| Option | Accès | Données envoyées | Coût | Contrôle | Limites |
| Modèle fermé via API | Accès par service externe | Données envoyées au fournisseur | Facturation à l’usage | Contrôle limité | Dépendance, quotas, règles du fournisseur |
| Modèle open-weight local | Poids téléchargeables | Données gardées en local si bien hébergé | Coût matériel et exploitation | Contrôle fort sur l’hébergement | Licence, compétences, évaluation nécessaires |
| Modèle open source complet | Poids, code et documentation ouverts | Données selon votre déploiement | Coût interne principalement | Contrôle maximal | Maintenance, sécurité et conformité à gérer |
Quelle taille choisir ?
La bonne taille dépend surtout de votre appareil et de votre usage. Je retiens une règle simple : 0.6B et 1.7B visent les configurations très limitées, 4B représente le meilleur compromis mobile, et 8B devient intéressant dès que vous avez plus de mémoire ou un GPU adapté.
Un paramètre, c’est une valeur interne apprise pendant l’entraînement du modèle. Plus un modèle contient de paramètres, plus il peut généralement représenter de connaissances, de nuances linguistiques et de comportements complexes. Mais ce gain a un coût : davantage de mémoire vive, plus de calcul, plus de chauffe, et souvent une génération plus lente sur téléphone.
Les tailles se lisent donc comme des niveaux de contrainte. 0.6B sert aux usages ultra-légers sur appareils très limités. 1.7B convient mieux à des téléphones plus anciens ou à des configurations modestes. 4B devient la taille raisonnable pour des smartphones modernes avec environ 6 Go de RAM, ou pour des ordinateurs portables avec 8 Go de mémoire. 8B demande déjà une machine plus confortable, par exemple un Mac avec 16 Go de mémoire unifiée ou un laptop équipé d’un GPU discret.
Qwen 3.5 est décrit comme un transformeur dense, et non comme un modèle MoE. MoE signifie Mixture of Experts : c’est une architecture qui active seulement une partie des paramètres selon la requête. Dense veut dire que le modèle suit une approche plus classique, où les paramètres principaux participent à l’inférence.
Le lien avec Qwen 3 est important. Qwen 3 a introduit un mode hybride thinking/non-thinking, pour choisir entre vitesse et raisonnement plus poussé, avec des tailles allant de 0.6B à 235B en MoE. Qwen 3.5 reprend cette logique d’efficacité, mais cible davantage le déploiement en périphérie, c’est-à-dire directement près de l’utilisateur, sur l’appareil.
En pratique, les petits modèles suffisent souvent pour résumer une note, reformuler un e-mail, extraire des informations dans un document, aider sur du code simple ou répondre à des questions sur un texte fourni. Les raisonnements complexes, les bases de connaissance massives et les tâches critiques demandent toujours une évaluation comparative sérieuse.
| Appareil | Mémoire disponible | Taille conseillée | Usage recommandé | Compromis attendu |
| Téléphone très contraint | Moins de 4 Go | 0.6B | Résumé court, reformulation simple | Très rapide, mais moins précis |
| Téléphone ancien | 4 à 6 Go | 1.7B | Questions simples, extraction légère | Bon minimum, limites visibles |
| Smartphone moderne | Environ 6 Go | 4B | Usage mobile polyvalent | Meilleur équilibre |
| Mac ou laptop GPU | 16 Go ou GPU discret | 8B | Code, analyse, réponses plus nuancées | Plus lourd, mais plus capable |
Pourquoi la quantification change tout ?
La réponse courte est simple : la quantification rend l’exécution locale réaliste parce qu’elle réduit fortement la taille du modèle en mémoire et sur disque, avec en échange une perte possible de précision. Sur un téléphone, ce compromis change tout, car la limite n’est pas seulement la puissance de calcul. C’est souvent la mémoire disponible, la chauffe, la batterie et la capacité du runtime à exploiter correctement le matériel.
Un modèle comme Qwen 3.5 manipule des milliards de nombres internes, appelés poids. Ces poids servent à représenter ce que le modèle a appris pendant son entraînement. Sans quantification, ils sont stockés avec une précision élevée, par exemple en 16 bits ou 32 bits. Avec la quantification, on accepte de les représenter avec moins de bits. Le fichier devient plus léger, le chargement demande moins de mémoire, et l’inférence, c’est-à-dire la génération de texte, peut parfois être plus rapide.
Les formats Q4 et Q8 correspondent à deux niveaux courants de compression. Q4 utilise environ 4 bits par poids, donc il économise beaucoup de mémoire. Q8 utilise environ 8 bits par poids, donc il conserve plus d’information, mais prend plus de place. Dans l’écosystème llama.cpp, GGUF est un format très utilisé pour exécuter des modèles localement, notamment via des outils compatibles sur ordinateur et parfois sur mobile.
En pratique, les ordres de grandeur sont parlants. Une version Qwen3.5-4B-Q4_K_M tourne autour de 2,5 à 3 Go sur disque. Une version Qwen3.5-8B-Q4_K_M se situe plutôt autour de 4,5 à 5 Go. La RAM réellement consommée peut être plus élevée, selon le moteur utilisé, la taille de contexte, le système d’exploitation et l’accélération matérielle disponible.
Des outils comme LM Studio, Ollama, Enchanted et les moteurs compatibles GGUF permettent de charger ces modèles selon la plateforme. Sur des iPhone récents, notamment iPhone 15 Pro ou iPhone 16, le Neural Engine peut aider certaines applications. Mais les performances dépendent beaucoup de l’implémentation : toutes les apps ne l’exploitent pas de la même façon.
La recommandation la plus pragmatique : commencer par une version 4B quantifiée en Q4, tester vos vrais usages, puis passer à 8B si la qualité ne suffit pas et si la mémoire disponible le permet.
| Format | Taille estimée | Avantage | Limite | Cas d’usage conseillé |
| Q4_K_M 4B | 2,5 à 3 Go | Très bon compromis mémoire | Qualité parfois inférieure | Premier test sur téléphone récent |
| Q4_K_M 8B | 4,5 à 5 Go | Réponses souvent meilleures | Plus lourd en RAM et stockage | Usage local plus exigeant |
| Q8 | Plus volumineux | Meilleure conservation de l’information | Moins adapté aux appareils limités | Machine avec plus de mémoire |
À quoi sert le contexte long ?
Une fenêtre de contexte longue sert à donner au modèle plus de texte à lire en une seule fois. Cela peut être un long document, une conversation avec plusieurs allers-retours, ou un ensemble d’instructions détaillées que le modèle doit garder en tête pendant sa réponse.
Un token est un fragment de texte utilisé par le modèle pour découper l’entrée. Il peut correspondre à un mot court, à un morceau de mot, à un chiffre ou à un signe de ponctuation. Une capacité de 32 768 tokens permet donc de traiter des contenus bien plus longs qu’un simple prompt, même si l’équivalence exacte en mots varie selon la langue et le tokenizer, c’est-à-dire l’outil qui découpe le texte en tokens.
Dans la plupart des configurations annoncées, Qwen 3.5 supporte jusqu’à 32 768 tokens. Ce contexte long apporte plusieurs bénéfices concrets : meilleure continuité dans les conversations, analyse de documents plus volumineux, synthèses plus complètes, conservation d’instructions métier, et respect plus stable des contraintes données au départ.
| Cas d’usage | Intérêt du local |
| Résumer un rapport interne | Les données financières, RH ou commerciales restent sur l’appareil. |
| Comparer plusieurs extraits | Le modèle peut lire plusieurs passages sans envoyer les documents à une API externe. |
| Préparer une réponse depuis un cahier des charges | Les contraintes client restent disponibles dans le contexte pendant la génération. |
| Analyser des notes de réunion | Les informations sensibles, décisions et noms propres ne sortent pas du téléphone. |
| Générer une checklist depuis un document | Le modèle transforme un contenu long en actions sans transfert cloud. |
La nuance est importante : plus le contexte est long, plus la mémoire et le temps de calcul augmentent. Sur smartphone, utiliser systématiquement le maximum n’est pas forcément une bonne idée. Le bon réglage dépend de la taille du modèle, de la quantification, c’est-à-dire la compression des poids numériques du modèle, de l’application utilisée et de la mémoire disponible.
Qwen 3.5 devient intéressant quand on combine plusieurs paramètres avec soin : modèle open-weight, taille adaptée au téléphone, quantification efficace et contexte réglé selon le besoin réel. Je partirais sur une méthode simple en 4 étapes :
- Choisir une taille de modèle compatible avec votre appareil.
- Choisir une quantification qui réduit la mémoire sans trop dégrader la qualité.
- Tester 3 tâches métier réelles, par exemple résumé, extraction et génération de réponse.
- Mesurer la qualité, la vitesse et la consommation mémoire avant de valider le réglage.
Alors, faut-il tester Qwen 3.5 en local ?
Qwen 3.5 mérite d’être regardé si vous cherchez une IA locale, contrôlable et utilisable sans dépendance permanente au cloud. Son intérêt vient du compromis entre modèles compacts, poids accessibles, quantification et fenêtre de contexte longue. Le choix ne se résume pas au modèle le plus gros : il faut partir de votre appareil, de votre mémoire disponible et de vos vrais cas d’usage. Pour un premier test, une version 4B quantifiée est souvent le meilleur point d’entrée. Vous gagnez surtout en confidentialité, en maîtrise des coûts et en autonomie pour vos usages IA quotidiens.
FAQ
- Qwen 3.5 fonctionne-t-il vraiment sans internet ?
Oui, l’objectif de Qwen 3.5 est l’exécution locale : le modèle peut être chargé sur un appareil compatible et générer des réponses sans envoyer chaque requête vers un serveur distant. Il faut toutefois avoir téléchargé le modèle et disposer d’une application compatible. - Quelle version de Qwen 3.5 choisir pour un smartphone ?
Pour un premier test mobile, une variante 4B quantifiée en Q4 est le choix le plus raisonnable : elle reste utilisable sur des smartphones modernes tout en offrant une qualité plus intéressante que les très petites versions. Les versions 8B demandent plus de mémoire et un matériel plus confortable. - Quelle est la différence entre Qwen 3.5 et une IA cloud ?
Une IA cloud tourne sur des serveurs distants et se consomme souvent via API ou abonnement. Qwen 3.5 vise une exécution locale : plus de contrôle, moins de dépendance réseau, pas de coût par requête, mais des performances limitées par votre appareil. - Open-weight veut-il dire open source ?
Pas forcément. Open-weight signifie que les poids entraînés sont accessibles. Cela ne garantit pas que toutes les données d’entraînement, le code complet d’entraînement ou la méthode exacte soient publiés. Il faut lire la licence avant tout usage business. - À quoi servent les 32 768 tokens de contexte ?
Cette fenêtre de contexte permet de fournir au modèle des documents plus longs, des conversations étendues ou des consignes détaillées. C’est utile pour résumer, comparer et analyser du texte, mais un contexte long consomme davantage de mémoire et peut ralentir l’inférence locale.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process business et le SEO/GEO. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, tester ou industrialiser des usages IA utiles dans votre entreprise, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.