วิธีแก้ปัญหา Ollama context deadline exceeded

ความหมายที่แท้จริงของ "context deadline exceeded"

ข้อผิดพลาด context deadline exceeded ใน Ollama คือการแจ้งเตือนว่าหมดเวลา (timeout) โค้ดภาษา Go บางส่วนได้กำหนดเส้นตาย (deadline) ให้กับคำขอไว้ แต่โมเดลประมวลผลไม่เสร็จภายในเวลาที่กำหนด เส้นตายจึงสิ้นสุดลง ไม่ได้มีส่วนใดของระบบล่มหรือไฟล์เสียหาย งานยังคงดำเนินการอยู่ขณะที่เวลาหมดลง

ถ้อยคำนี้มาจากแพ็กเกจ context มาตรฐานของ Go ซึ่งเป็นเบาะแสที่มีประโยชน์ในตัวมันเอง ไคลเอนต์ภาษา Python ที่สร้างบน httpx จะแสดงข้อผิดพลาด httpx.ReadTimeout แทน ส่วนเบราว์เซอร์จะแสดงข้อผิดพลาดเครือข่ายทั่วไป หากคุณกำลังอ่านข้อความนี้ แสดงว่าโปรแกรมภาษา Go ได้ยกเลิกการรอคอยไปแล้ว ไม่ว่าจะเป็นเครื่องมือบรรทัดคำสั่งของ Ollama, ตัวเซิร์ฟเวอร์ Ollama เอง หรือแอปพลิเคชันภาษา Go ที่เรียกใช้งาน API (application programming interface)

มี 5 เลเยอร์ที่สามารถกำหนดเส้นตายดังกล่าวได้ แต่ละเลเยอร์จะล้มเหลวในจุดที่ต่างกันและต้องใช้วิธีแก้ไขที่ต่างกัน งานของคุณคือการระบุว่าเลเยอร์ใดที่เป็นต้นเหตุ

1. HTTP client ของคุณ ซึ่งกำหนดงบประมาณเวลาคงที่ให้กับคำขอ
2. การตั้งค่า timeout ในการโหลดโมเดลของเซิร์ฟเวอร์ Ollama ซึ่งจะทำงานในขณะที่โมเดลขนาดใหญ่กำลังถูกอ่านจากดิสก์เป็นครั้งแรก
3. keep_alive ซึ่งจะยกเลิกการโหลดโมเดลระหว่างคำขอ ทำให้การเรียกใช้งานครั้งถัดไปต้องเสียเวลาโหลดใหม่อีกครั้ง
4. num_ctx ที่มีขนาดใหญ่จนการประมวลผล prompt เพียงอย่างเดียวใช้เวลาหลายนาทีบนเครื่องที่ไม่มี GPU
5. Reverse proxy เช่น nginx หรือ Traefik ซึ่งตัดการเชื่อมต่อก่อนที่ Ollama จะตอบกลับ

ให้ตรวจสอบตามรายการนี้จากบนลงล่าง แต่ละขั้นตอนด้านล่างจะช่วยตัดเลเยอร์ที่ไม่เกี่ยวข้องออกไป เพื่อให้คุณไม่ต้องคาดเดาสาเหตุอีกต่อไป

ทดสอบกับ API โดยตรงเพื่อตัดปัญหาเรื่อง proxy

ให้รันคำสั่ง request บนเซิร์ฟเวอร์โดยตรงไปยัง Ollama โดยไม่ผ่าน 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 ไม่มีการกำหนดระยะเวลา timeout รวมไว้ในตัว แต่จะมีเพียง connect timeout เท่านั้น ดังนั้นคำสั่งนี้จะรอจนกว่า Ollama จะประมวลผลเสร็จ ซึ่งจะช่วยแยกปัญหาออกเป็นสองส่วน หากได้รับ JSON body กลับมา แสดงว่า Ollama ตอบสนองได้ปกติ และปัญหาเรื่องระยะเวลาเกิดจากส่วนประกอบที่อยู่หน้า Ollama แต่หากคำสั่งนี้ค้างไปนานหลายนาที แสดงว่าความล่าช้าเกิดขึ้นภายใน Ollama เอง และ proxy ของคุณก็ไม่มีส่วนเกี่ยวข้อง

จากนั้นให้ส่ง request เดิมผ่าน public URL ของคุณและจับเวลา

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}'

