O proxy hospedado é o mecanismo de acesso, não o modelo que você serve

O comando de uma linha hf jobs run do Hugging Face levanta um endpoint vLLM privado e compatível com OpenAI num único comando, e a parte que sustenta tudo não é o modelo — é o proxy hospedado que restringe cada requisição ao seu namespace. Segundo a publicação de 2026 do Hugging Face «Run a vLLM Server on HF Jobs in One Command», um flavor a10g-large custa 1,50 $/hora faturado por segundo, e a URL exposta só é acessível com um token de HF com acesso de leitura ao job. A porta é provisionada, não construída.

É a mesma forma à qual voltamos sempre: a camada de roteamento decide quem recebe uma resposta antes de o modelo falar. Nomeie o mecanismo, depois julgue se o mecanismo está realmente presente e medindo — isso é o Teorema 3 dos 21 papers (uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo). Aqui a propriedade é acesso-limitado-a-mim, e o mecanismo é um proxy hospedado que exige um bearer token vinculado ao meu namespace. O modelo está a jusante dessa decisão.

O que o HF Jobs realmente provisiona

A publicação é franca sobre o que o comando te dá: «hf jobs run é docker run para a infraestrutura do HF». Você escolhe uma imagem (vllm/vllm-openai:latest), um flavor de GPU, uma porta para expor e um timeout. A plataforma baixa a imagem numa GPU alugada, arranca o vLLM e roteia a porta do contentor através de um proxy público de jobs. Esse proxy é o único mecanismo a fazer três coisas ao mesmo tempo: dá-te uma URL estável, termina a requisição e aplica a porta do bearer token.

A honestidade da publicação merece uma pausa. Os autores distinguem isto de um serviço de produção na mesma frase que o introduzem: «Se procuras um serviço gerido e pronto para produção, para isso é que servem os Inference Endpoints». Eles não chamam ao Jobs produção. Chamam-lhe «a forma mais rápida de levantar um modelo para testes, evals ou geração em lote». Isso é um fornecedor a nomear o alcance real do mecanismo em vez de o sobrevender — a postura que tentamos manter no nosso próprio roadmap, onde Wallet & Token 🔵, Super App 🔵 e Community Credit 🔵 continuam Roadmap até os seus mecanismos serem entregues e medidos.

O padrão de expor uma porta é a decisão de roteamento

A flag --expose 8000 é onde o roteamento acontece. Diz à plataforma para rotear a porta do contentor através do proxy público de jobs e devolver uma URL com a forma https://<job_id>--8000.hf.jobs. Tudo o resto — a escolha do modelo, o tamanho de tensor-parallel, o template de chat — é configuração do que corre atrás dessa rota. A rota é a fronteira. É a mesma forma que a nossa regra de que a persistência é sempre alcançada através de uma porta (um trait), nunca um PgPool concreto: o chamador depende da fronteira, não do que está atrás.

A porta do bearer token é o alcance de acesso

A publicação é explícita e direta sobre o que o proxy aplica: «Cada requisição tem de levar um token de HF com acesso de leitura ao namespace do job. Uma visita simples do navegador será rejeitada. Em efecto, o proxy de jobs é a tua porta de API: o acesso é limitado a ti (e à tua org)». Essa é toda a história de controlo de acesso. Não há uma segunda camada de auth dentro do vLLM. O proxy é a porta.

[UNIQUE INSIGHT] A ideia central é que a fronteira de acesso é uma propriedade da camada de roteamento, não do modelo nem da aplicação que está atrás. Um servidor de modelos sem proxy é uma porta aberta. O mesmo servidor atrás de um proxy limitado por namespace é um endpoint privado. O modelo não mudou; o roteamento mudou. Isto é «the space is the router» em miniatura: a topologia (quem consegue alcançar o quê) é decidida antes de algo responder. Na Everythink, a topologia network→community→room roteia uma requisição antes de uma Sister ou o Oracle a verem — o room é a porta, não o modelo atrás do room.

A faturação por segundo é o mecanismo de controlo de custo

