List the processes that must survive
Inference is rarely the only important job on a small computer. Remote access, camera control, request handling and health reporting may all be necessary to keep the system useful. Identify the minimum control path before allocating the rest of the machine to a model. This turns headroom into an application requirement with named beneficiaries. It also exposes an awkward design early: a system that cannot report or stop its own overloaded workload has made recovery depend on physical access.
Distinguish pressure from a hard boundary
Linux cgroup v2 documents memory.high as a reclaim and throttling boundary, while memory.max can lead to an out-of-memory kill within the group when reclaim cannot satisfy the limit. Those are different behaviours. Choose controls around the failure policy the service needs, then inspect their effect under a representative workload. An aggressively low boundary can make a process slow before it fails. A limit is therefore part of the service’s behaviour, not simply a protective number entered during installation.
Check what the counters describe
Record the kernel and resource-control arrangement and verify what the chosen counters actually account for. Do not assume one process reading describes every buffer or accelerator allocation in the system. Observe the application and the essential surrounding services together. The kernel’s pressure interface can help identify time lost to CPU, memory or I/O contention. Pair that evidence with request timing so an operational limit can be judged by the behaviour it creates, including the ability to inspect the device during load.
Exercise an intentional overload
Use a disposable deployment to send work beyond the normal allowance and observe the declared response. The expected result might be rejected requests, a controlled service restart or a smaller accepted workload. Confirm that health reporting and administrative access remain available. Then bring the workload back within its supported limits and verify recovery. This is an acceptance exercise for a resource policy; it should end with documented bounds and observable behaviour, not a claim that the computer can never run out of memory.
Sources & publication notes
Retrospective period: March 2026. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.