Beam 1.0 su quattro B300: la matematica del serving, e l'affermazione sul throughput che nessuno ha pubblicato

Il numero su cui vale la pena soffermarsi nella release Beam 1.0 di Reflection non è 501 miliardi. È quattro. Un modello con 501,3 miliardi di parametri totali e 23,4 miliardi attivi per token ora entra in un singolo server con quattro GPU NVIDIA B300 su NVLink, e la distanza tra queste due cifre — circa il 4,7 per cento del modello attivo su un dato token — è l'intera ragione per cui un checkpoint di queste dimensioni è scaricabile da chiunque non possieda un cluster. Reflection ha pubblicato i pesi il 16 ottobre 2026 con licenza Apache 2.0, e il materiale di lancio è insolitamente specifico su ciò che serve per servirli: quattro GPU B300 su NVLink per la build NVFP4, otto H200 per FP8 e otto B200 o B300 per BF16. Quella tabella hardware è più interessante della tabella dei benchmark, perché è la parte che un lettore può effettivamente verificare rispetto alla propria scheda di acquisto.

È anche l'elemento che distingue Beam 1.0 dai modelli con cui viene messo a confronto. Kimi K3 e GLM-5.2 vengono erogati tramite API e i loro pesi o non sono pubblici o sono soggetti a un diverso insieme di condizioni; Qwen3.8-Max è proprietario nella fascia di punta. La proposta di Beam è che la metà difficile di questo compromesso — un modello vicino alla frontiera disponibile per il download — è stata rilasciata, e che il costo di erogazione è un rack anziché un data centre.

Che cosa è davvero atterrato il 16 ottobre?

Il post di Reflection "Beam è ora disponibile" è datato 16 ottobre 2026, undici giorni dopo l'annuncio del modello, avvenuto il 5 ottobre. Sono stati rilasciati quattro artefatti, e le precisioni contano più del titolo:

• BF16 — 501,3 miliardi di parametri, 933,81 GiB su disco, 188 shard safetensors. La precisione di riferimento; la prima colonna della tabella di benchmark.

• FP8 — lo stesso numero di parametri in E4M3, 468,72 GiB. Quantizzato con N​VIDIA ModelOpt. Consigliato per Hopper e hardware meno recente.

• NVFP4 — una build packed a 4 bit da 273 GiB. È quella che le guide di serving di Reflection ti indicano di scaricare, e l'unica che gira nativamente su Blackwell senza penalità di dequantizzazione.

• DFlash2 — un drafter di decodifica speculativa da 1,93 miliardi di parametri, pubblicato come repository a sé stante e integrato nei comandi di esempio come set di pesi separato.

L'architettura alla base di questi checkpoint è una miscela sparsa di esperti: 52 livelli, di cui 3 densi e 49 MoE, 256 esperti per livello MoE, attenzione gated grouped-query combinata con la sliding-window attention, e un vocabolario di 152.000 token. Testo in ingresso, testo in uscita, contesto da 1M token sulla model card, 131.072 token di output massimo sull'API. Cutoff delle conoscenze: 30 giugno 2026.

Il valore di throughput che non è presente nella documentazione

Un numero circola insieme a questa release fin dal giorno zero: più di 70.000 token di output al secondo per GPU su Blackwell Ultra. È una cifra attraente e vale la pena essere precisi su dove compaia e dove non compaia. Non compare nel post di lancio di Reflection, né nella model card, né nelle note di rilascio di Hugging Face, né nella documentazione per sviluppatori. Non siamo riusciti a trovarlo in nessuna fonte di prima parte.

Ciò che il materiale del fornitore documenta è relativo, non assoluto. L'unica affermazione di efficienza contenuta nella model card è che Beam «raggiunge una qualità della soluzione comparabile a quella dei principali modelli aperti utilizzando circa 3 volte meno token di ragionamento in fase di inferenza», e il post di lancio inquadra la stessa idea come «più intelligenza per token». L'unico numero di tipo throughput che il rilascio pubblica è un'accelerazione misurata, non una velocità: il drafter DFlash2 aumenta la velocità di decodifica da 1,7× a 3,0× rispetto a Beam da solo, misurato sul checkpoint NVFP4 su quattro B300, con lunghezze di accettazione da 4,11 a 5,88 token su un massimo di otto. Si tratta di un rapporto rispetto alla baseline di Beam stesso, quindi non dice nulla sui token assoluti al secondo per GPU — non risolverà in un senso o nell'altro la questione del valore di 70.000.

