getvram.com · la capa, no el alquiler de GPUs

Tu GPU.
Un workload
a la vez. El resto espera.

getvram pone un techo de VRAM a cada contenedor. A se pasa y hace OOM local. B sigue sirviendo. El runtime es MIT. El grant se compra.

El runtime → El grant

docker-compose.yml

# Sin getvram: un contenedor se queda con la GPU
services:
  llm:
    image: ollama/ollama
    # ❌ Se come los 8 GiB. El vecino muere por OOM
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              capabilities: [gpu]

docker-compose.yml — getvram

# Con getvram: cada servicio tiene su techo
services:
  llm-inference:
    image: ollama/ollama
    runtime: vram
    labels:
      vram.limit: "6144m"      # ✅ 6 GiB grant
      vram.priority: "high"

  embedder:
    image: my-embedder
    runtime: vram
    labels:
      vram.limit: "1024m"      # ✅ 1 GiB, auto-burst if idle

  training:
    image: pytorch/pytorch
    runtime: vram
    labels:
      vram.limit: "2048m"      # ✅ 2 GiB, BestEffort QoS
      vram.priority: "low"

Dos tenants Ollama en una GPU: vram-ollama-a a 512 MiB, vram-ollama-b a 4 GiB — vram-ollama-a (512 MiB) se pasa del techo. vram-ollama-b (4 GiB) sigue sirviendo.

Esto ya lo viste

💀

OOM en cascada

A se queda con 8 GiB. B cae con CUDA out of memory. Matás A. Reiniciás B. Otra vez.

⚙️

Infierno de drivers

nvidia-container-toolkit, versiones de CUDA, WSL2, MPS. Horas de config antes de una línea de modelo.

🐌

Cuello de botella

La GPU al 5% mientras el LLM espera. El resto de contenedores bloqueados.

🔒

Sin aislamiento

Un contenedor mal portado ensucia el estado compartido. MPS no aísla memoria: un crash puede tumbar el contexto entero.

Tecnología

Virtual Memory de GPU.
No es multiplexar en software.

getvram no se mete de proxy entre el contenedor y la GPU. Habla con la CUDA Driver API a nivel de MMU de la GPU, la misma capa que usa el vGPU de NVIDIA.

Reserva de direcciones virtuales

Al arranque, cuMemAddressReserve reserva un espacio virtual del tamaño de la VRAM. Todavía no hay páginas físicas.

Handles físicos por contenedor

Al registrar (hook OCI), cuMemCreate crea un bloque físico del tamaño de la cuota. El handle se puede pasar entre procesos.

Mapeo virtual aislado

cuMemMap + cuMemSetAccess pega cada handle a un rango virtual distinto. Los punteros de A no se cruzan con los de B. Lo impone la MMU.

Resize en caliente, sin copiar

Si un contenedor está idle, se pueden remapear páginas a otro en microsegundos. Sin copiar datos. Un cuMemUnmap + cuMemMap.

Host (vram-daemon)

CUDA VMM Engine
cuMemCreate · cuMemMap · cuMemSetAccess

↕ IPC socket (OCI hook)

Container A — LLM

VA: 0x0000 – 0x17FF
6 GiB · Priority: HIGH

Container B — Embedder

VA: 0x1800 – 0x1BFF
1 GiB · Priority: NORMAL

Container C — Training

VA: 0x1C00 – 0x1FFF
1 GiB · Priority: LOW

vs. alternativas

Por qué no MPS, MIG o time-slicing

Qué	NVIDIA MPS	NVIDIA MIG	Time-Slicing	getvram
Aislamiento de memoria	❌ Nada	✅ Físico	❌ Nada	✅ VA-level (MMU)
Resize dinámico	❌ Estático	❌ Hay que reconfigurar	⚠️ Solo burst	✅ Hot-resize in μs
Cualquier CUDA	✅	⚠️ Solo A100/H100	✅	✅ Pascal+
Docker Desktop	❌	❌	❌	✅ Docker en Linux · `vram run` en Mac
OOM por contenedor	❌ Cascada	✅	❌	✅ Aislado
Config	Hay que armar MPS	Hardware + perfil	Flag del driver	Labels de Docker
Apple Silicon (M-series)	❌	❌	❌	✅ Metal MTLHeap (v2)

Licencia

Lo corrés en tu GPU.
Nosotros no hosteamos nada.

Licencia de software, una máquina. No es SaaS. No es un producto de clúster. Kubernetes no se vende porque no está hecho.

MIT runtime

Plugin de Docker y comando vram, gratis
Un número de VRAM en el contenedor (vram.limit=4g)
En Linux el contenedor ve la GPU
vram init escribe un compose de Ollama

El número es un label. Nadie lo hace cumplir. Un vecino greedy se puede quedar con la placa.

GitHub

Una máquina

getvram

$199 una GPU, un año

Dos (o veinte) modelos en la misma placa, cada uno con un techo de VRAM
Si uno se pasa, solo ese hace OOM. El otro sigue generando
Una página en el browser que muestra quién tiene qué
Lo instalás vos. Linux NVIDIA, o un Mac con vram run
Si se rompe, un mail. Contesta una persona. No hay mesa 24/7

Licencia de esa máquina. No nos quedamos con tu GPU ni con tus modelos.

hello@getvram.com

FAQ

Lo que la gente busca

¿Dos contenedores Ollama o vLLM pueden compartir una GPU NVIDIA?

Con --gpus all comparten el device, no la memoria. El primer cudaMalloc se suele quedar con la placa. El segundo muere con CUDA OOM. getvram pone un techo de VRAM a cada contenedor. Pasarse es OOM local. El vecino sigue generando.

¿El repo MIT hace cumplir `vram.limit`?

No. docker-vram es el runtime y el CLI. Los contenedores arrancan. Las labels se anotan. Ese repo no trae daemon. El grant pago es lo que lo hace cumplir en tu máquina.

¿Anda en un Mac?

Docker Desktop es una VM Linux. Metal del host no ve esos contenedores. En Apple Silicon: vram run --limit=1g -- ollama serve. Memoria unificada: el producto es la cuota, no un OOM en cascada al vecino.

¿getvram es un cloud de GPUs?

No. Lo instalás en hardware que ya tenés. No alquilamos GPUs y no hosteamos tus modelos.

getvram.com

Dos modelos. Una GPU.
El vecino sigue contestando.

Dejá el mail si querés el grant en tu placa. El runtime MIT ya está en GitHub. No alquilamos GPUs.

Mail de trabajo o GitHub GPU principal Para qué

Sin tarjeta. Si el sitio no alcanza un servidor de lista, una copia queda en este navegador hasta que la borres. Cookies · Términos

Tu GPU. Un workload a la vez. El resto espera.