วิธีติดตั้ง Ollama บน VPS เพื่อรัน LLM ส่วนตัวอย่างปลอดภัย

สิ่งที่คุณกำลังสร้าง

คุณกำลังสร้างโมเดลภาษาแบบ open-weight ที่ทำงานบนเซิร์ฟเวอร์ของคุณเอง โดยตอบสนองผ่าน HTTP API และหน้าแชทบนเบราว์เซอร์หากคุณต้องการ Ollama คือเครื่องมือที่ทำหน้าที่ดาวน์โหลดโมเดล โหลดเข้าหน่วยความจำ และให้บริการคำขอที่ http://127.0.0.1:11434 การติดตั้งทำได้ด้วยคำสั่งเดียว ความยากลำบากทั้งหมดอยู่ที่ส่วนอื่น ได้แก่ การเลือกโมเดลที่ VPS ของคุณมี RAM เพียงพอจะรองรับ และการป้องกันไม่ให้เปิดเผย inference server ที่ไม่มีการยืนยันตัวตนออกสู่สาธารณะโดยไม่ตั้งใจ

คำเตือนที่สำคัญสองประการ: VPS ที่ใช้เฉพาะ CPU จะประมวลผลโมเดลขนาดเล็กได้ช้า และตัว API ไม่มีระบบยืนยันตัวตนในตัว ทั้งสองประเด็นนี้จะถูกอธิบายโดยละเอียดด้านล่าง เนื่องจากเป็นจุดที่มักเกิดปัญหาบ่อยครั้ง

ความเป็นจริงเรื่องขนาดในเชิงตัวเลข

หน่วยความจำที่โมเดลใช้จะมีขนาดใกล้เคียงกับขนาดไฟล์ บวกด้วย overhead ขณะทำงานประมาณ 1 GB และบวกเพิ่มอีกเล็กน้อยสำหรับ context window โดยค่าเริ่มต้นของโมเดลยอดนิยมส่วนใหญ่ใน Ollama ซึ่งรวมถึง llama3.2:3b, llama3.1:8b และ mistral:7b นั้นเป็นแบบ 4-bit quantized (ระบุว่า Q4_K_M) ซึ่งใช้ RAM ประมาณครึ่ง GB ต่อทุกๆ 1 พันล้านพารามิเตอร์ ไม่ใช่ทุกโมเดลที่จะเป็น Q4 โดยค่าเริ่มต้น เช่น โมเดลขนาดเล็กอย่าง smollm2:135m จะมาในรูปแบบ 16-bit ดังนั้นควรตรวจสอบบรรทัด quantization ในหน้า library ของโมเดลก่อนคำนวณ การคำนวณจึงเป็นเรื่องง่ายและเป็นตัวตัดสินทุกอย่าง ส่วนสุดท้ายคือสิ่งที่คุณกำหนดเอง: การเพิ่ม num_ctx ให้มากกว่าค่าเริ่มต้นที่น้อยของ Ollama จะช่วยให้ใส่ prompt ได้ยาวขึ้น แต่จะทำให้ KV cache ใน RAM เพิ่มขึ้น ดังนั้นควรตัดสินใจเรื่องความยาวของ context ก่อนที่จะประเมินว่าโมเดลนั้นเหมาะสมหรือไม่

โมเดลขนาด 3B อย่าง llama3.2:3b มีขนาดไฟล์ดาวน์โหลดประมาณ 2 GB และต้องการ RAM ว่างประมาณ 4 GB ในการทำงาน โมเดลขนาด 7B หรือ 8B อย่าง mistral:7b หรือ llama3.1:8b มีขนาดประมาณ 5 GB บนดิสก์และต้องการ RAM ประมาณ 8 GB หรือ 16 GB เพื่อให้ทำงานได้อย่างราบรื่น โมเดลขนาด 13B หรือ 14B ต้องการ RAM ประมาณ 16 GB ส่วนโมเดลในช่วง 30B ถึง 70B จำเป็นต้องใช้เครื่องที่มี RAM ขนาดใหญ่ หรือในทางปฏิบัติคือต้องใช้ GPU หากรันบน CPU VPS โมเดลเหล่านี้อาจไม่สามารถโหลดได้ หรือตอบสนองช้าจนใช้งานจริงไม่ได้

ในส่วนของความเร็ว ซึ่งเป็นสิ่งที่คนมักประเมินต่ำเกินไป การทำ inference บน CPU จะถูกจำกัดด้วย memory bandwidth ไม่ใช่ความเร็วสัญญาณนาฬิกา และ VPS ที่ใช้ vCPU ร่วมกับผู้อื่นจะมี bandwidth ที่จำกัด คาดหวังความเร็วได้เพียงหลักหน่วยถึงหลักสิบต้นๆ ต่อวินาที: โมเดลขนาด 7-8B แบบ Q4 อาจทำความเร็วได้ 4 ถึง 10 tokens ต่อวินาที ส่วนโมเดล 3B อาจทำได้ 10 ถึง 25 tokens ต่อวินาที การใช้ GPU จะเร็วกว่าประมาณ 10 เท่า ตัวเลขเหล่านี้เป็นเพียงการประมาณการ วิธีที่ตรงไปตรงมาที่สุดคือการวัดผลบนเครื่องของคุณเอง ซึ่งขั้นตอนการรันด้านล่างจะแสดงวิธีการทำ จงเชื่อมั่นใน eval rate ของคุณ ไม่ใช่ตัวเลขในบทความใดๆ รวมถึงบทความนี้ด้วย

