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

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

การจะรัน Qwen 3.8 27B บน VPS คุณจำเป็นต้องใช้แท็กโมเดลที่มีอยู่จริงก่อน และ ณ วันที่ 4 สิงหาคม 2026 คลังของ Ollama ยังไม่มีรายการ qwen3.8 อยู่เลย แท็กที่ใกล้เคียงที่สุดที่มีการปล่อยออกมาคือ 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 สำหรับเก็บค่าน้ำหนักเพียงอย่างเดียว ก่อนที่จะเริ่มเก็บ context แม้แต่ token เดียว ซึ่งทำให้แผนการใช้งานขนาด 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 ที่ไม่มีอยู่จริงจะแสดงข้อผิดพลาดที่ชัดเจน ทำให้ตรวจสอบบนเซิร์ฟเวอร์ได้รวดเร็ว อย่างไรก็ตาม tag ที่มีอยู่จริงอาจไม่สามารถรันในเครื่องได้ ซึ่งเป็นจุดที่มักทำให้เกิดปัญหาสำหรับ GLM 5.2 ที่ระบุไว้ในไลบรารีแต่ให้บริการผ่านระบบคลาวด์ของ Ollama เท่านั้น

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 ที่ตรงกับคำแนะนำในคู่มือนี้แล้ว นอกจากนี้ในไลบรารียังมี qwen3.6:27b-q8_0 และ qwen3.6:27b-bf16 สำหรับ weight ชุดเดียวกันที่ความละเอียดสูงกว่า รวมถึงชุด 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 ไม่ได้จัดเก็บทุกเทนเซอร์ด้วยความกว้างตามชื่อเรียก เทนเซอร์ที่สูญเสียคุณภาพมากที่สุดภายใต้การบีบอัดจะถูกเก็บไว้ที่ 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 เพียงอย่างเดียว การเพิ่มขนาดเป็นสองเท่านี้จะทำให้เกิดภาระ memory traffic ต่อโทเค็นเพิ่มขึ้นสองเท่า ส่งผลให้ความเร็วในการประมวลผลโทเค็นต่อวินาทีลดลงประมาณครึ่งหนึ่ง ด้วยเหตุผลนี้ Q4_K_M จึงเป็นค่าเริ่มต้นที่เหมาะสมที่สุด หากคุณต้องการพิจารณาด้านคุณภาพมากกว่าด้านหน่วยความจำ การเปรียบเทียบเชิงลึกระหว่าง Q4, Q8 และ fp16 จะแสดงให้เห็นว่าคุณภาพของผลลัพธ์เริ่มลดลงที่จุดใด

ต้นทุนของ 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 ตัวแปรระดับเซิร์ฟเวอร์นี้ไม่ใช่ปัจจัยเดียว และ การตั้งค่า num_ctx ในแต่ละคำขอ ช่วยให้คุณคงค่าเริ่มต้นที่ประหยัดทรัพยากรไว้สำหรับงานทั่วไป ในขณะที่งานที่ต้องการ context ยาวสามารถใช้ window ที่ใหญ่ขึ้นได้ ให้ค่อยๆ เพิ่มขนาดและตรวจสอบ ollama ps หลังการเปลี่ยนแปลงแต่ละครั้ง

การตั้งค่าสองอย่างสามารถลดขนาด cache ลงได้ครึ่งหนึ่งหรือมากกว่านั้น OLLAMA_KV_CACHE_TYPE=q8_0 จะจัดเก็บ cache ที่ 8 บิตแทนที่จะเป็น 16 บิต ซึ่งลดขนาดสำหรับ 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 ของ CPU เสียอีก

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

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

CPU inference บน VPS ทำงานเร็วแค่ไหน

การสร้างหนึ่ง token จากโมเดลแบบ dense หมายถึงการอ่าน weight ทุกตัวจากหน่วยความจำหนึ่งครั้ง ไม่ใช่แค่บางส่วน แต่เป็นทั้งหมด ดังนั้นขีดจำกัดความเร็วไม่ได้อยู่ที่จำนวน core ของคุณ แต่อยู่ที่ memory bandwidth หารด้วยขนาดของ 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 แบบสองช่องสัญญาณ (two-channel) มีเพดานอยู่ที่ 3 tokens ต่อวินาที ดังนั้นคาดหวังได้ประมาณ 2 ส่วนเครื่องที่ใช้ DDR5-4800 แบบสองช่องสัญญาณมีเพดานอยู่ที่ 4.5 ดังนั้นคาดหวังได้ประมาณ 3

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

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

