Déploiement CPU de Qwen3.5 en 2026 : quelle mémoire faut-il ? Calculez d’abord le modèle, puis choisissez le serveur

Le modèle semble tenir dans la mémoire disponible, mais le serveur ralentit dès que le contexte ou les autres conteneurs démarrent.

La méthode la plus sûre consiste à estimer séparément les poids quantifiés, le cache de contexte, les charges annexes et la marge d’exploitation, puis à mesurer le pic avec les requêtes réelles. Le CPU-only convient aux essais, aux usages peu fréquents et à certains traitements par lots ; une mémoire plus importante ne remplace pas un GPU lorsqu’un service exige un débit élevé ou de nombreuses requêtes simultanées.

Cet article s’adresse aux développeurs et aux petites équipes qui évaluent le déploiement de Qwen3.5 sans GPU.
Il aide à construire un budget mémoire mesurable avant de retenir une configuration de serveur.
Pour un service à forte charge, il faut examiner la latence et le débit autant que la capacité mémoire.

Dernière vérification : 24 octobre 2026. Les informations sur la famille de modèles sont recoupées avec le dépôt officiel de Qwen3.5 et le catalogue de modèles Ollama. Les étiquettes, fichiers, licences et compatibilités peuvent évoluer : vérifiez-les de nouveau au moment du déploiement.

Mémoire de déploiement de Qwen3.5 sur CPU : le calcul de départ

La taille du fichier de modèle donne un premier indice, mais ne représente pas toute la mémoire consommée pendant l’exécution. Le processus d’inférence doit charger les poids, réserver de la mémoire pour le cache de contexte et partager la machine avec le système, les conteneurs et les autres services. Un modèle qui démarre peut donc manquer de marge dès qu’une requête plus longue ou un autre service est lancé.

Pour obtenir une première estimation des poids, utilisez la relation suivante :

nombre de paramètres × largeur de quantification en bits ÷ 8

Le résultat est une approximation des octets correspondant aux poids, sous les hypothèses retenues. Utilisez la largeur indiquée pour le fichier précis envisagé, plutôt qu’une valeur déduite du seul nom du modèle. Cette estimation ne correspond pas nécessairement à l’occupation exacte en mémoire : les métadonnées, la représentation utilisée par le moteur et les zones de travail peuvent modifier le résultat.

Le dépôt officiel de Qwen3.5 permet de vérifier les informations du modèle et sa licence. Le catalogue Qwen3.5 d’Ollama présente les étiquettes disponibles et les informations relatives aux fichiers. Avant de calculer, notez l’étiquette complète, la quantification, le fichier concerné et la licence. Une étiquette différente peut correspondre à un fichier et à des besoins différents : une estimation portant simplement sur « Qwen3.5 » est trop imprécise pour dimensionner un serveur.

Pour le budget d’exploitation, consignez séparément :

• la mémoire estimée des poids, calculée à partir du fichier choisi ;
• le cache de contexte associé à la longueur demandée et à la représentation utilisée ;
• les zones de travail requises par le moteur d’inférence ;
• la mémoire résidente du système, des conteneurs et des applications annexes ;
• une marge d’exploitation déterminée par les mesures du service réel, plutôt que par un pourcentage présenté comme universel.

Cette séparation évite une erreur fréquente : conclure que le modèle est déployable parce que son fichier est plus petit que la mémoire installée. La machine doit aussi absorber les besoins que la taille du fichier ne décrit pas.

Contexte, requêtes et mesures en situation réelle

La longueur du contexte influe sur les ressources consommées pendant l’inférence. Un échange court et une requête contenant un long historique ne mobilisent pas le même cache. Plusieurs séquences traitées en parallèle peuvent également accroître les réservations mémoire. Les entrées multimodales, si la variante et le moteur utilisés les prennent en charge, ajoutent d’autres conditions à vérifier. Sans mesure sur une combinaison précise de modèle, de moteur, de contexte et de requêtes, il n’est pas possible d’avancer une augmentation fixe fiable.

Pour les architectures qui stockent des clés et des valeurs dans le cache, une approximation conceptuelle peut s’écrire ainsi :

