วิธีติดตั้ง 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 เป็นแบบ 4-bit quantized (ระบุว่า Q4) ซึ่งใช้ RAM ประมาณครึ่ง GB ต่อพารามิเตอร์ 1 พันล้านตัว ดังนั้นการคำนวณจึงเป็นเรื่องง่ายและเป็นตัวตัดสินทุกอย่าง

โมเดลขนาด 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 ที่จำกัด ให้คาดหวังความเร็วระดับหลักหน่วยถึงหลักสิบต้นๆ ต่อวินาที (tokens per second): โมเดล 7-8B Q4 อาจทำความเร็วได้ 4 ถึง 10 tokens ต่อวินาที ส่วนโมเดล 3B อาจทำได้ 10 ถึง 25 tokens ต่อวินาที ส่วน GPU จะทำงานได้เร็วกว่าประมาณ 10 เท่า ตัวเลขเหล่านี้เป็นเพียงการประมาณการ การกระทำที่ตรงไปตรงมาที่สุดคือการวัดผลบนเครื่องของคุณเอง ซึ่งขั้นตอนการรันด้านล่างจะแสดงวิธีทำ จงเชื่อมั่นใน eval rate ของคุณเอง ไม่ใช่ตัวเลขในบทความใดๆ รวมถึงบทความนี้ด้วย

ข้อสรุปในทางปฏิบัติ: โมเดลขนาดเล็กที่ผ่านการทำ quantization บน CPU มีประโยชน์อย่างแท้จริงสำหรับการร่างข้อความ สรุปเนื้อหา และการจำแนกประเภท หากคุณยอมรับความเร็วระดับนี้ได้ สำหรับงานที่ใหญ่กว่าหรือต้องการความเร็วที่สูงกว่า ให้จัดสรรงบประมาณสำหรับ instance ที่มี GPU

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

การติดตั้ง 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 ที่เก็บคลังรูปภาพ ให้หักลบพื้นที่ส่วนนั้นออกจากพื้นที่ว่างที่มีอยู่ก่อน แล้วจึงใช้พื้นที่ที่เหลือเป็นงบประมาณสำหรับจัดเก็บโมเดลของคุณจริงๆ

เรียกใช้งานในรูปแบบ service ที่คุณควบคุมได้

สคริปต์ติดตั้งได้ลงทะเบียน 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 ทันทีที่คำขอเสร็จสิ้น systemctl edit จะทำการโหลดไฟล์ unit ใหม่ให้คุณโดยอัตโนมัติ จากนั้นให้รีสตาร์ทบริการเพื่อนำการตั้งค่าไปใช้:

sudo systemctl restart ollama

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

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

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

ดังนั้น นี่คือข้อผิดพลาดข้อเดียวที่ห้ามทำโดยเด็ดขาด: อย่าตั้งค่า OLLAMA_HOST=0.0.0.0 แล้วเปิดพอร์ต 11434 ใน firewall การทำเช่นนั้นจะเผยแพร่ inference server ที่ไม่มีการยืนยันตัวตนไปยัง Internet ทั้งหมด ไม่มีการตั้งค่าใดที่ทำให้การเปิด 11434 บน 0.0.0.0 โดยตรงปลอดภัยได้ เพราะ Ollama ไม่มีส่วนสำหรับตั้งค่าการยืนยันตัวตน และไม่มีระบบดังกล่าวอยู่เลย นี่เป็นกฎสำหรับบริการนี้โดยเฉพาะ ไม่ได้หมายความว่าห้ามเปิดพอร์ตทุกกรณี: รีเลย์ RustDesk ที่ self-host สำหรับ remote desktop จำเป็นต้องรับ network traffic จากภายนอกเพื่อทำงาน และมีเหตุผลรองรับการเปิดดังกล่าว เพราะมีการยืนยันตัวตนด้วย cryptographic key ของตัวเองและใช้รายการพอร์ตสั้น ๆ ที่มีเอกสารระบุไว้อย่างชัดเจน ซึ่งเป็นสิ่งที่ Ollama ไม่มีเลย

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

• เก็บไว้ในเครื่อง: หากผู้เรียกใช้งานเป็นโปรแกรมอื่นที่อยู่บน 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 คือสิ่งเดียวกับที่ 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 ไปยัง Docker bridge gateway และบริการที่ผูกไว้กับ 127.0.0.1 บนโฮสต์จะไม่สามารถเข้าถึงได้ผ่าน bridge ส่งผลให้ Open WebUI ค้างและแจ้งเตือนว่าไม่สามารถเชื่อมต่อกับ Ollama ได้

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

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

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

