Context
To achieve high-throughput, low-latency code generation, we are introducing a vLLM container to run alongside our local SearXNG instance. However, because our target environment utilizes a limited GPU resources, we cannot let vLLM run with its default configurations. vLLM aggressively pre-allocates VRAM for its KV Cache, which will cause the PyTorch DockerSandboxRunner to instantly encounter CUDA Out of Memory (OOM) errors during the execution phase.
Problem
- VRAM Starvation: Running vLLM without memory constraints will lock up the host GPU, leaving no VRAM available for the execution/testing sandbox.
- Lack of API Unload: Unlike Ollama, vLLM does not support an API endpoint to explicitly evict/unload a model (
keep_alive: 0). The API server must remain active, meaning it permanently retains its assigned VRAM while running.
Proposed Solution
- Spin up vLLM via Docker Compose using strict memory limiters (
--gpu-memory-utilization and --enforce-eager).
- Upgrade the Hardware Resource Manager (HARM) to use the Python
docker SDK to physically pause and unpause the vLLM container. This safely freezes the process and releases its VRAM allocations right before the PyTorch sandbox runs, restoring the container once execution completes.
Acceptance Criteria
Proposed Service & Code Architecture
docker-compose.yml Snippet:
vllm-server:
image: vllm/vllm-openai:latest
container_name: hephaestus_vllm
runtime: nvidia
ports:
- "8000:8000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
ipc: host
command: >
--model Qwen/Qwen2.5-Coder-3B-Instruct
--gpu-memory-utilization 0.5
--max-model-len 4096
--enforce-eager
networks:
- hephaestus_net
HARM Logic Blueprint:
import docker
import time
class HardwareResourceManager:
def __init__(self):
self.docker_client = docker.from_env()
self.vllm_container_name = "hephaestus_vllm"
async def evict_llm(self):
try:
container = self.docker_client.containers.get(self.vllm_container_name)
if container.status == "running":
print("[HARM] Pausing vLLM to reclaim VRAM...")
container.pause()
time.sleep(2)
except docker.errors.NotFound:
pass
async def restore_llm(self):
try:
container = self.docker_client.containers.get(self.vllm_container_name)
if container.status == "paused":
print("[HARM] Resuming vLLM service...")
container.unpause()
except docker.errors.NotFound:
pass
Context
To achieve high-throughput, low-latency code generation, we are introducing a
vLLMcontainer to run alongside our localSearXNGinstance. However, because our target environment utilizes a limited GPU resources, we cannot let vLLM run with its default configurations. vLLM aggressively pre-allocates VRAM for its KV Cache, which will cause the PyTorchDockerSandboxRunnerto instantly encounter CUDA Out of Memory (OOM) errors during the execution phase.Problem
keep_alive: 0). The API server must remain active, meaning it permanently retains its assigned VRAM while running.Proposed Solution
--gpu-memory-utilizationand--enforce-eager).dockerSDK to physicallypauseandunpausethe vLLM container. This safely freezes the process and releases its VRAM allocations right before the PyTorch sandbox runs, restoring the container once execution completes.Acceptance Criteria
vllm-serverservice to thedocker-compose.ymlmappingQwen/Qwen2.5-Coder-3B-Instruct.--gpu-memory-utilization 0.5,--max-model-len 4096, and--enforce-eagerto protect the host architecture.dockerPython SDK to our environment dependencies viauv add docker.evict_llm()andrestore_llm()methods inside a dedicatedHardwareResourceManagerclass using container pause/unpause hooks.execute_code_nodeto trigger the HARM isolation routine wrapping theDockerSandboxRunner.test_self_healing.pyunder the vLLM backend configuration.Proposed Service & Code Architecture
docker-compose.ymlSnippet:HARM Logic Blueprint: