วิธีเลือก AI Model สำหรับ Self-host ตามขนาด RAM ที่มี

ปัจจัยที่กำหนดว่าคุณสามารถ self-host โมเดล AI รุ่นใดได้บ้าง

โมเดล AI ที่คุณสามารถ self-host ได้นั้นถูกกำหนดโดยตัวเลขเพียงค่าเดียว คือปริมาณ RAM บนเครื่องของคุณ ตระกูลของโมเดลและเฟรมเวิร์กมีความสำคัญน้อยกว่าการที่น้ำหนัก (weights) ของโมเดลนั้นสามารถโหลดลงในหน่วยความจำโดยเหลือพื้นที่ว่างเพียงพอหรือไม่ บทความนี้จะอธิบายการคำนวณเพื่อหาคำตอบดังกล่าว ส่วนการติดตั้ง runtime นั้นเป็นงานแยกต่างหาก ซึ่งได้อธิบายไว้ใน คู่มือการรัน Ollama บน VPS

ต้นทุนสองส่วนเป็นตัวกำหนดคำตอบ น้ำหนักของโมเดลคือต้นทุนคงที่ ซึ่งถูกกำหนดโดยจำนวนพารามิเตอร์และการทำ quantisation ส่วน context window คือต้นทุนผันแปร และเป็นสิ่งที่ผู้คนมักลืมจนกระทั่งโมเดลที่เคยโหลดได้เมื่อวานกลับโหลดไม่ได้ในวันนี้

การคำนวณขนาด: จำนวนบิตต่อพารามิเตอร์

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

weights in GB = (parameters in billions x bits per weight) / 8

โมเดลที่ปล่อยออกมามักใช้ความละเอียด 16 บิต ซึ่งคิดเป็น 2 GB ต่อ 1 พันล้านพารามิเตอร์ นี่คือเหตุผลว่าทำไมแทบไม่มีใครรันโมเดลที่ความละเอียดต้นฉบับบน VPS ต่อไปนี้คือระดับการทำ Quantisation ที่คุณจะได้พบจริง พร้อมค่าเฉลี่ยจำนวนบิตต่อค่าน้ำหนัก:

• Q8_0 จัดเก็บประมาณ 8.5 บิตต่อค่าน้ำหนัก หรือประมาณ 1.1 GB ต่อ 1 พันล้านพารามิเตอร์
• Q6_K จัดเก็บประมาณ 6.6 บิต หรือประมาณ 0.83 GB ต่อ 1 พันล้านพารามิเตอร์
• Q5_K_M จัดเก็บประมาณ 5.7 บิต หรือประมาณ 0.71 GB ต่อ 1 พันล้านพารามิเตอร์
• Q4_K_M จัดเก็บประมาณ 4.8 บิต หรือประมาณ 0.6 GB ต่อ 1 พันล้านพารามิเตอร์

ให้ใช้ตัวเลข 0.6 GB ต่อ 1 พันล้านพารามิเตอร์เป็นค่ามาตรฐานในการคำนวณ Q4_K_M เป็นค่าเริ่มต้นที่เหมาะสมสำหรับเครื่องที่มีหน่วยความจำจำกัด เพราะการสูญเสียคุณภาพเมื่อเทียบกับ 8 บิตนั้นมีน้อยมากในงานส่วนใหญ่ และไฟล์มีขนาดเล็กลงเกือบครึ่งหนึ่ง หากต่ำกว่า 4 บิต คุณภาพจะลดลงอย่างรวดเร็ว ดังนั้นโมเดลขนาด 70B ที่ถูกบีบอัดเหลือ 2 บิต มักจะให้ผลลัพธ์ที่แย่กว่าโมเดลขนาด 32B ที่ 4 บิตจากรุ่นเดียวกัน หากหน่วยความจำไม่เพียงพอ ให้ลดขนาดโมเดลลงหนึ่งระดับก่อนที่จะลดค่า Quantisation ให้ต่ำกว่า 4 บิต

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

คอลัมน์น้ำหนักด้านบนคือการนำกฎ 0.6 GB ต่อ 1 พันล้านพารามิเตอร์มาประยุกต์ใช้ ไฟล์ GGUF จริงจะมีขนาดใกล้เคียงกับค่านี้โดยคลาดเคลื่อนเพียงไม่กี่เปอร์เซ็นต์ เนื่องจากชั้น embedding และ output จะถูกเก็บไว้ที่ความละเอียดสูงกว่าส่วนอื่น โมเดลขนาด 3B ที่ 4 บิตจะมีขนาดประมาณ 1.8 GB, โมเดล 8B มีขนาด 4.8 GB, โมเดล 32B มีขนาด 19.2 GB และโมเดล 70B มีขนาด 42 GB

