ลงมือทำ: เปิดเซิร์ฟเวอร์ vLLM บน Hugging Face Jobs ด้วยคำสั่งเดียว — เสิร์ฟโมเดลโอเพนเวตแบบ OpenAI-compatible จ่ายตามนาที

เมื่อ 26 มิถุนายน 2026 Hugging Face เผยแพร่คู่มือ (โดย Quentin Gallouédec) ที่ทำให้การ เปิดเซิร์ฟเวอร์ inference ด้วย vLLM กลายเป็นเรื่องของคำสั่งเดียว — ผ่าน hf jobs run บน HF Jobs โครงสร้างพื้นฐาน GPU แบบจ่ายตามการใช้งานของ Hugging Face เอง สิ่งที่ได้ออกมาคือ endpoint OpenAI-compatible สำหรับโมเดลโอเพนเวตตัวไหนก็ได้บน Hub โดยไม่ต้องจัดเตรียมเครื่อง, ลง CUDA, หรือดูแลเซิร์ฟเวอร์เอง

แนวคิดง่ายมาก: มอง hf jobs run เป็น docker run เวอร์ชันที่รันบนเครื่อง GPU ของ Hugging Face แทนที่จะรันบนเครื่องคุณ คุณบอกแค่ว่าจะใช้ GPU รุ่นไหน, รัน image อะไร, แล้วจะเสิร์ฟโมเดลตัวไหน — ที่เหลือ HF จัดการให้ และคิดเงินเป็นรายนาทีตามฮาร์ดแวร์ที่เลือก

คำสั่งเดียวจบ

ข้อกำหนดเบื้องต้นมีแค่: มีวิธีชำระเงิน (หรือเครดิตเติมล่วงหน้า), อัปเดต huggingface_hub และล็อกอิน

pip install -U "huggingface_hub>=1.20.0"
hf auth login

จากนั้นเปิดเซิร์ฟเวอร์ vLLM ได้ในบรรทัดเดียว:

hf jobs run --flavor a10g-large --expose 8000 --timeout 2h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000

อ่านทีละส่วน:

• --flavor a10g-large — เลือกฮาร์ดแวร์ GPU (A10G ราคาราว $1.50/ชั่วโมง) ดูตัวเลือกและราคาทั้งหมดด้วย hf jobs hardware
• --expose 8000 — ส่งพอร์ตของคอนเทนเนอร์ออกผ่าน public jobs proxy ของ HF เพื่อให้เรียกจากภายนอกได้
• --timeout 2h — ตาข่ายนิรภัย ปิด job อัตโนมัติเมื่อครบเวลา (โมเดลใหญ่ควรตั้งนานขึ้น)
• vllm/vllm-openai:latest — image ทางการของ vLLM
• vllm serve Qwen/Qwen3-4B ... — คำสั่งที่รันในคอนเทนเนอร์ เสิร์ฟโมเดลที่ต้องการ

เมื่อรัน ระบบจะพิมพ์ URL ที่เซิร์ฟเวอร์เข้าถึงได้ พร้อม job ID และพอร์ตที่เปิดไว้

เข้าถึงผ่าน proxy ที่มี gate — ไม่ใช่เปิดโล่ง

endpoint จะอยู่ในรูป https://<job_id>--8000.hf.jobs จุดสำคัญที่ต้องเข้าใจคือมันเป็น gated ไม่ใช่ public: ทุกคำขอต้องแนบ HF token ที่มีสิทธิ์ read ใน namespace ของ job นั้น พูดอีกแบบคือ jobs proxy ทำหน้าที่เป็นด่านยืนยันตัวตนให้ API ของคุณโดยปริยาย เหมาะกับงานส่วนตัว/ทีม หรือการต่อเข้ากับ agent ของตัวเอง

เนื่องจาก endpoint เป็น OpenAI-compatible คุณชี้ SDK ของ OpenAI หรือ client ใด ๆ มาที่ base URL นี้ได้ทันที โดยไม่ต้องแก้โค้ดฝั่งแอป

ดีบักด้วย SSH และสเกลขึ้นโมเดลใหญ่

ถ้าต้องไล่ปัญหาในคอนเทนเนอร์ เปิด job ด้วยแฟลก --ssh แล้วเชื่อมต่อด้วย:

