Inicio / Artículos / Phlox-GW: Portal de LLM de código abierto con presupuestos, límites y alta disponibilidad

llm-gateway phlox openai anthropic observability self-hosted

Phlox-GW: Portal de LLM de código abierto con presupuestos, límites y alta disponibilidad

Hospeda tú mismo una pasarela de LLM con contracargos, límites de tasa, medidas de protección de datos personales, registros de auditoría, puntos de conexión para OpenAI y Anthropic, y clústeres respaldados por Postgres.

2581 palabras

Los gateways de LLM de código abierto suelen incluir controles “ empresariales” —estornos, presupuestos, SSO, medidas de seguridad, registros de auditoría, clústeres de alta disponibilidad, límites de velocidad, enrutamiento— detrás de una licencia de pago. Phlox-GW (Phlox Gateway) mantiene esos controles en un gateway completamente de código abierto destinado a infraestructuras de equipos autohospedados: una única puerta de entrada consistente entre diferentes proveedores, con puntos finales de OpenAI y Anthropic además de traducción de protocolos para que clientes como Claude Code puedan comunicarse con modelos provenientes de diferentes backends.

Phlox-GW es un único binario en Go para macOS, Linux (incluido WSL) y Windows. Las implementaciones pequeñas pueden ejecutar una instancia con SQLite; las más grandes se escalan a clústeres de múltiples nodos utilizando PostgreSQL compartido. Un proyecto relacionado, la Phlox AI Platform, puede funcionar junto al gateway cuando se necesita una interfaz de chat completa; esta guía se centra en el propio gateway.

Recorrido por la interfaz de Phlox-GW

Panel de operaciones

Los administradores ven cifras a alto nivel: usuarios, proveedores, claves API, eventos y gasto total, además de gráficos de treinta días para el costo diario, tokens, solicitudes, errores y latencia promedio.

Monitoreo de costos y presupuestos

Los presupuestos mensuales se asignan a personas y departamentos. Los usuarios tienen una etiqueta de departamento para que el gasto se acumule. Al superarse un umbral de advertencia se emite una notificación; al alcanzarse el límite máximo, los modelos de pago quedan bloqueados hasta el próximo ciclo o hasta que se aumente el límite. Ese ciclo de devoluciones de cargo es una de las principales razones por las que los equipos optan por un gateway en lugar de claves directas del proveedor.

Límites de tasa

Los límites se aplican a nivel de usuario, departamento, proveedor o modelo, en términos de solicitudes por minuto (RPM) y/o tokens por minuto (TPM).

Disponibilidad alta y escalado mediante clústeres

Un solo proceso Go en PostgreSQL ya es suficiente para muchas necesidades. Para garantizar disponibilidad o manejar miles de sesiones concurrentes, agregue instancias que compartan un mismo Postgres y coloque un equilibrador de carga de red delante con comprobaciones de estado que eliminen los nodos problemáticos.

Auditoría

Los registros de auditoría capturan los inicios de sesión y las acciones de configuración: hora, autor, acción, destino, detalles e IP.

Registro de solicitudes que preserva la privacidad

Cada llamada a la pasarela registra metadatos: hora, ID de solicitud, usuario, departamento, clave API, proveedor, modelo, protocolo y punto final—sin almacenar el contenido de la solicitud ni su respuesta, de modo que el contenido permanece privado mientras los equipos operativos siguen teniendo un historial de incidentes.

Límites / Redacción y bloqueo de PII

El middleware puede redactar o bloquear mensajes cuando se detectan patrones sensibles, ya sea al recibirlos (evitando fugas de información a los proveedores) o al enviarlos (impidiendo fugas hacia los clientes), según la configuración establecida.

Claves API de autoservicio

Los usuarios conectados pueden crear claves con nombre y fecha de vencimiento opcional, revocarlas y ver cuándo se usaron por última vez. Los administradores cuentan con una vista general para asignar presupuestos/límites y revocar claves. Los datos completos de la clave se muestran una sola vez al crearla.

Monitoreo del uso de autoservicio

Cada usuario puede ver su cantidad de solicitudes, tokens de entrada/salida, gastos y desglose de costos por modelo sin tener que esperar a una exportación financiera.

