Caso de estudio
HALO Control
Un plano de control para cargas de IA local.
Un plano de control local para una estación AMD Halo con inventario de modelos, enrutamiento por capacidad, autorización de cargas, telemetría e historial de actividad.
Edición pública de arquitectura. El hardware objetivo y la inferencia real aún no están verificados.
Arquitectura independiente del sistema, diseño del plano de control y documentación pública.
Resumen del caso
El brief estratégico
El problema, la respuesta del sistema, la prueba disponible, el valor estratégico y el límite intencional.
- 01Problema
- Varias cargas de IA comparten una máquina, pero endpoints y registros separados dificultan revisar acceso, presión de recursos y actividad en conjunto.
- 02Sistema
- Plano de control headless con registro de modelos, rutas declaradas por capacidad, autorización de cargas, telemetría e historial de metadatos.
- 03Prueba
- Documentación pública de arquitectura, contratos y router TypeScript ilustrativos, fixtures sintéticos y recreación de Control Room.
- 04Valor
- Da a las cargas un punto explícito para solicitar una capacidad y al operador un lugar para revisar la decisión y el estado registrado.
- 05Límite
- El repositorio público omite la implementación privada. La inferencia real a través de HALO y su ejecución en hardware AMD Halo siguen sin verificarse.
01
El hardware compartido necesita reglas comunes
IRIS OS, un agente de programación y flujos de medios pueden solicitar inferencia local en la misma estación. Si cada carga gestiona su endpoint y sus registros, el operador no ve quién puede usar un modelo, qué ruta se eligió o de dónde viene la presión de recursos.
02
Enrutar por capacidad y registrar la decisión
HALO sitúa un registro de modelos y un router determinista entre las cargas y un runtime local compatible con OpenAI. La carga se identifica, pasa una autorización y solicita una capacidad como programación o visión. Una solicitud sin ruta devuelve un error explícito. Registrar un modelo no demuestra que esté disponible.
03
Mostrar al operador lo que se sabe
Control Room reúne modelos, reglas de rutas, cargas registradas y actividad reciente en una vista de solo lectura. Cada señal de telemetría indica su clase de evidencia: simulada, local, propia del hardware o no disponible. La captura pública usa fixtures sintéticos y lo declara.
04
Implementado en local, publicado de forma selectiva
El repositorio documenta un plano de control headless, rutas deterministas, autorización, historial SQLite, Control Room de solo lectura y un plano de cómputo limitado a servicios registrados. Publica arquitectura, contratos ilustrativos, una pequeña demo de rutas y ejemplos sintéticos. Ese paquete no es el runtime privado.
05
La prueba sobre el hardware sigue pendiente
El estado publicado no verifica una respuesta real de modelo a través de HALO ni una ejecución en la máquina AMD Halo. Las rutas sensibles a recursos son un objetivo de diseño con código ilustrativo. Por eso el caso explica la arquitectura y el estado local sin presentar Control Room sintética como prueba operativa.
