Jan.ai: Architettura Locale v2 e v3

La decentralizzazione dell’intelligenza artificiale rappresenta uno dei vettori di innovazione più significativi nell’ambito dei sistemi informativi aziendali.

La necessità di preservare la sovranità dei dati e di garantire la conformità a rigidi quadri normativi, come il Regolamento Generale sulla Protezione dei Dati (GDPR) in Europa, ha guidato lo sviluppo di soluzioni di inferenza interamente locali, eliminando la dipendenza da server esterni e i relativi rischi di esfiltrazione delle informazioni.

In questa traiettoria si colloca Jan.ai, un assistente e infrastruttura di intelligenza artificiale open-source e operante interamente offline, ideato da Menlo Research Pte. Ltd., società con sede a Singapore.

Distribuita sotto licenza Apache 2.0, l’applicazione consente la migrazione dei carichi di lavoro computazionali dai server cloud direttamente all’hardware dell’utente.

La piattaforma si propone come un’alternativa a codice sorgente aperto rispetto alle soluzioni commerciali proprietarie, offrendo un’esperienza d’uso simile a quella di ChatGPT ma incentrata sulla privacy assoluta.

Jan.ai non si limita alla gestione di un’interfaccia di chat desktop, ma si configura come un vero e proprio ecosistema che comprende client web, moduli server per la distribuzione aziendale e interfacce a riga di comando (CLI) per l’automazione dei flussi di lavoro degli sviluppatori.

L’ecosistema favorisce la massima trasparenza, garantendo all’utente il diritto alla verifica del codice e all’audit di sicurezza da parte della community.

Architettura Software, Stack Tecnologico e Compilazione

L’architettura software di Jan.ai si caratterizza per un design modulare altamente efficiente. La codebase dell’applicazione poggia prevalentemente su TypeScript per lo sviluppo della logica applicativa principale, della gestione degli assistenti e dei connettori esterni, mentre Rust costituisce l’ossatura del backend nativo mediante l’adozione del framework Tauri.

Tauri sostituisce i tradizionali ambienti basati su Electron, consentendo una drastica riduzione del consumo di memoria RAM a riposo, tempi di avvio estremamente rapidi e una compilazione nativa ottimizzata per le diverse architetture hardware.

Per gli sviluppatori e i professionisti che necessitano di compilare l’applicazione direttamente dai sorgenti per scopi di personalizzazione o auditing, il sistema richiede requisiti propedeutici specifici.

È necessaria la presenza di un runtime Node.js con versione uguale o superiore alla 20.0.0, accoppiato al gestore di pacchetti Yarn (versione uguale o superiore alla 4.5.3) e all’utilità di build Make (versione uguale o superiore alla 3.81).

Sui sistemi operativi macOS equipaggiati con processori Apple Silicon, è richiesto inoltre l’aggiornamento della MetalToolchain per abilitare l’accelerazione grafica nativa dei flussi di calcolo. La procedura di build prevede l’esecuzione di una sequenza standard di comandi per clonare il repository GitHub ed effettuare il bootstrap completo delle dipendenze:

Bash

git clone https://github.com/janhq/jan
cd jan
git checkout -b DESIRED_BRANCH
make dev

Questa catena di compilazione gestisce autonomamente l’installazione delle dipendenze di progetto, compila i plugin API e avvia l’applicazione desktop all’interno dell’ambiente di sviluppo locale.

Configurazione Hardware, Allocazione delle Risorse e Ottimizzazione

Le prestazioni del motore di inferenza locale di Jan.ai, il quale si appoggia all’implementazione della libreria llama.cpp, sono strettamente correlate alla configurazione e alla disponibilità di memoria di sistema e di calcolo grafico.

Per assicurare un’esecuzione fluida e prevenire il congelamento del sistema operativo durante i carichi di lavoro intensivi, la configurazione ottimale prevede la limitazione dei thread di calcolo della CPU.

Si raccomanda di impostare il numero di thread attivi a un valore equivalente al totale dei core fisici del processore meno due, lasciando così risorse residue sufficienti per la gestione delle attività di background del sistema operativo.

