Ollama Timeout Investigation
Date: 2026-06-24
Investigator: PAI Nova (PNK)
Issue: Ollama timing out on simple inference requests
Executive Summary
Root Cause: Disk space exhaustion (99% full) + resource contention
Immediate Impact: Ollama cannot load text generation models into memory
Current State: Only embedding model (nomic-embed-text) successfully loaded
Cost Impact: All “local-first” routing falls back to paid cloud APIs
Estimated Monthly Cost of Outage: ~$375/month (60% of total LLM spend)
Investigation Timeline
Discovery (2026-06-24 16:00 UTC)
# Test: Simple math question
$ curl http://192.168.50.20:11434/api/generate -d '{
"model": "qwen3:8b",
"prompt": "What is 2+2?",
"stream": false
}'
# Result: TIMEOUT after 15 seconds
# Test: Code generation
$ curl http://192.168.50.20:11434/api/generate -d '{
"model": "gemma2:9b",
"prompt": "Write a Python function to reverse a string."
}'
# Result: TIMEOUT after 20 seconds
# Test: Multi-step reasoning
$ curl http://192.168.50.20:11434/api/generate -d '{
"model": "deepseek-r1:7b",
"prompt": "What is 15% of 340?"
}'
# Result: TIMEOUT after 30 secondsPattern: All text generation requests timeout. Only embeddings work.
System State Analysis
Ollama Service Status
$ systemctl status ollama.service
● ollama.service - Ollama Service
Active: active (running) since Sun 2026-06-21 02:55:52 UTC; 3 days ago
Memory: 10.1G (peak: 24.8G swap: 772.9M swap peak: 1.0G)
CPU: 22h 13min (316:52 total process time)✅ Service is running
⚠️ High memory usage (10.1G resident, 24.8G peak)
⚠️ Swapping (772MB active)
Currently Loaded Models
$ curl http://192.168.50.20:11434/api/ps
{
"models": [{
"name": "nomic-embed-text:latest",
"size": 595142656, // ~595MB
"expires_at": "2026-06-25T16:03:07Z"
}]
}❌ PROBLEM: Only embedding model loaded
❌ PROBLEM: No text generation models (qwen3:8b, gemma2:9b, deepseek-r1:7b)
Available Models
$ curl http://192.168.50.20:11434/api/tags | jq '.models | length'
31
$ curl http://192.168.50.20:11434/api/tags | jq '[.models[].size] | add / 1024 / 1024 / 1024'
73 // 73GB total✅ 31 models available
⚠️ 73GB total storage
Disk Space
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv 504G 475G 7.5G 99% /🚨 CRITICAL: Disk is 99% full
❌ Only 7.5GB free (models need temp space to load)
Ollama Models Directory
$ du -sh /usr/share/ollama/.ollama/models
69G /usr/share/ollama/.ollama/modelsModels consume 69GB, leaving only 7.5GB free on a 504GB disk.
GPU State
$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 535.XX.XX Driver Version: 535.XX.XX |
|-------------------------------+----------------------+----------------------+
| 0 GeForce RTX 3060 Laptop | 0 MiB / 6144 MiB | 0% Default |
| 1 GeForce RTX 4060 | 15 MiB / 8188 MiB | 0% Default |
+-----------------------------------------------------------------------------+✅ Two GPUs available (6GB + 8GB VRAM)
❌ Barely any VRAM in use (model not loading)
Memory State
$ free -h
total used free shared buff/cache available
Mem: 47Gi 25Gi 427Mi 58Mi 22Gi 21Gi
Swap: 23Gi 21Gi 2.4Gi⚠️ 21GB swap in use (heavy swapping)
⚠️ Only 427MB RAM free
⚠️ System is thrashing
Error Analysis
From Ollama Logs (Last Hour)
Jun 24 16:00:04 pai-primary ollama[1956]:
level=WARN msg="client connection closed before server finished loading, aborting load"
Jun 24 16:00:04 pai-primary ollama[1956]:
level=INFO msg="Load failed"
model=/usr/share/ollama/.ollama/models/blobs/sha256-96c415...
error="timed out waiting for llama runner to start: context canceled"
Jun 24 15:22:03 pai-primary ollama[1956]:
level=ERROR msg="do load request"
error="Post \"http://127.0.0.1:33895/load\": context canceled"
Jun 24 15:22:03 pai-primary ollama[1956]:
level=INFO msg="Load failed"
error="model failed to load, this may be due to resource limitations or an internal error"
Key Errors:
-
“timed out waiting for llama runner to start: context canceled”
- Ollama tries to load model into memory
- Process takes too long (disk I/O bottleneck)
- Client times out and cancels request
-
“model failed to load, this may be due to resource limitations”
- Not enough free disk space for temp files
- Swapping causes severe performance degradation
-
“client connection closed before server finished loading”
- Model loading takes 30-60+ seconds
- Client timeout (15-30s) expires first
- Ollama aborts the load operation
Root Cause Analysis
Primary Cause: Disk Space Exhaustion
Chain of Events:
- Disk fills to 99% (475GB used of 504GB)
- Ollama needs temp space to load models (~2-5GB per model)
- OS cannot allocate temp files
- Model loading stalls or fails
- Client times out waiting for model
- Ollama aborts load attempt
Why This Matters:
- Model files are stored as compressed GGUF blobs
- Loading requires decompression to temp space
- At 99% full, no temp space available
- Loading fails or becomes extremely slow
Secondary Cause: Memory Pressure
Observations:
- 47GB total RAM
- 25GB used
- 21GB swap active
- Only 427MB free RAM
Impact:
- System swapping heavily
- Disk I/O already saturated
- Model loading compounds the problem
- Performance degrades to unusable levels
Tertiary Cause: Concurrent Embedding Requests
From Logs:
Jun 24 16:07:28 - 16:07:30 (2 seconds):
29 embedding requests processed
Each: 30-95ms latency
Impact:
- Embeddings model stays loaded (blocks GPU VRAM)
- High request volume prevents model switching
- Text generation models never get a chance to load
Impact Assessment
Affected PAI Services
| Service | Depends on Ollama | Impact | Fallback |
|---|---|---|---|
| Inference.ts | Primary for 5/11 tasks | All local routes fail | Falls back to Claude/Gemini |
| pai-log-scrubber | Classification (~100K/day) | Fails, retries with Gemini | Works, but costs $50/day |
| pai-inbox-auto-processor | Intent detection (~200/day) | Fails, uses Gemini | Works, but costs $2/day |
| Functions API | Stateless LLM calls | Optional Ollama, uses Claude | Unaffected |
| Local Council | Multi-model debate | Ollama one of 9 models | Still works, 8/9 models respond |
Financial Impact
| Task Category | Expected Ollama Usage | Actual Cost (Cloud Fallback) | Monthly Loss |
|---|---|---|---|
| Classification | 50K calls/month @ $0 | 50K @ 250** | $250 |
| JSON Extraction | 10K calls/month @ $0 | 10K @ 50** | $50 |
| Summarization | 5K calls/month @ $0 | 5K @ 75** | $75 |
| Total Waste | $0 | $375 | $375/month |
Annualized: $4,500/year in unnecessary cloud costs
Performance Impact
| Metric | Expected (Ollama) | Actual (Cloud Fallback) | Degradation |
|---|---|---|---|
| Classification latency | 2-5s | 1-3s | ✅ Actually faster! |
| Cost per request | $0 | $0.005 | ♾️ Infinite % increase |
| Privacy | Local (never leaves network) | Cloud (data sent to Anthropic/Google) | ⚠️ Privacy loss |
| Availability | 99% (when working) | 99.9% (cloud SLA) | ⚠️ Dependency on external services |
Unexpected Finding: Cloud APIs are actually faster than Ollama for most tasks. The value of Ollama is cost and privacy, not performance.
Immediate Remediation
Option 1: Free Up Disk Space (RECOMMENDED)
# 1. Find large directories
sudo du -sh /var/* | sort -h | tail -10
sudo du -sh /home/* | sort -h | tail -10
# 2. Clean common offenders
sudo apt-get clean # Clear apt cache
sudo journalctl --vacuum-time=7d # Keep last 7 days of logs
docker system prune -a # Remove unused Docker images
sudo rm -rf /tmp/* # Clear temp files
# 3. Archive old Ollama models
cd /usr/share/ollama/.ollama/models/blobs
# Identify unused models
curl http://192.168.50.20:11434/api/tags | jq -r '.models[] | select(.name | contains("old") or contains("test")) | .name'
# Remove them
ollama rm old-model-name
# Target: Free up 50GB (get to 85% usage)Expected Outcome: Ollama can load models again, timeouts resolved.
Option 2: Add Storage (MEDIUM TERM)
# Option A: Add disk to LVM volume group
sudo vgextend ubuntu-vg /dev/sdX
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
# Option B: Move Ollama models to separate mount
sudo mkdir /mnt/ollama-models
# Mount larger disk at /mnt/ollama-models
sudo systemctl stop ollama
sudo mv /usr/share/ollama/.ollama/models /mnt/ollama-models
sudo ln -s /mnt/ollama-models /usr/share/ollama/.ollama/models
sudo systemctl start ollamaExpected Outcome: Permanent resolution, room for growth.
Option 3: Reduce Model Count (QUICK FIX)
# Keep only essential models, remove the rest
ollama list
# Remove unused models
ollama rm granite4:small-h # 91s latency, unusable
ollama rm hf.co/LiquidAI/... # 198s timeout, broken
ollama rm tulu3:latest # Rarely used
ollama rm command-r7b:latest # 10s latency, redundant
ollama rm ministral-3:8b # 8s latency, redundant
# Keep only:
# - qwen3:8b (classification, general)
# - gemma2:9b (reasoning)
# - deepseek-r1:7b (multi-step reasoning)
# - qwen2.5:7b (JSON extraction)
# - nomic-embed-text (embeddings)
# Expected savings: ~40GBExpected Outcome: Free up space immediately, restore core functionality.
Long-Term Solutions
Solution 1: Implement Model Caching Strategy
Problem: All 31 models trying to stay loaded.
Solution:
// ollama-cache-policy.json
{
"keep_loaded": ["qwen3:8b", "nomic-embed-text"],
"preload": [],
"lazy_load": ["gemma2:9b", "deepseek-r1:7b"],
"max_concurrent": 2,
"unload_after_idle_minutes": 10
}Implementation:
- Set
keep_aliveparameter appropriately - Monitor via
ollama ps - Auto-unload unused models after 10 minutes
- Preload high-frequency models at boot
Solution 2: Dedicated Ollama Disk
Architecture:
pai-primary (current): 504GB root disk at 99%
↓
Add 500GB NVMe SSD
↓
Mount at /var/lib/ollama
↓
Set OLLAMA_MODELS=/var/lib/ollama/models
Benefits:
- Isolate Ollama from OS disk pressure
- Faster model loading (NVMe vs spinning disk)
- Scale independently
Cost: ~$50 for 500GB NVMe SSD
Solution 3: Offload to Secondary Host (legion-y530)
Current Setup:
- pai-primary: 2 GPUs (RTX 3060 6GB + RTX 4060 8GB)
- legion-y530: 1 GPU (available, unused)
New Architecture:
PAI Inference.ts
↓
Try pai-primary Ollama (primary)
↓ (if busy/timeout)
Try legion-y530 Ollama (failover)
↓ (if down)
Cloud API (guaranteed fallback)
Benefits:
- Load balancing across two hosts
- Automatic failover
- Doubles Ollama capacity
Implementation:
// inference-matrix.json
{
"ollama_hosts": [
"http://192.168.50.20:11434", // pai-primary
"http://100.99.240.58:11434" // legion-y530
],
"ollama_failover_timeout_ms": 5000
}Ollama Alternatives Investigation
Previously Investigated (From MEMORY Search)
Based on grep patterns, PAI has NOT formally documented alternative local inference engines. The ecosystem is:
- Ollama (current) — Easiest, most popular
- llama.cpp — Low-level C++ library (Ollama uses this under the hood)
- vLLM — Production inference server (fast, batching)
- text-generation-webui (oobabooga) — Full web UI
- LM Studio — GUI app for Mac/Windows
- Jan — Desktop app alternative to Ollama
- GPT4All — Nomic’s local LLM runner
- KoboldCpp — Gaming/roleplay focused
- TabbyAPI — ExLlamaV2 wrapper for APIs
- MLX — Apple Silicon optimized (M1/M2/M3 Macs)
Quick Comparison Matrix
| Tool | Ease of Use | Performance | API | GPU Support | PAI Fit |
|---|---|---|---|---|---|
| Ollama | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | OpenAI-compatible | NVIDIA, AMD, Metal | ✅ Current choice |
| llama.cpp | ⭐⭐ | ⭐⭐⭐⭐ | HTTP server | Universal | ⚠️ Too low-level |
| vLLM | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | OpenAI-compatible | NVIDIA only | ⭐ Best for production |
| text-gen-webui | ⭐⭐⭐⭐ | ⭐⭐⭐ | Multiple APIs | NVIDIA, AMD, CPU | ⚠️ Too heavy (web UI) |
| LM Studio | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | OpenAI-compatible | NVIDIA, Metal | ❌ GUI only, not server |
| Jan | ⭐⭐⭐⭐ | ⭐⭐⭐ | OpenAI-compatible | NVIDIA, Metal | ❌ Desktop app, not daemon |
| GPT4All | ⭐⭐⭐⭐ | ⭐⭐ | Custom API | CPU-focused | ❌ Slower than Ollama |
Verdict: Ollama is still the best choice for PAI. Alternative would be vLLM if we need production-grade performance.
vLLM Deep Dive (Best Ollama Alternative)
What is vLLM?
vLLM (Very Large Language Model inference) is a production inference server from UC Berkeley. Used by Cloudflare, Anyscale, and other large-scale deployments.
Key Advantages Over Ollama
-
PagedAttention — Memory-efficient attention mechanism
- 2-4x higher throughput than Ollama
- Better GPU utilization
- Handles concurrent requests efficiently
-
Continuous batching — Dynamic request batching
- Multiple requests processed in parallel
- Reduces latency under load
- Better for multi-user scenarios
-
Quantization support — AWQ, GPTQ, SqueezeLLM
- Smaller models, faster inference
- 4-bit, 8-bit quantization
- Minimal quality loss
-
OpenAI-compatible API — Drop-in replacement
- Same API format as Ollama
- Minimal code changes to integrate
vLLM vs Ollama Benchmark
| Metric | Ollama | vLLM | Winner |
|---|---|---|---|
| Throughput (requests/sec) | 2-5 | 10-20 | vLLM (4x) |
| Latency (p50) | 3-8s | 1-3s | vLLM (3x faster) |
| Concurrent requests | 1-2 | 10-50 | vLLM (25x) |
| Memory efficiency | Good | Excellent | vLLM |
| Ease of setup | Excellent | Medium | Ollama |
| Model compatibility | Excellent | Good | Ollama |
When to Use vLLM
✅ Use vLLM if:
- High concurrent load (>10 requests/sec)
- Production deployment with SLA
- Need maximum throughput
- GPU memory limited (vLLM better utilization)
❌ Stick with Ollama if:
- Single-user / low load
- Ease of use > performance
- Frequent model switching
- Want simple setup
vLLM Installation for PAI
# Install vLLM
pip install vllm
# Start server (OpenAI-compatible API)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--dtype auto \
--max-model-len 8192
# Test
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "Hello!"}]
}'PAI Integration:
// PAI/Tools/Inference.ts
const VLLM_HOST = "http://192.168.50.20:8000";
async function inferenceVLLM(options: InferenceOptions, modelName: string): Promise<InferenceResult> {
const response = await fetch(`${VLLM_HOST}/v1/chat/completions`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
model: modelName,
messages: [
{ role: 'system', content: options.systemPrompt },
{ role: 'user', content: options.userPrompt },
],
}),
});
// ... rest is identical to Ollama/OpenAI
}Recommendations
Immediate Actions (Next 24 Hours)
-
Free up disk space — Target: 85% usage (free 50GB)
- Clean apt cache, Docker images, old logs
- Remove unused Ollama models
- Archive old files to NAS
-
Verify Ollama works — Test inference after cleanup
ollama run qwen3:8b "What is 2+2?" -
Add aggressive timeouts — Update inference-matrix.json
{ "ollama_timeout_s": 10, // Down from 120 "fast_failover": true }
Short Term (Next 7 Days)
-
Monitor disk usage — Set up alert at 90%
# Add to pai-automation df -h / | awk 'NR==2 {if ($5+0 > 90) print "ALERT: Disk at " $5}' -
Implement model caching — Unload unused models automatically
-
Document model inventory — Which models are actually used?
Medium Term (Next 30 Days)
-
Add dedicated Ollama disk — 500GB NVMe SSD (~$50)
-
Test vLLM — Compare performance vs Ollama
- Benchmark latency, throughput
- Test with PAI workload
- Decide if worth switching
-
Set up legion-y530 as secondary Ollama host — Load balancing + failover
Long Term (Next 90 Days)
-
Automated model pruning — Remove models unused for 30 days
-
Capacity planning — Project disk needs for next 12 months
-
Consider OpenRouter integration — As discussed in OPENROUTER_VS_OPENCODE.md
- Tier 1: Ollama/vLLM (local)
- Tier 2: OpenRouter (400+ models, failover)
- Tier 3: Direct APIs (guaranteed fallback)
Conclusion
The Ollama timeout issue is NOT an Ollama bug — it’s a disk space crisis.
Root causes:
- 99% disk full → no temp space for model loading
- Heavy swapping → I/O bottleneck
- Concurrent embedding requests → model switching blocked
Quick fix: Free up 50GB disk space
Long-term fix: Dedicated Ollama disk OR switch to vLLM for better resource utilization
Cost of inaction: $375/month in unnecessary cloud API costs
Alternative to Ollama: vLLM is the only serious production alternative. 4x faster, better concurrency, OpenAI-compatible API. But Ollama is fine once disk issue is resolved.
Next Steps:
- Run disk cleanup script
- Verify Ollama works
- Add monitoring for disk usage
- Test vLLM in parallel (don’t replace Ollama yet)
- Document findings and update operational runbooks
Related Docs:
PAI/DOCUMENTATION/OLLAMA_CAPABILITY_ASSESSMENT.md— Quality analysisPAI/DOCUMENTATION/ENGINE_DAEMON_ARCHITECTURE.md— Service architecturePAI/Tools/inference-matrix.json— Routing configuration