Ollama as a Control Plane for Open Models
Ollama’s surface promise is a short command, but its real subject is the coordination that makes that command useful. The central question of this series has been how Ollama turns model files and unavoidable hardware limits into a usable application boundary. The answer is a control-plane pattern: model artifacts declare what exists, request handling decides what is being asked, scheduling makes the work fit available resources, and interfaces carry the result to a person or application. That pattern gives the reader a way to evaluate Ollama without confusing a convenient surface with a constraint-free system.
The complete runtime model
A useful interpretation of Ollama begins with the model artifact. A name and tag select a manifest, and the manifest binds configuration to content layers stored as reusable, content-addressed blobs. The configuration can carry a prompt template, system behavior, generation defaults, message examples, capabilities, and a runtime requirement. The content can include weights and optional adapters or projectors. This is not merely packaging around a file. It is the first contract in the system: it says which bytes and interaction rules make up the runnable identity.
That contract explains why model management and inference cannot be separated completely. Pulling or creating a model changes what identities are available to the runtime. Copying a model can give shared material another name. Deleting a model can remove a manifest while preserving a blob still referenced elsewhere. Importing can change supported behavior or format compatibility, while quantization changes the resource budget and may change quality. An adapter can alter learned behavior only when its base-model relationship is correct. The artifact layer gives Ollama something precise to resolve and inspect, but it does not certify model quality, provenance, or universal compatibility.
The second contract is the request. Ollama’s server resolves the model, reads its metadata, checks required capabilities, merges model and request options, and asks for a compatible runner. A request for ordinary text, a vision input, a tool call, an embedding, structured JSON, or a thinking-capable response is not the same workload. Capability metadata prevents the service from treating those requests as generic text and failing later, after resources have already been committed.
Prompt preparation connects the artifact to the request. A configured template can determine how system messages, user prompts, and responses are represented. A native chat path can let the runner apply the model’s own conversation format. Images need to cross the boundary as media data. Thinking and tool parsers may separate fields that share one native stream. Request-time options can specialize behavior without creating a new artifact. These choices explain why a model name alone cannot predict an output: the artifact, the request, and the selected route jointly determine what the native runner receives.
The third contract is resource state. Ollama’s scheduler estimates memory, chooses a device or device group, and accounts for context, batch, parallel requests, projectors, and already loaded runners. If a compatible runner is available, it can be reused. If a new runner is needed, the request may wait, cause an idle runner to expire, or trigger eviction. The scheduler can retry selected out-of-memory cases when automatically chosen settings can be reduced, but a persistent failure remains a failure of the current model, workload, placement, or hardware combination.
This is where Ollama’s control-plane character becomes most visible. The native runner performs inference, but the scheduler decides whether that runner can exist alongside other work. Context length and parallelism are not just API decoration; they change the memory obligation. A model that fits on one GPU may be kept there to avoid transfers. A model that does not fit may be spread across available devices. A model that has loaded successfully may still be expired after it becomes idle or cleared after a runtime OOM. The server turns these conditions into states that a client can observe rather than leaving every application to invent its own model lifecycle.
The fourth contract is the application boundary. Ollama exposes its own REST API and official Python and JavaScript libraries, and it can translate supported OpenAI and Anthropic requests. The client receives streamed content or a single response, usage metrics, model status, and terminal reasons. The application still owns responsibilities that cannot be delegated to a transport layer: it maintains chat history when needed, accumulates streamed tool calls, executes tools, validates structured data, and decides whether an answer is acceptable.