Tuve la misma idea, así que he estado probándolo en nanochat. Por ejemplo, aquí hay 8 agentes (4 claude, 4 códex), con 1 GPU cada uno ejecutando experimentos nanochat (intentando eliminar el softcap de logit sin regresión). El resumen es que no funciona y es un desastre... Pero sigue siendo muy bonito de ver :) Probé varias configuraciones: 8 investigadores independientes en solitario, 1 científico jefe dando trabajo a 8 investigadores junior, etc. Cada programa de investigación es una rama git, cada científico lo bifurca en una rama de funcionalidad, árboles de trabajo git para aislamiento, archivos simples para comunicaciones, salta Docker/VMs por simplicidad ahora mismo (encuentro que las instrucciones son suficientes para evitar interferencias). La organización de investigación funciona en cuadrículas de ventanas tmux de sesiones interactivas (como Teams) para que sea bonito de ver, ver su trabajo individual y "tomar el control" si es necesario, es decir, sin -p. Pero vale, la razón por la que no funciona hasta ahora es que las ideas de los agentes son bastante malas desde el principio, incluso con la inteligencia más alta. No piensan cuidadosamente en el diseño de los experimentos, ejecutan variaciones un poco absurdas, no crean líneas base fuertes ni ablacionan las cosas correctamente, no controlan cuidadosamente el tiempo de ejecución o los flops. (Por ejemplo, ayer un agente "descubrió" que aumentar el tamaño oculto de la red mejora la pérdida de validación, lo cual es un resultado totalmente innecesario dado que una red más grande tendrá una pérdida de validación menor en el régimen de datos infinitos, pero además entrena mucho más tiempo, no está claro por qué tuve que intervenir para señalarlo). Son muy buenos implementando cualquier idea bien definida y descrita, pero no la generan creativamente. Pero el objetivo es que ahora estés programando una organización (por ejemplo, una "organización de investigación") y sus agentes individuales, así que el "código fuente" es la colección de prompts, habilidades, herramientas, etc. y procesos que lo componen. Por ejemplo, una reunión diaria de pie por la mañana ahora forma parte del "código de organización". Y optimizar el preentrenamiento de nanochat es solo una de las muchas tareas (casi como una evaluación). Entonces, dada una tarea arbitraria, ¿qué tan rápido genera progresos en ella tu organización de investigación?

Con el inminente tsunami de demanda de tokens, existen oportunidades significativas para orquestar la memoria subyacente + cálculo *justo a la perfección* para los LLMs. La restricción fundamental y no obvia es que, debido al proceso de fabricación del chip, se obtienen dos pools de memoria completamente distintos (de diferentes implementaciones físicas también): 1) SRAM integrada que está justo al lado de las unidades de cálculo, que es increíblemente rápida pero de muy baja capacidad, y 2) DRAM fuera del chip que tiene una capacidad extremadamente alta, pero cuyo contenido solo puedes aspirar con una pajita larga. Además, hay muchos detalles de la arquitectura (por ejemplo, arrays sistólicos), números, etc. El diseño del sustrato físico óptimo y luego la orquestación de memoria+computación a lo largo de los flujos de trabajo de mayor volumen de los LLMs (prellenado/decodificación de inferencia, entrenamiento/ajuste fino, etc.) con el mejor rendimiento de rendimiento/latencia/dinero es probablemente el puzle intelectual más interesante de hoy en día con las mayores recompensas (\cite 4,6T de NVDA). Todo para conseguir muchas fichas, rápido y barato. Se podría argumentar que el flujo de trabajo que más importe (decodificación por inferencia *y* sobre contextos largos de tokens en bucles agentivos ajustados) es el más difícil de lograr simultáneamente por los ~ambos bandos de lo que existe hoy en día (adyacente a NVIDIA primero con HBM y adyacente a Cerebras con SRAM primero). En fin, el equipo de MatX tiene un nivel A++, así que es un placer tener una pequeña participación y ¡enhorabuena por el aumento!