Hvorfor vi gikk vekk fra Mac mini

For et drøyt år siden satt jeg på kontoret med en Mac mini og prøvde å overbevise meg selv om at vi hadde funnet svaret. Den var stillegående, billig, hadde unified memory, og det fantes et helt økosystem av verktøy rundt MLX og llama.cpp. På papiret var den perfekt for det vi ville: kjøre lokale språkmodeller for norske SMB-er som ikke kunne sende dataene sine til Silicon Valley.

Det jeg ikke skjønte da, var at vi hadde stilt feil spørsmål. Vi spurte hvilken maskin som kunne kjøre én stor modell raskt, når det vi egentlig trengte var noe ganske annet. Det tok noen måneder, et par feilsteg og en seriøs runde med testing før vi forsto det. I dag bygger vi på NVIDIA DGX Spark, og denne teksten handler om hvorfor.

Den handler også om noe litt mer urovekkende, som jeg skal komme tilbake til mot slutten. For det viser seg at når du først har en AI som faktisk kjenner bedriften din inn og ut, jobber 24 timer i døgnet og aldri tar ferie, så begynner du å lure på hva en ansatt egentlig er.

Mac er ikke svaret, og det tok oss tid å innse det

La meg være tydelig på én ting før jeg sier noe stygt om Mac: Mac Studio M3 Ultra er en formidabel maskin for lokal LLM-kjøring. Med opptil 512 GB unified memory og rundt 819 GB/s minnebåndbredde slår den DGX Spark på rå inference-hastighet for store modeller. Hvis spørsmålet ditt er hvilken enhet som kan kjøre én tung modell fortest, så er svaret ofte M3 Ultra. Det er ikke en konkurranse vi prøver å vinne.

Men spørsmålet endret seg over tid. Det vi faktisk trenger for kundene våre, er ikke en maskin som kjører én stor modell raskt. Det er en plattform som kan kjøre flere modeller parallelt, der den ene aldri stjeler ressurser fra den andre. En kundeservice-agent som svarer på e-post mens en dokumentanalyse-agent leser kontrakter mens en bakgrunnsprosess holder vektorbasen oppdatert. Vi trenger noe som kan skaleres ved å legge til en ny enhet når lasten øker, ikke ved å bytte ut hele maskinen. Vi trenger en stack som matcher det datasentrene faktisk kjører, slik at koden vi skriver ikke må omskrives den dagen kunden vokser ut av rommet sitt.

Mac feiler på alle disse punktene. Ikke fordi maskinvaren er dårlig, men fordi hele filosofien bak den er en annen. Mac Studio er en kreativ-arbeidsstasjon som også kan kjøre språkmodeller. DGX Spark er en miniatyr av et datasenter. Det er en betydelig forskjell, og den blir tydelig først når du faktisk skal sette opp noe i produksjon.

På Mac er du fanget i Apples økosystem. MLX-rammeverket. Metal-shadere. Ingen CUDA, ingen NIM-containere, ingen direkte vei til skyen den dagen du trenger den. Hvis du har bygget noe på Apple Silicon og kunden plutselig trenger ti ganger så mye kapasitet, så starter du på nytt. På Spark kjører du nøyaktig den samme NVIDIA AI-stacken som Anthropic, OpenAI og halvparten av verdens AI-team bruker i datasentrene sine. Koden flytter seg uten endringer. Det er forskjellen mellom å kode i Swift for iOS og kode i TypeScript for hva-som-helst. Begge fungerer, og Swift er kanskje litt finere på iPhone, men hvis du skal ha samme app til å kjøre på server, browser, mobil og embedded-enhet, så velger du ikke Swift.

Det er litt rart å erkjenne, fordi vi er en norsk bedrift som liker fine ting som virker. Det føles riktig å bruke Mac. Men det viste seg at riktig følelse og riktig arkitektur er to forskjellige ting.

Det tekniske: hva du faktisk får med Spark

Spark er bygget rundt NVIDIAs GB10 Grace Blackwell Superchip, som er en monstrøs liten brikke for hva den er. Tjue ARM-kjerner i to klynger. En Blackwell GPU med 6144 CUDA-kjerner og femte generasjons Tensor Cores. Hundre og åttisju gigabyte unified memory delt mellom CPU og GPU på 273 GB/s. NVLink C2C som binder det sammen med fem ganger båndbredden av PCIe Gen 5. Hele dingsen trekker 240 watt og passer på pulten.

Det er to ting i denne lista som er mer interessante enn resten, og som er hovedgrunnene til at vi valgte den.

