วิธีรัน Qwen 27B บน VPS ด้วย Ollama พร้อมคำนวณ RAM

คุณสามารถรัน Qwen 3.8 27B บน VPS ที่ไม่มี GPU ได้หรือไม่

ในการรัน Qwen 3.8 27B บน VPS คุณจำเป็นต้องใช้แท็กโมเดลที่มีอยู่จริงก่อน และ ณ วันที่ 4 สิงหาคม 2026 คลังของ Ollama ยังไม่มีรายการ qwen3.8 อยู่เลย แท็ก 27B ที่มีการปล่อยออกมาใกล้เคียงที่สุดคือ qwen3.6:27b: ซึ่งมีพารามิเตอร์ 27.8 พันล้านตัว, การทำ quantisation แบบ Q4_K_M และใช้สัญญาอนุญาต Apache 2.0 คำสั่งและตัวเลขทุกตัวด้านล่างนี้ใช้แท็กดังกล่าวบน Ollama v0.32.5 ซึ่งเผยแพร่เมื่อวันที่ 27 กรกฎาคม 2026

คำตอบสั้นๆ คือทำได้บน VPS ที่มี RAM ขนาด 32 GB ขึ้นไป แต่จะทำงานได้ช้า โมเดลแบบ dense ขนาด 27B ที่ระดับ Q4 ต้องการ RAM ประมาณ 17 GB สำหรับเก็บค่าน้ำหนัก (weights) เพียงอย่างเดียว ก่อนที่จะเริ่มเก็บ token ของ context แม้แต่ตัวเดียว ซึ่งทำให้แผนการใช้งานขนาด 8 GB และ 16 GB ไม่สามารถใช้งานได้เลย บน VPS ที่ใช้ DDR4 แบบสองช่องสัญญาณทั่วไป ความเร็วสูงสุดจะอยู่ที่ประมาณ 3 tokens ต่อวินาที ซึ่งช้ากว่าความเร็วในการอ่านของคนส่วนใหญ่

เลข 3.8 มาจากไหน? มีความเป็นไปได้สูงว่ามาจากจำนวนพารามิเตอร์ หน้าเพจของ Ollama สำหรับ qwen3.6:27b ระบุว่ามีพารามิเตอร์ 27.8B และเลข 27.8 นั้นจำง่ายกว่าในภายหลังว่าคือ 3.8 นอกจากนี้ยังมี qwen3.5:27b ซึ่งเป็น build แบบ Q4_K_M เดียวกันกับรุ่นก่อนหน้า โปรดตรวจสอบรายการล่าสุดก่อนที่คุณจะคัดลอกคำสั่งใดๆ ที่ หน้าแท็ก Ollama qwen3.6 หากมีการปล่อย qwen3.8 จริงออกมาในภายหลัง การคำนวณที่นี่ก็ยังคงใช้ได้ผล เนื่องจากขึ้นอยู่กับจำนวนพารามิเตอร์และจำนวนบิตต่อน้ำหนักมากกว่าที่จะขึ้นอยู่กับหมายเลขเวอร์ชัน

ควรดึง Ollama tag ใด และวิธีการตรวจสอบ

การดึง tag ที่ไม่มีอยู่จริงจะแสดงข้อผิดพลาดที่ชัดเจน ดังนั้นจึงสามารถตรวจสอบบนเครื่องได้ทันที

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show จะแสดงสถาปัตยกรรม, จำนวนพารามิเตอร์, ความยาวของบริบท (context length) และการทำ quantisation สำหรับ tag ที่คุณใช้งานอยู่ หากบรรทัดพารามิเตอร์แสดงค่า 27.8B และบรรทัด quantisation แสดงค่า Q4_K_M แสดงว่าคุณมี build ที่ตรงกับคู่มือฉบับนี้ นอกจากนี้ใน library ยังมี qwen3.6:27b-q8_0 และ qwen3.6:27b-bf16 สำหรับน้ำหนัก (weights) เดียวกันที่ความละเอียดสูงกว่า รวมถึงชุด tag 35b-a3b ซึ่งเป็นโมเดลแบบ MoE (mixture of experts) ที่มีพฤติกรรมการทำงานบน CPU แตกต่างออกไปอย่างมาก รายละเอียดเพิ่มเติมเกี่ยวกับโมเดลเหล่านี้จะกล่าวถึงด้านล่าง

จำนวนพารามิเตอร์คูณด้วยไบต์ต่อค่าน้ำหนัก

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

