GGUF-format: en komplett guide till lokal LLM-inferens

Vad är GGUF?

GGUF, kort för GGML Unified Format, är ett binärt filformat som paketerar modellvikter, tokeniserardata, arkitekturmetadata och kvantiseringsinformation i en enda, portabel fil för inferens med GGML-baserade körmiljöer, särskilt llama.cpp.

GGUF löser ett distributionsproblem för LLM. Många modellformat kräver att användare håller flera filer tillsammans, inklusive modellvikter, tokeniserarfiler, konfigurationsfiler och arkitekturspecifik laddningskod. GGUF förenklar detta genom att göra modelfilen i stor utsträckning självbeskrivande.

En GGUF-fil innehåller typiskt:

• Modelltensorer
• Kvantiserade eller okvantiserade vikter
• Tokeniserarens ordförråd
• Tokeniserarkonfiguration
• Modellarkitekturmetadata
• Kontext-inställningar för längd
• Inbäddningsdimensioner
• Antal attention-huvuden
• RoPE-konfiguration
• Tensornamn, former och datatyper

Huvudidén är att filen beskriver sig själv. Körmiljön kan inspektera metadata, förstå arkitekturen, ladda tokeniseraren och mappa tensorerna utan att förlita sig på en separat config.json eller tokeniserarmapp.

Det betyder inte att varje GGUF-fil är universellt kompatibel med varje körmiljö för alltid. Körmiljön måste fortfarande stödja modellarkitekturen och de tensortyper som används i filen. Men GGUF gör den kompatibiliteten mycket enklare än äldre format eftersom filen bär med sig mycket mer strukturerad information.

Fyra definierande egenskaper hos GGUF är:

1. Distribuering i en enda fil
2. Stöd för minnesmappning för effektiv inläsning
3. Utbyggbar typad nyckel-värde-metadata
4. Stöd för många kvantiseringstyper, från aggressiva lågbitar till full precision

GGUF introducerades som en del av ekosystemet kring llama.cpp och GGML år 2023. Det är nu det dominerande formatet för distribution av kvantiserade lokala LLM:er på Hugging Face.

GGUF vs. GGML

GGML (Georgi Gerganov Machine Learning) var föregångaren till GGUF. Det var viktigt eftersom det hjälpte till att göra tidig lokal inferens möjlig. Men det hade praktiska begränsningar när ekosystemet växte bortom de ursprungliga LLaMA-modellerna.

Vanliga problem med GGML inkluderade:

• Mindre flexibel metadatahantering
• Fler arkitekturspecifika laddningsantaganden
• Tokeniserar- och konfigurationshantering som var mindre självbärande
• Svårare utbyggbarhet när nya modellfamiljer dök upp

GGUF adresserade dessa begränsningar med ett mer strukturerat format. Det introducerade typad metadata, bättre tokeniserar-inbäddning och en tydligare fillayout. Detta gjorde det enklare för llama.cpp och relaterade verktyg att stödja fler arkitekturer utan att ständigt behöva designa om laddningskedjan.

För användare är den viktiga skillnaden enkel: GGUF är det moderna formatet. Om du laddar ner modeller idag bör du nästan alltid välja GGUF i stället för äldre GGML-filer.

GGUF vs. GPTQ och AWQ

När du undersöker filformaten stöter du säkert på GGUF, GPTQ (Generative Post-Training Quantization) och AWQ (Activation-Aware Weight Quantization). De diskuteras ofta tillsammans eftersom alla tre används för att göra LLM-inferens mer effektiv. Men de är inte identiska kategorier.

GGUF är i första hand ett filformat och ett distributionskärl. Det stöder många kvantiseringstyper och förknippas nära med lokal inferens i stil med llama.cpp.

GPTQ och AWQ är kvantiseringsmetoder och ekosystem som ofta används för GPU-optimerad inferens, särskilt på NVIDIA-hårdvara via ramverk som Transformers, ExLlama, AutoGPTQ och vLLM-kompatibla arbetsflöden.

Om ditt mål är maximal kompatibilitet över bärbara datorer, stationära datorer, Apple Silicon och blandad hårdvara är GGUF oftast det säkrare valet.

