Exécuter Qwen 27B sur un VPS avec Ollama

Pouvez-vous exécuter Qwen 3.8 27B sur un VPS sans GPU ?

Pour exécuter Qwen 3.8 27B sur un VPS, vous devez d’abord utiliser un tag de modèle existant. Au 4 août 2026, la bibliothèque Ollama ne contient aucune entrée qwen3.8. Le tag 27B publié le plus proche est qwen3.6:27b : 27.8 milliards de paramètres, quantification Q4_K_M, licence Apache 2.0. Toutes les commandes et tous les nombres ci-dessous utilisent ce tag avec Ollama v0.32.5, publié le 27 juillet 2026.

La réponse courte est oui sur un VPS doté de 32 GB de RAM ou plus, mais l’exécution sera lente. Un modèle dense 27B en Q4 nécessite environ 17 GB de RAM rien que pour les poids, avant même de stocker un seul token de contexte. Les offres avec 8 GB et 16 GB sont donc totalement insuffisantes. Sur un VPS courant équipé de DDR4 à deux canaux, le débit maximal est d’environ 3 tokens par seconde, ce qui est plus lent que la vitesse de lecture de la plupart des utilisateurs.

D’où vient le 3.8 ? Il s’agit probablement d’une confusion avec le nombre de paramètres. La page Ollama de qwen3.6:27b indique 27.8B paramètres, et 27.8 peut facilement être retenu plus tard comme 3.8. Il existe également qwen3.5:27b, la même build Q4_K_M issue de la version précédente. Vérifiez la liste actuelle avant de copier une commande, sur la page des tags qwen3.6 d’Ollama. Si un véritable qwen3.8 est publié plus tard, les calculs présentés ici resteront valables, car ils dépendent du nombre de paramètres et du nombre de bits par poids, et non du numéro de version.

Quel tag Ollama télécharger et comment le vérifier

Le téléchargement d’un tag qui n’existe pas renvoie une erreur explicite. Vous pouvez donc régler rapidement ce point directement sur le serveur.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show affiche l’architecture, le nombre de paramètres, la longueur du contexte et la quantisation du tag que vous avez réellement installé. Si la ligne des paramètres indique 27.8B et que la ligne de quantisation indique Q4_K_M, vous utilisez le build ciblé par ce guide. La bibliothèque propose également qwen3.6:27b-q8_0 et qwen3.6:27b-bf16 pour les mêmes poids avec une précision supérieure, ainsi qu’un ensemble de tags 35b-a3b correspondant à des modèles MoE (mixture of experts), dont le comportement sur CPU est très différent. Ces modèles sont présentés plus loin.

Nombre de paramètres multiplié par le nombre d’octets par poids

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

La formule tient sur une ligne. Nombre d’octets des poids = paramètres * nombre de bits par poids / 8. Avec 4 bits exactement, 27.8 milliards de paramètres représenteraient 13.9 GB. Le tag Q4_K_M distribué fait 17 GB, ce qui correspond en pratique à 4.89 bits par poids.

Cet écart n’est pas une erreur. Les formats K-quant ne stockent pas chaque tenseur à la largeur nominale. Les tenseurs qui perdent le plus en qualité avec la compression sont conservés sur 5 ou 6 bits. Les couches d’embedding des tokens et de sortie restent généralement en Q6_K ou Q8_0. Le nom du format indique une moyenne, et cette moyenne est proche de 4.9. Le même effet apparaît à l’autre extrémité de l’échelle : 56 GB pour BF16 correspondent à 16.1 bits par poids, et non à 16 bits fixes, car le fichier contient aussi des métadonnées et une table d’embedding en pleine précision.

Q5_K_M ne dispose pas de tag publié pour ce modèle. La ligne de 19.8 GB est donc calculée avec les 5.7 bits par poids habituels de ce format, et non mesurée. Q8_0 fait presque doubler la taille par rapport à Q4, pour atteindre 30 GB. Sur une machine équipée uniquement d’un CPU, ce doublement double le trafic mémoire par token. Il réduit donc aussi approximativement de moitié le nombre de tokens par seconde. Pour cette seule raison, Q4_K_M est le choix par défaut adapté ici.

Le coût du cache KV augmente avec la longueur du contexte

