Devo mettere gli occhiali, mi servono delle lenti progressive, mi sono fatto fare un paio di preventivi e la "forchetta" tra i prezzi che mi hanno dato è molto alta.

Purtroppo non ho nessun modo di capire quale sia la scelta più razionale e attualmente ho solo due criteri a disposizione:

a) compro le economiche così risparmio;
b) compro le costose perché se costano di più sono migliori ed è meglio non risparmiare sulla salute.

Nessuno dei due criteri mi sembra quello ottimale. L'unica cosa utile sarebbe provarle entrambe e vedere come sono ma ovviamente non è possibile.

Voi che le avete come vi regolate?

#lenti #occhiali

Homebrew bills itself as the package manager MacOS never had (conveniently ignoring MacPorts) but they leave the PPC crowd criminally under-served, to say nothing of the 68k gang. Enter [that-ben] with MR Browser, a simple utility to fetch software from Macintosh Repository for computers too old to hit up the website.

If you’re not familiar with Macintosh Repository, it is what it says on the tin: a repository of vintage Macintosh software, like Macintosh Garden but apparently less accessible to vintage machines.
MRBrowser sys6 runs nicely on the Macintosh Plus, as you can see.
There are two versions available, depending on the age of your machine. For machines running System 6, the appropriately-named MR Browser sys6 will run on any 68000 Mac in only 157 KB of and MacTCP networking. (So the 128K obviously isn’t going to cut it, but a Plus from ’86 would be fine.)

The other version, called MR Browser 68K, ironically won’t run on the 68000. It needs a newer processor (68020 or newer, up-to and including PPC) and TCP/IP networking. Anything starting from the Macintosh II or newer should be game; it’s looking for System 7.x upto the final release of Mac OS 9, 9.2.2. You’ll want to give it at least 3 MB of RAM, but can squeak by on 1.6 MB if you aren’t using pictures in the chat.

Chat? Yes, perhaps uniquely for a software store, there’s a chat function. That’s not so weird when you consider that this program is meant to be a stand-alone interface for the Macintosh Repository website, which does, indeed, have a chat feature. It beats an uncaring algorithm for software recommendations, that’s for sure. Check it out in action in the demo video below.

It’s nice to see people still making utilities to keep the old machines going, even if coding on them isn’t always the easiest. If you want to go online on with vintage hardware (Macintosh or otherwise) anywhere else, you’re virtually locked-out unless you use something like FrogFind.

Thanks to [PlanetFox] for the tip. Submit your own, and you may win fabulous prizes. Not from us, of course, but anything’s possible!

hackaday.com/wp-content/upload…

*

hackaday.com/2025/07/18/mr-bro…

Negli ultimi anni i modelli di linguaggio di grandi dimensioni (LLM, Large Language Models) come GPT, Claude o LLaMA hanno dimostrato capacità straordinarie nella comprensione e generazione del linguaggio naturale. Tuttavia, dietro le quinte, far funzionare un LLM non è un gioco da ragazzi: richiede una notevole infrastruttura computazionale, un investimento economico consistente e scelte architetturali precise. Cerchiamo di capire perché.

70 miliardi di parametri: cosa significa davvero

Un LLM da 70 miliardi di parametri, come LLaMA 3.3 70B di Meta, contiene al suo interno 70 miliardi di “pesi”, ovvero numeri in virgola mobile (di solito in FP16 o BF16, cioè 2 byte per parametro) che rappresentano le abilità apprese durante l’addestramento. Solo per caricare in memoria questo modello, servono circa:

• 140 GB di RAM GPU (70 miliardi × 2 byte).

A questa cifra vanno aggiunti altri 20-30 GB di VRAM per gestire le operazioni dinamiche durante l’inferenza: cache dei token (KV cache), embedding dei prompt, attivazioni temporanee e overhead di sistema. In totale, un LLM da 70 miliardi di parametri richiede circa 160-180 GB di memoria GPU per funzionare in modo efficiente.

Perché serve la GPU: la CPU non basta

Molti si chiedono: “Perché non far girare il modello su CPU?”. La risposta è semplice: latenza e parallelismo.

