Ya están los pesos de Beam de Reflection. Cómo los sirva ahora importa tanto como el modelo

Cuando Reflection anunció Beam el 5 de octubre, los pesos seguían en red teaming final. Nuestro primer análisis trataba sobre qué hereda una empresa cuando ejecuta por cuenta propia un modelo de 501 mil millones de parámetros. El 16 de octubre llegaron los pesos, y la pregunta ha cambiado: ya no se trata de si puede ejecutar Beam, sino de por qué forma de servirlo está pagando.

Qué se lanzó

Beam está en Hugging Face bajo Apache 2.0 en tres precisiones, BF16, FP8 y NVFP4, más un modelo borrador pequeño para decodificación especulativa, con una tarjeta de modelo y un informe técnico de seguridad. La arquitectura es la anunciada: una mezcla dispersa de expertos con 501 mil millones de parámetros totales y unos 23 mil millones activos por token. Las publicaciones de AWS y Google indican una ventana de contexto de alrededor de un millón de tokens.

Reflection también publicó Mirror, un harness de línea de comandos de código abierto para ejecutar Beam como agente de programación. Permite a un desarrollador inspeccionar lo que hace el agente, aprobar llamadas a herramientas, guiarlo a mitad de tarea y ejecutar agentes en paralelo en distintos Git worktrees, y se extiende mediante instrucciones de proyecto, skills, conexiones MCP y Python. Más de veinte plataformas anunciaron soporte el primer día, entre ellas AWS, Google Cloud, Microsoft Foundry, Databricks, Oracle y Cloudflare, además de Dell y HPE para despliegue en instalaciones propias. Las recetas de autodestilación se prometen “en los próximos días”.

Tres precisiones son tres decisiones de calidad

La precisión que elija no es solo una decisión de hardware. En AWS, los pesos FP8 se ejecutan en instancias H100 o H200 (ml.p5.48xlarge, ml.p5e.48xlarge, ml.p5en.48xlarge), NVFP4 se ejecuta en B200 (ml.p6-b200.48xlarge) y BF16 necesita una configuración de varios nodos. Como aritmética aproximada, 501 mil millones de parámetros ocupan alrededor de un terabyte a 16 bits, cerca de la mitad a 8 bits y alrededor de un cuarto a 4 bits, antes del KV cache que llenan las sesiones largas de agentes.

La propia guía de AWS recomienda volver a comprobar la calidad de salida después de cambiar la precisión. Es el instinto correcto: un modelo de 4 bits que cabe en menos GPU es un modelo distinto a efectos de evaluación. Ejecute su conjunto de evaluación de programación con la precisión que realmente va a servir, no con la que usó el benchmark.

Cuatro formas de ejecutar los mismos pesos de Beam

	Quién lo opera	Qué elige	Qué sigue demostrando
API de Reflection o un socio alojado	El proveedor	Plan y región	Calidad en sus tareas, términos de datos
SageMaker JumpStart	AWS gestiona el endpoint	Tipo de instancia y precisión	Calidad a esa precisión, cuota de capacidad
GKE con llm-d o Dynamo	Su equipo de plataforma	Enrutamiento, caché, desagregación	Rendimiento y latencia con su tráfico
Su propio centro de datos (Dell, HPE)	Usted, de extremo a extremo	Todo	Todo, más la aplicación de parches

Por qué la capa de servicio ahora importa tanto como el modelo

La publicación de Google es el documento más instructivo del lanzamiento, leído con atención. En GKE, Google informa de hasta 5x más rendimiento y 8x menos latencia con NVIDIA Dynamo y SGLang en 32 GPU GB300, y de hasta 2x más rendimiento y 8x menos latencia con llm-d y vLLM en ocho GPU RTX PRO 6000. Ambas cifras se comparan con un despliegue simple en el mismo hardware con enrutamiento round-robin sin estado, en una carga de trabajo de programación agéntica de varios turnos. La cifra de 5x está marcada como basada en benchmarking de clientes, y las dos configuraciones no son comparables entre sí.

Las ganancias vienen de tres técnicas: enrutar cada sesión de varios turnos de vuelta a la réplica que ya tiene su KV cache, separar la fase de procesamiento del prompt de la generación de tokens para que las ráfagas de prompts largos no bloqueen la salida, y volcar el KV cache a la memoria del host y al SSD local. Ninguna cambia el modelo. Todas cambian lo que cuesta una tarea de programación completada.

Esto importa porque los agentes de programación son el peor caso para un servicio sin optimizar. Una sesión envía un contexto largo y creciente en cada turno. Sin enrutamiento con reconocimiento de caché, cada turno puede caer en una réplica que tiene que procesar todo el historial de nuevo. Los mismos pesos, en las mismas GPU, pueden costar por tanto varias veces más por tarea según una decisión de enrutamiento que tome su equipo de plataforma, que es el punto que planteamos sobre el precio de la inferencia por tarea completada.

Dos advertencias. Las cifras de Google son cifras “de hasta” frente a una línea base débil, y las ganancias crecen con el tamaño del despliegue, así que un piloto pequeño no las verá. Y la afirmación de Reflection de 3x a 4x menos tokens de razonamiento que modelos abiertos comparables es de Reflection; pruébela en sus tareas antes de que llegue a un caso de negocio.

Qué hacer con el lanzamiento

Para los equipos que evaluaron Beam desde el anuncio, el trabajo ahora es concreto. Elija la ruta de la tabla según quién debe operar el modelo. Si elige SageMaker JumpStart, en el lanzamiento solo está disponible en dos regiones de US East y no en ninguna región europea, lo que importa a los equipos en España que necesitan procesar en la UE bajo el RGPD; HyperPod puede ejecutarse en cualquier región que ofrezca las instancias GPU necesarias, y los equipos de Latinoamérica deben confirmar la disponibilidad en su región. Escoja una precisión y evalúe con esa precisión. Si aloja el modelo usted mismo, trate el enrutamiento con reconocimiento de KV cache como un requisito para el tráfico de agentes, no como una optimización. Y revise las aprobaciones de llamadas a herramientas de Mirror antes de que sus desarrolladores lo apunten a un repositorio con credenciales de producción: un harness abierto es útil precisamente porque puede ver y definir dónde se detiene a preguntar.