Kjører en lokal LLM på Apple Silicon for Security Triage

En modell som klassifiserer en nettverkstilkobling som verdt å se på eller ikke, kjører på samme Mac som opprettet tilkoblingen, endrer tre ting på en gang: hva som forlater maskinen, hva den koster å kjøre, og om den fortsetter å fungere når nettverket i seg selv er det som er mistenkt. Alle tre betyr mer for et sikkerhetsverktøy enn for de fleste andre bruksområder av en språkmodell, og det er derfor denne artikkelen spesifikt handler om saken på enheten i stedet for å kalle en API.

Hvorfor på enheten, spesielt for triage

Å sende en tilkoblingslogglinje til en skymodell for klassifisering betyr å overføre, for hver enkelt beslutning, hvilken app på Mac-en som snakker med hvilken vert, på hvilken port akkurat nå. Ingenting av dette er en hemmelighet i måten et passord er, men det er akkurat den typen metadata et sikkerhetsbevisst oppsett prøver å minimere deling, og et verktøy hvis hele formålet er å bestemme hva Mac-en din har lov til å sende andre steder har en åpenbar grunn til ikke å være avhengig av å sende noe andre steder for hver beslutning den tar. Å kjøre modellen lokalt fjerner den avhengigheten helt: logglinjen forlater aldri enheten, fordi det ikke er noe nettverksanrop i beslutningsbanen i det hele tatt.

Den andre grunnen er kontinuitet. Et skybasert triage-trinn er bare så tilgjengelig som internettforbindelsen din og leverandørens API, som begge er nøyaktig de tingene som kan bli forringet eller bevisst kuttet under en virkelig hendelse. En modell som kjører i lokalt minne fortsetter å svare med nettverket nede, Wi-Fi av eller et mistenkt kompromiss pågår på den samme koblingen som API-kallet ville ha brukt.

MLX: Apples eget array-rammeverk

MLX er et array-rammeverk bygget av Apples maskinlæringsforskningsteam spesielt for Apples silisium, med Python, C++, C og Swift APIer. Dens egen dokumentasjon beskriver en enhetlig minnemodell som dets definerende designvalg: arrays i MLX lever i delt minne, og operasjoner på dem kan kjøres på hvilken som helst støttet enhet – CPU eller GPU – uten at modellens vekter kopieres mellom separate minnepooler først. Det betyr konkret for en bærbar datamaskin: en diskret GPU-maskin må kopiere en modells vekter over en buss inn i GPU-minnet før den kan beregne noe, noe som koster tid og dobler minneavtrykket; på en Macs enhetlige minnearkitektur deler CPU og GPU allerede det samme fysiske minnet, så det er ingenting å kopiere.

mlx-lm, følgepakken for å kjøre språkmodeller på MLX, installeres med en enkelt kommando og sender en standardmodell ut av esken:

$ 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

llama.cpp: det bærbare alternativet

llama.cpp er den eldre, mer utbredte porterte av de to, skrevet i C/C++ uten at Python-kjøretid kreves på inferenstidspunkt. Dens egen README angir prosjektets posisjon på denne maskinvaren direkte: Apple-silisium blir behandlet som, med prosjektets ord, "en førsteklasses borger - optimalisert via ARM NEON, Accelerate og Metal-rammeverk," og byggedokumentasjonen bekrefter at på macOS er Metal GPU-backend aktivert som standard, med et byggtidsflagg hvis du spesifikt ønsker å deaktivere det.

$ 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 fungerer fra GGUF-filer, et enkeltfilmodellformat som samler de kvantiserte vektene og alt som trengs for å kjøre dem; kommandoen ovenfor henter en rett fra et Hugging Face-lager ved navn. MLX, derimot, holder seg nærmere en innfødt Python-arbeidsflyt, konverterer og kvantiserer modeller til sitt eget format på forhånd. Ingen av delene er strengt tatt bedre: llama.cpp er den du skal strekke deg etter hvis du vil ha en enkelt kompilert binær uten Python-avhengighet, MLX er den du skal strekke deg etter hvis du allerede bygger resten av pipelinen din i Python og vil ha førsteklasses tilgang til Apples enhetlige minnemodell derfra.

Kvantisering: hva du faktisk bytter for en mindre modell

