Nodes
2 – 8+
modular, added in stages
Technical decision guide · revised July 2026
Architecture, explained for decisions.
How ArrayMeld combines modular compute nodes, local storage, network fabric, Linux software and acceptance testing into a practical research platform — and where the design does not fit.
Aggregate memory disclosed
Workload-specific topology
Version-controlled software
Measured acceptance
This page is a public decision guide, not an installation recipe. The final bill of materials, software versions, security controls and acceptance criteria are fixed in the written project scope.
Per node
128 GB
unified within the node
Workloads
AI + science
two acceptance paths
01 · What it is
A scale-out research platform — not one oversized workstation.
ArrayMeld turns several standardised machines into one coordinated, documented environment. Understanding one thing up front prevents most disappointment later: aggregate is not unified.
What the platform delivers
- Enough aggregate node memory to run selected open models and simulations that exceed a single machine's capacity
- A local, private environment for inference, development and iteration — no per-token metering, no data leaving your network
- An integrated stack — hardware, fabric, Linux, runtime, monitoring — delivered configured, not as a parts list
- A documented, expandable system with a credible path from two nodes to a custom scale-out
The most important clarification
512 GB aggregate ≠ 512 GB unified VRAM
In a four-node system, memory stays attached to separate nodes. Software partitions the model or workload across them, and inter-node traffic affects performance. Aggregate capacity is real and useful — it is simply not one physically unified pool, and we never describe it as one.1
02 · Fit by workload
The same hardware can serve different jobs — but the acceptance test must change.
A coding-agent deployment and a molecular-dynamics workflow succeed on entirely different criteria. We define the right one before quoting, never after.
Private AI inference
We assess
model, format, quantisation, context, concurrency, usable memory
Strongest value
private local serving with no per-token cost and full data control
Not assumed
frontier-model training, high-concurrency enterprise serving, every framework
Acceptance example: a target open model loads and serves a representative prompt set within an agreed time and memory budget.
Scientific computing
We assess
solver, libraries, message-passing pattern, numerical format, I/O, scaling
Strongest value
per-node GPU runs, high-throughput ensembles and parameter sweeps (embarrassingly parallel), local development and method iteration
Not assumed
strong-scaling one tightly-coupled simulation across the fabric, high-accuracy quantum chemistry at scale, CUDA-only code
Acceptance example: a representative run completes within the agreed time and accuracy budget, and an ensemble or parameter sweep reaches the agreed throughput across nodes.
Shared research platform
We assess
users, scheduling, access policy, storage, monitoring, administration
Strongest value
a controllable team resource that avoids external queues and metering
Not assumed
data-centre-class uptime, unlimited concurrency, a public network service
Acceptance example: nominated users run their workloads under the agreed access and scheduling model.
03 · Logical layers
Five layers turn separate machines into one usable environment.
Each layer is a responsibility, not a separate box. The control layer runs on Node 01 alongside its own compute — there is no extra orchestrator machine to buy or maintain.
01 · AccessResearchers, local API and approved remote access under your policy
02 · Services & controlModel/inference server, job scheduling and monitoring — running on Node 01
03 · InterconnectDirect, Fabric or Hybrid — chosen for the traffic pattern, not the biggest number
04 · Nodes & storageFour peer nodes, each memory + compute, with local NVMe for model/data staging
05 · Security & recordsSegmentation, observability, documentation and support spanning the whole system
A fast network is not local memory
The single ratio that shapes every topology decision: each node reads its own memory around 25–40× faster than any external link can move data between nodes. The runtime's job is to keep the heavy traffic inside each node and cross the fabric only when it must.
The honest consequence: adding more nodes buys capacity, precision and context — not linear speed. A distributed layer pipeline traverses nodes in sequence, so per-token latency does not fall as you scale. We design for the workload's real traffic, and we say this plainly.
04 · The building block
A compact high-memory node, verified as a complete system.
The present reference platform is the AMD Ryzen AI Max+ 395. Per-node figures follow AMD's published specification; system-level I/O is a vendor-board property, so we verify it per chassis rather than inheriting it from the CPU page.
Per-node specificationAMD published data
CPU16 cores / 32 threadsZen 5 · native 512-bit AVX-5126
Integrated GPURadeon 8060S40 compute units
Memory128 GB LPDDR5x-8000256-bit · unified CPU+GPU within the node
Local memory BW≈ 256 GB/stheoretical: 8000 MT/s × 256-bit ÷ 8
ExpansionPCIe 4.0
USB42 × 40 Gbps native80 Gbps USB4 v2 depends on the vendor board & controller — verified per node system2
Four-node aggregateacross nodes — not a shared pool
Memory512 GB across four nodes128 GB × 4 — scales proportionally with node count1
CPU64 cores / 128 threadsaggregate
GPU160 compute unitsaggregate
Local memory BW4 × ≈ 256 GB/seach node accesses only its own memory at this rate
Runtimecoordinated distributed inferencethe model is sharded across nodes, not held in one VRAM pool
Why x86 — your scientific stack runs as shipped. Every node runs full, native 512-bit AVX-512 on Zen 5 desktop-class cores — eight double-precision values per instruction. Because GROMACS, LAMMPS, NAMD, FFTW and the standard BLAS/LAPACK libraries are written and hand-tuned for x86 with AVX-512, they run natively, with no recompilation and no re-porting of vector kernels. Apple's M-series and NVIDIA's Grace (DGX Spark) are capable ARM platforms, but the mainstream scientific stack targets x86 first — so on ARM the same code must be rebuilt and any x86 vector kernels re-implemented for NEON/SVE. You spend your time on science, not on porting.6
05 · Bandwidth reality
Local memory is far faster than any external fabric.
This is why we choose a fabric for the traffic pattern rather than the largest number on a cable — and why aggregate memory, not raw link speed, is the value you are buying.
per-node local memory = 8000 MT/s × 256-bit ÷ 8 ≈ 256 GB/s
USB4 v2 raw link = 80 Gbps = 10 GB/s
dual 25GbE aggregate = 2 × 25 Gbps = 6.25 GB/s
Linear scale, theoretical figures — the gap is the point. Distributed inference works here because the runtime shards the model so the heaviest traffic stays inside each node.
06 · Interconnect
Choose the fabric for the traffic — not the largest number on a cable.
Three options, each with an honest constraint. Raw path capacity is not application throughput; we never simply add link speeds and present the sum as guaranteed performance.
Option 01 · lowest component count
Direct
Two systems joined by a certified cable talk directly, host-to-host — no NIC, no switch. It is the cheapest path and ideal for a two-node pilot.
Constraint, plainly: direct links are point-to-point, and USB4 host networking is platform- and OS-dependent. Four-node direct-only builds need chain or ring designs and are shipped only after the routes are measured.2
Option 02 · standard four-node path · recommended
Fabric
Switched high-speed Ethernet — typically dual 25GbE paths per node through a compact SFP28 switch. Standard tooling means standard diagnostics: bonding, MTU tuning and per-port monitoring. The recommended default for a production-style ArrayMeld 4.
Aggregate means aggregate. Two 25GbE links give up to 50 Gbps of capacity per node across flows; a single stream rides one 25 Gbps path unless MPTCP, multi-flow traffic or bonding is configured — engineering we perform and then verify.3
Option 03 · specialist engineering
Hybrid
The full 25GbE switch backbone still reaches every node — so the controller talks to all workers — and the controller adds direct USB4 links to accelerate its heaviest worker paths. Each board exposes two USB4 ports, so the controller can direct-link at most two workers; any remaining node rides the fabric. Reserved for the traffic patterns that justify the extra engineering — and only there.
Raw paths ≠ throughput. Applications do not automatically use the summed capacity of every interface. Multi-path aggregation (e.g. MPTCP) must be engineered and measured per topology, and is additionally bounded by controller uplinks and the software stack. We sell hybrid as a validated design, never as an automatic number.4
07 · Software stack
Freeze a supportable stack instead of chasing every new release.
Linux is the serious path for multi-node work: full control of interfaces, routing and kernel parameters, and the best ROCm alignment for this platform. Each product release records its exact versions and is regression-tested before it becomes supported.
AI inference path
InterfaceLocal OpenAI-compatible API / approved UI
Runtimellama.cpp or a scoped alternative
Distributed layerRPC where validated for the workload
AccelerationROCm / HIP on the node GPUs
OS baselineUbuntu LTS
Scientific computing path
OrchestrationMPI / OpenMP / batch scheduling
LanguagesC / C++ · Fortran · Python
DeliveryNative or containerised environments
AccelerationROCm / HIP where the solver supports it
OS baselineUbuntu LTS
Compatibility snapshot (verified per release). AMD's published Linux matrix lists the Ryzen AI Max+ 395 (gfx1151) with a current Ubuntu 24.04 / ROCm release. Supported frameworks, data types and versions are recorded in each product release and re-checked before every quote — we do not assume a general "runs everything" compatibility.5
RPC security boundary. Upstream documentation describes the llama.cpp RPC backend as proof-of-concept and insecure on open networks. Our default deployment confines it to an isolated private segment, firewall-restricted and never internet-exposed, soak-tested for stability before handover.5
08 · Sizing
Size the first system to a useful workload, then keep a credible expansion path.
Model and simulation fit is arithmetic before it is anything else: weights, cache and runtime overhead must live inside aggregate node memory with headroom — then it is verified on the real system.
| Configuration | Nodes / aggregate | Suited to | Positioning |
|---|---|---|---|
| ArrayMeld 2 | 2 × 128 GB = 256 GB | pilots, development, selected smaller models & simulations | Entry / validation — a deliberately controlled fit |
| ArrayMeld 4 | 4 × 128 GB = 512 GB | large low-bit open models; production-style team use | Recommended — real headroom for cache, context and runtime |
| ArrayMeld Scale | 6–8+ × 128 GB = 768 GB – 1 TB+ | the largest open models and larger simulations | Custom engineering — capacity scales proportionally with node count |
Proven pattern. AMD's own published guide runs a one-trillion-parameter-class quantised model across four 128 GB Ryzen AI Max+ 395 systems on Ubuntu, ROCm and llama.cpp RPC over Ethernet. The recommended ArrayMeld 4 is that architecture, engineered and validated as a product.5
On the AI side, a strong current open model (for example GLM-5.2-class, our July 2026 recommendation) is deployed at low-bit precision across the aggregate memory. It is a recommendation, not a lock-in — the open platform also serves single-node families such as Qwen 3.6 or Gemma 4, and redeploys as the ecosystem moves. Proprietary API-only tiers cannot run locally and are never listed as options.
On the scientific side, the same nodes run molecular-dynamics, macromolecular-modelling and parameter-sweep workloads, with genuinely large or tightly-coupled jobs bursting to institutional HPC. Suitability is sized to your solver and acceptance workload before commitment.
09 · Acceptance
Every delivered system leaves with evidence attached.
We do not publish throughput until it is measured on the final hardware, model, quantisation, context, runtime and topology — and neither should anyone else. Here is what gets measured.
01
Define the acceptance workload
Agree a representative model or simulation and the pass criteria — in writing, before procurement where possible.
02
Qualify every node
Memory, storage, thermals, power and stability tested per node; firmware and versions recorded; assets labelled.
03
Validate the fabric
Addressing and network map documented; links and multi-flow behaviour measured against the design.
04
Run the customer-relevant workload
Load, timing, throughput, scaling and I/O measured on the representative workload — with conditions recorded.
05
Test stability and recovery
Long-context / long-run stability, and behaviour after a worker restart, verified before sign-off.
06
Hand over the operating record
As-built documentation, the acceptance report, credentials transferred securely, and administrator handover.
Load successWall timeTime to first tokenTokens/s
Scaling efficiencyNetwork per pathPer-node memoryThermalsRecovery
10 · Operating environment
A local cluster still needs an operating environment.
Owning the compute means owning a little responsibility for where it lives. We confirm each of these during design, and document them at handover.
Power & cooling
Circuit capacity, peak load, ventilation, ambient conditions, placement and acceptable noise — confirmed for the site before build.
Network & access
Addressing, segmentation, administrator access, firewall rules and any approved remote-support method — documented and handed over.
Data & backup
Storage layout, model/data staging, backup responsibility and a data-erasure procedure for replaced or returned drives.
Updates & support
A versioned, regression-tested software stack; a defined support boundary; a change-control process that protects the validated configuration.
Local does not automatically mean secure. Security depends on configuration, people and process. We define the network, access and remote-support model with you rather than describing the system as "secure" without a defined scope.
11 · Reasons not to buy
A credible architecture includes the reasons not to buy it.
If any of these describe your workload, we will say so during the assessment — and, where we can, point you to a better route.
It is not one unified 512 GB accelerator
A four-node system has separate memory domains connected by a fabric. Software must partition the workload; it is not a single physically unified pool of GPU memory.
It is not a universal AI-training system
The platform targets inference, development and selected workloads. Frontier-model training and high-concurrency enterprise serving need dedicated infrastructure and validation we do not promise by default.
CUDA-only or hardware-specific software may not run
This is an AMD/ROCm platform. Software that requires CUDA or a specific accelerator may be incompatible or need porting — we check this before you commit.
More nodes do not make one task faster
Scaling adds capacity, precision and context, not linear speed. A distributed layer pipeline traverses nodes sequentially, so per-token latency does not fall as node count rises.
Extreme-scale or tightly-coupled jobs belong elsewhere
Very large, tightly-coupled or bursty jobs are usually better on institutional or cloud HPC. ArrayMeld is designed to complement those, not replace them.
Support and compatibility evolve over time
Models, drivers and stacks move. We freeze and support a versioned release and revalidate on change — but a system is only "supported" within its documented configuration.
12 · Sources
Follow the source, then validate the delivered system.
Hardware, model rankings and software support all move. We re-check these before publishing final claims — and we recommend you click through and do the same.
AMD Ryzen AI Max+ 395
Node reference: 16 Zen 5 cores, 128 GB max, 256-bit LPDDR5x-8000, Radeon 8060S (40 CUs), PCIe 4.0, native USB4 listing.
amd.com — product pageAMD four-node cluster guide
Four 128 GB Ryzen AI Max+ 395 systems, Ubuntu, ROCm and llama.cpp RPC running a trillion-parameter-class quantised model over Ethernet.
amd.com — technical articleAMD ROCm — Ryzen Linux matrix
Supported gfx1151 / Ubuntu / ROCm combinations and validated data types — the basis for our compatibility snapshot.
rocm.docs.amd.comllama.cpp RPC backend
Distributed inference across nodes; upstream flags the RPC backend as proof-of-concept and insecure on open networks — the basis for our isolated-network discipline.
github.com — llama.cppOpen MPI
The message-passing foundation for distributed scientific workloads on the platform.
open-mpi.org — docsLinux kernel MPTCP
Multipath TCP can use several interfaces within one connection — the mechanism behind hybrid-fabric aggregation, subject to validation.
docs.kernel.orgA source link does not freeze a specification. Before we rely on any figure for a contract or claim, we open the current official source, record the date, and validate it on the delivered system.
From datasheet to delivered system
Bring the workload. We will test the architecture around it.
Share your target model or simulation, your context and data requirements, and your budget path — we will return a scoped topology, a bill of materials, and the validation plan we would sign off against.
- Target model or solver
- Data & context scale
- Site & power
- Budget path