Les poids représentent un coût fixe. Le cache KV (cache des clés et des valeurs, c’est-à-dire l’état d’attention que le modèle conserve pour chaque token déjà traité) augmente linéairement avec la longueur du contexte. C’est généralement là que la RAM vient à manquer.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Ces chiffres supposent l’architecture utilisée récemment par Qwen pour ses modèles denses de cette catégorie : 64 couches, 8 têtes key/value avec GQA (grouped-query attention) et une dimension de tête de 128. Cela représente 256 KiB par token en f16, soit 8 GB pour 32k tokens et 32 GB pour 128k. Ne considérez pas ces calculs comme valables pour votre propre machine. Chargez le modèle et consultez la colonne SIZE de ollama ps. Elle indique la taille totale des poids, du cache et de l’overhead.

C’est pourquoi le contexte de 256K affiché sur la fiche du modèle est une valeur mise en avant, pas un objectif pratique. Le remplir en f16 demanderait 64 GB de cache en plus des poids, alors que la machine utilise déjà 17 GB pour ces derniers. Ollama ne vous donne pas toute cette fenêtre par défaut. Il en charge une bien plus petite, que vous pouvez augmenter volontairement avec OLLAMA_CONTEXT_LENGTH. Augmentez-la progressivement et vérifiez ollama ps après chaque modification.

Deux réglages réduisent le cache de moitié ou davantage. OLLAMA_KV_CACHE_TYPE=q8_0 stocke le cache sur 8 bits au lieu de 16, ce qui fait passer la consommation pour 32k tokens de 8 GB à 4 GB. Ce réglage nécessite flash attention. Définissez donc aussi OLLAMA_FLASH_ATTENTION=1, puis vérifiez la baisse dans ollama ps au lieu de supposer qu’elle a bien été appliquée. OLLAMA_NUM_PARALLEL=1 est tout aussi important. Ollama peut traiter plusieurs requêtes simultanément, et chaque slot reçoit sa propre portion du contexte. Laisser le parallélisme à sa valeur par défaut multiplie donc discrètement la quantité de cache prévue.

Ce qui tient dans 8, 16, 32 et 64 Go de RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Lisez les deux nombres comme le nombre de milliers de tokens de contexte qui tiennent à côté des poids, avec un cache f16, sur un VPS Linux headless auquel il reste environ 1.5 Go pour le système d’exploitation et une petite marge supplémentaire. Un zéro signifie que les poids eux-mêmes ne tiennent pas. Rien ne peut donc tenir.

8 Go et 16 Go ne laissent presque aucune marge. 17 Go de poids ne tiennent pas dans 16 Go de RAM. Aucun réglage du contexte ne peut changer cela. Ajouter du swap ne résout pas non plus le problème. Ollama mappe le fichier GGUF en mémoire. Lorsque les pages résidentes dépassent la RAM, le kernel commence à les évacuer puis à les relire. Chaque token fait alors relire plusieurs gigaoctets depuis le disque. La machine reste en iowait élevé et produit nettement moins d’un token par seconde.

32 Go est le premier niveau utilisable. Les poids occupent 17 Go. Il vous reste environ 13 Go, ce qui permet environ 32k tokens de contexte f16 avec une marge. Les poids Q8_0 de 30 Go ne tiennent pas du tout dans cette configuration.

64 Go offrent une marge confortable. Avec Q4, il reste de la place pour environ 128k tokens de contexte. Les poids Q8_0 tiennent avec environ 64k tokens disponibles. Avant de payer 64 Go pour utiliser Q8, sachez précisément ce que vous achetez : une sortie légèrement meilleure, à la moitié de la vitesse, sur une machine déjà lente. Pour presque tout le monde, Q4 avec un contexte plus long constitue un meilleur compromis.

Quelle est la vitesse de l’inférence CPU sur un VPS ?

Générer un token à partir d’un modèle dense consiste à lire chaque poids en mémoire une fois. Pas seulement une partie. Tous les poids. La limite de vitesse ne dépend donc pas du nombre de cœurs, mais de la bande passante mémoire divisée par la taille des poids. En Q4, cela représente 17 Go de trafic mémoire par token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Il s’agit de plafonds théoriques, pas de mesures. En pratique, le débit atteint environ 50 à 70 % de la valeur indiquée, car la latence mémoire et le préchargement imparfait empêchent d’atteindre le maximum théorique. Un VPS équipé de deux canaux DDR4-3200 a un plafond de 3 tokens par seconde. Comptez donc environ 2. Une machine équipée de deux canaux DDR5-4800 a un plafond de 4.5 tokens par seconde. Comptez donc environ 3.

