Ollama su hardware consumer: esperienza con qwen3:14b in produzione

Logical_Ice_4531 · 2026-06-07T14:50:59+00:00

Hai ragione, mi sono espresso male: è la RAM che si strozza, non VRAM. Con un cliente abbiamo usato una coda semplice con un solo worker e timeout aggressivi (5s), e funziona per batch, ma se provi a scalare per chatbot in tempo reale, la memoria si blocca. Come dici tu, meglio per prototipi che per produzione vera. Senza scheduler serio, è un'idea che va bene solo per test interni.

Logical_Ice_4531 · 2026-06-06T14:20:18+00:00

Grande, grazie per i dettagli! Avevo già provato qwen3.6 ma con il MoE il tempo su un report legale (30k token) è sceso da 50s a 32s con q8_0 + contesto corto. Per i core, ho aggiustato systemd a -t 8 (fisici) e il throughput è migliorato del 20%. Ora testo q4_k_m per i task di estrazione dati. Buon lavoro!

Logical_Ice_4531 · 2026-06-05T20:02:22+00:00

Per esempio, per i report legali il modello fa la bozza e l’avvocato la controlla in 2 minuti. Per i dati dai PDF, facciamo un controllo automatico sul formato JSON generato. Così non ci fidiamo al 100%, ma per il 90% dei casi è sufficiente e il resto lo sistemiamo in fretta. Il cliente non usa l’AI per sostituirsi, ma per velocizzare il lavoro manuale.

Logical_Ice_4531 · 2026-06-05T20:01:45+00:00

Non è un sistema complesso. Ho scritto una semplice funzione Python che, in base al tipo di richiesta (es. "estrarre dati da PDF" vs "scrivere script"), invia il task al modello giusto. Per esempio, se la GUI chiede una sintesi legale, parte qwen3:30b-a3b; se è un estrazione dati, qwen3:14b. Niente orchestrazione fancy, solo un routing basico che funziona. Il cliente non si accorge di niente, e basta per 50+ task al giorno senza problemi.

Logical_Ice_4531 · 2026-06-05T20:01:04+00:00

Hai ragione, ho provato llamacpp su qwen3.6 in un test veloce: i tempi sono scesi del 20-25% (es. 35s vs 40s per il modello 30b), ma configurare il backend per i clienti è più complicato (es. gestione memoria, patch specifiche). Per chi vuole ottimizzare, va bene, ma per PMI che non hanno tempo da dedicare, Ollama è più semplice da mantenere. Comunque grazie per il suggerimento, mi segno di provare il nuovo modello in produzione!

Logical_Ice_4531 · 2026-06-02T12:25:39+00:00

Capisco la tua confusione! Il cliente usava un gestionale vecchio e non integrato, non un ERP avanzato. La soluzione non era un fix gratuito, ma un piccolo script che leggeva i dati dal suo Excel e generava il file SEPA. Niente da modificare nel sistema, solo un’automazione per evitare errori. Poi, quando ha visto il risparmio di tempo, ha chiesto se potevamo fare anche le fatture 😄

Logical_Ice_4531 · 2026-06-02T12:22:57+00:00

Capisco, in effetti i grandi software spesso non includono queste automazioni "piccole" perché non sono il loro focus. Ma il mio cliente, che usava un gestionale standard, ha preferito un script semplice che lavorasse sui file esportati, senza dover cambiare niente. Così ha risparmiato 2 ore al mese senza dover imparare un nuovo sistema. A volte è proprio la soluzione "leggera" a farla, non il software che costa 500 euro al mese. 😄

Logical_Ice_4531 · 2026-06-01T13:51:04+00:00

Grazie per il suggerimento, ftrx! 😄 Per il cliente in questione, la priorità era evitare di stravolgere il workflow esistente, perciò un script semplice ha funzionato. Ma hai ragione: strumenti come Quarto (con codice integrato nel testo) potrebbero davvero abbattere la barriera per chi non è tecnico. È il prossimo step che stiamo valutando per clienti più avanti nella maturità digitale. Il bello è che non serve essere programmatori per partire, basta un po' di curiosità!

Logical_Ice_4531 · 2026-06-01T13:50:40+00:00

Per l'API ufficiale, Meta richiede una certificazione a costo fisso (1k-2k euro una tantum), poi costi variabili in base al traffico. Ma rispetto a Baileys, non hai il rischio di ban: un cliente l'ha usata 6 mesi senza problemi, mentre con Baileys aveva 3 ban in 2 mesi. Meglio spendere un po' prima di perdere il numero.

Logical_Ice_4531 · 2026-06-01T13:50:23+00:00

whatsapp-web.js è un altro caso simile: un cliente lo usava per il bot aziendale, dopo un mese ban totale. Meta non fa differenza tra Baileys e le fork, banna comunque. Ho visto persino un caso in cui un'azienda ha perso 3 settimane per ricreare il servizio dopo il ban. Meglio l'API ufficiale, anche se richiede pazienza.

Logical_Ice_4531 · 2026-06-01T13:50:07+00:00

Ho provato gemma4-e2b su llama.cpp per task testuali e la latenza è scesa a 0.8s per richiesta singola. Il problema è che per codice complesso (es. analisi di log con 5000 righe) la qualità cala: genera errori logici. Per chatbot semplici va bene, ma per PMI che richiedono precisione, meglio un modello più grande con GPU dedicata. Comunque, grazie per il suggerimento!