2 × nombre de couches × nombre de têtes de clés-valeurs × dimension d’une tête × longueur du contexte × octets par élément × séquences actives

Cette expression sert à comprendre les facteurs en jeu ; elle ne remplace ni les caractéristiques réelles de l’architecture ni les mesures du moteur. Les paramètres nécessaires doivent provenir de la configuration du modèle déployé. La précision utilisée pour le cache et la gestion des séquences dépendent du logiciel et de ses réglages. Si une donnée manque, mieux vaut mesurer le pic que la remplacer par une valeur supposée.

Le protocole de mesure doit reproduire le service envisagé, et pas seulement le chargement initial :

• Avant le test : notez la version du modèle, l’étiquette, la quantification, le moteur, ses options et les limites appliquées aux conteneurs.
• Au chargement : relevez la mémoire disponible avant et après l’initialisation, puis attendez la fin du chargement des poids.
• Avec le contexte cible : exécutez une requête représentative de la longueur réellement attendue et relevez le pic, pas seulement l’occupation au repos.
• Avec la charge simultanée prévue : répétez le scénario de requêtes concurrentes ou de traitement par lots correspondant au service.
• Avec les services annexes actifs : relancez le test lorsque l’application, la base vectorielle et les autres conteneurs sont présents.

Sous Linux, /proc/meminfo expose des informations système consultables, par exemple avec grep -E 'MemAvailable|MemTotal|SwapFree' /proc/meminfo. La documentation du noyau sur les fichiers de processus décrit cette interface. Pour un service conteneurisé, contrôlez aussi ses limites : la documentation Docker sur les contraintes de ressources explique que la mémoire accessible au conteneur peut être restreinte. Une limite trop basse peut faire échouer le processus alors que l’hôte dispose encore de mémoire ; une limite généreuse, à l’inverse, ne crée pas de capacité physique supplémentaire.

Le relevé utile doit être reproductible : mémoire disponible au départ, pic du processus d’inférence, pic global de la machine, longueur des requêtes, nombre de séquences actives et éventuelles erreurs. Conservez ces éléments avec la configuration testée. Sans eux, une mesure isolée ne permet pas de comparer des modèles ni de déterminer si la difficulté vient du serveur, du conteneur ou des options de lancement.

CPU-only : capacité de chargement et expérience utilisateur

Pouvoir charger Qwen3.5 et obtenir une réponse ne signifie pas que l’expérience conviendra aux utilisateurs. La mémoire répond à une question de capacité ; le processeur et son sous-système mémoire influent sur la vitesse et le débit. Ajouter de la mémoire peut aider à accueillir davantage de données ou de services, mais ne transforme pas le processeur en accélérateur spécialisé.

Le processeur AMD EPYC 7543P utilisé dans les configurations concernées comporte 32 cœurs et 64 fils d’exécution et repose sur l’architecture Zen 3. AMD indique la prise en charge d’AVX2 ; ce processeur ne dispose pas d’AVX-512. Ces caractéristiques décrivent le processeur, mais ne déterminent pas à elles seules la vitesse de génération de Qwen3.5. Le résultat dépend également du moteur, de la quantification, du contexte, des réglages et de la charge simultanée. Les caractéristiques sont détaillées dans la fiche AMD EPYC 7543.

Pour comparer les scénarios, ne cherchez pas un chiffre de débit générique. Mesurez le temps de réponse sur des requêtes représentatives, vérifiez que les lots sont traités dans le délai attendu et observez la stabilité lors d’une utilisation prolongée. Le guide du serveur llama.cpp décrit le mode serveur et ses options. Vérifiez la compatibilité de la version retenue avec le modèle et les fonctions requises par le projet. Une compatibilité générale annoncée ne garantit ni une vitesse précise ni une prise en charge identique de toutes les variantes.

Les limites apparaissent particulièrement lorsque les demandes doivent être traitées rapidement et simultanément. Une mémoire importante peut aider à conserver le modèle et les services chargés, mais ne garantit ni un débit donné ni une latence acceptable. Un test pertinent doit inclure le profil des requêtes, le délai de réponse toléré et la charge de pointe visée. Si ces critères ne sont pas satisfaits après vérification des réglages et séparation des services, il faut envisager une autre architecture de calcul plutôt que de commander davantage de mémoire en espérant résoudre un problème de calcul.

