Hardware

Every other document here configures software. This one configures atoms — the watts, the bandwidth and the silicon that has to exist before any of the engine runs.

Supersedes the 7-seat live-in hub. An earlier version of this document sized a residential compound for the whole team (commit a2499aa, in git history). That is not what this is. No housing, no desks, no domestic load — a machine on a hill that answers when you call it. The change removes about two thirds of the electrical plant and most of the cost.

Status: plan, not a purchase order. Tier 1 is affordable today; everything else is costed so the trigger is a decision rather than a scramble. See Tiers and triggers.

The site

Erkowit is a British-era hill station, and the reason it was one is the reason it suits a machine: it is the one place within reach of Port Sudan that is cold enough to dump a kilowatt of heat into the air for free. In Khartoum, cooling a box like this costs more power than the box. Here it costs two fans.

What "run frontier models locally" can mean

The load-bearing constraint, so it goes first.

Frontier models in the strict sense cannot be run locally by anyone. Claude, GPT and Gemini weights are closed — no hardware buys them. What runs is the open-weight frontier-class tier, which is good and is not level with what we use today:

Self-hostable open-weight models top out around 71–72 % SWE-bench Verified; closed frontier coders sit at 80–95 %.

So the architecture is a ladder, not a replacement:

That third row is the argument money alone doesn't make. During Sudan's nationwide blackout from February 2024, ~30 million people were offline for over a month. A cloud-only operation stops completely. A node with local weights, a local git mirror and local CI keeps working at reduced quality.

Run MoE models with low active parameters — never dense 70B

This single rule decides whether the machine feels fast or broken, because decode speed is set by memory bandwidth × active parameters, not by model size:

A 30B MoE with 3B active reads a twentieth of the memory per token that a dense 70B does. Same box, two orders of magnitude of difference. Pin the model class in the config, not in someone's memory.

The second rule follows from the first: prefill is compute-bound, decode is bandwidth-bound. Cutting memory bandwidth 40 % raises prefill latency only ~17 %. That is why a machine can look fast on paper and stall on agentic coding, and why dispatched batch work — our case — is the friendliest possible workload.

The one box

Two real candidates, six months and $80,000 apart.

Recommendation: Spark-class is the box to buy now. At 240 W it fits the array with room to spare, costs a twentieth of the Station, and its weakness — bandwidth-bound decode on dense models — is one we sidestep by policy anyway (MoE only, above). Its strength is batch throughput, which is exactly what a dispatched queue is.

The Station is the named endpoint, not a fantasy. It is on the table at ~$85K plus roughly $20K of additional solar plant. It ships today. Its trigger is written down in Tiers like every other purchase.

Two notes that save money and watts:

• Disable the ConnectX-7 NIC unless clustering. It draws substantial idle power; a system update that adds hot-plug detection cuts idle draw by up to 18 W. On solar that is 0.43 kWh/day for a checkbox — about 130 W of panel.
• Two Sparks can be linked over ConnectX-7 at 200 Gb/s for 256 GB, which is the cheap path to bigger models if one proves insufficient. Then the NIC earns its watts.

Buy the class, never the SKU

NVIDIA's roadmap says the current Spark's one real weakness gets fixed on a known schedule: Rubin Spark with LPDDR6 lands 2027–2028, and LPDDR5X bandwidth is precisely what caps decode today. (Rubin R100 samples Q4 2026, volume Q1 2027; Rosa Feynman Spark follows around 2029.)

Our Tier 3 trigger plausibly fires in 2027. So the specification is "Spark-class, current generation at trigger time" — never a part number. Written that way, buying the box last is not only cash discipline; the plan upgrades itself while it waits.

The roads not taken

Three reasonable alternatives, each rejected for a specific reason rather than a preference.

Apple — Mac Studio

Disqualified on availability, as of August 2026. The M3 Ultra's 819 GB/s is still 3× the Spark's bandwidth and it does it at ~200 W, which on solar is superb. But Apple pulled the large memory configurations during 2026's memory-supply squeeze: the Mac Studio now ships M3 Ultra at 96 GB and M4 Max at 36–64 GB. The 128 GB, 256 GB and 512 GB options are gone.

Today's Mac Studio therefore has less memory than a $4K DGX Spark — 96 GB against 128 GB — and the "512 GB Mac runs a 671B model" story describes a machine you cannot currently buy.

An M5 Ultra with up to 768 GB is reported for later in 2026 (around October, delayed by the same supply problem) — that is press rumour, not published spec. Even if it ships, it does not re-qualify: no CUDA means no media lane and no vLLM. The Mac's role here is Abdout's development machine, not the node.

macOS vs Linux — a decision the box already made

