Servir Beam 1.0 en el Día Cero: qué determina realmente la receta de SGLang

Un checkpoint que puedes descargar no es un modelo que puedes desplegar, y la distancia entre ambos normalmente se mide en semanas de trabajo de framework realizado por quien sea lo suficientemente impaciente como para hacerlo. Reflection Beam 1.0 es el raro caso en el que ese trabajo llegó junto con los pesos. Reflection anunció el modelo el 5 de octubre de 2026; el 16 de octubre de 2026, los pesos, la licencia Apache 2.0, un endpoint propio y soporte desde el día cero en siete stacks de inferencia llegaron todos juntos, y uno de esos stacks —SGLang, cuya propia cuenta de proyecto dijo el día 16 que sirve Beam en producción en Reflection— publicó una receta lo suficientemente detallada como para discutirla.

Esa receta es el artefacto interesante, más que la tabla de benchmarks. Una publicación de lanzamiento te dice que un modelo es bueno. Una matriz de despliegue te dice lo que cuesta averiguarlo, y dónde las decisiones que tomas determinarán silenciosamente tu latencia. La documentación de SGLang de Reflection Beam 1.0 es un generador: eliges una plataforma de hardware y una estrategia, y emite un comando de Docker con versiones fijadas. Las opciones por las que te obliga a pasar son la verdadera noticia para cualquiera que tenga la intención de ejecutar esto en lugar de llamarlo.

Los tres ejes que la receta se niega a ocultar

La página solicita la plataforma de hardware, la estrategia y la cuantización, y luego construye el comando. Ese es un espacio de decisión más reducido de lo que admite la mayoría de los lanzamientos de modelos, y cada eje tiene una consecuencia real:

• Plataforma de hardware — B300, GB300 o H200. Los chips Blackwell admiten la compilación NVFP4 de forma nativa; H200 es la ruta de FP8 y BF16. Este es el mismo mínimo que describen las notas de la versión de Reflection, reformulado como una lista desplegable.

• Estrategia — de baja latencia o de alto rendimiento, y este es el eje en el que la mayoría de los despliegues se equivocan por defecto. La de baja latencia ejecuta paralelismo de tensores con el drafter DFlash2 habilitado con tamaño de bloque de 8. La de alto rendimiento desactiva DFlash2 por completo.

• Cuantización — NVFP4, FP8 o BF16, que deben estar en consonancia con la plataforma y la estrategia en lugar de poder combinarse libremente.

Los dos preajustes de estrategia no son un ajuste de rendimiento, son un cambio de algoritmo. La decodificación especulativa intercambia latencia de decodificación por trabajo adicional del modelo borrador en cada paso; con un tamaño de bloque de 8 y un borrador de 1,93 mil millones de parámetros, ese intercambio vale la pena cuando atiendes a un solo usuario a la vez y conviene rechazarlo cuando procesas por lotes de forma agresiva. Desactivar DFlash2 para la receta de alto rendimiento no es una degradación, es la respuesta correcta a una pregunta diferente.

Donde las recetas dejan de ser intercambiables

Ve más allá de los ajustes preestablecidos y la página documenta unas cuantas divisiones de configuración que existen por razones de hardware concretas, y vale la pena conocerlas antes de copiar el primer comando de Docker que veas:

• H200 BF16 se ejecuta con TP8 con una fracción de memoria estática automática. El checkpoint BF16 de 933,81 GiB no cabe en menos dispositivos, y la fracción de memoria se calcula en lugar de exponerse, lo que significa que esta es la única receta que no puedes ajustar manualmente sin salir de la ruta soportada.

• Todas las demás recetas usan paralelismo de tensores más DPA. DPA aquí es la disposición de atención de paralelismo de datos que desacopla la atención de la división de paralelismo de expertos, y es la razón por la que las recetas que no son BF16 toleran recuentos de dispositivos que la de BF16 no tolera.

• Blackwell NVFP4 además habilita el paralelismo de expertos y FlashInfer MegaMoE. Esta es la combinación a la que apuntan las propias guías de Reflection, y solo pasa a estar disponible una vez que el checkpoint es la compilación empaquetada de 4 bits de 273 GiB en lugar de FP8 de 468,72 GiB.

La conclusión práctica: «ejecutamos Beam 1.0 en SGLang» no es una afirmación sobre el hardware. Dos equipos pueden decir lo mismo mientras ejecutan precisiones diferentes, configuraciones de paralelismo diferentes y algoritmos de decodificación diferentes, y la única forma de comparar notas es nombrar las tres.

Lo que vale el “día cero” y lo que no

El soporte de frameworks el mismo día en que se publican los pesos es una señal real, y es un tipo específico de señal. El soporte de SGLang para Beam 1.0 existe porque los ingenieros de Reflection trabajaron con la comunidad de SGLang antes del lanzamiento — eso es lo que el proyecto SGLang dijo públicamente el 16 de octubre, y es coherente con que Reflection nombrara a SGLang entre sus socios de día cero junto con Transformers, vLLM, Unsloth, Axolotl, TokenSpeed y NVIDIA Dynamo, con recetas escritas para SGLang, vLLM y TokenSpeed, además de un chart de Helm para Kubernetes.

• Lo que establece — una ruta documentada y mantenida desde el checkpoint publicado hasta un endpoint servido, sobre hardware con nombre, con las variantes de cuantización contempladas. Eso es realmente más de lo que la mayoría de los lanzamientos abiertos logran en la primera semana.

