Beam 1.0 en cuatro B300s: las matemáticas del serving, y la afirmación de throughput que nadie publicó

El número en el que vale la pena detenerse en el lanzamiento de Reflection Beam 1.0 no es 501 mil millones. Es cuatro. Un modelo con 501,3 mil millones de parámetros totales y 23,4 mil millones activos por token ahora cabe en un solo servidor con cuatro GPU NVIDIA B300 en NVLink, y la distancia entre esas dos cifras —alrededor del 4,7 por ciento del modelo despierto en cualquier token dado— es la razón principal por la que un checkpoint de este tamaño puede descargarlo cualquiera que no tenga un clúster. Reflection publicó los pesos el 16 de octubre de 2026 bajo Apache 2.0, y el material de lanzamiento es inusualmente específico sobre lo que se necesita para servirlos: cuatro GPU B300 en NVLink para la versión NVFP4, ocho H200 para FP8 y ocho B200 o B300 para BF16. Esa tabla de hardware es más interesante que la tabla de benchmarks, porque es la parte que un lector puede contrastar realmente con su propia hoja de adquisición.

También es la parte que separa a Beam 1.0 de los modelos con los que se lo compara. Kimi K3 y GLM-5.2 se sirven detrás de API, y sus pesos o no son públicos o vienen con un conjunto distinto de condiciones; Qwen3.8-Max es propietario en la gama insignia. La propuesta de Beam es que la mitad difícil de ese intercambio —un modelo cercano a la frontera disponible para descargar— ya se lanzó, y que el coste de servicio es un rack en lugar de un centro de datos.

Qué aterrizó realmente el 16 de octubre

La publicación de Reflection «Beam ya está disponible» está fechada el 16 de octubre de 2026, once días después de que el modelo se anunciara el 5 de octubre. Se lanzaron cuatro artefactos, y las precisiones importan más que el titular:

• BF16 — 501,3 B de parámetros, 933,81 GiB en disco, 188 fragmentos de safetensors. La precisión de referencia; la primera columna de la tabla de benchmarks.

• FP8 — la misma cantidad de parámetros en E4M3, 468,72 GiB. Cuantizado con N​VIDIA ModelOpt. Recomendado para Hopper y hardware más antiguo.

• NVFP4 — una compilación empaquetada de 4 bits de 273 GiB. Esta es la que las propias guías de servicio de Reflection te indican descargar, y la única que se ejecuta de forma nativa en Blackwell sin penalización por descuantización.

• DFlash2 — un borrador de decodificación especulativa de 1.93B parámetros, publicado como su propio repositorio e integrado en los comandos de ejemplo como un conjunto de pesos independiente.

La arquitectura que hay detrás de esos puntos de control es una mezcla dispersa de expertos: 52 capas, de las cuales 3 son densas y 49 son MoE, 256 expertos por capa MoE, atención de consulta agrupada con compuertas combinada con atención de ventana deslizante, y un vocabulario de 152.000 tokens. Entrada de texto, salida de texto, contexto de 1 M de tokens en la ficha del modelo, 131.072 tokens de salida máxima en la API. Fecha de corte de conocimiento: 30 de junio de 2026.

La cifra de rendimiento que no está en la documentación

Un número ha estado circulando con este lanzamiento desde el día cero: más de 70.000 tokens de salida por segundo por GPU en Blackwell Ultra. Es una cifra atractiva y vale la pena ser precisos sobre dónde aparece y dónde no. No está en la publicación de lanzamiento de Reflection, ni en la tarjeta del modelo, ni en las notas de la versión de Hugging Face, ni en la documentación para desarrolladores. No pudimos encontrarlo en ninguna fuente de primera parte.