La gestione della memoria RAM deve essere pianificata con rigore in base alla dimensione dei parametri del modello linguistico che si intende ospitare e alla larghezza della finestra di contesto desiderata.

Una stima inadeguata di questi parametri può condurre a fenomeni di saturazione della memoria e conseguente terminazione anomala dei processi. La tabella seguente delinea le specifiche raccomandate e i parametri di ottimizzazione relativi alla gestione della memoria volatile.

L’accelerazione hardware è un requisito fondamentale per l’inferenza in tempo reale, specialmente quando si utilizzano modelli complessi o si integrano agenti autonomi.

Jan.ai supporta un’ampia gamma di backend grafici: l’architettura CUDA per schede video Nvidia (che richiede l’installazione del CUDA Toolkit versione 11.7 o superiore e driver Nvidia versione 470.63.01 o successiva), le librerie Vulkan per schede AMD e Intel Arc, e l’integrazione con Apple Metal per la gestione unificata della memoria su macOS.

Su sistemi Linux, l’introduzione del supporto nativo per il backend AMD ROCm/HIP ha esteso le opzioni di calcolo parallelo anche all’hardware non-Nvidia, garantendo un’alternativa performante nei contesti aziendali basati su piattaforme aperte.

Il Modello Multimodale Jan-v2-VL e l’Automazione Long-Horizon

La transizione verso la seconda generazione dell’ecosistema locale è contrassegnata dal rilascio della famiglia di modelli Jan-v2-VL. Si tratta di modelli di visione-linguaggio (VLM) da 8 miliardi di parametri sviluppati a partire dall’architettura open-source Qwen3-VL-8B-Thinking.

A differenza dei modelli linguistici tradizionali confinati al solo dominio testuale, Jan-v2-VL integra nativamente la comprensione spaziale e visiva con le capacità di ragionamento logico sequenziale, ponendosi come strumento ideale per l’automazione dei processi d’ufficio e il controllo dei sistemi desktop.

L’elemento di maggiore innovazione di Jan-v2-VL risiede nell’efficacia con cui affronta i compiti definiti “long-horizon”, ovvero scenari operativi complessi che richiedono pianificazioni articolate su decine di passaggi consecutivi all’interno di interfacce software reali.

Nei benchmark condotti sull’indicatore Illusion of Diminishing Returns, il modello è in grado di completare flussi di lavoro fino a 49 passaggi all’interno di un singolo turno operativo senza subire degradazioni di performance o deviazioni semantiche (drift), superando in modo sensibile le prestazioni del modello base di partenza.

L’efficacia operativa di Jan-v2-VL poggia su tre pilastri funzionali tra loro sinergici. Il primo è rappresentato dallo screenshot grounding, ovvero la capacità di analizzare visivamente lo stato dello schermo per identificare con precisione millimetrica gli elementi dell’interfaccia grafica e tradurli in coordinate d’azione.

Il secondo pilastro è costituito dal supporto nativo per le chiamate a strumenti (tool calling), che si interfaccia direttamente con i server Model Context Protocol (MCP) per consentire l’interazione programmata con browser e desktop.

Infine, l’architettura implementa meccanismi avanzati di recupero dagli errori (error recovery), mantenendo in memoria gli stati intermedi di esecuzione; questo consente al modello di correggere la propria traiettoria operativa qualora si verifichino risposte impreviste dall’applicazione target, riducendo drasticamente il fenomeno della deriva computazionale che affligge le soluzioni sprovviste di tale modulo.

La variante Jan-v2-VL-max rappresenta la massima espressione computazionale di questa famiglia: basata su un’architettura Mixture of Experts (MoE) da 30 miliardi di parametri, essa consente la gestione di compiti di pianificazione ad elevata complessità strutturale con oltre 130 chiamate a strumenti in un singolo ciclo di lavoro, collocandosi come un diretto concorrente locale di modelli di frontiera proprietari.

L’Architettura dei Modelli Jan-v3 e le Varianti Specializzate