เหตุใดความยาวของบริบท (context length) จึงใช้ RAM มากกว่าน้ำหนักของโมเดล

KV cache (key value cache ซึ่งเป็นสถานะ attention ที่โมเดลเก็บไว้สำหรับทุกโทเค็นในการสนทนา) คือต้นทุนส่วนที่สอง โดยจะถูกจัดสรรเมื่อโมเดลโหลดขึ้นมา โดยมีขนาดตามความยาวของบริบทที่คุณกำหนด และจะเพิ่มขึ้นเป็นเส้นตรงตามความยาวนั้น

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

ที่ค่า context เริ่มต้นของ Ollama โมเดลขนาด 8B จะใช้ RAM ไปครึ่งกิกะไบต์สำหรับ cache ที่ 8192 โทเค็นจะใช้ไป 1 GB และที่บริบท 128k ตามที่ระบุใน model card จะใช้ไป 16 GB ซึ่งมากกว่าน้ำหนักของโมเดลถึงสามเท่า ส่วนโมเดลขนาด 70B จะเป็นกรณีตรงกันข้าม คือ cache ที่ 128k จะใช้เพียง 40 GB ซึ่งน้อยกว่าน้ำหนักของตัวโมเดลเอง เนื่องจาก grouped query attention ช่วยป้องกันไม่ให้ต้นทุนต่อโทเค็นเพิ่มขึ้นเร็วเท่ากับจำนวนพารามิเตอร์

ความยาวบริบทเริ่มต้นของ Ollama คือ 4096 โทเค็นบนเซิร์ฟเวอร์ที่ใช้เฉพาะ CPU แต่หากมี GPU ระบบจะเลือกค่าเริ่มต้นจาก VRAM แทน คือ 32k สำหรับ VRAM ระหว่าง 24 ถึง 48 GiB และ 256k สำหรับ 48 GiB ขึ้นไป คุณสามารถเพิ่มค่านี้ได้ด้วยตัวแปร OLLAMA_CONTEXT_LENGTH บนเซิร์ฟเวอร์ จากนั้นตรวจสอบว่าโมเดลที่กำลังทำงานอยู่ได้รับค่าเท่าใดจริงในคอลัมน์ CONTEXT ของ ollama ps การคำนวณหน่วยความจำเบื้องหลังการตั้งค่านี้ได้อธิบายไว้ใน บทความเรื่อง num_ctx และความยาวของบริบท

มีสองวิธีในการลดการใช้หน่วยความจำของ cache วิธีแรกคือการกำหนดความยาวบริบทเท่าที่จำเป็นแทนที่จะใช้ค่าตามที่ model card ระบุ เนื่องจากงานแชทและการเขียนโปรแกรมส่วนใหญ่ใช้พื้นที่เพียง 8k ถึง 32k เท่านั้น หรือวิธีที่สองคือการทำ quantise ตัว cache เองให้เหลือ 8 bits ซึ่งจะช่วยลดขนาดลงครึ่งหนึ่ง แต่อาจส่งผลต่อความแม่นยำในการเรียกคืนข้อมูลจากบริบทที่ยาวมากได้

โมเดลที่ทำงานค้างไว้จะยึดพื้นที่ RAM จนกว่าจะมีคำสั่งให้ยกเลิกการโหลด

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

ollama ps
ollama stop qwen3:4b

ollama ps จะแสดงรายการสิ่งที่ค้างอยู่ในหน่วยความจำ โดยมีคอลัมน์ SIZE แสดงปริมาณหน่วยความจำที่ใช้ และคอลัมน์ UNTIL แสดงเวลาที่จะหมดอายุ หากต้องการตรึงโมเดลไว้ถาวร ให้ตั้งค่า OLLAMA_KEEP_ALIVE=-1 ใน service หากกำหนดค่าเป็น 0 ระบบจะยกเลิกการโหลดโมเดลทันทีที่การตอบกลับแต่ละครั้งเสร็จสิ้น

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