หากสถานะ 504 ปรากฏขึ้นหลังจากผ่านไปเป็นจำนวนวินาทีที่ลงตัวอย่างน่าสงสัย เช่น 60.0 หรือ 30.0 แสดงว่าเกิดปัญหา proxy timeout เนื่องจาก proxy มักใช้ค่าเริ่มต้นที่เป็นตัวเลขกลมๆ โดยปกติแล้วโมเดลจะไม่ประมวลผลเสร็จสิ้นที่เวลา 60.000 วินาทีพอดีเป๊ะสองครั้งติดต่อกัน หากการเรียกใช้งานโดยตรงถูกปฏิเสธทันทีแทนที่จะช้า แสดงว่าคุณมีปัญหาเรื่อง listener ไม่ใช่ปัญหาเรื่อง deadline ซึ่งกรณีนี้ครอบคลุมอยู่ในหัวข้อ ที่อยู่ซึ่ง Ollama ผูกไว้บนพอร์ต 11434

ตรวจสอบ log ของเซิร์ฟเวอร์ขณะที่คำขอทำงาน

เปิด session ที่สองแล้วติดตาม log ของบริการ จากนั้นส่งคำขออีกครั้ง

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

การเริ่มต้นแบบ cold start ที่ปกติจะแสดง log การโหลดโมเดล ตามด้วยการเริ่ม runner และการให้บริการคำขอ หากการโหลดล้มเหลวจะแสดงข้อความในลักษณะนี้แทน ซึ่งเป็นข้อความที่ระบุถึงปัญหา load timeout ของเซิร์ฟเวอร์เอง:

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

ข้อความดังกล่าวหมายความว่ากระบวนการโหลดโมเดลไม่เสร็จสิ้นภายในระยะเวลาที่เซิร์ฟเวอร์กำหนด ตัวเลขความคืบหน้าจะบอกว่ากระบวนการไปถึงจุดใดแล้ว หากค่าเป็น 0.00 หมายความว่า runner ไม่รายงานสถานะใดๆ ออกมาก่อนครบกำหนดเวลา ซึ่งมักเกิดจากการที่ระบบกำลังอ่านไฟล์หรือเครื่องกำลังทำ swapping หากต้องการรายละเอียดเพิ่มเติมระหว่างการโหลด ให้รีสตาร์ทบริการโดยตั้งค่า OLLAMA_DEBUG=1 แล้วลองใหม่อีกครั้ง

วัดผลว่าความล่าช้าเกิดจากการโหลดหรือการสร้างคำตอบ

Ollama จะรายงานเวลาที่ใช้ด้วยตัวเอง คุณจึงไม่ต้องคาดเดาส่วนนี้

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

หลังจากแสดงคำตอบ Ollama จะพิมพ์ total duration, load duration, prompt eval count, prompt eval rate, eval count และ eval rate ออกมา ให้ลองรันคำสั่งสองครั้ง ในการรันครั้งที่สองค่า load duration ควรลดลงจนเกือบเป็นศูนย์ เนื่องจากโมเดลถูกโหลดไว้ในหน่วยความจำแล้ว หากค่าไม่ลดลง แสดงว่าโมเดลถูกยกเลิกการโหลดระหว่างการรันทั้งสองครั้ง ซึ่งเป็นกรณี keep_alive ที่จะกล่าวถึงต่อไป

ตัวเลขชุดเดียวกันจะถูกส่งกลับมาจาก API ในออบเจกต์ JSON สุดท้ายในชื่อ load_duration, prompt_eval_duration และ eval_duration เอกสารระบุว่าระยะเวลาทั้งหมดจะส่งกลับมาในหน่วยนาโนวินาที ดังนั้นให้หารด้วย 10^9 เพื่อแปลงเป็นวินาที

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")})'

ให้พิจารณาตัวเลขที่มากที่สุด หาก load_duration มีค่าสูงที่สุด แสดงว่าคุณมีปัญหาเรื่องการโหลดโมเดล ให้ข้ามไปดูสองส่วนถัดไป หาก prompt_eval_duration มีค่าสูงที่สุด แสดงว่าต้นทุนอยู่ที่การประมวลผล prompt ให้ข้ามไปที่ส่วน num_ctx หาก eval_duration มีค่าสูงที่สุด แสดงว่าโมเดลกำลังสร้างคำตอบช้าบนฮาร์ดแวร์นี้ และไม่มีการตั้งค่า timeout ใดที่จะแก้ไขได้ ให้ลดความยาวของผลลัพธ์ด้วย num_predict หรือเปลี่ยนไปใช้โมเดลที่มีขนาดเล็กลง

