L’ANALISI
Apertus 1.5: cosa viene pubblicato oltre ai pesi
Analisi pratica del rapporto Apertus 1.5: artefatti aperti, multimodalità, contesto 262k, runtime, limiti e checklist per una prova ripetibile.
In breve: La novità utile non è un nuovo file di pesi, ma la catena di evidenze pubblicata intorno ad Apertus 1.5: rapporto tecnico, dati, ricette, checkpoint intermedi ed evaluation card. Questo rende più ispezionabile come il modello è stato costruito e valutato; non rende però economica la riproduzione del training né dimostra da solo qualità e prestazioni sul proprio hardware.
Che cosa cambia il 15 ottobre
Swiss AI separa correttamente due date: i pesi aggiornati sono del 24 luglio, mentre il 15 ottobre arriva il rapporto tecnico con dettagli su training, post-training ed evaluation. Per chi deve decidere se adottare il modello, il delta è soprattutto documentale: ora si possono collegare risultati, configurazioni, dati e checkpoint a una procedura dichiarata.
Che cosa significa “aperto” qui
Il pacchetto comprende pesi Apache 2.0, inventario delle fonti dati, valori dichiarati, ricette e codice di training, mix SFT e preference data, oltre a checkpoint base, SFT, RLVR e DPO. È più di una semplice licenza sui pesi. Resta però una differenza tra ispezionabilità e riproducibilità economica: rifare 17 o 19 trilioni di token richiede risorse fuori scala per un laboratorio piccolo.
Multimodalità e contesto lungo
Apertus usa early fusion: immagini e audio diventano token nella stessa sequenza del testo. Una immagine 512×512 occupa 1.024 token e l’audio 40 token al secondo; l’output resta solo testuale. Il contesto dichiarato arriva a 262.144 token, ma memoria e latenza crescono con la lunghezza e la model card suggerisce di ridurla quando l’hardware non regge.
Runtime: attenzione ai fork
Il modello è eseguibile con vLLM e Transformers, ma al momento della verifica il supporto non è ancora nelle release upstream: la documentazione indica branch fissati e un’immagine container dedicata. Thinking e tool calling sono modalità distinte. Prima di integrare il modello serve quindi bloccare commit, container e parametri, non affidarsi a un comando generico non versionato.
Come leggere le valutazioni
Le evaluation card registrano esecutore, accesso al modello, impostazioni di generazione e semantica delle metriche. È un passo utile per confronti ripetibili, ma i risultati restano prodotti dal progetto e da collaboratori selezionati. Il team stesso dichiara che Apertus 1.5 resta dietro ai modelli open-weight di frontiera: il valore da verificare è trasparenza, controllo e adeguatezza al caso d’uso, non una presunta leadership assoluta.
Condizioni e limitazioni
I pesi 8B e 70B erano già disponibili dal 24 luglio: il delta del 15 ottobre è la documentazione tecnica e riproducibile. L’audio è sperimentale, tool calling e thinking non vanno combinati, l’integrazione richiede ancora fork specifici di vLLM e Transformers e i benchmark del progetto non sostituiscono test locali.
Checklist pratica
- Fissare modello, revisione del runtime e hash dell’immagine container.
- Partire dall’8B con una lunghezza di contesto realistica per RAM e VRAM disponibili.
- Separare tre test: solo testo, immagine più testo, audio più testo.
- Provare thinking e tool calling in run distinti, come richiesto dalla model card.
- Registrare prompt, seed, parametri, memoria, latenza e token al secondo.
- Verificare risposte italiane, citazioni e failure case con un set locale.
- Confrontare i risultati con un modello di riferimento nelle stesse condizioni.