วิธีติดตั้ง Ollama บน VPS ให้ปลอดภัย

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

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

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

การตรวจสอบขนาดทรัพยากรที่ต้องใช้จริง ด้วยตัวเลขที่ชัดเจน

ขนาดหน่วยความจำ (memory footprint) ของโมเดล จะมีค่าใกล้เคียงกับขนาดไฟล์ บวกกับ overhead ขณะทำงานประมาณ 1 GB และบวกเพิ่มอีกเล็กน้อยสำหรับ context window โมเดลมาตรฐานของ Ollama จะเป็นแบบ 4-bit quantized (ระบุด้วย Q4) ซึ่งใช้ RAM ประมาณ 0.5 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 จะไม่สามารถโหลดโมเดลลงหน่วยความจำได้ หรือจะตอบโต้ช้ามากจนใช้งานไม่ได้จริง

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

สรุปในทางปฏิบัติ: โมเดลขนาดเล็กแบบ quantized ที่รันบน CPU สามารถใช้งานได้จริงสำหรับการร่างข้อความ (drafting), การสรุปความ (summarizing) และการจำแนกประเภท (classification) หากคุณยอมรับความเร็วระดับนี้ได้ แต่หากต้องการโมเดลที่ใหญ่กว่าหรือเร็วกว่านี้ ควรเตรียมงบประมาณสำหรับ GPU instance

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

ติดตั้ง Ollama

มี 2 วิธีที่สะอาดที่สุด การใช้ script อย่างเป็นทางการเป็นวิธีที่ง่ายที่สุดสำหรับ VPS ที่ติดตั้งระบบใหม่:

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

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

systemctl status ollama
ollama --version

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

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

โปรดสังเกต prefix 127.0.0.1: ในการทำ port mapping ซึ่งเป็นการผูก port ไว้กับ localhost เท่านั้น การใช้ -p 11434:11434 จะเป็นการเปิดเผย port บนทุก interface ซึ่งเป็นข้อผิดพลาดที่ส่วนความปลอดภัยได้แจ้งเตือนไว้ เลือกวิธีการติดตั้งเพียงวิธีเดียว ห้ามรันทั้ง script และ container พร้อมกัน เพราะจะทำให้เกิดการแย่งชิง port กันระหว่าง 2 process

Pull and run your first model

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

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

ตรวจสอบข้อมูลโมเดลที่โหลดและพื้นที่ที่ใช้:

ollama ps

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

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

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

ตำแหน่งที่เก็บโมเดล และการคำนวณพื้นที่ดิสก์ที่ต้องใช้

หากติดตั้งผ่าน script และรันในรูปแบบ service โมเดลจะถูกเก็บไว้ใน home directory ของผู้ใช้ ollama:

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

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

รันในรูปแบบ service ที่คุณควบคุมเอง

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

sudo systemctl edit ollama.service

เพิ่มข้อมูลนี้ภายใต้ header [Service] ที่โปรแกรมแก้ไขแสดงขึ้นมา:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE คือระยะเวลาที่ model จะคงอยู่ใน memory หลังจากเสร็จสิ้น request สุดท้าย (ค่าเริ่มต้นคือ 5 minutes) หากคุณใช้งานเครื่องตลอดทั้งวัน ให้เพิ่มค่านี้เพื่อหลีกเลี่ยงการโหลด weights ใหม่ทุกครั้ง หากต้องการคืนค่า RAM ทันทีที่ request สิ้นสุดลง ให้ตั้งค่าเป็น 0 สำหรับเครื่องที่มีทรัพยากรจำกัด systemctl edit จะทำการ reload unit files ให้คุณ ดังนั้นโปรด restart เพื่อเริ่มใช้การเปลี่ยนแปลง:

sudo systemctl restart ollama

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

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

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

ดังนั้น นี่คือข้อผิดพลาดเดียวที่ห้ามทำโดยเด็ดขาด: ห้ามตั้งค่า OLLAMA_HOST=0.0.0.0 และห้ามเปิด port 11434 ใน firewall ของคุณ การทำเช่นนั้นจะเป็นการเผยแพร่ inference server ที่ไม่มีการยืนยันตัวตนออกสู่ internet ทั้งหมด การตั้งค่าใดๆ ก็ตามไม่สามารถทำให้การเปิด 11434 บน 0.0.0.0 ปลอดภัยได้ เพราะ Ollama ไม่มีระบบยืนยันตัวตนให้ตั้งค่า เนื่องจากระบบดังกล่าวไม่มีอยู่จริง

