Comercial

Grant enterprise

Las mismas labels que el runtime MIT. El daemon en :8765 las convierte en grant. A se pasa del límite y hace OOM local. B sigue sirviendo. Vendemos esa capa. No alquilamos GPUs.

Qué comprás

Daemon, allocator, CUDA VMM, libvram.so / libvram.dylib, dashboard. Admisión: un tercer tenant que no entra se rechaza al registrar. Nadie muere a mitad de kernel por eso.

Con getvram, A tiene techo de 512 MiB y hace OOM local. B a 4 GiB sigue sirviendo.
La misma GPU que el diagrama without. A es OOM local. B sigue con su heap.
Sin (solo MIT)Con 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.
C extra 1g No hay puerta. Arranca igual. Rechazado al registrar.

La prueba

Dos Ollama en una NVIDIA de escritorio. B a 4g carga tinyllama y genera. A a 512m prueba el mismo modelo y falla el grant. B genera de nuevo.

Dashboard: vram-ollama-a a 512 MiB, vram-ollama-b a 4 GiB
vram-ollama-a 512 MiB. vram-ollama-b 4 GiB. Eso es lo que se compra.

Cómo funciona el grant

  1. El hook OCI (MIT) lee vram.limit y habla con el daemon.
  2. El daemon admite al tenant o rechaza si no hay presupuesto.
  3. La carga hace load de libvram. En Linux el proceso importa un heap VMM del tamaño del grant (cuMemImportFromShareableHandle).
  4. Las allocs gastan ese heap. Sobre el grant: CUDA_ERROR_OUT_OF_MEMORY en ese proceso. El vecino sigue con su handle.

Solo contar (el hook anota bytes y CUDA igual saca de la placa) no es el producto en Linux. El heap importado sí.

El runtime MIT anota labels. El daemon enterprise y libvram hacen cumplir el grant.

Linux

Instalá primero el runtime MIT (docs open source). Después el daemon y libvram.so en el host. El runtime monta la librería y el socket de aislamiento en el guest. 

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

La demo que corrimos: B vram.limit=4g en :11444, A vram.limit=512m en :11445, los dos con tinyllama. A falla el grant. B sigue contestando.

vram status, ps, top, inspect, set hablan con http://127.0.0.1:8765. Si ya tenés ese daemon, el script MIT examples/linux-two-ollama.sh es el with.

Apple Silicon

Docker Desktop es una VM Linux. Metal del host no puede policíar esos contenedores. Camino: vram run --limit=1g -- ollama serve with libvram.dylib.

Memoria unificada. No hay cascada CUDA al vecino. A sobre el grant recibe nil de Metal. B igual aloca. C se rechaza al registrar. En Mac el producto es la cuota, no matar al vecino.

Dashboard

Con el daemon arriba: http://127.0.0.1:8765/. Presupuesto de GPU, techo y gasto de cada tenant, nombres de Docker (vram-ollama-a, vram-ollama-b).

Mail a hello@getvram.com por una licencia de máquina y por soporte. El daemon lo corrés en tu máquina. No hay clúster hosteado ni SKU de Kubernetes. El soporte es mail. Contestamos. No es un contrato de operaciones 24/7.