Cara Memperbaiki Ollama context deadline exceeded

Arti sebenarnya dari “context deadline exceeded”

Error Ollama context deadline exceeded adalah laporan timeout. Sebagian kode Go menetapkan batas waktu pada request, model tidak selesai dalam batas tersebut, lalu batas waktu itu terlewati. Tidak ada yang crash dan tidak ada file yang rusak. Proses masih berjalan ketika waktu habis.

Pesan ini berasal dari package standar Go context. Hal itu sendiri merupakan petunjuk yang berguna. Klien Python yang dibangun di atas httpx akan memunculkan httpx.ReadTimeout. Browser menampilkan network error biasa. Jika Anda melihat pesan yang persis seperti ini, program Go berhenti menunggu: command-line tool Ollama, server Ollama itu sendiri, atau aplikasi Go yang memanggil API (application programming interface).

Ada lima lapisan yang dapat menetapkan batas waktu tersebut. Lapisan-lapisan ini gagal pada tahap yang berbeda dan masing-masing memerlukan perbaikan yang berbeda. Karena itu, tugas utamanya adalah menentukan lapisan mana yang memicu timeout.

1. Klien HTTP Anda, yang memberikan anggaran waktu tetap untuk request.
2. Timeout pemuatan model pada server Ollama, yang aktif ketika model besar pertama kali dibaca dari disk.
3. keep_alive, yang membongkar model di antara request sehingga pemanggilan berikutnya harus membayar kembali biaya pemuatan.
4. num_ctx yang cukup besar sehingga pemrosesan prompt saja berlangsung selama beberapa menit pada mesin yang hanya menggunakan CPU.
5. Reverse proxy seperti nginx atau Traefik, yang memutus koneksi sebelum Ollama mengirimkan respons.

Periksa daftar tersebut dari atas ke bawah. Setiap langkah di bawah ini menghapus satu lapisan dari analisis sehingga Anda tidak perlu menebak.

Reproduksi melalui API untuk mengeluarkan proxy dari jalur

Jalankan request langsung pada server, menuju Ollama tanpa perantara proxy.

time curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Why is the sky blue?",
  "stream": false
}' | head -c 400

curl tidak menetapkan batas waktu keseluruhan, melainkan hanya timeout koneksi. Karena itu, perintah ini menunggu selama yang diperlukan Ollama. Langkah ini membagi masalah menjadi dua kemungkinan. Jika respons berupa body JSON diterima, Ollama telah memberikan respons dan batas waktu tersebut berasal dari komponen di depannya. Jika pemanggilan ini sendiri menggantung selama beberapa menit, keterlambatan terjadi di dalam Ollama dan proxy bukan penyebabnya.

Sekarang kirim request yang sama melalui URL publik Anda dan ukur waktunya.

curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
  -X POST https://llm.example.com/api/generate \
  -d '{"model": "llama3.1:8b", "prompt": "hi", "stream": false}'

Status 504 yang tercetak setelah durasi yang mencurigakan dan bulat, seperti 60.0 atau 30.0 detik, menunjukkan timeout proxy. Proxy biasanya menggunakan nilai default yang bulat. Model tidak akan selesai tepat pada 60.000 detik dua kali berturut-turut. Jika pemanggilan langsung langsung ditolak, bukan berjalan lambat, masalahnya ada pada listener, bukan pada batas waktu. Alamat yang digunakan Ollama untuk bind pada port 11434 membahas kasus tersebut.

Pantau log server saat permintaan diproses

Buka sesi kedua dan ikuti log service, lalu kirim ulang permintaan.

journalctl -u ollama --no-pager --follow --pager-end

Cold start yang sehat mencatat bahwa model sedang dimuat, kemudian runner dimulai, lalu permintaan dilayani. Kegagalan pemuatan akan terlihat seperti berikut. String ini mengidentifikasi batas waktu pemuatan yang ditetapkan server:

Error: timed out waiting for llama runner to start - progress 0.00 -