Accanto allo sviluppo dell’ecosistema multimodale v2, Jan.ai ha introdotto la linea di modelli Jan-v3, focalizzata sull’efficienza e sulla riduzione dell’impronta di memoria dei carichi di lavoro locali.

Questi modelli, con un parametrizzazione quantificata in 4 miliardi di pesi, sono realizzati attraverso tecniche di distillazione post-addestramento a partire da modelli “teacher” di dimensioni nettamente superiori.

La distillazione consente di trasferire le capacità logiche superiori e la precisione nel seguire le istruzioni del modello più grande all’interno di una struttura agile, riducendo i costi di calcolo del sistema ospite senza compromettere l’affidabilità delle risposte.

I modelli della serie Jan-v3 integrano una finestra di contesto nativa da 262.144 token, una dimensione eccezionale per la categoria che consente l’elaborazione di interi database di codice o corposi fascicoli documentali direttamente in locale.

La suite v3 si articola in varianti generiche e modelli ottimizzati per compiti specifici, valutati attraverso benchmark industriali rigorosi i cui risultati sono illustrati di seguito.

I dati prestazionali evidenziano come l’opera di ottimizzazione svolta dal team di Menlo Research abbia consentito a Jan-Code-4B di superare sensibilmente il modello di base Qwen3-4B in tutti gli indicatori logici e di programmazione, attestandosi come uno strumento di riferimento per gli sviluppatori che operano in mobilità o su workstation prive di acceleratori grafici di classe server.

In questa generazione si inserisce inoltre la variante Jan-v3.5-4B, un modello che esplora l’integrazione di una spiccata personalità conversazionale definita dal team di sviluppo.

Distaccandosi dal tono formale, asettico e standardizzato che caratterizza la totalità dei modelli commerciali, Jan-v3.5-4B adotta uno stile di scrittura casuale, diretto e realistico, privilegiando risposte concise e auto-ironiche, ed evitando l’uso di formule di cortesia artificiali tipiche dei sistemi di assistenza clienti.

Evoluzione Storica e Cronologia degli Aggiornamenti dell’App

La rapidità di evoluzione dell’applicazione Jan nel corso del primo semestre del 2026 riflette una strategia orientata a colmare il divario con le piattaforme cloud e a consolidare la stabilità dell’infrastruttura locale basata su llama.cpp.

Gli aggiornamenti rilasciati documentano l’introduzione progressiva di funzionalità avanzate per la gestione del contesto, l’integrazione con agenti esterni e la fruizione di formati di output complessi.

L’analisi di questa linea temporale rivela l’attenzione del team di sviluppo verso l’esperienza utente e l’efficienza dei sistemi locali.

L’introduzione della tecnologia Multi-Token Prediction nella release v0.8.0 consente di accelerare la velocità di generazione dell’output testuale su hardware compatibile, mentre l’adozione del caricamento a fasi nella versione v0.8.2 differisce l’esecuzione dei moduli non essenziali a un momento successivo al rendering della prima schermata, abbattendo i tempi percepiti di latenza all’avvio dell’applicazione.

Containerizzazione, Integrazione API ed Esecuzione in Rete

Per l’utenza professionale e per le infrastrutture IT aziendali che desiderano distribuire Jan come servizio condiviso all’interno di reti locali o cluster di calcolo, l’applicazione supporta la containerizzazione nativa tramite Docker.

Questa modalità consente di svincolare l’esecuzione del motore di intelligenza artificiale dall’interfaccia grafica desktop, servendo i modelli in modalità headless.

La configurazione di Docker è strutturata per gestire sia l’inferenza basata su CPU sia l’esecuzione accelerata su GPU abilitando i rispettivi profili all’interno del file di orchestrazione:

Bash

# Per avviare Jan in modalità solo CPU
docker compose --profile cpu up -d

# Per avviare Jan in modalità GPU (richiede driver nvidia-docker2)
docker compose --profile gpu up -d