ข้อสรุปในทางปฏิบัติ: โมเดลขนาดเล็กที่ผ่านการทำ quantization บน CPU มีประโยชน์อย่างแท้จริงสำหรับการร่างข้อความ การสรุปความ และการจัดหมวดหมู่ หากคุณยอมรับความเร็วระดับนี้ได้ สำหรับงานที่ใหญ่กว่าหรือต้องการความเร็วสูงกว่านี้ ควรจัดสรรงบประมาณสำหรับ instance ที่มี GPU หากคุณต้องการเห็นการคำนวณนี้แบบละเอียดในโมเดลเฉพาะเจาะจง การรัน Nemotron 3.5 Lightning บน VPS จะครอบคลุมถึง tag ที่ควรดึงมาใช้, RAM ที่จำเป็นต้องใช้จริง และการประเมินว่าการรันบน CPU เพียงอย่างเดียวจะเพียงพอหรือไม่

ในการเปรียบเทียบโมเดลเฉพาะกับเครื่องเฉพาะ ให้ประเมินหน่วยความจำที่ต้องใช้ได้ที่นี่:

การติดตั้ง Ollama

มีวิธีที่สะอาดอยู่ 2 วิธี วิธีที่ง่ายที่สุดบน VPS เปล่าคือการใช้สคริปต์อย่างเป็นทางการ:

curl -fsSL https://ollama.com/install.sh | sh

สคริปต์นี้จะสร้างผู้ใช้ระบบชื่อ ollama ติดตั้งไบนารีไว้ที่ /usr/local/bin/ollama และลงทะเบียน systemd service ชื่อ ollama.service ซึ่งจะเริ่มทำงานตอนบูตเครื่องและผูกพอร์ต 127.0.0.1:11434 ตรวจสอบว่าบริการทำงานอยู่ด้วยคำสั่ง:

systemctl status ollama
ollama --version

หากคุณใช้งาน Docker อยู่แล้ว ให้ใช้คอนเทนเนอร์แทน:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

สังเกตคำนำหน้า 127.0.0.1: ในการแมปพอร์ต ซึ่งเป็นการผูกพอร์ตไว้กับ localhost เท่านั้น การเขียน -p 11434:11434 แทนจะเป็นการเปิดพอร์ตบนทุกอินเทอร์เฟซ ซึ่งเป็นข้อผิดพลาดที่ส่วนความปลอดภัยได้เตือนไว้ เลือกวิธีติดตั้งเพียงวิธีเดียว ห้ามรันสคริปต์และคอนเทนเนอร์พร้อมกัน มิฉะนั้นทั้งสองกระบวนการจะแย่งพอร์ตกันทำงาน

ดึงและรันโมเดลแรกของคุณ

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull จะดาวน์โหลดเลเยอร์ของโมเดลลงในดิสก์ (ประมาณ 2 GB สำหรับโมเดลนี้) run จะโหลดเลเยอร์เหล่านั้นเข้าสู่หน่วยความจำและแสดงพรอมต์ >>> ให้คุณพิมพ์คำถาม โทเคนแรกอาจใช้เวลาหลายวินาทีในขณะที่น้ำหนัก (weights) ถูกโหลดจากดิสก์เข้าสู่ RAM จากนั้นคำตอบจะค่อยๆ แสดงออกมา พิมพ์ /bye เพื่อออกจากแชท โดย Ollama จะยังคงทำงานอยู่เบื้องหลัง

ตรวจสอบสิ่งที่ถูกโหลดและสถานะการใช้งานหน่วยความจำ:

ollama ps

คอลัมน์ PROCESSOR จะแสดงข้อมูลที่เป็นจริง หากขึ้นว่า 100% CPU หมายความว่าไม่มีการใช้ GPU ซึ่งเป็นสาเหตุที่ทำให้การทำงานช้า วัดความเร็วที่แท้จริงด้วยแฟล็ก verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

บรรทัด eval rate ที่แสดงตอนท้ายคือจำนวนโทเคนต่อวินาทีบนฮาร์ดแวร์นี้ ซึ่งเป็นตัวเลขที่คุณควรใช้ในการวางแผนการใช้งาน

ตำแหน่งที่เก็บโมเดลและขนาดพื้นที่ดิสก์ที่ควรจัดเตรียม

เมื่อติดตั้งผ่านสคริปต์และรันในรูปแบบ service โมเดลจะถูกเก็บไว้ในโฮมไดเรกทอรีของผู้ใช้ ollama:

sudo du -sh /usr/share/ollama/.ollama/models