Instalación de Phlox-GW

Para la evaluación en estaciones de trabajo, el binario es autónomo y crea una base de datos SQLite al iniciarse por primera vez. Para compilar desde el código fuente se necesita una herramienta Go actual y npm para los recursos de la interfaz. Un ejemplo típico de inicio:

curl \
  --proto '=https' \
  --tlsv1.2 \
  -fsSL \
  https://raw.githubusercontent.com/robert-mcdermott/phlox-gw/main/install.sh \
  | sh

Cree un directorio de datos e inicie el servicio:

  mkdir -p "/Users/<your-username>/.local/share/phlox-gw"
  cd "/Users/<your-username>/.local/share/phlox-gw"
  phlox-gw

Dirija un navegador a la interfaz de usuario local, cree al primer administrador y continúe con la configuración allí. Las instalaciones en producción suelen establecer variables de entorno para el DSN de Postgres, la dirección de escucha, la terminación TLS en el balanceador de carga y los secretos de sesión; consulte la documentación del repositorio para obtener la lista completa de variables.

Configuración de Phlox-GW

No existe un archivo de configuración obligatorio: las variables de entorno junto con la interfaz web son suficientes para el setup.

Agregar/configurar un proveedor

Registre cada servicio upstream (compatible con OpenAI, Anthropic u otros soportados) con su URL base y credenciales almacenadas por la pasarela, no en cada ordenador portátil.

Agregar y configurar un modelo

Asocie los IDs de modelos del proveedor con nombres utilizados por la pasarela, indique los precios para los reembolsos y elija los pares de enrutamiento/fallo automático cuando varios servidores backend puedan ofrecer el mismo modelo lógico.

Prueba de un proveedor y modelo en el entorno de pruebas

El entorno de pruebas integrado envía un chat de prueba a través de la ruta del proveedor/modelo seleccionado, de modo que los problemas de conexión se detecten antes de dirigir a los clientes hacia la pasarela.

Agregar usuarios

Cree cuentas (o conéctese mediante SSO/OIDC si está habilitado), asigne roles y departamentos, y establezca presupuestos/límites.

Crear presupuestos

Defina límites mensuales y umbrales de advertencia para personas y departamentos; los modelos con precios respetan dichos límites al momento de la solicitud.

Uso de Phlox-GW

Crear una clave API

Desde el panel de autoservicio, genere una clave, cópiela una vez y guárdela en el almacén de secretos del cliente.

Probar los puntos finales de la pasarela

Exporte la clave:

export PHLOX_API_KEY="pgw-sk-<rest-of-your-api-key>"

Completación de chats compatible con OpenAI contra la pasarela local:

curl -Ns http://127.0.0.1:8080/v1/chat/completions \
  -H "Authorization: Bearer $PHLOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "stream": false
  }'

Mensajes al estilo de Anthropic a través del punto final traducido:

curl -sS http://127.0.0.1:8080/anthropic/v1/messages \
  -H "x-api-key: $PHLOX_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "local-ollama/glm-5.2:cloud",
    "max_tokens": 64,
    "messages": [{ "role": "user", "content": "What is the capital of Texas?" }]
  }'|jq

Uso de Claude Code con Phlox-GW

Dirija Claude Code (o similar) hacia la URL base compatible con Anthropic y la clave del gateway:

env \
  ANTHROPIC_BASE_URL="http://127.0.0.1:8080/anthropic" \
  ANTHROPIC_API_KEY="$PHLOX_API_KEY" \
  ANTHROPIC_MODEL="azure/gpt-5.5" \
  claude

La traducción de protocolos permite que los clientes diseñados para Anthropic accedan a cualquier destino al que dirija el gateway.

Verificación del uso

Los usuarios actualizan los paneles de uso relacionados con tokens y gastos; los picos deberían corresponder a trabajos por lotes conocidos o agentes que funcionan de forma incontrolada.

Monitoreo del uso y los gastos como administrador

Los administradores observan los paneles de control del conjunto de dispositivos, los resúmenes por departamento y los gráficos de errores y latencia. Las infracciones presupuestarias y las violaciones de los límites de uso son eventos operativos importantes, no sorpresas que surgen al revisar hojas de cálculo.

