Plataforma de modelos especializados
Tus aplicaciones llaman a /v1/ocr,
/v1/embeddings,
/v1/transcribe o
/v1/tts. Nunca saben qué modelo hay detrás.
Cambiar el modelo por otro mejor es reasignar un alias en el panel. Ninguna aplicación se entera, y ninguna se despliega otra vez.
# La app pide la capacidad, no el modelo
Authorization: Bearer ah_a1b2c3...
{ "texts": ["hola mundo"], "task": "passage" }
# El Hub responde con el esquema del Hub
{
"model": "default",
"dimensions": 384,
"vectors": [[0.021, -0.118, ...]]
}Detrás está multilingual-e5-small. Mañana puede estar otro, y la respuesta seguirá teniendo esta forma.
Qué sabe hacer
Cada capacidad es un contenedor propio, porque las dependencias de aprendizaje automático se llevan mal entre ellas. Cada una decide en su contrato si responde al momento o encola el trabajo.
POST /v1/ocr
Saca el texto de una imagen o de un PDF. Devuelve bloques, líneas y palabras con su confianza y su recuadro, venga del motor que venga.
POST /v1/embeddings
Convierte texto en vectores para buscar por significado. El modelo por defecto es multilingüe, así que sirve para español, catalán e inglés sin cambiar nada.
POST /v1/transcribe
Pasa un audio a texto. En un servidor sin tarjeta gráfica una transcripción tarda minutos, así que siempre va a la cola y devuelve un identificador de trabajo.
POST /v1/tts
Convierte texto en audio. La voz rápida responde al momento; la que clona una voz a partir de una muestra es lenta sin tarjeta gráfica y conviene mandarla a la cola.
Añadir la quinta capacidad es una carpeta con un adaptador, un manifiesto y un contrato. Si algún día hiciera falta tocar el gateway, el controller o el panel para conseguirlo, la arquitectura se habría estropeado.
Lo único estable
Cada capacidad puede tener varios modelos instalados a la vez, y cada modelo tiene alias. Solo default tiene garantía de estabilidad. Promocionar un experimento es reasignarlo en el panel, sin tocar ni desplegar ninguna aplicación.
| Alias | Capacidad | Modelo | Motor | RAM |
|---|---|---|---|---|
| e5-small default | Embeddings | multilingual-e5-small | sentence-transformers | 700 MB |
| minilm-l6 | Embeddings | all-MiniLM-L6-v2 | sentence-transformers | 350 MB |
| ppocr-v4 default | OCR | PP-OCRv4 | RapidOCR · onnxruntime | 900 MB |
| whisper-small default | Voz a texto | faster-whisper-small | ctranslate2 · int8 | 1.200 MB |
| whisper-base | Voz a texto | faster-whisper-base | ctranslate2 · int8 | 600 MB |
| piper-es default | Texto a voz | es_ES-davefx-medium | piper · onnxruntime | 300 MB |
| xtts-v2 no comercial | Texto a voz | XTTS-v2 | coqui-tts · torch | 3.200 MB |
Puedes instalar un modelo que todavía no usa nadie y probarlo con tranquilidad. El panel trae un banco de pruebas por capacidad: lanzas la misma petición contra varios modelos y comparas la salida, el tiempo y la memoria uno al lado del otro.
Cada petición queda registrada indicando si vino de una aplicación o del banco de pruebas. Así las estadísticas de uso siguen contando lo que hacen tus aplicaciones de verdad.
La restricción que manda
La memoria es el recurso escaso, y el diseño entero está montado alrededor de ese hecho en lugar de ignorarlo hasta que revienta.
Una capacidad que nadie usa no ocupa memoria. El controller arranca y para los contenedores según hagan falta.
Tras un tiempo sin peticiones, el modelo sale de memoria. El tiempo se configura por modelo desde el panel.
Antes de cargar un modelo se compara la memoria que declara su manifiesto con la que hay libre. Si no cabe, responde que vuelvas más tarde o encola el trabajo. No revienta el servidor.
La cola serializa los trabajos largos, con uno o dos a la vez por servicio, para no tumbar el resto de aplicaciones del servidor.
Cómo está montado
El controller necesita hablar con Docker para arrancar y parar contenedores. Por eso jamás está expuesto a internet, y por eso el plano público es otra pieza distinta.
Público
Gateway
Claves, límite de peticiones, validación del contrato, enrutado y registro
Panel
Aplicación web de administración, servida como ficheros estáticos
Red interna, sin salida
Controller
Registro de capacidades y modelos, ciclo de vida de contenedores, métricas
svc-ocr
Un contenedor por capacidad
svc-embeddings
Un contenedor por capacidad
svc-speech
Un contenedor por capacidad
svc-tts
Un contenedor por capacidad
Estado
PostgreSQL
Registro, claves, historial de peticiones, cola de trabajos y configuración. La única pieza con estado
Volumen de modelos
Los pesos descargados, compartidos entre el controller y los servicios
No hay Redis ni RabbitMQ. Los trabajos se reparten con un bloqueo de PostgreSQL que salta las filas ya cogidas, y aguanta este volumen durante años. Menos piezas que mantener encendidas.
La forma de cada respuesta está escrita y versionada aparte, y el adaptador traduce la salida del modelo a esa forma. Es exactamente lo que permite cambiar de modelo sin romper apps.
Desde un asistente
Hay un servidor MCP que expone las capacidades del Hub como herramientas. Un asistente de IA puede leer un PDF, transcribir un audio o generar voz sin que le escribas ninguna integración.
aihub_ocr # saca el texto de una imagen o un PDF
aihub_speech # transcribe un audio
aihub_tts # convierte texto en audio
aihub_embeddings # vectores para buscar por significado
aihub_job # consulta un trabajo de la colaLas operaciones que van a la cola mantienen la respuesta abierta hasta que terminan, así que el asistente recibe el resultado y no un identificador que luego tendría que ir a buscar.
Quién puede entrar
Ficha técnica
Cambiar de modelo debería ser
una decisión, no una migración.
AI Hub