El proxy alojado es el mecanismo de acceso, no el modelo que sirves

El comando de una línea hf jobs run de Hugging Face levanta un endpoint vLLM privado y compatible con OpenAI en un solo comando, y la parte que sostiene todo no es el modelo — es el proxy alojado que limita cada solicitud a tu namespace. Según la publicación de 2026 de Hugging Face «Run a vLLM Server on HF Jobs in One Command», un flavor a10g-large cuesta 1,50 $/hora facturado por segundo, y la URL expuesta solo es accesible con un token de HF con acceso de lectura al job. La puerta se provisiona, no se construye.

Es la misma forma a la que volvemos una y otra vez: la capa de enrutamiento decide quién recibe una respuesta antes de que el modelo hable. Nombra el mecanismo, luego juzga si el mecanismo está realmente presente y midiendo — eso es el Teorema 3 de los 21 papers (una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo). Aquí la propiedad es acceso-limitado-a-mí, y el mecanismo es un proxy alojado que exige un bearer token vinculado a mi namespace. El modelo está aguas abajo de esa decisión.

Qué provisiona realmente HF Jobs

La publicación es franca sobre lo que el comando te da: «hf jobs run es docker run para la infraestructura de HF». Eliges una imagen (vllm/vllm-openai:latest), un flavor de GPU, un puerto que exponer y un timeout. La plataforma descarga la imagen en una GPU alquilada, arranca vLLM y enruta el puerto del contenedor a través de un proxy público de jobs. Ese proxy es el único mecanismo que hace tres cosas a la vez: te da una URL estable, termina la solicitud y aplica la puerta del bearer token.

La honestidad de la publicación merece una pausa. Los autores distinguen esto de un servicio de producción en la misma frase que lo introducen: «Si buscas un servicio gestionado y listo para producción, para eso están Inference Endpoints». No llaman a Jobs producción. Lo llaman «la forma más rápida de levantar un modelo para tests, evals o generación por lotes». Eso es un proveedor nombrando el alcance real del mecanismo en lugar de sobrevenderlo — la postura que intentamos mantener en nuestra propia hoja de ruta, donde Wallet & Token 🔵, Super App 🔵 y Community Credit 🔵 siguen siendo Roadmap hasta que sus mecanismos se entreguen y midan.

El patrón de exponer un puerto es la decisión de enrutamiento

La flag --expose 8000 es donde ocurre el enrutamiento. Le dice a la plataforma que enrute el puerto del contenedor a través del proxy público de jobs y devuelva una URL con la forma https://<job_id>--8000.hf.jobs. Todo lo demás — la elección del modelo, el tamaño de tensor-parallel, la plantilla de chat — es configuración de lo que corre detrás de esa ruta. La ruta es la frontera. Es la misma forma que nuestra regla de que la persistencia siempre se alcanza a través de un puerto (un trait), nunca un PgPool concreto: el llamador depende de la frontera, no de lo que hay detrás.

La puerta del bearer token es el alcance de acceso

La publicación es explícita y directa sobre lo que aplica el proxy: «Cada solicitud debe llevar un token de HF con acceso de lectura al namespace del job. Una visita simple del navegador será rechazada. En efecto, el proxy de jobs es tu puerta de API: el acceso se limita a ti (y a tu org)». Esa es toda la historia de control de acceso. No hay una segunda capa de auth dentro de vLLM. El proxy es la puerta.

[UNIQUE INSIGHT] La idea central es que la frontera de acceso es una propiedad de la capa de enrutamiento, no del modelo ni de la aplicación que hay detrás. Un servidor de modelos sin proxy es un puerto abierto. El mismo servidor detrás de un proxy limitado por namespace es un endpoint privado. El modelo no cambió; el enrutamiento sí. Esto es «the space is the router» en miniatura: la topología (quién puede alcanzar qué) se decide antes de que algo responda. En Everythink, la topología network→community→room enruta una solicitud antes de que una Sister o el Oracle la vean — el room es la puerta, no el modelo detrás del room.

La facturación por segundo es el mecanismo de control de costes