สูตรคำนวณเป็นบรรทัดเดียว คือ ไบต์ของค่าน้ำหนัก = จำนวนพารามิเตอร์ * จำนวนบิตต่อค่าน้ำหนัก / 8 ที่ระดับ 4 บิตพอดี พารามิเตอร์จำนวน 27.8 พันล้านตัวจะมีขนาด 13.9 GB โดยแท็ก Q4_K_M ที่ปล่อยออกมามีขนาด 17 GB ซึ่งในทางปฏิบัติคิดเป็น 4.89 บิตต่อค่าน้ำหนัก

ช่องว่างดังกล่าวไม่ใช่ข้อผิดพลาด รูปแบบ K-quant ไม่ได้จัดเก็บทุก tensor ไว้ที่ความกว้างตามชื่อเรียก โดย tensor ที่สูญเสียคุณภาพมากที่สุดจากการบีบอัดจะถูกเก็บไว้ที่ 5 หรือ 6 บิต ส่วนชั้น token embedding และชั้น output มักจะถูกคงไว้ที่ Q6_K หรือ Q8_0 ชื่อของรูปแบบจึงเป็นค่าเฉลี่ย ซึ่งค่าเฉลี่ยจะอยู่ที่ประมาณ 4.9 ผลลัพธ์ในลักษณะเดียวกันนี้ยังปรากฏที่ปลายอีกด้านของสเกล คือขนาด 56 GB สำหรับ BF16 คิดเป็น 16.1 บิตต่อค่าน้ำหนัก แทนที่จะเป็น 16 บิตเต็ม เนื่องจากไฟล์ยังประกอบด้วย metadata และตาราง embedding แบบความละเอียดสูง (full-precision)

รูปแบบ Q5_K_M ไม่มีแท็กที่เผยแพร่สำหรับโมเดลนี้ ดังนั้นแถวขนาด 19.8 GB จึงเป็นการคำนวณที่ระดับ 5.7 บิตต่อค่าน้ำหนักตามปกติสำหรับรูปแบบนั้นแทนที่จะเป็นการวัดจริง ส่วน Q8_0 มีขนาดเกือบสองเท่าของ Q4 คือ 30 GB บนเครื่องที่ใช้เฉพาะ CPU การเพิ่มขึ้นเป็นสองเท่านี้ทำให้เกิดภาระการรับส่งข้อมูลในหน่วยความจำต่อ token เพิ่มขึ้นสองเท่า ส่งผลให้ความเร็วในการประมวลผล token ต่อวินาทีลดลงประมาณครึ่งหนึ่ง ด้วยเหตุผลนี้เพียงอย่างเดียว Q4_K_M จึงเป็นค่าเริ่มต้นที่เหมาะสมที่สุดในกรณีนี้

ต้นทุนของ KV cache เมื่อ context เพิ่มขึ้น

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

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

ตัวเลขเหล่านี้อ้างอิงจากโครงสร้างที่ Qwen ใช้ในโมเดลแบบ dense ขนาดนี้ ได้แก่ 64 เลเยอร์, 8 key/value heads ภายใต้ GQA (grouped-query attention) และ head dimension ขนาด 128 ซึ่งคิดเป็น 256 KiB ต่อ token ที่ f16 หรือเท่ากับ 8 GB ที่ 32k tokens และ 32 GB ที่ 128k อย่าเชื่อการคำนวณของผมมากกว่าเครื่องของคุณเอง ให้โหลดโมเดลแล้วอ่านคอลัมน์ SIZE ของ ollama ps ซึ่งจะแสดงผลรวมของน้ำหนัก, cache และ overhead เป็นตัวเลขเดียว

นี่คือเหตุผลที่ context ขนาด 256K บน model card เป็นเพียงหัวข้อโฆษณาไม่ใช่แผนการใช้งานจริง การเติมข้อมูลจนเต็มที่ f16 จะต้องใช้ cache เพิ่มอีก 64 GB นอกเหนือจากน้ำหนักโมเดล บนเครื่องที่ใช้ RAM ไปแล้ว 17 GB สำหรับน้ำหนัก Ollama ไม่ได้กำหนดค่า window เต็มให้คุณโดยค่าเริ่มต้น มันจะโหลดขนาดที่เล็กกว่ามาก และคุณต้องเพิ่มค่าเองอย่างตั้งใจด้วย OLLAMA_CONTEXT_LENGTH ให้ค่อยๆ เพิ่มทีละขั้นและตรวจสอบ ollama ps หลังจากเปลี่ยนค่าทุกครั้ง