• Lo que no establece — que la configuración sea óptima, ni que las cifras de rendimiento que obtenga coincidan con las de cualquier otra persona. La afirmación de producción en Reflection es del proveedor y del framework, reportada por las personas que prestan el servicio. No hemos visto una reproducción independiente de la misma, y no se ha publicado ningún benchmark de terceros de un despliegue de Beam autoalojado.

Esa distinción importa más aquí que de costumbre, porque se trata de una mezcla dispersa de expertos de 501,3 mil millones de parámetros con 23,4 mil millones de parámetros activos por token, y todo el valor de la arquitectura radica en que tu coste de servicio es una fracción del nombre del modelo. El soporte del framework es lo que convierte esa afirmación de un diagrama de arquitectura en un presupuesto de memoria. No lo convierte en una cifra de rendimiento medida, y ningún material de primera parte que hayamos podido encontrar publica una para inferencia — el único número concreto de tokens por segundo en el lanzamiento describe el ajuste fino supervisado con LoRA en un nodo único de 8 GPUs B300, que es un paso de entrenamiento, no una tasa de servicio.

El modo de fallo que realmente tiene una pila autoalojada de día cero

Hay una forma específica en la que esto sale mal, y no es el modelo. Es la segunda semana. Una imagen de Docker fijada, compilada para una sola cuantización y un solo esquema de paralelismo, no es un respaldo para sí misma: si el modelo de borrador tiene una mala interacción con tu patrón de tráfico, si una actualización del controlador cambia lo que asigna la fracción de memoria, o si tu capacidad está en cola detrás de otro inquilino, no te queda ninguna configuración a la que recurrir — tienes una caída en la que hay un modelo muy capaz sentado.

Beam 1.0 no es una de nuestras rutas, así que no podemos servírtelo, y nada de lo que aparece aquí debe interpretarse como una declaración de disponibilidad por nuestra parte. Lo que sí podemos hacer es poner el fallback en un lugar útil. OrcaRouter ejecuta una única clave compatible con OpenAI en más de 200 modelos, con el precio de lista del proveedor traspasado y sin ningún añadido, y con conmutación por error automática entre proveedores, de modo que un piloto de Beam autoalojado que deja de responder es un cambio de enrutamiento y no un incidente. Los modelos que un despliegue de Beam suele reemplazar, y que son accesibles de esa forma, vienen con tarifas publicadas:

• GLM-5.2 — 1,40 $ por millón de tokens de entrada y 4,40 $ por millón de salida con un contexto de 1.000.000 de tokens. El modelo con el que se mide la propia afirmación de eficiencia de Reflection, y el sustituto más directo del trabajo de codificación de contexto largo de Beam.

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

• Qwen3.8-Max — $2.00 por millón de tokens de entrada y $6.00 de salida con una ventana de 1,000,000 de tokens, la opción propietaria de gama insignia para equipos que quieren la capacidad sin el rack.

Lo que la receta aún no te dice

Merece la pena nombrar tres lagunas, porque cada una es una decisión que acabarás tomando con menos información de la que te gustaría.

Lo primero es el precio. El endpoint de Reflection está documentado y es compatible con OpenAI, con esfuerzos de razonamiento max, xhigh, high, medium y low, razonamiento obligatorio regido por un valor predeterminado de max, y límites por organización compartidos entre todas las claves. No tiene una tarifa publicada por millón de tokens, por lo que el caso de eficiencia de Beam 1.0 no puede completarse como un ejercicio aritmético. Un modelo que siempre razona y usa el esfuerzo máximo como valor predeterminado es una propuesta comercial distinta según si el token de salida cuesta uno o diez dólares.

El segundo es una medición independiente. Artificial Analysis incluye el modelo con un Intelligence Index de 30, sin datos de velocidad ni precio, y no registra ninguna API disponible públicamente para él, lo que constituye una declaración de terceros de que la superficie alojada aún no es visible para quienes miden estas cosas. Su único dato de eficiencia contabilizado de forma independiente es real: Beam generó 79 M de tokens de salida en el Intelligence Index de AA, frente a una mediana de 130 M para el conjunto de comparación. Eso respalda la afirmación de "menos tokens de razonamiento". No te dice a qué velocidad salen los tokens.

El tercero es la deriva de versiones. Las recetas publicadas están escritas para un checkpoint específico y una compilación específica de SGLang, y el drafter es su propio repositorio. Cuando cualquiera de los dos cambia, la receta que fijaste en octubre es una configuración que nadie ha probado en noviembre. Trata el comando de Docker como un punto de partida con fecha de caducidad, no como un despliegue.

¿Quién debería actuar sobre esto ahora y quién debería esperar?

Si ya posees la capacidad de Blackwell, la receta de SGLang es realmente suficiente para empezar: cuatro B300 son la configuración de referencia de NVFP4, los cálculos de memoria están publicados, existe la suite de conformidad y el riesgo a la baja está acotado al tiempo de ingeniería. Si no posees el hardware, el cálculo sigue sin cuadrar, porque la opción alojada no tiene una tarifa con la que compararla con una compra de capital — y el soporte del framework desde el día cero, por bueno que sea, no sustituye a un precio.

Lo que hay que seguir de cerca no es otro framework que anuncie soporte. Es la primera cifra publicada que no provenga de Reflection ni de un proyecto de framework: una medición independiente de rendimiento sobre una configuración con nombre, o una lista de tarifas para el endpoint de primera parte. Cualquiera de las dos hace que esto pase de ser un experimento bien documentado a una partida presupuestaria. Hasta entonces, la lectura correcta del 16 de octubre es que la ingeniería dura se entregó según lo previsto —y el caso comercial es la parte que aún está en construcción.

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.