Guida rapida per Vane (Perplexica 2.0) con Ollama e llama.cpp

Ricerca AI auto-ospitata con LLM locali

Indice

Vane è una delle voci più pragmatiche nel settore della “ricerca AI con citazioni”: un motore di risposta ospitato autonomamente che combina il recupero live sul web con LLM locali o cloud, mantenendo l’intera stack sotto il tuo controllo.

Il progetto era originariamente noto come Perplexica, e il rinominamento in Vane non è solo cosmetico: riflette sia una pulizia del branding che uno spostamento costante dall’essere inquadrato come “un clone” verso l’essere un motore di risposta generale.

laptop-llama-server

Poiché la parte utile dello stack non è solo l’interfaccia utente, ma anche dove risiedono l’inferenza e i dati, questo confronto sull’hosting di LLM nel 2026 riunisce configurazioni locali, self-hosted e cloud, così da poter posizionare Vane accanto ad altri runtime e scelte di deployment.

Questo post si concentra sulle parti che interessano davvero ai lettori tecnici: come funziona il sistema, un’avvio rapido minimale con Docker e come eseguirlo con inferenza locale tramite Ollama e llama.cpp (direttamente o tramite LM Studio). Lungo la strada, ogni argomento FAQ viene risposto in contesto, non relegato in fondo.

Cos’è Vane e come funzionano i motori di ricerca AI

A livello alto, Vane è un’applicazione Next.js che combina un’interfaccia di chat con ricerca e citazioni. I pezzi architetturali fondamentali sono esattamente quelli che ci si aspetterebbe da un moderno motore di ricerca AI: route API per chat e ricerca, un’orchestrazione che decide quando effettuare il recupero e un generatore di risposte consapevole delle citazioni.

Quando invii una query nell’interfaccia, Vane chiama POST /api/chat. Internamente, il flusso di lavoro è deliberatamente strutturato:

  • Classifica prima la domanda per decidere se è necessaria una ricerca e quali helper devono essere eseguiti.
  • Esegue la ricerca e i widget in parallelo.
  • Genera la risposta finale includendo le citazioni.

Quella etichetta di “motore di ricerca AI” è importante, perché questo non è solo un frontend per la chat. La differenza chiave è la generazione aumentata dal recupero (Retrieval Augmented Generation): invece di affidarsi puramente ai parametri dell’LLM, Vane recupera contesto esterno (risultati web e, opzionalmente, file caricati dall’utente) e utilizza quel materiale come substrato di base per la risposta finale. La documentazione cita esplicitamente la ricerca web e la “ricerca nei file caricati dall’utente” come parte della ricerca, con l’uso di embedding per la ricerca semantica sui caricamenti.

Le citazioni non sono un ripensamento. Vane sollecita il modello a citare i riferimenti che ha utilizzato, e poi l’interfaccia rende quelle citazioni accanto alla risposta. Nella pratica, è ciò che separa la ricerca AI “utile” da un generatore di allucinazioni sicuro di sé che si limita ad avere un pulsante di ricerca.

SearxNG si trova sotto lo strato di recupero web per la maggior parte delle configurazioni. SearxNG è un metaricerca gratuito che aggrega risultati da molti servizi di ricerca e, per progettazione, non traccia né profila gli utenti. Questa è una filosofia fondamentalmente diversa dalle API di ricerca a pagamento, che solitamente ti offrono un indice singolo del fornitore e un contratto commerciale sui dati.

Storia da Perplexica a Vane e rinominamento

Perplexica è iniziata come un motore di risposta open-source ospitabile autonomamente ispirato da Perplexity AI. Diverse guide pubbliche descrivono ancora il progetto come “precedentemente noto come Perplexica” e trattano Vane come la continuazione piuttosto che come una forca ostile.

Il rinominamento è stato implementato direttamente nel repository upstream. Nella cronologia dei commit del ramo master, il commit intitolato feat(app): rename to 'vane' appare il 9 marzo 2026 (SHA 39c0f19).

Il “come” è più interessante del titolo. Quel commit di rinominamento non è solo una modifica del README: aggiorna i nomi delle immagini Docker da itzcrazykns1337/perplexica a itzcrazykns1337/vane, regola i percorsi del filesystem del contenitore da /home/perplexica a /home/vane e aggiorna di conseguenza i testi e le risorse del progetto.

Se ti chiedi perché i progetti AI open-source vengono rinominati, Vane è un esempio da manuale dei soliti fattori scatenanti:

  • La vicinanza del nome a un marchio commerciale crea confusione (e talvolta rischi legali).
  • La portata del progetto si espande oltre l’inquadratura originale (da “clone” a “motore di risposta”).
  • Gli artefatti di distribuzione necessitano di un’identità coerente (immagini Docker, documenti, etichette UI).

