เอาโมเดล 27B ขึ้น GPU เช่าด้วย vLLM
กับดักอยู่ตรงที่ไม่มีใครเขียนไว้

โพสต์ที่แล้วเราเล่าสมการต้นทุนของการเช่า GPU มารันโมเดลเอง จบที่ตัดสินใจเช่า RTX 5090 เครื่องเกรด datacenter ที่ $0.756 ต่อชั่วโมง โพสต์นี้คือภาคลงมือ: เอาโมเดล Qwen ขนาด 27B ขึ้นเครื่องนั้นจริงๆ ด้วย vLLM ตั้งแต่กดเช่าจนถึงยิงคำถามแรกสำเร็จ

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

ช่วงที่ 1ของที่ต้องมีก่อนเริ่ม

เป้าหมายคือรันโมเดล 27B บนการ์ดใบเดียว สมการหน่วยความจำต้องลงตัวก่อน: โมเดล 27B แบบเต็มลง VRAM 32GB ไม่ได้ แต่เวอร์ชันที่ NVIDIA บีบด้วย NVFP4 แล้ว (เราใช้ Qwen3.6-27B-NVFP4 จาก Hugging Face) น้ำหนักเหลือราว 20GB พอวางบน RTX 5090 แล้วยังเหลือที่ให้ KV cache แบบ fp8 กับ context ยาว 32K สบายๆ

เงื่อนไขที่ตามมาจากตัวฟอร์แมต: NVFP4 ต้องการการ์ดตระกูล Blackwell ขึ้นไป (RTX 50xx) กับ CUDA รุ่นใหม่พอ และ vLLM รุ่นที่รองรับ (ตอนที่เราติดตั้ง กลางปี 2026 คือ vLLM 0.8 ขึ้นไป) เวลาเลือกเครื่องเช่าจึงต้องกรองที่รุ่นการ์ดกับรุ่น CUDA ไม่ใช่แค่ราคา ส่วนวิธีคิดเรื่องเลือกเจ้าไหนเกรดไหน อยู่ในโพสต์ที่แล้วทั้งเรื่อง

สรุปเช็คลิสต์ก่อนกดเช่า: การ์ด Blackwell VRAM 32GB ขึ้นไป, CUDA 12.8 ขึ้นไป, ดิสก์พอสำหรับน้ำหนักโมเดลราว 20GB บวก environment, และเครื่องต้องมี volume ถาวร (เดี๋ยวเจอเหตุผลในกับดักที่ 3)

ช่วงที่ 2กับดักที่ 1: เครื่อง "ว่าง" ที่ไม่ว่าง

เครื่องเช่าเรามากับ template สำเร็จรูปสำหรับงาน LLM ตัว template สะดวกจริง แต่วันแรกที่เอาโมเดล 27B ขึ้น vLLM ก็เจอ out of memory (OOM คือ VRAM ไม่พอ) ทันที ทั้งที่เพิ่งเช่าเครื่องมาหมาดๆ

เปิด nvidia-smi ดูถึงเข้าใจ: มีโปรเซสโมเดลตัวเก่าของ template ค้างอยู่ และกิน VRAM ไปแล้ว 28GB จากทั้งหมด 32GB มันคือโมเดลตัวเล็กที่ template ตั้งให้เปิดอัตโนมัติเป็นของแถม เครื่องที่เราคิดว่าว่างจึงไม่เคยว่างจริง โมเดลของเราเลยไม่มีที่ลง

วิธีแก้มีสองครึ่ง ครึ่งแรกคือปิดโปรเซสนั้นทิ้ง ครึ่งหลังสำคัญกว่า: ตามไปลบค่า config ที่สั่งเปิดมันตอนบูต ไม่งั้นรีสตาร์ทเครื่องเมื่อไหร่มันก็ฟื้นกลับมากินการ์ดอีก ของเราค่านั้นอยู่ในไฟล์ environment ของระบบที่ supervisor อ่านตอนเปิดบริการ

