SWE-bench: il ranking 2026 dei modelli LLM open-source per il coding

Valutare un LLM con SWE-bench in locale permette di misurare la capacità reale di un modello a pesi aperti di risolvere bug autentici su GitHub, ben oltre i punteggi di HumanEval. SWE-bench si distingue perché impone al modello di esplorare un intero repository, comprendere una segnalazione, modificare più file e superare la suite di test. Questo articolo illustra il funzionamento del benchmark, la variante SWE-bench Verified, i requisiti hardware, i modelli candidati del catalogo e la procedura di esecuzione locale, poi risponde alle domande frequenti di chi usa soluzioni self-hosted.

Capire il funzionamento di SWE-bench

SWE-bench è un benchmark pubblicato nel 2023 dall'Università di Princeton che raccoglie 2.294 problemi GitHub reali tratti da 12 progetti Python popolari (Django, scikit-learn, sympy, matplotlib, ecc.). Ogni compito fornisce al modello un repository allo stato di un determinato commit e la descrizione di un'issue. Il LLM deve produrre una patch (diff) che, applicato, fa passare i test precedentemente falliti senza rompere i test esistenti. Per i dettagli sulla costruzione del dataset, vedi il articolo originale su SWE-bench e il repository GitHub ufficiale.

A differenza di HumanEval che valuta funzioni brevi isolate, SWE-bench misura:

• Comprensione contestuale : leggere un repository con decine di migliaia di righe
• Localizzazione del bug : identificare i file giusti da modificare senza indicazioni esplicite
• Modifica di più file : produrre una patch coerente che non rompa nulla
• Ragionamento a catena lunga : alternare esplorazione, ipotesi, verifica

Un punteggio grezzo del 20 % su SWE-bench corrisponde spesso a un punteggio superiore all'80 % su HumanEval, il che spiega perché molti modelli ottengono risultati eccellenti su HumanEval ma crollano su SWE-bench.

SWE-bench Verified: la versione filtrata

SWE-bench Verified è un sottoinsieme di 500 istanze annotate manualmente da OpenAI in collaborazione con gli autori di Princeton. L'obiettivo: eliminare le attività il cui enunciato è ambiguo, i cui test nascosti sono troppo specifici o la cui patch di riferimento dipende da un contesto non fornito. Dettagli completi sul blog di OpenAI dedicato a Verified.

Per un test locale, SWE-bench Verified è la scelta giusta :

• 500 istanze invece di 2.294: esecuzione realizzabile in pochi giorni su una workstation
• valutazione più affidabile del ragionamento reale del modello
• Confronto diretto con i punteggi pubblicati dai fornitori

L'agente di riferimento più utilizzato è SWE-agent, un sistema che mette a disposizione del LLM un terminale interattivo, consentendogli di modificare file, eseguire comandi ed eseguire test. Un'alternativa popolare è OpenHands, che supporta nativamente i backend compatibili con OpenAI (vLLM, llama.cpp server, SGLang).

Modelli del catalogo adatti al benchmark

L'LLM usato come agente di programmazione deve coniugare un contesto ampio (il framework di esecuzione inserisce stack trace, codice sorgente e cronologia delle azioni) e buone prestazioni nel ragionamento. Ecco i candidati del catalogo ordinati per profilo hardware.

Workstation con una disponibilità di VRAM molto elevata (≥ 400 GB)

• DeepSeek V3.2 (685B, MIT) — VRAM Q4 ~410 GB, ctx 128k. Attuale punto di riferimento tra i modelli a pesi aperti su SWE-bench Verified secondo le valutazioni indipendenti.
• DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB, ctx 128k. Modello di ragionamento a lunga catena, particolarmente adatto alla localizzazione di bug.
• Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB, ctx 256k. Licenza permissiva, interessante per uso commerciale.
• Kimi K2.6 (1000B, Modified MIT) — VRAM Q4 ~600 GB, ctx 256k. Ottimizzato per i workflow agentici secondo Moonshot.

Cluster multi-GPU (140-250 GB)