Pesan tersebut berarti proses model tidak selesai dimulai dalam batas waktu yang ditetapkan server. Angka progres menunjukkan sejauh mana proses berjalan. Nilai 0.00 berarti runner sama sekali tidak melaporkan progres sebelum batas waktu berakhir. Biasanya, file masih sedang dibaca atau mesin sedang menggunakan swap. Untuk memperoleh detail lebih lanjut selama pemuatan, mulai ulang service dengan OLLAMA_DEBUG=1 yang telah ditetapkan, lalu ulangi proses.

Ukur apakah keterlambatan disebabkan oleh pemuatan atau pembuatan

Ollama melaporkan waktu prosesnya sendiri, jadi Anda tidak perlu menebak bagian ini.

ollama run --verbose llama3.1:8b "Why is the sky blue?"

Setelah jawaban, Ollama mencetak total duration, load duration, prompt eval count, prompt eval rate, eval count, dan eval rate. Jalankan dua kali. Pada proses kedua, load duration seharusnya turun hingga hampir nol karena model sudah berada di memori. Jika tidak turun, model sedang di-unload di antara kedua proses tersebut. Ini adalah kasus keep_alive yang dibahas lebih lanjut di bawah.

Nilai yang sama dikembalikan oleh API dalam objek JSON terakhir sebagai load_duration, prompt_eval_duration, dan eval_duration. Dokumentasi menyatakan bahwa semua durasi dikembalikan dalam nanodetik. Jadi, bagi nilainya dengan 10^9 untuk mendapatkan detik.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Why is the sky blue?",
  "stream": false
}' | python3 -c 'import json,sys; d=json.load(sys.stdin); print({k: round(v/1e9, 2) for k, v in d.items() if k.endswith("_duration")})'

Periksa nilai terbesar. Jika load_duration dominan, terdapat masalah saat memuat model. Lanjutkan ke dua bagian berikutnya. Jika prompt_eval_duration dominan, pemrosesan prompt menjadi sumber beban. Lanjutkan ke bagian num_ctx. Jika eval_duration dominan, model memang menghasilkan keluaran dengan lambat pada perangkat keras ini. Tidak ada pengaturan timeout yang dapat mengubahnya. Persingkat keluaran dengan num_predict, atau gunakan model yang lebih kecil.

Naikkan OLLAMA_LOAD_TIMEOUT setelah memeriksa versi

Variabel server yang menentukan berapa lama server menunggu model dimulai adalah OLLAMA_LOAD_TIMEOUT. Nilai defaultnya berubah antar-rilis. Karena itu, periksa nilai untuk build Anda, bukan nilai dari artikel mana pun, termasuk artikel ini. Cetak versinya terlebih dahulu.

ollama --version

Kemudian buka sumber untuk tag yang tepat tersebut, https://github.com/ollama/ollama/blob/<your version>/envconfig/config.go, lalu cari OLLAMA_LOAD_TIMEOUT. Nilai dalam file itu adalah nilai default yang dikompilasi ke dalam binary Anda. Tetapkan nilai sendiri melalui systemd drop-in.

sudo systemctl edit ollama.service

Tambahkan variabel tersebut di bawah bagian [Service]. Inilah metode yang diberikan dokumentasi Ollama sendiri untuk Linux:

[Service]
Environment="OLLAMA_LOAD_TIMEOUT=15m"
Environment="OLLAMA_KEEP_ALIVE=-1"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

Perintah terakhir mencetak environment yang benar-benar diterima service. Hasil kosong berarti drop-in disimpan di luar penanda editor atau di bawah nama bagian yang salah. Akibatnya, tidak ada pengaturan yang Anda tetapkan yang berlaku. Pahami manfaatnya: timeout pemuatan yang lebih panjang mencegah server menyerah terlalu cepat, tetapi tidak membuat proses apa pun menjadi lebih cepat. Jika model tidak muat di memori, mesin akan menggunakan swap, proses pemuatan akan sangat lambat, dan nilai yang lebih besar hanya menunda kegagalan.

Permintaan pertama setelah jeda adalah yang lambat

