Níveis de armazenamento num servidor de IA: modelo, dataset, scratch, checkpoint

Há uma conversa recorrente que temos com os compradores sobre NVMe. Pedem "o mais rápido possível" porque as fichas técnicas mostram 14 GB/s numa unidade Gen5 e uma 4090 ao lado de um Samsung 9100 PRO parece um par equilibrado. Depois perguntamos para que serve a máquina, a resposta é "sobretudo inferência", e a configuração correta acaba por ser uma unidade em vez de oito. O armazenamento num servidor de IA é a parte da configuração em que sobredimensionar é fácil, indolor para o fornecedor e quase completamente invisível para a carga de trabalho.

Este artigo cobre os quatro níveis reais de armazenamento num único servidor de IA, o que cada um tem efetivamente de fazer, o aspeto do mercado NVMe em 2026, quando é que o Gen5 compensa o seu prémio, por que razão o RAID por hardware deixou de ter importância em NVMe e como dimensionar cada nível sem queimar dinheiro. A escolha do sistema de ficheiros é uma questão à parte, tratada em L04; o armazenamento partilhado em cluster (NFS, BeeGFS, Lustre, object stores) é o K04. Aqui ficamos dentro do chassis.

Os quatro níveis de armazenamento

Um servidor de IA a sério tem quatro papéis de armazenamento distintos. Têm perfis muito diferentes de dimensão, débito, resistência e custo. Tratá-los como um único conjunto é o primeiro erro.

Um servidor de inferência com 4 GPU precisa normalmente apenas do primeiro nível e talvez de uma fatia do segundo. Uma máquina de treino com 8 GPU precisa dos quatro, e os quatro querem unidades diferentes. A pergunta "quantos TB de NVMe?" não tem significado sem escolher um nível.

Armazenamento de modelos

O nível de modelos é o que guarda a sua biblioteca de pesos — todas as variantes de Llama, Qwen, Mistral, Stable Diffusion, Flux e Whisper que alguma vez espere carregar. É também onde vivem o SO, as imagens de contentores, os ambientes conda e os binários do servidor de inferência. Na maioria das configurações, tudo isto se junta na unidade de arranque.

O dimensionamento é função de quantos modelos mantém residentes. Alguns exemplos em quantizações comuns:

• Llama 3 70B Q4: ~40 GB
• Llama 3 70B FP8: ~70 GB
• Qwen2.5-VL 72B Q4: ~45 GB mais alguns GB de torre de visão
• Mistral Large 2 (123B) Q4: ~70 GB
• Llama 4 Maverick MoE FP8: ~250 GB
• Uma biblioteca VLM modesta (8 modelos, quantizações mistas): 300–500 GB
• Um laboratório de investigação com 30 modelos sempre prontos: 2–4 TB

Quase só leitura. O modelo carrega uma vez no arranque do processo e fica na VRAM o resto do dia. A unidade vê uma leitura sequencial de 40 GB no arranque do vLLM e depois fica praticamente parada. Uma única NVMe Gen4 de 2–4 TB — mesmo uma unidade de consumo como a Samsung 990 PRO — dá conta disto sem esforço. Pague por capacidade, não por débito.

Armazenamento de datasets

O nível de datasets é onde assentam os corpora de treino e o material de afinação. É o nível que os clientes subdimensionam cronicamente, porque o dataset com que trabalham hoje cabe e esquecem-se de que o próximo não caberá.

Intervalos realistas:

• Corpus de afinação LoRA de domínio único: 10–100 GB
• Conjunto de afinação multimodal (imagens + texto): 1–10 TB
• Corpus de texto à escala de pré-treino (subconjunto do FineWeb, etc.): 5–50 TB
• Pré-treino de vídeo ou conjunto de demonstrações de robótica: 20–200 TB
• Arquivo genómico, científico ou de recolha web: 100 TB – 1 PB+

O padrão de acesso é leitura sequencial, repetida ao longo das épocas, em muitos workers de DataLoader em paralelo. Sensível ao débito (porque a GPU está à espera) e tolerante à latência. A taxa de escrita é essencialmente nula assim que os dados estão colocados.

Para datasets acima de ~10 TB, a resposta certa sai habitualmente do chassis — ver K04 para padrões de NFS, BeeGFS e object store. Dentro do chassis, um nível de datasets com HDD em RAIDZ2 (barato, grande, lento mas suficiente depois de a page cache aquecer) ou um RAID de NVMe U.2 de gama média é razoável até talvez 50 TB.