C'è un solo segnale indipendente che la tesi sull'efficienza non è puro marketing. Artificial Analysis ha misurato Beam 1.0 a 79M token di output sull'Intelligence Index, rispetto a una mediana di 130M per i modelli con cui viene confrontato — classificato al 10° posto su 46 per quella misura. Si tratta di una terza parte che conta i token generati e trova Beam più parsimonioso della maggior parte del settore, il che è una rivendicazione più debole di un dato di throughput per GPU, e una molto meglio supportata.

Cosa ti danno davvero quattro B300, in termini di memoria

La documentazione di serving è la cosa più utile che Reflection abbia pubblicato, perché risponde a domande che una tabella di benchmark non pone mai. Tre numeri spiccano.

• Impronta della cache KV — le ricette vLLM e N​VIDIA Dynamo predefiniscono entrambe una cache FP8 E4M3 con una dimensione di pagina di 64 token, che la ricetta vLLM indica raddoppiare a circa 14M-28M token di contesto memorizzabile in cache su otto H200 che eseguono il checkpoint FP8. Questo è il numero in base al quale dimensionare un deployment; un piano con tre GPU fallisce molto prima che la cache lo faccia.

• Il checkpoint NVFP4 quantizza solo gli esperti instradati. L'attenzione, gli MLP densi, il router, gli embedding e la testa LM restano in BF16, ed è per questo che il file è di 273 GiB anziché i circa 250 che una passata completa a 4 bit darebbe. Su Blackwell viene eseguito in W4A4; su Hopper, vLLM serve gli esperti FP4 tramite Marlin con attivazioni BF16.

• Il checkpoint NVFP4 su quattro B300 è la configurazione di riferimento, e la recipe SGLang viene distribuita come immagine Docker bloccata con parallelismo tensoriale impostato a 4, il drafter DFlash2 abilitato con block size 8 e la decodifica speculativa configurata insieme alla cache KV FP8.

Esiste anche uno strumento di verifica. Il beam-verifier CLI open source esegue una suite di conformità contro qualsiasi endpoint Beam live — contratto di richiesta, contratto di risposta, protocollo degli strumenti — e poi lo valuta sui principali benchmark, così puoi confrontare la tua distribuzione, o quella di un provider, con i punteggi di riferimento di Reflection. Per un modello la cui tabella di benchmark è interamente dichiarata dal fornitore, distribuire l'harness che consente a un acquirente di riprodurla è un impegno più significativo di qualsiasi singolo numero in quella tabella.

Il supporto ai framework dal giorno zero è l’altra metà della storia del deployment, ed è più ampio di quanto riesca a gestire la maggior parte delle release aperte: Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed e N​VIDIA Dynamo, con ricette passo passo per SGLang, vLLM e TokenSpeed, oltre a un Helm chart per Kubernetes. Sul fronte dell’addestramento, Reflection nomina gli stack con cui ha costruito i workflow — NeMo RL e AutoModel e Megatron Bridge di N​VIDIA, Miles di RadixArk, TRL di Hugging Face, SkyRL di Anyscale e Axolotl — e pubblica i numeri del suo runbook RL invece di una cifra hardware: 10,5K GPU GB300 nell’arco di quattro settimane, oltre 100 milioni di rollout, un contesto massimo di 256K token durante l’addestramento e circa 1,3 miliardi di sandbox.

L'API esiste, e continua a non avere un prezzo