ให้ส่ง prompt หนึ่งรายการ จากนั้นรันคำสั่ง ollama ps อีกครั้งในอีกสิบนาทีถัดมา โมเดลจะยังคงอยู่ในรายการ ซึ่งนั่นคือจุดประสงค์หลัก: โมเดลจะยึดพื้นที่ RAM นั้นไว้ไม่ว่าจะมีใครใช้งานอยู่หรือไม่ก็ตาม โมเดลที่ถูกตรึงไว้ไม่ใช่ความจุส่วนเกิน บน VPS ขนาด 16 GB โมเดลขนาด 8B ที่ context 8k จะใช้พื้นที่ประมาณ 6 GB ตลอดระยะเวลาที่ service ทำงาน ดังนั้นควรคำนวณขนาดของเซิร์ฟเวอร์โดยรวมทั้งโมเดลและแอปพลิเคชันของคุณ ไม่ใช่คำนวณแค่ขนาดของโมเดลเพียงอย่างเดียว การตรึงโมเดลไว้ในหน่วยความจำ ครอบคลุมถึงการแลกเปลี่ยนระหว่างการตรึงโมเดลกับความหน่วงในการเริ่มทำงานแบบ cold start

สิ่งที่รันบน VPS ขนาด 4 GB

ให้สำรองหน่วยความจำประมาณ 1 GB สำหรับระบบปฏิบัติการและเซิร์ฟเวอร์โมเดล ซึ่งจะเหลือพื้นที่ใช้งานจริงประมาณ 3 GB ขนาดนี้เพียงพอสำหรับโมเดลขนาด 1B ถึง 4B ที่ระดับ 4 bits และ context 4096 tokens ตามค่าเริ่มต้น ณ เดือนสิงหาคม 2026 กลุ่มนี้รวมถึง Llama 3.2 ขนาด 3B, Qwen 3 ขนาด 1.7B และ 4B รวมถึงโมเดลขนาดเล็กอย่าง Gemma และ Phi ให้ถือว่าชื่อเหล่านี้เป็นตัวอย่างขนาด ไม่ใช่คำแนะนำในการเลือกใช้ เนื่องจากชื่อโมเดลมีการเปลี่ยนแปลงทุกสองสามเดือน แต่หลักการคำนวณยังคงเดิม

คาดการณ์ความเร็วได้ประมาณ 6 ถึง 14 tokens ต่อวินาที โมเดลขนาดเล็กเหล่านี้ทำงานเฉพาะทางได้ดี เช่น การจำแนกประเภท, การดึงแท็ก, การสรุปความสั้นๆ และการเขียนเรียบเรียงย่อหน้าใหม่ตามรูปแบบที่กำหนด แต่จะมีจุดอ่อนในการใช้เหตุผลหลายขั้นตอนและการเขียนโค้ดที่ครอบคลุมหลายไฟล์ ซึ่งการปรับแต่ง prompt ไม่สามารถแก้ไขข้อจำกัดนี้ได้

รูปแบบความล้มเหลวที่ระดับนี้คือการใช้ swap หากโมเดลมีขนาดใหญ่เกินกว่าหน่วยความจำ Linux จะไม่ปฏิเสธการโหลด แต่จะย้ายข้อมูลหน่วยความจำไปไว้ที่ดิสก์แทน และเนื่องจากการสร้าง token หนึ่งตัวต้องอ่านค่าน้ำหนัก (weight) ทั้งหมดหนึ่งครั้ง ความเร็วในการสร้างข้อความจะตกลงเหลือระดับวินาทีต่อหนึ่ง token ให้เฝ้าสังเกต free -h รวมถึงคอลัมน์ si และ so ของ vmstat 1 ในขณะที่โมเดลกำลังตอบคำถาม หากมีการใช้งาน swap in และ swap out ที่ไม่ใช่ศูนย์ในระหว่างการสร้างข้อความ แสดงว่าโมเดลมีขนาดใหญ่เกินกว่าแผนที่เลือกไว้

สิ่งที่รันบน VPS ขนาด 8 ถึง 16 GB

