Ollama · Modelfile · modellhantering

Kör en modell som inte finns i Ollamas bibliotek: importera en GGUF med Modelfile

Fyra instruktioner räcker för att göra en nedladdad GGUF-fil till en namngiven modell med låsta inställningar — och ett kommando visar vad som faktiskt hamnade i Ollama.

Av C. Leijon · Publicerad · Senast granskad · 10 min läsning

Mörkt teknikrum med svarta serverrack, en vit konfigurationssida och gröna statuslampor.
Modelfilen binder ihop GGUF-filen, systemprompten och parametrarna innan modellen registreras i Ollamas lokala lagring.

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.

Fyra instruktioner till som finns men sällan behövs vid import

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ältExempelVad raden ska bevisa
Modellnamn i Ollamamin-modell-q4km-v1Att namnet är entydigt och versionerat, inte överskrivbart
KällfilExakt GGUF-filnamn med kvantiseringsbeteckning och storlek i byteVilken av modellens tio varianter som faktiskt kördes
Hämtad frånURL till modellkortet eller repositoriet, plus datumAtt filen går att hämta igen och att ursprunget är känt
ChecksummaSHA-256 över den nedladdade filen, beräknad före importenAtt det är samma bytes nästa gång — filnamn räcker inte
LicensLicensnamn och var texten finnsAtt villkoren är lästa och går att hitta igen
ModelfileSökväg i repot och commit som byggde modellenAtt inställningarna är versionshanterade, inte muntliga
Ändrade parametrarBara raderna som avviker från standardvärdet, med skälVad som är ett aktivt val och vad som är Ollamas grundläge
Ollama-versionVad ollama --version rapporterar vid byggetVad felsökningen ska jämföras mot när syntaxen ändras
Kontroll av byggetDatum då ollama show --modelfile lästes och vad som stämdeAtt importen är verifierad och inte bara utförd
BaslinjeprovFrågorna, svaren och datumet från provet efter importenVad 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

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.

Nästa steg

Skriv Modelfilen bredvid GGUF-filen, bygg modellen och läs ollama show --modelfile innan du kör ett enda riktigt anrop.

Välj rätt kvantisering först