หากรันแบบโต้ตอบ (interactive) ในฐานะผู้ใช้ของคุณเอง โมเดลจะถูกเก็บไว้ใน ~/.ollama/models ส่วนในคอนเทนเนอร์ โมเดลจะถูกเก็บไว้ใน named volume ที่ชื่อ ollama ข้อมูลส่วนนี้มีความสำคัญเนื่องจากน้ำหนักของโมเดลแบบ quantized มีขนาดใหญ่ขึ้นอย่างรวดเร็ว โดยโมเดลขนาด 3B จะใช้พื้นที่ประมาณ 2 GB, ขนาด 7-8B ใช้ประมาณ 5 GB และขนาด 14B ใช้ประมาณ 9 GB หากคุณดาวน์โหลดโมเดล 4 ตัวเพื่อเปรียบเทียบกัน คุณจะใช้พื้นที่ไปถึง 20 GB โดยไม่รู้ตัว ดังนั้นควรจัดสรรขนาดดิสก์ให้เหมาะสมกับจำนวนโมเดลที่คุณต้องการเก็บไว้ และลบโมเดลที่ไม่ใช้งานออกด้วยคำสั่ง ollama rm <model> หาก VPS เครื่องเดียวกันมีการรันบริการอื่นที่ใช้พื้นที่จัดเก็บข้อมูลจำนวนมาก เช่น PhotoPrism หรือ Immich ที่เก็บคลังรูปภาพ ให้หักลบพื้นที่ส่วนนั้นออกจากพื้นที่ว่างที่มีอยู่ก่อน แล้วจึงใช้พื้นที่ที่เหลือเป็นงบประมาณสำหรับจัดเก็บโมเดลของคุณจริงๆ

การรันในฐานะบริการที่คุณควบคุมได้

สคริปต์ติดตั้งได้ลงทะเบียน ollama.service ไว้เรียบร้อยแล้ว ทำให้บริการเริ่มทำงานใหม่เมื่อบูตเครื่องโดยไม่ต้องตั้งค่าเพิ่มเติม การตั้งค่าที่ควรปรับเปลี่ยนคือระยะเวลาที่โมเดลจะคงอยู่ในหน่วยความจำ และในบางระบบคือ bind address ซึ่งทั้งสองอย่างนี้ควรใส่ไว้ใน systemd drop-in เพื่อป้องกันไม่ให้การอัปเกรด Ollama เขียนทับการตั้งค่าของคุณ:

sudo systemctl edit ollama.service

เพิ่มบรรทัดเหล่านี้ภายใต้หัวข้อ [Service] ที่โปรแกรมแก้ไขข้อความแสดงให้คุณเห็น:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE คือระยะเวลาที่โมเดลจะคงอยู่ในหน่วยความจำหลังจากคำขอสุดท้าย (ค่าเริ่มต้นคือ 5 นาที) ให้เพิ่มค่านี้บนเครื่องที่คุณใช้งานตลอดทั้งวันเพื่อหลีกเลี่ยงการโหลด weight ใหม่ทุกครั้ง หรือตั้งค่าเป็น 0 บนเครื่องที่มีทรัพยากรจำกัดเพื่อคืนพื้นที่ RAM ทันทีที่คำขอเสร็จสิ้น หากคุณต้องการให้โมเดลคงอยู่ในหน่วยความจำตลอดไปแทนที่จะเป็นช่วงเวลาที่กำหนดไว้ การคงโมเดล Ollama ไว้ในหน่วยความจำถาวร จะอธิบายถึงฟิลด์ keep_alive ในแต่ละคำขอ และวิธีทำให้ weight พร้อมใช้งานทันทีหลังจากรีบูตแทนที่จะต้องรอการโหลดที่ช้าในคำขอแรก systemctl edit จะโหลดไฟล์ unit ใหม่ให้คุณ ดังนั้นให้รีสตาร์ทบริการเพื่อนำการตั้งค่าไปใช้:

sudo systemctl restart ollama

ประเด็นด้านความปลอดภัยที่สำคัญที่สุด

โดยค่าเริ่มต้น Ollama จะผูกไว้ที่ 127.0.0.1:11434 ดังนั้นเฉพาะโพรเซสที่อยู่บน VPS เท่านั้นที่สามารถเข้าถึงได้ ค่าเริ่มต้นนี้ถูกต้องแล้ว ให้คงไว้เช่นนั้น

API นี้ไม่มีการตรวจสอบสิทธิ์ใดๆ ทั้งสิ้น ไม่มี API key, ไม่มีการล็อกอิน และไม่มีการจำกัดอัตราการใช้งาน (rate limit) รายการอนุญาต (allow-list) เพียงรายการเดียวที่มีคือ OLLAMA_ORIGINS ซึ่งควบคุมเฉพาะแหล่งที่มาของเบราว์เซอร์ที่สามารถเรียกใช้งานได้ (CORS) เท่านั้น แต่ไม่สามารถหยุดการเรียกผ่าน curl หรือสคริปต์จากเครื่องอื่นได้ ใครก็ตามที่เข้าถึงพอร์ต 11434 ได้ สามารถรันโมเดลที่คุณดาวน์โหลดไว้, ดาวน์โหลดโมเดลใหม่, ลบโมเดลทิ้ง หรือทำให้ CPU หรือ GPU ของคุณทำงานเต็มกำลังอย่างต่อเนื่องได้ เครื่องมือสแกนอย่าง Shodan ทำการจัดทำดัชนีอินสแตนซ์ Ollama ที่เปิดสาธารณะไว้หลายพันรายการ และอินสแตนซ์ที่ถูกเปิดเผยจะถูกตรวจพบและถูกนำไปใช้ในทางที่ผิดภายในเวลาไม่กี่ชั่วโมง