นี่คือจุดที่โมเดลแบบ self-hosted เริ่มมีประโยชน์อย่างแท้จริง บนหน่วยความจำ 8 GB คุณสามารถรันโมเดลขนาด 7B หรือ 8B ที่ระดับ 4 bits ซึ่งใช้ขนาด weight ประมาณ 4.8 GB พร้อม context ขนาด 8k ส่วนบนขนาด 16 GB คุณสามารถรันโมเดลขนาด 13B หรือ 14B ที่ระดับ 4 bits ซึ่งใช้ขนาดประมาณ 8.4 GB หรือจะเลือกใช้โมเดลขนาด 8B ที่ระดับ 8 bits หากคุณต้องการใช้หน่วยความจำไปกับความละเอียดของโมเดลมากกว่าจำนวนพารามิเตอร์

ความเร็วคือข้อจำกัดสำคัญ โมเดลขนาด 8B ที่รันบน CPU จะสร้างข้อความได้ประมาณ 3 ถึง 7 tokens ต่อวินาที และโมเดลขนาด 14B จะอยู่ที่ประมาณ 1.5 ถึง 3.5 tokens ต่อวินาที โดยปกติมนุษย์อ่านหนังสือด้วยความเร็วประมาณ 5 ถึง 10 tokens ต่อวินาที ดังนั้นการรันโมเดล 8B บน VPS ที่ใช้ CPU จะให้ความรู้สึกเหมือนกำลังดูคนพิมพ์งานช้าๆ ซึ่งถือว่าเพียงพอสำหรับงานเบื้องหลัง (background job) แต่จะน่าเหนื่อยหน่ายสำหรับการแชทโต้ตอบ ผลการทดสอบรัน Qwen 3 ขนาด 8B และขนาดที่ใหญ่กว่าบน VPS แสดงให้เห็นถึงประสิทธิภาพในทางปฏิบัติ

สิ่งที่รันบน VPS ขนาด 32 ถึง 64 GB

โมเดลขนาด 32B ที่ระดับ 4 บิต ใช้หน่วยความจำประมาณ 19.2 GB ดังนั้นจึงสามารถรันบนแผน 32 GB ได้โดยใช้ context ที่สั้น และทำงานได้อย่างราบรื่นบนขนาด 48 GB หรือ 64 GB ส่วนโมเดล 70B ที่ระดับ 4 บิต ใช้หน่วยความจำประมาณ 42 GB จึงจำเป็นต้องมีหน่วยความจำ 64 GB ก่อนที่จะเพิ่มส่วนของ cache เข้าไป

จากนั้นควรประเมินความเร็วตามความเป็นจริง โมเดล 32B ที่ประมวลผลบน CPU ทำความเร็วได้ประมาณ 0.6 ถึง 1.5 tokens ต่อวินาที ส่วนโมเดล 70B ทำได้ประมาณ 0.2 ถึง 0.5 tokens ต่อวินาที คำตอบความยาว 500 tokens จากโมเดล 70B ใช้เวลาประมาณ 20 นาที ด้วยความเร็วดังกล่าว request มักหยุดทำงานก่อนที่โมเดลจะประมวลผลเสร็จ เพราะ client หรือ proxy ที่อยู่หน้า Ollama หมดเวลาเสียก่อน นี่คือสาเหตุของ ข้อผิดพลาด context deadline exceeded เครื่องมือเหล่านี้เหมาะสำหรับการประมวลผลแบบ batch ให้เครื่องมือรับคิวเอกสารแล้วทำงานตลอดคืนได้ โดยความเร็วไม่ใช่ประเด็นสำคัญ แต่หากนำไปใช้หลัง chat window ความเร็วจะมีผลอย่างมาก

การจัดเส้นทางแบบ Mixture of experts (MoE) เปลี่ยนแปลงการคำนวณนี้ และเป็นรายละเอียดทางสถาปัตยกรรมเพียงอย่างเดียวที่ควรศึกษา โมเดลแบบ MoE จะส่งแต่ละโทเค็นผ่านน้ำหนัก (weights) เพียงส่วนเล็กๆ เท่านั้น โมเดลที่มีพารามิเตอร์รวม 30B และมีพารามิเตอร์ที่ทำงานจริง (active) 3B ต่อโทเค็น จะต้องการหน่วยความจำเท่ากับโมเดล 30B ทั่วไป แต่สร้างผลลัพธ์ได้ใกล้เคียงกับความเร็วของโมเดล 3B แบบ dense เพราะแต่ละโทเค็นจะอ่านเฉพาะส่วนที่ทำงานอยู่เท่านั้น บนเครื่องขนาด 32 GB โมเดล MoE ในลักษณะนี้จะใช้งานได้จริงมากกว่าโมเดล 30B แบบ dense มาก กฎที่ควรจำคือ พารามิเตอร์รวมเป็นตัวกำหนดหน่วยความจำที่ต้องใช้ ส่วนพารามิเตอร์ที่ทำงานจริงเป็นตัวกำหนดความเร็ว