• Qwen 3 235B-A22B (235B, Apache 2.0) — VRAM Q4 ~142 GB, ctx 131k. MoE con 22B parametri attivi, buon rapporto costo/qualità.
• Llama 4 Maverick 400B (400B, Llama 4 Community) — VRAM Q4 ~240 GB, ctx 1M. Contesto eccezionale per repository di grandi dimensioni.
• GLM-5.1 (744B, MIT) — VRAM Q4 ~445 GB, ctx 200k.

Singola workstation (≤ 80 GB)

• Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 ~48 GB, ctx 262k. Specializzato nella programmazione, eseguibile su una A100 80GB o su due 3090.
• gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB, ctx 128k. Modello di OpenAI pubblicato con pesi aperti.
• Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB, ctx 256k.

Per un confronto dettagliato nell'ambito della programmazione, vedi Qwen3-Coder vs DeepSeek V3.2 e la pagina Migliore LLM per il codice.

Tokens/sec e impatto sulla durata dell'esecuzione

Un'esecuzione completa di SWE-bench Verified consuma tra 500 milioni e 2 miliardi di token a seconda dell'ambiente di esecuzione (harness) e del numero di tentativi consentiti. Il throughput in token/sec determina quindi direttamente la durata del benchmark.

Stime indicative (da confermare sulla tua configurazione) :

• DeepSeek V3.2 su 8×H100 80GB in Q4: ~25 token/sec in generazione, run Verified stimato tra 5 e 8 giorni
• Qwen 3 235B-A22B su 4×H100: ~40 token/sec in Q4 (il MoE con 22B di parametri attivi aiuta), durata stimata dell'esecuzione da 3 a 5 giorni
• Qwen3-Coder-Next 80B-A3B su 2×A100 80GB: ~60 token/sec in Q4, durata stimata dell'esecuzione da 2 a 3 giorni
• gpt-oss 120B su 1×H200 141GB in Q4: ~35 token/sec, durata stimata dell'esecuzione da 3 a 4 giorni

Il contesto effettivo conta quanto la velocità bruta: SWE-agent inserisce regolarmente da 30k a 60k token nel prompt per ricostruire lo stato del repository. Un modello limitato a 32k di contesto è poco adatto; punta ad almeno 128k. Vedi anche il guida alla VRAM per livello di quantizzazione per regolare il tuo budget di memoria.

Procedura di esecuzione locale

Ecco una procedura semplificata per una configurazione rigorosamente self-hosted.

1. Preparare l'ambiente Docker : SWE-bench Verified richiede immagini Docker per progetto (Django, sympy, ecc.) per isolare l'esecuzione dei test. Prevedi 80 GB di disco per le immagini ufficiali pubblicate dai maintainer.

2. Avviare un server di inferenza compatibile con OpenAI : con vLLM o llama.cpp in modalità server, esponi il tuo modello su localhost:8000/v1. Per Qwen3-Coder-Next in Q4 su 2×A100, un comando vLLM tipico imposta --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.

3. Clonare SWE-agent e configurare l'harness in modo che punti all'endpoint locale. Il file di configurazione accetta api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.

4. Avviare un run di calibrazione su 10-20 istanze per verificare che la formattazione delle azioni sia rispettata. Molti modelli a pesi aperti falliscono qui perché inventano tag XML che il sistema di valutazione non riconosce.

5. Esecuzione completa : 500 istanze, diversi giorni, registrare sistematicamente le patch generate per l'analisi post-mortem.

6. Invio facoltativo au leaderboard ufficiale per confronto pubblico.

Suggerimento pratico: limita il numero di azioni per istanza (50-75) per evitare che un modello entri in un ciclo infinito che consuma il tuo budget dei token.

Interpretazione dei risultati

Un punteggio grezzo su SWE-bench Verified va interpretato in termini relativi, non assoluti.