Ollama membongkar model yang tidak aktif untuk membebaskan memori. Pengaturan keep_alive menentukan waktunya. Dokumentasi Ollama menetapkan nilai bawaan 5 menit, berdasarkan pemeriksaan pada September 2026. Jadi, aplikasi chat yang digunakan sekali dalam satu jam akan memuat ulang model pada setiap pesan, dan setiap pesan harus menunggu seluruh proses cold start. Permintaan yang mengalami timeout adalah permintaan pertama setelah periode tanpa aktivitas. Pola ini persis seperti yang sering dianggap acak.

Periksa model yang saat ini berada di memori:

ollama ps
curl -s http://127.0.0.1:11434/api/ps

Daftar kosong atau waktu kedaluwarsa yang tinggal beberapa menit mengonfirmasi kondisi tersebut. keep_alive menerima string durasi seperti "10m" atau "24h", angka biasa dalam satuan detik, 0 untuk langsung membongkar model, serta angka negatif untuk mempertahankan model di memori tanpa batas waktu. Tetapkan pengaturan ini per permintaan, atau tetapkan OLLAMA_KEEP_ALIVE pada service agar berlaku untuk setiap permintaan.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "keep_alive": -1
}'

Permintaan yang mencantumkan model tanpa prompt akan memuat model lalu selesai. Ini adalah cara yang didokumentasikan untuk melakukan warm-up pada server setelah reboot. Masukkan konfigurasi ini ke dalam unit systemd kecil agar tidak ada yang perlu menunggu cold start. Konsekuensinya jelas: model yang dipertahankan di memori akan terus menggunakan memori tersebut. Jadi, pada server kecil, Anda mungkin hanya dapat mempertahankan satu model, bukan empat. Mempertahankan model di memori di antara permintaan menjelaskan perhitungan memori dan unit warm-up.

Mengapa num_ctx besar mengalami timeout sebelum token pertama

Sebelum model menulis apa pun, model harus membaca seluruh prompt. Tahap ini disebut prefill, dan inilah yang diukur oleh prompt eval. num_ctx menetapkan panjang konteks, yang melakukan dua hal sekaligus. Parameter ini membatasi jumlah token yang dapat dipertimbangkan model dan menentukan ukuran KV cache (key value cache) yang dialokasikan server sejak awal. Keduanya menambah beban kerja.

Pada server yang hanya menggunakan CPU, prefill berjalan lambat dan waktunya bertambah secara linear sesuai jumlah token dalam prompt. Dokumen panjang yang ditempelkan ke chat dapat menghabiskan waktu beberapa menit dalam tahap prefill, sementara client sama sekali belum menerima apa pun karena streaming belum dimulai. Client mencapai batas waktunya dan melaporkan context deadline exceeded, sedangkan server terus bekerja selama itu. Buktikan dengan angka dari bagian sebelumnya: jalankan prompt yang sama dengan "options": {"num_ctx": 2048}, lalu dengan 32768, dan bandingkan prompt_eval_duration.

Nilai default server berasal dari OLLAMA_CONTEXT_LENGTH, sedangkan num_ctx per request dalam objek options akan menimpanya. Kesalahan yang umum adalah menaikkan nilainya hingga maksimum yang diumumkan model hanya karena maksimum tersebut tersedia. Alokasi KV cache dapat membuat model tidak lagi muat di RAM dan mengubah konfigurasi yang semula berjalan menjadi konfigurasi yang menggunakan swapping. Menentukan num_ctx berdasarkan memori aktual Anda menjelaskan detail penentuan ukurannya.

Mengapa nginx mengembalikan 504 Gateway Time-out

nginx mendokumentasikan proxy_read_timeout dengan nilai default 60s, dan log error-nya menjelaskan kegagalan tersebut secara langsung:

upstream timed out (110: Connection timed out) while reading response header from upstream