การประมวลผล inference บน CPU มีความเร็วเท่าใดในความเป็นจริง?

การสร้าง 1 token จำเป็นต้องอ่าน weight ที่ใช้งานอยู่ทั้งหมดออกจากหน่วยความจำ 1 ครั้ง ไม่มีวิธีใดหลีกเลี่ยงขั้นตอนนี้ได้ ดังนั้นความเร็วในการสร้างบน CPU จึงถูกกำหนดโดยแบนด์วิดท์ของหน่วยความจำ (memory bandwidth) ไม่ใช่จำนวนคอร์ ขีดจำกัดสูงสุดคำนวณได้จากการหาร: แบนด์วิดท์หน่วยความจำที่ใช้งานได้ หารด้วยขนาดของ weight ทั้งหมดในหน่วยไบต์ VPS ขนาดเล็กทั่วไปมักทำความเร็วได้ที่ 10 ถึง 25 GB ต่อวินาทีผ่าน vCPU ดังนั้นโมเดลขนาด 4.8 GB จะทำความเร็วได้สูงสุดประมาณ 2 ถึง 5 tokens ต่อวินาที

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

ตัวเลขเหล่านี้เป็นช่วงความเร็วที่พบได้ทั่วไปบนฮาร์ดแวร์ VPS ปกติ ไม่ใช่ผลการทดสอบจากเครื่องใดเครื่องหนึ่งโดยเฉพาะ ตัวเลขของคุณจะขึ้นอยู่กับรุ่นของหน่วยความจำ, จำนวนช่องสัญญาณ (channel count) บนโฮสต์ และจำนวนเพื่อนบ้านที่แย่งทรัพยากรกันอยู่ คุณสามารถวัดค่าด้วยตนเองโดยใช้ tag ของโมเดลที่คุณมีอยู่แล้ว:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

สรุปผลที่แสดงหลังจากคำตอบเสร็จสิ้นจะลงท้ายด้วยบรรทัดที่ระบุว่า eval rate: ... tokens/s นั่นคือความเร็วในการสร้างคำตอบของคุณ ให้ละเว้นการรันครั้งแรกของเซสชันนั้นไป เพราะค่า load duration ในสรุปผลเดียวกันจะรวมเวลาที่ใช้ในการอ่าน weight จากดิสก์ด้วย เนื้อหาใน การวัดจำนวน tokens ต่อวินาทีอย่างถูกต้อง จะอธิบายวิธีเพื่อให้ได้ตัวเลขที่นำไปเปรียบเทียบกันได้จริง

มีผลลัพธ์ 2 อย่างที่มักทำให้ผู้ใช้ประหลาดใจ อย่างแรกคือการเพิ่ม vCPU จะหยุดช่วยเพิ่มประสิทธิภาพอย่างรวดเร็ว เพราะเมื่อเกิน 8 คอร์โดยประมาณ คอร์ที่เพิ่มเข้ามาจะรอหน่วยความจำมากกว่าที่จะได้คำนวณจริง และอย่างที่สองคือบนแผนบริการแบบ shared คำสั่งเดียวกันอาจให้ตัวเลขที่ต่างกันในแต่ละช่วงเวลา ซึ่งเป็นผลมาจาก CPU steal time จากเพื่อนบ้านที่ใช้งานหนัก ไม่ใช่เพราะคุณตั้งค่าอะไรผิดพลาด

การอ่าน prompt ของคุณเป็นงานที่ต่างจากการสร้างคำตอบ การประมวลผล prompt เป็นงานที่เน้นการคำนวณ (compute bound) ดังนั้นจึงเพิ่มประสิทธิภาพตามจำนวนคอร์ได้จริง และเป็นจุดที่ GPU ทิ้งห่าง CPU มากที่สุด เอกสารขนาดยาวอาจใช้เวลา CPU อ่านนานหลายนาที แต่ GPU ใช้เวลาเพียงไม่กี่วินาที นี่คืออุปสรรคแรกที่คุณจะพบเมื่อ ใช้งาน coding agent กับโมเดลที่คุณโฮสต์เอง เพราะทุกครั้งที่มีการโต้ตอบ ระบบจะต้องส่ง context ของไฟล์และคำจำกัดความของเครื่องมือใหม่ทั้งหมด ก่อนที่จะได้รับ token แรกของคำตอบกลับมา

