# NeuronPlant / Design decisions Why this fabric, cooling, storage, sequence, or plant. Rationale in writing. Canonical HTML: https://neuronplant.com/mcp Collection file: https://neuronplant.com/llms/decision.txt NeuronPlant is not an NVIDIA Cloud Partner. NVOnline packs are named, not reprinted. Customer names and customer specifications publish only after written approval. # Four fabric planes, not four equal jobs Topic: fabric Kind: engineering-position ## Question Why not one flat network for the whole AI factory? ## Decision Design four planes. East-West compute fabric (GPU-to-GPU, DGX-to-DGX, RDMA/RoCE or InfiniBand, Spectrum-X or Quantum-X). Storage/data fabric as its own internal data plane when dedicated. North-South / front-end for users, apps, API gateway/LB, enterprise/core. Management/OOB for BMC and operational control, never as application North-South. They may share a vendor. They do not share a failure domain. ## Why Collectives, checkpoint burst, user traffic, and BMC traffic have different congestion and blast-radius profiles. Collapsing them to save ports is how an outage looks like a model problem. NVIDIA SuperPOD public reference architectures already name distinct switch jobs for those planes (Q3400 or QM9700 compute, QM9700 or SN5600 storage, SN5610 user/NFS). Structured cabling is how those plants are built, not a fifth fabric. ## Alternatives considered - Single Ethernet leaf for every job - InfiniBand for every job including homes and BMC ## Related - https://neuronplant.com/insights/ethernet-vs-infiniband - https://neuronplant.com/capabilities#nvidia-switches - https://neuronplant.com/capabilities#fabrics Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Specify the loop before the NVL72 purchase order Topic: cooling Kind: engineering-position ## Question Why is an NVL72 not treated as a dense server install? ## Decision Treat NVL72 as plant equipment. Facility water, CDU, isolation, and a 100 kW-class feed are gates. The rack is specified after the room can take it. ## Why An NVL72 is a liquid-cooled NVLink domain. If the hall cannot present the water, the rack ships and sits. Redundancy lives in the loop, the CDU, and the rejection plant, not in a spare fan. Power nameplate and sustained draw are different numbers. Design to the one that shows up on the utility bill and the breaker. ## Alternatives considered - Order the rack and retrofit cooling later - Air-cool a 72-GPU NVLink domain as if it were 8-GPU nodes ## Related - https://neuronplant.com/insights/deploy-nvl72 - https://neuronplant.com/dsx Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Storage is sized to the workload, not to one NAS brochure Topic: storage Kind: engineering-position ## Question Why not one enterprise array for training, RAG, and inference? ## Decision Split the machines. Training wants sequential GB/s and checkpoint burst. RAG wants random read IOPS and a document / index split. Inference wants local NIM weights. Homes and logs stay on a quieter user tier. ## Why NVIDIA SuperPOD B300 public guidance states high-performance storage I/O per node must exceed 40 GB/s (Ethernet RA) and 80 GB/s on the Quantum-X800 RA. A single NAS asked to be both home directories and training scratch will stall jobs and look like a GPU problem. The index does not belong on the training filesystem. ## Alternatives considered - One quota, one protocol, every lab on the same queue - Vector store on the training parallel FS ## Related - https://neuronplant.com/capabilities#storage - https://neuronplant.com/capabilities#rag-storage - https://neuronplant.com/models Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Feasibility before architecture before procurement Topic: power Kind: engineering-position ## Question Why not start from the accelerator SKU list? ## Decision Sequence is feasibility first (what the hall can present: power, water, space, floor, connectivity), architecture of the accelerator cell second, procurement third. ## Why Time-to-power and time-to-water bind the cell more often than PUE slogans. Those clocks belong to the hall owner or the custom-system supplier. If you cannot draw the path the room presents to the compute rack, including maintenance bypass, you do not yet have an architecture. NeuronPlant does not become the utility or the civil contractor. ## Alternatives considered - Buy accelerators, then discover the hall cannot present the feed - Redundancy that exists only on a slide - NeuronPlant pouring a campus to rescue a bad sequence ## Related - https://neuronplant.com/insights/power-cooling-ai-factories - https://neuronplant.com/what-we-build Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Specify the PDU job. Managed is not automatic. Topic: power Kind: engineering-position ## Question Why not put a managed PDU in every compute rack? ## Decision Treat unmanaged distribution, metered, and switched/outlet-level as three jobs. Write the one you need. Do not default to a management plane. ## Why A PDU is how the rack gets power. Managed means metering, a network, and often remote outlet control. That is justified when you need to see kW, phase balance, and headroom versus nameplate, when the hall is multi-tenant or billed, or when the board and BMS do not already meter at that grain. Dual-cord GPU and compute racks do not want outlet switching. You do not power-cycle a training node from a PDU web UI. If EPMS or BMS already meters the feed, a metered PDU can be redundant. The PDU management network is another plane to design, secure, and cable. Unmanaged, or metered but not switched, is a valid spec. Cheaper, fewer failure modes, still distributes power. ## Alternatives considered - Managed PDU in every rack as a standard BOM line - Outlet switching on dual-cord training nodes - Metered PDUs on top of an EPMS or BMS that already meters the feed ## Related - https://neuronplant.com/capabilities#pdu - https://neuronplant.com/what-we-build#pdu - https://neuronplant.com/insights/power-cooling-ai-factories Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Specify structured cabling with the fabric, not after the GPUs land Topic: cabling Kind: engineering-position ## Question Why is structured cabling and passive infrastructure a factory layer instead of a fit-out? ## Decision Four fabric planes on separate trays (East-West compute, storage/data, North-South front-end, management/OOB), polarity as a drawing, IL / OTDR / as-builts as gates. Recable is the recovery when this is skipped. Firmware is not. Structured cabling is how those plants are built, not a fifth fabric. ## Why Dirty MPO, mixed polarity, no slack, blocked chimneys, and mixed trays take rails dark while teams chase NCCL and switch code. NVIDIA's public DSX overview puts a 500 m optical reach limit on the CIN spine. That is a fiber plant number. NeuronPlant has watched an unnamed operator buy a large CPU and GPU fleet, hand structured cabling to another firm, and sit offline. That is a cautionary record, not a customer logo. ## Alternatives considered - Let cabling to a fit-out contractor after hardware lands - Nearest free port installs on mixed trays ## Related - https://neuronplant.com/cabling - https://neuronplant.com/cabling#tomorrow - https://neuronplant.com/insights/passive-plant-offline - https://neuronplant.com/projects/gpu-hall-passive-plant Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Use public NVIDIA DSX as language for a hall partner or customer program, not as a campus NeuronPlant builds Topic: campus Kind: engineering-position ## Question Why cite NVIDIA DSX if NeuronPlant is not an NVIDIA Cloud Partner and does not construct data centers? ## Decision Restate the public facilities overview when a hall partner or customer program needs that language. Name NVOnline packs by title and number only. Do not reprint them. Do not claim partnership. Do not present NVIDIA's 157-acre example as a NeuronPlant delivery. ## Why The open DSX campus (grid, BESS, CUB, dry coolers, CDU gallery, compute hall, CIN) is the right shape of the problem at hall and campus scale for the people who actually own the room. The gated packs are NVIDIA's. Shipping them, or implying NVOnline access we do not have, is not engineering. It is a compliance failure. Treating the 157-acre table as a NeuronPlant campus is a positioning failure. ## Alternatives considered - Treat a brochure rack as a campus design - Copy NVOnline drawings into a customer pack - Sell NeuronPlant as the builder of NVIDIA's example campus ## Related - https://neuronplant.com/dsx Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Accelerators without a data-to-workload path are inventory Topic: pipeline Kind: engineering-position ## Question Why is the AI platform a plant layer? ## Decision Architect ingest, storage tiers, train or RAG, runtime, NIM serving from public NVIDIA docs, and handover as part of the factory. Do not claim to write every model or to be a generic software ISV. ## Why After power, cooling, racks and accelerators exist, bytes still have to move. Train / fine-tune and RAG are different I/O machines that can share a hall. Mixing them on one filesystem is how jobs stall. Ownership of the application stays with the operator. ## Alternatives considered - Stand up accelerators and call the factory done at first token - Bundle a NeuronPlant SaaS application suite ## Related - https://neuronplant.com/applications - https://neuronplant.com/applications#rag - https://neuronplant.com/runtime - https://neuronplant.com/models Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Run the factory as a Docker and Kubernetes cell, not as ssh-and-excel Topic: pipeline Kind: engineering-position ## Question Why Docker and Kubernetes on an AI factory, and why three masters? ## Decision Ship serving, ingest, RAG, NIM runtime, and plant services as Docker images. Schedule them on Kubernetes. Start with three masters and three workers. Masters may be VMs. Workers that hold accelerators are usually bare metal. Fluent Bit is the example log shipper. Do not pin CNI, mesh, or operator SKUs. ## Why The hall is not a unique snowflake OS. Same artifact from lab to factory. An AI factory is a fleet. A fleet that is ssh-and-excel will not stay up. Three masters so etcd and the API stay up if one dies. That is why 3, not 1. Observability is part of the plane, not a dashboard catalog. ## Alternatives considered - Treat each hall as a unique OS and copy binaries by hand - Run production on a single master - Require three physical master servers when VMs will hold quorum - Maintain a weekly CNI / mesh / accelerator-operator SKU list ## Related - https://neuronplant.com/runtime - https://neuronplant.com/runtime#plane - https://neuronplant.com/applications#runtime Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp # Growth is an architecture evolution, not a node count Topic: expansion Kind: engineering-position ## Question Why not sell scale-from-two-to-eight-DGX as the growth story? ## Decision Name additive expansion versus an architecture transition. Write how far Day-1 grows without a redesign. Gate the next investment on compute, storage, fabric, platform, and facility measurements. Offer minimum Day-1 or a future-ready foundation, with the money path visible. Do not promise unlimited scale. ## Why Adding nodes inside a designed envelope is one job. Changing fabric class, cooling, storage machine, or hall is another. A cheaper first invoice that forces a recable is a steered money path. Integrity is showing CapEx versus disruption before procurement. ## Alternatives considered - Scale from 2 to 8 DGX as a slogan - Unlimited scale as an intake option - Hide the future-ready premium so the minimum cell wins the bid ## Related - https://neuronplant.com/expansion - https://neuronplant.com/start-a-project - https://neuronplant.com/cabling#tomorrow Source: https://neuronplant.com/mcp Canonical: https://neuronplant.com/mcp