Kvantisering lagrer hver modellvekt i færre biter enn de 16 eller 32 modellene ble opplært i, og krymper både filen på disken og minnet som trengs for å kjøre den, til en viss pris for utskriftskvaliteten. llama.cpps egen kvantiseringsdokumentasjon viser nøyaktige bits-per-weight-tall for hvert skjema den støtter, noe som er en mer presis måte å resonnere på avveiningen enn den vanlige forkortelsen for "4-bit" eller "8-bit":

Å multiplisere en modells parametertelling med bits-per-vekt-tallet gir et grovt minneestimat for vektene alene: en modell med 7 milliarder parametere ved Q4_K_Ms 4,89 biter per vekt trenger omtrent 7 000 000 000 × 4,89 ÷ 8 byte, eller ca. topp avhengig av hvor mye tekst du mater den. Det er en beregning fra den siterte bits-per-weight-figuren, ikke et tall som enten prosjektene publiserer direkte, og faktisk minnebruk vil løpe høyere når en ekte forespørsel og dens kontekst er lastet inn. Den praktiske veiledningen som følger av tabellen er enkel: for en oppgave som å klassifisere én tilkoblingslogglinje om gangen, der inngangen er kort og den nødvendige utgangen er en liten strukturert dom, er en Q4_K_M-klasse-modell veldig ofte den rette handelen – merkbart mindre og raskere enn Q8_0 eller F16, uten å falle til ekstremkompresjonsnivået med skarpere utdatakvalitet.

Ingen av prosjektene publiserer et minnekrav per Mac-konfigurasjon, så den praktiske tilnærmingen er å jobbe bakover fra estimatet ovenfor og gi reell takhøyde: selve macOS, nettleseren din og alt annet som kjører trenger også enhetlig minne, og en modell som så vidt passer med ingenting annet åpent vil bytte eller stoppe i det øyeblikket du bytter til en annen app. På en Mac med en beskjeden mengde enhetlig minne, argumenterer det for å holde seg mot den mindre enden av tabellen ovenfor – noen få milliarder parametere ved Q4_K_M i stedet for en mye større modell med samme kvantisering – og reservere de større alternativene med høyere presisjon for maskiner med minne til overs. For en smal klassifiseringsoppgave som den denne artikkelen handler om, har en mindre modell stilt et presist spørsmål en tendens til å være både raskere og i praksis mer konsistent enn en større modell gitt en vag.

Begge prosjektene er under aktiv utvikling, og den ærlige sammenligningen er mindre "som er bedre" enn "som passer din pipeline." llama.cpp kompileres til en enkelt binærfil uten at Python-kjøretid kreves ved inferenstidspunkt, noe som betyr noe om du vil bygge den inn i en annen programvare uten å sende en Python-tolk ved siden av. MLX antar at du allerede jobber i Python (eller Swift, som den også sender bindinger for) og belønner det med tettere integrering i Apples egen maskinlæringsstabel og den enhetlige minnemodellen beskrevet ovenfor. Et sikkerhetsverktøy bygget som en frittstående macOS-applikasjon, som er situasjonen FireAI selv er i, sitter nærmere llama.cpp-enden av det spekteret; en forskningsnotisbok som utforsker hvilket promptmønster som fungerer best, sitter nærmere MLX-enden.

Et spørsmålsmønster for triaging av én tilkobling

Jo smalere spørsmål du stiller en liten lokal modell, jo mer pålitelig svarer den. For en enkelt forbindelse betyr det å gi den nøyaktig de feltene en menneskelig anmelder ville se på - ikke noe mer, ingenting utledet - og å be om en strukturert dom i stedet for fri formprosa:

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:

Feltene som betyr noe, er de som en kodesigneringssjekk og en trusselfeed faktisk kan produsere uten å gjette: om binærfilen er signert og av hvem, hvor den prøver å koble til og på hvilken port, om den destinasjonen vises på en trusselfeed, og om dette er første gang denne appen har prøvd å koble til i det hele tatt. Å be om en fast to-linjers utgang, i stedet for en åpen forklaring, gjør resultatet enklere å logge, enklere å sammenligne på tvers av tusenvis av tilkoblinger, og mye vanskeligere for modellen å fylle med sikringsspråk som høres autoritativt ut uten å si noe som kan kontrolleres.

