24GB VRAM Enough? Berth Lets Multiple AI Engines Take Turns

In the local AI model deployment community, VRAM anxiety is an eternal topic. Is 24GB on an RTX 4090 enough? If you're running ComfyUI, LLM inference, speech recognition, and other engines simultaneously, the answer is clearly no—unless they learn to "take turns on duty." The Berth project, released by a developer on Reddit, was born precisely to solve this pain point.

VRAM Conflicts: The Daily Frustration of Multi-Engine Coexistence

Anyone who has tinkered with multiple model services on Linux has probably experienced scenarios like this: a node process unexpectedly becomes an orphan process, ComfyUI auto-starts and occupies 500MB of VRAM, and Strata can't get any allocation. Even more insidious is the problem that a Flux GGUF model left over from a previous workflow might still be hanging in ComfyUI without being released—and you've long forgotten it exists.

The original author admits he "runs into problems every day." Manually checking and cleaning up VRAM usage is not only tedious but error-prone—you have to confirm that Strata or llama-swap isn't stuck in a loading state, and figure out which process is secretly hogging VRAM. When multiple devices share the same RTX 4090, this chaos gets amplified further.

GGUF is a model file format proposed by the llama.cpp project, short for GPT-Generated Unified Format. It packages model weights, tokenizer configuration, and metadata into a single file, and supports multiple quantization precisions (such as Q4_K_M, Q8_0), enabling large models to run on consumer-grade VRAM. Flux is an image generation model launched by Black Forest Labs, whose GGUF quantized versions are often used in ComfyUI to reduce VRAM usage. Since GGUF models remain resident in VRAM after loading and are not automatically released, they easily become "invisible" VRAM consumers during multi-engine switching—which is precisely one of the reasons Berth needs to automatically unload engines.

Berth's Solution: A System-Level VRAM Scheduler

Berth's core idea is straightforward: turn VRAM management from "manual operation" into a "system service." It monitors your GPU status, automatically unloading the current engine and loading the target engine when needed—all without human intervention. The author emphasizes that each engine can exclusively use all VRAM while running, with no "VRAM consumers" squeezing each other out.

The tool natively supports switching between multiple engines including Ninfer-4090 (llama-swap), Strata, ComfyUI, and OpenWebUI. "Native" here means you don't need to remember how to start each engine, nor worry about the old engine not being properly unloaded during switching. Berth maintains a complete operation log, so you can check at any time what time, which engine, and what operation was performed.

A typical use case: during the day you need to run image workflows in ComfyUI, and at night let the machine run Hermes for inference. With Berth, this switching can be as natural as changing TV channels, with logs available throughout.

llama-swap is a lightweight model-switching proxy for loading and unloading different models on demand in the llama.cpp server; Strata and Polystrata are inference engines/frameworks for local AI workflows (commonly seen in image generation or composite pipeline scenarios); OpenWebUI is a self-hosted LLM chat frontend. These tools each manage VRAM independently and lack a unified coordination mechanism, making it easy for "one engine to hold VRAM without releasing it while another engine cannot load." Berth, as a system-level scheduling layer, is designed to replace each engine's built-in loading logic and take unified control of VRAM allocation and release.

Balancing API Services and Gaming Scenarios

Beyond local switching, Berth also provides API service capabilities. When you need to call engines programmatically, simply use Berth as the API endpoint—it can load Strata, Polystrata, and any custom engine. This means upper-layer applications don't need to care which engine is responding underneath; Berth handles the scheduling.

Even more practical is the protection for gaming scenarios. Many developers have encountered this awkward situation: while playing a game, a cron job or API request suddenly grabs the GPU, and the frame rate instantly plummets. One of Berth's design goals is to avoid such conflicts—when you're gaming or running custom workflows, no background tasks will seize the GPU.

The project's code is hosted on GitHub (T-Crypt/berth). For users who need to run multiple AI workloads on a single card, this is an infrastructure-layer tool worth paying attention to. Whether 24GB of VRAM is enough may not depend on the capacity itself, but on how you schedule it.

Cron jobs are a mechanism in Linux/Unix systems for automatically executing commands based on a schedule, commonly used for timed batch jobs, model inference, or data synchronization. On a machine where multiple engines share a single GPU, cron-triggered background tasks may load models and occupy VRAM without the user's knowledge, causing frame rate drops or even out-of-memory (OOM) errors in running games or interactive workflows. Berth intercepts such requests through its scheduling layer, deferring or queuing background tasks when the GPU is occupied by foreground tasks, thereby avoiding resource contention.

Why "Taking Turns" Is More Practical Than "Stacking VRAM"

Consumer GPUs' VRAM ceilings are unlikely to increase significantly in the short term, while AI models' VRAM demands continue to grow. For individual developers and small teams, rather than pursuing larger VRAM, it's better to optimize the utilization of existing resources. Berth represents the latter approach: eliminating idle occupancy through scheduling, letting the same GPU serve different tasks at different times.

Of course, this approach has a prerequisite—your workloads cannot require multiple engines to be online simultaneously. If your scenario needs LLMs and image generation to respond to requests at the same time, turn-based scheduling won't help. But for most individual developers and research scenarios, tasks are inherently serial, so Berth's assumption holds.

One-line Summary

Berth uses system-level VRAM scheduling to let multiple AI engines take turns exclusively using VRAM on a single 4090.

Paragraph Summary

Berth is a system-level VRAM scheduling service released by a Reddit developer, designed to solve VRAM conflicts when multiple AI engines coexist on a single RTX 4090. It monitors GPU status, automatically unloading the current engine and loading the target engine when needed, supporting native switching among ComfyUI, Strata, llama-swap, OpenWebUI, and more, with each engine exclusively using all VRAM while running. Berth also provides API endpoint services, can load custom engines, and protects games or foreground workflows from GPU preemption by cron or API requests. Its core idea is to eliminate idle VRAM occupancy through scheduling, suitable for individual developer scenarios with serial tasks, but it cannot support multiple engines being online simultaneously.