Inoltre, l’ecosistema non cambia nome dall’oggi al domani. Docker Hub mostra ancora entrambi i repository sotto l’account del maintainer, inclusi itzcrazykns1337/vane e itzcrazykns1337/perplexica. Quindi continuerai a vedere vecchi post sul blog, file compose e riferimenti al registro che usano la denominazione Perplexica anche dopo il rebrand del repository.

Avvio rapido Docker e configurazione di base

Il README ufficiale di Vane è rinfrescantemente diretto: esegui un singolo contenitore e ottieni Vane più un backend di ricerca SearxNG incluso. L’avvio rapido minimale con Docker è il seguente.

docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

Quella immagine è posizionata come la via “che funziona subito” perché include già SearxNG, quindi non hai bisogno di un backend di ricerca esterno solo per testare l’interfaccia. La configurazione avviene nella schermata di configurazione dopo aver aperto l’interfaccia web su http://localhost:3000.

Se esegui già SearxNG (comune nei homelab), l’immagine “slim” di Vane si aspetta che tu la punti a un’istanza SearxNG esterna utilizzando SEARXNG_API_URL. Il README cita anche due aspettative pratiche per le impostazioni di SearxNG: output JSON abilitato e motore Wolfram Alpha abilitato.

docker run -d -p 3000:3000 \
  -e SEARXNG_API_URL=http://your-searxng-url:8080 \
  -v vane-data:/home/vane/data \
  --name vane \
  itzcrazykns1337/vane:slim-latest

Mantenere Vane aggiornato è anche documentato nel repository. Il flusso di lavoro ufficiale di aggiornamento è fondamentalmente tirare l’ultima immagine e riavviare con lo stesso volume, il che preserva le impostazioni.

docker pull itzcrazykns1337/vane:latest
docker stop vane
docker rm vane
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

Una volta che lo hai in esecuzione, Vane può essere utilizzato come scorciatoia per il motore di ricerca del browser puntando un motore personalizzato su http://localhost:3000/?q=%s. Questa è una piccola caratteristica con un impatto sproporzionato se vuoi che la “ricerca AI” sembri una ricerca piuttosto che un’app a cui si visita.

Per l’automazione e l’integrazione, Vane espone un’API. La documentazione descrive GET /api/providers per scoprire provider e modelli configurati, e POST /api/search per eseguire una ricerca con un modello di chat scelto, un modello di embedding, fonti e una modalità di ottimizzazione (optimizationMode: velocità, bilanciato, qualità).

Configurazione LLM locale con Ollama

Vane supporta LLM locali tramite Ollama e provider cloud nella stessa interfaccia, che è l’astrazione corretta se pensi in termini di “connessioni” e “modelli” piuttosto che “fornitori”.

Il problema più comune non è la scelta del modello, ma il networking. Quando Vane viene eseguito in Docker e Ollama viene eseguito sull’host, “localhost” non significa quello che pensi significhi dall’interno del contenitore. Vane documenta URL base specifici per sistema operativo per la connessione a Ollama da un contenitore.

Insidie di connettività con Docker

La sezione di risoluzione dei problemi di Vane raccomanda esplicitamente:

  • Windows e macOS: http://host.docker.internal:11434
  • Linux: http://<private_ip_of_host>:11434

Per Linux, Vane nota anche che Ollama potrebbe essere legato a 127.0.0.1 di default e ha bisogno di essere esposto. Il README suggerisce di impostare OLLAMA_HOST=0.0.0.0:11434 nel servizio systemd e di riavviare il servizio.

Questo si allinea con le proprie variabili di ambiente serve di Ollama, dove OLLAMA_HOST controlla l’indirizzo di binding del server e di default è 127.0.0.1:11434.

Mantieni i modelli caldi e scegli i modelli

Se esegui l’inferenza locale, sentirai i cold start (avvii freddi). Ollama ha due meccanismi correlati per mantenere i modelli caricati:

  • OLLAMA_KEEP_ALIVE come impostazione del server.
  • keep_alive come parametro per richiesta per /api/generate e /api/chat, che sovrascrive il default del server.

Vane ha aggiunto il proprio supporto keep_alive per i modelli Ollama (così l’app può influenzare quanto tempo un modello rimane in memoria). Questa caratteristica appare nelle note di rilascio v1.10.0 di Vane.

La selezione del modello è la parte che si complica troppo su Internet. Per lavori di stile Vane, la divisione più pratica è:

  • Un modello di chat istruito (per sintesi e riassunto).
  • Un modello di embedding per la ricerca di similarità sui caricamenti e sul testo recuperato. La documentazione API di Vane mostra che la richiesta di ricerca sceglie esplicitamente sia un modello di chat sia un modello di embedding.

