Du har hittat en modellvariant som inte finns i Ollamas bibliotek, laddat ner GGUF-filen och sitter med några gigabyte på disken utan ett sätt att köra dem. Vägen in heter Modelfile: en textfil på några rader som pekar ut filen, sätter körparametrarna och lägger på systemprompten. Ollama läser den, registrerar modellen i sin egen lagring och ger den ett namn du väljer. Det som gör importen värd besväret är inte att den går snabbt utan att den blir reproducerbar — filen kan ligga i ett repo bredvid koden som anropar modellen.
Skaffa filen och anteckna vad det är du importerar
Ollamas importdokumentation räknar upp tre vägar till en GGUF-fil: konvertera en Safetensors-modell med convert_hf_to_gguf.py från llama.cpp, konvertera en LoRA-adapter med convert_lora_to_gguf.py, eller ladda ner en färdig fil från en plats som Hugging Face. De flesta som läser den här artikeln har gjort det sista.
Innan du skriver en enda rad Modelfile: anteckna exakt vilken fil du har. Modellens namn räcker inte, eftersom samma modell brukar publiceras i ett tiotal kvantiseringar med olika filstorlek och olika kvalitet. Skriv ner filnamnet, kvantiseringsbeteckningen, filstorleken i byte och en checksumma. Skriv också ner var licensen står och vad den kräver — den frågan går inte att lösa i efterhand, och juridiken kring användningen ligger utanför den här sajten.
Kvantiseringen ska vara vald före nedladdningen, inte efter importen. Ollamas --quantize-flagga gäller enligt dokumentationen modeller i FP16 eller FP32, och de kvantiseringar importsidan listar som stödda är q8_0, q4_K_S och q4_K_M. En redan kvantiserad GGUF hamnar alltså inte i ett omkvantiseringsflöde: har du laddat ner fel variant laddar du ner rätt. Vad steget mellan varianterna kostar i minne och kvalitet står i artikeln om att välja kvantisering, och urvalskriterierna för själva modellen står i modellguiden.
Modelfilen: fyra instruktioner räcker
Formatet är en instruktion per rad, INSTRUCTION arguments, med # för kommentarer. Dokumentationen är tydlig med två saker som ofta missförstås: filen är inte skiftlägeskänslig, och instruktionerna får stå i vilken ordning som helst. Versalerna i exemplen finns bara för att skilja instruktionen från argumentet.
Den enda obligatoriska instruktionen är FROM. För en GGUF-fil skriver du sökvägen till filen, och dokumentationen anger att den ska vara antingen absolut eller relativ till Modelfilens plats — inte till katalogen du råkar stå i när du kör kommandot. Lägger du Modelfilen bredvid GGUF-filen blir raden kort och flytten till en annan maskin enkel.
# Modelfile
FROM ./min-modell-q4_K_M.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.4
PARAMETER top_p 0.9
PARAMETER stop "<|im_end|>"
SYSTEM """Du är en teknisk assistent. Svara på svenska, kortfattat och
utan att gissa. Saknas underlag i frågan: säg det i stället för att fylla ut."""
PARAMETER tar formen PARAMETER <parameter> <värde>. Sätt bara de parametrar du har ett skäl att flytta från standardläget, och skriv skälet som en kommentar bredvid. Dokumentationens standardvärden är utgångspunkten: temperature 0.8, top_k 40, top_p 0.9, min_p 0.0, repeat_penalty 1.0 (alltså avstängd), repeat_last_n 64, seed 0, num_predict -1 för obegränsad generering och num_ctx 2048. Den sista är den vanligaste källan till förvåning: en modell som marknadsförs med lång kontext körs ändå på 2048 tokens tills du säger något annat.
stop är ett specialfall. Behöver du flera stoppsekvenser skriver du flera separata stop-rader — det finns ingen listform. Vilka strängar som är rätt står i modellkortet, inte i Ollamas dokumentation.
SYSTEM """…""" sätter systemmeddelandet. Trippelcitattecknen är den dokumenterade formen för flerradiga strängar och behövs så fort prompten är längre än en rad. Det här är den instruktion som gör mest nytta i praktiken: i stället för att varje klient skickar sin egen variant av samma systemprompt ligger den i modellen, i en fil som går att granska i en pull request.
TEMPLATE anger hela promptmallen i Go:s template-syntax med variablerna {{ .System }}, {{ .Prompt }} och {{ .Response }}; dokumentationen påpekar att syntaxen är modellspecifik, så hämta den från modellkortet i stället för att hitta på en. ADAPTER lägger på en LoRA-adapter — men bara mot exakt den basmodell adaptern tränades mot, annars blir beteendet enligt dokumentationen oberäkneligt. MESSAGE <roll> <text> med rollerna system, user och assistant bygger exempelhistorik. REQUIRES <version> anger lägsta Ollama-version modellen kräver; dokumentationens exempel är 0.14.0.
Bygg modellen
Byggkommandot i Modelfile-referensen är ollama create choose-a-model-name -f <sökväg till filen>, följt av ollama run. Ligger Modelfilen i den katalog du står i räcker den kortare formen som importsidan visar.
ollama create min-modell -f ./Modelfile
ollama run min-modell
Ge modellen ett namn som säger vad den innehåller, inte vad du hoppas att den gör. Ett namn som bär kvantiseringen och en versionssiffra — min-modell-q4km-v1 — gör att du kan bygga en v2 med ändrad systemprompt utan att förlora möjligheten att jämföra de två.
Kontrollera ledigt diskutrymme före och efter importen. Ollama registrerar modellen i sitt bloblager, men dokumentationen lovar inte att varje installation använder exakt dubbelt utrymme. Behåll därför källfilen tills du har verifierat att modellen går att köra och mät sedan vad som faktiskt ligger kvar. Ligger Ollamas modellkatalog på en trång disk beskriver artikeln om att flytta modellkatalogen hur du sätter OLLAMA_MODELS innan du importerar, inte efter.
Prova att det blev det du bad om
Att kommandot skriver success betyder att modellen byggdes, inte att den byggdes med dina inställningar. Kontrollen är ollama show --modelfile, som skriver ut den Modelfile Ollama faktiskt har lagrat för modellen.
ollama show --modelfile min-modell
Läs tre saker i utdata. FROM-raden ska peka på en blobsökväg av typen .../models/blobs/sha256-<hex> och inte längre på din GGUF-fil. Det visar att den skapade modellen refererar till Ollamas bloblager; mät diskanvändningen separat om du behöver veta om filens byte har duplicerats på just din installation. Dina PARAMETER-rader ska stå kvar. Och SYSTEM-blocket ska vara ordagrant det du skrev, radbrytningar inräknade; en systemprompt som tappat sin sista rad är svår att upptäcka i ett vanligt svar.
Kör därefter ett litet innehållsprov, inte bara ett hälsningsanrop. Ställ en fråga där systemprompten borde märkas — be om något på svenska när prompten kräver svenska, eller ställ en fråga med för lite underlag när prompten säger att modellen ska påpeka det. Behöver du ett strängare svenskt prov finns fem fasta uppgifter med poängprotokoll i testpaketet för svenska. Kör provet en gång direkt efter importen och spara svaren: det är den baslinje du jämför mot nästa gång du ändrar en parameter.
Importkortet
En Modelfile i ett repo säger vad du bad om. Den säger inte vilken fil du utgick från, vem du hämtade den av eller vilken Ollama-version som byggde modellen. Anteckna det bredvid.
Exemplet nedan är påhittat och visar detaljnivån. Kopiera formen, inte värdena: filnamn, checksumma, digest och versioner ska vara det din egen import faktiskt rapporterar.
| Fält | Exempel | Vad raden ska bevisa |
|---|---|---|
| Modellnamn i Ollama | min-modell-q4km-v1 | Att namnet är entydigt och versionerat, inte överskrivbart |
| Källfil | Exakt GGUF-filnamn med kvantiseringsbeteckning och storlek i byte | Vilken av modellens tio varianter som faktiskt kördes |
| Hämtad från | URL till modellkortet eller repositoriet, plus datum | Att filen går att hämta igen och att ursprunget är känt |
| Checksumma | SHA-256 över den nedladdade filen, beräknad före importen | Att det är samma bytes nästa gång — filnamn räcker inte |
| Licens | Licensnamn och var texten finns | Att villkoren är lästa och går att hitta igen |
| Modelfile | Sökväg i repot och commit som byggde modellen | Att inställningarna är versionshanterade, inte muntliga |
| Ändrade parametrar | Bara raderna som avviker från standardvärdet, med skäl | Vad som är ett aktivt val och vad som är Ollamas grundläge |
| Ollama-version | Vad ollama --version rapporterar vid bygget | Vad felsökningen ska jämföras mot när syntaxen ändras |
| Kontroll av bygget | Datum då ollama show --modelfile lästes och vad som stämde | Att importen är verifierad och inte bara utförd |
| Baslinjeprov | Frågorna, svaren och datumet från provet efter importen | Vad nästa parameterändring ska jämföras mot |
Kopiera tom mall
IMPORTKORT — <modellnamn i Ollama> Importerad: <datum> Senast kontrollerad: <datum> Källfil ............ filnamn / kvantisering / storlek i byte Hämtad från ........ URL / datum Checksumma ......... SHA-256 före import Licens ............. namn / var texten finns Modelfile .......... sökväg i repot / commit Ändrade parametrar . rad / värde / skäl Systemprompt ....... i Modelfilen (ja/nej) / kort syfte Ollama-version ..... vad ollama --version rapporterade Kontroll av bygget . datum / FROM pekar på blob / parametrar kvar / SYSTEM ordagrant Baslinjeprov ....... frågor / svar / datum Nästa kontroll ..... när modellkortet eller Ollamas dokumentation ändras
Har du en importerad modell i drift hör de tre sista raderna hemma i driftkortet också, tillsammans med den rollback du redan har skrivit ned. En importerad modell är den variant som är svårast att återskapa av en efterträdare, eftersom den inte finns att hämta med ett ollama pull.
Källor
- Ollama Modelfile Reference — format,
FROMmot en GGUF-fil, parametertabellen med standardvärden,SYSTEM,TEMPLATE,ADAPTER,MESSAGE,REQUIRESoch noteringen att filen inte är skiftlägeskänslig - Ollama — Importing a Model: GGUF-import, vägar till en GGUF-fil,
ollama createoch kvantisering med--quantize - Ollama CLI —
ollama create -f Modelfile
Källorna kontrollerades 24 aug 2026 mot den publicerade dokumentationen på docs.ollama.com och mot motsvarande källfiler på huvudgrenen i Ollamas repositorium. Modelfile-syntaxen har ändrats mellan versioner och dokumentationen har flyttat: den äldre sökvägen docs/modelfile.md på GitHub svarar inte längre. Exempelsökvägarna är platshållare och inga tider, filstorlekar eller kvalitetssiffror för en importerad modell påstås här. Kontrollera artikeln igen när Ollama ändrar Modelfile-referensen eller listan över stödda kvantiseringar, eller senast 24 nov 2026.