บทเรียนที่เอาไปใช้ได้ทุกเครื่องเช่า: คำสั่งแรกบนเครื่องใหม่คือ nvidia-smi เสมอ ยังไม่ต้องติดตั้งอะไรทั้งนั้น ดูก่อนว่า VRAM ว่างจริงไหม มีโปรเซสอะไรนั่งอยู่บ้าง ห้านาทีตรงนี้ประหยัดชั่วโมงของการงมว่าทำไม OOM

ช่วงที่ 3กับดักที่ 2: config อยู่สองที่ และ template มีพี่เลี้ยง

สัญชาตญาณแรกของคนคุ้น Linux คือแก้สคริปต์แล้วรันเอง แต่เครื่อง template ไม่ได้ทำงานแบบนั้น มันมี supervisor เป็นพี่เลี้ยงคอยเปิดและเฝ้าบริการทุกตัว ถ้าเรารัน vLLM เองข้างนอก supervisor ก็จะเปิดของมันซ้อนขึ้นมาอีกตัว แย่งการ์ดกันเอง

ความยักย้ายอยู่ตรงที่ config กระจายอยู่สองที่: ชื่อโมเดลอยู่ในไฟล์ environment ของระบบ ส่วน argument ของ vLLM อยู่อีกไฟล์หนึ่งที่ supervisor อ่าน แก้ที่เดียวแล้วงงว่าทำไมไม่เปลี่ยน คือหลุมที่เราตกไปแล้วรอบหนึ่ง

ทางออกที่ถูกคืออ่านคู่มือของ template ก่อนลงมือ แล้วทำงานผ่านพี่เลี้ยง ไม่ใช่สู้กับมัน เครื่องเรามีไฟล์ guide วางไว้ในเครื่องเลยว่า config ตัวไหนอยู่ไฟล์ไหน พออ่านจบแล้วทุกอย่างตรงไปตรงมา: แก้สองไฟล์ให้ชี้โมเดลใหม่ สั่ง supervisor restart บริการ จบ ไม่มีโปรเซสซ้อน ไม่มีของแปลกตอนบูต

ช่วงที่ 4กับดักที่ 3: ของหายตอน stop เครื่อง

โพสต์ที่แล้วบอกว่าวินัยที่เปลี่ยนบิลได้เป็นเท่าตัวคือปิดเครื่องเมื่อไม่ใช้ แต่ปิดเครื่องเช่ามีรายละเอียด: stop กับ destroy ไม่เหมือนกัน stop คือหยุดจ่ายค่า GPU แต่เก็บดิสก์ persistent ไว้ destroy คือล้างกระดาน และเส้นแบ่งสำคัญคือ ของที่รอด stop มีเฉพาะที่อยู่ใน volume ถาวร (บนเครื่องเราคือ /workspace)

แปลเป็นภาคปฏิบัติ: ทั้ง Python environment และน้ำหนักโมเดล 20GB ต้องลงใต้ /workspace ตั้งแต่คำสั่งแรก ถ้าเผลอติดตั้งไว้ที่ home ปกติ วันแรกทุกอย่างทำงานดี พอ stop เครื่องประหยัดเงินตอนกลางคืน เช้ามาเจอเครื่องเปล่า ต้องโหลดโมเดล 20GB ใหม่ เสียทั้งเวลาและค่าเช่าระหว่างรอ

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

ช่วงที่ 5กับดักที่ 4: ท่อกลับบ้านที่หลุดแล้วต้องต่อเอง

โมเดลรันได้แล้ว แต่มันอยู่บนเครื่องเช่าอีกซีกโลก คำถามถัดมาคือให้ระบบที่บ้านเรียกใช้ยังไงโดยไม่เปิดพอร์ต API สู่อินเทอร์เน็ตเปล่าๆ คำตอบที่เราใช้คือ SSH tunnel: พาพอร์ตของ vLLM บนเครื่องเช่า มาโผล่เป็น localhost บนเครื่องฝั่งบ้าน โค้ดฝั่งเรียกใช้เลยเห็นโมเดลเหมือนรันอยู่ในบ้านตัวเอง (วิธีคิดเรื่องท่อแบบนี้เราเขียนละเอียดไว้แล้วในโพสต์เรื่อง SSH tunnel)

