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 seconds

Pattern: 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/models

Models 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:

  1. “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
  2. “model failed to load, this may be due to resource limitations”

    • Not enough free disk space for temp files
    • Swapping causes severe performance degradation
  3. “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:

  1. Disk fills to 99% (475GB used of 504GB)
  2. Ollama needs temp space to load models (~2-5GB per model)
  3. OS cannot allocate temp files
  4. Model loading stalls or fails
  5. Client times out waiting for model
  6. 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

ServiceDepends on OllamaImpactFallback
Inference.tsPrimary for 5/11 tasksAll local routes failFalls back to Claude/Gemini
pai-log-scrubberClassification (~100K/day)Fails, retries with GeminiWorks, but costs $50/day
pai-inbox-auto-processorIntent detection (~200/day)Fails, uses GeminiWorks, but costs $2/day
Functions APIStateless LLM callsOptional Ollama, uses ClaudeUnaffected
Local CouncilMulti-model debateOllama one of 9 modelsStill works, 8/9 models respond

Financial Impact

Task CategoryExpected Ollama UsageActual Cost (Cloud Fallback)Monthly Loss
Classification50K calls/month @ $050K @ 250**$250
JSON Extraction10K calls/month @ $010K @ 50**$50
Summarization5K calls/month @ $05K @ 75**$75
Total Waste$0$375$375/month

Annualized: $4,500/year in unnecessary cloud costs

Performance Impact

MetricExpected (Ollama)Actual (Cloud Fallback)Degradation
Classification latency2-5s1-3s✅ Actually faster!
Cost per request$0$0.005♾️ Infinite % increase
PrivacyLocal (never leaves network)Cloud (data sent to Anthropic/Google)⚠️ Privacy loss
Availability99% (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

# 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 ollama

Expected 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: ~40GB

Expected 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_alive parameter 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

Based on grep patterns, PAI has NOT formally documented alternative local inference engines. The ecosystem is:

  1. Ollama (current) — Easiest, most popular
  2. llama.cpp — Low-level C++ library (Ollama uses this under the hood)
  3. vLLM — Production inference server (fast, batching)
  4. text-generation-webui (oobabooga) — Full web UI
  5. LM Studio — GUI app for Mac/Windows
  6. Jan — Desktop app alternative to Ollama
  7. GPT4All — Nomic’s local LLM runner
  8. KoboldCpp — Gaming/roleplay focused
  9. TabbyAPI — ExLlamaV2 wrapper for APIs
  10. MLX — Apple Silicon optimized (M1/M2/M3 Macs)

Quick Comparison Matrix

ToolEase of UsePerformanceAPIGPU SupportPAI Fit
Ollama⭐⭐⭐⭐⭐⭐⭐⭐OpenAI-compatibleNVIDIA, AMD, Metal✅ Current choice
llama.cpp⭐⭐⭐⭐⭐⭐HTTP serverUniversal⚠️ Too low-level
vLLM⭐⭐⭐⭐⭐⭐⭐⭐OpenAI-compatibleNVIDIA only⭐ Best for production
text-gen-webui⭐⭐⭐⭐⭐⭐⭐Multiple APIsNVIDIA, AMD, CPU⚠️ Too heavy (web UI)
LM Studio⭐⭐⭐⭐⭐⭐⭐⭐OpenAI-compatibleNVIDIA, Metal❌ GUI only, not server
Jan⭐⭐⭐⭐⭐⭐⭐OpenAI-compatibleNVIDIA, Metal❌ Desktop app, not daemon
GPT4All⭐⭐⭐⭐⭐⭐Custom APICPU-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

  1. PagedAttention — Memory-efficient attention mechanism

    • 2-4x higher throughput than Ollama
    • Better GPU utilization
    • Handles concurrent requests efficiently
  2. Continuous batching — Dynamic request batching

    • Multiple requests processed in parallel
    • Reduces latency under load
    • Better for multi-user scenarios
  3. Quantization support — AWQ, GPTQ, SqueezeLLM

    • Smaller models, faster inference
    • 4-bit, 8-bit quantization
    • Minimal quality loss
  4. OpenAI-compatible API — Drop-in replacement

    • Same API format as Ollama
    • Minimal code changes to integrate

vLLM vs Ollama Benchmark

MetricOllamavLLMWinner
Throughput (requests/sec)2-510-20vLLM (4x)
Latency (p50)3-8s1-3svLLM (3x faster)
Concurrent requests1-210-50vLLM (25x)
Memory efficiencyGoodExcellentvLLM
Ease of setupExcellentMediumOllama
Model compatibilityExcellentGoodOllama

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)

  1. 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
  2. Verify Ollama works — Test inference after cleanup

    ollama run qwen3:8b "What is 2+2?"
  3. Add aggressive timeouts — Update inference-matrix.json

    {
      "ollama_timeout_s": 10,  // Down from 120
      "fast_failover": true
    }

Short Term (Next 7 Days)

  1. 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}'
  2. Implement model caching — Unload unused models automatically

  3. Document model inventory — Which models are actually used?

Medium Term (Next 30 Days)

  1. Add dedicated Ollama disk — 500GB NVMe SSD (~$50)

  2. Test vLLM — Compare performance vs Ollama

    • Benchmark latency, throughput
    • Test with PAI workload
    • Decide if worth switching
  3. Set up legion-y530 as secondary Ollama host — Load balancing + failover

Long Term (Next 90 Days)

  1. Automated model pruning — Remove models unused for 30 days

  2. Capacity planning — Project disk needs for next 12 months

  3. 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:

  1. 99% disk full → no temp space for model loading
  2. Heavy swapping → I/O bottleneck
  3. 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:

  1. Run disk cleanup script
  2. Verify Ollama works
  3. Add monitoring for disk usage
  4. Test vLLM in parallel (don’t replace Ollama yet)
  5. Document findings and update operational runbooks

Related Docs:

  • PAI/DOCUMENTATION/OLLAMA_CAPABILITY_ASSESSMENT.md — Quality analysis
  • PAI/DOCUMENTATION/ENGINE_DAEMON_ARCHITECTURE.md — Service architecture
  • PAI/Tools/inference-matrix.json — Routing configuration