สิ่งที่เปลี่ยนไปเมื่อเพิ่ม GPU

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

• VRAM ขนาด 8 GB รองรับโมเดล 7B หรือ 8B ที่ระดับ 4 bits พร้อม context สั้นๆ
• VRAM ขนาด 16 GB รองรับโมเดล 14B ที่ระดับ 4 bits พร้อม context ที่ใช้งานได้จริง หรือโมเดล 8B ที่ระดับ 8 bits
• VRAM ขนาด 24 GB รองรับโมเดล 32B ที่ระดับ 4 bits โดยต้องจำกัดความยาว context
• VRAM ขนาด 48 GB ขึ้นไป รองรับโมเดล 70B ที่ระดับ 4 bits โดยมีพื้นที่เหลือสำหรับ cache และการประมวลผลพร้อมกัน

เมื่อโมเดลมีขนาดใหญ่เกินกว่าจะบรรจุได้ Ollama จะแบ่งการทำงาน: บางเลเยอร์จะอยู่บน GPU ส่วนที่เหลือจะอยู่บน CPU โดย ollama ps จะรายงานการแบ่งนี้ในคอลัมน์ PROCESSOR ในรูปแบบเช่น 78%/22% CPU/GPU ให้มองว่านี่เป็นคำเตือนมากกว่าจะเป็นฟีเจอร์ ส่วนที่ทำงานบน CPU จะเป็นตัวกำหนดความเร็ว เพราะทุก token ยังคงต้องรอการประมวลผลจากเลเยอร์เหล่านั้น ดังนั้นโมเดลที่มีเลเยอร์หนึ่งในสี่ส่วนอยู่บน CPU จะมีความเร็วใกล้เคียงกับความเร็วของ CPU มากกว่า GPU หากคุณพบการแบ่งการทำงานโดยไม่ได้ตั้งใจ ให้ลดความยาว context ลงก่อน เพราะโดยปกติแล้ว cache คือสิ่งที่ทำให้หน่วยความจำเต็ม

การประมวลผลพร้อมกัน (Concurrency) เป็นอีกเหตุผลที่ต้องขยายขนาดทรัพยากร แม้ว่าน้ำหนัก (weights) ของโมเดลจะถูกใช้ร่วมกันระหว่างคำขอที่เข้ามาพร้อมกัน แต่ทุกคำขอที่กำลังทำงานต้องการ KV cache ของตัวเอง ดังนั้นผู้ใช้งาน 10 คนที่เรียกใช้โมเดล 8B ที่ context 8k จะต้องใช้ cache เพิ่มขึ้นอีก 10 เท่าของ 1 GB นอกเหนือไปจากตัวน้ำหนักโมเดล การให้บริการผู้ใช้งานพร้อมกันจากโมเดลที่โฮสต์เอง จะอธิบายถึงวิธีการคำนวณขีดจำกัดดังกล่าว

ความคุ้มค่าในการเช่า GPU ก็เป็นเรื่องของการคำนวณเช่นกัน ซึ่งขึ้นอยู่กับจำนวน token ต่อเดือนที่คุณสร้างจริง จุดคุ้มทุนระหว่าง GPU VPS และ API tokens มีตัวเลขเหล่านั้นให้พิจารณา

สิ่งที่คุณไม่สามารถ self-host ได้

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

ประเภทแรกคือโมเดลแบบ closed weights โมเดลเชิงพาณิชย์ระดับแนวหน้าไม่ได้ถูกแจกจ่ายออกมา ดังนั้นจึงไม่มีไฟล์ให้ดาวน์โหลด และไม่ว่าคุณจะปรับเปลี่ยน RAM อย่างไรก็ไม่สามารถช่วยได้ คุณสามารถ self-host ทุกอย่างที่อยู่รอบตัวโมเดลเหล่านั้นได้ ไม่ว่าจะเป็นอินเทอร์เฟซ, เลเยอร์การดึงข้อมูล, ลูปของเอเจนต์ หรือ log แต่ตัวโมเดลเองยังคงเป็น API ระยะไกล ว่าด้วยเรื่องที่คุณสามารถ self-host Claude ได้หรือไม่ ได้อธิบายเรื่องนี้ไว้อย่างละเอียด

