AI NAS Local Processing: Where Your AI Data Runs

Leo · 2026-10

AI NAS Local Processing: Where Your AI Data Actually Runs

AI NAS local processing keeps the model, the index and the source files on storage inside your building, so a query never leaves the network. The phrase now appears on half the AI storage brochures we see, and it describes at least four different architectures, only one of which survives an audit. This guide separates them, then works through the memory arithmetic that decides which appliance can actually run the models a buyer has in mind.

This guide is written for the person who writes the specification and signs off on the network diagram. Each section below answers one of those questions with a number you can check.

What moves off the cloud is more than the files

Local processing relocates three things, and buyers tend to conflate them.

Working data comes first: documents, images, recordings, database exports. Derived data follows, and it is often the more sensitive of the two, because embeddings and vector indexes aggregate across files. Model weights come third, and they set how much memory the device must hold at rest.

Only the first is usually discussed. The other two are where cloud dependence survives after a team thinks it has gone local. A device that keeps files at home but ships every query to a remote API is a hybrid, not an on-premises AI NAS, and the distinction belongs in the specification rather than the brochure. For the cost side of that comparison, the worked figures in the AI NAS versus public cloud TCO analysis are worth running against your own volume mix before you scope hardware.

Four architectures sold under the words “local AI”

Four architectures get sold under the same words. They behave very differently in an audit.

Rows three and four are the honest shape of an AI NAS. Row three matches the S1’s published positioning: 100% local computing, with edge analysis handled on the appliance itself. Row four is the more practical configuration for most operators, who still want an off-site copy but want to pick its destination themselves.

The memory ceiling, not storage capacity, decides the model class

A local model has to sit in RAM before it answers anything, and the arithmetic is unforgiving.

The planning rule for quantized weights is bytes per parameter. In 4-bit quantization the figure is 0.5 bytes per parameter, plus a small constant for overhead. A 7-billion-parameter model therefore needs roughly 3.5 GB just to load; a 13-billion-parameter model needs about 6.5 GB. Add the context window, the runtime and the operating system, and the remaining headroom on an 8 GB device is small. A 13-billion model alongside a working index is better matched to the 16 GB configuration.

Put the memory ceiling in the spec sheet, not the port count. The published X4 configuration lists Intel N100, 8 GB DDR4 (OEM configurations up to 16 GB) and 64 GB eMMC boot storage (OEM up to 128 GB). Those two figures, RAM ceiling and boot storage, bound the model class you can promise a customer. Port count does not.

The wider hardware checklist sits in the AI-ready NAS hardware requirements guide, a page worth circulating with this one.

Published model sizes and their RAM cost

Meta published the parameter counts of its Llama 2 sizes on its public model page: 7B, 13B, 34B and 70B. The figures below reuse that published scale and stop there. Those figures are useful precisely because they are public and independent of any vendor’s pitch.

Treat the middle column as a range, not a promise. Quantization method, context length and runtime all shift it. Memory ceiling is a purchasing decision either way, and it should be quoted by the supplier rather than inferred from a model name on a website.

A small firm’s real requirement is smaller than the pitch

Most projects overspend on this point, and they overspend on the wrong component.

Consider a hypothetical practice, invented for this example only: a 45-person architecture firm that needs answers inside its own drawing register, spec library and project correspondence. It does not need a model that writes code or reasons across a hundred thousand tokens. A 7-billion-parameter model with retrieval over that archive answers the questions the staff actually ask, and retrieval quality counts for far more than the parameter count.

Suppose the firm holds 400,000 document chunks of 512 tokens each. At 768 dimensions and four bytes per float, the raw index is 400,000 x 768 x 4 bytes, or about 1.23 GB. With a stated 30 percent allowance for metadata and index overhead, the planning figure is roughly 1.6 GB. On those assumptions the index leaves room after a 7-billion model loads. A 70-billion model would not fit on the same device, so any supplier quotation for that class belongs to a different hardware tier.

woCyber publishes the device limits for each model rather than performance promises: the X4 page lists four tool-less bays, Intel N100, an 8 GB DDR4 base that OEM orders can take to 16 GB, 64 GB eMMC boot storage, a 120 TB drive-capacity ceiling and dual 2.5GbE ports with link aggregation and failover. Those are the figures to quote in a customer bid, and each is a device limit rather than a throughput measurement.

Worked example: sizing a retrieval index

The formula fits in one spreadsheet cell.

Vector storage in bytes = number of chunks x dimensions x bytes per float.

Re-run the same arithmetic for a larger archive: 1.2 million chunks at 768 dimensions and 4 bytes per float. The raw figure is 1,200,000 x 768 x 4 = 3,686,400,000 bytes, or about 3.44 GB. With a 30 percent allowance for metadata and index overhead, plan for about 4.5 GB.

Now add the model. A 13-billion-parameter model at 4-bit needs roughly 6.5 GB of weights. The two together come to about 11 GB in this illustrative sum, before the operating system and the runtime take their share. On these figures a 16 GB OEM configuration is the working floor; 8 GB would not cover this archive.

Run the same sum for a 7-billion model and the total falls to roughly 8 GB. Decide at that point whether the archive shrinks or the memory budget grows.

Asking the supplier the right three questions

Ask these before a purchase order. Paper answers, not sales calls, settle them.

• Where does inference run? On the appliance, or behind an API the vendor does not disclose.
• What can the device reach? Confirm that the appliance needs no always-on outbound connection, and find out what the firmware does when that link is closed.
• Who can be compelled to hand over data? A vendor holding your corpus can be ordered to hand it over, regardless of where its servers sit. A device inside your building, holding material your own team operates, keeps that material outside the reach of a third party that was never given it.

The third question is where Europe and North America part company in emphasis, and it is the reason the next section exists.

Data residency: US vendor-risk forms versus EU processing agreements

The question underneath both regimes is the same one: which actor is technically able to produce the corpus.

When an AI tool processes material from identifiable individuals, the controller carries obligations under data-protection law, and the contract with the supplier becomes the first document a buyer negotiates rather than the last. Article 5 of the GDPR sets out the principles that govern that processing, including storage limitation and integrity, and those principles do not disappear because the processing happens on a box in the office. They simply become easier to evidence when the box is yours and its access log is yours.

A buyer in either market reads different documents, though. In the United States, firmware and AI features that arrive from a supplier are part of supply-chain due diligence; NIST publishes an AI Risk Management Framework that gives procurement and engineering a shared vocabulary for those questions. In the European Union, the CNIL publishes guidance on artificial intelligence that procurement teams quote in tender files, and it is worth reading before you accept a supplier’s summary of it.

Writing the OEM specification

For a brand or integrator building on someone else’s platform, the on-device rules travel with the hardware. That is the part of the programme woCyber spends its specification work on, because a distributor cannot sell a promise it cannot quote.

Write down four things: the RAM ceiling in the OEM configuration, the boot-storage ceiling, whether the AI feature set can run with the network cable unplugged, and which model classes the supplier will support in writing. The OEM memory ceiling decides whether a distributor can be promised a larger model class on the same chassis. The X4 product page page carries the published figures: four tool-less bays, Intel N100, RAID 0/1/5/6/10, a 120 TB drive-capacity ceiling and dual 2.5GbE ports supporting link aggregation and failover.

Two of those figures deserve more attention than AI marketing gives them. A 120 TB drive-capacity ceiling leaves room for the corpus and a copy of it on the same appliance, subject to the RAID level the buyer chooses. The two 2.5GbE ports can be bonded. During an initial index build, the bonded link sets the upper bound on transfer time, provided the drives and the source can feed the pipe. The actual build time depends on drive throughput and file count, so treat the link as an upper bound rather than a measured gain.

What local processing does not remove

Before you sign, compare the promised feature set with the list in the AI NAS security features checklist. Two entries there apply directly to local inference: whether the appliance needs an outbound connection to work, and what its access log records when a query is served.

Local inference is not free of trade-offs, and a buyer should hear them before signing.

Model quality lags the largest hosted systems. A 7-billion model on an edge box trades away some open-ended reasoning ability compared with the largest hosted systems. Saying so early protects the project’s credibility with staff who use both. The practical answer is to scope the local model to retrieval and summarisation over your own archive, where a well-built index beats raw model size.

Someone has to own the model lifecycle. New weights arrive, quantisation formats change, and an appliance that shipped last year may not run this year’s release. Ask who tests that update and who is accountable when it fails.

Remote access needs a design. If staff answer questions from outside the office, the path back in is now part of your security posture and has to be reviewed like any other entry point.

Frequently asked questions

Does AI NAS local processing remove the need for a data-processing agreement?

No. If the appliance handles personal data, the controller still owes the law an account of how that data is processed, and a supplier that touches the system for support may still need to be treated as a processor. Local processing changes the technical facts, not the legal categories.

Is a 1 TOPS NPU enough for a local language model?

That depends on the model and the runtime, so a supplier should quote it rather than a spec sheet implying it. The published S2 and A2 Pro specifications list an RK3568 with a 1 TOPS NPU. Ask which model classes that budget supports in production, not in a demo.

How much RAM do I need for a 7-billion-parameter model?

Roughly 3.5 GB for the weights at 4-bit quantisation, and about 5 to 6 GB once the context window and runtime are included. An 8 GB appliance runs it with modest headroom. Add the retrieval index on top before deciding that 8 GB is sufficient.

Can I keep using a cloud model and still call it local?

Only if you describe it accurately, which is a hybrid architecture. Files may stay on site while queries leave it, and that distinction is the one an auditor will test. Write the architecture into the specification instead of leaving it to the brochure.

What does 100 percent local computing mean on the published specification?

For the S1 it refers to edge classification of people, vehicles and pets running on the device itself. S1 is a security appliance with recording retention of 7, 14 or 30 days, so the claim covers video analytics rather than general-purpose language models.