Detail pentingnya terdapat dalam dokumentasi nginx: timeout tersebut “hanya diterapkan di antara dua operasi pembacaan berturut-turut, bukan untuk transmisi seluruh respons”. Respons streaming mereset penghitung waktu setiap kali mengirim chunk, sehingga chat streaming tetap berjalan. Permintaan dengan "stream": false tidak mengirim apa pun sampai jawaban selesai, sehingga seluruh proses pembuatan jawaban harus selesai dalam satu jendela timeout tersebut. Karena itu, model yang sama dapat berfungsi di jendela chat tetapi mengalami timeout saat dipanggil dari skrip.

location / {
    proxy_pass http://127.0.0.1:11434;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    proxy_buffering off;
}

sudo nginx -t && sudo systemctl reload nginx

proxy_buffering off penting untuk streaming. Jika buffering aktif, nginx dapat mengumpulkan respons lalu meneruskannya sekaligus pada akhir proses. Akibatnya, token tidak lagi muncul satu per satu dan stream yang sebenarnya berjalan akan terlihat seperti hang.

Traefik menempatkan pengaturan yang sama pada ServersTransport yang digunakan oleh router.

http:
  serversTransports:
    ollama:
      forwardingTimeouts:
        dialTimeout: "30s"
        responseHeaderTimeout: "0s"
        idleConnTimeout: "60s"

responseHeaderTimeout mencakup waktu tunggu untuk header respons setelah permintaan selesai ditulis, dan nilai zero berarti tidak ada timeout. Service harus mereferensikan transport berdasarkan namanya dengan serversTransport: ollama. Jika tidak, Anda mungkin mengubah blok konfigurasi yang tidak digunakan apa pun.

Quantisation yang lebih kecil memuat lebih cepat karena data yang harus dibaca lebih sedikit

Quantisation adalah tingkat presisi penyimpanan bobot. Presisi yang lebih rendah menghasilkan file yang lebih kecil, dan proses memuat model pada dasarnya hanya membaca file tersebut dari disk ke memori.

[
  {
    "label": "q4_K_M",
    "download_size_gb": 4.9
  },
  {
    "label": "q8_0",
    "download_size_gb": 8.5
  },
  {
    "label": "fp16",
    "download_size_gb": 16
  }
]

Ukuran tersebut adalah ukuran yang dipublikasikan pada halaman model, bukan hasil pengukuran dari server pengujian. Build 8B default berukuran 4.9 GB. Build dengan presisi penuh dari model yang sama berukuran 16 GB. Ukuran ini memerlukan lebih dari tiga kali jumlah byte untuk dibaca dan lebih dari tiga kali kapasitas memori untuk menampungnya. Pada server sewaan dengan penyimpanan bersama, perbedaan tersebut dapat menentukan apakah proses pemuatan selesai atau mengalami timeout. Menghitung model yang sesuai dengan RAM Anda adalah pemeriksaan yang perlu dilakukan sebelum mengunduh file berukuran besar.

Yang perlu diubah pada server sewaan

Terapkan perubahan ini sesuai urutan yang ditunjukkan oleh hasil pengukuran, satu per satu, lalu jalankan kembali perintah pengukuran waktu setelah setiap perubahan.

1. Tetapkan model dengan OLLAMA_KEEP_ALIVE=-1, atau muat model saat boot, agar tidak ada permintaan pengguna yang menanggung waktu pemuatan.
2. Turunkan num_ctx sesuai kebutuhan prompt Anda. Langkah ini mempersingkat prefill dan membebaskan memori yang digunakan oleh cache KV.
3. Gunakan quantisation yang lebih kecil agar proses pemuatan membaca lebih sedikit byte dan model menyisakan ruang untuk cache.
4. Naikkan proxy_read_timeout di nginx atau responseHeaderTimeout di Traefik, lalu nonaktifkan buffering agar token yang dialirkan segera sampai ke client.
5. Naikkan timeout di client Anda sendiri. Program Go atau Python dengan batas waktu 30 detik akan gagal jika model membutuhkan waktu lebih lama untuk memproses permintaan.

