Four gigabytes free and a two gigabyte allocation failing is the clearest possible demonstration that free memory and largest contiguous block are different numbers, and only one of them predicts an OOM. Worth alerting on the second one, because a dashboard showing total free will look calm right up to the crash. Heterogeneous request sizes are what turn this from theory into a nightly incident - uniform workloads reuse blocks cleanly, mixed resolutions leave gaps nothing fits into. The mitigation that has helped me most before reaching for a custom pool is bucketing: quantise request dimensions to a small set of sizes so allocations are interchangeable, and accept a little wasted padding in exchange for a reusable pool. It is the same insight behind PagedAttention on the LLM side - the fix was treating a big contiguous reservation as pages rather than making anything faster. Also worth capping concurrency by memory rather than by request count, since a queue of large jobs and a queue of small ones are very different loads under the same number.