Om ditt mål är maximal genomströmning på dedikerade NVIDIA-inferensservrar kan GPTQ, AWQ, FP8 eller andra GPU-optimerade serverformat vara mer lämpliga.

Varför använda GGUF?

GGUF blev populärt eftersom det löser praktiska distributionsproblem. Jag har också kommit att tycka att de är så smidiga när jag kör lokalt utan allt konfigurationskrångel.

Att köra lokala LLM:er brukade innebära splittrad verktygskedja, stora okomprimerade vikter, inkompatibla modellformat och krångliga installationssteg. GGUF kan nu hjälpa dig att standardisera en stor del av det arbetsflödet.

I stället för att tänka på många separata filer och inläsningsskript kan användare fokusera på att välja rätt modell, välja en kvantiseringsnivå och köra inferens.

Kör modeller lokalt

GGUF låter dig köra LLM:er på din egen maskin. Det innebär:

• Ingen kostnad per token via API
• Inget beroende av en hostad inferenstjänst
• Ingen behov av att skicka promptar till ett tredjeparts-API
• Offline-inferens är möjlig efter att modellen laddats ner

Detta är särskilt användbart för integritetskänsliga arbetsflöden. Utvecklare vill kanske inte skicka proprietär kod, interna dokument, kundregister eller konfidentiella promptar till ett externt API.

Lokal inferens är inte automatiskt säker i sig. Du behöver fortfarande hantera din maskin, loggar, applikationer och åtkomstkontroll på rätt sätt. Men GGUF gör privat lokal distribution mycket mer tillgänglig.

För praktiska övningar i att köra modeller lokalt, se våra handledningar om att serva Mistral Medium 3.5 med SGLang, att köra DeepSeek V4 Flash lokalt, att köra den effektiva Bonsai 1-bit-modellen på en gammal laptop och att köra MiniMax M2 lokalt som kodassistent.

Hårdvaruflexibilitet

GGUF är användbart eftersom det fungerar över många hårdvarukonfigurationer.

Beroende på körmiljö och backend kan GGUF-modeller köras på:

• Maskiner endast med CPU
• NVIDIA-GPU:er via CUDA
• Apple Silicon via Metal
• AMD-GPU:er via HIP eller Vulkan
• Intel-GPU:er via SYCL eller Vulkan
• Vissa ARM- och mobilmiljöer

Denna flexibilitet är en stor anledning till att llama.cpp blev inflytelserikt. Det var inte designat enbart för högklassiga server-GPU:er. Det var designat för att göra lokal inferens möjlig på ett brett spann av hårdvara.

Till exempel kan en Mac-användare förlita sig på Metal-acceleration, medan en Linux-stationär användare kan använda CUDA eller Vulkan. En användare endast med CPU kan fortfarande köra mindre kvantiserade modeller, även om genereringshastigheten blir långsammare.

Brett ekosystemstöd

GGUF stöds av många verktyg för lokal inferens. Exempel inkluderar:

• llama.cpp för kommandorads- och serverinferens
• Ollama för CLI-fokuserad modellhantering och API-åtkomst
• LM Studio för ett skrivbords-GUI
• GPT4All för integritetsfokuserad lokal chatt
• KoboldCpp för lokal rollspel- och textgenereringsarbetsflöden
• Jan och Open WebUI för lokala AI-gränssnitt

Detta är viktigt eftersom användare inte är låsta till ett gränssnitt. Samma generella modellformat kan användas i olika arbetsflöden.

En utvecklare kan benchmarka en modell med llama.cpp, chatta med den i LM Studio, serva den via Ollama och koppla den till ett webbläsar-UI via Open WebUI.

Distribution via Hugging Face

Hugging Face har blivit en stor distributionshubb för GGUF-modeller.

Källa: Hugging Face

Många populära öppenviktiga modeller får GGUF-varianter uppladdade av communityn kort efter släpp. Dessa repo:n innehåller ofta flera kvantiseringsalternativ så att användare kan välja en modell som passar deras hårdvara.

Vanliga uppladdade varianter inkluderar:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0
• IQ4_XS
• IQ3_M
• IQ2_XXS

Detta innebär att manuell konvertering ofta är onödig. För de mest populära modellerna har någon i communityn redan skapat GGUF-filer för vanliga kvantiseringsnivåer.

