Tuve el mismo pensamiento, así que he estado experimentando con ello en nanochat. Por ejemplo, aquí hay 8 agentes (4 claude, 4 codex), cada uno con 1 GPU ejecutando experimentos de 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é algunas configuraciones: 8 investigadores independientes, 1 científico jefe dando trabajo a 8 investigadores junior, etc. Cada programa de investigación es una rama de git, cada científico la bifurca en una rama de características, git worktrees para aislamiento, archivos simples para comunicaciones, omitir Docker/VMs por simplicidad por ahora (encuentro que las instrucciones son suficientes para prevenir interferencias). La organización de investigación se ejecuta 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 bien, la razón por la que no funciona hasta ahora es que las ideas de los agentes son simplemente bastante malas desde el principio, incluso con la mayor inteligencia. No piensan cuidadosamente en el diseño del experimento, ejecutan variaciones un poco sin sentido, no crean bases sólidas y no ablationan las cosas correctamente, no controlan cuidadosamente el tiempo de ejecución o los flops. (solo como ejemplo, un agente ayer "descubrió" que aumentar el tamaño oculto de la red mejora la pérdida de validación, lo cual es un resultado totalmente espurio dado que una red más grande tendrá una menor pérdida de validación en el régimen de datos infinitos, pero luego también entrena durante mucho más tiempo, no está claro por qué tuve que intervenir para señalar eso). Son muy buenos implementando cualquier idea bien definida y descrita, pero no 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 la componen. Por ejemplo, una reunión diaria por la mañana ahora es parte del "código de la organización". Y optimizar el preentrenamiento de nanochat es solo una de las muchas tareas (casi como una evaluación). Entonces, dado un tarea arbitraria, ¿qué tan rápido genera progreso tu organización de investigación en ella?

Con la inminente ola de demanda de tokens, hay oportunidades significativas para orquestar la memoria y el procesamiento subyacentes *justo bien* para los LLMs. La restricción fundamental y no obvia es que, debido al proceso de fabricación de chips, obtienes dos grupos de memoria completamente distintos (de diferentes implementaciones físicas también): 1) SRAM en chip que está inmediatamente al lado de las unidades de procesamiento, 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 extraer a través de una pajita larga. Además de esto, hay muchos detalles de la arquitectura (por ejemplo, arreglos sistólicos), numéricos, etc. El diseño del sustrato físico óptimo y luego la orquestación de memoria y procesamiento a través de los flujos de trabajo de volumen superior de los LLMs (inferencia, prellenado/decodificación, entrenamiento/ajuste fino, etc.) con el mejor rendimiento/latencia/$ es probablemente el rompecabezas intelectual más interesante de hoy con las mayores recompensas (\cite 4.6T de NVDA). Todo esto para obtener muchos tokens, rápido y barato. Se podría argumentar que el flujo de trabajo que puede importar más (decodificación de inferencia *y* sobre contextos de tokens largos en bucles agenciales ajustados) es el que más difícil es de lograr simultáneamente por los ~dos grupos de lo que existe hoy (NVIDIA adyacente a HBM primero y Cerebras adyacente a SRAM primero). De todos modos, el equipo de MatX es de grado A++, así que es un placer tener una pequeña participación y ¡felicitaciones por la recaudación!