ดังนั้น นี่คือข้อผิดพลาดเพียงหนึ่งเดียวที่ห้ามทำ: อย่าตั้งค่า OLLAMA_HOST=0.0.0.0 และเปิดพอร์ต 11434 ในไฟร์วอลล์ของคุณ เพราะนั่นเท่ากับการเผยแพร่เซิร์ฟเวอร์ inference ที่ไม่มีการตรวจสอบสิทธิ์ออกสู่สาธารณะบนอินเทอร์เน็ต ไม่มีการตั้งค่าใดที่จะทำให้การเปิดพอร์ต 11434 บน 0.0.0.0 ปลอดภัยได้ เนื่องจากการตั้งค่าที่ระบุไว้ในเอกสารของ Ollama ไม่มีส่วนใดที่เพิ่มการตรวจสอบสิทธิ์ให้กับ API ภายใน และรายการอนุญาตแหล่งที่มาก็ไม่ใช่การล็อกอิน นี่เป็นกฎเฉพาะสำหรับบริการนี้ ไม่ใช่การห้ามเปิดพอร์ตโดยเด็ดขาด: RustDesk relay ที่โฮสต์เองสำหรับรีโมทเดสก์ท็อป จำเป็นต้องรับทราฟฟิกสาธารณะเพื่อให้ทำงานได้ และบริการนั้นมีความปลอดภัยด้วยการตรวจสอบสิทธิ์ผ่านคีย์ของตนเองและมีรายการพอร์ตที่ชัดเจน ซึ่ง Ollama ไม่มีคุณสมบัติเหล่านี้เลย

มี 3 วิธีที่ปลอดภัยในการเข้าถึงโมเดลจากภายนอกเครื่อง:

• เก็บไว้ในเครื่อง: หากผู้เรียกใช้งานเป็นเพียงโปรแกรมอื่นบน VPS เดียวกัน, สคริปต์ cron, บอท หรือ MCP server ที่เชื่อมต่อเครื่องมือของคุณเข้ากับโมเดล ให้คงการผูกไว้ที่ 127.0.0.1 และให้โปรแกรมนั้นเรียกใช้งานที่ http://127.0.0.1:11434 วิธีนี้จะไม่มีส่วนใดถูกเปิดเผยและไม่จำเป็นต้องทำสิ่งอื่นเพิ่มเติม
• เข้าถึงผ่านอุโมงค์ส่วนตัว (private tunnel): นำ VPS ไปไว้ใน WireGuard VPN ที่คุณโฮสต์เอง ตั้งค่า OLLAMA_HOST ให้เป็นที่อยู่ของอุโมงค์ (ตัวอย่างเช่น 10.8.0.1 ไม่ใช่ 0.0.0.0) และให้เฉพาะสมาชิกใน VPN เท่านั้นที่เชื่อมต่อได้ อินเทอร์เน็ตสาธารณะจะไม่เห็นสิ่งใดบนพอร์ต 11434
• ใช้ reverse proxy ที่มีการตรวจสอบสิทธิ์อยู่ด้านหน้า: ทำ TLS termination และกำหนดให้ต้องใช้รหัสผ่านหรือโทเค็นที่ nginx, Traefik หรือ Caddy จากนั้นจึงทำ proxy ไปยัง 127.0.0.1:11434 โดยให้ Ollama ผูกไว้ที่ localhost ตามเดิม และให้ proxy เป็นเพียงสิ่งเดียวที่ฟังพอร์ตสาธารณะ วิธีนี้มีรูปแบบเดียวกับการนำ ใบรับรอง Let's Encrypt บน nginx มาไว้หน้าบริการภายในใดๆ

ตัวเลือก reverse proxy คือสิ่งที่คุณจะได้รับในขั้นตอนถัดไปจาก chat UI พร้อมกับการเพิ่มระบบล็อกอินจริงเข้าไปด้วย

เพิ่มส่วนติดต่อผู้ใช้สำหรับการแชทด้วย Open WebUI โดยอยู่หลัง TLS

Open WebUI เป็นอินเทอร์เฟซสำหรับการแชทแบบ self-hosted ให้รันผ่าน Docker และชี้ไปยัง Ollama ที่ติดตั้งอยู่ในเครื่อง:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

แฟล็ก --network=host เป็นรายละเอียดที่สำคัญบน Linux VPS โดยจะนำคอนเทนเนอร์ไปไว้ใน network namespace ของโฮสต์ ทำให้ 127.0.0.1 ภายในคอนเทนเนอร์กลายเป็น loopback ของโฮสต์เอง และคอนเทนเนอร์จะเข้าถึง Ollama ได้ที่ 127.0.0.1:11434 โดยที่ Ollama ไม่จำเป็นต้องฟังบนอินเทอร์เฟซอื่น สูตรการใช้ bridge-network ที่คุณอาจพบเห็นที่อื่นอย่าง --add-host=host.docker.internal:host-gateway ร่วมกับ OLLAMA_BASE_URL=http://host.docker.internal:11434 จะใช้ไม่ได้ในกรณีนี้ เนื่องจากชื่อดังกล่าวจะ resolve ไปยัง gateway ของ Docker bridge และบริการที่ผูกไว้กับ 127.0.0.1 บนโฮสต์จะไม่สามารถเข้าถึงได้ผ่าน bridge ส่งผลให้ Open WebUI ค้างและแจ้งเตือนว่าไม่สามารถเชื่อมต่อกับ Ollama ได้

