SUPERADO POR 2026-09-27-plan-hf-unificado.md. Se conserva como detalle/evidencia.

HF PRO evaluado: la capa RAG ya está operativa en ZeroGPU (2026-09-27)

Pregunta: ¿qué nos da Hugging Face hoy, que estamos pagando PRO ($9/mes)?

Respuesta corta: la capa de cómputo del RAG/harnessing ya funciona y es gratis marginalmente. No sustituye a Cloudflare en producción; es el laboratorio + el demo por cliente.

Estado verificado (no de memoria)

  • Cuenta [usuario]: PRO activo, isPro: true. Renueva 2026-10-01 (en 4 días).
  • Token OAuth del MCP ahora incluye jobs e inference-api (antes no).
  • Space [usuario]/sonrisa-inference: RUNNING con hardware zero-a10g (ZeroGPU). El bloqueador de ayer (“quedó en cpu-basic”) está resuelto.
  • Endpoints probados en vivo (POST /gradio_api/call/{embed|rerank|chat}):
endpointmodelopruebaresultado
embedQwen3-Embedding-4B2 textos✅ vectores reales
rerankQwen3-Reranker-0.6B1 query, 3 docs✅ acierta: 8.5 vs −12.4 / −9.6
chatQwen3-14B”cuánto cuesta la limpieza”✅ “850 pesos” (ver trampa abajo)

Nota de API: en Gradio 6 la ruta es /gradio_api/call/<api_name> (el viejo /call/<api_name> da 405). El POST devuelve event_id y el resultado se lee por SSE con GET /gradio_api/call/<api_name>/<event_id>.

Qué da PRO (fuente: docs HF + /pricing)

  • 8× cuota ZeroGPU + máxima prioridad → ~40 min GPU/día (RTX Pro 6000 Blackwell), hasta 10 Spaces ZeroGPU, Gradio y Docker Spaces, Dev Mode.
  • $2/mes de créditos de cómputo generales (Inference Providers, Endpoints, HW de Spaces, Jobs). No es un presupuesto de producción; es un colchón.
  • 1 TB privado + 10 TB público de storage.
  • Dataset Viewer en datasets privados + Data Studio. Blog personal.

Qué desbloquea (los 3 bloqueadores que mataron el plan anterior)

  1. ZeroGPU en CPU → resuelto: ya está en zero-a10g.
  2. Groq TPD (200k tokens/día) bloqueaba la eval RAGAS completa (~1.2M de tokens de juez) → resuelto: el juez es Qwen3-14B en ZeroGPU, sin TPD.
  3. HF Inference 402 / créditos agotados → resuelto: ZeroGPU + $2/mes cubren el indexado y la evaluación de un corpus pequeño.

Trampa encontrada (misma clase de bug que gemma)

Qwen3-14B razona por defecto. Con max_tokens=256 el <think> se comió el presupuesto y la respuesta quedó cortada (“…850 pe”). Igual que gemma-4 en el Worker.

Arreglo probado: /no_think en el mensaje del usuario → </think> vacío y respuesta correcta (“850 pesos”). Arreglo robusto: apply_chat_template(..., enable_thinking=False) en el app.py del Space. Regla general: todo modelo “thinking” hay que apagarlo o el tope de tokens se agota en razonamiento y la respuesta sale vacía o cortada.

División de trabajo

capadóndepor qué
Producción (chat del paciente)Cloudflare Worker + Workers AI, gemma-4$0, ya desplegado, 20/20 verificado. gemma se queda.
Laboratorio / evaluaciónSpace HF ZeroGPU (embed+rerank+chat)gratis, sin TPD, modelos abiertos, control total del juez
Demo por clienteun Space Gradio por clienteartefacto demostrable y compartible (hasta 10)
Storagerepos/buckets privados HF (1 TB)corpus + resultados de eval

Límites honestos: 40 min/día de GPU no es servicio 24/7; hay cold start y cola. Para servir a un paciente, Cloudflare; para medir y demostrar, HF.

Siguiente paso mínimo

En proyecto_1_dentistas, cambiar el backend de Groq/Ollama al Space: embed + rerank del corpus real, y correr el golden set 20/20 con Qwen3-14B de juez (con thinking apagado). Eso cierra la evaluación completa que no cabía en Groq.

Ventana: la suscripción renueva el 2026-10-01. Si el valor se va a medir, medirlo ahora.