การตั้งค่าสองอย่างสามารถลดขนาด cache ลงได้ครึ่งหนึ่งหรือมากกว่านั้น OLLAMA_KV_CACHE_TYPE=q8_0 จะจัดเก็บ cache ที่ 8 bits แทนที่จะเป็น 16 bits ซึ่งลดการใช้หน่วยความจำสำหรับ 32k tokens จาก 8 GB เหลือ 4 GB วิธีนี้จำเป็นต้องใช้ flash attention ดังนั้นต้องตั้งค่า OLLAMA_FLASH_ATTENTION=1 ด้วย และให้ยืนยันการลดลงใน ollama ps แทนที่จะคาดเดาว่ามันทำงานแล้ว OLLAMA_NUM_PARALLEL=1 ก็มีความสำคัญไม่แพ้กัน Ollama สามารถให้บริการหลายคำขอพร้อมกันได้ และแต่ละ slot จะได้รับส่วนแบ่งของ context ดังนั้นการปล่อยให้ parallelism เป็นค่าเริ่มต้นจะทำให้ cache ที่คุณวางแผนไว้ถูกคูณเพิ่มขึ้นโดยไม่รู้ตัว หากมีผู้ใช้งานมากกว่าหนึ่งคนบนเครื่องนี้ การคูณเพิ่มดังกล่าวคือจุดเริ่มต้นของปัญหา และ จำนวนผู้ใช้พร้อมกันที่โมเดลแบบ self-hosted รองรับได้ จะถูกกำหนดโดย cache slots และความลึกของคิว ก่อนที่จะถูกกำหนดโดยจำนวน core เสียอีก

สิ่งที่สามารถรองรับได้ใน RAM ขนาด 8, 16, 32 และ 64 GB

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

ตัวเลขสองชุดนี้แสดงถึงจำนวนโทเค็นของบริบท (context) ในหน่วยพันโทเค็นที่สามารถรองรับได้ควบคู่ไปกับค่าน้ำหนัก (weights) โดยใช้ cache แบบ f16 บน headless Linux VPS ที่เหลือ RAM สำหรับระบบปฏิบัติการประมาณ 1.5 GB และมีส่วนเผื่อสำรองเล็กน้อย หากเป็นศูนย์หมายความว่าตัวค่าน้ำหนักเองก็ไม่สามารถโหลดลง RAM ได้ จึงไม่เหลือพื้นที่สำหรับบริบทใดๆ

ขนาด 8 GB และ 16 GB ไม่ใช่ระดับที่ใกล้เคียงกับการใช้งานจริง ค่าน้ำหนักขนาด 17 GB ไม่สามารถโหลดลงใน RAM ขนาด 16 GB ได้ ไม่ว่าจะปรับการตั้งค่าบริบทอย่างไรก็ตาม การเพิ่ม swap ก็ไม่ช่วยแก้ปัญหานี้ เนื่องจาก Ollama ใช้การทำ memory-map ไฟล์ GGUF ดังนั้นเมื่อหน้าหน่วยความจำ (resident pages) เกินขนาด RAM ที่มี เคอร์เนลจะเริ่มย้ายข้อมูลออกและอ่านกลับเข้ามาใหม่ ส่งผลให้ทุกโทเค็นที่ประมวลผลต้องดึงข้อมูลขนาดหลายกิกะไบต์จากดิสก์ เครื่องจะติดสถานะ iowait สูงและผลิตผลลัพธ์ได้ต่ำกว่าหนึ่งโทเค็นต่อวินาที

ขนาด 32 GB คือจุดเริ่มต้นที่ใช้งานได้จริง ค่าน้ำหนักใช้พื้นที่ 17 GB และคุณจะเหลือ RAM ประมาณ 13 GB ซึ่งครอบคลุมบริบทแบบ f16 ได้ประมาณ 32k โทเค็นโดยมีส่วนเผื่อไว้ให้ ทั้งนี้ค่าน้ำหนักแบบ Q8_0 ที่ขนาด 30 GB ไม่สามารถใช้งานในระดับนี้ได้เลย

ขนาด 64 GB เป็นระดับที่ใช้งานได้อย่างสะดวกสบาย โดย Q4 จะเหลือพื้นที่สำหรับบริบทประมาณ 128k โทเค็น และค่าน้ำหนักแบบ Q8_0 ก็สามารถใช้งานได้โดยเหลือพื้นที่สำหรับบริบทอีกประมาณ 64k โทเค็น ก่อนที่จะตัดสินใจจ่ายเงินเพิ่มเพื่ออัปเกรดเป็น 64 GB เพียงเพื่อให้ใช้ Q8 ได้ ควรพิจารณาให้ชัดเจนว่าคุณกำลังซื้ออะไร: คุณจะได้ผลลัพธ์ที่ดีขึ้นเล็กน้อยแต่แลกมาด้วยความเร็วที่ลดลงครึ่งหนึ่งบนเครื่องที่ทำงานช้าอยู่แล้ว สำหรับคนส่วนใหญ่ การใช้ Q4 พร้อมกับบริบทที่ยาวขึ้นถือเป็นการแลกเปลี่ยนที่คุ้มค่ากว่า

