Process Killed (Code 137) When Running DeepSeek R1

If your OpenClaw process suddenly terminates with:

Killed

Or you see this in logs:

Exit code: 137

Your process was terminated by the Linux OOM (Out of Memory) killer.

This is not a bug.

This is a memory ceiling.

What Code 137 Means

Exit code 137 = 128 + 9 = SIGKILL

The math:

• 128 = Signal base offset
• 9 = SIGKILL signal number

SIGKILL is the "terminate immediately" signal. It cannot be caught or ignored.

When the Linux kernel runs out of memory, it invokes the OOM killer. The OOM killer selects a process to terminate to free memory. It sends SIGKILL.

Your process dies instantly. No cleanup. No error handling. No log message from the application itself.

Why This Happens With DeepSeek R1

DeepSeek R1 models are memory-intensive:

Common Causes

1. Docker Memory Limit Too Low

Docker Desktop defaults to 2 GB memory. DeepSeek R1 8B alone needs 16+ GB.

2. Host RAM Insufficient

Your system physically doesn't have enough RAM for the model + OS + other processes.

3. GPU VRAM Spillover

When GPU VRAM fills, PyTorch/TensorFlow offload to system RAM. This can overwhelm available memory.

4. Context Window Too Large

Longer context = more KV cache = more memory. A 32k context window can double memory usage.

How to Confirm OOM Is the Cause

Check System Logs

# Check for OOM events
dmesg | grep -i "out of memory"
dmesg | grep -i "oom"

# Check systemd journal
journalctl -xe | grep -i "oom"

You'll see something like:

Out of memory: Killed process 12345 (python) total-vm:16384MB, anon-rss:8192MB

Check Docker Events

docker events --filter 'event=oom'

Local Fix Attempts

Fix 1: Increase Docker Memory Limit

If running in Docker Desktop:

1. Open Docker Desktop Settings
2. Go to Resources
3. Increase Memory to at least 16 GB (24+ GB for 8B models)

Or via command line:

docker run --memory=24g --memory-swap=24g your-image

Fix 2: Reduce Model Size

Use a smaller quantization or model variant:

# Use 4-bit quantization instead of full precision
# Use 8B model instead of 32B or 70B

Fix 3: Reduce Context Window

# Limit context length
OLLAMA_NUM_CTX=2048 ollama run deepseek-r1:8b

Fix 4: Enable Swap (Temporary Mitigation)

# Create 16 GB swap file
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Warning: Swap is slow. It only delays the inevitable. Disk I/O will kill inference performance.

The Reality Check

If you're hitting code 137, you're under-provisioned.

These fixes are band-aids:

• Increasing Docker memory doesn't help if your host has 16 GB total
• Swap makes inference unusably slow
• Reducing model size reduces capability

The real question: Do you have enough hardware?

Check Your Hardware First

Before any debugging, run a hardware check:

👉 /preflight

This tells you if your setup can even run the model you're trying to run.

The Real Fix

If preflight says NOT VIABLE, local tweaks won't help.

You have three options:

1. Downgrade model — Use 1.5B or 8B instead of 32B/70B
2. Use API — DeepSeek API instead of local inference
3. Rent proper hardware — Cloud GPU with adequate VRAM

Why Cloud GPU Solves This

New users may qualify for promotional credit. Terms apply.

Cloud GPU gives you:

• 24GB+ VRAM — No spillover to RAM
• 64GB+ System RAM — Headroom for OS + model
• No Docker caps — Full memory access
• No OOM killer — Run at full capacity

When to Give Up on Local

If you've tried all the local fixes and still see code 137:

1. Your hardware is fundamentally insufficient
2. No configuration will fix physics
3. Time spent debugging > cost of cloud GPU

Hourly cloud GPU rates start around $0.50-2.00/hour.

If you bill $50+/hour, spending 2 hours debugging OOM costs more than renting a proper GPU for a week.

Quick Links

• Run hardware check → /preflight
• Back to Deployment Hub → /guides/deepseek-r1-openclaw-deployment-hub
• Browse all errors → /guides/openclaw-error-index
• Check VRAM reality → /guides/hardware-requirements-reality-check

Bottom Line

Exit code 137 = OOM killer.

You can tweak Docker limits. You can add swap. You can reduce context.

But if your hardware can't handle the model, you're fighting physics.

Check your hardware. Then decide: downgrade, API, or cloud GPU.