A table, not an AI, decides which machine runs each job

Hasta ahora cada trabajo del enjambre llevaba --node mac escrito a mano. Funcionaba, pero tenía que recordar qué sabe hacer cada máquina y si estaba despierta. Medí que la Mac mini gana en casi todo lo que corre sin pantalla: bash de 14 a 27 veces, git de 2 a 10, Blender con Metal 3 veces. Lo lógico era que eso se decidiera solo.

La tentación era pedirle a un modelo que eligiera. No lo hice. Elegir nodo es una decisión repetible: con las mismas entradas tiene que dar lo mismo, y tengo que poder leer por qué. Además, un modelo gasta cuota en cada trabajo y no sabe si la Mac está apagada. Quedó una tabla (routing.toml) que dice qué necesita cada tipo de trabajo y a quién prefiere. Al lado, las capacidades de cada máquina como etiquetas: metal, mlx, display, keychain.

El algoritmo tiene cuatro pasos, en orden:

1. Filtros duros: capacidades, la regla de datos sensibles y que el nodo esté despierto.
2. Estado vivo: huecos libres y presión de memoria.
3. Historia medida.
4. Si nada desempata, el primero de la lista de preferencia.

Cada decisión imprime una línea:

enjambre route [rule] queue: tests: mac is down; queued until it is ready (win: fits, but has no executor yet)

Dos cosas me enseñaron más que el código.

Una celda medida no es una comparación. En el registro hay 17 renders buenos en la Mac, con una mediana de 7,9 s, y cero en Windows. Habría sido fácil escribir “la historia dice Mac”. Pero la Mac no ganó a nadie: es la única que corrió. El router solo deja decidir a la historia cuando dos máquinas tienen al menos 5 corridas del mismo tipo. Hoy eso no pasa en ninguna celda, así que todas las decisiones salen por regla, y la línea lo dice.

Lo honesto a veces es “no”. Windows tiene pantalla y 48 GB, pero todavía no sabe ejecutar trabajos: el worker necesita tmux. El router lo sabe. Con la Mac caída, un trabajo de tests no se va a Windows a fallar: se encola y explica por qué. Uno de edición de video se rechaza con el motivo exacto.

También encontré un punto ciego. Mientras escribía esto, la Mac corría un banco de modelos dentro de tmux. El gestor de modelos decía “nada corriendo” y la memoria tenía 48 % libre, así que el router habría mandado un render a la GPU en plena carga. La memoria no ve la GPU. Queda anotado como límite, no escondido.

Los números y los comandos están en el paso 22 del tutorial, y el porqué del diseño en enrutamiento.