Accanto ai pesi c'è un endpoint first-party su api.reflection.ai con una superficie compatibile con OpenAI e l'ID modello Beam-1.0-501B-A23B. Presenta un contratto documentato: reasoning obbligatorio con livelli di effort max, xhigh, high, medium e low, dove max è quello predefinito; output strutturati e tool calling; rate limit a livello di organizzazione misurati in richieste e token al minuto e per giorno UTC, condivisi tra ogni progetto e chiave, così che aggiungere una chiave non li aumenti; e una risposta 429 che imposta x-should-retry a false una volta esaurita la quota giornaliera, che è il dettaglio che impedisce a un ingenuo ciclo di retry di girare a vuoto fino a mezzanotte.

La documentazione non riporta un prezzo per milione di token, e nemmeno l'annuncio. È proprio questa singola omissione a rendere irrisolvibile per un acquirente l'argomentazione sull'efficienza: un modello che ragiona sempre, usa per impostazione predefinita lo sforzo massimo e dichiara tre volte meno token di ragionamento è una proposta commerciale diversa a un dollaro per milione di token di output rispetto a dieci, e attualmente nessuno al di fuori di Reflection può dire quale delle due sia. L'hosting autonomo elimina del tutto la questione e la sostituisce con un numero in conto capitale, che è almeno un numero calcolabile.

Dove questo lascia un team che vuole provarlo

Beam 1.0 non è una delle nostre route, quindi non possiamo erogarlo per voi, e nulla di quanto scritto qui va inteso come una nostra dichiarazione di disponibilità. Quello che possiamo fare è rendere economica la valutazione. Se la decisione che avete davanti è se spendere un quarto del tempo di ingegneria per un pilot Beam di due settimane, la mossa utile è mantenere la produzione su un modello con una rate card pubblicata e uno storico di servizio mentre il pilot è in corso, e avere già pronto il fallback. OrcaRouter gestisce una sola chiave compatibile con OpenAI su oltre 200 modelli, con il prezzo di listino del fornitore passato tal quale e nulla di aggiunto, così un taglio di prezzo del fornitore arriva sulla vostra fattura lo stesso giorno, e il failover automatico significa che un pilot che si rivela non disponibile il mese prossimo è un cambio di routing anziché una migrazione.

I modelli più vicini a Beam per i carichi di lavoro che prende di mira sono tutti raggiungibili in quel modo. I tre da prendere come riferimento per il prezzo del progetto pilota, dal nostro stesso catalogo:

• GLM-5.2 — contesto da 1.000.000 di token, $1,40 per milione di token di input e $4,40 per milione di output. Il modello rispetto al quale viene misurata la dichiarazione di efficienza di Reflection stessa.

• Kimi K3 — contesto di 1.048.576 token, 3,00 $ per milione di token di input, 0,30 $ per quelli in cache, 15,00 $ di output. Il post di lancio di Reflection ammette che K3 resta avanti in termini di capacità grezza.

• Qwen3.8-Max — contesto da 1.000.000 di token, $2,00 per milione in input e $6,00 in output, la classe da 2.000 miliardi di parametri rispetto alla quale Beam sostiene di avere il suo maggiore vantaggio di efficienza.

Le tre cose da tenere d'occhio

Il primo è il prezzo. Finché Reflection non pubblicherà un listino prezzi, la tesi dell'efficienza resta un'ipotesi sul calcolo più che un fatto sul denaro, e il confronto con GLM-5.2 o Kimi K3 rimane una discussione sulla metodologia.

Il secondo è una misurazione indipendente del throughput. Artificial Analysis attualmente elenca Beam con un Intelligence Index di 30 e nessuna velocità e nessun prezzo, perché registra «Nessuna API pubblicamente disponibile» per il modello. Quando ciò cambierà, la questione del per-GPU otterrà una risposta che non ha avuto origine presso il fornitore.

Il terzo è se il verificatore viene effettivamente utilizzato. Una suite di conformità che nessuno esegue è documentazione; una suite di conformità da cui una dozzina di deployment pubblica risultati è un benchmark. Beam 1.0 ha distribuito lo strumento fin dal giorno zero. Se distribuirà anche i numeri è la parte ancora in sospeso.

Niente di tutto ciò è ipotetico: i fallimenti documentati dell'IA e gli incidenti degli agenti alla base di rilasci come questo sono raccolti in l'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.