Esecuzione di un LLM locale su Apple Silicon per il security triage

Un modello che classifica una connessione di rete come meritevole o meno di un'occhiata, in esecuzione sullo stesso Mac che ha effettuato la connessione, cambia tre cose contemporaneamente: cosa lascia la macchina, quanto costa gestirla e se continua a funzionare quando la rete stessa è la cosa sospettata. Tutti e tre sono più importanti per uno strumento di sicurezza che per la maggior parte degli altri usi di un modello linguistico, motivo per cui questo articolo riguarda specificamente il caso sul dispositivo piuttosto che la chiamata a un'API.

Perché sul dispositivo, specificatamente per il triage

Inviare una logline di connessione a un modello cloud per la classificazione significa trasmettere, per ogni singola decisione, quale app sul tuo Mac sta parlando con quale host, su quale porta, in questo momento. Niente di tutto ciò è un segreto come lo è una password, ma è esattamente il tipo di metadati che una configurazione attenta alla sicurezza cerca di ridurre al minimo la condivisione, e uno strumento il cui unico scopo è decidere cosa il tuo Mac può inviare altrove ha una ragione ovvia per non dipendere dall'invio di qualcosa altrove per ogni decisione che prende. L'esecuzione del modello localmente rimuove completamente tale dipendenza: la riga di registro non lascia mai il dispositivo, perché non è presente alcuna chiamata di rete nel percorso decisionale.

Il secondo motivo è la continuità. Una fase di triage basata su cloud è disponibile tanto quanto la tua connessione Internet e l'API del fornitore, che sono entrambe esattamente le cose che potrebbero essere degradate o tagliate deliberatamente durante un incidente reale. Un modello in esecuzione nella memoria locale continua a rispondere anche con la rete inattiva, il Wi-Fi disattivato o una sospetta compromissione in corso sullo stesso collegamento che avrebbe utilizzato la chiamata API.

MLX: il framework di array di Apple

MLX is an array framework built by Apple’s machine-learning research team specifically for Apple silicon, with Python, C++, C and Swift APIs. La sua stessa documentazione descrive un modello di memoria unificato come scelta progettuale determinante: gli array in MLX risiedono nella memoria condivisa e le operazioni su di essi possono essere eseguite su qualsiasi dispositivo supportato - CPU o GPU - senza che i pesi del modello vengano prima copiati tra pool di memoria separati. Ciò conta concretamente per un laptop: una macchina con GPU discreta deve copiare i pesi di un modello attraverso un bus nella memoria della GPU prima di poter calcolare qualsiasi cosa, il che costa tempo e raddoppia l'ingombro della memoria; on a Mac’s unified memory architecture, the CPU and GPU already share the same physical memory, so there is nothing to copy.

mlx-lm, il pacchetto complementare per l'esecuzione di modelli linguistici su MLX, si installa con un singolo comando e fornisce un modello predefinito pronto all'uso:

$ pip install mlx-lm
# runs the default model (mlx-community/Llama-3.2-3B-Instruct-4bit)
$ mlx_lm.generate --prompt "How tall is Mt Everest?"
# or name a specific quantized model from the mlx-community hub
$ mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit --prompt "..."
# interactive chat session instead of a single prompt
$ mlx_lm.chat
# convert and quantize a model yourself
$ mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q

lama.cpp: l'opzione portatile

llama.cpp è il più vecchio e il più ampiamente portato dei due, scritto in C/C++ senza che sia richiesto il runtime Python al momento dell'inferenza. Il suo stesso README afferma direttamente la posizione del progetto su questo hardware: il silicio Apple è trattato come, nelle parole del progetto, "un cittadino di prima classe - ottimizzato tramite i framework ARM NEON, Accelerate e Metal" e la documentazione di build conferma che su macOS, il backend della GPU Metal è abilitato per impostazione predefinita, con un flag in fase di compilazione per disabilitarlo se si desidera specificamente l'inferenza solo della CPU.

$ git clone https://github.com/ggml-org/llama.cpp
$ cd llama.cpp
$ cmake -B build
$ cmake --build build --config Release
# Metal is on by default on macOS; add -DGGML_METAL=OFF to the first
# command above if you need to force CPU-only inference
$ llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
# or run it as a local server instead of a one-shot command
$ llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

llama.cpp funziona da file GGUF, un formato di modello a file singolo che raggruppa i pesi quantizzati e tutto il necessario per eseguirli; il comando sopra ne estrae uno direttamente da un repository Hugging Face per nome. MLX, al contrario, si avvicina al flusso di lavoro nativo di Python, convertendo e quantizzando i modelli nel proprio formato in anticipo. Nessuno dei due è strettamente migliore: llama.cpp è quello a cui rivolgersi se si desidera un singolo binario compilato senza dipendenza da Python, MLX è quello a cui rivolgersi se si sta già costruendo il resto della pipeline in Python e si desidera un accesso di prima classe al modello di memoria unificato di Apple da lì.

