title: Choose a computer with enough capacity description: Memory, storage, and processing needs depend on your models, documents, and number of users — three named configurations the repository supports numbers for, and what happens below the floor. url: https://legalquants.github.io/lq-ai/operate/hardware-sizing/ checked-against: 8c66c85a (2026-10-26) status: draft kind: reference sources: docs/operate/hardware-sizing.md, docs/adr/0026-document-ingestion-parser-and-docling.md, README.md, docs/INSTALL-MAC.md, docker-compose.yml, docs/quickstart.md, docs/PRD.md, deploy/helm/lq-ai/values.yaml Memory, storage and processing needs depend on the models, documents and number of users. Treat the published sizes and setup times below as estimates, not guarantees — where the repository doesn't give a number, this page says so rather than guessing one. ## What uses resources Local AI models can take substantial memory. Document processing, simultaneous jobs, stored files and downloaded build files also add up. Starting successfully doesn't tell you how the app will perform with a full workload — none of throughput under concurrent users, ingestion latency for a large document corpus, or a recommended CPU core count is measured anywhere in the repository as of the checked commit. ## Measure a realistic trial Try documents with sizes and layouts similar to the ones you expect to use. Watch memory use, storage growth and completion times as you go — a first run, before layers and caches are warm, will likely take longer than a later one. **Details:** the repository doesn't supply those numbers for you. There's no per-seat or per-matter sizing guidance and no benchmark of tokens-per-second on any hardware. If your deployment plan depends on one of those, that's not documented in the repository as of the checked commit — measure it yourself against your own workload before you commit hardware to it. ## Configuration 2 — Docker Compose, cloud provider keys (a small server or a laptop) The README's starting figures are about 8 GB of disk and 6 GB of memory available to Docker, per [README.md](/lq-ai/operate/install-docker-compose/#quick-start). This is the floor to bring the eight always-on services up (`postgres`, `redis`, `rustfs`, `gateway`, `api`, `ingest-worker`, `arq-worker`, `web`) — [`docker-compose.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docker-compose.yml) sets no CPU or memory `deploy.resources` limit on any of them, so nothing in the compose file itself enforces or guarantees a ceiling either way. These figures don't size a team deployment or promise every workload will fit — on a Mac, check both the memory allocated in Docker Desktop and the computer's total memory, and leave room for images, build caches, uploads and growth. :::danger[Before you run this] The 6 GB is guidance, not a boundary the stack enforces or the repository has measured: `docker-compose.yml` sets no memory limit, and nothing in the canon records at what allocation the stack stops coming up or how it fails. What the README's own troubleshooting section does say is that an immediate failure is a reason to check the allocation first: *"`docker compose up` fails immediately — confirm Docker Desktop is running and has at least 6 GB RAM allocated."* On macOS: Docker Desktop → Settings → Resources. Under memory pressure, expect a refused boot, a container killed after it started, or a build that crawls — not one predictable symptom. There is no in-app signal beyond the compose error itself; a container that never starts doesn't leave a growth curve to read. ::: The first `docker compose up -d` also *builds* `api`, `gateway`, `web`, `ingest-worker`, and `arq-worker` from source rather than pulling them — [`docker-compose.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docker-compose.yml) gives each of those five a `build:` block and no `image:` tag (`ingest-worker` and `arq-worker` reuse the `./api` build context, so their layers are cached from the `api` build) — and pulls the other three (`postgres`, `redis`, `rustfs`). How long the build takes and how much disk it needs on an operator's own machine isn't measured anywhere in the repository; the closest figures on record are two CI workflows' notes about their GitHub-hosted runners, not a developer laptop: a cold compose build of roughly 20–30 minutes ([`.github/workflows/e2e.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/.github/workflows/e2e.yml)), and the api-family image alone unpacking to ~12 GB with the BuildKit cache costing about as much again ([`.github/workflows/stack-smoke.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/.github/workflows/stack-smoke.yml)) — so read the README's ~8 GB as a planning figure for the images at rest, not a verified minimum for a from-source build. A related, larger number from a different install path: the macOS desktop launcher's first run downloads roughly 17 GB of images (`api` ~9.5 GB, `web` ~6 GB, `gateway` ~1.6 GB, plus `proxy`) before it starts pulling document-processing models — [docs/PRD.md](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docs/PRD.md) records this as the reason that first run can look frozen for 10–30 minutes on a slow connection (see *The Mac desktop installer*, below). None of these is the same number as the compose ~8 GB floor above (different install path, different image set, different machine class), and none is reproduced here as a general Compose expectation — cited so a slow first build or pull doesn't read as a hang. ## The Mac desktop installer The Mac install guide describes Apple Silicon and roughly 12 GB of free disk, with Docker Desktop installed separately. Intel support isn't established anywhere in the install doc, so treat it as unconfirmed rather than assuming it works. Download sizes and extracted images can exceed a headline estimate, so check available space during first setup. **Details:** [`docs/INSTALL-MAC.md`](/lq-ai/operate/install-macos/) states the exact prerequisites — an **Apple Silicon Mac (M1/M2/M3/M4)**, Docker Desktop installed and running, ~12 GB free disk, and an internet connection for first run. No terminal and no cloned repository are needed, but Docker Desktop is a separate install the app links you to if it is missing or stopped. The ~12 GB is the install doc's planning figure, not a measured clean-install footprint — nothing in the repository records disk use or elapsed time for this path, and [docs/PRD.md](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docs/PRD.md)'s own fresh-install note for the same desktop launcher puts the first-run image download alone at roughly 17 GB (see *Configuration 2 — Docker Compose, cloud provider keys (a small server or a laptop)*, above), so leave headroom above the stated figure rather than treating it as a ceiling. ## Adding local models Budget for the selected model's files and working memory on top of the app. Document-processing models have their own downloads and caches. Nothing in the repository benchmarks CPU or GPU models, simultaneous users or large document collections — treat all of the below as **not measured** rather than assuming either "works fine" or a specific number. Start from Configuration 2's floor above, then add: - **`ollama` container** (`--profile local`) — no separate RAM/CPU minimum is stated in the repository; [`docker-compose.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docker-compose.yml) ships GPU acceleration as an operator-uncommented block (`nvidia-docker`), so a GPU is optional, not required, but neither CPU-only nor GPU throughput is measured anywhere in the canon. - **Model storage** — [`docs/quickstart.md`](/lq-ai/start/quickstart/) describes the `qwen3.5:9b` pull as "a few GB"; that is the only size figure the repository gives for any Ollama model. `gateway.yaml.example` ships three Tier-1 aliases pointed at Ollama: `local` and `local-thinking` (both `qwen3.5:9b`) and `local-fast` (`qwen3.5:4b-nvfp4`, a separate tag you must pull yourself if you want that alias) — budget disk for whichever tag(s) you pull, on top of Configuration 2's floor above. - **First-ingestion download** — the ingest worker still pulls roughly 700 MB of Docling layout/OCR models from Hugging Face on the first document it processes (`lq_ai_docling_enabled` defaults to `True` in `api/app/config.py`), cached afterward in the `ingest-hf-cache` / `ingest-easyocr-cache` named volumes ([`docker-compose.yml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docker-compose.yml)). It is dead weight: [ADR 0026](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/docs/adr/0026-document-ingestion-parser-and-docling.md) records that Docling has never produced output here and decides its removal, so budget for the download only until that lands. It happens regardless of inference mode, but it matters most for an air-gapped plan: pull it while you still have network access. See [Air-gapped and local-only inference](/lq-ai/operate/air-gapped/) for the install steps and what the repository can and cannot yet prove about Mode 2's network behavior. Helm resource settings are starting values, not performance measurements. **Details:** [`values.yaml`](https://github.com/LegalQuants/lq-ai/blob/8c66c85a/deploy/helm/lq-ai/values.yaml) does set CPU and memory requests and limits per component — `gateway` and `api` each request `200m`/`256Mi`, limited to `1000m`/`1Gi` and `1000m`/`2Gi` respectively; `web` requests `100m`/`256Mi`, limited to `500m`/`1Gi`; the Postgres, Redis, and object-store StatefulSets carry only a storage request. Those are chart defaults to start from, not a measured capacity recommendation, and the chart is **drafted** — it does not deploy the two background workers at all (see [Install with Helm](/lq-ai/operate/install-helm/)) — so they aren't evidence the chart runs the whole stack end to end. ## Next - [Air-gapped and local-only inference](/lq-ai/operate/air-gapped/) - [Install with Docker Compose](/lq-ai/operate/install-docker-compose/#quick-start) - [Install on macOS](/lq-ai/operate/install-macos/)