Lo que el material del proveedor sí documenta es relativo, no absoluto. La única afirmación de eficiencia de la ficha del modelo es que Beam «alcanza una calidad de solución comparable a la de los principales modelos abiertos utilizando aproximadamente 3× menos tokens de razonamiento en tiempo de inferencia», y la publicación de lanzamiento enmarca la misma idea como «más inteligencia por token». El único número con forma de rendimiento que sí publica la versión es una aceleración medida, y no una tasa: el drafter DFlash2 eleva la velocidad de decodificación entre 1,7× y 3,0× respecto a Beam por sí solo, medido en el checkpoint NVFP4 en cuatro B300, con longitudes de aceptación de 4,11 a 5,88 tokens de un máximo de ocho. Se trata de una proporción frente a la propia línea base de Beam, así que no dice nada sobre los tokens absolutos por segundo por GPU — no resolverá la cifra de 70.000 en ningún sentido.

Hay una señal independiente de que la afirmación de eficiencia no es puro marketing. Artificial Analysis midió Beam 1.0 en 79M tokens de salida en el Intelligence Index, frente a una mediana de 130M para los modelos con los que se compara — clasificado en el puesto #10 de 46 en esa medida. Eso es un tercero contando tokens generados y encontrando que Beam es más frugal que la mayoría del sector, lo cual es una afirmación más débil que una cifra de rendimiento por GPU y mucho mejor respaldada.

Lo que cuatro B300 te aportan realmente, en memoria

La documentación de servido es lo más útil que Reflection publicó, porque responde preguntas que una tabla comparativa de rendimiento nunca plantea. Tres cifras destacan.

• Huella de la caché KV — las recetas de vLLM y NVIDIA Dynamo usan de forma predeterminada una caché FP8 E4M3 con un tamaño de página de 64 tokens, que, según señala la receta de vLLM, se duplica a aproximadamente 14M a 28M tokens de contexto cacheable en ocho H200 ejecutando el checkpoint FP8. Ese es el número con el que hay que dimensionar un despliegue; un plan de tres GPU falla mucho antes de que lo haga la caché.

• El checkpoint NVFP4 solo cuantiza los expertos enrutados. La atención, los MLP densos, el enrutador, los embeddings y la cabeza LM permanecen en BF16, por lo que el archivo ocupa 273 GiB en lugar de los 250 y pico que te daría una pasada completa de 4 bits. En Blackwell se ejecuta W4A4; en Hopper, vLLM sirve los expertos FP4 mediante Marlin con activaciones BF16.

• El checkpoint NVFP4 en cuatro B300 es la configuración de referencia, y la receta de SGLang se distribuye como una imagen Docker fijada con paralelismo tensorial establecido en 4, el drafter DFlash2 habilitado con tamaño de bloque 8, y decodificación especulativa configurada junto con la caché KV FP8.

También hay una herramienta de verificación. La CLI de código abierto beam-verifier ejecuta una suite de conformidad contra cualquier endpoint de Beam en vivo —contrato de solicitud, contrato de respuesta, protocolo de herramientas— y luego lo evalúa en los principales benchmarks para que puedas comparar tu propio despliegue, o el de un proveedor, con las puntuaciones de referencia de Reflection. Para un modelo cuya tabla de benchmarks es enteramente reportada por el proveedor, entregar el arnés que permite a un comprador reproducirla es un compromiso más significativo que cualquier número individual en esa tabla.

El soporte de frameworks desde el día cero es la otra mitad de la historia del despliegue, y es más amplio de lo que consiguen la mayoría de los lanzamientos abiertos: Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed y NVIDIA Dynamo, con recetas paso a paso para SGLang, vLLM y TokenSpeed, además de un chart de Helm para Kubernetes. En el apartado de entrenamiento, Reflection nombra los stacks con los que construyó los flujos de trabajo —NeMo RL y AutoModel y Megatron Bridge de NVIDIA, Miles de RadixArk, TRL de Hugging Face, SkyRL de Anyscale y Axolotl— y publica las cifras de su runbook de RL en lugar de una cifra de hardware para estos: 10,5K GPU GB300 durante cuatro semanas, más de 100 millones de rollouts, un contexto máximo de 256K tokens durante el entrenamiento y aproximadamente 1300 millones de sandboxes.

La API existe, y todavía no tiene precio.