El modelo de facturación no es una nota al pie. Jobs factura por segundo de uso de hardware, y la publicación te dice que pares el servidor cuando termines: hf jobs cancel <job_id>. La flag --timeout es una red de seguridad que auto-detiene el job, pero «cancelar explícitamente es más barato». El mecanismo que controla el coste es el comando cancel más el medidor por segundo — no una promesa sobre eficiencia.

Esto es el Teorema 3 otra vez, aplicado al coste. La propiedad no pago por inactividad está garantizada por el mecanismo scale-to-zero, y scale-to-zero está presente en Inference Endpoints, no en Jobs. En Jobs, la propiedad no pago por inactividad está garantizada solo por el mecanismo yo cancelo explícitamente, lo que significa que está garantizada solo si un humano o un script lanza cancel. Si nadie cancela, pagas hasta el timeout. La publicación honra esto nombrando los dos productos uno al lado del otro en lugar de pretender que uno hace ambos.

El timeout es una red de seguridad, no un presupuesto

Un --timeout 2h no significa «esto cuesta como máximo dos horas de GPU». Significa «si olvido cancelar, la plataforma parará el job a las dos horas». La diferencia importa. Una red de seguridad te atrapa cuando el mecanismo primario (cancelar) falla; no reemplaza al mecanismo primario. Tratamos nuestro propio camino de rollback igual: un flujo de deploy-and-pray necesita un mecanismo de rollback, y la red de seguridad (un timeout, un health probe) no es el mecanismo — el rollback explícito sí lo es.

Jobs frente a Inference Endpoints es un emparejamiento de mecanismos

La comparación final de la publicación es la parte más limpia, porque se niega a clasificar los dos productos y en su lugar empareja cada uno con un trabajo. Recurre a HF Jobs cuando quieres «máxima flexibilidad y control» — eliges la imagen, las flags exactas de vllm serve y el hardware, y pagas por segundo mientras el job corre. Recurre a Inference Endpoints cuando quieres «algo más listo para producción» — control de acceso más fino (público, protegido o privado) y scale-to-zero para que no se te facture durante la inactividad.

Esto es un emparejamiento de mecanismos, no una comparación de características. La pregunta no es «cuál es mejor». La pregunta es «qué mecanismo garantiza la propiedad que necesito». Si la propiedad es experimentar, luego desmontar, Jobs encaja: la facturación por segundo más el cancel explícito es el mecanismo, y la flexibilidad sobre las flags de serve es el mecanismo para probar un modelo antes de comprometerte. Si la propiedad es endpoint durable sin gasto por inactividad, Inference Endpoints encaja: scale-to-zero es el mecanismo que garantiza no-facturar-en-inactividad, y el control de acceso más fino es el mecanismo que garantiza el alcance que quieres sin una puerta de enlace personalizada.

[ORIGINAL DATA] La serie de los 21 papers llama a esto la correspondencia mecanismo-propiedad: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Aplicado aquí, la decisión entre Jobs y Endpoints no es una cuestión de gusto — es una consulta. Lista la propiedad que necesitas (coste-cero-en-inactividad, acceso-público, control-exacto-de-flags, experimento-por-segundo), luego elige el producto cuyo mecanismo implementa y mide esa propiedad. Si ninguno lo hace, ninguno es la herramienta correcta, y ninguna configuración lo hará así.

El mecanismo de sharding debe coincidir con el flavor

La sección de la publicación sobre modelos más grandes esconde una regla de mecanismo que vale la pena extraer. Para servir un Qwen3.5 mixture-of-experts de 122B en 2× H200, fijas --tensor-parallel-size 2, y la regla se establece claramente: «--tensor-parallel-size debería coincidir con el número de GPUs del flavor (h200x2 → 2, h200x8 → 8)». Desempareja los dos y el mecanismo no funciona — el modelo no se fragmentará correctamente entre las GPUs que realmente tienes.

La misma sección nombra el mecanismo de memoria: para la arquitectura híbrida Mamba/attention con un contexto por defecto de 256K tokens, «Limitar la longitud del contexto y el número de secuencias concurrentes lo mantiene dentro de la memoria de las GPUs. Si un modelo falla al arrancar con un error de out-of-memory o cache-block, lo primero que hay que probar es reducir estos dos». El mecanismo para que un modelo quepa en memoria es limitar --max-model-len y --max-num-seqs al presupuesto que las GPUs realmente tienen. Es una restricción medida, no una afirmación de vibes sobre capacidad.