Scratch

O scratch é o herói esquecido. Absorve tudo o que não assenta bem noutro sítio: shards de imagem descodificados, ativações intermédias descarregadas pelo ZeRO-Offload, caches de datasets construídas pelo webdataset/DALI, baralhamentos temporários de datasets, artefactos de construção de contentores e o despejo de uma execução que falhou. Leitura intensiva e escrita intensiva ao mesmo tempo.

Dimensionamento: 2–8 TB é o ponto ideal. Abaixo de 2 TB, uma única afinação enche-o. Acima de 8 TB está normalmente a construir um pequeno nível de datasets e a chamar-lhe scratch — tudo bem, mas assuma o que está a fazer.

A resistência importa aqui de uma forma que não importa nos outros níveis. O scratch devora escritas — 5–20 TB escritos por dia não é invulgar numa máquina de treino muito utilizada. Uma unidade empresarial de 1 DWPD com 4 TB permite escrever 4 TB por dia durante cinco anos; um scratch de treino a sério quer 1–3 DWPD, de classe mixed-use.

Checkpoint

O nível de checkpoint é onde aterra o estado do treino. Em rajadas: silencioso durante dez minutos, depois 50–500 GB escritos em poucos segundos, depois silencioso outra vez.

Um checkpoint de um modelo de 70B em FP16 são ~140 GB de pesos. Com FSDP, os gradientes e o estado do otimizador empurram a pegada por checkpoint para 400–700 GB. Com DeepSpeed ZeRO-3 e estado completo do otimizador (Adam: 8 bytes por parâmetro para o master FP32 + primeiro/segundo momento), um checkpoint de 70B pode chegar perto de 1 TB.

A taxa de escrita sustentada de uma única NVMe Gen5 é de ~10–13 GB/s. Um checkpoint de 700 GB escreve-se em cerca de um minuto, de forma otimista — se cada rank transmitir para a sua própria unidade. De forma síncrona, o treino fica bloqueado durante esse minuto. A solução é o checkpointing assíncrono em shards (abordado mais abaixo).

NVMe Gen4 vs Gen5 — quando o prémio compensa

O mercado NVMe de 2026 está dividido entre um Gen4 maduro (5–7 GB/s) e um Gen5 já generalizado (12–14 GB/s). No topo da oferta de consumo está a Samsung 9100 PRO, com 14.8 GB/s de leitura sequencial e 13.4 GB/s de escrita sequencial. O Gen5 empresarial anda pelos mesmos valores — Solidigm D7-PS1010 com 14.5 GB/s de leitura, Micron 9550 MAX com 14 GB/s de leitura, Kioxia CD8, SanDisk DC SN861 — todas a entregar 13–14 GB/s de leitura e 8–10 GB/s de escrita sustentada.

O prémio de custo do Gen5 sobre um Gen4 de capacidade comparável em meados de 2026 é de 30–50% na gama de consumo e de 20–35% na gama empresarial.

Quando o Gen5 se paga de facto:

• Carregamento de modelos a frio. Um modelo MoE de 250 GB carrega em 18 segundos em Gen5 contra 36 segundos em Gen4. Conta se trocar de modelo com frequência.
• Treino limitado por I/O. Pipelines de visão a descodificar JPEG em bruto a partir do disco, datasets multimodais em que o pré-processamento é o estrangulamento.
• Checkpoint para NVMe local antes da cópia assíncrona. Quanto mais rápida a escrita local, mais cedo o treino recomeça.
• Servidor de armazenamento de cluster a servir 8+ nós de treino. A procura agregada dos clientes excede o teto do Gen4.

Quando o Gen4 chega e o Gen5 é dinheiro deitado fora:

• Servidores de inferência. O modelo carrega uma vez no arranque; o resto do dia a unidade anda em MB/s de um só dígito.
• Raiz do SO e repositório de contentores. Arranca uma vez por mês, instala pacotes de vez em quando.
• Nível de datasets com shards grandes e pré-descodificados. Um DataLoader do PyTorch com 8 workers a ler shards WebDataset satura talvez nos 4–6 GB/s agregados; o Gen4 cobre isso.

A versão honesta: cerca de 70% das configurações que enviamos aos clientes são de inferência pura e, para essas, NVMe Gen4 em toda a linha é a opção correta. O Gen5 é uma decisão de nível de treino.

Formatos — M.2, U.2/U.3, E3.S