Detaljstyrd kontroll av storlek kontra kvalitet

GGUF ger användare finfördelad kontroll över avvägningen storlek–kvalitet. Du kan välja:

• Mindre kvantiseringar för minnessvaga maskiner
• Mellannivåkvantiseringar för balanserad vardagsanvändning
• Högre bitkvantiseringar för kodning, resonemang eller strukturerad output
• Full eller nästan full precision när minne inte är en begränsning

Denna flexibilitet är en av formatets största fördelar. I stället för ett enda fast distributionsmål låter GGUF användare anpassa samma modellfamilj till många hårdvarunivåer.

Hur fungerar GGUF?

En GGUF-fil är organiserad i tre huvuddelar:

1. Header
2. Metadata och tensorinformation
3. Tensordata

Den exakta strukturen definieras av GGUF-specifikationen. Det viktiga är att metadata och tensorinformation kommer före den råa tensordatan, vilket gör att en körmiljö kan förstå vad den är på väg att läsa in.

Headern

Headern identifierar filen som GGUF och talar om för körmiljön hur resten av filen ska tolkas. Den inkluderar:

• Magiskt nummer för GGUF
• Formatversion
• Antal tensorer
• Antal metadata-nyckelvärden

Moderna GGUF-filer använder vanligtvis GGUF version 3.

Inferensmotorer kontrollerar det magiska numret först. Om filen inte börjar med den förväntade GGUF-identifikatorn kan körmiljön avvisa den innan den försöker tolka tensorer eller allokera minne.

Detta är ett enkelt men viktigt steg för säkerhet och tillförlitlighet. Det förhindrar att en körmiljö av misstag behandlar en orelaterad binärfil som en modell.

Metadata med nyckel–värde-par

GGUF-metadata är ett typat nyckel–värde-lager. Denna metadata kan beskriva:

• Allmän modellinformation
• Arkitekturfamilj
• Kontextlängd
• Inbäddningsstorlek
• Antal lager
• Antal attention-huvuden
• RoPE-parametrar
• Tokeniserarens ordförråd
• Specialtoken
• Kvantiseringsinformation

Nycklar är vanligtvis namnområdesindelade. Exempel inkluderar:

• general.architecture
• general.alignment
• llama.context_length
• tokenizer.ggml.tokens

Namnområden är viktiga eftersom de gör det möjligt för GGUF att stödja många arkitekturer utan att ändra hela filformatet. En modell i LLaMA-familjen kan använda llama.*-nycklar, medan andra modellfamiljer kan använda sin egen arkitekturspecifika metadata.

Detta är en anledning till att GGUF anpassade sig väl till modeller bortom den ursprungliga LLaMA-familjen, inklusive arkitekturer som Qwen, Mistral, Gemma, DeepSeek, Phi och andra.

Tensorinformation och tensordata

Efter metadatan lagrar filen tensorinformation och tensordata.

Tensorinformationen beskriver:

• Tensorns namn
• Form
• Datatyp
• Offset in i tensordatasektionen

Tensordatasektionen innehåller de faktiska modellvikterna. Dessa vikter kan lagras i full precision eller i en av GGUF:s stödda kvantiserade tensortyper.

GGUF använder ett alignmentsvärde definierat i metadatan, vanligtvis general.alignment. Många GGUF-filer använder 32-byte-alignment, men det korrekta sättet att beskriva detta är att alignment styrs av metadata snarare än att vara hårdkodat permanent.

Alignment spelar roll eftersom det gör att körmiljöer kan komma åt tensorblock effektivt.

Minnesmappning

En av GGUF:s praktiska fördelar är minnesmappning, ofta kallad mmap.

Med minnesmappning kan operativsystemet mappa modelfilen till virtuellt minne i stället för att tvinga körmiljön att kopiera hela filen till RAM i förväg.

Detta kan få modellstart att kännas mycket snabbare, särskilt på SSD:er. Det låter också operativsystemet växla modelldata in och ut vid behov.

Men minnesmappning är inte magi. Modellen behöver fortfarande tillräcklig praktisk minnesbandbredd och tillgängligt RAM eller VRAM för att fungera väl. Om ditt system ständigt växlar från disk kan inferens bli långsam.

Ett bättre sätt att tänka på mmap är detta:

• Det förbättrar inläsningseffektiviteten
• Det minskar onödiga kopieringar
• Det låter OS:et hantera växling
• Det eliminerar inte inferensens minneskrav

Förstå GGUF:s kvantiseringstyper

Kvantisering komprimerar modellvikter till representationer med lägre precision.

I stället för att lagra varje vikt som ett 16-bitars flyttal lagrar en kvantiserad modell approximativa värden med färre bitar. Detta minskar diskutrymme, RAM- och VRAM-användning samt trycket på minnesbandbredd.

Nyckelinsikten är att många neurala nätvikter inte behöver full flyttalsprecision under inferens. En noggrant kvantiserad modell kan bevara mycket av den ursprungliga modellens beteende och samtidigt bli dramatiskt mindre.

Namngivning av GGUF-kvantisering

GGUF-kvantiseringsnamn följer vanligtvis detta mönster:

• Q betyder kvantiserad
• Siffran antyder ungefärliga bitar per vikt
• K avser k-quant-familjen
• S, M och L betyder vanligtvis små, medelstora och stora varianter

Exempel inkluderar:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0

Namnet är en användbar vägledning, men det är inte alltid ett exakt påstående om total filstorlek. Verklig filstorlek beror på tensormix, arkitektur, metadata, tokeniserarstorlek och om vissa tensorer förblir i högre precision.

Vanliga GGUF-kvantiseringstyper

Dessa siffror är approximationer för täta modeller i 7B-klassen. Nyare arkitekturer, mixture-of-experts-modeller, större tokeniserare och olika tensorlayouter kan ändra den faktiska filstorleken.

I praktiken blev Q4_K_M ett populärt standardval eftersom det ger en stark balans mellan storlek och kvalitet. Många användare tycker att det är tillräckligt bra för allmän chatt, sammanfattning, omformulering och utforskande lokalt AI-arbete.

Q5_K_M och Q6_K är ofta bättre val för mer krävande arbetsbelastningar, såsom kodning eller fler-stegs instruktionsefterföljd

Anledningen är enkel: dessa uppgifter är mer känsliga för små kvalitetsförsämringar.

K-quants vs. I-quants

K-quants är den allmänt använda kvantiseringsfamiljen bakom format som Q4_K_M, Q5_K_M och Q6_K.

De använder grupperade kvantiseringsscheman med skalningsinformation som hjälper till att bevara modellbeteendet samtidigt som minneskraven minskas. De är populära eftersom de är pålitliga, brett stödda och lätta att hitta i communityns GGUF-släpp.

I-quants, ofta skrivna som IQ-format, är nyare kvantiserings typer såsom:

• IQ4_XS
• IQ3_M
• IQ2_XXS
• IQ1_S

I-quants är utformade för att uppnå bättre kvalitet vid mycket små storlekar. De kan använda tekniker som viktighetsmedveten kvantisering och icke-linjära kvantiseringskodböcker. Vissa arbetsflöden använder en viktighetsmatris, ofta kallad imatrix, för att hjälpa till att bevara viktigare vikter under kvantiseringen.

Avvägningen är komplexitet. I-quants kan ge utmärkta resultat i fråga om storlek–kvalitet, särskilt vid mycket låga bitrater, men de kan kräva mer noggranna kvantiseringsarbetsflöden och körstöd.

För de flesta nybörjare är K-quants fortfarande den enklaste startpunkten.

Välja en kvantiseringsnivå för din hårdvara

Tabellen nedan ger praktiska startpunkter. Se dem som tumregler, inte strikta garantier. Kontextlängd, operativsystemets overhead, GPU-offload, KV-cache-storlek och den specifika modellarkitekturen kan alla ändra minneskraven.

Allmänna tumregler:

• Använd Q4_K_M som ett säkert standardval för de flesta lokala inferenser.
• Använd Q5_K_M när kvalitet är viktigare än att spara varje gigabyte.
• Använd Q6_K eller Q8_0 när minne finns tillgängligt och du vill ha bättre fidelity.
• Undvik Q2_K för seriöst arbete om du inte testar extremt minnesbegränsade scenarier.
• Lämna extra minne för KV-cachen, särskilt när du använder långa kontextfönster.