เพิ่มค่า OLLAMA_LOAD_TIMEOUT หลังจากตรวจสอบเวอร์ชันของคุณ

ตัวแปรเซิร์ฟเวอร์ที่ควบคุมระยะเวลาการรอให้โมเดลเริ่มทำงานคือ OLLAMA_LOAD_TIMEOUT ค่าเริ่มต้นของตัวแปรนี้มีการเปลี่ยนแปลงระหว่างการออกรุ่น (release) ดังนั้นให้ตรวจสอบจากเวอร์ชันที่คุณใช้งานจริงแทนการอ้างอิงจากบทความใดๆ รวมถึงบทความนี้ด้วย ให้พิมพ์เวอร์ชันออกมาก่อน

ollama --version

จากนั้นให้เปิดซอร์สโค้ดสำหรับแท็กนั้นโดยเฉพาะที่ https://github.com/ollama/ollama/blob/<your version>/envconfig/config.go แล้วค้นหา OLLAMA_LOAD_TIMEOUT ค่าที่อยู่ในไฟล์นั้นคือค่าเริ่มต้นที่ถูกคอมไพล์มาพร้อมกับไบนารีของคุณ ให้กำหนดค่าของคุณเองผ่านทาง systemd drop-in

sudo systemctl edit ollama.service

เพิ่มตัวแปรต่างๆ ไว้ภายใต้ส่วน [Service] ซึ่งเป็นวิธีที่เอกสารประกอบของ Ollama แนะนำสำหรับ 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

คำสั่งสุดท้ายจะแสดงสภาพแวดล้อมที่ service ได้รับจริง หากผลลัพธ์ว่างเปล่า แสดงว่าไฟล์ drop-in ถูกบันทึกไว้นอกเครื่องหมายของตัวแก้ไข หรืออยู่ภายใต้ชื่อส่วนที่ไม่ถูกต้อง ทำให้สิ่งที่คุณตั้งค่าไว้ไม่มีผล โปรดทำความเข้าใจให้ชัดเจนว่าสิ่งนี้ช่วยอะไรคุณได้บ้าง: การเพิ่ม timeout ในการโหลดช่วยป้องกันไม่ให้เซิร์ฟเวอร์ยอมแพ้ แต่ไม่ได้ทำให้การทำงานเร็วขึ้นแต่อย่างใด หากโมเดลไม่สามารถโหลดลงในหน่วยความจำได้ เครื่องจะทำการ swap และการโหลดจะช้าลงมาก การเพิ่มตัวเลขให้มากขึ้นเพียงแค่เป็นการเลื่อนเวลาที่ระบบจะล้มเหลวออกไปเท่านั้น

เหตุใดคำขอแรกหลังจากหยุดพักจึงทำงานช้า

Ollama จะยกเลิกการโหลดโมเดลที่ไม่ได้ใช้งานออกจากหน่วยความจำเพื่อคืนพื้นที่ว่าง การตั้งค่า keep_alive จะเป็นตัวกำหนดช่วงเวลาดังกล่าว เอกสารของ Ollama ระบุค่าเริ่มต้นไว้ที่ 5 นาที (ตรวจสอบเมื่อเดือนกันยายน 2026) ดังนั้นแอปแชทที่มีการใช้งานชั่วโมงละครั้งจะโหลดโมเดลใหม่ทุกครั้งที่มีข้อความส่งเข้ามา และทุกข้อความจะต้องรอการเริ่มต้นระบบใหม่ (cold start) ทั้งหมด คำขอที่หมดเวลา (timeout) คือคำขอแรกหลังจากช่วงเวลาที่ไม่มีการใช้งาน ซึ่งตรงกับรูปแบบที่ผู้ใช้มักอธิบายว่าเป็นปัญหาที่เกิดขึ้นแบบสุ่ม

ตรวจสอบว่ามีโมเดลใดอยู่ในหน่วยความจำขณะนี้:

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