Les lignes correspondant aux gros serveurs doivent être interprétées avec prudence. Une plateforme EPYC à douze canaux offre 460.8 Go/s et un plafond de 27.1 tokens par seconde, mais vous ne louez pas un serveur EPYC entier. La bande passante mémoire est une ressource de l’hôte, partagée entre tous les tenants de cette machine. Une tranche de 8 vCPU ne bénéficie donc pas de douze canaux de bande passante exclusifs. Les guides axés sur les GPU ignorent souvent ce point. C’est pourquoi deux offres VPS ayant le même nombre de vCPU peuvent avoir des performances trois fois différentes avec le même modèle.

Ajouter des vCPU cesse rapidement d’améliorer les performances, pour la même raison. Dès que les cœurs demandent les données plus vite que le contrôleur mémoire ne peut les fournir, les threads supplémentaires ajoutent de la surcharge d’ordonnancement, sans autre bénéfice. Définissez OLLAMA_NUM_THREAD sur le nombre de cœurs physiques, mesurez les performances, puis essayez la moitié de cette valeur. Sur de nombreuses offres mutualisées, la valeur inférieure est plus rapide.

Le traitement du prompt se comporte différemment. Le prefill, c’est-à-dire le traitement de votre entrée avant l’apparition du premier token, dépend principalement de la puissance de calcul et non de la bande passante. Il s’accélère donc avec le nombre de cœurs. En pratique, une longue pause précède l’affichage de la sortie avec un prompt volumineux, puis le débit reste stable et lent, comme indiqué plus haut. Mesurez séparément ces deux phases avec --verbose. Cette commande affiche un prompt eval rate et un eval rate pour chaque requête.

Si le modèle dense 27B est simplement trop lent, examinez les tags qwen3.6:35b-a3b avant d’abandonner l’inférence CPU. Ceux-ci activent environ 3 milliards de paramètres par token au lieu des 27.8 milliards, ce qui réduit presque d’un facteur 10 le trafic mémoire par token, même si le fichier sur disque est plus volumineux. Vous échangez ainsi une empreinte RAM plus importante contre davantage de vitesse. Le choix du runtime compte également ici, et Ollama et llama.cpp exposent des contrôles de réglage CPU différents malgré l’utilisation du même code d’inférence sous-jacent.

Quand louer une heure de GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

La même formule appliquée à la bande passante mémoire GPU annoncée donne une réponse d’une autre catégorie. Une carte grand public de 24 GB atteint au maximum 59 tokens par seconde avec ces poids. Une carte actuelle de data center atteint 197. Vous ne comblerez pas cet écart en ajustant le nombre de threads. La carte fait fonctionner sa mémoire à 1008 GB/s, tandis que votre VPS atteint seulement quelques dizaines de GB/s.

Déterminez donc la limite selon la charge de travail, et non selon vos préférences. L’inférence sur CPU convient lorsque le traitement est asynchrone et que personne n’attend le résultat : résumé nocturne d’un ensemble de documents ou tâche de classification lancée chaque nuit pendant votre sommeil. Louez un GPU dès qu’une personne attend une réponse ou que les requêtes arrivent à un rythme supérieur à une toutes les 30 secondes. Un serveur limité au CPU ne dispose d’aucune marge pour le batching, et la file d’attente continue simplement de croître.

La comparaison des coûts est moins évidente qu’il n’y paraît. Un VPS de 64 GB est facturé chaque heure du mois, que le modèle soit chargé ou non, tandis qu’une instance GPU n’est facturée que pendant les heures où vous la laissez fonctionner. Si votre utilisation réelle est de deux heures par jour, le GPU loué peut être à la fois plus rapide et moins cher. Calculez d’abord votre taux d’utilisation, puis comparez les prix. Choisir un VPS avec un GPU explique les points à vérifier sur l’instance elle-même, et vLLM prend l’avantage sur Ollama lorsque vous servez des requêtes concurrentes sur un GPU parce qu’il les regroupe correctement.

Il existe une troisième option souvent oubliée. Conservez le 27B sur CPU pour les traitements par lots et utilisez un modèle d’API hébergé pour les requêtes interactives. Rien ne vous oblige à utiliser un seul modèle pour les deux usages.

Installer Ollama et mesurer votre machine

