L’ANALISI
Mellum2.1: cosa cambia per i coding agent locali
Analisi di Mellum2.1: pesi open, architettura MoE, coding agent locali, benchmark dichiarati e checklist per una prova controllata.
In breve: Mellum2.1 rende disponibile un worker open e self-hostable per attività di coding agent: conserva l’architettura 12B MoE con 2,5B parametri attivi, ma sostituisce gran parte del post-training con reinforcement learning su ambienti software. Il vantaggio pratico è la possibilità di provarlo come sub-agent locale; i risultati pubblicati restano però vendor benchmark.
Che cosa è stato rilasciato
JetBrains distribuisce Mellum2.1 con licenza Apache 2.0 e checkpoint su Hugging Face. L’architettura resta quella di Mellum2: 12 miliardi di parametri totali, 2,5 miliardi attivi per token e una finestra di contesto dichiarata fino a 131.072 token.
Il delta rispetto a Mellum2
La novità è nel post-training. JetBrains descrive milioni di esecuzioni in sandbox e compiti filtrati di ingegneria software, uso di strumenti, matematica e programmazione competitiva. Il modello viene addestrato a esplorare un repository, applicare modifiche e controllarne l’esito.
Dove può essere utile
Il posizionamento più concreto è come worker veloce dentro un sistema multi-agent: analisi di un test fallito, ricerca della causa, proposta di patch e verifica. Pesi locali e GGUF permettono di mantenere codice e prompt sull’infrastruttura scelta, se anche runtime e strumenti restano locali.
Come leggere velocità e benchmark
JetBrains dichiara throughput quasi doppio rispetto a Qwen3.5-9B sotto carico e un vantaggio di circa 1,6 volte su richiesta singola con multi-token prediction. Sono confronti prodotti dal vendor con configurazioni specifiche: non equivalgono a latenza su workstation né a qualità costante su repository proprietari.
Condizioni e limitazioni
Prestazioni e benchmark sono misurati da JetBrains con il proprio setup, incluso hardware H200 per la velocità. Il modello non è stato provato end-to-end da Radar su repository reali: qualità, memoria e compatibilità con il proprio harness vanno validate prima dell’uso.
Checklist pratica
- Scaricare il checkpoint o una quantizzazione ufficiale e registrare variante, hash e licenza.
- Misurare memoria, token al secondo e tempo al primo token sull’hardware destinato al servizio.
- Preparare un repository usa-e-getta con test riproducibili e permessi minimi.
- Confrontare patch valide, test superati e regressioni contro il modello già in uso.
- Isolare shell, rete e segreti: pesi locali non rendono sicuro l’harness agente.