Un modello con i pesi scaricabili non diventa automaticamente open source. La differenza sembra terminologica finché un’azienda non deve modificare il modello, distribuirlo in un prodotto, verificare come è stato costruito o rispettare una licenza con condizioni commerciali. A quel punto cambia il rischio del progetto, non l’etichetta.

Il lancio di Muse Spark Open da parte di Meta, il 15 ottobre 2026, rende il confronto concreto. Meta lo definisce correttamente open-weight: pubblica i pesi e consente di eseguire e personalizzare il modello, ma applica una licenza propria. Il criterio utile per una PMI non è quindi «posso scaricarlo?». È: «quali libertà tecniche e contrattuali mantengo quando il progetto passa dal test alla produzione?».

Open-weight: accesso al modello, con condizioni

Muse Spark Open è un modello multimodale Mixture-of-Experts da 816 miliardi di parametri totali, con 42 miliardi attivi per token e una finestra di contesto da un milione di token. Meta distribuisce i pesi e documenta l’uso con framework come MLX, vLLM, SGLang, Transformers e llama.cpp. Questo offre un vantaggio reale: il team può eseguire il modello sulla propria infrastruttura, misurarlo sui dati interni e adattarlo senza dipendere da una sola API.

Accesso ai pesi, però, non significa assenza di vincoli. La Muse Model License consente uso, copia, modifica, fine-tuning, distillazione e distribuzione, ma richiede di conservare licenza e Usage Policy e di mostrare l’attribuzione «Built with Muse Spark Open». Per chi offre modelli come servizio e supera 20 milioni di dollari di ricavi lordi aggregati in dodici mesi consecutivi è previsto un accordo separato con Meta. La soglia non riguarda la tipica PMI, ma dimostra che la libertà dipende dal contratto.

Open source: conta ciò che puoi ricostruire

La Open Source AI Definition 1.0 dell’Open Source Initiative usa un criterio più ampio. Un sistema deve poter essere usato, studiato, modificato e condiviso per qualsiasi scopo. Per rendere effettive queste libertà non bastano i parametri finali: servono informazioni sufficienti sui dati, il codice di training e inferenza e i parametri del modello.

Qui sta la separazione operativa. Un modello open-weight permette di ispezionare e modificare il risultato dell’addestramento. Un sistema open source mira a rendere comprensibile anche il processo che lo ha prodotto. Non significa che ogni azienda debba riaddestrare un modello da zero. Significa che audit, portabilità e sviluppo di derivati non dipendono solo da ciò che il fornitore decide di pubblicare.

Primo criterio: velocità contro verificabilità

L’open-weight vince spesso nel tempo di adozione. Il modello è disponibile, ha una toolchain pronta e può essere provato dietro un endpoint compatibile con i workflow esistenti. Per una web agency significa collegarlo a un ambiente di staging, misurare qualità e latenza su task reali e sostituire il provider senza riscrivere tutta l’automazione.

Il limite emerge durante un audit. Vedere i pesi non spiega in modo completo provenienza e selezione dei dati, filtri, iperparametri e decisioni prese durante il training. Un progetto realmente open source offre più materiale da verificare, ma richiede anche competenze per leggerlo. Il vantaggio non è «fidarsi meno»: è poter controllare di più.

Secondo criterio: costo e responsabilità

Scaricare i pesi non rende economica l’inferenza. La model card di Muse Spark Open indica almeno 700 GB di VRAM per la versione NVFP4 e 2 TB per BF16; la configurazione Apple documentata usa due Mac Studio M5 Ultra. Per la maggior parte delle PMI, quindi, open-weight descrive una facoltà tecnica, non un acquisto sensato. Un’API ospitata resta il modo più rapido per validare il caso d’uso.

Con l’infrastruttura propria sparisce parte del costo per chiamata, ma arrivano aggiornamenti, monitoraggio, controllo accessi, capacità, incident response e guardrail. La model card di Meta raccomanda esplicitamente protezioni di sistema adatte al caso d’uso. Il self-hosting sposta la responsabilità: non la elimina.

Cosa cambia per WordPress e automazioni

Su WordPress la licenza del modello e la licenza del plugin sono due piani distinti. Integrare un modello open-weight in un plugin GPL non rende automaticamente aperto il modello, né autorizza a ridistribuirne i pesi. Prima di impacchettare un servizio AI dentro un plugin commerciale bisogna verificare distribuzione, attribuzione, Usage Policy e trattamento dei derivati.

Nel workflow quotidiano partirei da un’API o da un endpoint isolato, con credenziali fuori dal repository, log minimizzati e output sottoposti a validazione. Per contenuti e aggiornamenti del sito manterrei staging, revisione umana e permessi WordPress limitati: è lo stesso principio del buffer di approvazione prima dell’invio. Un modello eseguito localmente non deve ottenere automaticamente il diritto di pubblicare.

Per dati sensibili, il controllo va esteso a prompt, cache, telemetria, backup e strumenti richiamati dall’agente. «Locale» descrive dove gira l’inferenza; non certifica da solo privacy, sicurezza o conformità. Prima del deployment serve quindi la stessa disciplina usata per valutare self-hosting e API AI: threat model, budget, fallback e una via di uscita dal fornitore.

La scelta netta per una PMI

Sceglierei un modello open-weight quando prestazioni e disponibilità sono già dimostrate sul caso d’uso, la licenza è compatibile con il prodotto e il team vuole controllare inferenza o fine-tuning. Non lo chiamerei open source nei documenti commerciali: precisione tecnica e contrattuale evitano promesse sbagliate ai clienti.

Preferirei invece un sistema conforme ai principi open source quando il vantaggio competitivo dipende da redistribuzione, audit profondo, modifiche durature o indipendenza dalla politica di un singolo vendor. Costa più lavoro iniziale, ma riduce l’incertezza strutturale.

La mia take è semplice: per una PMI i pesi aperti sono un’opzione di deployment, mentre l’open source è una strategia di controllo. Se il progetto è ancora un prototipo, ottimizza il tempo e valida il valore. Se deve diventare infrastruttura, valuta prima licenza, materiali disponibili e piano di uscita; il nome del modello viene dopo.

Fonti