El harness es el mecanismo del agente, no el modelo

La sección del agente de codificación Pi de la publicación es una ilustración silenciosa de una regla que sostenemos firmemente: el harness es el mecanismo, no el modelo. Para respaldar un agente de codificación de terminal, rearrancas vLLM con --enable-auto-tool-choice y --tool-call-parser hermes, porque «los agentes conducen el modelo a través de tool calls, y vLLM solo los acepta si el servidor se arranca con tool calling habilitado». El modelo no ganó una capacidad. El harness (parseo de tool calls, el bucle del agente Pi) se cableó al servidor, y ese cableado es el mecanismo que hace funcionar las tool calls. Lo hemos escrito en otro lugar: no contratas un agente, cableas un mecanismo. El agente es el cableado; el modelo es el motor detrás.

Cross-domain: the space is the router

Cada mecanismo de la publicación de HF Jobs tiene un paralelo en nuestro propio stack, y nombrarlos es cómo mantenemos la arquitectura honesta en lugar de aspiracional.

• El proxy como puerta ↔ el room como puerta. El proxy de jobs de HF limita el acceso a un namespace. En Everythink, la topología network→community→room limita el acceso a un room. «The space is the router» significa que el room enruta una solicitud antes de que una Sister o el Oracle respondan — el room es la puerta, el modelo está detrás de la puerta. La forma del mecanismo es idéntica; el dominio es distinto.
• El bearer token ↔ el Eye Key. El token de HF con acceso de lectura al namespace del job es la credencial que te lleva a través del proxy. Nuestro Eye Key (con un espacio) es la credencial que te lleva a través de nuestra puerta de API, y el texto plano del Eye Key nunca toca disco — solo el HMAC y la huella persisten. La propiedad soberanía-de-credencial está garantizada por el mecanismo HMAC-antes-de-persistir, igual que acceso-limitado-a-mí está garantizada por bearer-token-vinculado-a-namespace. Ambas son garantías de la capa de enrutamiento, no del modelo.
• Tensor-parallel ↔ normalización del Oracle. La regla de sharding (el tamaño de paralelismo coincide con el número de GPUs) es un mecanismo de emparejamiento de restricciones. Nuestro Oracle ✅ normaliza probabilidades en exactamente un lugar — los consumidores confían en sum(probability) ≈ 1.0, escenarios ordenados descendientemente, entropía en nats. Ambos son «el mecanismo debe coincidir con la restricción»: tamaño de shard con número de GPUs, normalización con una ubicación. Equivócate en el emparejamiento y la garantía se rompe.

[PERSONAL EXPERIENCE] El HAI Engine ha corrido en producción desde 2016, y la lección que reaprendemos continuamente es la que la publicación de HF Jobs establece sin alharaca: la puerta es lo primero que provisionas, y el modelo es lo segundo que configuras. Un modelo detrás de la puerta equivocada es un puerto abierto. Un modelo detrás de la puerta correcta es un producto.

Qué significa esto para construir en Everythink

El stack de Everythink está moldeado por la misma regla que sigue la publicación de HF Jobs. Las Sisters ✅ nunca escriben a Postgres — devuelven un SisterOutput y el Loom persiste a través de un puerto (LoomStore), igual que vLLM sirve a través de un proxy. El Oracle ✅ fusiona los borradores de las Sisters en un Ensemble normalizado en exactamente un lugar, igual que el proxy es el único lugar donde se aplica el acceso. El World Monitor ✅ es una puerta de enlace que lee de una caché, nunca de los upstreams, limitada por nuestra planificación de polling en lugar de por el número de clientes — igual que el proxy de jobs limita el acceso por namespace en lugar de por modelo.