KV-cachen är lätt att förbise. En modell kan få plats i RAM vid kort kontextlängd men misslyckas eller bli långsam vid mycket längre kontextlängd eftersom cachen växer med sekvenslängden.

GGUF-ekosystemet

GGUF:s antagande drivs lika mycket av verktygen som av själva formatet.

Ett format blir bara användbart när användare enkelt kan ladda ner, köra, inspektera, konvertera och serva modeller. GGUF gynnas av ett starkt ekosystem över kommandoradsverktyg, skrivbordsappar, API:er och hostade modellrepo:n.

1. llama.cpp

llama.cpp är den ursprungliga och viktigaste körmiljön för GGUF. Det är en lättvikts C/C++-inferensmotor skapad av Georgi Gerganov och underhållen av GGML-communityn. Dess huvudmål är att möjliggöra effektiv LLM-inferens med minimal setup på många hårdvaruplattformar.

Modern llama.cpp stöder många backends, inklusive:

• CPU
• CUDA för NVIDIA-GPU:er
• Metal för Apple-enheter
• Vulkan
• HIP för AMD-GPU:er via ROCm
• SYCL för Intel-GPU:er
• OpenCL i utvalda miljöer
• Andra specialiserade backends som CANN, OpenVINO och WebGPU, beroende på plattformsstöd

Det inkluderar också verktyg för konvertering, kvantisering, servering, benchmarkning och kommandoradsinferens. Vanliga verktyg inkluderar:

• convert_hf_to_gguf.py
• llama-quantize
• llama-cli
• llama-server
• llama-bench

Kommandona för att skapa en grundläggande CPU-CMake-build är:

cmake -B build
cmake --build build --config Release

För vissa konfigurationer behöver vissa flaggor läggas till i det första av dessa två kommandon:

• Inaktivera Apple Metal på macOS (aktiverat som standard): -DGGML_METAL=OFF
• Vulkan-build: -DGGML_VULKAN=1
• CUDA-build för NVIDIA-GPU:er: -DGGML_CUDA=ON

Observera att de aktuella byggena använder GGML_*-CMake-alternativ såsom GGML_CUDA, GGML_VULKAN och GGML_HIP.

2. Ollama

Ollama är ett av de enklaste sätten att köra lokala modeller. Det erbjuder:

• Ett enkelt CLI
• Nedladdning och hantering av modeller
• Ett lokalt REST-API
• Officiella Python- och JavaScript-bibliotek
• Integration med många lokala AI-frontends

Ollama lagrar och hanterar modeller åt dig, så användaren interagerar vanligtvis inte direkt med .gguf-filer. Men Ollama är byggt kring llama.cpp-kompatibel lokal inferens och kan också importera GGUF-filer via ett Modelfile-arbetsflöde.

Ollama exponerar ett lokalt API på:

http://localhost:11434/api

Två vanliga ändpunkter är:

• /api/generate för promptkomplettering
• /api/chat för chattliknande meddelanden

För nybörjare är Ollama ofta den snabbaste vägen från noll till lokal inferens.

3. LM Studio

Källa: LM Studio

LM Studio är en skrivbordsapplikation för att upptäcka, ladda ner och chatta med lokala modeller. Den är användbar för användare som föredrar ett grafiskt gränssnitt i stället för kommandoradsverktyg.

4. GPT4All

Källa: GPT4All

GPT4All är en annan plattformsoberoende lokal AI-applikation med fokus på privata, lokala chatbot-arbetsflöden. Den stöder GGUF-modeller och ger en nybörjarvänlig miljö för lokal inferens.

Dessa verktyg gör GGUF tillgängligt för icke-specialister. Användare behöver inte förstå CMake, tensorlayouter eller kvantiseringsinternals bara för att prova en lokal modell.

Så kommer du igång med GGUF-modeller

Det finns två praktiska sätt att komma igång:

1. Använd Ollama för den enklaste upplevelsen.
2. Använd llama.cpp direkt för mer kontroll.

Köra en modell med Ollama

Det enklaste arbetsflödet är att ladda ner modellen och starta en interaktiv chattsession:

ollama pull llama3.3
ollama run llama3.3

För att anropa modellen från Python med REST-API:t:

import requests