หากรายการว่างเปล่า หรือมีเวลาหมดอายุเหลืออีกเพียงไม่กี่นาที นั่นเป็นการยืนยันสถานะดังกล่าว keep_alive รองรับค่าที่เป็นสตริงระยะเวลา เช่น "10m" หรือ "24h", ตัวเลขจำนวนวินาทีปกติ, 0 เพื่อยกเลิกการโหลดทันที หรือตัวเลขติดลบเพื่อเก็บโมเดลไว้ในหน่วยความจำอย่างถาวร คุณสามารถตั้งค่านี้ได้ในแต่ละคำขอ หรือตั้งค่า OLLAMA_KEEP_ALIVE ไว้ที่ตัวบริการเพื่อให้มีผลกับทุกคำขอ

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

คำขอที่มีการระบุโมเดลแต่ไม่มี prompt จะเป็นการโหลดโมเดลแล้วส่งค่ากลับทันที นี่เป็นวิธีที่ระบุไว้ในเอกสารสำหรับการเตรียมระบบให้พร้อม (warm-up) หลังจากรีบูต และควรนำไปใส่ไว้ใน systemd unit ขนาดเล็ก เพื่อไม่ให้ผู้ใช้ต้องรอการเริ่มต้นระบบใหม่ ค่าใช้จ่ายที่เกิดขึ้นคือความจริงที่ว่าโมเดลที่ถูกตรึงไว้ (pinned model) จะใช้หน่วยความจำตลอดไป ดังนั้นบนเครื่องที่มีทรัพยากรจำกัด คุณจะสามารถตรึงโมเดลได้เพียงหนึ่งโมเดล ไม่ใช่สี่โมเดล การคงโมเดลไว้ในหน่วยความจำระหว่างคำขอ จะอธิบายรายละเอียดเกี่ยวกับการคำนวณหน่วยความจำและหน่วยการทำงานสำหรับการเตรียมระบบให้พร้อม

เหตุใด num_ctx ขนาดใหญ่จึงทำให้หมดเวลา (timeout) ก่อนแสดงโทเค็นแรก

ก่อนที่โมเดลจะเขียนข้อความใดๆ โมเดลจะต้องอ่าน prompt ทั้งหมดของคุณก่อน ขั้นตอนนี้เรียกว่า prefill ซึ่งเป็นสิ่งที่ prompt eval ใช้วัดผล num_ctx เป็นตัวกำหนดความยาวของบริบท (context length) ซึ่งส่งผลสองอย่างพร้อมกัน คือจำกัดจำนวนโทเค็นที่โมเดลจะพิจารณา และกำหนดขนาดของ KV cache (key value cache) ที่เซิร์ฟเวอร์ต้องจัดสรรไว้ล่วงหน้า ทั้งสองอย่างนี้ทำให้ภาระงานเพิ่มขึ้น

บนเซิร์ฟเวอร์ที่ใช้เฉพาะ CPU ขั้นตอน prefill จะทำงานช้าและเป็นสัดส่วนโดยตรงกับจำนวนโทเค็นใน prompt เอกสารขนาดยาวที่ถูกวางลงในแชทอาจใช้เวลาหลายนาทีในขั้นตอน prefill โดยที่ฝั่งไคลเอนต์ไม่เห็นผลลัพธ์ใดๆ เนื่องจากกระบวนการสตรีมมิ่งยังไม่เริ่มต้น ไคลเอนต์จึงพบกับกำหนดเวลาที่ตั้งไว้และรายงานข้อผิดพลาดว่า context deadline exceeded ทั้งที่เซิร์ฟเวอร์ยังคงทำงานอยู่ตลอดเวลา คุณสามารถพิสูจน์ได้ด้วยตัวเลขจากส่วนก่อนหน้า: ให้รัน prompt เดียวกันด้วย "options": {"num_ctx": 2048} แล้วตามด้วย 32768 จากนั้นเปรียบเทียบค่า prompt_eval_duration

ค่าเริ่มต้นของเซิร์ฟเวอร์มาจาก OLLAMA_CONTEXT_LENGTH และสามารถใช้ num_ctx ในออบเจกต์ options เพื่อกำหนดค่าเฉพาะสำหรับแต่ละคำขอได้ ข้อผิดพลาดที่พบบ่อยคือการปรับค่าขึ้นไปจนถึงค่าสูงสุดที่โมเดลรองรับเพียงเพราะค่าสูงสุดนั้นมีอยู่จริง เนื่องจากขนาดของ KV cache ที่ถูกจัดสรรอาจทำให้โมเดลใช้ RAM จนเต็มและเปลี่ยนระบบที่ทำงานได้ปกติให้กลายเป็นการใช้ swap แทน การเลือก num_ctx ให้เหมาะสมกับหน่วยความจำจริงของคุณ มีรายละเอียดเกี่ยวกับการคำนวณขนาดที่เหมาะสม