Le script d’installation est le script officiel. Il configure un service systemd exécuté avec un utilisateur ollama dédié.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version doit afficher 0.32.5 ou une version ultérieure. Vérifiez free -g avant de télécharger quoi que ce soit. Si la colonne total de la ligne Mem affiche une valeur inférieure à 32, arrêtez-vous ici et choisissez un modèle plus petit. Télécharger 17 GB que vous ne pouvez pas exécuter ferait perdre une heure et occuperait beaucoup d’espace disque.

Définissez les options d’exécution dans une surcharge systemd plutôt que dans votre shell. Le modèle s’exécute dans le service. Il ne voit donc jamais votre environnement interactif.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

La sortie de --verbose contient la mesure recherchée. eval rate correspond à votre débit en tokens par seconde pendant la génération. prompt eval rate correspond à la vitesse de prefill. load duration indique le temps nécessaire pour lire les poids depuis le disque. C’est pourquoi OLLAMA_KEEP_ALIVE=60m est défini : sur CPU, recharger 17 GB depuis le disque à chaque requête coûte plus cher que la requête elle-même.

Pendant que le modèle est chargé, vérifiez son empreinte depuis un second terminal.

ollama ps

La colonne SIZE indique l’empreinte mémoire réelle, cache KV compris. Elle doit être proche de la taille des poids, augmentée de la valeur correspondant à votre longueur de contexte dans le tableau KV. Avec 8192 tokens et un cache 8-bit, prévoyez environ un gigaoctet supplémentaire par rapport aux poids, contre 2 GB si le cache restait en f16. La colonne PROCESSOR doit afficher 100% CPU. Si elle affiche autre chose, un GPU a été utilisé et les mesures de vitesse de ce guide ne correspondent pas à votre machine.

Modes d’échec et chaînes exactes affichées

Le modèle refuse de se charger. Ollama affiche une ligne qui indique les deux valeurs, au format model requires more system memory (18.6 GiB) than is available (15.2 GiB). C’est l’échec attendu, car Ollama effectue la vérification avant l’allocation, au lieu de laisser le kernel gérer la situation. Réduisez la longueur du contexte, choisissez un tag plus petit ou passez à une offre supérieure.

Le processus disparaît au milieu d’une réponse. Le client n’affiche rien d’utile et journalctl -u ollama -n 50 indique que le service redémarre. Exécutez dmesg -T | tail. Une ligne contenant Out of memory: Killed process ... (ollama) signifie que l’OOM killer du kernel a arrêté le processus. Cela se produit lorsque la vérification préalable au chargement réussit, mais que le cache dépasse l’estimation pendant une longue conversation. Réduisez la longueur du contexte.

Le pull échoue immédiatement. Error: pull model manifest: file does not exist signifie que le tag n’existe pas dans la library. La commande qwen3.8:27b produit exactement ce résultat, comme toute faute de frappe dans le numéro de version. Vérifiez le tag sur la page de la library avant d’incriminer le réseau.

Tout fonctionne, mais les performances sont insupportablement lentes. Une vitesse inférieure à un token par seconde sur une machine disposant de suffisamment de RAM indique un paging plutôt qu’un manque de puissance de calcul. Exécutez vmstat 1 pendant la génération. Une valeur non nulle dans la colonne si ou so signifie que le kernel utilise le swap. La solution consiste à réduire le contexte ou le nombre de modèles chargés. Une valeur élevée et stable dans wa sans activité de swap signifie que les poids memory-mapped sont relus depuis le disque. Ils ne tiennent donc pas réellement en mémoire.

Le premier token met 30 secondes à arriver, puis la sortie accélère. Il s’agit du prefill, ce qui est normal. Un long system prompt doit être traité pour chaque requête qui ne bénéficie pas du cache. Raccourcissez donc le system prompt avant de modifier un autre paramètre.

À quoi sert réellement un modèle 27B sur CPU

Fixez vos attentes à partir des chiffres, pas de vos espoirs. À 2 à 4 tokens par seconde, une réponse de 500 tokens prend entre 2 et 4 minutes. C’est inutilisable pour un chat, mais parfaitement adapté à une file de traitement. La synthèse de documents, l’étiquetage en masse, l’extraction de champs depuis un ensemble de fichiers et la revue de code sans intervention tolèrent ce délai, car rien n’attend la réponse.