payload = {
    "model": "llama3.3",
    "prompt": "Give me three practical use cases for GGUF.",
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/generate",
    json=payload
)

print(response.json()["response"])

För chattliknande applikationer, använd /api/chat:

import requests

payload = {
    "model": "llama3.3",
    "messages": [
        {"role": "user", "content": "What is GGUF used for?"}
    ],
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/chat",
    json=payload
)

print(response.json()["message"]["content"])

Fältet stream: false är viktigt för enkla skript. Utan det returnerar Ollama en ström av JSON-objekt i stället för ett slutligt JSON-svar.

Du kan också använda Ollamas officiella Python-bibliotek:

from ollama import chat

response = chat(
    model="llama3.3",
    messages=[
        {"role": "user", "content": "Explain GGUF quantization simply."}
    ]
)

print(response.message.content)

Köra en GGUF-fil med llama.cpp

Om du redan har en .gguf-fil kan du köra den direkt med llama.cpp efter att ha byggt projektet.

Exempel:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Explain the difference between GGUF and GPTQ." \
  -n 256

Om du har GPU-stöd aktiverat kan du offloada lager till GPU:n:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Summarize GGUF in five bullet points." \
  -n 256 \
  -ngl 99

Flaggan -ngl styr hur många lager som offloadas till GPU:n. Ett högt värde som 99 används ofta för att offloada så mycket som möjligt, givet att modellen får plats i VRAM.

För API-servering, använd llama-server:

./build/bin/llama-server \
  -m models/model.Q4_K_M.gguf \
  -ngl 99 \
  --host 127.0.0.1 \
  --port 8080

Detta ger dig ett lokalt servergränssnitt för att integrera llama.cpp i applikationer.

Konvertera en Hugging Face-modell till GGUF

De flesta användare behöver inte konvertera modeller manuellt eftersom communityns GGUF-släpp är allmänt tillgängliga.

Men manuell konvertering är användbar när:

• Du har finjusterat din egen modell
• Ingen GGUF-version finns ännu
• Du vill styra kvantiseringsprocessen själv
• Du behöver en specifik kvantiserings typ

Ett typiskt arbetsflöde är:

1. Ladda ner en Hugging Face-modell.
2. Konvertera den till GGUF.
3. Kvantisera GGUF-filen.

Exempel:

huggingface-cli download mistralai/Mistral-7B-Instruct-v0.3 \
  --local-dir mistral-7b

Konvertera sedan till GGUF:

python convert_hf_to_gguf.py mistral-7b \
  --outfile mistral-f16.gguf \
  --outtype f16

Kvantisera sedan:

./build/bin/llama-quantize \
  mistral-f16.gguf \
  mistral-q4_k_m.gguf \
  Q4_K_M

I nuvarande arbetsflöden med llama.cpp är convert_hf_to_gguf.py och llama-quantize de relevanta verktygen. Äldre handledningar kan hänvisa till föråldrade konverteringsskript eller äldre binärnamn.

Fördelar och begränsningar med GGUF-formatet

GGUF är optimerat för praktisk lokal inferens. Det är inte en universell ersättning för varje modellformat eller serverstack.

För CPU-först, Apple Silicon, blandad hårdvara och integritetsfokuserad inferens är GGUF ofta ett utmärkt val.

För NVIDIA-serverdrift med hög genomströmning kan andra format och motorer vara snabbare beroende på modell, batchstorlek, kvantiseringsmetod och serverramverk.

Avslutande tankar

GGUF gör lokal LLM-inferens praktisk genom att paketera allt en körmiljö behöver (vikter, tokeniserare, metadata, kvantiseringsinfo) i en portabel fil. Dess verkliga styrka är ekosystemet runt det: llama.cpp, Ollama, LM Studio och Hugging Face har alla gjort det till standardformatet för lokal AI-distribution.

För de flesta användare är vägen enkel: installera Ollama, hämta en modell och kör den. Q4_K_M är ett stabilt standardval; gå upp till Q5_K_M eller Q6_K när du behöver bättre resonemang eller kodningsresultat och har minne att avvara.

Om du vill gå djupare i LLM-distribution, modelloptimering och arbetsflöden för lokal inferens bör du utforska karriärspåren Associate AI Engineer for Data Scientists eller Associate AI Engineer for Developers.