O modelo de faturação não é uma nota de rodapé. O Jobs fatura por segundo de uso de hardware, e a publicação diz-te para parar o servidor quando terminares: hf jobs cancel <job_id>. A flag --timeout é uma rede de segurança que auto-detém o job, mas «cancelar explicitamente é mais barato». O mecanismo que controla o custo é o comando cancel mais o medidor por segundo — não uma promessa sobre eficiência.

Isto é o Teorema 3 outra vez, aplicado ao custo. A propriedade não pago por inatividade é garantida pelo mecanismo scale-to-zero, e o scale-to-zero está presente nos Inference Endpoints, não no Jobs. No Jobs, a propriedade não pago por inatividade é garantida só pelo mecanismo eu cancelo explicitamente, o que significa que é garantida só se um humano ou um script disparar cancel. Se ninguém cancelar, pagas até ao timeout. A publicação honra isto nomeando os dois produtos lado a lado em vez de fingir que um faz ambos.

O timeout é uma rede de segurança, não um orçamento

Um --timeout 2h não significa «isto custa no máximo duas horas de GPU». Significa «se eu me esquecer de cancelar, a plataforma vai parar o job às duas horas». A diferença importa. Uma rede de segurança apanha-te quando o mecanismo primário (cancelar) falha; não substitui o mecanismo primário. Tratamos o nosso próprio caminho de rollback do mesmo modo: um fluxo de deploy-and-pray precisa de um mecanismo de rollback, e a rede de segurança (um timeout, um health probe) não é o mecanismo — o rollback explícito é.

Jobs versus Inference Endpoints é um emparelhamento de mecanismos

A comparação final da publicação é a parte mais limpa, porque se recusa a classificar os dois produtos e em vez disso emparelha cada um com um trabalho. Recorre ao HF Jobs quando queres «máxima flexibilidade e controlo» — escolhes a imagem, as flags exatas de vllm serve e o hardware, e pagas por segundo enquanto o job corre. Recorre aos Inference Endpoints quando queres «algo mais pronto para produção» — controlo de acesso mais fino (público, protegido ou privado) e scale-to-zero para não seres faturado durante inatividade.

Isto é um emparelhamento de mecanismos, não uma comparação de funcionalidades. A pergunta não é «qual é melhor». A pergunta é «que mecanismo garante a propriedade que eu preciso». Se a propriedade é experimentar, depois desmontar, o Jobs encaixa: a faturação por segundo mais o cancel explícito é o mecanismo, e a flexibilidade sobre as flags de serve é o mecanismo para experimentar um modelo antes de te comprometeres. Se a propriedade é endpoint durável sem gasto por inatividade, os Inference Endpoints encaixam: o scale-to-zero é o mecanismo que garante não-faturar-em-inatividade, e o controlo de acesso mais fino é o mecanismo que garante o alcance que queres sem um gateway personalizado.

[ORIGINAL DATA] A série dos 21 papers chama a isto a correspondência mecanismo-propriedade: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Aplicado aqui, a decisão entre Jobs e Endpoints não é uma questão de gosto — é uma consulta. Lista a propriedade que precisas (custo-zero-em-inatividade, acesso-público, controlo-exato-de-flags, experimento-por-segundo), depois escolhe o produto cujo mecanismo implementa e mede essa propriedade. Se nenhum o fizer, nenhum é a ferramenta certa, e nenhuma configuração o tornará assim.

O mecanismo de sharding tem de coincidir com o flavor

A secção da publicação sobre modelos maiores esconde uma regra de mecanismo que vale a pena extrair. Para servir um Qwen3.5 mixture-of-experts de 122B em 2× H200, fixas --tensor-parallel-size 2, e a regra é enunciada claramente: «--tensor-parallel-size deve coincidir com o número de GPUs do flavor (h200x2 → 2, h200x8 → 8)». Desemparelha os dois e o mecanismo não funciona — o modelo não vai fragmentar-se corretamente pelas GPUs que realmente tens.