En liten modell vil av og til ignorere det forespurte formatet uansett - tre linjer i stedet for to, en ekstra advarsel, et domsord som ikke er ett av de tre du ba om. Behandle det som et ingeniørproblem, ikke et modelleringsproblem: valider resultatet mot den eksakte formen du forventer, og hvis det ikke stemmer, spør du enten på nytt eller fall tilbake til den sikreste dommen (spør, betyr vis et menneske) i stedet for å prøve å analysere et løsere svar. Et triage-trinn som feiler trygt på misformet utgang er langt mer nyttig enn et som av og til produserer en selvsikker, men uparsebar linje og dropper den stille.

Kjør dette mønsteret over en hel dag med tilkoblingsforsøk i stedet for ett om gangen, og formen på arbeidsbelastningen endres: de fleste tilkoblinger er fra apper med en eksisterende regel og når aldri modellen i det hele tatt, et mindre antall blir virkelig først sett og får en dom, og bare en brøkdel av disse dommene er noe annet enn en rutine tillater. Modellens virkelige jobb, på det tidspunktet, er ikke å være en sikkerhetsekspert; det er å kutte en lang liste av første-sett-forbindelser ned til den lille delmengden en person faktisk trenger å se på, som er et mye mer oppnåelig mål for en modell med få milliarder parameter enn en åpen sikkerhetsvurdering ville vært.

Hvor dette går galt

• En liten lokal modell kan produsere en selvsikker, velskrevet, helt feil grunn. Ingenting med å løpe lokalt endrer den risikoen; det endrer seg bare der feilen skjer, ikke om det kan skje.
• Kontekstvinduer er begrensede, og en lang, støyende logg passer ikke. Oppsummering eller forhåndsfiltrering før modellen ser dataene introduserer sitt eget feilpunkt – du kan miste den ene linjen som betydde noe før modellen noen gang får en sjanse til å se på den.
• Modellen ser bare hva logglinjen inneholder. Den kan ikke se innsiden av kryptert trafikk, den kan ikke bekrefte at en trusselfeed er aktuell, og den kan ikke vite intensjonen din - en tilkobling fra et verktøy du nettopp installerte med vilje ser identisk ut med en fra et verktøy du aldri har hørt om.
• En dom er ikke en handling. Ingenting her skal blokkere, slette eller i det stille tillate en tilkobling alene; en person trenger fortsatt å se årsaken og bekrefte den, og kunne reversere samtalen hvis modellen tok feil.

Det siste punktet er ikke en begrensning som er spesifikk for en liten kvantisert modell som kjører på en bærbar datamaskin – det gjelder for enhver automatisert sikkerhetsbeslutning, lokal eller sky, liten modell eller stor. Verdien av å kjøre den lokalt er det den fjerner fra ligningen (en nettverksavhengighet, en gjentakende regning, en tredjepart som mottar tilkoblingsmetadataene dine), ikke en påstand om at det fjerner behovet for et menneske i løkken.

Hvor FireAI passer til dette mønsteret

FireAI, HisnLabs' brannmur for Mac, sender noe bygget på samme idé, med et smalere omfang enn en generell chat-modell: en valgfri lokal modell, en ekstra nedlasting på omtrent 1,5 GB, som kjører helt på Mac og vurderer tilkoblinger fra apper som ikke har noen regler ennå. Den krever macOS 14 eller nyere på Apple-silisium, bruker offentlige trusselstrømmer lokalt i stedet for å sjekke dem mot en ekstern tjeneste, og viser årsaken til avgjørelsen i den samme tillatelsesforespørselen den bruker for å be deg om å tillate eller nekte tilkoblingen – hver av disse avgjørelsene blir en synlig, redigerbar regel, og hvilken som helst av dem kan angres. Det er verdt å være presis om hva det er og ikke er: det er ikke den åpne chat-modellen med få milliarder parametre som denne artikkelen har beskrevet, og det er ikke et antivirus eller en VPN – den gjør en smal klassifiseringsjobb lokalt og overlater den siste samtalen til den som leser forespørselen.

Hvor FireAI og HisnLabs kommer inn

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 er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.