The DGX Spark ships DGX OS, built on Ubuntu Desktop, with CUDA, cuDNN, TensorRT and the NVIDIA Container Runtime pre-configured. Choosing the box chooses the OS; there is no second decision.

It is the right one anyway, for two reasons that matter to this node:

• Serving. vLLM has no official GPU support on macOS — PagedAttention is a Linux+CUDA feature. The Apple-silicon bridge translates a subset of CUDA through Metal and is slower than llama.cpp's native Metal backend. The native macOS path, mlx_lm.server, does now expose an OpenAI-compatible API with continuous batching, but its KV cache is per-request — no paged or block-based KV management. For a node whose entire workload is concurrent dispatched jobs, that is the exact gap.
• Unattended operation. Headless, remote, containerised, power-cycled without a human is what a server OS is for. macOS is not built to be run this way.

Starlink — the best link we cannot lawfully use

On the technical merits it wins outright, and its power figures are remarkable for an off-grid site: Starlink Mini draws ~15–20 W steady (≈17 W typical) after the January 2026 firmware, with a 60 W startup peak — budget ~30 W, about 720 Wh/day. Licensed VSAT costs 4,320 Wh/day, six times more, at fifteen times the latency.

If Sudan licensed it, the honest planning consequence is not "somewhat better link" — it would delete the VSAT line item entirely ($1,500–3,500 capex plus $200–800/mo) and hand back 3.6 kWh/day of generation.