Los módulos que aún no son Production llevan sus propias etiquetas de honestidad y se mantienen etiquetados. Matchmaking ⚠️, Marketplace ⚠️ y Calendar ⚠️ son Partial — el mecanismo existe pero aún no mide a escala completa. Wallet & Token 🔵, Super App 🔵 y Community Credit 🔵 son Roadmap, pre-revenue, sujetos a revisión Howey, y no los promoveremos en silencio. Es la misma postura que la publicación de HF Jobs toma cuando separa Jobs de Endpoints: nombra el mecanismo, nombra su alcance, no asciendas un estado.

Alcance civil y defensivo únicamente. No construimos herramientas de targeting ni ofensivas. Una capa de enrutamiento que limita el acceso es un mecanismo defensivo — decide quién alcanza qué — y esa es la única dirección en la que la apuntamos.

Conclusiones clave

• El proxy es la puerta, no el modelo. El proxy de jobs de HF limita cada solicitud a tu namespace mediante un bearer token. El acceso es una propiedad de la capa de enrutamiento, no del modelo detrás.
• La facturación por segundo es un mecanismo, no un precio. La propiedad sin gasto por inactividad está garantizada por scale-to-zero (Inference Endpoints) o por cancel explícito (Jobs). El timeout es una red de seguridad, no el mecanismo primario.
• Jobs frente a Endpoints es un emparejamiento de mecanismos. Lista la propiedad que necesitas, luego elige el producto cuyo mecanismo la implementa y mide. Es una consulta, no una cuestión de gusto.
• El tamaño de shard debe coincidir con el número de GPUs; los límites de memoria deben coincidir con el presupuesto de GPU. Ambos son mecanismos de emparejamiento de restricciones. Equivócate y la garantía se rompe.
• El harness es el mecanismo del agente. Las tool calls funcionan porque el servidor se arrancó con parseo de tool calls habilitado, no porque el modelo se volviera más listo. Cableas un mecanismo; no contratas un agente.
• The space is the router. El room enruta antes de que el modelo responda, igual que el proxy enruta antes de que vLLM responda. La puerta se provisiona primero; el modelo se configura segundo.

Preguntas frecuentes

¿Cuál es el único mecanismo que hace privado a un endpoint de HF Jobs? El proxy alojado de jobs. Cada solicitud debe llevar un token de HF con acceso de lectura al namespace del job, y una visita simple del navegador se rechaza. El modelo detrás del proxy no hace control de acceso propio — el proxy es la puerta.

¿Por qué la publicación distingue HF Jobs de Inference Endpoints en lugar de llamar a Jobs producción? Porque los mecanismos difieren. Jobs factura por segundo y se detiene solo con cancel explícito o timeout; Inference Endpoints añaden scale-to-zero y control de acceso más fino. Llamar a Jobs producción ascendería un estado que el mecanismo no soporta — lo mismo que nos negamos a hacer con nuestros módulos Roadmap.

¿Cómo funciona el tamaño de tensor-parallel y por qué importa? --tensor-parallel-size debe igualar el número de GPUs del flavor (h200x2 → 2). Es un mecanismo de emparejamiento de restricciones: el sharding debe coincidir con el hardware. Desemparéjalo y el modelo no se fragmentará correctamente entre las GPUs que tienes.

¿Qué tiene que ver esto con el «the space is the router» de Everythink? El proxy de HF limita el acceso a un namespace antes de que el modelo responda. La topología network→community→room de Everythink limita el acceso a un room antes de que una Sister o el Oracle respondan. Ambas son garantías de la capa de enrutamiento — la puerta se provisiona primero, el modelo se configura segundo.

¿Es el HAI Engine de Everythink el mismo tipo de mecanismo? La misma forma, dominio distinto. El HAI Engine ha corrido en producción desde 2016, y su regla es la misma: la puerta (el room, el puerto, el proxy) enruta antes de que el motor responda. Las Sisters devuelven salida y el Loom persiste a través de un puerto; el Oracle normaliza en un lugar. El mecanismo se nombra, no se adjetiva.

Si quieres una plataforma donde la capa de enrutamiento se provisione antes de que el modelo hable, donde cada capacidad lleva una etiqueta de honestidad y donde la puerta es lo primero que construyes — crea tu red.

Sources

• 2026 — Hugging Face, «Run a vLLM Server on HF Jobs in One Command»: https://huggingface.co/blog/vllm-jobs