O M.2 Gen5 vai reduzir a frequência. Uma Samsung 9100 PRO de 2 TB a 13 GB/s sustentados num chassis quente atinge 75 °C e abranda. Os modelos com dissipador ajudam. O M.2 serve para arranque e cargas moderadas; não é o formato certo para um nível de scratch com escrita sustentada.

O U.2 é o cavalo de batalha. Todas as NVMe empresariais que a Kentino envia num chassis Bone64c ou Supermicro são U.2, quase universalmente intermutáveis com backplanes U.3. Envelope térmico de 25 W, porta dupla para multipath, hot-swap, e as capacidades de 7.68 TB e 15.36 TB situam-se no ponto ideal de preço por densidade.

O E3.S é o futuro, devagar. Concebido de raiz para os térmicos Gen5/Gen6. Para um servidor único ou um pequeno cluster Kentino, o U.2/U.3 continua a ser a escolha prática ao longo de 2026; o E3.S entra em cena nos ciclos de renovação de 2027.

Evite empilhar suportes M.2 num chassis quente. As placas PCIe que levam quatro unidades M.2 atrás de um chip de comutação funcionam, mas num servidor 4U com oito GPU o fluxo de ar sobre esses suportes é mau. Vemos redução térmica de frequência ao fim de dez minutos de carga sustentada. Se precisa de quatro NVMe num servidor, use U.2.

Resistência — o DWPD como sinal de compra

Para um servidor de IA, o mapeamento é simples:

• Nível de modelos: leitura intensiva, 0.3–1 DWPD.
• Nível de datasets: leitura intensiva, 0.3–1 DWPD.
• Nível de scratch: mixed-use, 1–3 DWPD. É o nível que justifica o seu orçamento de resistência.
• Nível de checkpoint: mixed-use, 1–3 DWPD. As escritas em rajada acumulam-se; 1 DWPD numa unidade de 4 TB só permite 4 TB/dia, valor que uma cadência de treino pesada ultrapassa.

A escrita intensiva (3+ DWPD) é exagero para quase todas as cargas de trabalho de IA. Comprar o nível de resistência errado resolve-se com uma substituição; comprar a classe de débito errada muitas vezes não. Acerte no débito no momento da construção e trate a resistência como algo que pode melhorar depois.

RAID para NVMe — o hardware morreu, o software é a resposta

Isto merece uma secção própria porque os clientes continuam a perguntar. A versão curta: se a sua configuração tem uma controladora RAID por hardware à frente de unidades NVMe em 2026, está mal configurada.

As controladoras RAID por hardware (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) foram concebidas para SAS/SATA. O ASIC da controladora trata da paridade, da cache e do enfileiramento de comandos e, à largura de banda do SAS (12 Gbit/s = 1.5 GB/s), tem folga de sobra.

O NVMe Gen5 a 14 GB/s por unidade satura uma controladora RAID de placa única ao fim de duas unidades. Oito unidades atrás de uma placa RAID por hardware produzem mais largura de banda do que o uplink PCIe da placa consegue mover. A controladora torna-se o estrangulamento e, depois, o ponto de falha.

As respostas práticas são de software:

• mdadm (RAID por software no Linux). Maduro, dentro do kernel, suporta bem RAID0/1/10. O RAID5/6 em NVMe funciona, mas o cálculo de paridade consome CPU. Para 4 NVMe em espelho ou stripe: perfeito.
• ZFS RAIDZ2. Melhor garantia de integridade (checksums ponta a ponta), melhores ferramentas para scrubs e substituições, semântica de snapshot/clone. Mais pesado para a CPU do que o mdadm. A escolha certa para níveis de arquivo e de datasets em que a integridade dos dados importa mais do que o débito máximo.
• Replicação por unidade / erasure coding na camada aplicacional. Para arrays muito grandes, o EC do MinIO/Ceph ou o striping do BeeGFS tiram a decisão de redundância da camada de blocos por completo.

Para a maioria das configurações Kentino:

• Arranque: 2× M.2 NVMe em mdadm RAID1.
• Scratch: RAID0 com 2–4 NVMe (os dados são regeneráveis).
• Datasets/checkpoint: RAID10 em mdadm ou RAIDZ2 em ZFS.

O RAID por hardware tem exatamente um caso de utilização que resiste num servidor de IA: um pequeno espelho de arranque atrás de uma placa Broadcom/MegaRAID básica, num servidor em que queira mesmo redundância de arranque antes do SO. Mesmo aí, o mdadm RAID1 com EFI nas duas unidades funciona bem.