ประเภทที่สองคือโมเดลแบบ open weights ที่มีขนาดใหญ่เกินไป โมเดลแบบ open releases ที่ใหญ่ที่สุดใช้การออกแบบแบบ mixture of experts ซึ่งมีพารามิเตอร์รวมกันหลายแสนล้านตัว กฎเดียวกันนี้ยังคงใช้กับโมเดลเหล่านี้: โมเดลที่มีพารามิเตอร์รวม 400B ที่ความละเอียด 4 bits ต้องการพื้นที่ประมาณ 240 GB สำหรับตัว weights เพียงอย่างเดียว ก่อนจะรวม cache นี่คือฮาร์ดแวร์เฉพาะทาง และการเช่าใช้งานรายเดือนมีค่าใช้จ่ายสูงกว่าค่า API tokens ที่คนส่วนใหญ่จ่ายในหนึ่งปีมาก สิ่งที่ต้องใช้ในการ self-host โมเดลระดับ Kimi จะอธิบายถึงความต้องการที่แท้จริง การแบ่งแยกแบบเดียวกันนี้ปรากฏให้เห็นในไลบรารีของ Ollama เอง โดยที่ GLM 5.2 ถูกระบุว่าเป็นโมเดลแบบ cloud เท่านั้น และมีโมเดลรุ่นน้องที่เล็กกว่ามากซึ่งสามารถดาวน์โหลดลงบน VPS ได้จริง

เส้นแบ่งที่ชัดเจนระหว่างสองทางเลือกนี้คือ: ให้เลือก self-host เมื่อปริมาณงานมีความสม่ำเสมอและข้อมูลไม่ควรออกจากเซิร์ฟเวอร์ของคุณ และให้เลือกซื้อ tokens เมื่อปริมาณงานมีความผันผวน หรือเมื่อคุณภาพคำตอบระดับแนวหน้าคือสิ่งที่คุณต้องการจริงๆ

ตรวจสอบทรัพยากรที่คุณมีก่อนตัดสินใจ

free -h
nproc
lscpu | grep 'Model name'

ให้วางแผนโดยอ้างอิงจากคอลัมน์ available ของ free -h ไม่ใช่คอลัมน์ total เนื่องจาก total ได้รวมหน่วยความจำที่ระบบกำลังใช้งานอยู่ไว้แล้ว ให้หักลบหน่วยความจำประมาณ 1 GB สำหรับระบบปฏิบัติการและเซิร์ฟเวอร์โมเดล จากนั้นนำค่าที่เหลือหารด้วย 0.6 เพื่อหาจำนวนพารามิเตอร์สูงสุดในหน่วยพันล้านที่คุณสามารถรองรับได้ที่ระดับ 4 bits ต่อจากนั้นให้หักลบหน่วยความจำสำหรับ KV cache ตามบริบท (context) ที่คุณต้องการใช้งานจริง ผลลัพธ์ที่ได้คือคำตอบของคุณ ซึ่งต่างจากรายการชื่อโมเดลตรงที่ค่านี้จะไม่ล้าสมัย

FAQ

ฉันต้องใช้ RAM เท่าไรในการรันโมเดลขนาด 8B?

ต้องใช้ RAM ประมาณ 4.8 GB สำหรับน้ำหนักโมเดลที่การทำ quantization ระดับ 4 bit บวกกับ KV cache ตามความยาว context ของคุณ และบวกเพิ่มอีกประมาณ 1 GB สำหรับระบบปฏิบัติการและตัว model server หากใช้ context ที่ 8192 token ตัว cache จะเพิ่มขึ้นอีกประมาณ 1 GB ดังนั้นแผนการใช้งานขนาด 8 GB จึงเพียงพอ แต่ขนาด 4 GB จะไม่สามารถใช้งานได้ หากคุณต้องการใช้ context เต็มที่ 128k ตามที่ระบุไว้ใน model card ตัว cache เพียงอย่างเดียวจะใช้พื้นที่ถึง 16 GB ซึ่งคุณจะต้องพิจารณาแผนการใช้งานขนาด 32 GB

ทำไมโมเดลของฉันถึงทำงานช้าทั้งที่ VPS มี vCPU จำนวนมาก?