• < 10 % : il modello non comprende il formato di azione dell'agente, o il suo contesto è troppo breve
• 10-25 % : livello discreto per un modello open-weights generalista
• 25-50 % : livello atteso di un modello specializzato in ragionamento (DeepSeek R1 671B, Kimi K2.6)
• > 50 % : livello di frontiera, raggiunto dai migliori modelli proprietari

Oltre al punteggio, guarda la distribuzione dei fallimenti : test che vanno in timeout, patch che non si applicano, file modificati al di fuori dell'ambito previsto. Questa analisi rivela spesso che il modello è limitato non dal suo ragionamento, ma dall'ambiente di esecuzione (harness), con la dimensione della finestra e il parsing delle azioni. Per approfondire la selezione di un modello per agenti, consulta la guida LLM per agenti.

FAQ

Q: SWE-bench o SWE-bench Verified per un primo test?

Verified, senza esitazione. Le 500 istanze sono annotate manualmente, le ambiguità vengono eliminate e il tempo di esecuzione rimane ragionevole su una singola workstation. SWE-bench completo (2.294 istanze) contiene compiti definiti male che penalizzano ingiustamente i modelli. Verified offre anche un confronto diretto con i punteggi pubblicati dai fornitori di modelli proprietari.

Q: Quale quantizzazione scegliere per preservare il punteggio nelle attività di programmazione?

Q4_K_M (GGUF) o AWQ 4-bit riducono tipicamente di 1 a 3 punti il punteggio SWE-bench rispetto al FP16, cosa accettabile. Evita Q3 e Q2 sui modelli di ragionamento, dove la perdita diventa significativa. Se la tua VRAM lo permette, Q5_K_M o Q8 offrono un migliore rapporto. Vedi il confronto sulla quantizzazione GGUF vs AWQ.

Q: Serve un modello "coder" specializzato o uno generale?

Entrambi i profili funzionano. I modelli specializzati nella programmazione come Qwen3-Coder-Next 80B-A3B eccellono nella generazione di patch, ma i modelli di ragionamento generalisti come DeepSeek R1 671B sono spesso superiori nell'individuazione dei bug e nella pianificazione in più fasi, che incidono maggiormente sul costo di un compito SWE-bench.

Q: È possibile eseguire SWE-bench Verified su una sola RTX 4090?

Difficile. 24 GB di VRAM limitano la scelta a modelli ≤ 30B in Q4, e questi modelli generalmente non superano il 10% su Verified per capacità di ragionamento insufficienti. Puoi usarlo per validare la tua pipeline con un modello leggero come Qwen3-Coder-Next con offload parziale sulla CPU, ma punta piuttosto a 2×3090 o 1×A100 80GB per un risultato utilizzabile.

Q: Quanti token consuma un run completo?

Stimato tra 500 milioni e 2 miliardi di token secondo il framework (SWE-agent, OpenHands, custom) e il numero massimo di azioni autorizzate per istanza. Con un budget di 50 azioni per istanza e un contesto medio di 30k token, considera circa 1 miliardo di token per 500 istanze. Più il modello "pensa" in catena (stile R1), più salgono i costi dei token.

D: I risultati locali sono comparabili ai punteggi della classifica?

Sì, a condizione di utilizzare l'harness ufficiale, la stessa versione del dataset e di rispettare il protocollo di invio (una sola patch per istanza, nessun nuovo tentativo con un oracolo). Qualsiasi modifica all'harness o al prompt di sistema deve essere documentata. Il leaderboard SWE-bench accetta l'invio di risultati ottenuti in modalità self-hosted e verifica la riproducibilità.

Conclusione

Eseguire in locale un benchmark SWE-bench su un LLM resta la prova più significativa per distinguere un modello di coding a pesi aperti da uno che ottiene semplicemente buoni risultati su HumanEval. Con SWE-bench Verified, una workstation con 2×A100 o 4×H100 e un modello adatto (Qwen3-Coder-Next, DeepSeek V3.2 o gpt-oss 120B), un'esecuzione realistica può essere completata in pochi giorni. Per calibrare la tua configurazione prima di avviare il benchmark, usa il configuratore di quelllm.fr o sfoglia il catalogo completo.