กับดักของท่อคือมันหลุดเงียบๆ เน็ตสะดุดครั้งเดียว ท่อขาด แล้วทุกอย่างที่พึ่งมันก็เงียบตาม สิ่งที่ทำให้เรื่องนี้จบคือมอบท่อให้ systemd ดูแล: เขียนเป็น service ที่สั่ง restart อัตโนมัติเสมอ ท่อขาดกี่โมงมันต่อใหม่เองภายในไม่กี่วินาที ไม่ต้องมีมนุษย์มานั่งเฝ้า

ของแถมจากสนามจริงอีกข้อ: ตอนสั่งงานเครื่องเช่าผ่าน SSH ซ้อน SSH (บ้านเข้าเซิร์ฟเวอร์ เซิร์ฟเวอร์เข้าเครื่องเช่า) การใส่คำสั่งซ้อนใน quote หลายชั้นกลืน output เงียบๆ ได้ คำสั่งเหมือนรันแล้วแต่ไม่มีอะไรตอบกลับ เราเสียหลายรอบกว่าจะเปลี่ยนมาส่งสคริปต์เข้า stdin แทนการซ้อน quote ถ้าเจอ output ว่างจากคำสั่งซ้อน อย่าเดา ให้เปลี่ยนวิธีส่งทันที

ช่วงที่ 6เสร็จจริงคือแบบไหน: verify ก่อนประกาศ

คำว่า "ติดตั้งเสร็จ" มีหลายชั้น และชั้นที่เชื่อได้มีชั้นเดียว: ยิง chat completion จริงผ่านท่อ แล้วได้คำตอบจริงกลับมา โปรเซสขึ้นแล้ว พอร์ตเปิดแล้ว log สวยแล้ว ทั้งหมดนั้นยังไม่นับ เพราะแต่ละอย่างเราเจอมาแล้วว่าเขียวได้ทั้งที่ของจริงยังพัง

1. เช็คโมเดลบนการ์ด nvidia-smi ต้องเห็นโปรเซส vLLM ตัวเดียว กิน VRAM ราวที่คำนวณไว้
2. เช็ค API ที่ปลายเครื่องเช่า ยิง completion สั้นๆ ที่ localhost ของเครื่องเช่าเอง ต้องได้ token กลับมาจริง
3. เช็คผ่านท่อจากฝั่งบ้าน คำถามเดิม ยิงจาก localhost ฝั่งบ้าน ผ่าน tunnel ต้องได้คำตอบเดียวกัน
4. เช็ควงจร stop/start ปิดเครื่อง เปิดใหม่ แล้วไล่สามข้อบนซ้ำ ต้องกลับมาเองครบโดยไม่ต้องลงมืออะไรเพิ่ม

ผ่านครบสี่ข้อถึงเรียกว่าเสร็จ และตัวเลขจากเครื่องจริงหลังผ่านครบ: โมเดล 27B ตอบงานสั้นได้ต่อเนื่อง ค่าเช่าเดินเฉพาะช่วงเปิดใช้ ระบบฝั่งบ้านเห็นมันเป็นแค่ endpoint ที่ localhost ตัวหนึ่ง เหมือนโมเดลอยู่ในบ้าน

ปิดท้ายด้วยหลักข้อเดียวเหมือนเคย: ตัวติดตั้งคือส่วนที่ง่าย ของจริงคือรู้ว่าเครื่องเช่าไม่ใช่เครื่องเปล่า มันมีของเก่า มีพี่เลี้ยง มีกติกาว่าอะไรรอดตอน stop อ่านเครื่องให้ออกก่อน แล้วทุกอย่างที่เหลือจะตรงไปตรงมา