Det første er nettverkskortet. Spark kommer med en NVIDIA ConnectX-7 SmartNIC som har dual QSFP-porter med 200 Gb/s aggregert båndbredde. Dette er ikke et workstation-nettverkskort. Det er et datasenter-nettverkskort. Det støtter RDMA, GPUDirect, RoCE og InfiniBand. Den korte versjonen er at når du kobler en Spark mot din egen workstation, så går trafikken ikke gjennom CPU-en på vanlig TCP/IP-måte. Den går direkte fra GPU til GPU. Forskjellen er som å sende en pakke i posten kontra å skyve den over et bord. Mac har Thunderbolt 5, og det er bra, men det er ikke i samme klasse for distribuerte AI-laster.

Det andre er memory-arkitekturen, og her er det viktig å være ærlig om svakheten også. Sparks 273 GB/s er klart lavere enn M3 Ultras 819 GB/s. På modeller som er båndbredde-begrenset, slår Mac Spark grundig. Men Spark har 128 GB delt mellom CPU og GPU, og kan kobles sammen med en annen Spark for å nå 256 GB og kjøre modeller på opptil 405 milliarder parametere. Det betyr at båndbredde er en flaskehals for én modell, men ikke for arkitekturen som helhet. Vi får én Spark per kunde, typisk i kombinasjon med en kraftig RTX-workstation, og den enheten kan håndtere flere modeller, flere brukere og flere agenter parallelt uten at noe bremser noe annet.

Og det er her vi kommer til den delen som virkelig fikk oss til å lukke MacBook-en og bestille NVIDIA-kort.

Hva som skjer når du kobler Spark til en seriøs workstation

Vår referansearkitektur er en Spark koblet til en RTX-workstation med 5070 eller bedre, over enten 10 GbE eller QSFP. Spark kjører de tunge modellene, agentkjøring som krever stort kontekstvindu, og finetuning. Workstationen kjører det som trenger å være kjapt: embeddings-generering, vektoroppslag, raske spesialiserte modeller for klassifisering og oppsummering.

Det høres kanskje teknisk ut, men praktisk er det enkelt: når en agent på Spark trenger å gjøre to hundre embeddings-oppslag mot vektorbasen, så går ikke det via samme GPU som kjører hovedmodellen. Det går over nettet til workstationen, som spinner opp en spesialisert embeddings-modell, leverer resultatene, og legger seg ned igjen. Spark forblir fri til å gjøre det den er god på.

Dette er forskjellen mellom å kjøre alt i én monolittisk prosess og å bruke en mikrotjeneste-arkitektur der hver tjeneste skaleres uavhengig. På Mac måtte alt deles på samme GPU og samme minnepool. På Spark pluss workstation kan du dele opp arbeidsmengden basert på hva hver enhet er best til. For en kunde som kjører to agenter parallelt, betyr det at den ene aldri blokkerer den andre. Det er en arkitektonisk ting, ikke en hastighetsting, og det er forskjellen mellom et leketøy og et produksjonssystem.

Greit. Maskinvaren har vi snakket om. Men maskinvare er aldri det interessante. Det interessante er hva du gjør med den, og det leder oss til det egentlige problemet vi prøver å løse.

Hvorfor ChatGPT er blitt et leketøy, og hva det betyr

Hvis du har brukt både ChatGPT og Claude det siste året, har du sannsynligvis merket det samme som meg. ChatGPT er blitt et leketøy. Claude får ting gjort. Det er ikke fordi den ene modellen er smartere i absolutt forstand. Det er fordi Claude faktisk kjører kode, leser filer, gjør tool-kall og fullfører oppgaver, mens ChatGPT prater om oppgaver og foreslår at du gjør dem selv.

Forskjellen er som mellom en kollega som svarer "det skal jeg se på" og en kollega som faktisk gjør det. Begge er hyggelige. Bare den ene er nyttig.

Men selv Claude, og dette er poenget, kjenner ikke bedriften din. Den kan kode, lese, analysere, men den vet ikke hva Tenki gjør, hvem kundene våre er, hvordan vi prater, eller hvilke prosjekter som er aktive akkurat nå. Hver samtale starter på null. Du må fortelle den hvem du er, hva selskapet driver med, og hva som er konteksten, før du kan komme til poenget. For en privatperson som bruker AI til å forklare kode eller skrive et brev, er det ikke noe stort problem. For en bedrift er det et veldig stort problem. Du trenger ikke en universell intelligens som er litt klok på alt. Du trenger en kollega som vet at Espen er kunden hos Kursagenten, at vi installerte en DGX Spark i Oslo i forrige måned, og at den e-posten som kom inn på fredag handler om en oppfølging fra et møte vi hadde før påske.