การอนุมานด้วย CPU บน VPS มีความเร็วเท่าใด

การสร้างหนึ่ง token จากโมเดลแบบ dense หมายถึงการอ่าน weight ทุกตัวจากหน่วยความจำหนึ่งครั้ง ไม่ใช่แค่บางส่วน แต่เป็นทั้งหมด ดังนั้นขีดจำกัดความเร็วไม่ได้อยู่ที่จำนวน core แต่เป็นแบนด์วิดท์ของหน่วยความจำหารด้วยขนาดของ weight ที่ระดับ Q4 จะมีการรับส่งข้อมูลในหน่วยความจำถึง 17 GB ต่อหนึ่ง token

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

ตัวเลขเหล่านี้คือเพดานสูงสุด ไม่ใช่ค่าที่วัดได้จริง ผลลัพธ์ที่ได้จริงจะอยู่ที่ประมาณ 50 ถึง 70 เปอร์เซ็นต์ของตัวเลขที่แสดง เนื่องจาก latency ของหน่วยความจำและการ prefetching ที่ไม่สมบูรณ์ทำให้คุณไม่มีทางถึงจุดสูงสุดตามทฤษฎี VPS ที่ใช้ DDR4-3200 แบบสองช่องสัญญาณมีเพดานอยู่ที่ 3 tokens ต่อวินาที ดังนั้นคาดหวังได้ประมาณ 2 ส่วนเครื่องที่ใช้ DDR5-4800 แบบสองช่องสัญญาณมีเพดานอยู่ที่ 4.5 ดังนั้นคาดหวังได้ประมาณ 3

เซิร์ฟเวอร์ขนาดใหญ่มีข้อควรระวัง แพลตฟอร์ม EPYC แบบสิบสองช่องสัญญาณมีแบนด์วิดท์ 460.8 GB/s และมีเพดานที่ 27.1 tokens ต่อวินาที แต่คุณไม่ได้เช่า EPYC ทั้งเครื่อง แบนด์วิดท์หน่วยความจำคือทรัพยากรของโฮสต์ที่แชร์ร่วมกันโดยผู้เช่าทุกคนบนเครื่องนั้น ดังนั้น slice ขนาด 8 vCPU จึงไม่ได้มาพร้อมกับแบนด์วิดท์แบบ exclusive ทั้งสิบสองช่องสัญญาณ คู่มือที่เน้น GPU มักข้ามประเด็นนี้ไป ซึ่งเป็นเหตุผลว่าทำไม VPS สองแผนที่มีจำนวน vCPU เท่ากันเป๊ะ อาจมีความเร็วต่างกันถึง 3 เท่าเมื่อรันโมเดลเดียวกัน

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

การประมวลผล prompt มีพฤติกรรมที่ต่างออกไป ช่วง prefill ซึ่งเป็นการประมวลผล input ก่อนที่ token แรกจะปรากฏ จะถูกจำกัดด้วยพลังประมวลผล (compute bound) ไม่ใช่แบนด์วิดท์ ดังนั้นจึงเพิ่มประสิทธิภาพตามจำนวน core ได้ ผลที่เกิดขึ้นจริงคือการหยุดรอที่ยาวนานก่อนที่ผลลัพธ์จะเริ่มแสดงสำหรับ prompt ขนาดใหญ่ ตามด้วยความเร็วที่คงที่และช้าดังที่กล่าวข้างต้น ให้จับเวลาทั้งสองส่วนแยกกันด้วย --verbose ซึ่งจะแสดง prompt eval rate และ eval rate สำหรับทุกคำขอ

หากโมเดล dense ขนาด 27B ช้าเกินไป ให้พิจารณาแท็ก qwen3.6:35b-a3b ก่อนที่จะเลิกใช้ CPU เพราะแท็กเหล่านี้จะเปิดใช้งานพารามิเตอร์ประมาณ 3 พันล้านตัวต่อ token แทนที่จะเป็นทั้งหมด 27.8 พันล้านตัว ทำให้การรับส่งข้อมูลในหน่วยความจำต่อ token ลดลงเกือบหนึ่งลำดับความสำคัญ แม้ว่าไฟล์บนดิสก์จะมีขนาดใหญ่กว่าก็ตาม คุณกำลังแลกพื้นที่ RAM กับความเร็ว การเลือก runtime ก็มีความสำคัญในจุดนี้เช่นกัน และ Ollama และ llama.cpp มีการควบคุมการปรับแต่ง CPU ที่แตกต่างกัน บนโค้ดการอนุมานพื้นฐานเดียวกัน

เมื่อใดที่ควรเช่า GPU รายชั่วโมงแทน

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