เหตุใด nginx จึงส่งคืนข้อผิดพลาด 504 Gateway Time-out

เอกสารของ nginx ระบุถึง proxy_read_timeout โดยมีค่าเริ่มต้นเป็น 60s และ log ของข้อผิดพลาดจะระบุสาเหตุไว้อย่างชัดเจน:

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

รายละเอียดที่สำคัญอยู่ในเอกสารของ nginx: ค่า timeout "จะถูกกำหนดเฉพาะระหว่างการอ่านข้อมูลสองครั้งที่ต่อเนื่องกัน ไม่ใช่สำหรับระยะเวลาการส่งข้อมูลทั้งหมด" การตอบสนองแบบ streaming จะรีเซ็ตเวลาใหม่ในทุกๆ chunk ดังนั้นการแชทแบบ streaming จึงไม่ถูกตัดการเชื่อมต่อ แต่คำขอที่ใช้ "stream": false จะไม่ส่งข้อมูลใดๆ ออกมาจนกว่าคำตอบจะเสร็จสมบูรณ์ ดังนั้นการประมวลผลทั้งหมดต้องเสร็จสิ้นภายในช่วงเวลาดังกล่าว นี่คือเหตุผลว่าทำไมโมเดลเดียวกันจึงทำงานได้ในหน้าต่างแชท แต่กลับเกิด timeout เมื่อเรียกผ่านสคริปต์

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 มีความสำคัญต่อการทำ streaming หากเปิดใช้งาน buffering ไว้ nginx จะรวบรวมการตอบสนองและส่งมอบให้เมื่อเสร็จสิ้น ทำให้ token ไม่ปรากฏออกมาทีละตัว และ stream ที่ทำงานอยู่จะดูเหมือนค้างไป

Traefik ใช้การควบคุมแบบเดียวกันนี้ใน ServersTransport ที่ router ใช้งาน

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

responseHeaderTimeout ครอบคลุมถึงการรอ response header หลังจากเขียนคำขอเสร็จสิ้น โดยค่าศูนย์หมายถึงไม่มีการจำกัดเวลา บริการจะต้องอ้างอิง transport ด้วยชื่อผ่านทาง serversTransport: ollama มิฉะนั้นคุณอาจกำลังแก้ไขบล็อกที่ไม่มีการเรียกใช้งานจริง

การทำ Quantisation ขนาดเล็กช่วยให้โหลดได้เร็วขึ้นเนื่องจากมีข้อมูลที่ต้องอ่านน้อยลง

Quantisation คือความละเอียดที่ใช้ในการจัดเก็บค่าน้ำหนัก (weights) ความละเอียดที่ต่ำกว่าหมายถึงไฟล์ที่มีขนาดเล็กลง และการโหลดโมเดลส่วนใหญ่คือการอ่านไฟล์นั้นจากดิสก์เข้าสู่หน่วยความจำ

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

ขนาดเหล่านี้เป็นขนาดที่ประกาศไว้บนหน้าโมเดล ไม่ใช่ค่าที่วัดจากเครื่องทดสอบ รุ่น 8B มาตรฐานมีขนาดไฟล์อยู่ที่ 4.9 GB ในขณะที่รุ่นความละเอียดเต็มของโมเดลเดียวกันมีขนาด 16 GB ซึ่งต้องอ่านข้อมูลมากกว่าสามเท่าและใช้หน่วยความจำในการเก็บมากกว่าสามเท่า บนเซิร์ฟเวอร์เช่าที่ใช้พื้นที่จัดเก็บร่วมกัน ความแตกต่างนี้คือช่องว่างทั้งหมดระหว่างการโหลดที่เสร็จสมบูรณ์กับการโหลดที่เกินเวลา (timeout) การคำนวณว่าโมเดลใดเหมาะสมกับ RAM ของคุณ คือสิ่งที่ควรตรวจสอบก่อนที่จะดึงข้อมูลขนาดใหญ่ใดๆ มาใช้งาน

