Presentar un modelo y permitir que otros lo desplieguen son decisiones distintas. Reflection dio a conocer Beam el 5 de octubre de 2026 y publicó sus pesos el día 16, bajo Apache 2.0. La segunda fecha abre una vía de operación propia, junto a la API y el servicio alojado descritos por la empresa. [1] [2]
Beam utiliza una mezcla de expertos: suma 501.000 millones de parámetros, de los que activa 23.000 millones al procesar una entrada. Esa diferencia explica parte de su arquitectura, pero no convierte el conjunto en una descarga ligera. Su funcionamiento dentro de un agente añade otra capa de herramientas, permisos y gestión del trabajo. [1]
Una arquitectura que distribuye el cálculo
Reflection presentó Beam el 5 de octubre y anunció la publicación de sus pesos el 16. Lo describe como un modelo de mezcla de expertos con 501.000 millones de parámetros totales y 23.000 millones activos, centrado en código, razonamiento y tareas de agentes. La publicación posterior distribuye los pesos bajo Apache 2.0. [1] [2]
Separar ambas fechas evita vender una demostración anterior como si fuera el estreno del día. También distingue una promesa de apertura de la posibilidad efectiva de descargar archivos. Es el segundo hecho el que permite a terceros empezar a estudiar despliegue y adaptación bajo las condiciones publicadas.
En una arquitectura de mezcla de expertos, una entrada no necesita utilizar de igual manera todas las partes del modelo. La ruta selecciona una fracción del conjunto para el cálculo. Eso permite que el trabajo por token difiera mucho del tamaño total de los parámetros almacenados.
La distinción importa para interpretar el hardware. Menos parámetros activos puede reducir parte del cálculo, pero no convierte automáticamente todo el conjunto en un archivo pequeño. Memoria, movimiento de datos y atención también participan. No se puede deducir que un PC capaz de alojar un modelo de 23.000 millones ejecute sin más este conjunto de 501.000 millones.
Una aplicación generada por código puede tener gráficos, sonido y movimiento aunque el modelo no reciba imágenes directamente. El modelo describe o escribe instrucciones que otra herramienta interpreta. De la misma manera, puede utilizar texto extraído de un documento por un servicio auxiliar.
Por eso hay que separar el tipo de entrada del modelo del aspecto de la aplicación final. Un juego visual no prueba visión directa; una tabla calculada no prueba acceso a datos que no se proporcionaron. La explicación completa debe identificar esas conexiones, especialmente cuando el resultado parece atribuir al modelo capacidades de todo el sistema.
Del modelo al agente que utiliza herramientas
Un modelo puede proponer código. Un agente añade la posibilidad de ejecutarlo, observar un error y volver a modificarlo. Entre ambas cosas hay un entorno con archivos, permisos, herramientas y reglas de parada. La calidad de esa organización influye en el resultado tanto como la respuesta inicial.
En una aplicación web, por ejemplo, la primera salida puede tener un botón que no funciona. Si el sistema ejecuta la página y lee el fallo, puede corregirlo. Si solo entrega el código sin comprobarlo, ese paso sigue pendiente. Ver la aplicación final no revela por sí solo cuántas iteraciones o intervenciones hicieron falta.
Entre las demostraciones de la presentación figura un juego 3D en p5.js: un astronauta cae hacia la Tierra y debe esquivar o destruir asteroides. Reflection lo presenta como un ejemplo de código generado por Beam, que trabaja con texto. [1]
Ver un juego funcionando no significa que el modelo esté observando la pantalla o jugando por sí solo. El programa resultante puede dibujar y responder a controles aunque la herramienta que escribió el código no tenga entrada visual. Esa distinción ayuda a entender qué parte del proceso se está mostrando.
El anuncio de disponibilidad incluye documentación, integraciones de inferencia, personalización y herramientas como Mirror CLI. Reflection subraya que un sistema de agentes necesita más capas que los pesos del modelo. [2]
En un trabajo real también importan el acceso a archivos, las herramientas que puede ejecutar y cómo se revisan sus cambios. Dos sistemas basados en el mismo modelo pueden ofrecer experiencias distintas si su entorno permite o impide comprobar resultados. Por eso, evaluar un agente exige describir el conjunto y no solo citar una puntuación del modelo.
Desplegarlo exige algo más que descargarlo
Reflection describe formatos BF16, FP8 y NVFP4, compatibilidad con varios motores de inferencia y el entorno Mirror CLI. También presenta rutas de adaptación y evaluación dentro de un ecosistema de integraciones. [2]
La precisión reducida cambia la forma de representar valores y puede ayudar con memoria o velocidad, pero debe ser compatible con el motor y el hardware. Una integración anunciada indica una vía de uso; no garantiza que cualquier combinación de versión y equipo alcance los tiempos de una demostración del proveedor.
Los usos a evaluar incluyen mantenimiento de software, preparación de herramientas y trabajo repetido con varias etapas. El interés de los pesos abiertos es poder inspeccionar y adaptar el despliegue dentro de las condiciones publicadas. Esa posibilidad implica asumir operación, actualizaciones y control del entorno.
Para un equipo pequeño puede resultar más práctico empezar con un servicio gestionado y una tarea limitada. Para una organización con infraestructura, puede importar más la integración y el control del despliegue. Son decisiones de adopción diferentes; no se resuelven diciendo que el modelo es abierto o que una aplicación de muestra parece terminada.
Los parámetros activos describen parte del cálculo por token; el conjunto de pesos tiene una escala mucho mayor. Descargar el modelo y ejecutarlo con una velocidad útil son requisitos diferentes.
La infraestructura, la latencia, el coste y la calidad de la tarea terminada condicionan un despliegue. Una mejora en eficiencia de cálculo no elimina por sí sola las necesidades de memoria, comunicación y operación.
La página de Reflection reúne peticiones iniciales, resultados y ejemplos de programación. Astronaut Free-Fall utiliza p5.js para representar un astronauta que esquiva o destruye obstáculos. [1]
Una aplicación interactiva necesita lógica y ejecución, además de una apariencia visual. Controles, colisiones y reinicio forman parte del programa. El resultado de una demostración no describe por sí solo todos los intentos necesarios para construirlo.
Los ejemplos de aplicaciones interactivas muestran un resultado del sistema completo. Para atribuir una capacidad concreta a Beam hay que separar la generación de texto de los programas que ejecutan código, mantienen el estado o representan la escena. Los pesos abiertos permiten estudiar y operar el modelo; no eliminan esas piezas del proceso.
Fuentes y documentación
El material original
Demostraciones originales interactivas de Reflection.