Ollama รองรับ API ชุดย่อยของ OpenAI ที่ /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) มาไว้แล้ว หากระบุชื่อที่ไม่รู้จักจะได้รับข้อผิดพลาด model "x" not found, try pulling it first การเรียกใช้งานผ่าน 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" ระหว่างการสร้างผลลัพธ์ คุณเริ่มต้นโมเดลขนาดใหญ่ แล้ว terminal แสดง Killed หรือ log ของเซิร์ฟเวอร์แสดง llama runner process has terminated: signal: killed Linux OOM killer หยุดกระบวนการ เพราะโมเดลต้องใช้ RAM มากกว่าที่เครื่องมี ยืนยันสาเหตุด้วย sudo dmesg | grep -i oom ซึ่งจะแสดงบรรทัดลักษณะเดียวกับ Out of memory: Killed process ... (ollama) วิธีแก้คือใช้โมเดลที่เล็กลงหรือ quantize มากขึ้น ใช้ llama3.2:3b แทน 13B หรือเพิ่ม swap เพื่อให้การโหลดที่ใช้ RAM เกิน physical RAM เพียงเล็กน้อยยังทำงานต่อได้ช้า แทนที่จะหยุดทำงาน swap เปลี่ยนการ crash ทันทีให้เป็นการตอบสนองที่ช้าลง แต่ไม่ได้ทำให้โมเดล 70B ใช้งานได้จริงบนเครื่องที่มี 4 GB การ kill จะไม่แสดงข้อความ เว้นแต่คุณกำลังดู terminal อยู่ ดังนั้นบนเครื่องที่คุณ query จากที่อื่น การผูก unit ของ OnFailure= เข้ากับ ollama.service เพื่อโพสต์ไปยัง เซิร์ฟเวอร์ ntfy ที่คุณโฮสต์ไว้สำหรับการแจ้งเตือนแบบ push จะทำให้คุณทราบทันทีเมื่อกระบวนการหยุดทำงาน แทนที่จะต้องมาพบในคำขอครั้งถัดไป

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

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

ทุกอย่างทำงานช้าผิดปกติ ความเร็วอยู่ที่ 10 tokens ต่อวินาทีหรือน้อยกว่าโดยไม่มีข้อความแจ้งเตือนข้อผิดพลาด นี่คือการประมวลผลด้วย CPU ตามปกติ ollama ps จะแสดง 100% CPU ซึ่งหมายความว่าไม่มี GPU ใช้งานอยู่ นี่ไม่ใช่บั๊กและไม่มีการตั้งค่าใดที่จะแก้ไขได้ เนื่องจากข้อจำกัดอยู่ที่ memory bandwidth ไม่ใช่การตั้งค่าที่ผิดพลาด ให้ใช้โมเดลที่เล็กลง ยอมรับความเร็วที่ได้ หรือย้ายไปใช้ instance ที่มี GPU และวัดอัตราความเร็วที่แท้จริงด้วย --verbose ก่อนที่จะสรุปว่าระบบมีปัญหา

Connection refused จากเครื่องอื่น จากแล็ปท็อปของคุณได้รับข้อความ curl: (7) Failed to connect to <ip> port 11434: Connection refused นี่คือการทำงานตามการออกแบบ: Ollama ผูกการเชื่อมต่อไว้ที่ localhost เท่านั้น อย่า "แก้ไข" ด้วยการผูกไว้ที่ 0.0.0.0 เพราะนั่นคือความผิดพลาดในการเปิดเผยบริการสู่สาธารณะตามที่กล่าวไว้ข้างต้น ให้เข้าถึงโมเดลผ่าน VPN หรือผ่าน proxy ที่มีการยืนยันตัวตนแทน

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

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

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

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 ตามด้วยการสร้าง container ขึ้นมาใหม่ อย่าตรึงเวอร์ชันไว้นานเกินไป เนื่องจากทั้งคุณภาพของโมเดลและ runtime มีการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นควรอ่าน release notes และทดสอบประสิทธิภาพบนเครื่องของคุณเอง แทนที่จะเชื่อตัวเลขจากไตรมาสที่ผ่านมา

FAQ

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

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

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

หลักการคร่าวๆ สำหรับโมเดลที่ทำ 4-bit quantization ตามค่าเริ่มต้นคือ ต้องใช้ RAM ประมาณ 0.5 GB ต่อ 1 พันล้านพารามิเตอร์สำหรับค่าน้ำหนัก (weights) บวกกับ 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 ได้จะมีสิทธิ์ควบคุมทั้งหมด นี่คือเหตุผลว่าทำไมมันจึงผูกกับ 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 ที่ไฟร์วอลล์ไว้เสมอเพื่อให้ proxy เป็นประตูสาธารณะเพียงทางเดียว บัญชีผู้ดูแลระบบของ Open WebUI จะทำหน้าที่จัดการการล็อกอิน ซึ่งคุณสามารถตั้งรหัสผ่านได้ในการเปิดใช้งานครั้งแรก

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

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