La sequenza di sigle racconta da sola la parabola tecnica: 9B Dense, 31B Dense, 35B MoE, 397B MoE. DeepReinforce AI ha rilasciato su Hugging Face la famiglia Ornith-1.0, un quartetto di Large Language Models che copre taglie radicalmente diverse e due filosofie architetturali. I benchmark dichiarati parlano di stato dell'arte, ma accompagnati da una premessa che è anche un avvertimento: «vediamo se tiene». Il richiamo alla verifica indipendente è salutare: in un settore dove le classifiche si gonfiano facilmente, la prova del fuoco arriva soltanto quando la comunità replica i test.

Cosa c'è sotto il cofano? Dense e Mixture of Experts a confronto

Tralasciando le performance promesse e non ancora validate, ciò che colpisce è l'ampiezza dello spettro. Due modelli dense, il 9B e il 31B: l'architettura tradizionale in cui ogni token attiva tutti i parametri, con un costo computazionale che cresce linearmente con la dimensione. Poi due Mixture of Experts: 35B e 397B, dove il forward pass attiva solo un sottoinsieme degli esperti. La logica è quella resa familiare da Mixtral: molti parametri totali, ma un costo di inference per token molto più basso di un dense equivalente.

Il 35B MoE, per esempio, potrebbe attivare qualcosa come 6-8B di parametri per token (la configurazione esatta non è nota), rendendolo competitivo in velocità con un dense molto più piccolo, ma con una capacità di generalizzazione potenzialmente superiore. Il 397B MoE, invece, è una bestia: un modello che per essere servito in self-hosted ha bisogno di infrastruttura multi-GPU e di un'attenzione quasi maniacale alla parallellizzazione, ma potrebbe offrire qualità da laboratorio di frontiera in un contesto controllato dall'organizzazione.

Il nodo hardware: VRAM, parallelismo e scelte di deployment

Per chi opera in regime on-premise o air-gapped, una famiglia così articolata accende un dibattito pratico. Il 9B dense, dopo quantization INT8 o FP8, può girare su una singola GPU consumer con 24 GB di VRAM o su un acceleratore enterprise di classe A10/L4, portando l'inference dentro il perimetro aziendale senza costi proibitivi. Il 31B dense è già su un altro pianeta: senza quantization aggressiva, richiede almeno una A100 da 80 GB, e con una finestra di contesto ampia i requisiti di memoria esplodono ancora più in fretta. I modelli MoE, di contro, offrono un compromesso affascinante: il totale dei parametri è alto, quindi la memoria totale per ospitare il modello rimane notevole, ma l'elaborazione per token attiva meno risorse, consentendo di bilanciare latenza e throughput in modi che un dense non permetterebbe.

Resta il fatto che il 397B MoE, anche se caricato su più GPU con tensor parallelism, ha un TCO che va calcolato con attenzione. L'acquisto di quattro o otto A100/H100, i costi di alimentazione, raffreddamento e manutenzione spostano il baricentro decisionale verso valutazioni di CapEx e OpEx che vanno oltre il semplice dato di performance. È qui che framework come vLLM, TensorRT-LLM, o configurazioni di orchestrazione Kubernetes diventano essenziali per il tuning. AI-RADAR, nel suo verticale /llm-onpremise, fornisce strumenti analitici per confrontare scenari di questo tipo senza piegarsi a semplificazioni.

Il contesto: perché un'altra famiglia di modelli?

Il panorama dei modelli open-weight è affollato. Ci sono le famiglie LLaMA di Meta, Mistral e Mixtral, Qwen, DeepSeek, Phi. In questo mare magnum, la mossa di DeepReinforce AI va letta più come arricchimento che come rottura. La compresenza di quattro taglie e due architetture nello stesso progetto suggerisce un obiettivo: fornire un cantiere sperimentale in cui team diversi possano testare, con lo stesso ecosistema, cosa funziona meglio per il loro use case. Chi fa RAG su documenti aziendali potrà provare il 9B e poi scalare se serve; chi costruisce assistenti conversazionali complessi potrà spingersi fino ai modelli più grandi, sempre mantenendo la sovranità dei dati.

C'è però l'incognita dei benchmark. La sbandierata superiorità sugli score va verificata senza fretta. Spesso i modelli appena usciti brillano sui test più citati (MMLU, HellaSwag, HumanEval) ma deludono su compiti reali o su benchmark di robustezza. La domanda interessante non è tanto se Ornith batte Llama-3 su una tabella, ma se lo scarto è reale in condizioni di deployment concreto: prompt lunghi, recupero di informazioni da knowledge base, latenza sotto carico, resilienza alla deriva dei prompt. Le metriche di laboratorio, da sole, non bastano.

Prospettive: controllo, privacy e l'esca dei modelli grandi

La direzione indicata da rilasci come Ornith-1.0 è chiara: la frontiera dei modelli open si allarga, e con essa la possibilità di portare capacità da centri di ricerca dentro infrastrutture private. Questo cambia i termini del dibattito fra cloud e on-premise. Se fino a ieri rinunciare al cloud significava tagliarsi fuori dai modelli più potenti, oggi l'asticella si sposta. Il 397B MoE non è un giocattolo, ma un artefatto che – con il giusto investimento hardware – può operare interamente su macchine di proprietà, sotto GDPR, senza far transitare dati sensibili oltre il perimetro. La vera partita diventa quella dell'ingegnerizzazione: gestire il serving in modo economicamente sostenibile, manutenere la pipeline, aggiornare i checkpoint, orchestrare l'inference. Non è più solo un problema di ricerca, ma di operations.