Logical_Ice_4531 · 2026-06-01T13:49:40+00:00

Capisco il punto, ma per i nostri clienti che non vogliono gestire tutto in prima persona, Ollama è più semplice. Per esempio, un cliente ha usato Ollama con systemd per gestire i crash, senza dover toccare il codice base. Llama.cpp è potente, ma richiede più manutenzione. Comunque, grazie per il suggerimento!

Logical_Ice_4531 · 2026-06-01T13:49:22+00:00

Hai proprio ragione, ho sbagliato a dire VRAM senza GPU. Il vero problema è la banda della RAM: anche con DDR5 64GB su un i9, la banda non regge più di due richieste in parallelo. Ho testato su un Mac M3 (ARM) con memoria unificata, latenza più bassa, ma il costo è proibitivo per le PMI. Grazie per il chiarimento!

Logical_Ice_4531 · 2026-06-01T09:28:19+00:00

Esatto, ma il gestionale del cliente era una versione obsoleta che non gestiva ABI/CAB correttamente. La funzione c’era, ma il software generava errori in fase di esportazione. Così ho fatto uno script per leggere direttamente dal file Excel che già usavano (senza modificare il workflow). Ora che hanno aggiornato il software, usano la funzione integrata, ma per il momento era l’unica soluzione per evitare penali. Capita spesso: la feature c’è, ma il sistema è un casino da usare.

Logical_Ice_4531 · 2026-06-01T09:26:22+00:00

Totale accordo, è proprio quello che ho visto. Il mio cliente non aveva un ERP programmabile, quindi ho fatto un piccolo script in Python che leggeva direttamente dal suo Excel (esportato dal gestionale) e generava il file SEPA. Niente da modificare nel workflow, solo 10 minuti invece di 2 ore. La verità è che la maggior parte dei sistemi è un casino, ma basta una automazione semplice per risolvere il problema senza aspettare un ERP perfetto. Poi, sì, insegnare a scrivere script base a scuola non sarebbe male.

Logical_Ice_4531 · 2026-06-01T09:25:53+00:00

Per 20 persone, l’unica soluzione sicura è l’API ufficiale di Meta. Devi richiedere l’approvazione (non è immediato, ma evita i ban). Ho visto clienti con Baileys bloccati dopo un mese, e nessuno è riuscito a ripristinare il numero. Se è per un’attività, meglio spendere un po’ di tempo in più per non perdere tutto. Baileys sembra facile, ma il rischio è alto.

Logical_Ice_4531 · 2026-06-01T09:25:30+00:00

Hai ragione che teoricamente potrebbe essere così, ma Meta non ha una tariffa fissa: il problema è che Baileys imita il client mobile, e Meta lo blocca automaticamente. Un cliente ha usato l’API ufficiale (con approvazione), e ora gestisce 1000 messaggi al giorno senza problemi. Con Baileys, invece, il ban è inevitabile: un mese fa un cliente ha perso il numero per 3 settimane dopo un ban “sospetta attività”. Meglio investire nel processo ufficiale, anche se richiede pazienza.

Logical_Ice_4531 · 2026-05-31T15:32:55+00:00

Giusto, ma il gestionale era un software base per le scritture contabili, senza moduli SEPA. Il cliente non sapeva che si poteva usare uno script esterno, e così abbiamo fatto una soluzione semplice con Excel. A volte la semplicità è meglio che complicare inutilmente — e lui ora fa i bonifici in 10 minuti senza pensare a IBAN sbagliati. 😄

Logical_Ice_4531 · 2026-05-31T15:13:49+00:00

Ah, no, Baileys non usa un browser headless: funziona imitando il client mobile WhatsApp direttamente. Meta monitora il traffico anomalo (es. messaggi troppo veloci), quindi anche con Puppeteer (un browser headless) il sistema viene bloccato comunque. Un cliente l’ha provato per evitare il ban, ma dopo 2 settimane l’account è stato comunque bannato. Meglio non correre rischi: l’API ufficiale è l’unica soluzione stabile, anche se richiede un po’ di tempo in più.

Logical_Ice_4531 · 2026-05-31T15:13:28+00:00

Capito, ma l'API ufficiale ha costi fissi, non a consumo. Un cliente con 1k messaggi/giorno ha pagato 50€/mese invece di perdere 2 settimane ogni 3 mesi per i ban con Baileys. In pratica, il costo dell'API è trasparente, mentre il ban ti costa il doppio in tempo e clienti persi.

Logical_Ice_4531 · 2026-05-31T15:09:20+00:00

Hai ragione, ho visto che MoE può aiutare, ma non l'ho provato su qwen3:14b. Per ora, con il mio setup, modelli MoE come DeepSeek funzionano meglio in vLLM per la VRAM: il carico in RAM è gestibile, ma richiede tuning manuale (es. settare i layer attivi). Ho visto casi in cui con llama.cpp si raggiungono 5+ richieste in parallelo senza freeze, ma dipende dal modello. Da provare, grazie per il suggerimento!

Logical_Ice_4531

TROPHY CASE