ข้อแลกเปลี่ยนของการใช้ host networking คือ Open WebUI จะฟังบนพอร์ต 8080 ของโฮสต์ในทุกอินเทอร์เฟซ การแมป -p ใดๆ จะถูกละทิ้งและ Docker จะแสดงคำเตือนเกี่ยวกับเรื่องนี้ ดังนั้นให้ปิดพอร์ต 8080 ทั้งที่โฮสต์และไฟร์วอลล์ของผู้ให้บริการ และให้ TLS reverse proxy เป็นประตูสาธารณะเพียงทางเดียว ในการเข้าใช้งานครั้งแรก Open WebUI จะให้คุณสร้างบัญชีผู้ดูแลระบบ บัญชีนั้นจะเป็นชั้นการยืนยันตัวตนของคุณ ดังนั้นควรเลือกใช้รหัสผ่านที่คาดเดายาก

หากต้องการเปิดใช้งานแชทจากแล็ปท็อปของคุณผ่าน HTTPS ให้ติดตั้ง TLS reverse proxy ไว้หน้า 127.0.0.1:8080 หากคุณมีการกำหนดเส้นทางแอป Docker หลายตัวบนเครื่องอยู่แล้ว Traefik พร้อม TLS อัตโนมัติสำหรับหลายแอป จะเป็นวิธีที่เหมาะสมที่สุด: บล็อก label เพียงชุดเดียวจะออกใบรับรองและกำหนดเส้นทาง chat.example.com ไปยัง Open WebUI การกำหนดเส้นทางแบบ label-per-app เช่นนี้เป็นวิธีที่เบราว์เซอร์ front-end อื่นๆ บนเครื่องจะใช้เช่นกัน ไม่ว่าจะเป็นแดชบอร์ดแสดงสถานะหรือแอปที่เน้นความบันเทิงอย่าง Halcyon ซึ่งแสดงคลังสื่อ Jellyfin ในรูปแบบร้านเช่าวิดีโอสมัยยุค 90 โดยแต่ละแอปจะมี hostname ของตนเองและอยู่หลังระบบล็อกอินของตน กฎจากส่วนความปลอดภัยยังคงมีผลบังคับใช้ คือ proxy จะเป็นผู้ดูแลพอร์ตสาธารณะและระบบล็อกอิน ในขณะที่ Ollama จะยังคงอยู่บน localhost และพอร์ต 8080 ของ Open WebUI เองจะถูกปิดกั้นด้วยไฟร์วอลล์ต่อไป

การใช้งาน endpoint ที่รองรับ OpenAI จากโค้ดของคุณ

Ollama รองรับชุดคำสั่งย่อยของ OpenAI chat API ที่ /v1 ดังนั้นไลบรารีไคลเอนต์ของ OpenAI ส่วนใหญ่จึงใช้งานได้โดยการเปลี่ยนค่าสองอย่าง ได้แก่ base URL และคีย์สมมติ

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

api_key เป็นสิ่งที่ไลบรารีไคลเอนต์ต้องการ แต่ Ollama จะเพิกเฉยต่อค่านี้ ดังนั้นคุณสามารถใส่สตริงใดก็ได้ ส่วน model ต้องเป็นชื่อโมเดลที่คุณดึง (pull) มาไว้แล้ว หากระบุชื่อที่ไม่รู้จัก ระบบจะส่งกลับสถานะ 404 พร้อมกับ model 'x' not found การเรียกใช้งานผ่าน curl ก็ใช้หลักการเดียวกัน:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

นี่คือวิธีการเชื่อมต่อโมเดลเข้ากับเครื่องมือสำหรับ agent และ editor หากคุณพัฒนาโปรแกรมบนเซิร์ฟเวอร์อยู่แล้ว โมเดลที่รันในเครื่องสามารถใช้สนับสนุนสคริปต์และปลั๊กอินควบคู่ไปกับ Claude Code ที่รันบน VPS ภายใน tmux ซึ่งช่วยให้งานร่างเนื้อหาที่มีต้นทุนต่ำและต้องการความเป็นส่วนตัวไม่ต้องพึ่งพา API แบบเสียค่าใช้จ่าย ในขณะที่งานที่ต้องใช้การประมวลผลเชิงตรรกะขั้นสูงยังคงใช้โมเดลที่โฮสต์ไว้บนคลาวด์ได้ตามปกติ

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