hf jobs ssh <job_id>

(ต้องลงทะเบียน SSH key ไว้ที่ huggingface.co/settings/keys ก่อน)

สำหรับโมเดลใหญ่ เช่น Qwen3.5 ระดับ 122B ใช้ tensor parallelism กระจายข้ามหลาย GPU ให้ตรงกับจำนวนการ์ดของ flavor (เช่น h200x2, h200x8) พร้อมแฟลกจัดการหน่วยความจำ:

hf jobs run --flavor h200x2 --expose 8000 --timeout 4h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3.5-122B \
  --tensor-parallel-size 2 \
  --max-model-len 32768 --max-num-seqs 256 \
  --host 0.0.0.0 --port 8000

และถ้าจะต่อเข้ากับ agent harness แบบ provider-agnostic อย่าง Pi ก็เพิ่ม --enable-auto-tool-choice กับ --tool-call-parser hermes เพื่อเปิด tool calling

ข้อจำกัดที่ควรรู้: การเข้าถึงผูกกับ namespace ของเจ้าของ job (proxy คือด่าน API) — เหมาะกับงานพัฒนา ทดสอบ และ batch ที่ใช้แล้วทิ้ง แต่สำหรับ production หรือต้องเปิดสาธารณะจริงจัง HF แนะนำให้ใช้ gateway ที่เหมาะสมหรือ Inference Endpoints แทน

มุมมอง AI Curator

เสน่ห์ของฟีเจอร์นี้ไม่ใช่เทคโนโลยีใหม่ — vLLM กับ HF Jobs มีอยู่แล้ว — แต่คือการ ลดแรงเสียดทาน ลงจนเกือบเป็นศูนย์ ช่องว่างที่เจ็บที่สุดเวลาทดลองโมเดลโอเพนเวต คือระยะจาก “อยากลองรันโมเดลตัวนี้” ไปถึง “มี endpoint ให้ยิง” ซึ่งปกติต้องเช่า GPU, ตั้งไดรเวอร์, จัดการ networking เอง การยุบทั้งหมดเหลือคำสั่งเดียวที่จ่ายตามนาที ทำให้การ “ลองของจริง” ถูกและเร็วพอจะทำเป็นกิจวัตร — ปั่นขึ้นมาเบนช์มาร์ก แล้วปิดทิ้งภายในไม่กี่นาที

สำหรับนักพัฒนาและทีมเล็กในไทย/อาเซียน นี่คือทางสายกลางที่น่าสนใจระหว่างสองขั้ว: ฝั่งหนึ่งคือ API แบบปิดที่จ่ายต่อ token และส่งข้อมูลออกนอกบ้าน อีกฝั่งคือการตั้ง GPU เองที่ลงทุนสูงและดูแลยาก โมเดลแบบ “เช่า GPU เป็นนาที + เสิร์ฟโมเดลโอเพนเวตที่เราเลือกเอง” ให้ทั้งความยืดหยุ่นเรื่องโมเดล (เลือกตัวที่เหมาะกับภาษาไทยหรือโดเมนงาน) และคุมต้นทุนได้ตามจริง โดยเฉพาะงาน batch/ออฟไลน์ที่ไม่ต้องการ uptime 24 ชั่วโมง

ข้อควรระวังมีสองข้อ: หนึ่ง — อย่าลืม teardown งานที่ลืมปิดคือค่าใช้จ่ายเงียบ ๆ ต่อนาที ตั้ง --timeout ให้สมเหตุผลเสมอ สอง — proxy ที่เป็น gate ด้วย token เหมาะกับ dev/ทดสอบ ไม่ใช่ระบบ production ที่มีผู้ใช้จริง อย่าหลงเอา endpoint ชั่วคราวไปแปะหน้าแอปจริงโดยไม่มี gateway ที่ออกแบบมาเพื่อการนั้น เข้าใจเส้นแบ่งนี้แล้ว hf jobs run จะเป็นเครื่องมือที่ดีมากสำหรับขั้น “ลองและวัดผล” ของวงจรพัฒนา

แหล่งข่าว

• Run a vLLM Server on HF Jobs in One Command — Hugging Face Blog (26 มิ.ย. 2026)
• vLLM on Hugging Face Inference docs
• vLLM project