Environnement d’exécution et services annexes

Un serveur consacré à l’IA peut aussi héberger une interface, une orchestration de tâches, un stockage documentaire et une base vectorielle. Il faut comptabiliser leur mémoire résidente séparément : la consommation totale de la machine correspond aux charges effectivement présentes, tandis qu’une limite de conteneur représente seulement un plafond applicable à ce conteneur.

Cette distinction aide à diagnostiquer plusieurs situations :

• Le conteneur atteint sa limite alors que le système conserve de la mémoire disponible : contrôlez la limite Docker et les journaux du conteneur avant de conclure à un manque de capacité globale.
• Le système manque de mémoire alors que le modèle seul fonctionne : recherchez les services concurrents, les tâches d’indexation, les caches et les processus auxiliaires.
• Le modèle est chargé sans épuiser la mémoire, mais les réponses sont trop lentes : examinez le processeur, le moteur, le contexte et le profil de charge ; augmenter la mémoire ne répond pas nécessairement au problème.

Pour distinguer ces cas, relevez l’occupation du processus d’inférence, celle des autres services et les valeurs système. Effectuez les mêmes mesures pendant une requête courte, une requête au contexte cible et une période où l’indexation ou les autres tâches prévues sont actives. Si le moteur s’exécute dans un conteneur, notez sa limite et comparez-la à la mémoire disponible de l’hôte. Vous pourrez ainsi distinguer un défaut de capacité du conteneur d’une saturation de la machine entière.

Les données, les fichiers de modèle et les index doivent aussi être prévus au-delà de la RAM. Les configurations CloudUDP comprennent deux unités NVMe de 1 To en accès direct ; elles ne constituent pas un miroir matériel. Pour obtenir une redondance, le stockage doit être organisé et sauvegardé en conséquence. Vérifiez les capacités et les options disponibles avant de retenir une machine. La taille d’un fichier de modèle ne mesure pas la mémoire d’exécution, pas plus qu’une capacité de stockage annoncée ne garantit la vitesse d’inférence.

Choix CPU-only selon la charge

Le choix dépend du résultat attendu, et non d’une étiquette générale telle que « petit modèle » ou « grand serveur ». Utilisez cette liste de décision après les mesures :

• [ ] Si le déploiement sert à tester un modèle, à valider une intégration ou à traiter des demandes peu fréquentes, et que la latence mesurée est acceptable, retenez le CPU-only. Fixez un scénario de requête et surveillez le pic mémoire avant d’ouvrir le service à d’autres utilisateurs.
• [ ] Si l’IA cohabite avec une base vectorielle, une interface ou des traitements documentaires, mais que les services se gênent, séparez les charges ou réduisez leur concurrence avant de changer de machine. Reprenez ensuite les mesures avec tous les services actifs.
• [ ] Si le chargement réussit, mais que le débit ou la latence ne respecte pas les objectifs, ne prenez pas la mémoire disponible pour une réserve de performance. Mesurez avec le moteur et le profil de requêtes prévus ; si le besoin reste insatisfait, évaluez une solution GPU adaptée.
• [ ] Si le pic mesuré dépasse la mémoire utilisable après prise en compte des services et de la marge d’exploitation, choisissez une capacité supérieure lorsqu’elle est disponible, ou répartissez le modèle et les applications sur des machines distinctes.
• [ ] Si le besoin se limite à une expérimentation ponctuelle ou à un usage très léger, comparez le coût et la charge d’administration d’un serveur dédié avec une solution temporaire ou un service externe. Une machine dédiée n’est pas automatiquement le meilleur choix pour une charge occasionnelle.

CloudUDP propose des configurations avec 128 Go ou 256 Go de mémoire DDR4-3200 ECC RDIMM. La mémoire installée ne peut pas être augmentée sur place : la capacité doit être choisie lors de la sélection de la configuration. Ces options matérielles ne sont pas des besoins minimaux garantis pour Qwen3.5. Pour déterminer celle qui convient, partez du pic mesuré pour le modèle et les services dans le scénario visé, puis gardez une réserve correspondant aux variations de charge. Les caractéristiques et les options de stockage sont consultables dans les informations de configuration de CloudUDP.