มี 3 วิธีที่ปลอดภัยในการเข้าถึง model จากอุปกรณ์อื่นที่ไม่ใช่เครื่อง server:

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

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

เพิ่ม 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

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

ข้อเสียของการใช้ host networking คือ Open WebUI จะเปิดฟัง (listen) บน port 8080 ของ host ในทุก interface การทำ -p mapping จะถูกยกเลิกและ Docker จะแสดงคำเตือนแจ้งให้ทราบ ดังนั้นควรปิด port 8080 ทั้งที่ firewall ของ host และของผู้ให้บริการ เพื่อให้ TLS reverse proxy เป็นช่องทางเข้าสาธารณะเพียงช่องทางเดียว เมื่อเข้าใช้งานครั้งแรก Open WebUI จะให้คุณสร้างบัญชี admin บัญชีนี้จะทำหน้าที่เป็นชั้นการยืนยันตัวตน (authentication layer) จึงควรตั้งรหัสผ่านที่คาดเดายาก

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

การใช้งาน OpenAI-compatible endpoint จากโค้ดของคุณ

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

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)

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

Failure modes, with the exact strings you will see

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

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

token แรกใช้เวลานานมาก จากนั้นทำงานได้ปกติ เมื่อเริ่มใช้งาน model ครั้งแรก (cold model) จะไม่มีการแสดงผลใดๆ เป็นเวลา 5 ถึง 30 วินาที แล้วจึงเริ่ม stream ข้อมูลตามปกติ ช่วงเวลาที่หยุดไปคือการโหลด weights จาก disk ลงสู่ RAM เป็นครั้งแรก ซึ่ง storage ที่มีความเร็วต่ำจะทำให้เกิดปัญหานี้มากขึ้น เมื่อโหลดเสร็จแล้ว model จะถูกเก็บไว้ในหน่วยความจำตลอดช่วงเวลา OLLAMA_KEEP_ALIVE ทำให้การตอบคำถามครั้งที่สองทำได้ทันที หากระยะเวลานี้ทำให้คุณรู้สึกรำคาญ ให้เพิ่มค่าดังกล่าว และใช้ ollama ps เพื่อตรวจสอบว่ามี model ใดถูกโหลดอยู่หรือไม่

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

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

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

Backups and upgrades

ข้อมูลที่ต้องรักษาไว้มีเพียงเล็กน้อย เนื่องจากสามารถดาวน์โหลด model ใหม่ได้ สิ่งที่ควรสำรองข้อมูลไว้มีเพียง data 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 โดยการรัน install script อีกครั้ง ส่วน Open WebUI ให้ใช้วิธี docker pull ghcr.io/open-webui/open-webui:main แล้วจึงสร้าง container ใหม่ ไม่ควรยึดติดกับเวอร์ชันใดเวอร์ชันหนึ่งในระยะยาว เนื่องจากคุณภาพของ model และ runtime มีการเปลี่ยนแปลงอย่างรวดเร็ว ควรตรวจสอบ release notes และทำการ benchmark บนเครื่องของคุณเองแทนการอ้างอิงตัวเลขจากไตรมาสที่แล้ว

FAQ

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

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

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

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

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

ไม่มี Ollama ไม่มีระบบ authentication, API key หรือ rate limit ในตัว ผู้ที่สามารถเข้าถึง port 11434 ได้จะสามารถควบคุมระบบได้ทั้งหมด นี่คือเหตุผลที่ระบบทำการ bind 127.0.0.1 โดย default และเป็นเหตุผลที่คุณต้องไม่เปิด port 11434 บน 0.0.0.0 ออกสู่ internet โดยตรง ควรเข้าถึงผ่านทาง local, ผ่าน private VPN หรือผ่าน reverse proxy ที่มีการเพิ่มระบบ login

ฉันจะเพิ่ม web chat interface ได้อย่างไร?

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

ฉันจะเรียกใช้งานผ่าน application ของตัวเองได้อย่างไร?

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