Resource sizing

The per-service ports and profiles are in services, ports and profiles, which is generated from the compose files. This page is the sizing arithmetic on top of them: what each container actually used when it was measured, what that totals per profile, and how to compute a figure for your own deployment. For the host you should provision, start at requirements and sizing; for what an added component costs, see optional services and what each one costs.

Reading the numbers

Container memory has three readings and they differ by gigabytes.

Whole stack, 21 containers, idle: 12.53 GiB of anonymous memory, against 15.00 GiB that docker stats prints and 18.00 GiB of charged memory. The 2.5 GiB difference is active page cache, most of it the model files the detectors read at startup, and the kernel drops it under pressure without the process noticing.

Per container

Measured 2026-09-08 on the development server: Ubuntu 24.04, 10 vCPU, 32 GB, no GPU, cgroup v2, the default compose profile plus the llm-analyst and tools profiles. Idle means the stack had been up two hours with no traffic. Declared is the compose memory limit; a dash means the service declares none.

Three services — the jailbreak, toxicity and PII detectors — are 7.87 GiB of the 12.53 GiB total: 63 % of the idle stack is three ONNX detectors. Each uvicorn worker loads its own full copy of the model, so UVICORN_WORKERS moves this table more than any other setting. The same stack idled at 7.3 GiB with one worker per service against 12.5 GiB with two to four.

Two containers are missing from this table because nothing constrains them and nothing measured them: the services that declare no limit are the reverse proxy, the dashboard, the gateway, the database, the cache and the host reconfigure agent — all of them small here, but unbounded by design rather than by intent.

Per profile

Six of the nineteen default-profile services declare no limit, so 37.63 GB is a floor rather than a ceiling and a host running out of memory is not diagnosable from the compose file alone.

What load adds, and does not give back

Measured end to end: the same 21 containers went from 12.53 GiB in the morning to 15.25 GiB after one OCR matrix and three detector bursts, then idle again. None of the 2.7 GiB came back. Sizing from an idle reading under-counts the PII detector alone by more than a gigabyte.

CPU, not memory, is the binding constraint on the image path. One A4 page costs 190 CPU-seconds and runs 8.4 cores wide, so a 10-vCPU box does under three pages a minute and nothing else while it does them. Concurrency makes it worse: four pages at once cost 238 CPU-seconds each instead of 190.

Where a GPU changes something

A GPU is recommended, never required, and only for the image path and for a self-hosted model. There are three GPU paths and they are independent of each other.

Nothing else in the stack uses a GPU. PII, toxicity, jailbreak and injection detection run on ONNX on the CPU, hallucination detection is a CPU-only build, and adding a card does not change their latency.

How to compute your own total

To measure a service yourself, read its own cgroup rather than docker stats:

docker compose exec ml-detector \
  awk '/^(anon|file|active_file) /' /sys/fs/cgroup/memory.stat

Read it before and after a realistic burst. The difference is what that traffic costs, and for the ONNX detectors it is the difference that matters, not the starting value.

Notes

• Disk grows with retention, not with traffic peaks. Detections, event logs and compliance evidence are what accumulate; container images and model caches are a fixed cost paid once. The shipped retention windows and the fact that the sweep does not delete by default are in requirements and sizing.
• Swap is a margin for brief model spikes, not a substitute for memory. 8 GB is enough on a correctly sized host, and no amount of it rescues a host below the 32 GB floor.
• The shipped appliance image is pre-sized at the supported minimum — 32768 MB and 8 vCPU — so it powers on without operator arithmetic. Raise it before you put load on it.
• Two older figures circulate and neither is generated. The repository guide and the OVA build notes say about 42 GB of declared limits across 11 unlimited services, and about 30 GiB measured. The generated figure is 37.63 GB across 19 services with 6 unlimited; the 30 GiB came from a 2026-07 staging rehearsal that recorded all services running with head-room on a 62 GiB box, not a per-container measurement. Use the generated and measured figures on this page.

Related

• Requirements and sizing — the host to provision, per deployment mode.
• Optional services and what each one costs — the requirement line per added component.
• Services, ports and profiles — the generated per-service table.
• Compose profiles and CLI — how a profile is started.