สิ่งที่ควรปรับเปลี่ยนบนเซิร์ฟเวอร์เช่า

ให้ดำเนินการตามลำดับที่การวัดผลระบุไว้ โดยปรับทีละรายการและรันคำสั่งวัดเวลาซ้ำหลังจากปรับแต่ละครั้ง

1. ตรึงโมเดลไว้ด้วย OLLAMA_KEEP_ALIVE=-1 หรืออุ่นเครื่องโมเดลตอนบูต เพื่อไม่ให้คำขอของผู้ใช้ต้องแบกรับภาระเวลาในการโหลด
2. ปรับลด num_ctx ให้เหลือเท่าที่ prompt ของคุณจำเป็นต้องใช้จริง ซึ่งจะช่วยลดระยะเวลา prefill และคืนหน่วยความจำที่ KV cache เคยจองไว้
3. เลือกใช้ quantisation ที่เล็กลง เพื่อให้การโหลดอ่านข้อมูลจำนวนไบต์ที่น้อยลง และเหลือพื้นที่ในโมเดลสำหรับ cache
4. เพิ่มค่า proxy_read_timeout ใน Nginx หรือ responseHeaderTimeout ใน Traefik และปิดการใช้งาน buffering เพื่อให้ token ที่สตรีมมาถึงฝั่งไคลเอนต์ได้ทันที
5. เพิ่มค่า timeout ในไคลเอนต์ของคุณ เนื่องจากโปรแกรมที่เขียนด้วย Go หรือ Python ซึ่งตั้งงบประมาณเวลาไว้ที่ 30 วินาที จะล้มเหลวเมื่อเจอกับโมเดลที่ใช้เวลาประมวลผลนานกว่านั้น

ยังมีอีกสาเหตุหนึ่งที่ซ่อนอยู่เบื้องหลังปัจจัยเหล่านี้ Ollama รองรับจำนวนคำขอพร้อมกันได้จำกัดและจะนำคำขอที่เหลือเข้าคิว ดังนั้นผู้เรียกใช้งานรายที่สองอาจต้องรออยู่ในคิวจนกระทั่งครบกำหนดเวลา (deadline) โดยที่ตัวโมเดลไม่ได้ทำงานช้าแต่อย่างใด บันทึกของเซิร์ฟเวอร์จะแสดงให้เห็นว่าคำขอนั้นถูกประมวลผลล่าช้าแทนที่จะล้มเหลว สิ่งที่เกิดขึ้นเมื่อหลายคนใช้งาน Ollama บนเซิร์ฟเวอร์เดียวกัน ครอบคลุมการตั้งค่าการทำงานแบบขนาน และ การติดตั้งพื้นฐานบน VPS ครอบคลุมการตั้งค่า service ที่การปรับแต่งเหล่านี้อ้างอิงถึง

FAQ

"context deadline exceeded" ใน Ollama หมายความว่าอย่างไร

หมายความว่ากำหนดเวลาของคำขอหมดลงก่อนที่โมเดลจะตอบกลับ ข้อความนี้มาจากแพ็กเกจ context ของภาษา Go ซึ่งโปรแกรมที่เขียนด้วย Go เป็นผู้แสดงผลออกมา ไม่ว่าจะเป็นเครื่องมือบรรทัดคำสั่งของ Ollama, เซิร์ฟเวอร์ Ollama หรือแอปพลิเคชัน Go ที่เรียกใช้งาน API นี่คือปัญหาเรื่องการหมดเวลา (timeout) ไม่ใช่ความเสียหายหรือข้อมูลผิดพลาด ขั้นตอนถัดไปคือการตรวจสอบว่าเลเยอร์ใดเป็นผู้กำหนดกำหนดเวลานั้น เนื่องจากทั้งฝั่งไคลเอนต์, การโหลดโมเดล, keep_alive, num_ctx และ reverse proxy ต่างก็มีกำหนดเวลาของตนเอง

ฉันควรเพิ่มค่า timeout ที่ฝั่งไคลเอนต์หรือที่ฝั่ง Ollama

