Skip to main content

ollama systemd service

Supercharging Your Local Ollama Server: Network Access, Permanent Memory, and Extended Context

If you run LLMs locally on Linux using Ollama, you know how smooth and lightweight the installation experience is. However, out of the box, Ollama’s default configuration is tailored for a single-user desktop environment—binding strictly to localhost, unloading models from memory after 5 minutes of inactivity, and capping the context length to a standard limit.

If you are setting up a dedicated AI server on your local network, running a WebUI on another machine, or building RAG (Retrieval-Augmented Generation) applications, these defaults can get in your way.

In this post, we’ll explore how to tweak Ollama's systemd service file on Linux to:

1. Expose the API across your local network.

2. Keep models continuously loaded in memory (zero startup lag).

3. Extend the context window size up to 32,768 tokens.

The Customized systemd Service File

When installing Ollama on Linux, it registers a systemd unit file located at /etc/systemd/system/ollama.service.

Here is what an optimized production configuration looks like:

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=/usr/local/node/bin:/home/mihamina/.local/bin:/home/mihamina/bin:/usr/local/bin:/usr/bin"
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=32768"

[Install]
WantedBy=default.target

What Do These Three Environment Variables Do?

Let's dissect the three crucial Environment= parameters added to the default unit file.

1. OLLAMA_HOST=0.0.0.0:11434

Default: 127.0.0.1:11434

Why change it? By default, Ollama only listens on the loopback interface (localhost). Setting 0.0.0.0 allows Ollama to listen on all available network interfaces.

Use Case: This is mandatory if you want to access your Ollama server from another computer, a mobile app, or a web frontend (like Open WebUI) running on a separate machine on your local network.

2. OLLAMA_KEEP_ALIVE=-1

Default: 5m (5 minutes)

Why change it? Normally, Ollama unloads the model from VRAM/RAM after 5 minutes of idle time to conserve hardware resources. When a new query arrives later, you have to wait several seconds (or even half a minute for large models) while the model reloads into memory.

Use Case: Setting OLLAMA_KEEP_ALIVE=-1 keeps the active model permanently loaded in memory indefinitely. This ensures instantaneous responses every time you send a query.

3. OLLAMA_CONTEXT_LENGTH=32768

Default: Model-dependent (typically 2,048 or 4,096 tokens)

Why change it? Context length determines how much text (history, documents, code files) the model can read and remember in a single interaction. Bumping this value up to 32768 (32k tokens) enables long-document summarization, large code repository analysis, and deep multi-turn conversations.

A Crucial Note on VRAM Consumption: Expanding the context window significantly increases the memory required for the KV (Key-Value) Cache. Bumping context length from 4096 to 32768 can consume several extra gigabytes of VRAM. Make sure your GPU has enough memory budget to handle the larger context alongside the base model weights, otherwise Ollama may offload parts of the execution to system CPU/RAM, causing severe speed degradation.

How to Apply These Changes

If you want to edit your systemd configuration on your server, follow these quick steps:

Method A: Editing the unit file directly

Open /etc/systemd/system/ollama.service with root privileges:

sudo nano /etc/systemd/system/ollama.service

Paste your updated configuration (including the Environment= directives) under the [Service] section, then save and exit.

Method B: Systemd Override (Recommended Linux Practice)

Alternatively, systemd allows override drop-in files so your custom changes aren't overwritten when Ollama updates:

sudo systemctl edit ollama.service

Add your variables into the editor:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Reload and Restart

Once saved, inform systemd about the changes and restart the daemon:

sudo systemctl daemon-reload
sudo systemctl restart ollama

To verify that the service is running cleanly:

sudo systemctl status ollama

Verifying the Setup

1. Test Network Access: From another machine on the network, run:

curl http://<YOUR-SERVER-IP>:11434/api/tags

If it returns a JSON list of your downloaded models, network binding is working!

2. Monitor Model Persistence & Memory: Run a query, then check model status using:

ollama ps

You should see your model listed under UNTIL as Forever (indicating -1 keep-alive works).

Conclusion

By applying these three tweaks to your Ollama systemd unit file, you transform a desktop-centric local LLM tool into a robust, high-capacity host server capable of servicing your local network with low-latency responses and deep contextual understanding. Just keep an eye on nvidia-smi or system RAM metrics to ensure your hardware stays within healthy limits!

Popular posts from this blog

Undefined global vim

Defining vim as global outside of Neovim When developing plugins for Neovim, particularly in Lua, developers often encounter the "Undefined global vim" warning. This warning can be a nuisance and disrupt the development workflow. However, there is a straightforward solution to this problem by configuring the Lua Language Server Protocol (LSP) to recognize 'vim' as a global variable. Getting "Undefined global vim" warning when developing Neovim plugin While developing Neovim plugins using Lua, the Lua language server might not recognize the 'vim' namespace by default. This leads to warnings about 'vim' being an undefined global variable. These warnings are not just annoying but can also clutter the development environment with unnecessary alerts, potentially hiding other important warnings or errors. Defining vim as global in Lua LSP configuration to get rid of the warning To resolve the "Undefined global vi...
Read more

LazyGit AI Commit Message

Having AI‑generated commit messages directly integrated into LazyGit If you use LazyGit every day, you already know how it turns Git from a chore into something you can actually enjoy. But there is one part of the workflow that still tends to feel a bit tedious: writing good commit messages. In this post, I show how to plug OpenAI models directly into LazyGit using a tiny one‑file BASH script, so you can get AI‑generated commit messages based on your actual diffs, without waiting for external tools to catch up with the new OpenAI Responses API . The result is a minimal, focused tool you can drop into your setup today: lgaicm . It behaves like a mini aichat that does exactly one thing: generate commit messages from Git diffs, optimized for LazyGit. Why AI‑generated commit messages in LazyGit? Commit messages matter. They are the stor...
Read more

CopilotChat GlobFile Configuration

CopilotChat GlobFile Configuration Want to feed multiple files into GitHub Copilot Chat from Neovim without listing each one manually? Let's add a tiny feature that does exactly that: a file glob that includes full file contents . In this post, we'll walk through what CopilotChat.nvim offers out of the box, why the missing piece matters, and how to implement a custom #file_glob:<pattern> function to include the contents of all files matching a glob. Using Copilot Chat with Neovim CopilotChat.nvim brings GitHub Copilot's chat right into your editing flow. No context switching, no browser hopping — just type your prompt in a Neovim buffer and let the AI help you refactor code, write tests, or explain tricky functions. You can open the chat (for example) with a command like :CopilotChat , then provide extra context using built-in functions. That “extra context” is where the magic really happens. Built-in functio...
Read more