A mesma secção nomeia o mecanismo de memória: para a arquitetura híbrida Mamba/attention com um contexto por defeito de 256K tokens, «Limitar o comprimento do contexto e o número de sequências concorrentes mantém-no dentro da memória das GPUs. Se um modelo falhar ao arrancar com um erro de out-of-memory ou cache-block, a primeira coisa a tentar é reduzir estes dois». O mecanismo para caber um modelo em memória é limitar --max-model-len e --max-num-seqs ao orçamento que as GPUs realmente têm. É uma restrição medida, não uma afirmação de vibes sobre capacidade.

O harness é o mecanismo do agente, não o modelo

A secção do agente de codificação Pi da publicação é uma ilustração silenciosa de uma regra que seguramos com firmeza: o harness é o mecanismo, não o modelo. Para suportar um agente de codificação de terminal, reínicias o vLLM com --enable-auto-tool-choice e --tool-call-parser hermes, porque «os agentes conduzem o modelo através de tool calls, e o vLLM só os aceita se o servidor for arrancado com tool calling habilitado». O modelo não ganhou uma capacidade. O harness (parsing de tool calls, o ciclo do agente Pi) foi ligado ao servidor, e essa ligação é o mecanismo que faz as tool calls funcionar. Já o escrevemos noutro lado: não contratas um agente, ligas um mecanismo. O agente é a ligação; o modelo é o motor atrás.

Cross-domain: the space is the router

Cada mecanismo da publicação de HF Jobs tem um paralelo no nosso próprio stack, e nomeá-los é como mantemos a arquitetura honesta em vez de aspiracional.

• O proxy como porta ↔ o room como porta. O proxy de jobs do HF limita o acesso a um namespace. Na Everythink, a topologia network→community→room limita o acesso a um room. «The space is the router» significa que o room roteia uma requisição antes de uma Sister ou o Oracle responderem — o room é a porta, o modelo está atrás da porta. A forma do mecanismo é idêntica; o domínio é diferente.
• O bearer token ↔ o Eye Key. O token de HF com acesso de leitura ao namespace do job é a credencial que te leva através do proxy. O nosso Eye Key (com um espaço) é a credencial que te leva através da nossa porta de API, e o texto plano do Eye Key nunca toca o disco — só o HMAC e a impressão digital persistem. A propriedade soberania-de-credencial é garantida pelo mecanismo HMAC-antes-de-persistir, tal como acesso-limitado-a-mim é garantida por bearer-token-vinculado-a-namespace. Ambas são garantias da camada de roteamento, não do modelo.
• Tensor-parallel ↔ normalização do Oracle. A regra de sharding (o tamanho de paralelismo coincide com o número de GPUs) é um mecanismo de emparelhamento de restrições. O nosso Oracle ✅ normaliza probabilidades em exatamente um lugar — os consumidores confiam em sum(probability) ≈ 1.0, cenários ordenados descendente, entropia em nats. Ambos são «o mecanismo tem de coincidir com a restrição»: tamanho de shard com número de GPUs, normalização com uma localização. Engana-te no emparelhamento e a garantia parte-se.

[PERSONAL EXPERIENCE] O HAI Engine corre em produção desde 2016, e a lição que reaprendemos continuamente é a que a publicação de HF Jobs enuncia sem alarde: a porta é a primeira coisa que provisionas, e o modelo é a segunda que configuras. Um modelo atrás da porta errada é uma porta aberta. Um modelo atrás da porta certa é um produto.

O que isto significa para construir na Everythink

O stack da Everythink é moldado pela mesma regra que a publicação de HF Jobs segue. As Sisters ✅ nunca escrevem para o Postgres — devolvem um SisterOutput e o Loom persiste através de uma porta (LoomStore), tal como o vLLM serve através de um proxy. O Oracle ✅ funde os rascunhos das Sisters num Ensemble normalizado em exatamente um lugar, tal como o proxy é o único lugar onde o acesso é aplicado. O World Monitor ✅ é um gateway que lê de uma cache, nunca dos upstreams, limitado pelo nosso calendário de polling em vez de pelo número de clientes — tal como o proxy de jobs limita o acesso por namespace em vez de por modelo.

