La pila del laboratorio: qué corre dónde y por qué
El mapa completo del laboratorio: cartuchos de modelos, gateway con routing fail-closed, residentes independientes por nodo y el sistema de rotación con rollback. Nuestra arquitectura real.
La pregunta recurrente: “tenéis dos sparks, ¿y qué corréis exactamente?”. Este es el mapa completo, con las decisiones de arquitectura que más nos han enseñado.
El concepto: modelos como cartuchos
Cada modelo es un “cartucho” con su receta versionada: pesos fijados a un commit concreto,
flags exactos, tests de validación y rollback documentado. Un script (gpu-switch.sh) hace
la rotación transaccional: para el residente, espera a que la memoria unificada quede libre,
lanza el worker primero (por SSH al segundo nodo) y luego el head.
¿Por qué worker primero? Porque el head es el que coordina: si el worker no está listo, el head muere esperando. Worker primero = arranque limpio siempre.
El gateway: un solo punto de entrada, routing fail-closed
Todos los clientes (nuestro editor agéntico, el arnés web, el móvil) hablan con un único gateway local. El gateway sabe qué modelo está activo y enruta.
Las reglas de seguridad del routing —aprendidas a golpe de fallo—:
- Fail-closed: si no hay modelo activo, o hay varios, o está en carga, o no está aprobado → no enruta. Nunca adivina.
- La máquina manda: el estado real se lee del sistema de cartuchos, no de lo que diga la config.
- No toca los runtimes: el gateway nunca arranca ni para modelos. Solo observa y enruta.
- No trunca prompts: el contexto se corrige en los clientes, no en el gateway.
Residentes independientes: un cerebro por nodo
Modo alternativo al cluster: cada nodo sirve un modelo propio e independiente. Uno hace de “arquitecto” (chat largo, razonamiento) y otro de “programador” (código, herramientas). El gateway enruta por alias de nodo sin cambiar el residente del otro.
Los nombres se asignan por nodo y papel, nunca por modelo — así cambiar de modelo no rompe ninguna configuración de cliente.
La pila fijada: por qué clavamos los commits
La receta comunitaria que usamos referenciaba el modelo “por nombre, sin revisión”. Hoy no pasa nada porque la caché local tiene la buena… hasta que alguien borra la caché y baja “la última”, que puede ser distinta.
Por eso toda la pila está fijada a revisiones concretas: pesos, drafter, imagen base e imagen derivada, todo con su hash. La comparación con las cifras publicadas por la comunidad (coinciden en ±1%) confirma que corremos la misma pila.
El patrón que este laboratorio lleva corrigiendo desde el día uno: no falla, miente. Un benchmark que mide otra cosa de la que crees es peor que ningún benchmark.
Mission Control: el panel de la nave
Todo esto se gobierna desde un panel web propio (corriendo en el nodo head): estado de los cartuchos, rotaciones con un clic, benchmarks en vivo, histórico de experimentos, y un “banco visual” para lanzar evaluaciones contra el modelo activo con progreso en streaming.
El principio del panel es el mismo que el del gateway: mostrar la realidad de la máquina, no la deseada. Si el modelo no está cargado, no aparece como cargado. Si la temperatura va alta, se ve.
Lo que hemos descartado (y por qué)
- Modelo grande en un nodo: cabe y ya va rápido → repartir es ir más lento
- Modelo que necesita 3+ nodos: no los tenemos; ni envidia
- Dos modelos grandes residentes a la vez: la memoria unificada es finita; el swap es el infierno
- Routing adivinando: fail-closed siempre. Un error “lo siento, modelo no disponible” es infinitamente mejor que una respuesta del modelo equivocado.
El inventario actual
| Cartucho | Estado | Destacable |
|---|---|---|
| GLM-5.3 Flash EXL3 | beta operativa | 1M contexto, tool-eval 90/100 |
| DeepSeek V4 Flash (cluster) | probado, rollback listo | 43,9 tok/s · 1M · TTFT 131ms |
| Qwen3.8 Flash Next | probado, rotación verificada | 56 tok/s estructurado · 262k |
| Nemotron 3.5 Lightning | medido, el más rápido ×1 | 139 tok/s con DSpark |
| Qwen3.6 35B | descartado para cluster | cabe en uno a 120 tok/s |
| Muse Glimmer 30B | lección aprendida | denso: techo físico ~8.8 tok/s |
| Ling 3.0 Flash | medido | replicamos cifras externas ±5% |
Los números completos de cada uno, en los posts del banco de pruebas. En el próximo: la regla del reparto — la aritmética que decide cuándo usar un nodo y cuándo los dos. 🧮