Ada satu penyebab lain yang mendasari semua masalah ini. Ollama hanya melayani sejumlah permintaan secara bersamaan dan mengantrekan permintaan lainnya. Akibatnya, pemanggil kedua dapat tertahan dalam antrean hingga batas waktunya sendiri berakhir, meskipun tidak ada model yang berjalan lambat. Log server menunjukkan bahwa permintaan tersebut dilayani terlambat, bukan gagal. Yang terjadi saat beberapa orang menggunakan satu server Ollama membahas pengaturan paralelisme, sedangkan instalasi dasar pada VPS membahas penyiapan service yang diasumsikan oleh override ini.

FAQ

Apa arti "context deadline exceeded" di Ollama?

Artinya, batas waktu permintaan berakhir sebelum model memberikan jawaban. Frasa ini berasal dari paket context milik Go. Karena itu, pesan tersebut dicetak oleh program Go: alat baris perintah Ollama, server Ollama, atau aplikasi Go yang memanggil API. Ini adalah timeout, bukan tanda bahwa sesuatu rusak atau korup. Langkah berikutnya adalah mencari lapisan yang menetapkan batas waktu tersebut, karena client, pemuatan model, keep_alive, num_ctx, dan reverse proxy masing-masing menetapkan batas waktunya sendiri.

Sebaiknya saya menaikkan timeout client atau timeout Ollama?

Lakukan pengukuran terlebih dahulu. Kirim permintaan menggunakan curl pada server itu sendiri, langsung ke http://127.0.0.1:11434, karena curl tidak menetapkan batas waktu keseluruhan. Jika panggilan tersebut mengembalikan isi JSON, berarti Ollama merespons dan batas waktu berasal dari client atau proxy Anda. Naikkan timeout pada lapisan tersebut. Jika panggilan itu juga macet, berarti keterlambatan terjadi di dalam Ollama. Field load_duration dan prompt_eval_duration pada respons menunjukkan apakah model sedang dimuat atau membaca prompt Anda.

Mengapa permintaan pertama mengalami timeout, tetapi permintaan berikutnya berhasil?

Ollama membongkar model yang tidak aktif untuk membebaskan memori, berdasarkan jadwal yang ditetapkan oleh keep_alive. Nilai default yang didokumentasikan adalah 5 menit, berdasarkan pemeriksaan pada September 2026. Permintaan pertama setelah periode tidak aktif harus memuat ulang model dari disk dan mengalami seluruh waktu cold start. Sebaliknya, permintaan yang dikirim segera setelahnya menemukan model masih berada di memori dan selesai dengan cepat. Jalankan ollama ps untuk melihat model yang sedang dimuat dan waktu kedaluwarsanya. Atur OLLAMA_KEEP_ALIVE=-1 agar model tetap berada di memori, dengan konsekuensi bahwa memori tersebut akan tetap terpakai.

Mengapa masalah ini hanya terjadi saat saya melewati nginx?

nginx mendokumentasikan proxy_read_timeout dengan nilai default 60s. Timeout tersebut berlaku di antara dua pembacaan berturut-turut, bukan untuk seluruh respons. Respons streaming mereset timeout itu pada setiap chunk, sedangkan permintaan yang dikirim menggunakan "stream": false harus selesai dalam satu jendela waktu. Karena itu, jendela chat berfungsi, tetapi skrip gagal. Cari upstream timed out (110: Connection timed out) while reading response header from upstream di log error nginx, lalu naikkan proxy_read_timeout dan atur proxy_buffering off.

Apakah menaikkan OLLAMA_LOAD_TIMEOUT membuat pemuatan lebih cepat?

Tidak. Pengaturan tersebut hanya mengubah berapa lama server menunggu sebelum berhenti mencoba dan mencatat timed out waiting for llama runner to start. Jika model tidak muat di memori, mesin akan menggunakan swap, proses pemuatan menjadi sangat lambat, dan timeout yang lebih besar hanya menunda kegagalan tanpa memperbaikinya. Periksa nilai default untuk build Anda dengan menjalankan ollama --version dan membaca envconfig/config.go pada tag tersebut. Jika pemuatan memerlukan waktu beberapa menit, anggap itu sebagai tanda untuk menggunakan quantisation yang lebih kecil.