Ilustración de una puerta de cristal que reparte flujos de luz desde portátiles y agentes hacia dos superordenadores y un servidor

Plataforma · 2026

Una «OpenAI» privada para un equipo externo

Un equipo externo usa los modelos del laboratorio con su propia clave, como si fuera la API de OpenAI, con límites, trazabilidad y sin pagar por token.

tokens consumidos por un solo usuario
≈2.240 M
tokens en media hora en un pico
14,7 M
roles de modelo estables
8
por token
0 €

El planteamiento

Varios amigos y colaboradores querían usar modelos potentes con sus propios agentes, pero sin depender de una API de pago ni enviar sus datos fuera. La solución fue abrirles el laboratorio de forma controlada.

Cómo funciona

  • Un endpoint compatible con OpenAI, publicado con TLS. Cualquier herramienta que hable con OpenAI funciona cambiando solo la URL y la clave.
  • Ocho roles estables (spark, coder, embeds, tts…). Cuando cambio el modelo de detrás, nadie tiene que tocar su configuración.
  • Cuentas, equipos y presupuestos, con la lista de modelos permitidos para cada equipo.
  • Panel de consumo por persona y modelo, cuadrado con los registros del gateway.
  • Encadenado para un cliente con su propio servidor: su gateway usa el mío como un proveedor más, con una clave limitada.

Las cifras

Uno de los usuarios, con su propio agente Hermes, consumió unos 2.240 millones de tokens, con picos de 14,7 millones en media hora y prompts de hasta 180.000 tokens. Con una API comercial habría sido una factura importante; aquí el coste es la luz.

Lo que aprendí

  • Los timeouts se diseñan. Un prompt de 200.000 tokens tarda en procesarse, y cortar a los 30 segundos solo provoca reintentos.
  • Las IPs reales se ven en el borde, no en el gateway. Hay que mirarlas donde toca.
  • Nada de fallbacks escondidos. Si el local falla, el usuario lo sabe.