เพราะการสร้างข้อความ (generation) ถูกจำกัดด้วย memory bandwidth ไม่ใช่จำนวน core ในการสร้างแต่ละ token จำเป็นต้องดึงชุดน้ำหนักทั้งหมดที่ใช้งานอยู่จาก RAM ดังนั้นเมื่อ core จำนวนหนึ่งใช้งาน memory channel จนเต็มแล้ว core ที่เหลือก็จะทำได้เพียงรอ สาเหตุทั่วไปอีกประการหนึ่งคือ swap หาก vmstat 1 แสดงค่า si และ so ที่ไม่ใช่ศูนย์ในขณะที่โมเดลกำลังตอบสนอง แสดงว่าน้ำหนักโมเดลไม่พอดีกับ RAM และส่วนหนึ่งของทุก token กำลังถูกดึงมาจากดิสก์ ซึ่งส่งผลกระทบต่อประสิทธิภาพมากกว่าที่คาดไว้มาก

การใช้ context window ที่ยาวขึ้นจำเป็นต้องใช้หน่วยความจำมากขึ้นจริงหรือ?

จริง และการเพิ่มขึ้นจะเป็นแบบเชิงเส้นตามจำนวน token โมเดลขนาด 8B ทั่วไปจะใช้ KV cache ประมาณ 128 KiB ต่อ token ดังนั้น 8192 token จะใช้พื้นที่ 1 GB และ 131072 token จะใช้พื้นที่ 16 GB ตัว cache จะถูกจองไว้ตั้งแต่ตอนโหลดโมเดล ไม่ใช่ตอนที่บทสนทนายาวขึ้น ดังนั้นการกำหนด context ไว้ที่ 128k จะเป็นการจองหน่วยความจำจำนวนนั้นทันที แม้ว่า prompt ที่คุณส่งจะมีขนาดเพียง 200 token ก็ตาม

ฉันควรเลือกรันโมเดลขนาดใหญ่ที่ 2 bits หรือโมเดลขนาดเล็กที่ 4 bits?

ควรเลือกโมเดลขนาดเล็กที่ 4 bits คุณภาพของโมเดลจะลดลงอย่างช้าๆ จาก 8 bits ลงมาที่ 4 bits แต่จะลดลงอย่างรวดเร็วหากต่ำกว่า 4 bits ดังนั้นโมเดลขนาด 70B ที่ถูกบีบอัดเหลือ 2 bits มักจะให้คำตอบที่แย่กว่าโมเดลขนาด 32B ที่ 4 bits จากตระกูลเดียวกัน การทำ quantization ที่หนักเกินไปจะแสดงผลออกมาในรูปแบบของการพูดซ้ำๆ และการทำตามคำสั่งผิดพลาด แทนที่จะเป็นข้อความแจ้งเตือนข้อผิดพลาด ซึ่งทำให้เข้าใจผิดได้ง่ายว่าเป็นเพราะ prompt ของคุณ ให้ถือว่า 4 bits เป็นเกณฑ์ขั้นต่ำและใช้วิธีปรับเปลี่ยนจำนวน parameter แทน

ฉันสามารถ self-host โมเดลที่มีความสามารถเทียบเท่าโมเดลเชิงพาณิชย์ขนาดใหญ่ได้หรือไม่?

ไม่ได้หากใช้ VPS ทั่วไป โมเดลแบบ open weight ที่ทรงพลังที่สุดมีขนาดหลายแสนล้าน parameter ซึ่งที่ระดับ 4 bits จะต้องใช้ RAM มากกว่า 200 GB ก่อนจะนับรวม KV cache และโมเดลเชิงพาณิชย์ที่ทรงพลังที่สุดนั้นไม่มีการแจกจ่ายให้ใช้งานทั่วไป สิ่งที่ฮาร์ดแวร์ทั่วไปทำได้ดีคือการรันโมเดลขนาด 8B ถึง 32B ที่มีคุณภาพดีสำหรับงานเฉพาะทาง ซึ่งโมเดลขนาดเล็กที่ถูกปรับแต่งมาอย่างดีมักจะให้ผลลัพธ์เทียบเท่ากับโมเดลทั่วไป หากคุณต้องการคุณภาพระดับแนวหน้า ให้เปรียบเทียบราคาค่า API กับราคาฮาร์ดแวร์ก่อนตัดสินใจเลือกอย่างใดอย่างหนึ่ง