กระบวนการถูก "Killed" ในระหว่างการสร้างข้อความ คุณเริ่มรันโมเดลขนาดใหญ่แล้วเทอร์มินัลแสดง Killed หรือ log ของเซิร์ฟเวอร์ (journalctl -u ollama) แสดงบรรทัดที่ขึ้นต้นด้วย llama-server process has terminated นี่คือข้อความที่ปรากฏใน Ollama 0.40.7 ซึ่งตรวจสอบเมื่อวันที่ 21 ตุลาคม 2026 ส่วนรุ่นเก่าจะแสดง llama runner process has terminated: signal: killed สาเหตุคือ Linux OOM killer สั่งยุติการทำงานเนื่องจากโมเดลต้องการ RAM มากกว่าที่เครื่องมี ให้ยืนยันสาเหตุด้วย sudo dmesg | grep -i oom ซึ่งคุณจะเห็นบรรทัดที่คล้ายกับ Out of memory: Killed process ... วิธีแก้ไขคือใช้โมเดลที่เล็กลงหรือทำ quantization ให้หนักขึ้น เช่นใช้ llama3.2:3b แทนรุ่น 13B หรือเพิ่ม swap เพื่อให้โหลดที่เกิน RAM จริงเพียงเล็กน้อยยังคงทำงานต่อไปได้ช้าๆ แทนที่จะถูกสั่งปิดทันที Swap จะเปลี่ยนการ crash ทันทีให้กลายเป็นการตอบสนองที่ช้าลง แต่ไม่ได้ทำให้โมเดล 70B ใช้งานได้จริงบนเครื่องที่มี RAM 4 GB การสั่ง kill จะเกิดขึ้นอย่างเงียบๆ เว้นแต่คุณจะเฝ้าดูเทอร์มินัลอยู่ ดังนั้นบนเครื่องที่คุณเรียกใช้งานจากที่อื่น การแนบ unit OnFailure= เข้ากับ ollama.service ที่ส่งข้อมูลไปยัง ntfy server ที่คุณโฮสต์ไว้เพื่อรับการแจ้งเตือน จะช่วยให้คุณทราบทันทีที่มันหยุดทำงาน แทนที่จะต้องมารอพบปัญหาเมื่อเรียกใช้งานครั้งถัดไป

Ollama ปฏิเสธที่จะโหลดโมเดล คำขอจะล้มเหลวทันทีพร้อมข้อความแสดงข้อผิดพลาดแทนที่จะ crash และ log ของเซิร์ฟเวอร์จะบันทึก model is too large for system memory (Ollama 0.40.7, ตรวจสอบเมื่อวันที่ 21 ตุลาคม 2026) รุ่นเก่าจะแสดง Error: model requires more system memory (X GiB) than is available (Y GiB) ที่บรรทัดคำสั่ง นี่คือเวอร์ชันที่สุภาพกว่าการ crash ด้านบน: Ollama คำนวณแล้วพบว่าไม่สามารถรันได้จึงหยุดทำงานแทนที่จะปล่อยให้ OOM killer เป็นผู้จัดการ ให้เลือกโมเดลที่มีความต้องการต่ำกว่า RAM ที่ว่างอยู่ (ตรวจสอบด้วย free -h) ลดความยาวของ context หรือย้ายไปใช้ VPS ที่ใหญ่ขึ้น ไม่มี flag ใดที่จะทำให้โมเดลยัดลงไปได้หากหน่วยความจำไม่เพียงพอจริงๆ

token แรกใช้เวลานานมาก จากนั้นจึงทำงานได้ปกติ โมเดลที่ยังไม่ได้โหลดจะไม่มีการแสดงผลใดๆ เป็นเวลา 5 ถึง 30 วินาที จากนั้นจะสตรีมข้อความตามปกติ การหยุดชะงักนั้นคือช่วงที่น้ำหนัก (weights) ของโมเดลถูกโหลดจากดิสก์เข้าสู่ RAM เป็นครั้งแรก และที่เก็บข้อมูลที่ช้าจะทำให้ปัญหานี้แย่ลง เมื่อโหลดแล้วโมเดลจะค้างอยู่ในหน่วยความจำตามระยะเวลาของ OLLAMA_KEEP_ALIVE ดังนั้นการเรียกใช้ครั้งที่สองจะตอบสนองทันที หากการโหลดครั้งแรกใช้เวลานานเกิน timeout ในเส้นทางการเรียกใช้งาน คุณจะได้รับข้อผิดพลาดแทนที่จะเป็นการตอบสนองที่ช้า และ การตรวจสอบว่า layer ใดรายงานข้อผิดพลาด context deadline exceeded จะบอกคุณว่า client, proxy หรือตัวการโหลดเองที่หมดความอดทน ให้เพิ่มค่า OLLAMA_KEEP_ALIVE หากการหน่วงเวลานี้สร้างปัญหา และใช้ ollama ps เพื่อดูว่าโมเดลใดถูกโหลดอยู่ในขณะนี้

