Run an Ollama Local Model and Create a Modelfile

Ollama can download a language model and run it on your own computer. Choose a local model explicitly, then check that the service and selected model are available before building another workflow around them.

After installing Ollama from the official download page, a concrete local example is:

ollama run gemma3:1b

The gemma3:1b library entry documents that model tag. It is an example to begin with, not a claim that one model is the best choice for every machine or task.

Run an Ollama local model before adding integrations

Ollama’s CLI reference describes running and managing models. Downloading a model and loading it into memory are separate steps, even when one command handles them for you.

To download this example explicitly:

ollama pull gemma3:1b

Then run it with a small, inspectable prompt:

ollama run gemma3:1b "Explain the difference between HTML and CSS in two sentences."

Read the answer rather than treating a successful response as evidence that it is correct. A language model can produce a plausible explanation with mistakes, even when the installation and inference both work.

A small task is useful for checking the workflow before choosing a more demanding model. Model files, context, memory use, and execution speed all belong to the actual model and hardware combination; avoid deciding from the name alone.

Inspect downloaded and running models separately

The CLI can show what is stored locally and what is currently loaded:

ollama list
ollama ps

A downloaded model need not remain loaded. The running-models endpoint documentation describes the corresponding service view.

When a model name is not found, compare the full tag in the command with the installed list. A missing tag and an unavailable service are different failures and deserve different checks.

For the local API, first inspect the model list:

curl -sS http://localhost:11434/api/tags

The list-models API documents that response. If the connection is refused, investigate whether the Ollama service is running before changing the prompt or downloading the same model again.

For a CLI setup without an app-managed service, start the server in another terminal:

ollama serve

Keep that process running while you use the other commands. If the app already manages the service, use its existing instance rather than starting a second server on the same port.

Create a local variant with a Modelfile

A Modelfile can keep a base model choice, parameters, and a system message together. Save this as Modelfile:

FROM gemma3:1b
PARAMETER temperature 0.2
SYSTEM """
You explain small web development examples.
State assumptions and identify details that need verification.
Keep code examples focused on the question.
"""

Create and run the named variant:

ollama create web-notes -f ./Modelfile
ollama run web-notes "Explain why a fixed height can conflict with aspect-ratio."

The Modelfile reference explains FROM, PARAMETER, and SYSTEM. Changing temperature affects generation behavior; it does not turn a model into a source of verified facts.

The system message is a repeatable starting instruction, not a security boundary or a guarantee of format compliance. Keep that distinction when a response will be used by another program.

I would keep the first custom variant narrow enough that its purpose is obvious from the file. A long prompt containing unrelated jobs is harder to evaluate when a response goes wrong.

Make one explicit local API request

With the service running and the model available:

curl -sS http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gemma3:1b",
    "prompt": "Explain what an HTML form submits in two sentences.",
    "stream": false
  }'

The generate endpoint documents the fields. Setting stream to false requests one response object instead of the default streamed output.

Inspect the returned object before extracting a field in your own application. Handle a failed request separately from a generated answer, and do not invent a fixed response for a nondeterministic example.

This request targets the service on the same computer. Calling a local URL does not establish what every surrounding integration, extension, or application does with the data.

Distinguish local execution from Ollama Cloud

Ollama also supports cloud models. Those requests are processed remotely, so the product name alone does not establish that inference stays on your device.

For a local workflow, check the actual model selection and integration configuration. The FAQ covers local operation and settings, including disabling cloud features when that is the intended boundary.

Local model files still need to be obtained initially. Once the required model and runtime are available, local inference can avoid depending on a hosted generation service, but a separate tool that performs web searches or other network actions is another dependency.

Keep sensitive material out of an unfamiliar integration until you understand its data path. Running a local model is one part of that assessment, not the whole answer.

Diagnose the task before choosing a larger model

A failed connection needs a service check. A missing model needs a tag or download check. An inaccurate answer needs task evaluation; more disk space is not a substitute for that distinction.

Compare a few representative questions with results you can verify. For code, run the example and inspect the behavior. For explanations, check the relevant primary documentation.

For an initial experiment, I would use one modest local model and one concrete job. Keep it when the control and usefulness justify the hardware and maintenance it asks for.

← Back to all articles