Hvordan kommer du dit? Det er det de fleste "AI for små bedrifter"-løsninger på markedet ikke klarer å svare på, fordi svaret krever litt mer enn en chatbot med en lang systemprompt.

Hvordan en agent faktisk lærer bedriften din

De fleste forsøk på å gi en AI bedriftskontekst er å lime hele bedriftsinfoen inn i en prompt. Det skalerer ikke. Prompten blir for lang, modellen mister fokus, og du må oppdatere den manuelt hver gang noe endres. Det er som å gi en ny ansatt en tjue siders bedriftshåndbok å lese opp før hver eneste oppgave. Ingen jobber sånn.

Det vi gjør i stedet er å bygge bedriftens hjerne som markdown.

Hver kunde, hvert prosjekt, hver leverandør, hver intern prosess får sin egen .md-fil i et Obsidian-vault. Lenker mellom filene gir konteksten. En kunde-fil linker til prosjekt-filer som linker til møtenotat-filer som linker tilbake til personene som var i møtet. Quartz gjør det publiserbart som en intern wiki for de ansatte, eller for AI-en, som er det samme. Dette er ikke et tilfeldig valg. Markdown kan leses av mennesker, redigeres uten spesielle verktøy, lagres i Git, søkes med grep, og overleves i femti år. CRM-systemet du kjøper i 2026 finnes ikke i 2030. Markdown finnes alltid. Det er en av de få teknologivalgene jeg gjør med full ro i magen.

Så indekserer vi alle disse filene i Qdrant. Qdrant er en vektordatabase, og kort fortalt fungerer den slik: hver markdown-fil konverteres først til en lang vektor av tall som fanger meningen i teksten. Så kan du finne relevante filer ved å søke med en lignende vektor. For utviklere som tenker i klassiske database-termer er forskjellen denne: en SQL-database kan svare på "hvor er notatet med ID 42". Qdrant kan svare på "hvilke notater er semantisk like denne forespørselen". Det er forskjellen mellom å slå opp og å forstå.

Når agenten skal svare på noe, henter den først relevante notater fra Qdrant og legger dem inn som kontekst før den genererer svaret. Den gjetter ikke fra trening. Den leser bedriftens egne notater i sanntid, hver gang. Dette kalles RAG, eller Retrieval-Augmented Generation, og det er fundamentalt forskjellig fra å fintune en modell på dataene dine. Fintuning er dyrt, statisk og vanskelig å oppdatere. RAG er billig, dynamisk og oppdaterer seg selv den dagen du legger til en ny markdown-fil.

Og her er den siste biten, som folk ofte glemmer: agenten skriver notater selv. Etter hvert møte, hver e-post, hver oppgave, lager den nye .md-filer eller oppdaterer eksisterende. De indekseres på nytt automatisk. Bedriftens kunnskap vokser som et levende organ, og den blir bedre jo lenger den får jobbe.

På Spark kjører hele denne stacken lokalt. Markdown-filene ligger på workstationen. Qdrant kjører i Docker. Embeddings-modellen kjører på workstationens RTX-kort. Hovedagenten kjører på Spark. Dataene forlater aldri huset. For en bedrift med GDPR-følsomme data, sensitive klientdokumenter, eller bare en sunn skepsis til amerikanske skytjenester, er dette uvurderlig. Og det er der Spark slår Mac igjen, ikke fordi Mac ikke kunne kjørt deler av det samme, men fordi hele stacken er bygget for samme verden som datasentrene som driver bransjen.

Hva dette ser ut som i praksis

Forestill deg at en kunde sender en e-post på fredag klokken ti på kvelden om en spesifikk levering. På en bedrift uten dette systemet, ligger den uleste til mandag morgen. Da må noen først bruke en halvtime på å sette seg inn i konteksten før de kan svare. På et system som det vi bygger, leser agenten e-posten ett minutt etter at den kom inn. Den slår opp i Qdrant og finner ut hvem kunden er, hvilke leveranser som er aktive, og hva som er siste status. Den finner relevante notater fra de siste tre månedene. Den genererer et utkast til svar med korrekt kontekst. Avhengig av tillitsnivå sendes svaret enten direkte, eller flagges for godkjenning fra et menneske mandag morgen. Mennesket som tar over mandag, har et nesten ferdig svar med all relevant kontekst, ikke en ulest e-post fra fredag.

Dette er ikke fremtidsmusikk. Vi har dette kjørende hos kunder nå.

