Altman veut votre DRAM au data center : RAM serveur 2026
En bref (vérifié le 2026-10-31) : Sam Altman estime que la mémoire des ordinateurs personnels est un mauvais usage d'une puce rare et qu'elle travaille davantage dans un data center, où elle est partagée. L'offre confirme la pénurie : TrendForce prévoyait une hausse des prix contractuels de la DRAM serveur de 13 à 18% d'un trimestre à l'autre au 3T26 et de la DRAM conventionnelle de 10 à 15% au 4T26, la DRAM serveur restant déficitaire. Pour qui loue des serveurs, la question utile est plus étroite : quelle part de la RAM que vous payez déjà utilisez-vous vraiment ? Voici un script qui la mesure, et ce que nos offres cloud facturent par gigaoctet supplémentaire.
Source. Altman s'exprimait dans le podcast Cheeky Pint animé par John Collison. Tom's Hardware et d'autres ont rapporté ses propos le 2026-10-30, discutés sur Hacker News. Les citations sont reprises telles que ces articles les publient (en anglais, avec notre traduction).
Ce qu'il a dit, et ce qu'il n'a pas montré
À propos de l'inférence locale, Altman a dit que "a lot of people want local inference" (beaucoup veulent de l'inférence locale) et pensent que des modèles ouverts sur leurs propres machines supprimeront le besoin de mémoire dans les data centers. Sa réponse : "From a global allocation perspective, actually, it's quite terrible to have everybody have a bunch of the world's limited supply of DRAM sitting in their own computer and being used 5% of the time." Autrement dit, du point de vue de la répartition mondiale, il est désastreux que la DRAM limitée du monde dorme dans chaque ordinateur et ne serve que 5% du temps. Et, dans un contexte aussi contraint, on veut une utilisation maximale dans le cloud.
Il faut séparer deux choses. L'argument de l'utilisation est réel et c'est tout le modèle économique de l'hébergement mutualisé : la mémoire d'un serveur physique est vendue à de nombreux clients, donc moins de mémoire reste inactive. Mais rien dans l'entretien n'appuie le chiffre de 5% : ni étude, ni définition de "utilisée". Et l'orateur dirige une entreprise dont les modèles tournent en data center, la conclusion sert donc son activité. Aucun de ces points ne rend la pénurie fausse ; tous deux invitent à mesurer votre propre cas au lieu d'adopter le chiffre d'un autre.
La pénurie de mémoire, datée
| Date | Ce qui s'est passé | Source |
|---|---|---|
| 2025-12-03 | Micron annonce sa sortie de l'activité grand public Crucial ; les livraisons grand public s'arrêtent avec son trimestre fiscal Q2 (février 2026) | Communiqué de Micron |
| 2026-07-09 | Prix contractuels de la DRAM serveur attendus en hausse de 13 à 18% sur le trimestre au 3T26 ; les contrats à long terme limitent les hausses pour certains acheteurs | TrendForce |
| 2026-09-30 | Prix contractuels de la DRAM conventionnelle attendus en hausse de 10 à 15% sur le trimestre au 4T26 ; la DRAM serveur reste déficitaire | TrendForce |
L'ordre compte pour les acheteurs de serveurs. Les fabricants déplacent leur production vers les produits pour data center, et pourtant c'est la DRAM serveur que TrendForce qualifie encore de déficitaire. Les acheteurs sous contrat pluriannuel sont en partie protégés ; une petite entreprise qui achète des barrettes pour un nouveau serveur, ou un fournisseur qui en monte un sur commande, paie près du prix contractuel du moment.
Ce que cela change si vous louez des serveurs
- Serveurs dédiés. Un serveur dédié est monté avec des pièces aux prix du jour, et la RAM est une pièce dont TrendForce prévoyait la hausse des prix contractuels tout au long de 2026. Une configuration chiffrée en 2025 coûte en général plus cher à monter aujourd'hui, et une extension de RAM sur un serveur loué suit le même marché. Chiffrez votre machine dans le configurateur de serveur dédié : il utilise les prix actuels des pièces.
- Serveurs cloud. Dans le cloud, vous louez la mémoire par tranches : l'argument d'Altman joue alors pour vous. Sur nos offres publiées (Prague, HT, vérifié le 2026-10-31), Large (8 vCPU, 16 Go de RAM, 160 Go SSD) coûte EUR 36.88 par mois et X-Large (8 vCPU, 32 Go de RAM, 160 Go SSD) EUR 59.92 : les 16 Go supplémentaires coûtent EUR 23.04, soit EUR 1.44 par Go et par mois. Ce sont les prix d'aujourd'hui, pas une promesse pour l'an prochain.
- Dans les deux cas, la RAM inactive est le coût que vous maîtrisez. Un serveur dimensionné pour un pic qui ne vient jamais est la version salle serveur de l'ordinateur portable dont parle Altman.
Mesurez vos propres 5% : ramuse.py
Linux indique dans /proc/meminfo combien de mémoire pourrait être allouée sans swap (MemAvailable). Le total moins cette valeur, c'est ce que votre charge occupe réellement ; le cache de pages que le noyau peut libérer n'est pas compté. Le script l'échantillonne et affiche la moyenne, le pic, ce qui n'a jamais été touché et la plus petite puissance de deux qui contient le pic plus 25% de marge. Python 3, bibliothèque standard, Linux uniquement. Enregistrez-le sous ramuse.py :
#!/usr/bin/env python3
"""ramuse.py - how much of this server's RAM is actually used.
Samples /proc/meminfo (used = MemTotal - MemAvailable) and prints the
average, the peak, what was never touched and a right-sized RAM figure.
usage: python3 ramuse.py [seconds] [interval]"""
import sys, time
def meminfo():
m = {}
with open('/proc/meminfo') as f:
for line in f:
k, v = line.split(':')
m[k] = int(v.split()[0]) # kB
return m['MemTotal'], m['MemTotal'] - m['MemAvailable']
dur = int(sys.argv[1]) if len(sys.argv) > 1 else 60
step = int(sys.argv[2]) if len(sys.argv) > 2 else 5
used = []
for i in range(max(1, dur // step)):
total, u = meminfo()
used.append(u)
if i < dur // step - 1:
time.sleep(step)
g = 1024 * 1024 # kB per GiB
avg, peak = sum(used) / len(used), max(used)
fit = 1
while fit < peak * 1.25 / g: # peak + 25 % headroom, next power of two
fit *= 2
print(f'samples {len(used)} x {step} s')
print(f'total {total / g:.1f} GiB')
print(f'used avg {avg / g:.1f} GiB ({100 * avg / total:.0f}%)')
print(f'used peak {peak / g:.1f} GiB ({100 * peak / total:.0f}%)')
print(f'never touched {(total - peak) / g:.1f} GiB')
print(f'fits in {fit} GiB (peak + 25%, next power of 2)')
python3 ramuse.py 60 5
Résultat, exécuté sur un serveur DCXV Cloud avec Python 3.14.4 le 2026-10-31 :
samples 12 x 5 s
total 3.7 GiB
used avg 1.5 GiB (40%)
used peak 1.5 GiB (40%)
never touched 2.2 GiB
fits in 2 GiB (peak + 25%, next power of 2)
Comment le lire. C'est la machine de 4 Go qui rédige ces articles, mesurée pendant une minute alors qu'elle le faisait : 1,5 Gio au maximum, et 2,2 Gio jamais touchés sur cette période. Une minute ne prouve rien sur le dimensionnement. Lancez le script une semaine sous trafic réel, par exemple python3 ramuse.py 604800 300 > ramuse.txt dans tmux, en vérifiant que la semaine inclut votre jour le plus chargé. Deux mises en garde : une base de données ou un serveur de fichiers se sert de la RAM libre comme cache et va plus vite avec, donc "never touched" n'est pas toujours du gaspillage ; et un pic bref (une sauvegarde, un déploiement) reste un pic qui doit tenir, sinon le noyau swappe ou tue un processus. Les règles par type de charge sont dans notre guide de dimensionnement d'un serveur cloud.
En local, dans le cloud ou sur votre propre serveur
Le cadre d'Altman n'a que deux options : la mémoire dans votre PC ou dans son data center. Une entreprise en a une troisième, un serveur qu'elle loue et contrôle :
- Rester en local quand les données ne doivent pas quitter l'appareil ou que le travail est ponctuel ; cette RAM est déjà payée.
- Passer par une API partagée quand la demande arrive par pics et que les données peuvent aller chez un tiers.
- Avoir votre propre serveur dans l'UE quand la charge est régulière, que les données doivent rester sous votre contrôle ou que vous voulez choisir vous-même les poids du modèle. La mémoire nécessaire par taille de modèle est dans héberger des LLM avec Ollama en Europe, et les prix avec 64 Go dans combien coûte un serveur avec 64 Go de RAM.
La mémoire est la partie chère cette année : la troisième option n'est rentable que si elle est dimensionnée sur une mesure, pas au jugé.
Dimensionner avant d'acheter
Lancez le script une semaine, puis choisissez une offre d'après la ligne "fits in". Nos data centers Tier III de Prague et Covilha proposent des serveurs cloud jusqu'à 256 Go de RAM ; pour une charge lourde et stable, un serveur dédié configuré sur le pic mesuré. Envoyez la sortie du script à sales@dcxv.com et nous vous proposerons une taille.