สูตรคำนวณเดียวกันเมื่อนำไปใช้กับค่า memory bandwidth ของ GPU ที่ระบุไว้ จะให้คำตอบในอีกรูปแบบหนึ่ง การ์ดจอสำหรับผู้บริโภคขนาด 24 GB มีขีดจำกัดอยู่ที่ 59 tokens ต่อวินาทีสำหรับน้ำหนักโมเดลเหล่านี้ ในขณะที่การ์ดจอสำหรับศูนย์ข้อมูลรุ่นปัจจุบันทำได้ถึง 197 ซึ่งไม่ใช่ช่องว่างที่คุณจะปิดได้ด้วยการปรับแต่งจำนวน thread การ์ดจอดังกล่าวรันหน่วยความจำที่ความเร็ว 1008 GB/s ในขณะที่ VPS ของคุณรันอยู่ที่ระดับหลักสิบเท่านั้น

ดังนั้น ให้แบ่งเกณฑ์ตามประเภทของภาระงาน (workload) แทนที่จะแบ่งตามความชอบ การทำ inference บน CPU เป็นคำตอบที่ถูกต้องเมื่อเป็นงานแบบ asynchronous และไม่มีใครรอผลลัพธ์อยู่ เช่น การสรุปเนื้อหาจากเอกสารจำนวนมากในตอนกลางคืน หรือการจัดหมวดหมู่ข้อมูลที่รันในขณะที่คุณนอนหลับ ให้เช่า GPU ทันทีที่มีคนรอผลลัพธ์ หรือทันทีที่คำขอเข้ามาเร็วกว่าหนึ่งครั้งต่อ 30 วินาที เพราะเครื่องที่ใช้เฉพาะ CPU ไม่มีพื้นที่เหลือสำหรับการทำ batching และคิวจะยาวขึ้นเรื่อยๆ

การเปรียบเทียบต้นทุนไม่ได้ชัดเจนอย่างที่เห็น VPS ขนาด 64 GB จะคิดค่าบริการทุกชั่วโมงตลอดทั้งเดือนไม่ว่าโมเดลจะถูกโหลดอยู่หรือไม่ ในขณะที่ instance แบบ GPU จะคิดค่าบริการเฉพาะชั่วโมงที่คุณเปิดใช้งานเท่านั้น หากการใช้งานจริงของคุณคือวันละสองชั่วโมง การเช่า GPU อาจทั้งเร็วกว่าและถูกกว่า ให้คำนวณรอบการทำงาน (duty cycle) ของคุณก่อน แล้วจึงค่อยประเมินราคา การเลือก VPS ที่มี GPU ครอบคลุมถึงสิ่งที่ต้องตรวจสอบบนตัว instance เอง และ vLLM เหนือกว่า Ollama เมื่อคุณให้บริการคำขอพร้อมกันบน GPU เพราะมันสามารถจัดการ batching ได้อย่างเหมาะสม

ยังมีทางเลือกที่สามที่คนมักลืมไป คือการเก็บโมเดลขนาด 27B ไว้บน CPU สำหรับงานแบบ batch และใช้โมเดลผ่าน API ที่โฮสต์ไว้สำหรับงานที่ต้องการการโต้ตอบ ไม่มีข้อกำหนดใดที่บังคับว่าต้องใช้โมเดลเดียวเพื่อรองรับทั้งสองงาน

ติดตั้ง Ollama และวัดประสิทธิภาพเครื่องของคุณ

สคริปต์ติดตั้งที่ใช้เป็นสคริปต์อย่างเป็นทางการ ซึ่งจะตั้งค่าบริการ systemd ให้ทำงานในฐานะผู้ใช้ ollama โดยเฉพาะ

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

ollama --version ควรแสดงผลเป็น 0.32.5 หรือใหม่กว่า ตรวจสอบ free -g ก่อนที่คุณจะดึงข้อมูลใดๆ หากคอลัมน์ total ในบรรทัด Mem มีค่าน้อยกว่า 32 ให้หยุดที่ขั้นตอนนี้และเลือกรุ่นโมเดลที่เล็กลง เพราะการดึงข้อมูลขนาด 17 GB ที่คุณไม่สามารถรันได้นั้นจะทำให้เสียเวลาไปหนึ่งชั่วโมงและเสียพื้นที่ดิสก์ไปโดยเปล่าประโยชน์

ให้ตั้งค่ารันไทม์ผ่าน systemd override แทนการตั้งค่าในเชลล์ของคุณ เนื่องจากโมเดลทำงานอยู่ภายในบริการ จึงไม่สามารถมองเห็นสภาพแวดล้อมแบบโต้ตอบ (interactive environment) ของคุณได้

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