Límites y protección de información sensible

Habilite los patrones que coincidan con secretos, identificadores personales o nombres de hosts internos. Elija entre redactar o bloquear según la familia de patrones. Pruebe con muestras sintéticas en el entorno de pruebas antes de aplicarlo al tráfico real.

Registro y auditoría

Registro de solicitudes

Los registros de solicitudes que contienen únicamente metadatos permiten responder a incidentes y resolver disputas por reembolsos sin conservar el texto privado de las solicitudes.

Registro de auditoría

Los eventos de configuración y autenticación responden a la pregunta “¿quién cambió la ruta ayer?”, sin necesidad de examinar los registros de la aplicación.

Conclusión

Los paquetes Phlox-GW integran reembolsos, presupuestos, límites de velocidad, medidas de seguridad, rastreos de auditoría y clústerización en un único binario abierto con interfaces para OpenAI y Anthropic. Comience utilizando SQLite para evaluaciones, pase a Postgres y un NLB cuando sea importante la disponibilidad, y guarde las credenciales del proveedor y las políticas en un solo lugar en lugar de dispersarlas en archivos del entorno del ordenador portátil.

Lista de verificación operativa para el primer corte de producción: (1) fijar un precio a cada modelo procesado para que los presupuestos tengan sentido, (2) asignar usuarios a departamentos antes del primer ciclo de facturación, (3) activar los registros de solicitudes de metadatos y realizar auditorías desde el primer día, (4) probar muestras sintéticas de PII con las medidas de seguridad del entorno de pruebas, (5) utilizar un par de nodos con Postgres y equilibrio de carga verificado antes de prometer alta disponibilidad, y (6) documentar cómo los clientes de Claude Code / SDK deben configurar la URL base y la clave para que el uso no autorizado de tecnologías no evite el gateway con credenciales brutas del proveedor. Revisar los límites de RPM/TPM después de una semana de tráfico real del agente: los límites iniciales suelen ser demasiado generosos para ciclos intensivos de herramientas y demasiado estrictos para chats interactivos. Mantener un manual de procedimientos para rotar las claves del gateway y los secretos del proveedor en fechas diferentes, de modo que una sola fuga no cause dos interrupciones al mismo tiempo. Finalmente, exportar los gastos por departamento a intervalos fijos, incluso si

Todavía nadie lo ha solicitado; finanzas lo pedirá después de la primera factura inesperada, y la pasarela ya cuenta con las cifras si los etiquetados se configuraron correctamente.

Al expandirse más allá de un único equipo, trate la pasarela como una superficie de producto: defina políticas de enrutamiento por versión, revise los pares de respaldo cuando un proveedor sufre un incidente regional, y genere alertas sobre el aumento de errores 429 provenientes del origen, por separado de los límites impuestos por la pasarela. El throttling en el origen y los límites de las políticas locales requieren respuestas diferentes: adquirir capacidad o capacitar a un agente problemático. Combine las métricas de Phlox-GW con las páginas de estado del proveedor en la misma vista de atención para que los operadores no intenten solucionar una “latencia de la pasarela” que en realidad sea un corte de servicio en una región específica. Con esas prácticas, la pasarela seguirá siendo un plano de control en lugar de otro proxy opaco.

Los SLO del gateway de documentos se definen de la misma manera que cualquier otro servicio periférico: disponibilidad de las interfaces /v1 y /anthropic, latencia p95 excluyendo el tiempo del modelo ascendente cuando sea posible, y tasas por departamento según el presupuesto asignado. Esos tres gráficos permiten detectar la mayoría de los informes sobre problemas antes de que se conviertan en hilos de conversación en Slack.

Los SLOs de la pasarela de documentos se definen de la misma manera que cualquier otro servicio periférico: disponibilidad de las interfaces /v1 y /anthropic, latencia p95 excluyendo, cuando sea posible, el tiempo del modelo en la cadena de procesamiento, y tasas por departamento según el presupuesto asignado. Estos tres indicadores permiten detectar la mayoría de los informes sobre problemas antes de que se conviertan en hilos de conversación en Slack.

Todos los artículos Enviar el brief