# NeuronPlant / Storage by workload Training, RAG, inference, and HPC mixes as different machines. Large inference also has a KV / prefix cache tier. Canonical HTML: https://neuronplant.com/capabilities#storage Collection file: https://neuronplant.com/llms/storage.txt NeuronPlant is not an NVIDIA Cloud Partner. NVOnline packs are named, not reprinted. Customer names and customer specifications publish only after written approval. # Storage / Training / post-training Look for: Sustained sequential GB/s and checkpoint burst, not IOPS marketing. Shared parallel filesystem for datasets. Separate checkpoint target that can absorb a simultaneous flush from the job. NVIDIA SuperPOD B300 RA states high-performance storage I/O per node must exceed 40 GB/s (Ethernet RA) and, on the Quantum-X800 RA, 80 GB/s. Typically: HPS on IB (QM9700) or RoCE (SN5600) as the storage/data fabric, plus a quieter NFS/user tier on SN5610 as North-South / front-end. Do not fold HPS into a generic East-West compute line if dedicated. Avoid: A single enterprise NAS asked to be both home directories and the training scratch. NVIDIA source: https://docs.nvidia.com/dgx-superpod/reference-architecture/scalable-infrastructure-b300-xdr/latest/network-fabrics.html Canonical: https://neuronplant.com/capabilities#storage # Storage / RAG / enterprise retrieval Look for: Random read IOPS, metadata, and a clean split between documents and the vector index. Object or file store for source documents. NVMe-backed or in-memory vector index. Ingest path sized to nightly rebuilds, not to training checkpoints. Typically: Object + vector engine. North-South / front-end Ethernet is usually enough if the index is local or on a low-latency tier. That is not the East-West compute fabric. Avoid: Putting the vector store on the same parallel FS as a training job. NVIDIA source: https://docs.nvidia.com/nim/large-language-models/latest/support-matrix.html Canonical: https://neuronplant.com/capabilities#storage # Storage / Inference / NIM serving Look for: Fast model-weight load, local NVMe or a warm cache, isolation from training I/O, and a KV / prefix cache plan on large serving. NVIDIA NIM selects a profile from its support matrix (precision, tensor-parallel size, LoRA). Weights load from local NVMe. That is not the whole inference memory story. On a large workload, KV cache needs a hierarchy: GPU HBM, host overflow, and sometimes a shared prefix cache across the serving plane. That tier is not a storage array and not a checkpoint pool. Typically: Node-local NVMe for NIM images and weights. KV in HBM first. Host memory and a serving-plane prefix cache when context and concurrency fill the GPU. Avoid: Loading 70B-class weights over a contended NFS home share. Treating KV as another LUN on the training filesystem. NVIDIA source: https://docs.nvidia.com/nim/large-language-models/latest/support-matrix.html Canonical: https://neuronplant.com/capabilities#storage # Storage / Research / HPC mix Look for: Scratch that can be purged, project space that cannot, and a scheduler that knows the difference. Burst scratch on the HPS fabric. Project datasets on a capacity tier. Home and logs on the user-storage Ethernet path, as in the NVIDIA SuperPOD split. Typically: Two storage systems: HPS + user storage. NVIDIA documents this split explicitly. Avoid: One quota, one protocol, every lab on the same queue. NVIDIA source: https://docs.nvidia.com/dgx-superpod/reference-architecture/scalable-infrastructure-b300-xdr/latest/dgx-superpod-components.html Canonical: https://neuronplant.com/capabilities#storage # Storage sizing Capacity is not a storage architecture. TB on a quote is not a spec. Engineer the requirement before the product: throughput, IOPS, metadata, checkpoints, RAG, and protection. Then pick a machine that can do that job. Training, RAG, and inference remain different machines. - Throughput: Sequential GB/s for training scratch and checkpoint burst. NVIDIA SuperPOD public RAs already publish per-node floors. Size to the job, not to a single array's headline. - IOPS: Random read for RAG retrieve and metadata-heavy ingest. A parallel FS built for sequential train I/O is the wrong machine. - Metadata: Small files, many objects, index catalogs. The namespace can saturate before the bytes do. - Checkpoints: A simultaneous flush is a storage event. Burst target and recovery window are part of the plant, not an afterthought quota. - RAG: Source corpus, embeddings, and the index are different sizes and different I/O. See RAG storage below. Do not size from vector capacity alone. - Protection: Copies, erasure, snapshots, rebuild time. Protection is throughput you no longer have for the job while a disk is gone. ## RAG storage is sized from source data, not from vector capacity. Start with raw TB and how it grows. Then decide copy versus reference, retention, embedding volume, protection, and what a re-index costs. The vector store is one downstream number. It is not the architecture. - Raw TB: Authoritative source size today. Everything else is derived. - Growth: Ingest rate and how long the plant must take it without a storage transition. - Copy vs reference: Landing zones that copy the corpus multiply TB. Reference in place saves bytes and couples failure domains. Write the choice. - Retention: How long each data state lives. Legal hold is not the same as hot retrieve. - Embeddings: A function of chunking, dimensions, and versions kept. A new embedding model is a storage event, not a config flag. - Protection: Which states are rebuilt from source, which are backed up, which are disposable. - Re-index: Bytes, IOPS, and window to rebuild the index from chunks. If you cannot re-index, you do not own the RAG plant. Pages: /capabilities#storage, /capabilities#rag-storage. RAG path and lifecycle: /applications#rag. Canonical: https://neuronplant.com/capabilities#sizing