Og det er her det blir litt rart. For når du først har sett en sånn ting i drift hos en kunde i tre måneder, så begynner du å lure på spørsmålet jeg lovte å komme tilbake til.

Hva er egentlig en ansatt?

Tenk litt på regnestykket. En menneskelig kundeservicemedarbeider i en norsk SMB koster mellom 600 000 og 800 000 i året med sosiale kostnader. Hen jobber syv og en halv time om dagen, fem dager i uken, omtrent 230 dager i året, totalt rundt 1700 timer. Resten av tiden, godt over 7000 timer i året, er bedriften ubemannet på det området. Det er natt, helger, ferier, sykedager, kursdager, og alle de timene man trenger for å være menneske.

En agent som kjører på Spark jobber 8760 timer i året. Den koster strøm, og siden Spark trekker 240 watt blir det rundt 5000 kroner i året på norske strømpriser. Maskinvaren koster det den koster, men avskrives over tre til fem år. Den blir ikke syk. Den slutter ikke. Den krever ikke ferie. Den glemmer ikke hva som ble sagt for tre måneder siden. Den er ikke i dårlig humør på fredag.

Hva er den ansatte i dette bildet? Hva betyr det å ha ansatte?

Jeg vet at dette begynner å høres ut som et TED-foredrag, og jeg lover at jeg ikke prøver å skremme noen. Men jeg tror ærlig talt vi er inne i en periode der det grunnleggende konseptet er i endring. Det betyr ikke at folk forsvinner. Vi trenger fortsatt mennesker til strategi, relasjoner, kreativ retning, og alt det andre som faktisk krever et menneske. Å være menneske mot et annet menneske kan ikke automatiseres bort, og jeg tror heller ikke det kommer til å skje. Men en del av jobbene som tradisjonelt har krevd en lønnet stilling, som saksbehandling, dokumentsortering, første-linje kundeservice, leverandøroppfølging, kan nå gjøres av et system som kjører kontinuerlig, ikke gjør samme typer feil som mennesker, og blir bedre over tid.

For norske SMB-er er denne endringen mer dramatisk enn folk innser. Vi har et arbeidsmarked med strenge regler, høye lønninger, og en kultur der man ikke ansetter lett. Mange små bedrifter tar ikke neste steg fordi første ansatte er for risikabel. Du forplikter deg til en person, en lønn, en juridisk struktur, en HR-prosess. En AI-medarbeider har ingen oppsigelsesrettigheter. Den er ikke en juridisk person. Den er bare en tjeneste som leverer arbeid. Det betyr at en gründer som tidligere måtte velge mellom å brenne ut eller å ansette, plutselig har en tredje vei.

Hva det gjør med samfunnet vårt vet jeg ikke. Hva det gjør med bedriftene som forstår det først, det vet jeg ganske godt. De kommer til å være i en helt annen posisjon enn de som venter til 2028 med å ta dette seriøst.

Tilbake til der vi startet

Vi gikk vekk fra Mac av tre grunner. Den skalerer ikke til datasenter-stack. Den kobler ikke godt til ekstern hardware over reelle nettverk. Den fanger deg i et økosystem som ikke matcher hvor AI-bransjen faktisk er.

DGX Spark er ikke perfekt. Minnebåndbredden er lavere enn Apples beste. Prisen er høyere enn en Mac mini. Du må kunne Linux og NVIDIAs stack for å få den til å fly. Men den er bygget for samme verden som datasentrene som driver AI-revolusjonen, og det betyr at det du bygger på den, faktisk fungerer der ute. Den er en miniatyr av fremtiden, ikke et imponerende stykke maskinvare for nåtiden.

Og det den lar oss bygge, en agent som kjenner bedriften din inn og ut, jobber kontinuerlig og blir bedre over tid, er ikke en chatbot. Det er noe annet. Vi kaller det en AI-medarbeider fordi det er det nærmeste vi har av et ord, men jeg er ikke sikker på at det ordet kommer til å overleve denne dekaden. Vi kommer sannsynligvis til å trenge nytt språk for det vi bygger, fordi det vi bygger ikke helt passer inn i de gamle kategoriene.

Men det er en samtale for en annen tekst. For nå holder det å si at hvis du driver en norsk SMB og lurer på om dette er noe du burde tenke på, så er svaret ja. Og hvis du har spørsmål om hva det faktisk innebærer, så vet du hvor du finner oss.

---

Vi er midt i flere Spark-deployments og deler gjerne erfaringer. Ta kontakt hvis dere vurderer noe lignende, eller bare vil ha en ærlig vurdering av om det er riktig for dere.