Le GPU (Graphics Processing Unit) sono progettate per eseguire milioni di operazioni in parallelo, rendendole ideali per il calcolo tensoriale richiesto dagli LLM. Le CPU, invece, sono ottimizzate per un numero limitato di operazioni sequenziali ad alta complessità. Un modello come LLaMA 3.3 70B può generare una parola ogni 5-10 secondi su CPU, mentre su GPU dedicate può rispondere in meno di un secondo. In un contesto produttivo, questa differenza è inaccettabile.

Inoltre, la VRAM delle GPU di fascia alta (es. NVIDIA A100, H100) consente di mantenere il modello residente in memoria e di sfruttare l’accelerazione hardware per la moltiplicazione di matrici, cuore dell’inferenza LLM.

Un esempio: 100 utenti attivi su un LLM da 70B

Immaginiamo di voler offrire un servizio simile a ChatGPT per la sola generazione di testo, basato su un modello LLM da 70 miliardi di parametri, con 100 utenti attivi contemporaneamente. Supponiamo che ogni utente invii prompt da 300–500 token e si aspetti risposte rapide, con una latenza inferiore a un secondo.

Un modello di queste dimensioni richiede circa 140 GB di memoria GPU per i soli pesi in FP16, a cui vanno aggiunti altri 20–40 GB per la cache dei token (KV cache), attivazioni temporanee e overhead di sistema. Una singola GPU, anche top di gamma, non dispone di sufficiente memoria per eseguire il modello completo, quindi è necessario distribuirlo su più GPU tramite tecniche di tensor parallelism.

Una configurazione tipica prevede la distribuzione del modello su un cluster di 8 GPU A100 da 80 GB, sufficiente sia per caricare il modello in FP16 sia per gestire la memoria necessaria all’inferenza in tempo reale. Tuttavia, per servire contemporaneamente 100 utenti mantenendo una latenza inferiore al secondo per un LLM di queste dimensioni, una singola istanza su 8 GPU A100 (80GB) è generalmente insufficiente.

Per raggiungere l’obiettivo di 100 utenti simultanei con latenza sub-secondo, sarebbe necessaria una combinazione di:

• Un numero significativamente maggiore di GPU A100 (ad esempio, un cluster con 16-32 o più A100 da 80GB), distribuite su più POD o in un’unica configurazione più grande.
• L’adozione di GPU di nuova generazione come le NVIDIA H100, che offrono un netto miglioramento in termini di throughput e latenza per l’inferenza di LLM, però ad un costo maggiore.
• Massimizzare le ottimizzazioni software, come l’uso di framework di inferenza avanzati (es. vLLM, NVIDIA TensorRT-LLM) con tecniche come paged attention e dynamic batching.
• L’implementazione della quantizzazione (passando da FP16 a FP8 o INT8/INT4), che ridurrebbe drasticamente i requisiti di memoria e aumenterebbe la velocità di calcolo, ma con una possibile conseguente perdita di qualità dell’output generato (soprattutto per la quantizzazione INT4).

Per scalare ulteriormente, è possibile replicare queste istanze su più GPU POD, abilitando la gestione di migliaia di utenti totali in modo asincrono e bilanciato, in base al traffico in ingresso. Naturalmente, oltre alla pura inferenza, è fondamentale prevedere risorse aggiuntive per:

• Scalabilità dinamica in funzione della domanda.
• Bilanciamento del carico tra istanze.
• Logging, monitoraggio, orchestrazione e sicurezza dei dati.

Ma quanto costa un’infrastruttura di questo tipo?

L’implementazione on-premise richiede centinaia di migliaia di euro di investimento iniziale, cui si aggiungono i costi annuali di gestione, alimentazione e personale. In alternativa, i principali provider cloud offrono risorse equivalenti ad un costo mensile molto più accessibile e flessibile. Tuttavia, è importante sottolineare che anche in cloud, una configurazione hardware capace di gestire un tale carico in tempo reale può comportare costi mensili che facilmente superano le decine di migliaia di euro, se non di più, a seconda dell’utilizzo.

