Reflection ha rilasciato Beam, un LLM aperto che sposta l'attenzione dal semplice conteggio dei parametri al costo per ragionamento. La scheda tecnica indica 501 miliardi di parametri totali e 23 miliardi attivi, una finestra di contesto da 1 milione di token e tre formati numerici per l'inference: BF16, FP8 e NVFP4. Il modello è instruction-tuned e sviluppato prevalentemente per l'inglese.

Il dato più rilevante non è la massa complessiva del modello, ma la tesi ingegneristica che Reflection porta avanti: Beam è progettato per usare circa un terzo dei token di ragionamento rispetto ai migliori modelli aperti a parità di qualità. In un contesto in cui il costo operativo cresce con i token generati, questa scelta si traduce in un beneficio diretto sul TCO di chi gestisce carichi on-premise. Meno token di ragionamento significano pressione ridotta sulla latenza e sulle risorse di calcolo, soprattutto quando i modelli affrontano task lunghi di coding, debugging o uso di strumenti.

Ma c'è un nodo che l'etichetta 'MoE da 501 miliardi' non deve nascondere. I 23 miliardi di parametri attivi riducono il calcolo per token, perché a ogni passaggio viene coinvolta solo una parte degli esperti; l'intero set di esperti, però, deve restare disponibile in memoria. Con 256 esperti e 52 layer, di cui 3 layer dense e 49 MoE, la pressione sulla VRAM non è quella di un modello da 23 miliardi. È quella di un modello da 501 miliardi, mitigata dalla quantization. I formati FP8 e NVFP4 servono esattamente a questo: ridurre l'ingombro dei pesi e aumentare il throughput. In cambio, spostano l'attenzione sulla qualità della compressione, che diventa una variabile di deployment tanto importante quanto l'architettura stessa.

I benchmark pubblicati mostrano un profilo forte sui compiti di ragionamento e coding. Beam in BF16 raggiunge il 97,7% su AIME 2026, il 90,6% su GPQA Diamond e l'81,6% su SWE-bench Verified. Le differenze tra BF16, FP8 e NVFP4 restano contenute su molti test, un segnale utile per chi vuole sfruttare formati a precisione ridotta senza perdere troppo. Su tool calling e browsing il comportamento è più disomogeneo: MCP Atlas supera l'80%, mentre AutomationBench si ferma al 39,3% in BF16. Questa dispersione racconta un modello tarato su coding, ragionamento scientifico e orchestrazione di strumenti, non un generalista uniforme.

Per chi osserva il deployment on-premise, Beam rende più netta una separazione che spesso viene confusa: il costo computazionale dell'inference si riduce, ma la soglia di capitale per portare il modello in casa resta alta. La scelta tra BF16, FP8 e NVFP4 non è una decisione puramente tecnica, perché determina quali acceleratori possono servire il modello e quale TCO è realistico raggiungere. I numeri mostrano che la compressione tiene su diversi benchmark, ma non dicono come si comporta su hardware eterogenei o quando il contesto si avvicina davvero al milione di token. Beam è un test interessante proprio per questo: promette di ragionare spendendo meno token, ma il prezzo in memoria non è scontato.