Os módulos que ainda não são Production carregam as suas próprias etiquetas de honestidade e mantêm-se etiquetados. Matchmaking ⚠️, Marketplace ⚠️ e Calendar ⚠️ são Partial — o mecanismo existe mas ainda não mede à escala completa. Wallet & Token 🔵, Super App 🔵 e Community Credit 🔵 são Roadmap, pre-revenue, sujeitos a revisão Howey, e não os promovemos em silêncio. É a mesma postura que a publicação de HF Jobs toma quando separa Jobs de Endpoints: nomeia o mecanismo, nomeia o seu alcance, não faças upgrade de um estado.

Âmbito civil e defensivo apenas. Não construímos ferramentas de targeting nem ofensivas. Uma camada de roteamento que limita o acesso é um mecanismo defensivo — decide quem alcança o quê — e essa é a única direção para a qual a apontamos.

Conclusões principais

• O proxy é a porta, não o modelo. O proxy de jobs do HF limita cada requisição ao teu namespace através de um bearer token. O acesso é uma propriedade da camada de roteamento, não do modelo atrás.
• A faturação por segundo é um mecanismo, não um preço. A propriedade sem gasto por inatividade é garantida por scale-to-zero (Inference Endpoints) ou por cancel explícito (Jobs). O timeout é uma rede de segurança, não o mecanismo primário.
• Jobs versus Endpoints é um emparelhamento de mecanismos. Lista a propriedade que precisas, depois escolhe o produto cujo mecanismo a implementa e mede. É uma consulta, não uma questão de gosto.
• O tamanho de shard tem de coincidir com o número de GPUs; os limites de memória têm de coincidir com o orçamento de GPU. Ambos são mecanismos de emparelhamento de restrições. Engana-te e a garantia parte-se.
• O harness é o mecanismo do agente. As tool calls funcionam porque o servidor foi arrancado com parsing de tool calls habilitado, não porque o modelo ficou mais esperto. Ligas um mecanismo; não contratas um agente.
• The space is the router. O room roteia antes de o modelo responder, tal como o proxy roteia antes de o vLLM responder. A porta é provisionada primeiro; o modelo é configurado segundo.

Perguntas frequentes

Qual é o único mecanismo que torna um endpoint de HF Jobs privado? O proxy hospedado de jobs. Cada requisição tem de levar um token de HF com acesso de leitura ao namespace do job, e uma visita simples do navegador é rejeitada. O modelo atrás do proxy não faz nenhum controlo de acesso próprio — o proxy é a porta.

Porque é que a publicação distingue o HF Jobs dos Inference Endpoints em vez de chamar ao Jobs produção? Porque os mecanismos diferem. O Jobs fatura por segundo e para só com cancel explícito ou timeout; os Inference Endpoints acrescentam scale-to-zero e controlo de acesso mais fino. Chamar ao Jobs produção faria upgrade de um estado que o mecanismo não suporta — o mesmo que nos recusamos a fazer com os nossos módulos Roadmap.

Como funciona o tamanho de tensor-parallel e porque importa? --tensor-parallel-size deve igualar o número de GPUs do flavor (h200x2 → 2). É um mecanismo de emparelhamento de restrições: o sharding tem de coincidir com o hardware. Desemparelha-o e o modelo não se fragmentará corretamente pelas GPUs que tens.

O que isto tem a ver com o «the space is the router» da Everythink? O proxy do HF limita o acesso a um namespace antes de o modelo responder. A topologia network→community→room da Everythink limita o acesso a um room antes de uma Sister ou o Oracle responderem. Ambas são garantias da camada de roteamento — a porta é provisionada primeiro, o modelo é configurado segundo.

O HAI Engine da Everythink é o mesmo tipo de mecanismo? A mesma forma, domínio diferente. O HAI Engine corre em produção desde 2016, e a sua regra é a mesma: a porta (o room, a porta, o proxy) roteia antes de o motor responder. As Sisters devolvem saída e o Loom persiste através de uma porta; o Oracle normaliza num lugar. O mecanismo é nomeado, não adjetivado.

Se queres uma plataforma onde a camada de roteamento é provisionada antes de o modelo falar, onde cada capacidade carrega uma etiqueta de honestidade e onde a porta é a primeira coisa que constróis — cria a tua rede.

Sources

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