Junto a los pesos hay un endpoint propio en api.reflection.ai con una superficie compatible con OpenAI y el ID de modelo Beam-1.0-501B-A23B. Lleva un contrato documentado: razonamiento obligatorio con niveles de esfuerzo max, xhigh, high, medium y low, donde max es el predeterminado; salidas estructuradas y llamada a herramientas; límites de tasa para toda la organización medidos en solicitudes y tokens por minuto y por día UTC, compartidos entre todos los proyectos y claves, de modo que añadir una clave no los aumenta; y una respuesta 429 que establece x-should-retry en false una vez agotado el cupo diario, que es el detalle que evita que un bucle de reintentos ingenuo se quede girando hasta la medianoche.

La documentación no incluye un precio por millón de tokens, y el anuncio tampoco. Esa única omisión es lo que hace que el argumento de la eficiencia quede sin cerrar para un comprador: un modelo que siempre razona, que por defecto recurre al máximo esfuerzo y que afirma usar tres veces menos tokens de razonamiento es una propuesta comercial distinta a un dólar por millón de tokens de salida que a diez, y hoy nadie fuera de Reflection puede decir cuál de las dos es. El autoalojamiento elimina la pregunta por completo y la sustituye por una cifra de capital, que al menos es un número que se puede calcular.

¿En qué situación deja esto a un equipo que quiere probarlo?

Beam 1.0 no es una de nuestras rutas, así que no podemos servírtelo, y nada de lo que aquí se dice debe interpretarse como una afirmación de disponibilidad por nuestra parte. Lo que sí podemos hacer es abaratar la evaluación. Si la decisión que tienes delante es si dedicar un trimestre de tiempo de ingeniería a un piloto de Beam de dos semanas, lo útil es mantener producción en un modelo con una tarifa publicada y un historial de servicio mientras se ejecuta el piloto, y tener ya preparado el mecanismo de respaldo. OrcaRouter utiliza una única clave compatible con OpenAI en más de 200 modelos, con el precio de lista del proveedor traspasado y sin ningún recargo, de modo que una bajada de precio del proveedor llega a tu factura el mismo día, y la conmutación automática por error significa que un piloto que resulte no estar disponible el mes que viene es un cambio de enrutamiento en lugar de una migración.

Los modelos más parecidos a Beam en las cargas de trabajo a las que apunta son todos accesibles de esa manera. Los tres que vale la pena comparar en precio con el piloto, según nuestro propio catálogo:

• GLM-5.2 — contexto de 1.000.000 de tokens, $1,40 por millón de tokens de entrada y $4,40 por millón de salida. El modelo con el que se mide la propia afirmación de eficiencia de Reflection.

• Kimi K3 — contexto de 1.048.576 tokens, $3,00 por millón de tokens de entrada, $0,30 en caché, $15,00 de salida. La publicación de lanzamiento de Reflection admite que K3 sigue por delante en capacidad bruta.

• Qwen3.8-Max — contexto de 1.000.000 tokens, $2,00 por millón de entrada y $6,00 por millón de salida, la clase de 2 billones de parámetros sobre la que Beam afirma tener su mayor ventaja de eficiencia.

Las tres cosas que hay que vigilar

Lo primero es el precio. Hasta que Reflection publique una lista de tarifas, la tesis de la eficiencia es una hipótesis sobre el cómputo y no un hecho sobre el dinero, y la comparación con GLM-5.2 o Kimi K3 sigue siendo una discusión sobre la metodología.

El segundo es una medición de rendimiento independiente. Actualmente, Artificial Analysis incluye a Beam con un Intelligence Index de 30, sin velocidad y sin precio, porque registra «No hay API disponible públicamente» para el modelo. Cuando eso cambie, la pregunta por GPU obtendrá una respuesta que no se originó en el proveedor.

El tercero es si el verificador se utiliza. Una suite de conformidad que nadie ejecuta es documentación; una suite de conformidad de la que una docena de despliegues publican resultados es un benchmark. Beam 1.0 lanzó la herramienta el día cero. Si publica los números es la parte que sigue abierta.

Nada de eso es hipotético: los fallos documentados de IA y los incidentes de agentes detrás de lanzamientos como este se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, severidad, grado de confianza e indicador de disputa.