Armazenamento em rede para o nível de datasets

A conclusão: acima de 10 TB, o nível de datasets pertence quase sempre fora do servidor de IA. Dentro do chassis quer scratch rápido, checkpoint rápido e um repositório de modelos; o dataset pode estar remoto.

Como o PyTorch carrega realmente os dados

Um modelo útil para dimensionar o armazenamento é seguir o que o DataLoader do PyTorch faz. Com num_workers=8 e pin_memory=True:

1. Oito processos worker abrem ficheiros do dataset em paralelo.
2. Cada worker lê, descodifica (JPEG, fotogramas de vídeo, reamostragem de áudio) e transforma uma amostra em tensor.
3. O tensor descodificado é colocado em memória partilhada.
4. O processo principal retira da fila partilhada, fixa na RAM do anfitrião e copia para a GPU por DMA.

As implicações práticas:

• Um pipeline de visão raramente está limitado pelo armazenamento, a não ser que o dataset seja tão grande que a page cache não consiga reter o conjunto de trabalho.
• Um pipeline de pré-treino de LLM a ler shards já tokenizados está muitas vezes limitado pelo armazenamento em Gen4. O Gen5 ajuda. Colocar o conjunto de shards ativos em NVMe local em vez de NFS também.
• A inferência praticamente nunca está limitada pelo armazenamento depois de o modelo carregar. O indicador de atividade de disco numa máquina de serviço fica plano.

O precipício do checkpoint

Um checkpoint de um modelo de 70B em FP16 são 140 GB de pesos. Acrescente o estado do otimizador Adam (~8 bytes por parâmetro para o master FP32 + primeiro + segundo momento): mais ~560 GB. Acrescente os gradientes se guardar um instantâneo a meio do passo: mais ~140 GB. Um checkpoint "completo" de 70B pode chegar a 800 GB ou 1 TB, consoante o que guardar.

Checkpoint síncrono, com um único rank a escrever tudo para uma única NVMe Gen5 a 13 GB/s de escrita sustentada: ~75 segundos para um checkpoint de 1 TB. O treino fica bloqueado durante todo esse tempo. Fazer isto a cada 100 passos, quando cada passo demora 5 segundos, significa que acabou de tornar a execução de treino 15% mais lenta.

Duas soluções, ambas essenciais:

1. Checkpointing em shards. Cada rank FSDP escreve o seu próprio shard na sua própria NVMe local. Com 8 GPU e 8 unidades locais, a escrita por rank é de 125 GB e as escritas paralelizam. O tempo real cai para ~10 segundos.

2. Checkpointing assíncrono. O DCP do PyTorch (torch.distributed.checkpoint) delega a escrita numa thread de CPU. A GPU para brevemente para a cópia de staging GPU→CPU (alguns segundos), depois o treino recomeça e a escrita efetiva para o armazenamento acontece em segundo plano.

A combinação — assíncrono em shards — transforma o armazenamento de checkpoints de "tem de absorver 1 TB em segundos" em "tem de acompanhar uma cópia de fundo em regime estável de algumas centenas de MB/s". Quase qualquer nível de armazenamento dá conta disso. O erro a evitar: checkpoints síncronos, com estado completo por rank, escritos diretamente para NFS. Era normal em 2022. Em 2026 é má prática.

Esquemas concretos de armazenamento Kentino AI

Servidor de inferência com 4 GPU (p. ex. Kentino AI 192 Genoa, 4× RTX 5090 ou 4× RTX Pro 6000 Blackwell):

Arranque + modelos: 1× 2 TB Gen5 M.2 NVMe (consumo ou empresarial de leitura intensiva)
Scratch:            opcional, muitas vezes desnecessário em inferência pura
Dataset:            não é preciso na máquina
Checkpoint:         não é preciso na máquina

Total: 2 TB NVMe. Custo: baixo. Suficiente para qualquer carga de trabalho de inferência.

Servidor de treino com 8 GPU (p. ex. Kentino AI 256 Turin Dual, 8× RTX 5090 ou 8× RTX Pro 6000):