Nel caso si opti per l’esecuzione con accelerazione grafica su container, è indispensabile mappare correttamente l’immagine base corrispondente alla versione CUDA del sistema ospite, verificandola preventivamente tramite l’utility nvidia-smi per allineare i tag immagine del catalogo NGC di Nvidia.

È importante notare che l’esecuzione in modalità Docker è attualmente indicata per ambienti di sviluppo e test su localhost; le funzionalità di Retrieval-Augmented Generation (RAG) per l’interrogazione di documenti di progetto non sono ancora supportate all’interno del container.

Il server API integrato in Jan.ai, attivo di default sulla porta locale 1337, rappresenta una delle funzionalità più potenti per l’integrazione nei flussi aziendali.

Questo modulo espone un endpoint pienamente compatibile con le specifiche delle API di OpenAI, gestendo in modo trasparente le intestazioni CORS per consentire connessioni sicure da parte di applicazioni web ed estensioni locali.

L’infrastruttura locale può interfacciarsi e scambiare modelli con altri client presenti sulla macchina, inclusi Ollama (attivo sulla porta 11434) e LM Studio (attivo sulla porta 1234), consentendo di utilizzare Jan come frontend grafico unificato per diversi motori di inferenza.

La ricerca web in tempo reale, utile per superare i limiti di aggiornamento temporale dei modelli locali, è implementata nativamente tramite connettori per motori di ricerca focalizzati sull’AI come Exa.

Per abilitarla, è sufficiente inserire la chiave API del fornitore all’interno delle impostazioni dei server MCP e attivare il relativo servizio, permettendo al modello di arricchire il prompt dell’utente con informazioni aggiornate e verificate in tempo reale prima di procedere alla generazione della risposta.

Gestione dei Processi Sottostanti e Risoluzione dei Problemi

Dato lo stato di sviluppo attivo della piattaforma e la complessità intrinseca nell’interazione diretta con le librerie hardware a basso livello, l’utente può imbattersi in anomalie di esecuzione o build danneggiate. La risoluzione di questi problemi richiede una comprensione dei processi che operano in background. Jan.ai si affida a un processo denominato Nitro per l’esecuzione del server locale e la gestione dell’inferenza.

In caso di blocco dell’applicazione o qualora l’inferenza non risponda a causa di conflitti nell’allocazione della memoria GPU, si rende necessario terminare manualmente i processi residui che continuano a occupare le risorse di sistema. Su sistemi Unix-like e macOS, l’utente deve identificare e terminare i processi correlati tramite il terminale:

Bash

ps aux | grep nitro
kill -9 <PID_PROCESSO_NITRO>

Questa procedura consente di sbloccare la VRAM della scheda video senza richiedere il riavvio dell’intero sistema ospite. Qualora l’applicazione presenti comportamenti instabili persistenti dovuti a conflitti di configurazione, è possibile eseguire un ripristino completo dell’installazione seguendo una procedura di pulizia dei file di stato e delle estensioni locali.

Questa operazione prevede l’eliminazione dei file temporanei e delle build residue attraverso il comando make clean, la rimozione delle estensioni non stabili presenti nella cartella utente ~/jan/extensions e la cancellazione manuale della directory di cache dell’applicazione, localizzata sul sistema nel percorso ~/Library/Caches/jan.

Considerazioni Finali sull’Ecosistema Offline

L’evoluzione di Jan.ai testimonia la maturità tecnologica raggiunta dai sistemi di intelligenza artificiale eseguiti in locale.

La transizione dall’inferenza puramente testuale a complessi modelli multimodali di visione e linguaggio come Jan-v2-VL dimostra che l’indipendenza dal cloud non comporta una rinuncia in termini di potenzialità operative o di capacità di automazione.

L’adozione di standard aperti come il Model Context Protocol, la compatibilità drop-in con le API consolidate del settore e la flessibilità della linea di modelli distillati Jan-v3 posizionano l’ecosistema di Menlo Research come un punto di riferimento sia per l’utente comune desideroso di tutelare la propria riservatezza, sia per le grandi organizzazioni che necessitano di integrare flussi agentici intelligenti e sicuri all’interno delle proprie reti protette.