It is not licensed in Sudan. Starlink now operates in 27–28 African countries (Uganda and Côte d'Ivoire licensed during 2026), but Sudan carries no committed date and the service is treated as not legally operational; terminals in-country arrive informally. For a company signing school contracts and pursuing regulated enterprise buyers, running core infrastructure on an unlicensed service is a business exposure as much as a legal one.

So: plan on licensed LTE and licensed VSAT, and revisit the day the licence exists. The design already has a slot for it.

Tesla Powerwall — a good product in the wrong place

Not a like-for-like price comparison — Powerwall's figure is a US installed price and ours is landed hardware — but the gap is wide enough that the direction is not in doubt. Three reasons it is wrong for Erkowit specifically:

1. It integrates the inverter, which destroys the N+1 design. The whole reason the plan specifies two 3 kW hybrids instead of one bigger unit is that the site is four hours from a technician. A single integrated battery-plus-inverter is precisely the single point of failure that section exists to avoid.
2. There is no Tesla service network in Sudan. Powerwall is sold and supported through certified installers — it reached South Africa in 2025 — and commissioning and monitoring run through Tesla's app. A site whose entire premise is autonomy should not depend on a vendor cloud it cannot reach.
3. A 13.5 kWh monolith cannot go to Port Sudan in a car. A 5 kWh rack module can.

Its 11.5 kW inverter is also roughly four times our 2.6 kW peak — capacity we would pay for and never use.

Solar panels — no change

Already the design: 6 kWp, about 11 × 550 W modules at $0.25–0.45/W. Worth specifying bifacial or N-type TOPCon if the price delta is small — a hilltop with light-coloured ground returns a few percent on the rear face, and better temperature coefficients suit the site. Not worth paying a premium for.

Three planes, split by blast radius

"All owned local" is right for most of the stack and wrong for one part. The line is not ideology — it is who is harmed when a hilltop link drops.

The customer plane migrates only on evidence — 12 months of measured node uptime, and then only for customers who want on-prem. Some do: delivery already sells self-hosted and on-prem tiers to Tier-1 procurement. That reframes the capex — the node is the reference implementation of the on-prem enterprise product, not merely an internal cost saving. It is the only argument here with a direct line to revenue.

Unattended operations

This section exists because nobody is there. It matters more than the load table.

The recovery problem. Spark-class hardware has no BMC or IPMI — there is no lights-out management processor to call when the OS stops answering. The nearest human is four hours away. So recovery is built out of dumb, reliable parts:

The management plane needs its own path. If the primary link is what died, you cannot reach the PDU through it. So: a second LTE modem on a different carrier, reaching only the PDU and management gear — a few dollars a month for the ability to fix the site without driving to it. This is the highest-value $30 in the plan.

The queue must be idempotent. A hard power-cycle mid-job is a normal event here, not an incident. Every dispatched job must be safe to re-run: write outputs to a temporary key and rename on completion, record job state in the service-plane Postgres rather than in the worker's memory, and make the drain resume from the database on boot. Design for the power-cycle and it stops being a failure.

Delivery is a sizing input. Rendered media has to leave the site over rural LTE upload. Push finished assets straight to S3/CloudFront (cdn.databayt.org) as they complete rather than accumulating them, and keep the source frames local. Measure upload on the survey — it is the real ceiling on the media lane, not the GPU.

A caretaker is retained. Not optional and not a comfort item: an unmanned building holding $20–100K of silicon, copper and lithium is a theft target, and the panels need cleaning monthly (weekly after dust events). Budget the person. The minimal quarters in the load table below are theirs.

The load model

An unmanned node, not a compound. Replace with measured values after the first month.

The node

Site

Design point

Firm (non-sheddable) load: 3.3 kWh/day — service plane, storage, network, out-of-band, security. That is what battery autonomy actually has to protect. The supercomputer itself is not firm: it is the most schedulable load on the site.

Electrical sizing

Battery

E_batt = (E_daily × A) / (DoD × η_inv)

  E_daily = 10.3 kWh/day   A (autonomy) = 1.2 days
  DoD     = 0.90 (LiFePO4) η_inv        = 0.94

E_batt = (10.3 × 1.2) / (0.90 × 0.94) = 14.6 kWh  →  15 kWh nameplate

Specify: 48 V LiFePO4, 15 kWh, as 3 × 5 kWh rack modules.

Modules, not a monolith — a dead module costs 5 kWh, not the bank, and one fits in a car for the trip to a technician. At full load that is 1.2 days; on the firm bus alone, with the supercomputer idle, it is over four days.

Solar array

P_pv = E_daily / (PSH_worst-month × derate)

  PSH_worst-month = 4.5 h   (Sudan GHI ≈ 6.0–6.5 kWh/m²/day; Erkowit's fog
                             justifies a conservative worst month)
  derate          = 0.75    (soiling, temperature, wiring, MPPT, mismatch)

P_pv = 10.3 / (4.5 × 0.75) = 3.0 kW minimum

Specify: 6 kWp — about 11 × 550 W modules, ~29 m².

The 2× oversize is the cheapest decision in the document. At $0.25–0.45/W the marginal panel is the cheapest energy in the system, and it buys fog-day resilience, headroom to run the compute without touching the battery, degradation cover, and a second machine later. Altitude helps — cell temperature is the dominant PV loss in Sudan, and 1,350 m runs 8–12 °C cooler than Khartoum. Fog works the other way. Pull the exact pin from Global Solar Atlas before ordering.

Tilt ~15–18° south is optimal; use ≥20° regardless — fog and dust need a self-shedding angle. Wind-rate the mounting for an exposed hilltop.

Inverter

Peak concurrency is modest: supercomputer 0.24 + service/network/storage 0.11 + pump start 2.2 surge ≈ 2.6 kW peak, surging to ~3 kW.

Specify: 2 × 3 kW 48 V hybrid inverters in parallel.

Not one unit. Four hours from a replacement, N+1 is the whole argument: one dead inverter in a pair is a degraded week; one dead inverter alone takes the site off the air until someone drives there.

Solar-scheduled compute

On an off-grid site a daytime kWh costs about a third of a night-time one:

Daytime load   → needs PV only            ≈ $103 per kWh/day of capacity
Night-time load → needs PV *and* battery  ≈ $370 per kWh/day of capacity

The supercomputer is the largest and most flexible load on the site, so it belongs in the sun. kun already has the machinery — the social pipeline is a queue with a cron drain that runs today. Making the drain solar-aware is a scheduling change, not an architecture change:

Drain the queue when the battery is above 70 % and the array is above 60 % of nameplate. Otherwise let it wait.

That one rule is worth more than several kWh of battery, and it is exactly how a dispatched node should behave: jobs are asynchronous, so let physics pick the hour.

Priority bus

Split the distribution board into two circuits from day one:

The out-of-band gear belongs on the critical bus specifically so that you can still reach the site when everything else has been shed.

The UPS mostly disappears

There is no grid to drop from: the hybrid inverters plus 15 kWh of battery are the UPS. What is still worth buying is one 1 kVA online UPS on the critical rack — service plane, network, out-of-band — so inverter faults and maintenance never hard-cut a database mid-write. Anything beyond that duplicates a bank you already paid for.

Protection and environment

A hilltop at 1,350 m, 40 km from salt water, inside a mist oasis, unattended.

Cooling

The site's climate is why this section is short — and why putting a supercomputer here works at all.

Free-air cooling, not a compressor. The machine puts 240 W (Spark) to 1.6 kW (Station) of heat into the equipment room. At ~22 °C ambient that is removed by filtered forced ventilation — two EC fans, ~120 W, ~1.2 kWh/day — where Khartoum would need a mini-split drawing 6× that. This is the single biggest reason the site is Erkowit and not somewhere convenient.

Two caveats: the intake must be filtered (dust) and the room dehumidified (fog) — condensation on cold silicon at dawn is the failure mode here, not heat. Fit a small mini-split as backup for the hottest weeks and for a Station-class upgrade, sized for backup duty, not baseline.

Connectivity

Power is arithmetic. The link is the hard part, and for a remotely-operated node it is the product.

Ingress and bandwidth

Rural LTE gives no static IP and no inbound ports, so everything reaches the world outbound-only: Hermes over Slack Socket Mode (already correct — outbound WebSocket, no public endpoint), and Cloudflare Tunnel or Tailscale for the CRM, dashboards and staging.

Agent traffic is cheap — a session is text, a few MB per hour. What eats the link is housekeeping, and one row is new with local inference:

Bill of materials

USD, as of August 2026, estimates only. Landed cost in Sudan typically runs 25–40 % above international list once freight, customs and FX are included. Local distributors exist (EMPOWER, Khartoum); Port Sudan is the working import channel. GPUs and lithium both attract customs scrutiny — verify with a broker before committing.

Power — Spark-class node

Compute and operations

Connectivity and site

Totals

Tiers and triggers

The Drive settles it: cash flow first. A node that eats the runway before there is revenue is the failure mode, not the plan.

Note the shape: Tier 2 is the expensive part, and it is the part with no NVIDIA logo on it. The plant, the link and the ability to reach the site remotely cost four times what the computer costs. That is the honest structure of an off-grid compute node, and it is why the sequence puts the box last rather than first.

Fund Tiers 2–4 non-dilutively first. A solar-powered, remotely-operated AI compute node in eastern Sudan is a strong story for exactly the grants, vendor-credit programmes and accelerator tracks already on the fundraising ladder.

A generator is deliberately absent. Fuel scarcity and price are why Sudanese households are moving to solar; a diesel genset imports the problem the site was chosen to escape. If one is ever bought it is a manual-start emergency unit, never part of the daily energy balance.

Risks

Site survey checklist

Nothing above is buyable until someone stands on the hill. The first visit returns with:

• LTE readings — RSRP/RSRQ/SINR for Zain, MTN and Sudani at roof height on each bearing, and upload speed. This single measurement decides viability
• Second-carrier coverage — the management plane needs a different network to be worth anything
• Grid — any village supply? Voltage, hours per day
• Building — condition, roof load, a room that locks, photographs
• Ground — soil resistivity for earthing; rock depth
• Wind — prevailing direction and observed extremes, for array and mast rating
• Fog — hours per day, season, how late into the morning it persists
• Road — real travel time and vehicle requirement to Sinkat and Port Sudan
• Caretaker — is there someone local who can be trained and trusted?
• Ownership — who controls the building, on what terms

Open decisions

1. Rent, renovate, or build? Costed as renovation of a small existing structure.
2. IP KVM or serial console? $150–400 for the ability to watch a boot from 4,000 km away. Probably worth it.
3. Is microwave backhaul real? Depends on a licensed partner in Sinkat or Port Sudan. Would beat both LTE and VSAT.
4. Who owns the site? DevOps is Sedon's lane, but so is Saudi operations. Needs a named owner before Tier 2 fires.
5. Insurance — obtainable in Sudan at a sane price? If not, theft risk is uninsured and the caretaker line grows.

Sources

Site and climate: Ar Kaweit · Erkowit — Discover Sudan · Sinkat Grid: UNDP — $3bn damage to Sudan's grid · Sudan Tribune — power cuts · Port Sudan protests over outages Solar resource: Global Solar Atlas — Sudan The one box: NVIDIA DGX Station · MSI XpertStation WS300 at $85K · DGX Spark review — StorageReview · Spark concurrency benchmark · Spark idle power cut by ConnectX hot-plug detection · Spark vs Mac Studio bandwidth · Prefill is compute-bound, decode is memory-bound NVIDIA roadmap: RTX Spark roadmap — Rubin 2027, Rosa Feynman 2029 · Inside the Vera Rubin platform Apple: Mac Studio technical specifications (96 GB max, checked August 2026) · M5 Ultra Mac Studio reported for 2026 with up to 768 GB · …still due in 2026 macOS vs Linux serving: vLLM on Apple Silicon — does MLX integration work · vLLM GPU installation (Linux + CUDA) Starlink: Starlink now in 27 African nations · Starlink Mini power consumption — real wattage data Powerwall: Powerwall 3 review and pricing 2026 · Powerwall 3 launches in South Africa · 48 V server-rack battery vs Powerwall Open-weight models: Best open-weight coding models to self-host, 2026 Media generation: Video-gen GPU requirements 2026 Connectivity: Telecommunications in Sudan · VSAT services in Sudan · Starlink on the ruins of Sudan's networks

See also

• /hardware — the live sizing model: pick the box, watch the plant resize
• Delivery — the on-prem tier this node is the reference build for
• CRM · Hermes — the first two services to move onto it
• Stack — what runs, and where