inference-obs

El problema

Cuando varios proyectos propios empiezan a llamar a modelos, aparecen tres problemas a la vez: no sabés cuánto gasta cada uno, no sabés por qué una respuesta salió mal, y cada proyecto acaba con su propia clave y su propio desorden.

inference-obs resuelve eso con un único punto de entrada: un proxy compatible con OpenAI que aplica presupuesto por proyecto, y un servidor de trazas que guarda cada llamada con su atribución.

Dos aplicaciones, una operación

El núcleo es LiteLLM con PostgreSQL en un contenedor bajo supervisord, y sirve chat y transcripción. La observabilidad es Arize Phoenix, que recibe trazas por el protocolo abierto y además aloja los conjuntos de datos y los experimentos de evaluación.

Vive en un entorno con 4 GiB de memoria, así que la envolvente no es un detalle de optimización: es un requisito. El plan de despliegue asigna el núcleo y la observabilidad dentro de ese presupuesto, con un límite explícito de memoria para el contenedor principal, y la comprobación está escrita.

Lo que más me importa de este proyecto

Que la observabilidad pueda caerse sin llevarse la inferencia. Es la decisión de arquitectura central: el núcleo envía las trazas por HTTPS público, así que si Phoenix no responde, se pierde la traza y la llamada sigue. Está verificado con un test que levanta los dos servicios, apaga el de trazas y comprueba que la inferencia sigue devolviendo 200.

Lo contrario —que perder trazas tumbe el servicio— es un error de prioridades que se comete por defecto cuando la observabilidad se trata como parte del camino crítico.

Y que la evaluación diga la verdad sobre sí misma. El comparador de modelos informa por separado de los fallos de la tarea, los del juez automático y los juicios que no se pudieron emitir. Un promedio único habría ocultado justo lo que hacía falta saber.