Producer

How to Share Ollama and Local LLMs with Fasten Share

Configure Ollama connectivity, model IDs, an OpenAI-compatible endpoint, Fasten Share health checks, and resource limits to share a local model responsibly.

Fasten Share Team · Updated Aug 1, 2026 · 4 min read

Ollama makes it practical to run a large language model locally. Fasten Share can publish Ollama capacity that you are authorized to provide as a discoverable producer node. Consumers do not connect directly to your Ollama port. They call a Fasten Share endpoint, and the producer client forwards the request to Ollama on your machine.

This guide assumes that Ollama is already installed. Sharing local inference consumes CPU, GPU, memory, bandwidth, and electricity, so start with conservative concurrency and only publish models you may provide to others.

Prepare Ollama and a model

Confirm that Ollama is running and list the models installed on the producer machine:

ollama list

If you still need a model, pull one that fits your hardware using the current Ollama documentation. The model identifier must match the output of ollama list. Tags are significant: qwen2.5:7b and qwen2.5 may not resolve to the same installed model.

Send a direct request to the native Ollama endpoint:

curl http://127.0.0.1:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen2.5:7b","prompt":"reply with OK","stream":false}'

Continue only after this direct test works. Fasten Share cannot repair a missing model, insufficient memory, or an Ollama process that is not reachable.

Choose a protocol that you have tested

The producer form uses a protocol to determine request handling and health checks. Ollama exposes its own API and also offers OpenAI-compatible behavior. Choose from the presets currently available in Fasten Share based on the interface you have actually tested.

For an OpenAI-compatible path, verify it directly first:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model":"qwen2.5:7b",
    "messages":[{"role":"user","content":"reply with OK"}],
    "stream":false
  }'

A default local Ollama instance may not require an API key. Do not invent a credential simply to fill a field. Follow the client validation and the authentication settings of any proxy you have placed in front of Ollama.

Install and sign in to the Fasten Share client, open the producer page, and add a backend. A typical starting point is:

Field	Example	Notes
Base URL	`http://127.0.0.1:11434`	Usually only the host and port
Protocol	OpenAI-compatible preset	Match the Ollama endpoint you tested
Version prefix	`/v1`	Do not repeat it in the base URL
Model	`qwen2.5:7b`	Match the complete Ollama identifier
API key	Empty or your proxy credential	Native local Ollama often needs none
Max concurrency	`1`	Start low to avoid GPU or memory pressure

Save and start sharing. Wait for the client to report that the producer connection is running, the node is registered, and the backend is healthy. Health checks use a configured model, so an incorrect first model can keep the entire backend offline.

Why Docker and LAN addresses fail so often

When the Fasten Share client runs directly on the host, 127.0.0.1:11434 normally reaches Ollama. Inside Docker, 127.0.0.1 refers to the container, not the host.

Use host.docker.internal where supported, a reachable host LAN address, or service discovery on a shared Docker network. Test the Ollama URL from the producer client’s actual runtime environment. Do not expose an unauthenticated Ollama port to the public internet just to avoid local networking setup; the Fasten Share producer uses an outbound connection and does not require consumers to reach your local port.

If Ollama listens only on loopback and the producer runs on another machine, adjust the listener, firewall, and LAN policy carefully. A wider network exposure should come with authentication and isolation.

Set realistic resource limits

Local LLM capacity is normally limited by GPU memory, system memory, and generation speed. A larger concurrency number is not automatically better. Multiple long contexts can cause out-of-memory errors, swapping, and sharply increased latency.

Start at concurrency 1, complete several consumer tests, and increase it gradually only if the machine remains responsive. Monitor:

cold model loading time;
the impact of long contexts on memory and latency;
sleep, lid-close, and operating-system updates;
Ollama model retention and unloading;
upstream bandwidth and Fasten Share request timeouts.

Troubleshooting

The health check returns 404

The base URL and version prefix are probably combined incorrectly. Keep http://127.0.0.1:11434 as the base and /v1 in its dedicated field so the final path does not become /v1/v1/....

The backend returns model not found

Copy the full identifier from ollama list, including its tag, and use that same name in a direct curl request.

The client cannot reach local Ollama

Check whether the client runs in Docker, a virtual machine, or another physical device. Test from that environment rather than from a browser on the host.

Requests fail under load

Reduce maximum concurrency, choose a smaller model, shorten context, and inspect GPU and system memory. Routing cannot add hardware capacity.

The node is online but receives no calls

Consumer choice depends on actual demand, model name, protocol, availability, ratings, and credit multiplier. Publishing a node is not a traffic or income guarantee.

Next step

After the node is healthy, switch to the consumer workflow, find your own model, and complete one end-to-end request. Confirm streaming, logs, and resource use before adjusting concurrency or the multiplier. For a cloud or private API rather than Ollama, continue with How to Connect Compatible Model APIs.