Ollama stesso supporta flussi di lavoro di embedding e persino la documentazione CLI include un esempio che usa nomic-embed-text per gli embedding.

Questo è anche la risposta alla FAQ sull’esecuzione della ricerca AI localmente senza API cloud: con Vane in Docker, SearxNG locale e Ollama sul tuo hardware, puoi mantenere sia le tue query di ricerca sia i tuoi caricamenti di documenti privati entro il tuo confine di rete. (Se decidi di collegarti a un provider cloud invece, la connessione ovviamente cambia il percorso dei dati.)

Configurazione LLM locale con llama.cpp

Ci sono due modi realistici per abbinare Vane con llama.cpp:

  • Usare LM Studio come livello server (e lasciare che Vane parli con esso).
  • Eseguire il proprio server HTTP di llama.cpp (llama-server) e connettersi tramite un endpoint compatibile con OpenAI.

Vane supporta esplicitamente “Server Locali Compatibili con l’API OpenAI” e cita i requisiti soliti: legarsi a 0.0.0.0 invece che a 127.0.0.1, usare la porta corretta, impostare un nome modello che esista sul server e non lasciare il campo della chiave API vuoto anche se il server non forza l’autenticazione.

LM Studio è rilevante qui perché si trova sopra i backend locali (spesso llama.cpp) esponendo un’API compatibile con OpenAI. Vane v1.12.1 nota specificamente l’aggiunta di un provider LM Studio.

La documentazione di LM Studio elenca gli endpoint compatibili con OpenAI supportati e mostra un esempio di URL base che usa http://localhost:1234/v1 (dando per scontata la porta 1234). Questo è importante perché, dal punto di vista di Vane, è “solo un altro server di stile OpenAI”.

Se preferisci eseguire llama.cpp direttamente, il server HTTP ufficiale di llama.cpp supporta route completi chat, risposte e embedding compatibili con l’API OpenAI, insieme a una lunga lista di funzionalità del server (batching, monitoraggio, uso di strumenti).

Anche se non memorizzi i flag, le parti importanti sono:

  • Il server esiste ed è attivamente documentato.
  • La superficie API è abbastanza compatibile che i client di stile OpenAI possano parlarci, che è esattamente ciò di cui Vane ha bisogno per il suo modello di connessione “compatibile con OpenAI”.

Cosa è stato rilasciato recentemente e cosa sta cambiando ora

Se vuoi capire in cosa Vane è diventato nell’ultimo anno, segui le note di rilascio e la cronologia del ramo master piuttosto che l’hype.

Al 10 aprile 2026 (Australia/Melbourne), l’ultimo rilascio GitHub etichettato visibile nella pagina dei rilasci è v1.12.1 (31 dicembre 2025). Quelle note di rilascio aggiungono un provider LM Studio e correzioni intorno alle chiamate di funzione con provider compatibili con OpenAI e parsing JSON.

I rilasci precedenti delineano gli spostamenti più grandi:

  • v1.11.0 (21 ottobre 2025) ha introdotto una nuova procedura guidata di configurazione e un sistema di configurazione ridisegnato, insieme a un supporto più ampio per i provider e un percorso di installazione Docker a comando singolo. Menziona anche il recupero dinamico dei modelli e vari miglioramenti dell’interfaccia utente e dell’esperienza dello sviluppatore.
  • v1.12.0 (27 dicembre 2025) è un reset architetturale: rimuove LangChain a favore di un’implementazione personalizzata per lo streaming, la generazione e il comportamento specifico del provider. Rinomina anche “provider” in “connessioni”, aggiunge miglioramenti di rendering di codice e UI e sposta più capacità nelle proprie astrazioni del progetto (incluso un miglioramento delle chiamate di funzione rispetto agli approcci di parsing precedenti).
  • In precedenza, v1.10.0 (20 marzo 2025) ha aggiunto il caricamento di file (PDF, TXT, DOCX), aggiunto un parametro keep_alive per Ollama, aggiunto una classe di agente metaricerca per migliorare la manutenibilità e la creazione della modalità focus, e aggiunto la funzionalità di ricerca automatica di immagini e video.

Sul lato del branding, il rinominamento in Vane è atterrato il 9 marzo 2026 nel master (feat(app): rename to 'vane'), aggiornando sia la denominazione della codebase sia gli artefatti Docker.

E il progetto non ha smesso di evolversi dopo il rilascio di dicembre 2025. I commit del ramo master dell'8-9 aprile 2026 includono lavori descritti come “modalità deep research aggiornata, gestione del contesto” e nuove modifiche relative all’esecuzione della ricerca e allo scraping. In altre parole, la parte “motore di ricerca AI” è ancora attivamente iterata, non congelata dietro i tag di rilascio.

Alcuni Riferimenti