synsema

Todas las entradas · · 5 min de lectura

Un juez sin proveedor

La probabilidad calibrada que decide qué ve una persona ya no tiene que venir de una API. Un checkpoint System One open source en tu propio disco responde las mismas preguntas tipadas sin clave, sin red y sin costo por token — y el mismo programa corre contra cualquiera de los dos.

system-onelayajudgeopen-sourcecomputación-confidencial

El argumento a favor de un modelo System One es que una probabilidad calibrada es el control que hace falta para automatizar una decisión: arriba del umbral actúa la máquina, abajo mira una persona. Ese caso lo hicimos con Jev, el primer modelo de la clase, y el lado operativo en Poner un modelo System One en producción.

Volvieron dos objeciones, que son la misma objeción dos veces. Esos tickets no los podemos mandar a un tercero. Y: no vamos a poner una decisión que enruta nuestra cola detrás de la API de un solo proveedor.

Desde el motor v0.6.27 la respuesta a las dos es un cambio de configuración. El slot del juez acepta un tercer backend: un checkpoint open source en un disco que controlás, respondiendo las mismas tres preguntas tipadas — si esto es cierto, cuál de estas, dónde en esta escala — sin clave, sin red y sin costo por token. El programa no cambia. Ni una línea.

Qué es el modelo§

Laya, de Convai Innovations, Apache 2.0: un backbone ModernBERT de 421M de parámetros con una cabeza de decisión que puntúa preguntas tipadas sobre un estado en una sola pasada. Es la misma clase de modelo que Jev, publicado con una licencia que te deja poner los pesos adentro de tu propio despliegue, en tu propia región, adentro de tu propio enclave.

En concreto: el checkpoint pesa unos 843 MB, corre en CPU, y el motor ya viene con la capacidad de leerlo — así que cablearlo son dos variables de entorno: qué backend, y dónde está el checkpoint. No se descarga nada automáticamente; los pesos se aprovisionan como cualquier otro artefacto.

Cómo se ve en producción§

El mismo bloque que hacía cuatro preguntas sobre un ticket de soporte a través de la API respondió contra un checkpoint local en una laptop sin GPU: pedido de reembolso en 0,86, el equipo correcto (billing) pero con la masa repartida — 0,36 de confianza — así que la compuerta mandó el ticket a una persona, y un mensaje fuera de tema no coincidió con ninguna opción, correctamente, en 0,86. Cinco preguntas en dos bloques tardaron 7,9 segundos de reloj con la carga del modelo incluida; una sola pregunta en un proceso nuevo tarda 2,5 segundos. Tres corridas dieron números idénticos hasta el cuarto decimal.

Leé esas dos oraciones juntas, porque ahí está el canje en un párrafo. Resignás los 70–500 ms del proveedor y recibís segundos en una CPU. A cambio, el estado nunca sale de la máquina, el costo por token es cero, y no hay un proveedor cuya caída sea tu caída. Para una cola que se tría por lotes, o un agente que decide una vez por documento, unos segundos son invisibles. Para un camino sincrónico delante de alguien que está escribiendo, no — y ahí el modelo alojado sigue siendo la decisión correcta.

La misma perilla que hace que decide lo responda el juez funciona también acá, y eso significa una primitiva de decisión que corre sin ninguna capacidad de red otorgada: el proceso tiene derecho a juzgar y ningún derecho a hacer un request. No hay nada que denegar, porque no hay a quién llamar.

Dos cosas que hacer antes de cambiar§

Medí de nuevo tu umbral. Una compuerta en 0,9 es un número ajustado contra un modelo concreto. Jev y Laya son modelos distintos — la forma de la respuesta es idéntica, la calibración no necesariamente. Pasá una semana de tráfico por los dos, compará cada respuesta con lo que terminó haciendo la persona, y fijá el número desde ahí. Es la misma disciplina que aplicarías a cualquier modelo de scoring que cambiaras, y es la única forma honesta de moverlo.

Conocé la ventana. El checkpoint local lee 512 tokens: la pregunta, las opciones y después todo el estado que entre. Un hilo largo pierde la cola, en silencio, porque un estado truncado igual produce una respuesta perfectamente verosímil. Juzgá los campos que importan — el último mensaje del cliente, el asunto, el monto — en vez del objeto entero. Contra la API también es mejor práctica; acá es obligatorio.

De lo que no te tenés que preocupar es de un número inventado. Cuando el juez no está disponible, se pasó del presupuesto o no está cableado, cada respuesta vuelve marcada como no disponible, con confianza 0 y sin valor — así que la compuerta que ya escribiste manda la cola a las personas sola. Una oración inventada se ve en tu salida; una probabilidad inventada no, y se multiplica hasta convertirse en plata.

Por qué esto hace que valga la pena construir sobre el slot§

Un backend de juez es un protocolo, no un producto. Eso fue una decisión de diseño del lenguaje cuando todavía no había otro lugar donde apuntarlo, y hoy es una propiedad de portabilidad que se puede verificar: el mismo programa, el mismo bloque, la misma compuerta, corriendo contra una API alojada en un despliegue y contra un archivo en disco en el siguiente. Al cliente que no te puede mandar sus datos y al que quiere la menor latencia los sirve el mismo camino de código.

También responde la pregunta de compras que no tiene buena respuesta cuando hay un solo proveedor. ¿Qué le pasa a esta función si esa empresa cambia sus precios, sus términos o de opinión? Movés una variable. Las decisiones se siguen tomando, en tu propio datacenter, con pesos cuya licencia ya tenés.

La guía para quien programa, verbo por verbo y con los números, es Correr el juez local con Laya. La mitad generativa del mismo release — un modelo en tu proceso, sin egress — es Inferencia que no sale de tu máquina.