Quantizzazione: ciò che effettivamente scambi per un modello più piccolo

La quantizzazione memorizza il peso di ciascun modello in un numero di bit inferiore ai 16 o 32 in cui il modello è stato addestrato, riducendo sia il file su disco che la memoria necessaria per eseguirlo, con un certo costo per la qualità dell'output. La documentazione di quantizzazione di llama.cpp elenca le cifre esatte di bit per peso per ogni schema supportato, che è un modo più preciso per ragionare sul compromesso rispetto alla solita abbreviazione di "4 bit" o "8 bit":

Moltiplicando il conteggio dei parametri di un modello per il numero di bit per peso si ottiene una stima approssimativa della memoria solo per i pesi: un modello da 7 miliardi di parametri ai 4,89 bit per peso di Q4_K_M richiede circa 7.000.000.000 × 4,89 ÷ 8 byte, o circa 4,3 GB, prima di tenere conto della finestra di contesto e delle attivazioni intermedie, che ne aggiungono altro in base alla quantità di testo che si inserisce nutrilo. Si tratta di un calcolo basato sulla cifra di bit per peso citata, non di un numero che il progetto pubblica direttamente e l'utilizzo effettivo della memoria sarà maggiore una volta caricato un prompt reale e il relativo contesto. La guida pratica che segue dalla tabella è semplice: per un'attività come classificare una riga di registro di connessione alla volta, in cui l'input è breve e l'output richiesto è un piccolo verdetto strutturato, un modello di classe Q4_K_M è molto spesso la soluzione giusta: notevolmente più piccolo e più veloce di Q8_0 o F16, senza scendere al livello di compressione estrema dove la qualità dell'output degrada più bruscamente.

Nessuno dei due progetti pubblica un requisito di memoria per configurazione Mac, quindi l'approccio pratico è quello di lavorare a ritroso rispetto alla stima di cui sopra e lasciare un margine reale: macOS stesso, il tuo browser e qualsiasi altra cosa sia in esecuzione necessitano tutti di memoria unificata, e un modello che si adatta a malapena senza nient'altro aperto si scambierà o si bloccherà nel momento in cui passi a un'altra app. Su un Mac con una modesta quantità di memoria unificata, ciò suggerisce di rimanere verso l’estremità più piccola della tabella sopra – qualche miliardo di parametri a Q4_K_M piuttosto che un modello molto più grande con la stessa quantizzazione – e riservare le opzioni più grandi e di maggiore precisione per le macchine con memoria in più. Per un compito di classificazione ristretto come quello di cui tratta questo articolo, un modello più piccolo a cui viene posta una domanda precisa tende ad essere più veloce e, in pratica, più coerente di un modello più grande a cui viene posta una domanda vaga.

Entrambi i progetti sono in fase di sviluppo attivo e il confronto onesto è meno "che è meglio" che "che si adatta alla tua pipeline". llama.cpp viene compilato in un singolo binario senza che sia richiesto il runtime Python al momento dell'inferenza, il che è importante se si desidera incorporarlo all'interno di un altro software senza fornire un interprete Python insieme ad esso. MLX presuppone che tu stia già lavorando in Python (o Swift, per il quale fornisce anche collegamenti) e lo premia con una più stretta integrazione nello stack di apprendimento automatico di Apple e nel modello di memoria unificata descritto sopra. Uno strumento di sicurezza costruito come applicazione macOS autonoma, che è la situazione in cui si trova lo stesso FireAI, si trova più vicino all'estremità llama.cpp di quello spettro; un taccuino di ricerca che esplora quale modello di prompt funziona meglio si trova più vicino all'estremità MLX.

Un modello di richiesta per la valutazione di una connessione

Quanto più ristretta è la domanda posta a un piccolo modello locale, tanto più affidabile sarà la risposta. Per una singola connessione, ciò significa fornire esattamente i campi che un revisore umano esaminerebbe – niente di più, niente di dedotto – e chiedere un verdetto strutturato piuttosto che una prosa in forma libera:

System: You review one outbound network connection at a time. You are
given only the fields listed below. Do not assume anything not stated.
Respond with exactly two lines: a verdict (allow, ask, or block) and a
one-sentence reason a non-expert could understand.

Connection:
  app: UpdaterHelper.app
  code_signature: unsigned
  destination: 91.203.xxx.xxx:4444
  protocol: TCP
  threat_feed_hit: none
  first_seen: yes (no prior rule for this app)

Verdict:

I campi che contano sono quelli che un controllo della firma del codice e un feed delle minacce possono effettivamente produrre senza indovinare: se il codice binario è firmato e da chi, dove sta tentando di connettersi e su quale porta, se quella destinazione viene visualizzata in un feed delle minacce e se questa è la prima volta che questa app tenta di connettersi. Richiedere un output fisso di due righe, piuttosto che una spiegazione aperta, rende il risultato più facile da registrare, più facile da confrontare tra migliaia di connessioni e molto più difficile da riempire per il modello con un linguaggio di copertura che sembri autorevole senza dire nulla di controllabile.

Un modello piccolo occasionalmente ignorerà comunque il formato richiesto: tre righe invece di due, un avvertimento in più, una parola di verdetto che non è una delle tre richieste. Trattalo come un problema di ingegneria, non di modellazione: convalida l'output rispetto alla forma esatta che ti aspetti e, se non corrisponde, chiedi nuovamente o ricorri al verdetto più sicuro (chiedi, ovvero mostra un essere umano) piuttosto che provare ad analizzare una risposta più vaga. Un passaggio di triage che fallisce in modo sicuro su un output non valido è molto più utile di uno che occasionalmente produce una riga dall'aspetto sicuro ma non analizzabile e la rilascia silenziosamente.

Esegui questo schema durante un'intera giornata di tentativi di connessione anziché uno alla volta e la forma del carico di lavoro cambia: la maggior parte delle connessioni proviene da app con una regola esistente e non raggiunge mai il modello, un numero più piccolo viene effettivamente visto per primo e ottiene un verdetto, e solo una frazione di questi verdetti è qualcosa di diverso da quello consentito dalla routine. Il vero lavoro del modello, a quel punto, non è quello di essere un esperto di sicurezza; si tratta di ridurre un lungo elenco di connessioni viste per la prima volta al piccolo sottoinsieme che una persona ha effettivamente bisogno di guardare, che è un obiettivo molto più raggiungibile per un modello di pochi miliardi di parametri rispetto a un giudizio di sicurezza a tempo indeterminato.

Dove va storto

• Un piccolo modello locale può produrre una ragione sicura, ben scritta, completamente sbagliata. Niente nell'esecuzione locale cambia questo rischio; cambia solo dove avviene l’errore, non se può accadere.
• Le finestre di contesto sono limitate e un registro lungo e rumoroso non è adatto. Riepilogare o pre-filtrare prima che il modello veda i dati introduce il proprio punto di errore: puoi perdere l'unica riga che contava prima che il modello abbia la possibilità di esaminarla.
• Il modello vede sempre e solo ciò che contiene la riga di registro. Non può vedere il traffico crittografato, non può verificare che un feed di minacce sia attuale e non può conoscere le tue intenzioni: una connessione da uno strumento che hai appena installato di proposito sembra identica a quella di uno strumento di cui non hai mai sentito parlare.
• Un verdetto non è un'azione. Niente qui dovrebbe bloccare, eliminare o consentire silenziosamente una connessione da solo; una persona deve ancora vedere il motivo e confermarlo, ed essere in grado di invertire la chiamata se il modello ha sbagliato.

Quest’ultimo punto non è una limitazione specifica di un piccolo modello quantizzato in esecuzione su un laptop: è vero per ogni decisione automatizzata sulla sicurezza, locale o cloud, modello piccolo o grande. Il valore di eseguirlo localmente è ciò che rimuove dall'equazione (una dipendenza dalla rete, una fattura ricorrente, una terza parte che riceve i metadati della connessione), non l'affermazione che elimina la necessità di un essere umano nel ciclo.

Dove FireAI si adatta a questo modello

FireAI, il firewall di HisnLabs per Mac, fornisce qualcosa basato sulla stessa idea, con un ambito più ristretto rispetto a un modello di chat generico: un modello locale opzionale, un download aggiuntivo di circa 1,5 GB, che funziona interamente sul Mac ed esamina le connessioni da app che non hanno ancora regole. Richiede macOS 14 o versioni successive su silicio Apple, applica i feed delle minacce pubbliche localmente invece di confrontarli con un servizio remoto e mostra il motivo della sua decisione nella stessa richiesta di autorizzazione che utilizza per chiederti di consentire o negare la connessione: ognuna di queste decisioni diventa una regola visibile e modificabile e ognuna di esse può essere annullata. Vale la pena essere precisi su cosa sia e cosa non sia: non è il modello di chat aperto, con pochi miliardi di parametri, descritto in questo articolo, e non è un antivirus o una VPN: svolge un lavoro di classificazione ristretto, a livello locale, e lascia la chiamata finale a chiunque legga il messaggio.

Il ruolo di FireAI e di HisnLabs

FireAI’s own connection reviewer is this exact bet, made narrower still: an optional, roughly 1.5 GB on-device model, macOS 14 and up, Apple silicon only, reviewing one thing (should this unknown app reach this destination) with a visible reason and an undo button — and, like the triage pattern in this article, it still needs a person to confirm anything consequential.

FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.