ผลลัพธ์จาก --verbose คือค่าการวัดที่คุณต้องการ eval rate คือจำนวนโทเค็นต่อวินาทีของคุณในระหว่างการสร้างข้อความ prompt eval rate คือความเร็วในการประมวลผลช่วง prefill load duration คือระยะเวลาที่ใช้ในการอ่านค่าน้ำหนัก (weights) จากดิสก์ ซึ่งเป็นเหตุผลว่าทำไมจึงต้องตั้งค่า OLLAMA_KEEP_ALIVE=60m ไว้ เพราะหากรันบน CPU การโหลด 17 GB จากดิสก์ใหม่ทุกครั้งที่มีคำขอเข้ามา จะใช้ทรัพยากรมากกว่าตัวคำขอเองเสียอีก

ในขณะที่โมเดลถูกโหลดอยู่ ให้ตรวจสอบการใช้ทรัพยากรจากเทอร์มินัลที่สอง

ollama ps

คอลัมน์ SIZE คือการใช้หน่วยความจำจริงซึ่งรวมถึง KV cache ด้วย โดยค่านี้ควรใกล้เคียงกับค่าน้ำหนักรวมกับแถวสำหรับความยาวบริบท (context length) ของคุณในตาราง KV ที่ 8192 โทเค็นด้วย cache แบบ 8-bit ให้คาดการณ์ว่าจะมีการใช้หน่วยความจำเพิ่มขึ้นประมาณหนึ่งกิกะไบต์นอกเหนือจากค่าน้ำหนัก เมื่อเทียบกับ 2 GB หาก cache ยังคงเป็นแบบ f16 คอลัมน์ PROCESSOR ควรแสดงเป็น 100% CPU หากแสดงเป็นค่าอื่น แสดงว่ามีบางอย่างแย่งการใช้งาน GPU ไป และตัวเลขความเร็วในคู่มือนี้จะไม่ตรงกับประสิทธิภาพของเครื่องคุณ

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

โมเดลไม่ยอมโหลด Ollama จะแสดงบรรทัดที่ระบุตัวเลขทั้งสองค่าในรูปแบบ model requires more system memory (18.6 GiB) than is available (15.2 GiB) นี่เป็นความล้มเหลวในลักษณะที่คาดการณ์ได้ เนื่องจาก Ollama ตรวจสอบก่อนการจัดสรรหน่วยความจำ แทนที่จะปล่อยให้ kernel เป็นผู้จัดการ ให้ลดความยาวของ context, เปลี่ยนไปใช้ tag ที่เล็กลง หรือขยับไปใช้แผนการใช้งานที่ใหญ่ขึ้น

กระบวนการหายไปในระหว่างการตอบ ฝั่ง client จะไม่แสดงข้อมูลที่เป็นประโยชน์ และ journalctl -u ollama -n 50 จะแสดงสถานะว่าบริการกำลังเริ่มทำงานใหม่ ให้รันคำสั่ง dmesg -T | tail หากพบข้อความ Out of memory: Killed process ... (ollama) แสดงว่า kernel OOM killer ได้สั่งยุติกระบวนการดังกล่าว เหตุการณ์นี้เกิดขึ้นเมื่อการตรวจสอบก่อนโหลดผ่าน แต่ cache มีขนาดใหญ่เกินกว่าที่ประเมินไว้ในระหว่างการสนทนาที่ยาวนาน ให้ลดความยาวของ context ลง

การดึงข้อมูล (pull) ล้มเหลวทันที Error: pull model manifest: file does not exist หมายความว่า tag ดังกล่าวไม่มีอยู่ใน library การพิมพ์ qwen3.8:27b จะทำให้เกิดข้อผิดพลาดนี้เช่นเดียวกับการพิมพ์เลขเวอร์ชันผิด ให้ยืนยัน tag ที่หน้า library ก่อนที่จะสรุปว่าเป็นปัญหาที่เครือข่ายของคุณ

ทุกอย่างทำงานได้แต่ช้าจนรับไม่ได้ หากความเร็วต่ำกว่าหนึ่ง token ต่อวินาทีบนเครื่องที่มี RAM เพียงพอ แสดงว่าเป็นปัญหาเรื่อง paging ไม่ใช่เรื่องการประมวลผล ให้รัน vmstat 1 ในขณะที่ระบบกำลังสร้างข้อความ หากคอลัมน์ si หรือ so มีค่าที่ไม่ใช่ศูนย์ แสดงว่า kernel กำลังทำ swapping วิธีแก้ไขคือลด context หรือลดจำนวนโมเดลที่โหลดไว้ หากค่า wa สูงอย่างต่อเนื่องโดยไม่มีกิจกรรม swap แสดงว่า memory-mapped weights กำลังถูกอ่านซ้ำจากดิสก์ ซึ่งหมายความว่าโมเดลเหล่านั้นไม่ได้อยู่ในหน่วยความจำจริง

