Run large language models locally — no cloud, no API key, no data leaving your network
Ollama is an open-source tool that makes it straightforward to download, run, and manage large language models on your own hardware. It handles the complexity of model quantization, GPU acceleration, and API serving — you interact with it through a simple CLI or a local REST API that speaks the same language as the OpenAI API.
For a Linux SysAdmin, Ollama is the answer to a specific class of problems: situations where you want AI assistance but cannot or should not send data to a cloud provider. FERPA-regulated data, internal documentation containing sensitive configuration details, security-sensitive scripts, or simply environments where any external network call is prohibited.
Ollama also integrates directly with the other tools in this series — sgpt, aider, and fabric can all be pointed at a local Ollama instance instead of cloud APIs.
Ollama is free and open source (MIT license). The models it runs are also free — most are released under open licenses by Meta, Mistral, Google, and others. The only cost is your hardware.
The official install script handles everything — dependencies, systemd service, and GPU detection:
curl -fsSL https://ollama.com/install.sh | shOllama installs as a systemd service and starts automatically:
# Check service status systemctl status ollama # View logs journalctl -u ollama -fModels are stored in /usr/share/ollama/.ollama/models/ by default.
On systems with limited root partition space, change this before pulling models:
Ollama hosts a library of models at ollama.com/library. For SysAdmin work:
| Model | Size | Best For |
|---|---|---|
llama3.2 |
2-3 GB | Fast responses, general questions, light scripting tasks |
llama3.1:8b |
5 GB | Good balance of speed and quality for most SysAdmin tasks |
llama3.1:70b |
40 GB | Near cloud quality — needs substantial GPU VRAM or CPU RAM |
mistral |
4 GB | Strong at code and structured output, good for script generation |
codellama |
4-34 GB | Specialized for code — bash, Python, config file generation |
gemma2:9b |
5 GB | Google's open model — solid general purpose performance |
This drops you into an interactive session. Type your prompt, get a response,
continue the conversation. Type /bye to exit.
Ollama exposes a local REST API on port 11434 that is compatible with the OpenAI API format:
# Direct API call curl http://localhost:11434/api/generate \ -d '{"model": "llama3.1:8b", "prompt": "list 3 common causes of high load average on Linux", "stream": false}' \ | jq '.response' # OpenAI-compatible endpoint (for tools that speak OpenAI API) curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "llama3.1:8b", "messages": [{"role": "user", "content": "hello"}]}'Because Ollama speaks the OpenAI API format, it slots directly into the tools covered in this series:
By default Ollama only listens on localhost. To make it available to other machines on your network (e.g. a dedicated inference server):
# Allow network access echo 'OLLAMA_HOST=0.0.0.0' >> /etc/systemd/system/ollama.service.d/override.conf systemctl daemon-reload && systemctl restart ollamaA dedicated Ollama server on your LAN lets multiple users and tools share the same local model without each machine needing the storage and GPU resources to run it independently.
Ollama is the right answer to a specific question: "What do I do when I can't send this data to a cloud AI?" For a university SysAdmin dealing with FERPA considerations, internal infrastructure details, or simply working on a network segment with restricted egress — Ollama is the answer.
The quality gap between local models and Claude is real and significant for complex tasks. For simple tasks — syntax lookups, one-liner generation, explaining a config file — a local 8B model does the job well enough that the privacy benefit is worth it.
The most compelling use case is the dedicated inference server model: one machine with a decent GPU running Ollama, accessible to everyone on the LAN. sgpt, aider, and fabric all point at it. No one needs an API key. No queries leave the building. That's a meaningful capability for an institution with data handling obligations.