Proudly debugging the system since 1981

Tag: llm

OpenHuman: promesse grandi, prova sul campo deludente

Ho provato OpenHuman con l’idea di testare un progetto che, sulla carta, sembra voler portare gli agenti AI locali un passo più in là. Il risultato, però, è stato molto meno entusiasmante del racconto che accompagna il repository: installazione rapida, avvio instabile, integrazioni confuse e, alla fine, nessuna esperienza davvero solida da portare a casa.

La prova più interessante non è stata nemmeno il primo avvio fallito su Fedora in VM, ma il confronto tra ambienti diversi. Su una macchina fisica Windows con GPU, OpenHuman parte; appena si entra nel flusso di configurazione, però, emergono subito domande poco rassicuranti: login cloud richiesto, collegamento Gmail mediato da un servizio terzo, e una catena di dipendenze che rende il concetto di “locale” molto più sfumato di quanto il marketing lasci intendere.

Un progetto che promette molto

OpenHuman si presenta come un assistente personale AI locale, capace di integrarsi con servizi esterni, gestire memoria e collegarsi a modelli LLM sia in locale sia in cloud. Il pitch è forte: un agente “human-centric”, pronto a conoscersi in pochi minuti e a diventare parte del flusso di lavoro quotidiano.

Ed è proprio qui che nasce il problema. Più la promessa è ambiziosa, più ci si aspetta che il setup sia semplice, trasparente e affidabile. Invece la mia esperienza è stata l’opposto: ogni passo sembrava introdurre un nuovo livello di complessità, spesso non spiegato bene all’utente.

Fedora in VM: crash, errori e packaging fragile

Il primo test è stato su Fedora in macchina virtuale. Qui OpenHuman ha mostrato subito il suo lato più fragile. L’installazione è partita velocemente, ma all’avvio il programma non è riuscito a completare il bootstrap in modo stabile. I log hanno iniziato a restituire errori diversi a ogni tentativo, e questo è già di per sé un pessimo segnale.

Tra i messaggi più significativi c’erano:

textVMware: No 3D enabled

e soprattutto:

textError initializing NSS with a persistent database
version `NSSUTIL_3.108' not found
FATAL: nss_error=-5925

In pratica, il pacchetto distribuiva librerie incompatibili con quelle presenti sul sistema. Il risultato non era solo un crash, ma un crash dovuto a un conflitto abbastanza banale da sembrare quasi un errore di packaging elementare. Ho provato anche a forzare l’esecuzione con estrazione manuale dell’AppImage, variabili ambientali diverse e disabilitazione della GPU, ma senza successo.

A quel punto il problema non era più il singolo workaround: era il fatto che il software, su una configurazione abbastanza comune come Fedora in VM, falliva in modo ripetuto e poco affidabile.

Windows con GPU: parte, ma non convince

Su una macchina fisica Windows con GPU, OpenHuman si installa e si avvia. Questo però non ha risolto il mio giudizio, anzi lo ha reso più netto. La prima sorpresa è stata la richiesta di un login cloud già al primo avvio, cosa che stride parecchio con l’immagine di applicazione locale e privacy-oriented.

Poi è arrivata la richiesta di collegare Gmail attraverso un target chiamato Composio. Il problema non è solo tecnico, ma concettuale: non viene spiegato chiaramente perché un software che si presenta come locale debba passare da una terza parte esterna per accedere alle mail. Per me questa è una soglia di fiducia importante, e senza una spiegazione trasparente il risultato è un semplice “no”.

Skip sì, utilità poca

C’è un pulsante tipo “skip for now”, quindi in teoria si può andare avanti anche senza concedere tutto subito. In pratica bisogna insistere un po’, ma alla fine si entra davvero nell’app.

Il punto è un altro: se rifiuti di dare accesso a terze parti, OpenHuman resta davvero utile? Questa è la domanda centrale. Perché le funzioni più interessanti sembrano vivere proprio nel punto di incontro tra app locale, account cloud e servizi esterni. Se togli quella parte, resta un guscio molto meno significativo rispetto a quanto il progetto promette.

Ollama, Open WebUI e OpenRouter: altre prove fallite

A questo punto ho provato a portare il tutto sul terreno più favorevole possibile: accesso LLM locale via Ollama, poi Open WebUI come eventuale router/proxy, e infine OpenRouter per testare anche una strada cloud.

Il risultato è stato sempre negativo. Con Ollama non arrivava nessuna risposta in chat e ollama ps non mostrava modelli caricati. Con Open WebUI, usando impostazioni che con altre applicazioni funzionano correttamente, il backend restava silenzioso. Con OpenRouter non è cambiato nulla: le richieste non apparivano neppure nei log.

Questo è stato probabilmente il segnale più chiaro di tutti. Non si tratta di un singolo provider da sistemare o di una configurazione da rifinire. Il problema sembra stare nel modo in cui OpenHuman orchestra il tutto: integrazione, routing, backend, richieste. Se la pipeline non produce neppure tracce nei log, la sensazione è che la superficie sia più avanzata della sostanza.

Perché tante stelline?

La domanda, a questo punto, viene naturale: come fa un software così approssimativo a ottenere tante stelline su GitHub?

La risposta probabilmente non è misteriosa: oggi molti progetti AI vendono prima l’idea e solo dopo il prodotto. Bastano un README convincente, una roadmap ambiziosa, qualche schermata accattivante e un paio di video ben fatti per generare entusiasmo. In molti casi il pubblico non prova davvero il software in scenari normali, oppure lo fa per pochi minuti in condizioni ideali.

OpenHuman mi sembra rientrare proprio in questa categoria: molto forte sul piano narrativo, molto più debole nella prova concreta. E quando il marketing corre parecchio avanti rispetto alla maturità reale del codice, le stelline diventano un indicatore meno affidabile di quanto sembri.

Verdetto attuale

Per ora la valutazione è negativa. Non perché il progetto sia “senza idea”, ma perché l’idea è venduta come se fosse già matura, mentre nella pratica l’esperienza è fragile, poco trasparente e inadatta a un uso sereno.

Il test su Fedora in VM è fallito. Il test su Windows è partito ma ha introdotto dubbi sostanziali sulla privacy e sulle dipendenze cloud. I tentativi con Ollama, Open WebUI e OpenRouter non hanno migliorato il quadro. Il risultato complessivo è un software che promette molto, ma che al momento convince poco.

Disinstallerò OpenHuman e disconnetterò l’account. Per ora, almeno nel mio uso, resta un progetto interessante da osservare, ma non ancora uno strumento davvero affidabile.

Come ho configurato un assistente vocale locale con Anker PowerConf su Home Assistant OS

Ciao! Dopo un lungo percorso di test e configurazione, ho finalmente un assistente vocale locale funzionante sul mio Raspberry Pi con Home Assistant OS, usando l’Anker PowerConf come speakerphone USB. Wake word “Hey raspy”, voce italiana “Riccardo low” e trascrizione Whisper locale (lenta ma gratuita). Ecco il mio viaggio, strumenti usati, problemi risolti e risorse.

Strumenti utilizzati

  • Hardware: Anker PowerConf (speaker + microfono USB), Raspberry Pi (HA OS 2026.2.1).
  • Software:
    • Assist Microphone (add-on principale per input/output audio).
    • openWakeWord (wake word “Hey raspy”).
    • Wyoming Faster Whisper (STT locale).
    • Piper TTS (“Riccardo low”).

Config Assist Microphone finale:​

textsound_enabled: true
noise_suppression: 5
auto_gain: 3
mic_volume_multiplier: 3
sound_volume_multiplier: 1
debug_logging: true

Passi della configurazione

  1. PowerConf USB: Riconosciuto come alsa_input.usb-Anker_PowerConf.mono-fallback / alsa_output.usb-Anker_PowerConf.analog-stereo (ha audio info).
  2. Add-on installati:
    • openWakeWord.
    • Faster Whisper.
    • Piper TTS.
    • Assist Microphone (input/output PowerConf).
  3. Pipeline (Impostazioni → Assistenti vocali):
    • Wake word: openWakeWord → “Hey raspy”.
    • STT: Faster Whisper.
    • TTS: Piper → “Riccardo low”.
  4. Test: “Hey raspy, che ora è?” → wake word, trascrizione, TTS dal PowerConf.

Difficoltà e soluzioni

  • PowerConf riconosciuto ma ALSA vuoto (arecord -l vuoto): sudo alsa force-reload + restart PipeWire. Confermato con pactl list sources short.
  • openWakeWord instabile (1/20): YAML config: textthreshold: 0.2 trigger_level: 1 debug_logging: true
    • Assist Microphone auto_gain: 3, mic_volume_multiplier: 3 → ~70-80% affidabile.
  • Errore “assistente non connette a HA”: Impostazione corretta URL di Home assistant in Configurazione → Rete
  • Whisper lento (10-20s): Funziona locale; opzione futura Whisper Cloud.

Risorse utili

Funziona per comandi base, wake word migliorato ma non perfetto. Whisper locale gratuito ma lento.
L’ agente di conversazione e’ stato realizzato con Extended OpenAI Conversation, una estensione disponibile su HACS che permette di usare LLM di altre provider diversi da OpenAI. La scelta e’ stata per un proxy OpenWebUI che a sua volta rimanda a Groq.

Penso passero a Whisper cloud in quanto le limitate risorse del raspberry permettono di far girare solo un modello piccolo (tiny e small.int8) che non solo e’ lento ma anche impreciso, specie con la lingua italiana per la quale non e’ disponibile un modello specifico ma si deve usare il modello internazionale.

LLaMA Factory: La Soluzione Unificata per l’Ottimizzazione di Modelli LLM

Nel mondo dell’intelligenza artificiale, i grandi modelli linguistici (LLM) hanno rivoluzionato il modo in cui interagiamo con la tecnologia. Tuttavia, il loro potenziale si svela solo quando vengono addestrati in modo mirato a specifiche applicazioni. Ecco che entra in gioco LLaMA Factory, un progetto open source che semplifica e ottimizza il processo di fine-tuning di oltre 100 modelli LLM e VLM (Vision-Language Models). Con il suo approccio unificato, LLaMA Factory si presenta come una soluzione versatile per sviluppatori, ricercatori e aziende che desiderano sfruttare al massimo le capacità dei modelli linguistici.


Cos’è LLaMA Factory?

LLaMA Factory è un framework open source progettato per semplificare e accelerare il processo di fine-tuning di modelli linguistici di grandi dimensioni. Sviluppato da un team di esperti, il progetto è stato presentato al ACL 2024 e si distingue per la sua capacità di supportare una vasta gamma di modelli, da LLaMA a Qwen, da Mistral a DeepSeek, e non solo. LLaMA Factory unifica diverse metodologie di addestramento, come il fine-tuning supervisionato, la modellazione delle ricompense e le tecniche di ottimizzazione avanzate, rendendo il processo di personalizzazione dei modelli più accessibile e efficiente.

Il framework è progettato per adattarsi a diverse esigenze: che si tratti di un’azienda che desidera creare un modello specializzato per il supporto clienti o di un ricercatore che vuole esplorare nuove tecnologie, LLaMA Factory offre strumenti flessibili e potenti.


Le Caratteristiche Chiave di LLaMA Factory

LLaMA Factory si distingue per una serie di funzionalità che lo rendono unico nel panorama degli strumenti per il fine-tuning dei modelli LLM. Ecco le sue principali caratteristiche:

  1. Supporto per 100+ Modelli LLM e VLM
    LLaMA Factory supporta una vasta gamma di modelli, tra cui LLaMA, LLaVA, Mistral, Qwen, DeepSeek, Phi, GLM, e molti altri. Questo rende il framework adatto a diverse applicazioni, da compiti di comprensione del linguaggio a compiti multimediali come l’analisi di immagini o video.
  2. Metodi di Addestramento Integrati
    Il framework include diverse tecniche di fine-tuning, tra cui:

    • Fine-tuning supervisionato
    • Modellazione delle ricompense (Reward Modeling)
    • PPO (Proximal Policy Optimization)
    • DPO (Direct Preference Optimization)
    • KTO (Knowledge Transfer Optimization)
    • ORPO (Optimizing Reward with Preference Optimization)
      Questi metodi permettono di adattare i modelli a specifiche esigenze, come la generazione di testi, il ragionamento logico o l’interazione con utenti.
  3. Ottimizzazione delle Risorse
    LLaMA Factory supporta diverse strategie per ridurre il carico computazionale, come:

    • LoRA (Low-Rank Adaptation)
    • QLoRA (Quantized LORA)
    • GaLore, BAdam, APOLLO, DoRA
      Queste tecniche permettono di addestrare modelli su hardware meno potente, riducendo i costi e il tempo di elaborazione.
  4. Strumenti per la Gestione degli Esperimenti
    Il framework integra strumenti per il monitoraggio e la gestione degli esperimenti, come:

    • LlamaBoard
    • TensorBoard
    • WandB (Weights & Biases)
    • MLflow
      Questi strumenti aiutano a tracciare i progressi, confrontare i risultati e migliorare la produttività del processo di addestramento.
  5. Interfaccia Utente e CLI Zero-Code
    LLaMA Factory offre un’interfaccia web (LlamaBoard) e un CLI (Command Line Interface) che permettono di eseguire il fine-tuning senza codice, rendendo il processo accessibile anche a chi non ha esperienza avanzata in programmazione.
  6. Supporto per Inference Rapida
    Il framework include strumenti per l’inference veloce, come l’API OpenAI-style e il supporto per vLLM, che permettono di deployare i modelli in modo efficiente.

Perché Scegliere LLaMA Factory?

LLaMA Factory si distingue per la sua flessibilità, potenza e facilità d’uso. Ecco i vantaggi principali:

  • Unificazione di Metodi e Modelli: Riduce la complessità di gestire diversi framework e modelli, concentrando l’attenzione sulle esigenze specifiche del progetto.
  • Ottimizzazione delle Risorse: Grazie alle tecniche di quantizzazione e adattamento a basso rango, permette di addestrare modelli su hardware limitato.
  • Supporto per Task Complessi: Dalla comprensione del linguaggio ai compiti multimediali, LLaMA Factory è adatto a qualsiasi applicazione.
  • Community e Documentazione: Il progetto ha una documentazione completa e una comunità attiva, con blog, tutorial e esempi pronti all’uso.

Come Iniziare con LLaMA Factory

LLaMA Factory è facile da installare e usare, grazie alla sua struttura modulare e alla documentazione dettagliata. Ecco i passaggi principali per iniziare:

  1. Installazione
    Il framework può essere installato tramite pip o Docker. Per l’installazione tramite pip:

    git clone --depth 1 https://github.com/hiyouga/LLaMA-Factory.git  
    cd LLaMA-Factory  
    pip install -e ".[torch,metrics]" --no-build-isolation

    Per l’installazione Docker, si possono utilizzare le immagini preconstruite su Docker Hub.

  2. Preparazione dei Dati
    LLaMA Factory supporta diversi formati di dati, tra cui dataset su Hugging Face, ModelScope o cloud storage. È possibile specificare il percorso dei dati direttamente nel codice.
  3. Fine-Tuning
    Il framework permette di eseguire il fine-tuning tramite CLI o interfaccia web. Ad esempio, per eseguire un fine-tuning con LoRA:

    llamafactory-cli train examples/train_lora/llama3_lora_sft.yaml

    L’interfaccia web (LlamaBoard) permette di monitorare in tempo reale l’addestramento e di visualizzare i risultati.

  4. Deploy e Inference
    Dopo il fine-tuning, i modelli possono essere deployati tramite API OpenAI-style o vLLM per l’inference veloce.

Supporto per Modelli e Dataset

LLaMA Factory supporta una vasta gamma di modelli, tra cui:

  • LLaMA, LLaVA, Mistral, Mixtral-MoE, Qwen, DeepSeek, Phi, GLM, Gemma, ChatGLM
  • Modelli Vision-LLM: LLaVA-1.5, LLaVA-NeXT, LLaVA-NeXT-Video, InternVL, etc.

I dataset supportati includono:

  • Dataset per fine-tuning supervisionato: Alpaca, ShareGPT, etc.
  • Dataset per modellazione delle ricompense: Human Feedback, etc.
  • Dataset per compiti multimediali: ImageNet, COCO, etc.

Conclusione

LLaMA Factory rappresenta un passo avanti nella personalizzazione e ottimizzazione dei modelli linguistici. Con la sua capacità di unificare metodi, modelli e risorse, il framework si distingue come una soluzione versatile per sviluppatori, ricercatori e aziende. Che si tratti di addestrare un modello per un’applicazione specifica o di esplorare nuove tecnologie, LLaMA Factory offre strumenti potenti e accessibili.

Se sei interessato a esplorare le potenzialità di LLaMA Factory, visita il sito ufficiale o segui il blog per rimanere aggiornato sulle ultime novità e tutorial.

LLaMA Factory: perché il fine-tuning non deve mai essere complicato.

Workflow AI, un altro caso d’uso

Credo che sta cosa mi stia sfuggendo di mano. Ho messo insieme un po’ tutto. Riconoscimento vocale, chatbot potenziato con rag, embedding, sintesi della risposta e sintesi vocale in uscita.

Risultato: una assistente personale a portata di messaggistica istantanea con due tipi di memoria, una a breve termine per sostenere efficacemente una conversazione, e una a lungo termine supportata dal RAG. L’embedding si attiva inserendo nel messaggio di input una parola chiave. Il sistema inoltre risponde (anche) a voce se l’interazione iniziale avviene mediante voce o solo scritto se l’interazione e’ stata iniziata in forma testuale.

Lo utilzzero’ davvero? Non lo so, ma potrebbe essere che si … specie per via della memoria a lungo termine, in modo che posso di fatto prendere appunti velocemente e poi poterci accedere in modo altrettanto facile e veloce.

Intanto il trascrittore di vocali, nato per provare, l’ho usato varie volte.

Il tutto, come negli esempi precedenti, e’ selfhosted. Utilizzo:

Nuova versione di LLaMA ancora piu veloce

Sono molto affascinato da questo progetto. Spero che la IA esca presto da un utilizzo solo mediante API e in server remoti e misteriosi per arrivare ad essere disponibile sui dispositivi comuni. Il progetto LLaMA ci porta piu vicini a questo obbiettivo. La seguente chat e’ con Mistral 7B Q4 e LLaMA 0.7, eseguiti su un i7 13th gen con 16 GB di ram e nessuna accelerazione con GPU.

Annuncio : https://justine.lol/matmul/ – Repo: https://github.com/Mozilla-Ocho/llamafile

© 2026 b0sh.net

Tema di Anders NorenSu ↑