token แรกใช้เวลา 30 วินาทีก่อนที่ความเร็วจะเพิ่มขึ้น นี่คือขั้นตอน prefill ซึ่งเป็นเรื่องปกติ ระบบจะใช้เวลาประมวลผล system prompt ที่ยาวนานในทุกคำขอที่ไม่ได้อยู่ใน cache ดังนั้นควรทำให้ system prompt สั้นลงก่อนที่จะปรับแต่งส่วนอื่น

สิ่งที่ CPU-only 27B ทำได้ดีจริง

จงตั้งความคาดหวังจากตัวเลขแทนที่จะคาดหวังจากความรู้สึก ด้วยความเร็ว 2 ถึง 4 โทเค็นต่อวินาที คำตอบที่มีความยาว 500 โทเค็นจะใช้เวลาประมวลผลระหว่าง 2 ถึง 4 นาที ซึ่งถือว่าใช้งานไม่ได้สำหรับการแชท แต่เหมาะสมอย่างยิ่งสำหรับงานในคิว (queue) การสรุปเอกสาร, การติดแท็กจำนวนมาก, การดึงข้อมูลจากไฟล์ที่ค้างอยู่ และการตรวจสอบโค้ดแบบไม่ต้องเฝ้าหน้าจอ (unattended code review) ล้วนรองรับความเร็วระดับนี้ได้ เพราะไม่มีใครรอคำตอบอยู่ การช่วยเหลือด้านการเขียนโค้ดนั้นก้ำกึ่ง ดังนั้น การกำหนดให้ coding agent ใช้งานโมเดลที่คุณโฮสต์เอง จึงคุ้มค่าสำหรับงานเบื้องหลัง เช่น การเขียน commit message และการสร้างโครงร่างทดสอบ (test scaffolding) แต่ไม่เหมาะสำหรับคำแนะนำแบบ inline ที่คุณต้องนั่งรอ

ประเด็นเรื่องความเป็นส่วนตัวคือเหตุผลที่แท้จริง โมเดลทำงานบนฮาร์ดแวร์ที่คุณเช่าและควบคุมเอง ไม่มีคำขอใดหลุดออกไปนอกเครื่อง และไม่มีค่าใช้จ่ายต่อโทเค็น ซึ่งมีค่ามากสำหรับข้อมูลที่ถูกควบคุมดูแลแม้จะมีความเร็วเพียง 3 โทเค็นต่อวินาทีก็ตาม จงชั่งน้ำหนักอย่างตรงไปตรงมากับทางเลือกอื่น: การ self-host โมเดลระดับ frontier ต้องใช้ฮาร์ดแวร์มากกว่านี้หลายเท่า และโมเดล 27B บน CPU คือจุดที่ถูกที่สุดบนกราฟนั้นที่ผลลัพธ์ยังคงคุ้มค่าที่จะอ่าน

หากนี่เป็นการติดตั้ง Ollama ครั้งแรกของคุณ คู่มือฉบับเต็มสำหรับการรัน Ollama บน VPS จะครอบคลุมถึงการตั้งค่า service, HTTP API และกฎ firewall ที่คู่มือนี้ถือว่าคุณมีอยู่แล้ว ห้ามเปิดพอร์ต 11434 สู่สาธารณะ Ollama ไม่มีระบบยืนยันตัวตนในตัว ดังนั้นใครก็ตามที่เข้าถึงพอร์ตนี้ได้จะสามารถใช้โมเดลและอ่าน prompt ของคุณได้

FAQ

มีโมเดล Qwen 3.8 27B บน Ollama หรือไม่?

ไม่มี ณ วันที่ 4 สิงหาคม 2026 ไลบรารีของ Ollama ไม่มี namespace qwen3.8 อยู่จริง แท็ก 27B ที่มีอยู่คือ qwen3.5:27b และ qwen3.6:27b ซึ่งทั้งคู่เป็นรุ่น Q4_K_M ของโมเดลแบบ dense ขนาด 27.8 พันล้านพารามิเตอร์ ตัวเลข 3.8 ในคำค้นหานั้นเกือบจะแน่นอนว่าเป็นจำนวนพารามิเตอร์ 27.8B ที่ถูกจำสับสนว่าเป็นเลขเวอร์ชัน ให้ตรวจสอบ https://ollama.com/library/qwen3.6/tags สำหรับรายการปัจจุบัน และใช้คำสั่ง pull qwen3.6:27b หากคุณต้องการรุ่น 27B ที่ปล่อยออกมาล่าสุด แท็กที่ไม่มีอยู่จริงจะส่งผลให้เกิดข้อผิดพลาด Error: pull model manifest: file does not exist

