Altman quiere tu DRAM en el data center: RAM de servidor 2026
Respuesta corta (comprobado el 2026-10-31): Sam Altman sostiene que la memoria de los ordenadores personales es un mal uso de un chip escaso y que rinde más en un centro de datos, donde se comparte. La oferta confirma la escasez: TrendForce esperaba que los precios de contrato de la DRAM para servidores subieran un 13-18% trimestral en el 3T26 y los de la DRAM convencional un 10-15% en el 4T26, con la DRAM de servidor todavía en déficit. Para quien alquila servidores la pregunta útil es más concreta: ¿cuánta de la RAM que ya paga usa de verdad? Abajo hay un script que lo mide y lo que nuestros planes cloud cobran por cada gigabyte extra.
Fuente. Altman habló en el podcast Cheeky Pint que presenta John Collison. Tom's Hardware y otros medios recogieron sus palabras el 2026-10-30, y se debatieron en Hacker News. Las citas van tal como las publican esos medios (en inglés, con nuestra traducción).
Qué dijo y qué no demostró
Hablando de inferencia local, Altman dijo que "a lot of people want local inference" (mucha gente quiere inferencia local) y supone que los modelos abiertos en sus propios ordenadores quitarán la necesidad de memoria en los centros de datos. Su respuesta: "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." Es decir, desde el reparto global es terrible que la DRAM limitada del mundo esté en el ordenador de cada uno y se use el 5% del tiempo. Y que, en un entorno tan limitado, se quiere la máxima utilización en la nube.
Conviene separar dos cosas. El argumento de la utilización es real y es todo el modelo de negocio del hosting compartido: la memoria de un servidor físico se vende a muchos clientes, así que menos de ella queda ociosa. Pero el 5% no tiene respaldo en la entrevista: ni estudio ni definición de "usada". Además, quien habla dirige una empresa cuyos modelos viven en centros de datos, y la conclusión conviene a su negocio. Nada de eso hace falsa la escasez; ambas cosas son motivo para medir su propio caso en lugar de adoptar la cifra de otro.
La escasez de memoria, con fechas
| Fecha | Qué pasó | Fuente |
|---|---|---|
| 2025-12-03 | Micron anunció su salida del negocio de consumo Crucial; los envíos al consumidor terminan con su trimestre fiscal Q2 (febrero de 2026) | Comunicado de Micron |
| 2026-07-09 | Precios de contrato de DRAM de servidor: se espera +13-18% trimestral en el 3T26; los acuerdos a largo plazo limitan las subidas para algunos compradores | TrendForce |
| 2026-09-30 | Precios de contrato de DRAM convencional: se espera +10-15% trimestral en el 4T26; la DRAM de servidor seguirá en déficit | TrendForce |
El orden importa a quien compra servidores. Los fabricantes desplazan su producción hacia productos para centros de datos y, aun así, la DRAM de servidor es la que TrendForce sigue llamando deficitaria. Los compradores con contratos plurianuales están en parte protegidos; una empresa pequeña que compra módulos para un servidor nuevo, o un proveedor que lo monta por encargo, paga cerca del precio de contrato actual.
Qué significa si alquilas servidores
- Servidores dedicados. Un servidor dedicado se monta con piezas a precios de hoy, y la RAM es una pieza cuyos precios de contrato TrendForce esperaba al alza durante todo 2026. Una configuración presupuestada en 2025 suele costar más ahora, y una ampliación de RAM en un servidor alquilado sigue el mismo mercado. Calcula tu equipo en el configurador de servidor dedicado; usa precios de piezas actuales.
- Servidores cloud. En la nube alquilas la memoria por porciones, es decir, el argumento de Altman a tu favor. En nuestros planes publicados (Praga, sin IVA, comprobado el 2026-10-31) Large (8 vCPU, 16 GB de RAM, 160 GB SSD) cuesta EUR 36.88 al mes y X-Large (8 vCPU, 32 GB de RAM, 160 GB SSD) EUR 59.92: los 16 GB extra cuestan EUR 23.04, o EUR 1.44 por GB al mes. Son precios de hoy, no una promesa para el año que viene.
- En ambos casos, la RAM ociosa es el coste que controlas. Un servidor dimensionado para un pico que nunca llega es la versión de sala de servidores del portátil que describe Altman.
Mide tu propio 5%: ramuse.py
Linux indica en /proc/meminfo cuánta memoria podría entregarse sin usar swap (MemAvailable). El total menos ese valor es lo que tu carga ocupa de verdad; la caché de páginas que el kernel puede liberar no cuenta. El script lo muestrea e imprime la media, el pico, lo que nunca se tocó y el tamaño potencia de dos más pequeño que cabe el pico más un 25% de margen. Python 3, solo biblioteca estándar, solo Linux. Guárdalo como 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
Salida, ejecutado en un servidor DCXV Cloud con Python 3.14.4 el 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)
Cómo leerlo. Es la máquina de 4 GB que escribe estos artículos, medida durante un minuto mientras lo hacía: ocupó 1,5 GiB como máximo y 2,2 GiB no se tocaron en ese intervalo. Un minuto no demuestra nada sobre el tamaño. Ejecútalo una semana con tráfico real, por ejemplo python3 ramuse.py 604800 300 > ramuse.txt dentro de tmux, y asegúrate de que la semana incluye tu día de más carga. Dos avisos: una base de datos o un servidor de ficheros usan la RAM libre como caché y van más rápido con ella, así que "never touched" no siempre es desperdicio; y un pico breve (una copia de seguridad, un despliegue) sigue siendo un pico que debe caber, o el kernel usará swap o matará un proceso. Las reglas por tipo de carga están en nuestra guía para dimensionar un servidor cloud.
Local, nube o servidor propio
El planteamiento de Altman tiene dos opciones: memoria en tu PC o memoria en su centro de datos. Una empresa tiene una tercera, un servidor que alquila y controla:
- Mantenerlo en local cuando los datos no deben salir del dispositivo o el trabajo es ocasional; esa RAM ya está pagada.
- Usar una API compartida cuando la demanda va a picos y los datos pueden ir a un tercero.
- Tener tu propio servidor en la UE cuando la carga es estable, los datos deben quedar bajo tu control o quieres elegir tú los pesos del modelo. La memoria necesaria por tamaño de modelo está en alojar LLM con Ollama en Europa, y los precios con 64 GB en cuánto cuesta un servidor con 64 GB de RAM.
La memoria es la parte cara este año, así que la tercera opción solo compensa si se dimensiona con una medición y no a ojo.
Dimensiona antes de comprar
Ejecuta el script una semana y elige plan según la línea "fits in". Nuestros centros de datos Tier III en Praga y Covilha ofrecen servidores cloud de hasta 256 GB de RAM; para una carga fija y pesada, un servidor dedicado configurado al pico medido. Envía la salida del script a sales@dcxv.com y te propondremos un tamaño.
