Altman quer a sua DRAM no data center: RAM de servidor 2026
Resposta curta (verificado em 2026-10-31): Sam Altman defende que a memória dos computadores pessoais é um mau uso de um chip escasso e que rende mais num data center, onde é partilhada. A oferta confirma a escassez: a TrendForce previa que os preços de contrato da DRAM de servidor subissem 13-18% em cadeia no 3T26 e os da DRAM convencional 10-15% no 4T26, com a DRAM de servidor ainda em défice. Para quem aluga servidores, a pergunta útil é mais estreita: quanta da RAM que já paga usa de facto? Abaixo está um script que o mede e o que os nossos planos cloud cobram por cada gigabyte extra.
Fonte. Altman falou no podcast Cheeky Pint, apresentado por John Collison. O Tom's Hardware e outros noticiaram as declarações em 2026-10-30, que foram discutidas no Hacker News. As citações seguem o texto publicado por esses meios (em inglês, com a nossa tradução).
O que ele disse e o que não demonstrou
A falar de inferência local, Altman disse que "a lot of people want local inference" (muita gente quer inferência local) e assume que os modelos abertos nos próprios computadores vão eliminar a necessidade de memória nos data centers. A resposta dele: "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." Ou seja, do ponto de vista da distribuição global é péssimo que a DRAM limitada do mundo esteja no computador de cada um e seja usada 5% do tempo. E que, num ambiente tão restrito, se quer a utilização máxima na cloud.
Convém separar duas coisas. O argumento da utilização é real e é todo o modelo de negócio do alojamento partilhado: a memória de um servidor físico é vendida a muitos clientes, por isso menos dela fica parada. Mas o número de 5% não tem apoio na entrevista: nem estudo, nem definição de "usada". E quem fala dirige uma empresa cujos modelos vivem em data centers, pelo que a conclusão serve o seu negócio. Nada disto torna a escassez falsa; ambos os pontos são razões para medir o seu caso em vez de adotar o número de outro.
A escassez de memória, com datas
| Data | O que aconteceu | Fonte |
|---|---|---|
| 2025-12-03 | A Micron anunciou a saída do negócio de consumo Crucial; as entregas ao consumidor terminam com o seu trimestre fiscal Q2 (fevereiro de 2026) | Comunicado da Micron |
| 2026-07-09 | Preços de contrato da DRAM de servidor: previsão de +13-18% em cadeia no 3T26; os acordos de longo prazo limitam as subidas para alguns compradores | TrendForce |
| 2026-09-30 | Preços de contrato da DRAM convencional: previsão de +10-15% em cadeia no 4T26; a DRAM de servidor continua em défice | TrendForce |
A ordem importa para quem compra servidores. Os fabricantes estão a desviar produção para produtos de data center e, mesmo assim, é a DRAM de servidor que a TrendForce continua a dar como deficitária. Compradores com contratos plurianuais estão em parte protegidos; uma pequena empresa que compra módulos para um servidor novo, ou um fornecedor que o monta por encomenda, paga perto do preço de contrato atual.
O que significa se aluga servidores
- Servidores dedicados. Um servidor dedicado é montado com peças a preços de hoje, e a RAM é uma peça cujos preços de contrato a TrendForce previa em alta ao longo de 2026. Uma configuração orçamentada em 2025 custa normalmente mais a montar agora, e um aumento de RAM num servidor alugado segue o mesmo mercado. Faça as contas no configurador de servidor dedicado; usa preços de peças atuais.
- Servidores cloud. Na cloud aluga a memória às fatias, ou seja, o argumento de Altman a seu favor. Nos nossos planos publicados (Praga, sem IVA, verificado em 2026-10-31) o Large (8 vCPU, 16 GB de RAM, 160 GB SSD) custa EUR 36.88 por mês e o X-Large (8 vCPU, 32 GB de RAM, 160 GB SSD) EUR 59.92: os 16 GB extra custam EUR 23.04, ou EUR 1.44 por GB por mês. São preços de hoje, não uma promessa para o próximo ano.
- Em qualquer caso, a RAM parada é o custo que controla. Um servidor dimensionado para um pico que nunca chega é a versão de sala de servidores do portátil de que Altman fala.
Meça os seus próprios 5%: ramuse.py
O Linux indica em /proc/meminfo quanta memória poderia ser entregue sem swap (MemAvailable). O total menos esse valor é o que a sua carga ocupa realmente; a cache de páginas que o kernel pode libertar não conta. O script faz amostras e mostra a média, o pico, o que nunca foi tocado e a menor potência de dois que comporta o pico mais 25% de margem. Python 3, só biblioteca padrão, só Linux. Guarde-o 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
Resultado, executado num servidor DCXV Cloud com Python 3.14.4 em 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)
Como ler. É a máquina de 4 GB que escreve estes artigos, medida durante um minuto enquanto o fazia: ocupou no máximo 1,5 GiB e 2,2 GiB não foram tocados nesse intervalo. Um minuto não prova nada sobre o dimensionamento. Corra-o uma semana com tráfego real, por exemplo python3 ramuse.py 604800 300 > ramuse.txt dentro do tmux, e confirme que a semana inclui o seu dia de mais carga. Dois avisos: uma base de dados ou um servidor de ficheiros usa a RAM livre como cache e fica mais rápido com ela, por isso "never touched" nem sempre é desperdício; e um pico curto (uma cópia de segurança, uma implementação) continua a ser um pico que tem de caber, senão o kernel recorre ao swap ou termina um processo. As regras por tipo de carga estão no nosso guia de dimensionamento de servidores cloud.
Local, cloud ou servidor próprio
O enquadramento de Altman tem duas opções: memória no seu PC ou memória no data center dele. Uma empresa tem uma terceira, um servidor que aluga e controla:
- Manter local quando os dados não podem sair do dispositivo ou o trabalho é ocasional; essa RAM já está paga.
- Usar uma API partilhada quando a procura chega em picos e os dados podem ir para terceiros.
- Ter o seu próprio servidor na UE quando a carga é estável, os dados têm de ficar sob o seu controlo ou quer escolher os pesos do modelo. A memória necessária por tamanho de modelo está em alojar LLM com Ollama na Europa, e os preços com 64 GB em quanto custa um servidor com 64 GB de RAM.
A memória é a parte cara este ano, por isso a terceira opção só compensa quando é dimensionada a partir de uma medição e não a olho.
Dimensione antes de comprar
Corra o script uma semana e escolha o plano pela linha "fits in". Os nossos data centers Tier III em Praga e na Covilhã disponibilizam servidores cloud até 256 GB de RAM; para uma carga pesada e fixa, um servidor dedicado configurado para o pico medido. Envie o resultado do script para sales@dcxv.com e sugerimos um tamanho.
