An off-grid AI server is a computer that answers questions from a local knowledge base and local model weights, powered by something other than the utility grid. Built correctly, it keeps working through outages, in places with no connectivity, and for as long as the sun keeps hitting the panels. This guide covers three buildable tiers — from a laptop and a power station to a permanent solar node — with the actual watt-hour arithmetic, storage and redundancy strategy, and a commissioning checklist you can run before you depend on it.
A note on the numbers. The model, memory, and integrity figures below come from the system we build and ship, and are measured. The wattage, panel, and battery figures are engineering estimates derived from published component specifications and standard off-grid sizing practice — they are planning numbers, not measurements of your specific hardware. Buy a $20 inline watt meter and measure your own draw before you commit to a panel array. Every solar build should start with a measurement, not a table in an article.
What an off-grid AI server is actually for
The premise is narrow and worth stating plainly: the load survives, so the answer does not have to come from a datacenter. When cell towers are down, when the fiber is cut, when you are eighty miles past the last bar of signal, a machine sitting in a closet with a solar panel on the roof still knows how to dose an antibiotic, wire a transfer switch, diagnose a diesel injector, or treat a sick goat.
The people who build these fall into recognizable groups:
- Rural clinics and aid deployments — medical reference where the network is unreliable and the stakes are not.
- Homesteads and farms — livestock, crops, irrigation, equipment repair, seasonal planning.
- Remote industrial and research sites — mines, stations, vessels, field camps with a satellite link too expensive to use casually.
- Emergency operations centers — a reference system that does not compete for the same bandwidth as the response itself.
- Preparedness builders — the same reasoning that puts a generator and a water filter in the plan, applied to knowledge.
What unites them is that connectivity is the least reliable component in the system, so the design removes it from the critical path entirely.
Tier 1: The grab-and-go build
Hardware: the laptop you already own, plus a portable power station.
This is the build most people should start with, because the marginal cost is a power station you probably want anyway. A modern laptop with 16 GB of RAM runs a 14B-class model comfortably. Apple Silicon on macOS 14 or later is exceptional here — GPU acceleration through Metal, unified memory, and a fanless power envelope that a solar system barely notices.
Power budget
A laptop generating tokens draws far less than most people assume. Estimated figures for a typical 14-inch machine:
- Idle with the model loaded in RAM: 10–20 W
- Actively generating a response: 40–70 W, in bursts of seconds
- Screen off, suspended: under 2 W
Realistic daily use — two hours of active questioning, six hours idle-but-ready, the rest suspended — comes out around 200 Wh per day. A 1,000 Wh LiFePO4 power station therefore carries roughly five days of use with no recharge at all. Add a single 100 W folding panel and, at four peak sun hours with a 25% derate for angle, temperature, and controller losses, you harvest about 300 Wh per day. That is a surplus. This tier is energy-trivial.
Verdict: lowest cost, fully portable, no wiring. Best for individuals, vehicles, and anyone who wants capability now rather than a project.
Tier 2: The always-on solar node
Hardware: a low-power mini PC with 32–64 GB of RAM, fed from a 12 V battery bank and a modest panel array.
This is the sweet spot for a permanent installation, and there is a specific technical reason it works so well now.
Mixture-of-experts models have broken the old assumption that a big model requires a big graphics card. The 35B-parameter model we ship activates only about 3.6B parameters per token. All 22.1 GB of weights must be resident in RAM — that part is a 35B problem — but the arithmetic per token behaves like a 3.6B model. The result is roughly 30 tokens per second on CPU alone, which is genuinely conversational, on a machine with no discrete GPU at all.
For a solar build that changes everything. A GPU is the largest and least predictable load in a small power system. Removing it while keeping a 35B-class model is the single best trade available to an off-grid builder. It is also why the spec is 32 GB of RAM, not 16 — 22.1 GB of weights plus operating system plus working memory does not fit in 16 GB, and no amount of CPU will fix that.
Specification
- Compute: a fanless or low-fan mini PC, 8 or more cores, 32 GB RAM minimum and 64 GB if the budget allows.
- Power input: choose a unit with native 12 V DC input. This matters more than it sounds — see below.
- Storage: internal NVMe for the model and corpus, plus the original signed USB kept as the recovery image.
- Enclosure: ventilated, dust-resistant, off the floor, out of direct sun.
Power budget, shown as arithmetic
Estimated draw for a mini PC of this class:
- Idle, model resident: 8–15 W. Call it 10 W.
- Under sustained CPU inference: 45–75 W. Call it 60 W.
Daily energy, assuming the node stays powered around the clock with one hour of actual generation:
| Component | Calculation | Daily energy |
|---|---|---|
| Idle, 24 hours | 10 W × 24 h | 240 Wh |
| Inference, 1 hour | (60 W − 10 W) × 1 h | 50 Wh |
| Total | — | ≈ 290 Wh/day |
Panel sizing. Divide daily energy by peak sun hours, then divide again by a system derate of about 0.7 to cover panel temperature, wiring loss, charge controller efficiency, and imperfect angle. At four peak sun hours: 290 ÷ 4 ÷ 0.7 ≈ 105 W minimum. Nobody should build to minimum. Specify 200 W for a temperate site and 400 W if you need winter or cloudy-week performance — over-paneling is the cheapest insurance in solar.
Battery sizing. Decide your autonomy — how many sunless days the system must survive. Three days is a reasonable target: 290 Wh × 3 = 870 Wh. At 12 V with LiFePO4 chemistry, safely usable to 80% depth of discharge: 870 ÷ (12 × 0.8) ≈ 91 Ah, so specify a 100 Ah LiFePO4 battery. The same job in lead-acid AGM, limited to 50% depth of discharge, needs about 150 Ah and weighs three times as much for half the cycle life.
The inverter trap. A 12 V to 120 V inverter is typically 85 to 90 percent efficient under load, which is tolerable. The problem is its idle draw: many inverters consume 10 to 25 W just being switched on. On a node whose entire idle load is 10 W, the inverter can more than double your daily energy consumption while doing nothing. If your mini PC accepts 12 V DC directly, run it directly and skip the inverter. That single decision can shrink your panel and battery requirement by a third.
Tier 3: The base station
Hardware: a GPU workstation serving multiple users over a local network.
Build this when several people need simultaneous access, when you want sub-second responses, or when the same machine handles other work — image processing, mapping, video, local file services. A 24 GB card runs a 30B-class model fully offloaded at well over 100 tokens per second.
The power cost is real. Estimated: 60–90 W idle, 250–400 W under GPU inference. Assume eight hours powered at 80 W and two hours of generation adding 250 W:
| Component | Calculation | Daily energy |
|---|---|---|
| Powered idle, 8 hours | 80 W × 8 h | 640 Wh |
| GPU inference, 2 hours | 250 W × 2 h | 500 Wh |
| Total | — | ≈ 1,140 Wh/day |
That is roughly four times Tier 2 for a machine that is only on a third of the day. Sizing: 800–1,000 W of panel and, for two days of autonomy at 24 V LiFePO4, about 125 Ah at 24 V (2,280 Wh ÷ 24 V ÷ 0.8). Move to a 24 V or 48 V bus at this scale — the wire gauge and conversion losses at 12 V stop being reasonable.
Comparing the three tiers
| Tier | Compute | Est. daily energy | Suggested panel | Suggested battery | Model class |
|---|---|---|---|---|---|
| 1 — Grab-and-go | Existing laptop, 16 GB | ~200 Wh | 100 W folding | 1,000 Wh power station | 14B |
| 2 — Always-on node | Mini PC, 32–64 GB, no GPU | ~290 Wh | 200–400 W | 100 Ah @ 12 V LiFePO4 | 35B mixture-of-experts |
| 3 — Base station | GPU workstation, 64 GB+ | ~1,140 Wh | 800–1,000 W | 125 Ah @ 24 V LiFePO4 | 35B fully offloaded, multi-user |
If you want the full reasoning behind the compute side of these specs — VRAM headroom, quantization, why 32 GB is the mixture-of-experts threshold — see our companion article on the best local AI hardware for running LLMs.
Storage and redundancy
The payload on an off-grid AI server is unusual: it is large, it is static, and it is the entire value of the machine. Our core library is 685 vetted source documents indexed into 35,799 individually cited chunks, shipped alongside model weights that run from about 4.9 GB to 22.1 GB depending on tier. Total payload lands in the tens of gigabytes. That is small enough to duplicate freely and important enough that you should.
The redundancy strategy that actually works
Conventional backup assumes you can tell a good copy from a corrupted one. In the field, with no reference to check against, you often cannot. The solution is to make the payload read-only and self-verifying.
Every file in our corpus is SHA-256 hashed. The version manifest is canonically serialized and signed with an Ed25519 key. At startup, the runtime verifies the signature and the hashes before it will serve a single answer — and if anything has been altered, it refuses to start rather than serving you modified knowledge. That is a deliberate design choice: in a grid-down scenario, silently wrong information is more dangerous than no information.
The operational consequence is a clean recovery model. You do not need to diagnose a corrupted install. You re-flash from a verified drive and the system either verifies and boots or tells you the drive is bad. Practical rules:
- Keep two copies of the payload, stored apart. One in the server, one in a sealed container elsewhere on the property.
- Never treat the original signed drive as your working copy. It is the master. Copy from it; do not run daily off it.
- Prefer SSD over spinning disk for the working copy. No moving parts, lower power, better vibration tolerance, faster cold load.
- Verify on a schedule. Boot the backup once a quarter. An untested backup is a hypothesis.
- Storage is not RAM. A fast disk shortens the wait before the first answer; it does nothing for answer speed once the model is resident.
Environment, heat, and physical security
Heat is the failure mode you will actually experience. Sustained inference pins the CPU, and a thermally constrained machine will throttle — meaning your carefully-planned 30 tokens per second quietly becomes 12 in August. Ventilate the enclosure, keep it out of direct sun, and if it lives in an outbuilding, plan for the hottest week of the year rather than the average.
Dust and humidity kill more field electronics than surges do. A filtered intake and a few desiccant packs cost almost nothing. Elevate the box so a wet floor is not an event.
On EMP and Faraday enclosures, a measured position: shielding a spare drive and a spare mini PC in a sealed metal container is cheap, harmless, and gives you a cold spare against any electrical event — ordinary lightning surge included, which is vastly more likely than the scenario people build for. Do it for surge protection and treat the rest as a bonus. Do not spend money on shielding at the expense of an actual second copy of your data.
Physical security is the part serious builders underrate. A machine that contains your entire reference library is worth taking. Do not put it in the window of the outbuilding.
The software payload: why it must be verifiable, not just offline
Getting the hardware and power right buys you a machine that runs. It does not buy you a machine you can trust. A general-purpose local model on a solar-powered mini PC will still fabricate a dosage, invent a wire gauge, and state a purification ratio with total confidence and no source. Offline does not mean correct.
An off-grid AI server has one property that makes this worse than a desktop toy: you cannot check its work. There is no second opinion, no search engine, no phone call. Whatever it says is what you have. That constraint should drive the software choice as hard as the power budget drives the hardware choice.
What to require of the software payload on any off-grid AI server:
- Retrieval-bound answers. The model reasons over documents you can inspect, not over whatever it absorbed in training.
- A citation on every claim, with the source document openable on the same machine, offline.
- Refusal behavior. When grounding is insufficient the system says so instead of improvising. Incomplete is safe; confidently wrong is not.
- Cryptographic integrity, checked at boot. Signed manifests and per-file hashes, with a fail-closed startup.
- Determinism. The same question against the same library returns the same answer, which means the system is testable rather than merely impressive.
- Automatic hardware tiering, so the same payload runs on the laptop in the truck and the mini PC in the shed without configuration.
That is the specification Off-Grid AI Core was built to. It runs on macOS, Windows, and Linux, ships with three model tiers and selects between them automatically, and boots without installing or compiling anything on the host.
Match the expansion packs to the mission profile of the site:
- Clinic or aid post: Field Medic.
- Homestead or farm: Advanced Agriculture plus Veterinary.
- Infrastructure and equipment: Master Electrician plus Master Mechanic.
- Security and operations: Tactical Operations.
Commissioning checklist
Print this and work through it before the system is load-bearing. Every line exists because skipping it produces a surprise at the worst time.
- Measure real draw. Inline watt meter, idle and under sustained generation. Replace the estimates in this article with your numbers.
- Recompute your budget from the measured figures, then confirm the panel and battery still clear it with margin.
- Log cold boot time. From powered-off to first answer. Know it before you need it.
- Measure tokens per second on a real question. Under 8 tok/s means the machine is undersized for the model.
- Test at 50% battery. Some systems brown out or throttle under sag. Find out on a Tuesday.
- Run three real queries from your actual domain and read the cited sources. Confirm the library covers what you need it to cover.
- Verify true offline operation. Disconnect all networking and repeat step 6. Anything that stalls was reaching out.
- Boot the backup copy on different hardware. Confirm it verifies and runs.
- Check thermals under 30 minutes of sustained load at the hottest ambient temperature the site sees.
- Label everything — battery capacity and install date, panel wattage, DC polarity, boot instructions taped inside the enclosure lid. Assume the person restarting it is not you.
- Schedule a quarterly drill. Cold boot, one query, backup verification, torque check on the DC terminals.
Frequently asked questions
How much solar do I need to run an AI server?
It depends entirely on the machine. A laptop-based setup using about 200 Wh per day is well served by a single 100 W panel. An always-on mini PC node at roughly 290 Wh per day needs about 105 W of panel at minimum, but should be specified at 200–400 W for real-world weather. A GPU workstation at roughly 1,140 Wh per day needs 800–1,000 W. Measure your own draw before buying panels.
Can an AI server run on battery alone during an outage?
Yes. A 1,000 Wh power station carries a laptop-class setup for roughly five days of intermittent use. A 100 Ah LiFePO4 battery at 12 V carries an always-on mini PC node for about three days with no sun at all. Sizing autonomy is just daily energy multiplied by the number of sunless days you want to survive.
Do I need a GPU for an off-grid AI server?
No, and for most solar builds you should not want one. Mixture-of-experts models activate only a fraction of their parameters per token — a 35B model with 3.6B active reaches roughly 30 tokens per second on CPU alone. Removing the GPU removes the largest and least predictable load from a small power system. Spend the budget on RAM instead.
How much RAM does an off-grid AI server need?
32 GB is the working specification. A 35B mixture-of-experts model at Q4_K_M holds about 22.1 GB of weights that must stay resident in RAM, and that plus the operating system does not fit in 16 GB. A 16 GB machine still runs a 14B-class model well; it simply cannot host the largest tier.
Is an inverter necessary for a solar powered AI server?
Preferably not. Inverters lose 10 to 15 percent under load and, worse, many draw 10 to 25 W continuously just being switched on — which can exceed the idle draw of the mini PC itself. If your machine accepts 12 V DC natively, run it directly off the battery bus and skip the conversion entirely.
What is the difference between an edge AI server and a cloud AI deployment?
An edge AI server performs inference on local hardware with the model weights stored locally, so it functions with no connectivity. A cloud deployment sends every request to a remote datacenter and stops working the moment the link does. For grid-down and remote use, only the first design has a survivable failure mode.
How do I protect an off-grid AI server from corruption or tampering?
Use a payload that verifies itself. Per-file SHA-256 hashes plus a cryptographically signed manifest checked at every boot means the system refuses to start in a modified state rather than serving altered information. Keep two copies stored in separate locations, and boot the backup quarterly to confirm it still works.
What happens to an AI server in extreme heat or cold?
Heat is the practical problem. Sustained inference pins the processor, and a thermally constrained enclosure will throttle, cutting throughput substantially without any error message. Ventilate, shade, and test under load at the hottest ambient temperature the site actually reaches. LiFePO4 batteries also should not be charged below freezing without a heated model or a low-temperature cutoff.
Start with a measurement
The best off-grid AI server is the one that is already built and already tested. Start at Tier 1 — the laptop you own and a power station — measure the real draw, and let the numbers tell you whether you need Tier 2. Most people discover their energy budget is far smaller than they feared, and the harder question is not how to power the machine but what knowledge it should contain.
Off-Grid AI Core is the payload side of that build: a signed, self-verifying, citation-bound library on a bootable USB, with domain expansion packs for medical, veterinary, electrical, mechanical, tactical, and agricultural work. It runs on all three tiers described here without configuration.
If you are still deciding on hardware, read the best local AI hardware for running LLMs. If you are new to running models locally at all, start with how to run an offline AI LLM without internet access. And for the case for portable over permanent, see why a portable USB AI device works when nothing else does.
