Cómo funciona ElephantPool

1. La forma del sistema

Tres partes, un solo contrato entre ellas.

El host sondea hacia fuera; nada se conecta hacia él. Esa única decisión explica por qué una GPU tras un router doméstico funciona sin configuración alguna, y por qué un host nunca expone un puerto a Internet.

2. Qué pasa con una petición

1. Tu llamada llega al gateway con una clave API. Comprobamos la clave, estimamos el coste, y confirmamos que tu saldo prepagado y el límite de la clave lo cubren.
2. El job se encola para el modelo pedido. Lleva tus mensajes y nada sobre ti.
3. Un host lo reclama — uno que ha demostrado, por benchmark, en esa máquina, que puede servir ese modelo.
4. La GPU produce tokens, transmitidos de vuelta a través del gateway según se generan.
5. El job se liquida. Se cuentan los tokens, tu saldo se carga al micro-céntimo, el host recibe el 80%, y el prompt desaparece del registro. Lo que queda: recuentos y marcas de tiempo — nada de texto.
6. El host firma un recibo con una clave que nunca sale de su máquina: modelo, build exacto, recuentos de tokens, tiempos.

Los prompts viven en memoria mientras dura el job. No se escriben a disco, no se registran y no se usan para entrenar — ni nosotros ni los hosts.

3. mahout — el agente en el host

mahout es un único binario Rust open source de unos 5 MB, llamado así por la persona que monta el elefante. Corre como usuario normal, no necesita root, y hace seis cosas:

• Sondea la máquina — CPU, RAM, GPUs y su VRAM.
• Se inscribe con un código de un solo uso desde el panel, generando localmente una identidad ed25519; la clave privada nunca sale de la máquina.
• Descarga y verifica pesos y motor en una caché direccionada por contenido — contra huellas SHA-256 fijadas, durante la descarga y en cada carga.
• Supervisa el motor: lo arranca, vigila su salud, lo reinicia una vez si muere, lo para limpiamente.
• Sondea y sirve jobs, transmitiendo tokens por lotes.
• Firma un recibo por job, añadido a un registro local que puedes verificar sin conexión con mahout receipts verify.

Se pausa solo mientras usas la máquina, y mahout uninstall muestra un plan de borrado antes de quitar nada. El código y el instalador son públicos.

4. Los modelos son builds, no archivos

Un modelo es lo que pide un cliente (qwen3.8-27b). Un build es un artefacto concreto: una cuantización, un motor, un archivo exacto de una revisión upstream exacta, con su SHA-256 publicado.

Esa separación es lo que permite a un mismo modelo llegar a cada clase de GPU. Qwen3.8 27B se entrega en cinco builds, del Q5_K_M para una tarjeta de 24 GB al IQ2_XXS para una de 8 GB. La petición del cliente nunca cambia; el host elige el build que su tarjeta puede correr de verdad.

Un build solo se vuelve reclamable en una máquina después de que esa máquina lo haya cargado y medido. Las estimaciones deciden qué merece descargarse; las mediciones deciden qué merece enrutarse.

5. Los motores — y la cuestión de los contenedores

mahout no hace la aritmética él mismo. Dirige un motor de inferencia, y el motor pertenece al build, no al host — por eso añadir un motor es un añadido y no una reescritura.

Entonces, ¿qué imágenes son, exactamente?

Hoy, en una máquina host: ninguna. No hay imagen Docker que tirar, ni demonio que instalar, ni root que conceder. Un binario de 5 MB y un archivo de modelo verificado por checksum son toda la huella. Creemos que es la forma correcta para un PC gamer en un salón, y no quisimos fingir otra cosa por sonar cloud-native.

Los contenedores importan en el otro extremo del mercado. Cuando llegue el nivel vLLM, las imágenes de motor serán imágenes upstream referenciadas por digest — vllm/vllm-openai@sha256:…, no un tag móvil — y la lista de imágenes que un host puede correr está compilada en la propia release de mahout. El plano de control puede decir a tu máquina cuál de las imágenes permitidas arrancar; nunca puede introducir una nueva. El contenedor no tiene salida de red y un montaje de solo lectura de los pesos verificados.

Tres reglas gobiernan ese nivel, las mismas que gobiernan los pesos:

• Fijado por digest. Un digest es inmutable y lo verifica el runtime; un tag es una promesa que otro puede cambiar.
• Lista blanca en el cliente. Un host corre lo que permite su propio binario, no lo que pide un servidor.
• Opt-in por host. Nadie amanece hospedando un motor nuevo.

¿Y el registro?

Para motores upstream no alojamos imágenes — replicar una imagen pública añade terabytes de almacenamiento y cero seguridad, porque el digest ya prueba lo que recibiste. Operamos registro propio para exactamente un caso: imágenes que nosotros construimos. La primera es el hook de verificación — un build del motor que emite un compromiso criptográfico sobre sus propias activaciones, para que la salida de un job pueda comprobarse en vez de creerse. Esa imagen tiene que ser nuestra: se publicará desde nuestro registro europeo, firmada y fijada por digest como todo lo demás.

En corto: hoy ninguna imagen en los hosts; imágenes upstream fijadas por digest cuando llegue el nivel vLLM; registro propio solo para imágenes que producimos nosotros.

6. Qué se verifica, y quién

Una comprobación fallida no es un aviso: el artefacto se descarta y el job no corre. Preferimos que un host no sirva nada a que sirva algo que no podemos nombrar con exactitud.

7. El dinero

Los clientes pagan por token, en euros, por modelo, sin suscripción y sin mínimo: recargas un saldo prepagado, y cada clave API lleva un límite de gasto para que un bucle desbocado no pueda vaciarlo. Los hosts reciben el 80% de los ingresos de los jobs que sirven, por transferencia SEPA desde 50 €.

El panel expresa las ganancias de un host en euros por hora de servicio, calculadas con la tasa de decodificación que midió su propia tarjeta — nunca una proyección, y nunca una cifra mensual, porque eso exigiría prometer una demanda que no podemos prometer.

8. Donde somos honestos sobre los límites

• El motor corre hoy como proceso hijo sin privilegios ligado a localhost, no dentro de una sandbox de syscalls. El endurecimiento (seccomp, Landlock, contenedores sin egress) está previsto y aún no hecho.
• Linux y Windows x86_64 son las únicas plataformas host publicadas. macOS es portable en principio y no entregado en la práctica.
• La verificación de salida (compromisos de activaciones) está diseñada y aún no se impone; las garantías de hoy son recibos y reputación.

La especificación técnica distingue en todo momento lo que corre hoy de lo que está diseñado. El AGENTS.md de mahout, en el repositorio público, hace lo mismo.