ต้องใช้ RAM เท่าไรในการรันโมเดล Qwen 27B บน VPS?

32 GB คือขั้นต่ำที่ใช้งานได้จริงสำหรับ Q4_K_M โดยน้ำหนักโมเดลมีขนาด 17 GB ระบบปฏิบัติการต้องการประมาณ 1.5 GB และ KV cache จะเพิ่มขึ้นอีกประมาณ 1 GB สำหรับทุกๆ 4000 tokens ของบริบทที่ f16 แผน 16 GB ไม่สามารถโหลดน้ำหนักโมเดลได้เลย และการใช้ swap ก็ไม่ช่วยเนื่องจากไฟล์ถูก memory-mapped และ kernel จะอ่านไฟล์จากดิสก์ใหม่ทุกครั้งที่ประมวลผล token แผน 64 GB จะช่วยให้คุณมีพื้นที่สำหรับบริบทที่ยาวขึ้นหรือใช้ค่าน้ำหนัก Q8_0 ที่ขนาด 30 GB ได้

โมเดล 27B จะให้ความเร็วได้กี่ tokens ต่อวินาทีบน CPU?

ให้นำ memory bandwidth ของคุณหารด้วยขนาดของน้ำหนักโมเดล แล้วคิดเป็น 50 ถึง 70 เปอร์เซ็นต์ของค่าที่ได้ VPS ที่ใช้ DDR4-3200 แบบสองช่องสัญญาณจะมีเพดานความเร็วใกล้เคียงกับ 3 tokens ต่อวินาที และทำความเร็วได้จริงประมาณ 2 tokens ต่อวินาที ส่วนเครื่องที่ใช้ DDR5-4800 แบบสองช่องสัญญาณจะมีเพดานใกล้เคียงกับ 4.5 และทำความเร็วได้ประมาณ 3 tokens ต่อวินาที แพลตฟอร์มเซิร์ฟเวอร์ที่มีช่องสัญญาณหน่วยความจำมากกว่าอาจดูดีกว่าในทางทฤษฎี แต่ memory bandwidth จะถูกแชร์ร่วมกับผู้เช่ารายอื่นบนโฮสต์เดียวกัน ดังนั้นควรวัดค่าด้วยตนเองโดยใช้ ollama run qwen3.6:27b --verbose และอ่านบรรทัด eval rate

ควรใช้ Q4 หรือ Q8 บน VPS ที่ใช้เฉพาะ CPU?

ในเกือบทุกกรณีควรใช้ Q4_K_M โดย Q8_0 มีขนาด 30 GB เทียบกับ 17 GB ของ Q4_K_M ดังนั้น Q8_0 จึงต้องการแผน 64 GB และต้องย้ายข้อมูลในหน่วยความจำเกือบสองเท่าต่อหนึ่ง token ซึ่งจะทำให้ความเร็ว tokens ต่อวินาทีลดลงเหลือประมาณครึ่งหนึ่ง ความแตกต่างของคุณภาพระหว่าง Q4_K_M และ Q8_0 ในโมเดล 27B นั้นมีน้อยมากสำหรับงานส่วนใหญ่ ควรนำ RAM ไปเพิ่มความยาวของบริบท (context) จะดีกว่า เพราะนั่นจะเปลี่ยนความสามารถของโมเดลได้มากกว่าการเปลี่ยนวิธีการเรียบเรียงคำพูด

เมื่อใดที่การเช่า GPU ถึงจะถูกกว่าการใช้ VPS ที่มี RAM ขนาดใหญ่?

เมื่อรอบการทำงานของคุณต่ำหรือมีการรอใช้งานโดยมนุษย์ GPU ที่มีหน่วยความจำ 24 GB จะทำความเร็วได้ประมาณ 59 tokens ต่อวินาทีสำหรับน้ำหนักโมเดลเหล่านี้ เทียบกับ 2 หรือ 3 บน VPS ทั่วไป และคิดค่าบริการเฉพาะชั่วโมงที่ใช้งานจริงเท่านั้น ในขณะที่ VPS ขนาด 64 GB จะคิดค่าบริการตลอดทั้งเดือนไม่ว่าโมเดลจะถูกโหลดอยู่หรือไม่ก็ตาม ให้คำนวณว่าในแต่ละวันคุณสร้าง tokens จริงๆ กี่ชั่วโมง หากใช้งานต่ำกว่าสองหรือสามชั่วโมง การเช่า GPU รายชั่วโมงมักจะคุ้มค่ากว่าทั้งในด้านความเร็วและราคา ส่วนงานประมวลผลแบบ batch ที่มีความสำคัญต่ำและต้องรันต่อเนื่องตลอดเวลาคือจุดที่ VPS แบบเปิดตลอดเวลาจะคุ้มค่ากว่า