L’argument de la confidentialité est le principal. Le modèle s’exécute sur du matériel que vous louez et contrôlez, aucune requête ne quitte la machine et vous ne payez pas chaque token. Cela a beaucoup de valeur pour les données réglementées, même à 3 tokens par seconde. Comparez honnêtement cette solution à l’alternative : l’auto-hébergement d’un modèle de taille frontier nécessite un ordre de grandeur de matériel supplémentaire, et un modèle 27B sur CPU est le point le moins coûteux de cette courbe où la sortie reste lisible.

S’il s’agit de votre première installation d’Ollama, le guide complet pour exécuter Ollama sur un VPS couvre la configuration du service, l’API HTTP et les règles du firewall que ce guide suppose déjà en place. N’exposez pas le port 11434 à Internet. Ollama ne fournit aucune authentification native. Toute personne pouvant atteindre ce port peut utiliser votre modèle et lire vos prompts.

FAQ

Existe-t-il un modèle Qwen 3.8 27B sur Ollama ?

Non. Au 4 août 2026, la bibliothèque Ollama ne contient aucun espace de noms qwen3.8. Les tags 27B disponibles sont qwen3.5:27b et qwen3.6:27b, tous deux des builds Q4_K_M d’un modèle dense de 27.8 milliards de paramètres. Le 3.8 de votre recherche correspond presque certainement au nombre de paramètres 27.8B, mémorisé comme un numéro de version. Consultez https://ollama.com/library/qwen3.6/tags pour obtenir la liste actuelle et exécutez pull qwen3.6:27b` si vous voulez la version 27B la plus récente. Un tag inexistant échoue avec Error: pull model manifest: file does not exist`.

De quelle quantité de RAM ai-je besoin pour exécuter un modèle Qwen 27B sur un VPS ?

32 GB constituent le minimum pratique pour Q4_K_M. Les poids occupent 17 GB, le système d’exploitation nécessite environ 1.5 GB et le cache KV ajoute environ 1 GB par tranche de 4000 tokens de contexte en f16. Une offre de 16 GB ne peut même pas contenir les poids. Le swap n’aide pas, car le fichier est mappé en mémoire et le kernel le relit sur le disque à chaque token. 64 GB vous donnent la marge nécessaire pour un contexte long ou pour des poids Q8_0 de 30 GB.

Combien de tokens par seconde un modèle 27B fournira-t-il sur CPU ?

Divisez votre bande passante mémoire par la taille des poids, puis retenez 50 à 70 % de cette valeur. Un VPS DDR4-3200 à deux canaux atteint un plafond proche de 3 tokens par seconde et en fournit environ 2. Une machine DDR5-4800 à deux canaux atteint un plafond proche de 4.5 et en fournit environ 3. Les plateformes serveur dotées de davantage de canaux semblent bien meilleures sur le papier, mais la bande passante mémoire est partagée entre tous les tenants de l’hôte. Mesurez donc vos performances avec ollama run qwen3.6:27b --verbose et lisez la ligne eval rate.

Dois-je utiliser Q4 ou Q8 sur un VPS utilisant uniquement le CPU ?

Q4_K_M, dans presque tous les cas. Q8_0 occupe 30 GB contre 17 GB pour Q4_K_M. Il nécessite donc une offre de 64 GB et déplace presque deux fois plus de mémoire par token, ce qui réduit environ de moitié le nombre de tokens par seconde. Pour la plupart des tâches, la différence de qualité entre Q4_K_M et Q8_0 est faible sur un modèle 27B. Utilisez plutôt la RAM pour augmenter la longueur du contexte. Cela modifie les capacités du modèle, et pas seulement sa formulation.

Quand la location d’un GPU coûte-t-elle moins cher qu’un VPS avec beaucoup de RAM ?

Lorsque le taux d’utilisation est faible ou qu’une personne attend le résultat. Un GPU doté de 24 GB de mémoire atteint environ 59 tokens par seconde avec ces poids, contre 2 ou 3 sur un VPS courant. Il n’est facturé que pendant les heures d’utilisation. Un VPS de 64 GB est facturé pendant tout le mois, que le modèle soit chargé ou non. Calculez le nombre réel d’heures par jour pendant lesquelles vous générez des tokens. En dessous de deux ou trois heures, la location horaire d’un GPU est généralement plus rapide et moins chère. Le VPS toujours actif est plus avantageux pour les traitements batch continus et peu prioritaires.