MIT · docker-vram

Código abierto runtime

Repo: github.com/santiagolertora/docker-vram. Esto es el enchufe. No trae daemon. Sin uno el contenedor igual arranca; vram.limit se anota y no se hace cumplir.

Qué te da

vram-runtime envuelve runc. Pasás --runtime=vram y las labels que Docker ya sabe adjuntar. En Linux el runtime también monta los nodos NVIDIA del host, así el guest ve la GPU sin nvidia-container-toolkit.

Sin grant, A se come la GPU y B muere con CUDA OOM. — Este clone, sin daemon: los dos se pelean por la misma placa. Es el default de NVIDIA.

El grant (OOM local, el vecino sigue) está en la página enterprise.

Instalar (Linux)

Hace falta: Rust (cargo), Docker, una GPU NVIDIA.

git clone https://github.com/santiagolertora/docker-vram.git
cd docker-vram
cargo build --release -p vram-cli -p vram-runtime
./scripts/install.sh

install.sh copia solo vram y vram-runtime. La ruta es /usr/local/bin si podés escribir, si no ~/.local/bin. Eso va en el PATH.

Una vez, agregá el runtime en /etc/docker/daemon.json y reiniciá Docker:

{
  "runtimes": {
    "vram": { "path": "/usr/local/bin/vram-runtime" }
  }
}

sudo systemctl restart docker
docker run --runtime=vram -l vram.limit=4g ollama/ollama

El guest ve la GPU. Los 4g no son un grant hasta que algo conteste en http://127.0.0.1:8765.

Labels

Label	Qué es
`vram.limit`	Techo. `4g`, `512m`.
`vram.guarantee`	Reservado, si hay daemon.
`vram.priority`	`low` / `normal` / `high` / `critical`

Los mismos nombres que los flags de vram run.

vram init

Escribe ./docker-compose.yml en el directorio actual. Un servicio Ollama, runtime: vram, labels ya puestas. Si el archivo existe, avisa y no lo toca.

vram init
docker compose up -d
docker compose logs -f llama

Qué escribe:

services:
  llama:
    image: ollama/ollama
    runtime: vram
    ports:
      - "11434:11434"
    labels:
      vram.limit: "8g"
      vram.guarantee: "4g"
      vram.priority: high

En Linux, después de install.sh y daemon.json, ese compose arranca. Los 8g no son un grant hasta que haya daemon getvram en :8765. Editá el archivo si querés otra imagen u otro límite. vram init no pisa tus cambios.

CLI

vram --help lista cada comando. vram <command> --help es el resto.

Command	Qué hace
`vram init`	Escribe docker-compose.yml (Ollama + runtime: vram).
`vram run --limit=1g -- …`	Proceso nativo. Apple Silicon: esto, no Docker Desktop.
`vram status`	GPU + grants. Necesita daemon.
`vram ps`	Contenedores registrados. Necesita daemon.
`vram top`	TUI en vivo. Necesita daemon.
`vram inspect <id>`	Un grant. Necesita daemon.
`vram set <id> --limit=4g`	Cambiar un límite. Necesita daemon.

VRAM_DAEMON_URL pisa la URL del daemon (default http://127.0.0.1:8765). Si no hay nadie, status / ps / top / inspect / set lo dicen y salen 0.

Dos Ollama, one GPU

El script viene en el repo MIT: examples/linux-two-ollama.sh. B es 4g, A es 512m, los dos tiran tinyllama.

	Este clone (sin daemon)	Con daemon getvram
B 4g	Sirve. Puede morir cuando A se come la placa.	Sirve. Sigue sirviendo después de A.
A 512m	El label se anota. El load puede comerse la placa.	OOM local. B sigue contestando.

Corré el script después de instalar. Eso es el without. El with es enterprise.

Apple Silicon

M1 / M2 / M3 / M4. Memoria unificada, Metal, no CUDA. Docker Desktop es una VM Linux. --runtime=vram vive ahí. Metal del host no ve esos contenedores.

cargo build --release -p vram-cli
./scripts/install.sh
vram run --limit=1g -- ollama serve

Sin daemon el proceso igual arranca. El grant de Metal (libvram.dylib) es comercial, igual que libvram.so en Linux. No hay OOM en cascada al vecino como en una NVIDIA discreta. En Mac el producto es la cuota.