The short answer
Memory is the binding constraint when you run AI locally, not processor speed. As a working rule on Apple Silicon:
- 16GB runs a small model comfortably for one person
- 32GB runs a larger, noticeably more capable model and leaves room for real work alongside it
- 64GB and above is server territory, where several colleagues share one machine
You also need disk. Model files are large, and a working setup typically needs around 50GB free, more if you keep several models installed.
The rest of this article explains where those numbers come from, and covers the factor most sizing exercises miss.
Why memory is the constraint
A language model has to be loaded into memory before it can respond. The whole model, not a portion of it. If it does not fit, it does not run, and no amount of processor speed compensates.
On Apple Silicon this is more favourable than on a conventional machine, because the memory is unified: the same pool serves both the processor and the graphics cores, so a model can use it without being copied back and forth across a bus. It is the reason a laptop can run models that would otherwise need a dedicated graphics card.
It also matters how the software talks to the hardware. Estha for Mac runs models through MLX, the framework built for Apple Silicon, which uses unified memory and Metal acceleration directly rather than treating the machine as a generic computer. The practical effect is that the sizing figures below hold up in real use rather than only on paper.
The practical consequence is simple. When you specify a machine for local AI, spend on memory first.
The sizing table
Model files are usually distributed in a compressed form, most commonly at 4-bit precision, which cuts the memory requirement substantially with a modest quality cost. These figures assume that.
| Machine memory | What it comfortably runs | Realistic use |
|---|---|---|
| 16GB | A small model, roughly 7 to 9 billion parameters | One person, document and chat tasks, some headroom needed for everything else you have open |
| 24GB | The same, with more room to work alongside it | One person who keeps many applications open |
| 32GB | A mid-sized model, roughly 20 to 30 billion parameters | One person doing demanding work, or a very small shared setup |
| 64GB | A larger model with room for several jobs at once | A shared machine serving a small department |
| 128GB and above | Larger models, more simultaneous users | A departmental or multi-team server |
Two cautions. Manufacturer minimums describe what will start, not what will feel good. And the figure that matters is what is free after the operating system and your normal applications, which on a working machine is meaningfully less than the sticker number.
The factor most people forget
Almost every sizing conversation is about model size. Almost every disappointing deployment is about concurrency.
One machine running one model serves requests in sequence. Two people asking for a short summary at the same moment will barely notice. Ten people each asking for a long document to be rewritten at 9am on a Monday will notice a great deal.
So the sizing question is not “how many staff do we have”. It is “how many people will be running heavy jobs at the same moment, and what is the longest wait we consider acceptable”. Those two numbers size a shared deployment. Headcount alone does not.
If your usage pattern is spiky, that is worth saying out loud before hardware is bought, not after.
Storage, briefly
Model files are large. A single mid-sized model at 4-bit precision commonly runs to several gigabytes, and a working setup usually holds more than one: a conversational model, an embedding model for searching your own documents, and often a code model for data analysis.
Budget around 50GB free for a single-user setup. For a shared server holding several model options, 50 to 150GB is a more realistic range. Disk is the cheapest part of this exercise, so do not economise here.
One machine or a shared server
There are two shapes, and the difference is organisational as much as technical.
A machine per person. Each person runs the platform and the model on their own computer. Simple, no network dependency, nothing shared. It suits independent professional use and small numbers.
A shared machine on the office network. One well specified machine runs the models, and colleagues connect to it over the local network from their own computers, including from Windows machines where that has been configured. The traffic stays on your network.
The second shape is what most organisations actually want, because it concentrates the expensive hardware in one place and lets ordinary laptops stay ordinary. It is also the shape that needs sizing properly, because it introduces the concurrency question above.
Worth being precise about a distinction that gets blurred: a shared server on your network is on your premises, but it is not literally on the individual’s device. Both keep the work inside your environment. They are different configurations, and any vendor should be willing to say plainly which one is being proposed.
What Estha for Mac requires
For Estha for Mac specifically:
- Apple Silicon, M2 or later
- 16GB unified memory minimum, with 32GB recommended for the larger on-device model
- Around 50GB of storage for model downloads
- Server deployments: 32GB minimum, 64GB or more for the larger conversational models, and 50 to 150GB of free disk
AI inference runs locally on your Mac, and there is no per-token charge for local inference.
Hardware is quoted separately from software, after the capacity conversation rather than before it. Any organisation being sold a bundled figure before anyone has asked how many people will use it simultaneously is being sold a guess.
A sensible way to decide
- Name the workloads. Document processing, data analysis, meeting notes, drafting. Different jobs put different weight on the machine.
- Count concurrent users, not total users. How many people are realistically running a heavy job in the same five minutes.
- Set an acceptable wait. A few seconds for a chat reply. A minute or two for a long document is often perfectly fine.
- Specify memory first, then storage, then everything else.
- Test with your own material before buying at scale. A single machine will tell you more in a week than any specification table.
Frequently asked questions
How much RAM do you need to run AI locally?
16GB is a workable minimum for one person running a small model. 32GB is the comfortable figure for a more capable model with room to work alongside it. Shared deployments serving several colleagues start at 32GB and more commonly want 64GB or more. Remember that what matters is memory free after the operating system and your normal applications.
Is 16GB enough for local AI?
For one person running a small to mid-sized model, yes. It becomes tight if you keep many applications open, or if you want the larger models, which is why 32GB is the more common recommendation for daily professional use.
Do you need a graphics card to run AI locally?
On Apple Silicon, no. Unified memory lets the integrated graphics cores use the same memory pool as the processor, which is why these machines handle local models well without a separate card.
Can a whole team share one machine?
Yes, with a suitably specified machine on the local network. The limit is simultaneous heavy usage rather than headcount, so size for concurrent users and set an acceptable response time before deploying.
How much disk space do local AI models need?
Around 50GB free for a single-user setup. A shared server holding several models is more realistically 50 to 150GB.
Size it against your actual workflows
Before specifying hardware, it is worth mapping which processes you want running locally and how many people will use them at once. That conversation costs nothing and saves buying the wrong machine.
One email a month on private AI. For people who cannot put their work in the cloud. No spam, unsubscribe anytime.