Arranque:        2× 480 GB M.2 NVMe, mdadm RAID1, ext4 → /
Modelos:         2× 4 TB U.2 Gen5 NVMe, mdadm RAID1, ext4 → /models
Scratch:         2× 8 TB U.2 Gen5 NVMe, mdadm RAID0, XFS → /scratch
Checkpoint:      2× 8 TB U.2 Gen5 NVMe, mdadm RAID10, XFS → /checkpoints
Dataset:         montagem NFS a partir de servidor de armazenamento externo, 100 GbE

Total de NVMe local: ~36 TB. Custo: significativo, mas à medida do investimento em GPU.

Nó de armazenamento partilhado do cluster (separado da computação):

Arranque:        2× 960 GB M.2 NVMe, RAID1, ext4
Nível quente:    12× 7.68 TB U.2 Gen5 NVMe, ZFS RAIDZ2 ou alvo de armazenamento BeeGFS, XFS
Nível frio:      8× 16 TB SAS HDD, ZFS RAIDZ2 → /archive
Rede:            2× 100 GbE, com suporte RoCE ou NVMe-oF

Serve o nível de datasets do cluster. Ver K04 para a escolha de FS distribuído.

Há duas coisas a reparar. O servidor de inferência tem uma unidade. O servidor de treino tem quatro níveis, mas cada unidade está dimensionada para o seu papel, não sobredimensionada para ser a maior disponível. O nó de armazenamento do cluster é uma máquina totalmente separada.

Opinião honesta — a maioria dos clientes sobredimensiona o armazenamento

Um padrão que vemos com frequência suficiente para o assinalar: um cliente monta um servidor de 8 GPU "para estar preparado para o futuro", especifica oito unidades U.2 NVMe de 15.36 TB porque as ranhuras lá estão e depois corre cargas de inferência que tocam talvez 200 GB de ficheiros de modelos, deixando o resto do array parado para sempre. €25,000 de NVMe a arrefecer.

As regras honestas de dimensionamento:

• Inferência pura, servidor único: 2–4 TB de NVMe no total. Uma unidade. Está feito.
• Inferência mais afinação ocasional: 4–8 TB no total. Arranque + scratch.
• Treino a sério, servidor único: 16–40 TB distribuídos por arranque/modelos/scratch/checkpoint, com o dataset externo num NAS ou object store.
• Cluster: dataset e checkpoint passam para armazenamento partilhado; a NVMe local por nó encolhe de volta ao perfil de inferência (2–8 TB) para arranque, modelos e scratch de write-back.

O armazenamento é o único ponto de uma construção de IA onde o instinto de "mais é sempre melhor" está consistentemente errado. As GPU escalam o benefício de forma aproximadamente linear com o custo; a RAM escala razoavelmente; o armazenamento muitas vezes não escala de todo a partir do momento em que já tem o suficiente.

O que avaria

Os modos de falha que vemos no terreno, por ordem:

• Unidade de arranque M.2 de consumo sem redundância. A unidade falha ao fim de 18 meses, o servidor não arranca, os modelos continuam seguros no RAID, mas a reconstrução leva um dia. Solução: 2× M.2 em mdadm RAID1, mesmo em máquinas de inferência.
• O scratch enche-se a meio de uma execução. Cache de datasets, shards descodificados e ficheiros temporários da framework conspiram. Solução: monitorizar, alarme aos 80% de ocupação, dimensionar 1.5× o maior conjunto de trabalho previsto.
• Placa RAID por hardware à frente de NVMe. O desempenho é metade do que devia ser, a controladora é um ponto único de falha e a substituição é exótica. Solução: tirar a placa, mdadm ou ZFS diretos.
• Checkpoint síncrono para NFS, o treino bloqueia. Solução: checkpoint assíncrono em shards, primeiro para NVMe local e depois cópia assíncrona.
• Redução térmica de frequência em M.2 Gen5. Uma unidade anunciada a 14 GB/s faz 4 GB/s ao fim de 3 minutos de escrita sustentada. Solução: dissipador, melhor fluxo de ar ou mudar para U.2.
• O dataset no nível de datasets satura o Gen4. O pipeline de treino de visão fica 30% limitado pelo armazenamento. Solução: scratch Gen5, pré-descodificar para WebDataset, ou ambos.
• O ARC do ZFS come a RAM destinada ao treino. A alocação predefinida de 50% leva o processo de treino a OOM. Solução: limitar zfs_arc_max a 10–20% da RAM. Ver L04.

---

Este texto faz parte da Kentino Wiki, uma série de referência sobre computação de IA, robótica e os sistemas que os ligam. Comentários e correções são bem-vindos em info@kentino.com.