ให้วัดผลก่อนเสมอ ให้ส่งคำขอด้วย curl จากบนตัวเซิร์ฟเวอร์โดยตรงไปยัง http://127.0.0.1:11434 เนื่องจาก curl ไม่ได้กำหนดขีดจำกัดเวลาโดยรวมไว้ หากการเรียกใช้งานนั้นได้รับผลลัพธ์เป็น JSON แสดงว่า Ollama ตอบสนองได้ปกติ และปัญหาการหมดเวลาเกิดจากฝั่งไคลเอนต์หรือพร็อกซีของคุณ ให้ไปเพิ่มค่าที่จุดนั้นแทน แต่ถ้าการเรียกใช้งานนั้นค้างเช่นกัน แสดงว่าความล่าช้าเกิดขึ้นภายใน Ollama โดยฟิลด์ load_duration และ prompt_eval_duration ในการตอบกลับจะบอกคุณว่าโมเดลกำลังโหลดอยู่หรือกำลังอ่าน prompt ของคุณ

ทำไมคำขอแรกถึงหมดเวลา แต่คำขอถัดไปกลับทำงานได้ปกติ

Ollama จะยกเลิกการโหลดโมเดลที่ไม่ได้ใช้งานเพื่อคืนหน่วยความจำตามกำหนดเวลาที่ตั้งไว้ด้วย keep_alive โดยค่าเริ่มต้นตามเอกสารคือ 5 นาที (ตรวจสอบข้อมูล ณ เดือนกันยายน 2026) คำขอแรกหลังจากช่วงที่ไม่ได้ใช้งานจะเป็นการโหลดโมเดลจากดิสก์ใหม่ ซึ่งต้องใช้เวลาในการเริ่มต้น (cold start) ในขณะที่คำขอที่ส่งตามมาทันทีจะพบว่าโมเดลยังอยู่ในหน่วยความจำและตอบกลับได้อย่างรวดเร็ว ให้รันคำสั่ง ollama ps เพื่อดูว่ามีโมเดลใดโหลดอยู่บ้างและจะหมดอายุเมื่อใด คุณสามารถตั้งค่า OLLAMA_KEEP_ALIVE=-1 เพื่อคงโมเดลไว้ในหน่วยความจำ แต่ต้องยอมรับว่าหน่วยความจำจะถูกใช้งานตลอดเวลา

ทำไมถึงล้มเหลวเฉพาะตอนที่ผ่าน nginx

nginx มีการตั้งค่า proxy_read_timeout โดยมีค่าเริ่มต้นคือ 60s ซึ่งค่า timeout นี้จะใช้กับการอ่านข้อมูลสองครั้งที่ต่อเนื่องกัน ไม่ใช่กับเวลาตอบกลับทั้งหมด การตอบกลับแบบ streaming จะรีเซ็ตค่านี้ในทุกๆ chunk ข้อมูล ในขณะที่คำขอที่ส่งด้วย "stream": false จะต้องเสร็จสิ้นภายในหน้าต่างเวลาเดียว นี่คือเหตุผลว่าทำไมหน้าต่างแชทถึงทำงานได้แต่สคริปต์กลับล้มเหลว ให้ตรวจสอบหา upstream timed out (110: Connection timed out) while reading response header from upstream ใน log ของ nginx จากนั้นให้เพิ่มค่า proxy_read_timeout และตั้งค่า proxy_buffering off

การเพิ่มค่า OLLAMA_LOAD_TIMEOUT จะช่วยให้โหลดเร็วขึ้นหรือไม่

ไม่ช่วย ค่านี้เปลี่ยนเพียงระยะเวลาที่เซิร์ฟเวอร์จะรอคอยก่อนที่จะยอมแพ้และบันทึก timed out waiting for llama runner to start ลงใน log เท่านั้น หากโมเดลมีขนาดใหญ่เกินกว่าหน่วยความจำ เครื่องจะทำการ swap ทำให้การโหลดช้าลงมาก และการเพิ่มค่า timeout เพียงแค่ทำให้ความล้มเหลวเกิดขึ้นช้าลงโดยไม่ได้แก้ไขปัญหาที่ต้นเหตุ ให้ตรวจสอบค่าเริ่มต้นสำหรับ build ของคุณโดยรัน ollama --version และอ่าน envconfig/config.go ที่แท็กนั้น หากการโหลดต้องใช้เวลานานหลายนาที ให้พิจารณาเปลี่ยนไปใช้โมเดลที่มีการทำ quantisation ขนาดเล็กลงแทน