Jalons de déploiement avant mise en production

Un déploiement contrôlable se déroule par étapes. Chaque jalon doit produire une observation permettant de poursuivre ou de revoir le dimensionnement.

Jalon de préparation : choisissez une étiquette présente dans le catalogue, vérifiez sa licence et notez la quantification ainsi que la taille du fichier. Vérifiez les exigences de compatibilité dans le dépôt officiel et la documentation du moteur. Si la compatibilité de la variante n’est pas confirmée, ne la considérez pas comme acquise.

Jalon de calcul : estimez les poids à partir de la largeur de quantification correspondante, puis notez séparément les facteurs du cache de contexte. Ajoutez au budget les autres applications, les conteneurs et le système. Le résultat constitue une hypothèse de dimensionnement, pas une preuve de bon fonctionnement.

Jalon de lancement contrôlé : démarrez le moteur avec une requête représentative, relevez le pic mémoire et vérifiez les journaux. Si le conteneur est limité, consignez cette limite. Le guide d’accès à un serveur CloudUDP présente les modalités d’accès nécessaires pour effectuer ces vérifications sur la machine retenue.

Jalon de charge réelle : activez les services annexes prévus, utilisez le contexte attendu par l’application et répétez le test selon le mode de traitement envisagé. Documentez les erreurs, les délais et la mémoire observée ; ne transformez pas une mesure isolée en promesse générale de capacité.

Jalon de décision : conservez le CPU-only si les mesures satisfont les objectifs d’usage et si la mémoire garde une marge d’exploitation. Sinon, réduisez la concurrence, séparez les services ou réévaluez le type d’accélération. N’augmentez la RAM que si le problème constaté est bien un manque de capacité mémoire.

Enfin, vérifiez que le stockage et les sauvegardes correspondent à la valeur des modèles, des documents et des index. Deux unités NVMe en accès direct offrent de l’espace local, mais une sauvegarde hors machine reste nécessaire pour réduire le risque de perte. Si les données sont sensibles, documentez aussi les répertoires persistants des conteneurs, les accès administratifs et le processus de restauration avant la mise en service.

Du relevé à la configuration du serveur

Avant de choisir, rassemblez dans un même relevé le modèle et son étiquette, la quantification, le contexte du test, le nombre de séquences actives, l’occupation maximale du processus, la mémoire globale de l’hôte, les services simultanés et le délai observé. Ce relevé évite de comparer une mesure de chargement à une mesure sous requêtes ou de retenir une configuration sur la seule taille du fichier.

La mémoire système n’est qu’un axe de sélection. Vérifiez également l’espace requis pour les fichiers et les index, la méthode de sauvegarde, la bande passante adaptée au téléchargement des images et des modèles, ainsi que le cycle de facturation. Ne déduisez pas des caractéristiques matérielles une vitesse de Qwen3.5 : une telle conclusion exige un essai documenté sur la configuration et le logiciel concernés. Les options et modalités actuelles sont disponibles dans les informations de configuration de CloudUDP.

Un serveur physique dédié peut être pertinent lorsqu’un modèle et ses services doivent rester disponibles sur une machine réservée, avec une mémoire choisie à l’avance et des données conservées dans cet environnement. À l’inverse, un environnement partagé peut exposer à des ressources concurrentes, à des limites de conteneur ou à une configuration moins libre ; un service facturé à l’usage peut mieux convenir aux essais ponctuels ou aux charges très variables. Le choix dépend du profil mesuré, pas d’une préférence abstraite pour le matériel dédié.

CloudUDP propose des serveurs physiques AMD dédiés avec des options de mémoire et de stockage définies dans ses informations de configuration ; le service ne fournit pas de GPU. Si les essais montrent que le CPU répond aux objectifs, vérifiez que l’option mémoire retenue couvre le pic de Qwen3.5 et celui des services annexes, puis consultez les configurations CloudUDP. Si le débit ou la latence reste insuffisant malgré un budget mémoire adapté, comparez une solution GPU plutôt que de considérer davantage de RAM comme un substitut.