In entrambi i casi, emerge con chiarezza come l’impiego di LLM di grandi dimensioni rappresenti non solo una sfida algoritmica, ma anche infrastrutturale ed economica, rendendo sempre più rilevante la ricerca di modelli più efficienti e leggeri.

On-premise o API? La riservatezza cambia le carte in tavola

Un’alternativa semplice per molte aziende è usare le API di provider esterni come OpenAI, Anthropic o Google. Tuttavia, quando entrano in gioco la riservatezza e la criticità dei dati, l’approccio cambia radicalmente. Se i dati da elaborare includono informazioni sensibili o personali (ad esempio cartelle cliniche, piani industriali o atti giudiziari), inviarli a servizi cloud esterni può entrare in conflitto con i requisiti del GDPR, in particolare rispetto al trasferimento transfrontaliero dei dati e al principio di minimizzazione.

Anche molte policy aziendali basate su standard di sicurezza come ISO/IEC 27001 prevedono il trattamento di dati critici in ambienti controllati, auditabili e localizzati.

Inoltre, con l’entrata in vigore del Regolamento Europeo sull’Intelligenza Artificiale (AI Act), i fornitori e gli utilizzatori di sistemi di AI devono garantire tracciabilità, trasparenza, sicurezza e supervisione umana, soprattutto se il modello è impiegato in contesti ad alto rischio (finanza, sanità, istruzione, giustizia). L’uso di LLM attraverso API cloud può rendere impossibile rispettare tali obblighi, in quanto l’inferenza e la gestione dei dati avvengono fuori dal controllo diretto dell’organizzazione.

In questi casi, l’unica opzione realmente compatibile con gli standard normativi e di sicurezza è adottare un’infrastruttura on-premise o un cloud privato dedicato, dove:

• Il controllo sui dati è totale;
• L’inferenza avviene in un ambiente chiuso e conforme;
• Le metriche di auditing, logging e accountability sono gestite internamente.

Questo approccio consente di preservare la sovranità digitale e la conformità a GDPR, ISO 27001 e AI Act, pur richiedendo un effort tecnico ed economico significativo.

Conclusioni: tra potenza e controllo

Mettere in servizio un LLM non è solo una sfida algoritmica, ma soprattutto un’impresa infrastrutturale, fatta di hardware specializzato, ottimizzazioni complesse, costi energetici elevati e vincoli di latenza. I modelli di punta richiedono cluster da decine di GPU, con investimenti che vanno da centinaia di migliaia fino a milioni di euro l’anno per garantire un servizio scalabile, veloce e affidabile.

Un’ultima, ma fondamentale considerazione riguarda l’impatto ambientale di questi sistemi. I grandi modelli consumano enormi quantità di energia elettrica, sia in fase di addestramento che di inferenza. Con l’aumentare dell’adozione di LLM, diventa urgente sviluppare modelli più piccoli, più leggeri e più efficienti, che riescano a offrire prestazioni comparabili a fronte di un footprint computazionale (ed energetico) significativamente ridotto.

Come è accaduto in ogni evoluzione tecnologica — dal personal computer ai telefoni cellulari — l’efficienza è la chiave della maturità: non servono sempre modelli più grandi, ma modelli più intelligenti, più adattivi e sostenibili.

L'articolo Come Funziona Davvero un LLM: Costi, Infrastruttura e Scelte Tecniche dietro ai Grandi Modelli di Linguaggio proviene da il blog della sicurezza informatica.

Hanno cominciato ad ammazzare cattolici, stai a vedere che adesso comincia a importarcene qualcosa...

La presidente del Consiglio Giorgia Meloni ha condannato l’attacco contro la chiesa e in generale contro la popolazione civile con toni particolarmente duri: in un comunicato ha detto che «sono inaccettabili gli attacchi contro la popolazione civile che Israele sta dimostrando da mesi. Nessuna azione militare può giustificarla.

ilpost.it/2025/07/17/chiesa-sa…

Israele ha attaccato l’unica chiesa cattolica nella Striscia di Gaza

Quella della Sacra Famiglia: tre persone sono state uccise e nove ferite, fra cui il parroco

^{Il Post}