Quelqu’un de votre équipe a déjà évalué un workstation RTX 6000 Ada. Cela venait peut-être d’une proposition de fournisseur, peut-être d’un fil de forum sur la façon d’exécuter Llama localement, mais le chiffre qui a marqué était quelque part entre CHF 15 000 et 30 000, dépensés une fois, sans facture mensuelle après. C’est le pitch pour un cluster d’inférence local. Ce n’est pourtant pas tout à fait l’arithmétique correcte.
Cet article s’adresse à l’équipe qui a déjà décidé, pour des raisons de résidence des données, de langage contractuel ou d’obligations de secret professionnel, que l’inférence doit se produire sur un matériel que vous contrôlez. Si vous pesez toujours si aller entièrement on-prem, notre article compagnon sur qui construit réellement l’IA on-prem couvre cette décision : le fossé compétences, la question de localisation des données, et quand l’API gagne encore. Celui-ci suppose que vous avez déjà pris cette décision et passe en revue ce qu’un cluster d’inférence local est vraiment une fois que vous l’achetez. Et une fois qu’un workflow fonctionne dessus, si ce workflow lui-même est bien conçu est une question séparée, que nous couvrons dans comment nous réarchitecturons les processus autour des agents plutôt que de coller l’IA à n’importe quel processus existant.
Un cluster d’inférence local CHF 15 000 à 30 000 coûte grossièrement CHF 671 par mois une fois le matériel amorti sur trois ans et l’électricité suisse réaliste ajoutée. Mis en face d’un taux API mixte d’environ CHF 4,60 par million de tokens pour le trafic agent réel, ce coût fixe ne se rembourse que autour de 146 millions de tokens par mois mathématiquement, et plus réalistement autour de 250 à 300 millions une fois que vous comptabilisez comment le scaling sous-linéaire de la concurrence fonctionne réellement plutôt que la multiplication propre qu’une projection naïve suppose. Une équipe de 20 personnes effectuant 50 appels d’agent par jour, une ancre illustrative plutôt qu’une statistique de marché, n’atteint qu’environ 66 millions de tokens par mois. La lecture honnête est que l’inférence locale à ce niveau est fondamentalement une décision de résidence des données. Ne l’achetez pas en vous attendant à économiser de l’argent, car pour la plupart des PME l’arithmétique ci-dessous ne soutient pas cela.
Ce que CHF 15 000 à 30 000 achète vraiment
Trois parcours matériels se situent dans cette bande de budget à la mi-2026, et un quatrième vaut la peine d’être connu précisément parce qu’il ne l’est pas.
RTX 6000 Ada ou la plus nouvelle RTX Pro 6000 Blackwell, intégrées dans un châssis de workstation (Lenovo ThinkStation, Dell Precision), est la chose la plus proche d’un défaut. La carte Ada possède 48 Go de VRAM à 300W et un workstation complet autour de CHF 15 000 à 18 000. Passez à la carte Blackwell avec 96 Go à 600W et la même build se rapproche de CHF 25 000 à 30 000, le haut de cette gamme.
Une seule RTX 5090 est l’option grand public bon marché : 32 Go de VRAM, une build complète autour de CHF 8 000 à 12 000. Elle manque de mémoire ECC et du support des pilotes classe Quadro, mais de nombreux praticiens l’exécutent malgré tout une fois qu’ils ont affiné leur stack.
Une RTX A6000 reconditionnée attère dans la même bande CHF 8 000 à 12 000 alors que les entreprises retournent le matériel Ampere en 2026, et fonctionne 10 à 15 pour cent plus lentement que l’équivalent Ada en inférence tout en offrant les mêmes 48 Go.
Le Mac Studio M4 Max est l’exception, et pas dans la direction que vous attendriez. Une configuration mémoire unifiée 64 Go coûte grossièrement CHF 3 000 à 4 500, dramatiquement moins que n’importe quel parcours NVIDIA ci-dessus et pas une option plus chère et silencieuse au haut de la bande budget. Il n’a pas de GPU séparé à sourcer, exécute l’inférence via le framework MLX d’Apple plutôt que CUDA, et son faible coût compte plus que son silence.
Le chiffre qui compte plus que le prix ici est la puissance : un Mac Studio tire environ 60 watts au total, contre 600 watts à un kilowatt complet pour un workstation NVIDIA complet, cohérent avec l’évaluation comparative indépendante de la consommation électrique du matériel d’inférence. Cela décide où la machine peut vivre. Le Mac Studio s’assoit sur un bureau et reste silencieux ; les builds NVIDIA ont besoin d’un circuit 16 ampères dédié et d’une vraie ventilation. Ils fonctionnent aussi à 50 à 65 dBA en charge, assez fort pour le remarquer pendant un appel téléphonique. Une poignée d’équipes paient CHF 2 000 à 5 000 de plus pour une boucle de refroidissement liquide pour l’éviter.
Aucun d’entre eux n’a besoin d’une salle serveur, juste quelque part avec puissance et circulation d’air qui n’est pas le bureau de quelqu’un dans les cas NVIDIA, plus quelqu’un suffisamment technique pour installer le matériel et les pilotes.
Quels modèles de poids ouvert s’adaptent à cette enveloppe VRAM
La VRAM disponible décide quel modèle s’adapte. À 48 Go, le plafond pour les cartes Ada et A6000, un modèle dense de 32 milliards de paramètres fonctionne confortablement à quantification Q5 ou Q6 avec de la place pour une fenêtre de contexte décente. Les variantes Qwen 3.5 27B et les modèles Mistral denses similaires sont ici. Forcer un modèle 70B dans 48 Go à Q4 est techniquement possible mais laisse peu de marge pour les utilisateurs concurrents ou le contexte long, alors traitez-le comme un cas limite plutôt qu’un défaut.
Montez à 96 Go sur la carte Blackwell ou 64 Go de mémoire unifiée sur le Mac Studio, et les modèles classe 70B à quantification Q4 deviennent le défaut confortable. Llama 3.3 70B et Qwen 2.5 72B s’adaptent tous deux avec de la place pour une vraie fenêtre de contexte et une poignée de requêtes concurrentes. Llama 4 Scout de Meta, un modèle mixture-of-experts avec 17 milliards de paramètres actifs mais 109 milliards au total, s’adapte aussi aux cartes plus grandes une fois quantifié et se comporte bien sur les tâches de raisonnement long-contexte.
Ce qui ne s’adapte pas compte autant que ce qui s’adapte. Mistral Large 3, l’un des meilleurs reasoners open-weight entièrement à la mi-2026, porte 675 milliards de paramètres totaux et a besoin de deux à quatre GPUs classe H100 même à quantification agressive. C’est clairement le territoire de cluster entreprise, et aucune quantité de ruse de quantification ne l’apporte sur une seule carte workstation.
Spécifiquement sur l’appel d’outils, les plus petites variantes de Qwen 3.5 mènent les évaluations indépendantes de la performance d’appel d’outils open-weight. Les classements de benchmark, cependant, ne prédisent pas de manière fiable comment un modèle se comportera contre votre toolset personnel au niveau de quantification que vous envisagez d’exécuter, en utilisant votre propre modèle de chat. Testez les définitions d’outils de votre agent contre exactement cette stack avant de vous engager sur un modèle en production.
Le plafond de débit honnête
Un seul GPU workstation ne se comporte pas comme un point de terminaison API avec concurrence illimitée. Sur un modèle 70B à quantification Q4, la RTX 6000 Ada et la A6000 livrent grossièrement 40 à 50 tokens par seconde à un utilisateur, et tiennent bon pour 4 à 10 utilisateurs concurrents avant que les temps de réponse ne commencent à grimper au-delà de quelques secondes. L’évaluation de concurrence publiée la plus proche exécute un modèle 27B sur la carte Blackwell plus chère plutôt que la build Ada/A6000 de ce document. Elle a mesuré 46 tokens par seconde pour un utilisateur à contexte 1K, baissant à grossièrement 26 à 30 tokens par seconde par flux à trois utilisateurs concurrents. Le débit agrégé était encore en hausse plutôt que en effondrement.
Au-delà de 10 à 15 requêtes concurrentes, le cache KV, qui est la mémoire GPU contenant l’état de la conversation active, se remplit. Le serveur permute alors cet état vers la RAM système pour continuer. Chaque permutation coûte en latence, et au-delà d’un certain point, le système entier ralentit pour tout le monde connecté plutôt que d’échouer élégamment juste pour la demande la plus nouvelle.
Le Mac Studio échange la vitesse pour le silence : 20 à 28 tokens par seconde pour un seul utilisateur sur un modèle 70B. Ce plafond la limite probablement à deux à cinq utilisateurs concurrents, puisque personne n’a encore publié des évaluations de concurrence rigoureuses pour elle. L’RTX 5090 fonctionne un peu plus vite que la carte Ada pour un utilisateur seul, dans la gamme 60 à 70 tokens par seconde, mais partage les mêmes limites de concurrence.
C’est la capacité pour l’outil interne d’une équipe. Elle tombe bien en deçà de ce qu’un widget support face aux clients ou un centre d’appels a besoin, et la traiter comme telle est le moyen le plus rapide de décevoir quiconque l’a demandé.
La couche de service : vLLM, SGLang ou Ollama
Trois serveurs d’inférence couvrent essentiellement tous les déploiements workstation en 2026, et choisir entre eux importe plus que de choisir entre GPUs.
vLLM est le défaut pour tout ce qui a plus d’un utilisateur. Son astuce principale, PagedAttention, regroupe la mémoire GPU pour les conversations actives plutôt que de réserver un bloc fixe par requête, réduisant les gaspillages mémoire d’environ 60 à 80 pour cent jusqu’à environ 4 pour cent et doublant à quadruplant le débit par rapport au batching naïf sur la même carte. C’est le standard de production chez Meta, Mistral AI, Cohere et IBM, un signal raisonnable pour une infrastructure que personne ne veut chaperonner.
**SGLang gagne sa place quand vos agents émettent une sortie structurée, des appels d’outils JSON ou des champs d’extraction formatés, répétitivement dans une boucle serrée. Il est purpose-built pour la génération contrainte et mesure grossièrement 29 pour cent de débit plus élevé que vLLM sur les charges où les requêtes partagent un contexte, le modèle classique dans un agent appel d’outils chaînant plusieurs appels par tour.
**Ollama mérite sa popularité pour exactement un travail : faire fonctionner un modèle en moins de cinq minutes pour voir si c’est la peine de poursuivre. Il n’a pas de contrôles de ressources granulaires et ne s’adapte pas au-delà de l’usage utilisateur seul, et la déployer comme la couche service pour un outil d’équipe partagé est le moyen singulier le plus courant par lequel les gens laissent du débit sur la table à ce niveau matériel.
Commencez avec vLLM à moins qu’une charge lourdement orientée vers la sortie structurée ne vous pointe vers SGLang. Les deux sont open source avec des communautés actives, et basculer entre eux plus tard est un changement de configuration plutôt qu’une reconstruction.
Quantification : ce que Q4 vous coûte réellement
À ce niveau matériel, la VRAM est presque toujours la contrainte contraignante. Cela rend la quantification Q4, spécifiquement Q4_K_M, le défaut plutôt qu’un compromis. Elle réduit l’utilisation mémoire d’environ 75 pour cent et accélère l’inférence 3 à 4 fois, la seule raison pour laquelle un modèle 70B s’adapte à une seule carte du tout.
Cet économie n’est pas gratuit. Q4 coûte grossièrement 1 à 2 pour cent de qualité mesurable sur les modèles de 30B et plus grands, une perte que la plupart des charges agent ne remarqueront pas en pratique. Sur les modèles en dessous de 7B, la même quantification coûte 5 à 10 pour cent. Cela se montre comme un taux d’analyse JSON genuinely pire ou un argument d’outil subtlement faux. Ces défaillances sont faciles à manquer dans une démo et coûteuses à manquer en production.
FP8 est l’alternative plus douce où le matériel le supporte nativement, principalement sur les cartes classe Blackwell. La perte de qualité s’assoit plus près de 0,3 à 0,5 points sur les benchmarks standard. Elle ne libère pas la VRAM que Q4 fait, donc la plupart des déploiements workstation exécutent Q4 par nécessité plutôt que par choix.
Quelle que soit la quantification sur laquelle vous atterrissez, testez-la contre votre propre modèle de chat et schéma d’outils avant de la déployer. Un modèle qui analyse le JSON parfaitement à précision complète peut commencer à perdre des champs à Q4. Le seul moyen de savoir est d’exécuter votre propre ensemble d’évaluation à travers exactement la stack que vous prévoyez d’expédier.
L’économie : coût fixe contre utilisation variable
Voici l’arithmétique derrière ce résumé.
Prenez le workstation RTX 6000 Ada comme build de référence, puisqu’il se situe à mi-gamme. CHF 18 000 amortis sur 36 mois coûte CHF 500 par mois en matériel seul. Un système d’environ 1kW exécuté en permanence tire environ 720 kWh par mois ; au tarif commercial ElCom de CHF 0,237 par kWh, ce sont CHF 171 par mois en électricité. Le coût fixe total attère autour de CHF 671 par mois, dans une gamme d’environ CHF 650 à 700 selon votre tarif local, que la machine reste inactive la nuit ou fonctionne à plein.
Mettez cela en face d’un taux API mixte d’environ CHF 4,60 par million de tokens pour le trafic agent réel, basé sur la tarification actuelle de l’API du modèle frontier mélangée entre les tokens d’entrée et de sortie dans un ratio réaliste quatre-à-un, le modèle qu’un appel agent typique supporté par retrieval produit réellement. Cela se situe délibérément au-dessus du taux le moins cher sur le marché, puisqu’il reflète un mélange réaliste pour les charges agent au lieu d’une figure input-only meilleur cas.
Divisez le coût fixe par ce taux et vous obtenez le point de rentabilité mathématique : grossièrement 146 millions de tokens par mois. Cela suppose que vous puissiez réellement le soutenir, et les données de concurrence ci-dessous montrent que c’est plus difficile qu’il n’y paraît : le débit s’adapte bien en deçà linéairement alors que plus d’utilisateurs partagent un GPU, poussant le seuil réaliste plus haut que ce que les mathématiques brutes suggèrent.
L’utilisation décide votre coût réel par token bien plus que le matériel que vous achetez. Les lignes multi-utilisateur ci-dessous utilisent une gamme, expliquée sous la tableau :
| Charge (illustrative, build de référence RTX 6000 Ada) | Tokens mensuels | Coût fixe | Coût par million de tokens |
|---|---|---|---|
| 1 utilisateur, continu à 45 tokens/seconde | ~117 millions | CHF 671 | CHF 5,74 |
| 10 utilisateurs concurrents, continu (scaling sous-linéaire) | ~207 à 518 millions | CHF 671 | CHF 1,30 à 3,25 |
| 1 utilisateur, utilisation réaliste 15% | ~17,5 millions | CHF 671 | CHF 38 |
| 10 utilisateurs, utilisation réaliste 30% (scaling sous-linéaire) | ~62 à 155 millions | CHF 671 | CHF 4,30 à 10,80 |
Dix utilisateurs concurrents ne fournissent pas dix fois le débit d’un utilisateur : ils concourent pour la même mémoire GPU et le calcul plutôt que chacun d’obtenir une tranche dédiée. Un évaluation de concurrence publiée sur une carte comparable situe le multiplicateur agrégé réaliste autour de 1,8 à 4,4 fois le taux d’un utilisateur seul plutôt que 10 fois, la base pour les gammes ci-dessus.
Cette correction remodèle chaque ligne. La ligne utilisateur seul continu échoue toujours en deçà de l’API exécutée à plein régime, puisque 117 millions de tokens par mois se situe en deçà des 146 millions de rentabilité. La ligne utilisateur dix continu est le cas genuinely fort pour le matériel local, à CHF 1,30 à 3,25 par million de tokens même à l’extrémité conservatrice. La ligne utilisateur dix, utilisation 30 pour cent est celle à lire attentivement. Sa gamme, CHF 4,30 à 10,80 par million de tokens, chevauche le taux API plutôt que de le battre directement. Un outil partagé modérément utilisé est plus proche d’un lancer de pièce contre l’API qu’une victoire nette.
C’est aussi d’où le seuil réaliste 250 à 300 millions dans le résumé ci-dessus vient : battre l’API avec marge réelle signifie fonctionner proche du modèle utilisateur dix continu plutôt que le modèle utilisation trente-pour-cent léger que la plupart des outils partagés voient réellement. Une équipe de 20 personnes effectuant 50 appels d’agent par jour à environ 3 000 tokens par appel, illustrative plutôt que sondage de marché, atteint environ 66 millions de tokens par mois ; une équipe de 50 personnes au même rythme atteint environ 165 millions. Les deux se situent bien en deçà d’une marge confortable au-dessus du seuil de rentabilité, ce qui est le point : le volume de tokens seul n’arrive rarement à une PME typique là. C’est le même trade-off que notre modèle TCO pour l’agent IA personnalisé par rapport à l’infrastructure de plateforme examine en termes plus généraux.
L’économie du Mac Studio ressemble différente une fois que son prix est corrigé. CHF 4 000 amortis sur 36 mois est CHF 111 par mois. Ajoutez sa consommation d’environ 60 watts et le coût fixe total attère près de CHF 120 par mois. Cela place son seuil de rentabilité mathématique autour de 26 millions de tokens, un volume qu’un seul utilisateur continu exécutant ses 20 à 28 tokens par seconde nettoie seul. La build NVIDIA plus chère ne peut pas gérer cela même à saturation complète. Le trade-off est réel : moins de marge VRAM pour les utilisateurs concurrents et un plafond de débit qui ne servira qu’une poignée de personnes. Pour un seul analyste ou une équipe de deux personnes avec une exigence de résidence des données genuine, c’est le point de départ le plus défendable des quatre.
Rien de cela n’inclut le coût de construire réellement le workflow agent qui appelle le modèle, qui suit les mêmes niveaux indépendamment de l’infrastructure à laquelle il parle.
Ce qui casse après l’installation, et qui le possède
Acheter le matériel est la partie facile. Ce qui détermine si le cluster est toujours utile au mois six est une série de tâches ingrates, non glamoureuses, que personne ne budgétise au moment de l’achat.
La configuration prend une à deux semaines pour quelqu’un qui l’a fait avant : assembler le matériel, installer les pilotes, mettre en place vLLM ou Ollama, et télécharger un fichier modèle de 70 Go plus, ce qui seul peut prendre des heures sur une connexion de bureau typique. Plus simple que de mettre en place un cluster Kubernetes, mais pas plug-and-play.
Les nouvelles versions de modèles arrivent grossièrement tous les trimestres. Chacune a besoin d’être téléchargée, évaluée contre un ensemble de test de vraies questions et réponses connues bonnes, et une décision délibérée sur la permutation ou non. Sautez cette étape et les modèles se dégradent silencieusement : les mêmes prompts produisent des réponses subtlement pires, et personne ne le remarque jusqu’à ce qu’un utilisateur se plaigne.
Il n’y a pas de redondance à ce niveau. Un seul workstation est un seul point de défaillance : si le GPU meurt, vous êtes bas jusqu’à ce que vous sourciez un remplacement ou basculiez vers une API, typiquement un jour ou deux, à moins que vous n’ayez construit un chemin de secours à l’avance.
Le monitoring est ad hoc par défaut. Les clusters d’entreprise reçoivent des tableaux de bord d’observabilité appropriés ; un workstation dans un placard reçoit généralement rien au-delà d’une vérification ping, qui vous dit la disponibilité et rien sur si les réponses sont toujours bonnes, la métrique qui importe réellement.
Mis ensemble, cela exécute grossièrement 20 à 30 pour cent du temps continu d’une personne, chaque mois, tant que le cluster reste en production. Il n’a pas besoin d’une embauche dédiée, mais il a besoin de quelqu’un nommé, avec du temps creusé avant que le matériel n’arrive plutôt qu’après la première réponse gênante fausse. Le risque opérationnel ici renvoie notre regard plus large sur les risques de sécurité des agents IA : un déploiement non surveillé, sous-possédé devient souvent une plus grande exposition que le choix d’infrastructure visait à réduire en premier lieu.
Quand c’est le bon choix
Quelques exemples travaillés montrent le modèle. Une firme comptable suisse de 15 personnes à 100 millions de tokens par mois, sans contrainte de confidentialité au-delà de la discrétion ordinaire : l’API est moins chère, et personne ne peut dégager 20 à 30 pour cent du temps d’un ingénieur. Une pratique légale de 25 personnes à 150 millions de tokens par mois franchit le seuil de rentabilité mathématique mais tombe en deçà du seuil réaliste 250 à 300 millions, donc les chiffres seuls penchent vers l’API même ici. Une firme de services financiers de 40 personnes à 300 millions plus de tokens par mois, avec de vraies contraintes de réglementation et quelqu’un déjà sur le personnel pour posséder l’infrastructure, est le oui net.
Ce cas du milieu est où la plupart des décisions genuines de inférence locale en Suisse se produisent réellement. Le volume seul n’atteint rarement le seuil de rentabilité. La traction vers le matériel local vient plutôt de la LPD, du RGPD où les données EU sont concernées, du secret professionnel selon l’article 321 du Code pénal suisse, des attentes de la FINMA pour le secteur financier régulementé, ou d’une clause contractuelle de localisation des données qu’une équipe juridique d’un client a déjà écrite.
Achetez le workstation quand : la résidence des données est une exigence absolue qu’une API cloud ne peut vraiment pas satisfaire, votre cas d’usage interne peut tolérer 4 à 10 utilisateurs concurrents et quelques secondes de latence, et quelqu’un de l’équipe peut posséder la sélection et l’évaluation du modèle comme une tâche continue plutôt qu’une tâche ponctuelle.
Passez quand : rien de réglementaire ou contractuel ne force la décision, votre volume mensuel se situe dans les dizaines de millions de tokens plutôt que les centaines, ou vous avez besoin de disponibilité et de concurrence face aux clients qu’une seule carte n’a jamais été construite pour livrer. Dans chacun de ces cas, louer de la capacité GPU auprès d’un fournisseur hébergé en Suisse ou rester sur une API publique coûte moins et demande moins à votre équipe, au moins jusqu’à ce que le volume et la pression réglementaire pointent tous les deux dans la même direction.
Questions fréquentes
Combien coûte chaque mois l'exécution d'un cluster d'inférence local ?
Un cluster d'inférence local classe workstation dans la gamme CHF 15 000 à 30 000 coûte grossièrement CHF 671 par mois une fois le matériel amorti sur trois ans et l'électricité commerciale suisse ajoutée. Ce chiffre change à peine que la machine reste inactive ou fonctionne en permanence, ce qui fait que le facteur déterminant pour battre un abonnement API est l'utilisation plutôt que le prix d'achat.
Un cluster d'inférence local est-il moins cher qu'une API comme Claude ou GPT ?
Uniquement à haut volume soutenu. Le seuil de rentabilité mathématique par rapport à un taux API mixte d'environ CHF 4,60 par million de tokens se situe autour de 146 millions de tokens par mois, et le seuil réaliste une fois que vous comptabilisez comment le débit évolue réellement avec les utilisateurs concurrents est plus proche de 250 à 300 millions. Une équipe de 20 personnes effectuant 50 appels d'agent par jour n'atteint qu'environ 66 millions de tokens par mois, bien en deçà de l'un ou l'autre chiffre, donc pour eux l'API reste l'option la moins chère.
Combien d'utilisateurs un GPU de classe workstation CHF 15 000 à 30 000 peut-il réellement supporter ?
Réalistement 4 à 10 utilisateurs concurrents sur un modèle de 70 milliards de paramètres à quantification 4 bits, un utilisateur seul obtenant 40 à 50 tokens par seconde. Au-delà de 10 à 15 requêtes concurrentes, le GPU manque de mémoire pour suivre les conversations actives et les temps de réponse grimpe fortement. Ce niveau convient à un outil interne pour une équipe plutôt qu'à un chatbot face aux clients traitant plusieurs conversations simultanées.
Quels modèles de poids ouvert s'adaptent réellement à ce matériel ?
Avec 48 à 96 Go de VRAM, les modèles denses et mixture-of-experts dans la classe 30 à 70 milliards de paramètres s'adaptent à quantification Q4, y compris Llama 3.3 70B, Qwen 2.5 72B et les plus petites variantes Qwen 3.5 conçues pour les workflows riches en outils. Les modèles frontier open-weight comme Mistral Large 3, conçu pour les clusters multi-GPU d'entreprise, ne s'adaptent pas à une seule carte workstation à aucun niveau de quantification.
Quand l'inférence locale a-t-elle du sens pour une petite ou moyenne entreprise ?
Principalement quand la résidence des données est une exigence absolue imposée par la LPD, le RGPD là où les données EU sont concernées, le secret professionnel selon l'article 321 du Code pénal suisse, les attentes de la FINMA pour le secteur financier régulementé, ou une clause contractuelle de localisation des données, et une API publique ne peut pas vraiment la satisfaire. En dehors de ce cas, le coût et le fardeau d'entretien battent rarement la location de capacité GPU ou le paiement au token, puisque la plupart des entreprises n'atteignent jamais le volume soutenu où la possession se rembourse.