ทุกอย่างช้าไปหมด ความเร็วอยู่ที่ 10 token ต่อวินาทีหรือน้อยกว่าโดยไม่มีข้อผิดพลาดใดๆ นั่นคือการประมวลผลด้วย CPU ซึ่งทำงานตามปกติของมัน ollama ps จะแสดง 100% CPU ซึ่งหมายความว่าไม่มี GPU นี่ไม่ใช่บั๊ก และไม่มีการตั้งค่าใดที่จะเปลี่ยน CPU ให้เป็น GPU ได้ เพราะข้อจำกัดหลักคือ memory bandwidth อย่างไรก็ตาม มีการตั้งค่าหนึ่งที่ควรทดสอบบน VM: Ollama เลือกจำนวน thread ตามจำนวน physical core ที่ตรวจพบ และ hypervisor อาจรายงานค่านี้ผิดพลาด ในเซสชัน ollama run --verbose ให้ลองใช้ /set parameter num_thread 4 (หรือจำนวน vCPU ของคุณ) แล้วรันคำสั่งเดิมซ้ำ โดยเลือกค่าที่ให้ผลลัพธ์ eval rate ดีที่สุด นอกเหนือจากนั้น ให้ใช้โมเดลที่เล็กลง ยอมรับความเร็วที่ได้ หรือย้ายไปใช้ instance ที่มี GPU และวัดอัตราความเร็วที่แท้จริงด้วย --verbose ก่อนที่จะตัดสินว่ามีอะไรเสีย เมื่อการรอคอยเกิดจากความยาวของคำตอบแทนที่จะเป็นอัตราความเร็ว การจำกัดคำตอบด้วย num_predict จะช่วยป้องกันไม่ให้โมเดลที่ชอบพูดนอกเรื่องใช้เวลาหลายนาทีไปกับ token ที่คุณไม่ได้ต้องการอ่าน

Connection refused จากเครื่องอื่น จากแล็ปท็อปของคุณ curl รุ่นปัจจุบัน (8.23.0, ตรวจสอบเมื่อวันที่ 21 ตุลาคม 2026) จะแสดง curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server และ curl 8.5.0 ที่มากับ Ubuntu 24.04 จะแสดง curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server คำว่า "Connection refused" จะปรากฏขึ้นก็ต่อเมื่อคุณเพิ่ม -v ในบรรทัดที่อ่านว่า connect to <ip> port 11434 from ... failed: Connection refused นี่คือการทำงานตามที่ออกแบบไว้: Ollama ผูกไว้กับ localhost เท่านั้น อย่า "แก้ไข" ด้วยการผูกไว้กับ 0.0.0.0 ซึ่งเป็นความผิดพลาดในการเปิดเผยข้อมูลตามที่กล่าวข้างต้น ให้เข้าถึงโมเดลผ่าน VPN หรือผ่าน proxy ที่มีการตรวจสอบสิทธิ์แทน

คุณเปิดพอร์ต 11434 สู่สาธารณะ หากคุณตั้งค่า OLLAMA_HOST=0.0.0.0, เปิด firewall และตอนนี้พบการดึงโมเดลที่คุณไม่ได้เริ่ม หรือ CPU ทำงานที่ 100% โดย client ที่ไม่รู้จัก แสดงว่าคุณถูกตรวจพบและถูกใช้งานแล้ว นี่คือความผิดพลาดระดับหัวข้อข่าว ไม่ใช่กรณีพิเศษ ให้ผูกกลับไปที่ 127.0.0.1 หรือที่อยู่ VPN, ปิดพอร์ต 11434 ที่ firewall และติดตั้งระบบตรวจสอบสิทธิ์ไว้ด้านหน้า ให้สันนิษฐานว่าทุกสิ่งที่เข้าถึงได้ที่ที่อยู่นั้นในขณะที่เปิดอยู่ ได้ถูกบุคคลภายนอกเรียกใช้งานไปแล้ว

การสำรองข้อมูลและการอัปเกรด

ข้อมูลสถานะที่ต้องกังวลมีน้อยมาก เนื่องจากโมเดลสามารถดาวน์โหลดใหม่ได้ สิ่งที่ควรสำรองข้อมูลจึงมีเพียง volume ข้อมูลของ Open WebUI, บัญชีผู้ใช้, ประวัติการแชท, การตั้งค่า และไฟล์ systemd drop-in ที่คุณสร้างขึ้นเท่านั้น ให้สำรองข้อมูล volume ด้วยคอนเทนเนอร์ชั่วคราว:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

อัปเกรด Ollama โดยการรันสคริปต์ติดตั้งใหม่อีกครั้ง และอัปเกรด Open WebUI ด้วย docker pull ghcr.io/open-webui/open-webui:main ตามด้วยการสร้างคอนเทนเนอร์ขึ้นมาใหม่ ข้อควรระวังเรื่องดิสก์สำหรับเวอร์ชัน 0.40: Ollama 0.40.2 เริ่มทำการอัปเกรดโมเดลที่ดึงมาด้วยเวอร์ชันก่อนหน้าในเบื้องหลังและเก็บสำเนาต้นฉบับไว้เป็นข้อมูลสำรอง ทำให้ใช้พื้นที่ดิสก์เพิ่มขึ้นจนกว่าจะถูกลบออก และในเวอร์ชัน 0.40.3 (11 ตุลาคม 2026) ได้ระงับการอัปเกรดเบื้องหลังดังกล่าวไว้ ตรวจสอบ df -h หลังจากอัปเกรด และอ่านบันทึกประจำรุ่น (release notes) เพื่อดูคำสั่งสำหรับลบข้อมูลสำรองเหล่านั้น อย่าตรึงเวอร์ชัน (pin) ไว้ในระยะยาว เนื่องจากทั้งคุณภาพของโมเดลและรันไทม์มีการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นให้อ่านบันทึกประจำรุ่นและทำการทดสอบประสิทธิภาพ (benchmark) บนเครื่องของคุณเอง แทนที่จะเชื่อตัวเลขจากไตรมาสที่แล้ว

