Frontier open models, running on hardware you own.
Serve large open-weight models on a local ArrayMeld cluster — for coding agents, research assistants, retrieval and evaluation. No per-token billing, no prompt or repository leaves your network, and 400B-parameter-class capacity from around AUD 20,000 of standard hardware.
Coordinated distributed inference across four 128 GB nodes — not a single shared VRAM pool. Capability targets depend on model, quantisation, context length, runtime and validation.5
512 GB-class capacity, without a data-centre budget.
Frontier-scale open models need more memory than any single workstation GPU offers, and every conventional route to ~512 GB of local capacity has priced out small teams. ArrayMeld changes the entry price: the standard four-node build reaches 400B-parameter-class capacity (low-bit open models) for around AUD 20,000 of hardware — a fraction of the alternatives.
| Route to ≈512 GB-class local capacity | Typical configuration | Indicative cost, AUD* | The catch |
|---|---|---|---|
| Multi-GPU workstationRTX 6000-class | ~5 × 96 GB GPUs + host | 85,000+ | Highest throughput — and highest cost, power and heat |
| Apple Mac Studio fleetApple silicon | 6 × 96 GB units | 59,000+ | Per-unit ceiling + default GPU cap; not one system6 |
| Grace-Blackwell mini fleetDGX Spark-class | 4 × 128 GB units | 30,000+ | Fixed config, no PCIe expansion, Arm platform |
| ArrayMeld 4AMD Ryzen AI Max+ 395 | 4 × 128 GB nodes · 512 GB aggregate | ≈ 20,000 | Standard parts, integrated & validated; open x86 Linux/ROCm |
The straight answer on speed
Peak tokens/s here is below a multi-GPU server, and we say so before you ask. This is not the fastest route to inference — it is the one that lets a budget-constrained team run 400B-parameter-class models at all, privately. We publish tokens/s only after measuring your exact model, quantisation, context and topology.5
Why small models don't cut it
Sub-30 B local models are fine assistants and poor employees: they lose coherence across long contexts, large repositories and parallel agent tasks. Capacity is the unlock — and capacity is exactly what this cluster is engineered to deliver per dollar.
Not four mini PCs. One engineered inference system.
The hardware is the cheap part. The product is the integration — interconnect design, Linux/ROCm configuration, distributed runtime, model deployment and validation — delivered as a working system, with a report to prove it.
Three fabrics. One product family. Sized to your model.
The interconnect is engineered to how your model actually moves data. Each configuration is scoped to your workload — pricing follows the assessment, with inclusions, support and installation stated in writing.1
ArrayMeld 2
Host-to-host direct links — no NIC, no switch. The lowest-cost path to validate private local AI.
- Nodes2 × 128 GB
- Aggregate256 GB (2 × 128)
- FabricUSB4 v2 Direct2
- Best forpilot & R&D
ArrayMeld 4
Switched dual-25GbE fabric: repeatable, monitorable, diagnosable — the production-style coding-agent cluster.
- Nodes4 × 128 GB
- Aggregate512 GB (4 × 128)
- FabricDual 25GbE3
- Best fordaily team AI
ArrayMeld Scale
Direct links plus switched fabric in parallel, or six-plus nodes — a validated design for the largest open models.
- Nodes6–8+ custom
- Aggregate768 GB+ (6–8+ × 128)
- FabricHybrid multi-path4
- Best forlargest models
Current recommendation: GLM-5.2.
In our current assessment, GLM-5.2 offers the strongest balance of scale, reasoning, coding capability and open local deployability, with a 1M-token context target in its public documentation. Open models move fast; when a better one lands, the same cluster redeploys to it.5
Recommended — not required. The platform is yours.
GLM-5.2 is the model we build the cluster around, because its footprint is precisely what the 512 GB aggregate tier is for. But everything runs on an open Linux / ROCm / llama.cpp stack, so at handover we can deploy the open-weight model you prefer instead — and switch or add models later.
Models like Qwen 3.6 and Gemma 4 run comfortably on one or two nodes; the four-node cluster is what unlocks the largest open models. We deploy open-weight models only — proprietary API-only tiers cannot run locally.5
Built by people who run this class of system daily.
We build these clusters because we depend on local AI ourselves. That changes what ships: model fit, interconnect behaviour, thermals, storage layout and agent usability are validated as one system — not sold as a parts list.
Practitioner-built
Hardware topology, fabric design, Linux and ROCm tuning, llama.cpp RPC configuration, model staging and local API serving — the same stack we operate for our own work.
Measured before handover
Every system leaves with a validation report: model load time, time-to-first-token, tokens/s, per-node memory, network utilisation per path, thermals and multi-hour stability.
Scales with you
Start at two nodes for validation, grow to the recommended four-node cluster, or scope a custom multi-node design — capacity, precision and context scale, even though per-token latency does not.
Straight answers for a technical evaluator.
The questions AI teams actually ask. Deeper engineering detail lives on the AI architecture page.
Is this effectively one big GPU?
Does Dual 25GbE mean one connection runs at 50Gbps?
Can USB4 v2 and Dual 25GbE be combined?
How does this compare to a Mac Studio cluster?
Is GLM-5.2 as good as a closed frontier model?
Do I have to run GLM-5.2, or can I choose another model?
Why not just use cloud AI?
Where are you located — and do you work on-site?
Tell us the model you want to run.
We'll design the cluster around it.
Send your target model, context requirements, interconnect preference and budget path — we'll return a scoped configuration and the validation plan we would sign off against.
Also running scientific simulations? See the research & scientific-computing path →