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

ปัจจัยในการตัดสินใจเลือก AI model สำหรับการ self-host

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

ที่ความยาวบริบทเริ่มต้นของ 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 สำหรับ VRAM ตั้งแต่ 48 GiB ขึ้นไป คุณสามารถเพิ่มค่านี้ได้ด้วยตัวแปร OLLAMA_CONTEXT_LENGTH บนเซิร์ฟเวอร์ จากนั้นตรวจสอบว่าโมเดลที่กำลังทำงานอยู่ได้รับค่าเท่าใดในคอลัมน์ CONTEXT ของ ollama ps การคำนวณหน่วยความจำเบื้องหลังการตั้งค่านี้ได้อธิบายไว้ใน บทความเรื่อง num_ctx และความยาวบริบท

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

โมเดลที่ทำงานค้างไว้จะยึดพื้นที่ 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 อีกครั้งในอีก 10 นาทีต่อมา โมเดลจะยังคงอยู่ในรายการ ซึ่งนั่นคือจุดประสงค์หลัก คือการยึดพื้นที่ 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 ซึ่งใช้หน่วยความจำสำหรับ weights ประมาณ 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 จะให้ความรู้สึกเหมือนกำลังดูคนพิมพ์งานช้าๆ ซึ่งถือว่ายอมรับได้สำหรับงานเบื้องหลัง แต่จะน่าเหนื่อยหน่ายสำหรับการแชทโต้ตอบ ผลการทดสอบรัน Qwen 3 ขนาด 8B ขึ้นไปบน VPS แสดงให้เห็นถึงประสิทธิภาพในทางปฏิบัติ

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

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

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

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

ความเร็วในการทำ CPU inference เป็นอย่างไรในความเป็นจริง

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

[
  {
    "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 บนโฮสต์ และจำนวนเพื่อนบ้านที่แย่งทรัพยากรกัน คุณสามารถวัดค่าด้วยตนเองโดยใช้โมเดลที่คุณมีอยู่แล้ว:

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

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

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

การอ่าน prompt ของคุณเป็นงานที่ต่างจากการสร้างคำตอบ การประมวลผล prompt เป็นงานที่เน้นการคำนวณ (compute bound) จึงสามารถขยายประสิทธิภาพตามจำนวน core ได้ และเป็นจุดที่ GPU ทิ้งห่างได้ไกลที่สุด เอกสารขนาดยาวอาจใช้เวลา CPU อ่านนานหลายนาที แต่ GPU ใช้เวลาเพียงไม่กี่วินาที นี่คืออุปสรรคแรกที่คุณจะพบเมื่อ เชื่อมต่อ coding agent เข้ากับโมเดลที่คุณโฮสต์เอง เพราะทุกรอบการสนทนาจะต้องส่งบริบทของไฟล์และคำจำกัดความของเครื่องมือใหม่ทั้งหมด ก่อนที่ 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 ทุกอย่างที่อยู่รอบตัวโมเดลเหล่านั้นได้ ไม่ว่าจะเป็นอินเทอร์เฟซ, เลเยอร์การดึงข้อมูล (retrieval layer), ลูปของเอเจนต์ และ log ต่างๆ แต่ตัวโมเดลเองยังคงเป็น API ระยะไกล ว่าด้วยเรื่องที่คุณสามารถ self-host Claude ได้หรือไม่ ได้อธิบายรายละเอียดในส่วนนี้ไว้อย่างครบถ้วน

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

เส้นแบ่งที่ชัดเจนระหว่างสองประเภทนี้คือ: ให้เลือก 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 สำหรับน้ำหนักโมเดลที่การทำ quantisation ระดับ 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 จำนวนมาก?

เพราะความเร็วในการสร้างข้อความถูกจำกัดด้วย memory bandwidth ไม่ใช่จำนวน core ในการสร้างแต่ละ token ระบบต้องดึงชุดน้ำหนักทั้งหมดที่ใช้งานอยู่จาก RAM ออกมา ดังนั้นเมื่อ core จำนวนหนึ่งใช้งานช่องทางหน่วยความจำจนเต็มแล้ว 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 จากตระกูลเดียวกัน การทำ quantisation ที่หนักเกินไปจะแสดงผลออกมาในรูปแบบของการตอบซ้ำๆ หรือการข้ามคำสั่ง แทนที่จะแสดงข้อความแจ้งเตือนข้อผิดพลาด ซึ่งทำให้เข้าใจผิดได้ง่ายว่าเป็นเพราะ prompt ของคุณ ให้ถือว่า 4 bits เป็นเกณฑ์ขั้นต่ำและใช้วิธีปรับเปลี่ยนจำนวน parameter แทน

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

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