FAQ

ฉันสามารถรัน LLM บน VPS ที่มีเฉพาะ CPU ได้จริงหรือไม่?

ได้ แต่มีข้อจำกัด โมเดลขนาดเล็กที่ผ่านการทำ quantization ในช่วง 3B ถึง 8B สามารถรันบน CPU และใช้งานได้จริงสำหรับการร่างข้อความ สรุปเนื้อหา และการจำแนกประเภท เพียงแต่จะทำงานช้า โดยมีความเร็วอยู่ที่หลักหน่วยถึงหลักสิบต้นๆ ต่อวินาทีบน vCPU แบบแชร์ หากเป็นโมเดลขนาด 13B ขึ้นไปจะทำงานช้ามากจนใช้งานลำบากหรือไม่สามารถโหลดเข้า RAM ได้เลย หากต้องการความเร็วหรือใช้โมเดลขนาดใหญ่ คุณจำเป็นต้องใช้ instance ที่มี GPU

แต่ละโมเดลต้องใช้ RAM เท่าไหร่?

กฎโดยประมาณสำหรับโมเดลแบบ 4-bit (Q4) ซึ่งเป็นที่นิยมที่สุดคือ ใช้ RAM ประมาณ 0.5 GB ต่อ 1 พันล้านพารามิเตอร์สำหรับตัว weight บวกกับ overhead อีกประมาณ 1 GB และเผื่อไว้สำหรับ context อีกเล็กน้อย ดังนั้นโมเดลขนาด 3B จะต้องการ RAM ว่างประมาณ 4 GB, โมเดลขนาด 7-8B ต้องการประมาณ 8 GB และโมเดลขนาด 14B ต้องการประมาณ 16 GB ให้ตรวจสอบพื้นที่ว่างด้วย free -h และเผื่อ RAM ไว้สำหรับระบบปฏิบัติการและบริการอื่นๆ บนเซิร์ฟเวอร์ด้วย

Ollama API มีการยืนยันตัวตนหรือไม่?

ไม่มี Ollama ไม่มีระบบยืนยันตัวตน, API key หรือการจำกัดอัตราการใช้งาน (rate limit) ในตัว ใครก็ตามที่เข้าถึงพอร์ต 11434 ได้จะมีสิทธิ์ควบคุมทั้งหมด การตั้งค่า OLLAMA_ORIGINS ของ Ollama ทำหน้าที่เพียงจำกัดว่า browser origin ใดที่สามารถเรียกใช้งานได้เท่านั้น ไม่ใช่การจำกัดว่าใครสามารถเชื่อมต่อได้ นี่คือเหตุผลว่าทำไมมันจึงผูกกับ 127.0.0.1 เป็นค่าเริ่มต้น และทำไมคุณจึงไม่ควรเปิดพอร์ต 11434 บน 0.0.0.0 สู่สาธารณะโดยเด็ดขาด ให้เข้าถึงผ่าน localhost, ผ่าน VPN ส่วนตัว หรือผ่าน reverse proxy ที่มีการเพิ่มระบบล็อกอินแทน

ฉันจะเพิ่มหน้าเว็บสำหรับแชทได้อย่างไร?

ให้รัน Open WebUI ใน Docker ด้วย --network=host เพื่อให้มันแชร์ loopback ของโฮสต์และเข้าถึง Ollama ที่รันอยู่ภายในได้ที่ http://127.0.0.1:11434 จากนั้นให้ติดตั้ง TLS reverse proxy ไว้หน้าพอร์ต 8080 เพื่อให้คุณเข้าถึงจากแล็ปท็อปได้ ปิดพอร์ต 8080 ที่ firewall ไว้เสมอเพื่อให้ reverse proxy เป็นช่องทางเข้าถึงเดียวจากภายนอก บัญชีผู้ดูแลระบบของ Open WebUI จะทำหน้าที่จัดการการล็อกอิน ซึ่งคุณสามารถตั้งรหัสผ่านได้ในการเปิดใช้งานครั้งแรก

ฉันจะเรียกใช้งานจากแอปพลิเคชันของฉันได้อย่างไร?

ให้ใช้ endpoint ที่รองรับมาตรฐาน OpenAI ที่ http://127.0.0.1:11434/v1 โดยชี้ OpenAI SDK ไปที่ base URL ดังกล่าว ใส่ string อะไรก็ได้ในช่อง API key เนื่องจากระบบจะเพิกเฉยต่อค่านี้ และตั้งค่า model ให้เป็นชื่อโมเดลที่คุณได้ดึงมาใช้งาน โค้ดที่เขียนด้วย OpenAI SDK เดิมมักจะสามารถใช้งานได้ทันทีโดยไม่ต้องแก้ไขอะไร นอกเหนือจากการเปลี่ยน base URL และ key