การประมวลผล prompt มีพฤติกรรมที่ต่างออกไป ช่วง prefill ซึ่งเป็นการประมวลผล input ของคุณก่อนที่ token แรกจะปรากฏนั้น ถูกจำกัดด้วยพลังประมวลผล (compute bound) มากกว่า bandwidth ดังนั้นมันจึงขยายประสิทธิภาพตามจำนวน core ได้ ผลที่เกิดขึ้นจริงคือการหยุดรอที่ยาวนานก่อนที่ output จะเริ่มทำงานในกรณีที่เป็น 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 ที่แตกต่างกัน บนโค้ด inference พื้นฐานชุดเดียวกัน

เมื่อใดที่ควรเช่า 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 token ต่อวินาทีสำหรับน้ำหนักโมเดลเหล่านี้ ในขณะที่การ์ดจอสำหรับศูนย์ข้อมูลรุ่นปัจจุบันทำได้ถึง 197 ซึ่งไม่ใช่ช่องว่างที่คุณจะปิดได้ด้วยการปรับแต่งจำนวน thread การ์ดจอทำงานด้วย memory bandwidth ที่ 1008 GB/s ในขณะที่ VPS ของคุณทำงานได้เพียงหลักสิบ GB/s เท่านั้น

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

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

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

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

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

ให้ตั้งค่า runtime options ใน systemd override แทนการตั้งค่าใน shell ของคุณ เนื่องจากโมเดลทำงานอยู่ภายใน service จึงไม่สามารถมองเห็น environment แบบ interactive ของคุณได้

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 จากดิสก์ใหม่ทุกครั้งที่ร้องขอจะมีต้นทุนสูงกว่าตัวคำขอเอง ค่า timeout สำหรับสถานะว่าง (idle) เริ่มต้นคือห้านาที ซึ่งสั้นพอที่จะทำให้คิวงานที่มีช่วงว่างระหว่างรายการต้องเสียต้นทุนในการโหลดซ้ำแล้วซ้ำเล่า และ ตัวเลือกสำหรับการคงโมเดลไว้ในหน่วยความจำ ครอบคลุมทั้งฟิลด์ keep_alive ต่อคำขอ และการตั้งค่าให้คงอยู่แม้หลังจากรีบูตเครื่อง

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

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 ที่เล็กลง หรือขยับไปใช้แผนการใช้งานที่ใหญ่ขึ้น

กระบวนการทำงานหายไปในระหว่างการตอบ ฝั่งไคลเอนต์ไม่แสดงข้อมูลที่เป็นประโยชน์ และ journalctl -u ollama -n 50 แสดงให้เห็นว่า service กำลังเริ่มทำงานใหม่ ให้รันคำสั่ง 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 กำลังถูกอ่านซ้ำจากดิสก์ ซึ่งหมายความว่าโมเดลเหล่านั้นมีขนาดใหญ่เกินกว่าที่จะใส่ลงในหน่วยความจำได้จริง

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

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

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

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

ในการวัดประสิทธิภาพสิ่งเหล่านี้ คุณต้องมีข้อมูลนำเข้าที่มีโครงสร้างจริง และ API ข้อมูลสาธารณะส่วนใหญ่ต้องการบัญชีผู้ใช้ก่อนที่คุณจะวัดปริมาณงานได้ demo endpoint ของ Strasmore (เราเป็นผู้ดูแล) ตอบกลับ SQL แบบอ่านอย่างเดียวจากข้อมูลตลาดสหรัฐฯ ย้อนหลัง 22 ปี โดยไม่ต้องใช้ key และไม่ต้องลงทะเบียน: การทำ GET ไปยัง https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 จะส่งกลับ JSON ที่คุณสามารถส่งต่อไปยัง prompt loop ได้โดยตรง พร้อมกับ SQL ที่สร้างข้อมูลนั้นขึ้นมา เพื่อให้โมเดลมีเนื้อหาสำหรับสรุปที่คุณสามารถตรวจสอบได้อย่างอิสระ ขีดจำกัดคือ 500 แถวและ 20 วินาทีต่อการเรียก ซึ่งมากกว่าที่เครื่องระดับสองโทเค็นต่อวินาทีจะใช้ได้อย่างสบาย รายการคอลัมน์ทั้งหมดอยู่ที่ https://api.strasmore.com/v1/schema

หากนี่เป็นการติดตั้ง 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

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

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

ในเกือบทุกกรณีควรใช้ Q4_K_M เนื่องจาก Q8_0 มีขนาด 30 GB เทียบกับ 17 GB จึงต้องใช้แผน 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 แบบเปิดตลอดเวลาจะเป็นตัวเลือกที่เหมาะสมกว่า