Skip to main content

4 posts tagged with "vllm"

View All Tags

Qwen3.6-35B-A3B บน DGX Spark: เรื่อง sampling ที่ผมตั้งผิดมาตลอด

· 9 min read

ผมตั้งค่า vLLM มาหลายเดือนด้วยสูตรเดียวตลอด — temperature: 0.6, top_p: 0.95, top_k: 20 แล้วก็ปล่อยให้ client ไป override เอาเอง ไม่ว่าจะเป็น trading bot, Hermes agent, code review — ใช้ค่าเดียวกันหมด

จนเมื่อวานนี้ผมเปิด Hugging Face model card ของ Qwen3.6-35B-A3B อ่านเล่น ๆ ในส่วน Sampling Parameters ถึงได้รู้ว่า — Qwen team แนะนำ sampling ตาม mode และ task type ไม่ใช่ตาม benchmark หรือ use case แบบที่ผมเข้าใจ

อ้าว ผมเลยต้องกลับมานั่งคิดใหม่

Qwen3.6-35B-A3B: เลือก parameters ตาม use case

· 6 min read

Context

Qwen3.6-35B-A3B รันอยู่บน DGX Spark (port 8001, vLLM v0.23.0, 128K context)

ที่ผ่านมาใช้ temperature 0.6 ตาม --override-generation-config ของ recipe แต่พออ่าน HF model card ละเอียด ๆ เจอว่า Qwen team เองใช้ค่า ต่างกัน ในแต่ละ benchmark category

เลยรวบรวมมาเป็น note สั้น ๆ เพื่อใช้อ้างอิง

DGX Spark: เมื่อ spec แรงไม่ได้แปลว่า run ได้ทันที

· 25 min read

ตอน DGX Spark มาถึงบ้าน ผมตื่นเต้นมาก — GB10 chip, 128GB unified memory, Blackwell architecture ผมคิดว่า "แค่เสียบปลั๊ก ติดตั้ง vLLM ก็ให้บริการ LLM ได้แรงๆ แล้ว" — แต่ความจริงหาเป็นแบบนั้นไม่

DGX Spark ไม่ใช่เครื่อง plug-and-play มันเป็นเครื่องสำหรับคนที่พร้อมจะเรียนรู้ - เรียนรู้เรื่อง serving engines, โครงสร้างของ model, รูปแบบ quantization และอีกหลายเรื่อง ก่อนที่จะดึงพลังออกมาได้เต็มที่

การเดินทางนี้กินเวลาหลายวัน ผมต้องศึกษา vLLM, llama.cpp, ความแตกต่างระหว่าง MoE กับ Dense, quantization ทุกแบบ (FP4, FP8, BF16, NVFP4) จนในที่สุดก็เข้าใจว่าทำไมคนอื่นถึงบอกว่า "DGX เป็นเครื่องสำหรับนักพัฒนาที่ใช้เฉพาะทาง"

LiteLLM Proxy: วาง Gateway ครอบ LLM ให้ทีมใช้งานแบบมีระบบ

· 13 min read

intro

ผมรัน LLM เองบน homelab มาสักพัก

เริ่มจาก llama.cpp บนเครื่องสเปกต่ำ ถามอะไรก็ตอบได้

แล้วขยับมา vLLM ที่ throughput สูงกว่า รับ request พร้อมกันได้มากกว่า

ทุกอย่างดูดี จนกระทั่งวันหนึ่งเพื่อนร่วมงานถามว่า

"ขอใช้ด้วยได้ไหม?"

ผมก็เลยเปิด port ให้เพื่อนยิง request ตรงเข้ามา

ผ่านไปสักพัก ก็เริ่มเจอปัญหา

ไม่รู้ว่าใครใช้ไปเท่าไหร่ — ไม่มี log ไม่มี metric รู้แค่ GPU ทำงานหนักขึ้น

ไม่มี API key แยกคน — ทุกคนใช้ key เดียวกัน ถ้า key หลุดก็จบเลย

ไม่มี rate limit — มีคนส่ง request ต่อเนื่อง ทำให้คนอื่นรอคิวนาน

ไม่มี cache — คำถามซ้ำๆ ถูกส่งไป LLM ทุกครั้ง เสียทรัพยากรโดยไม่จำเป็น

backend ล่มที ทุกอย่างก็หยุดทำงาน — ไม่มี fallback ไม่มี retry

ถ้าจะเขียนระบบจัดการเองก็ทำได้ แต่ต้องมานั่งทำ auth, logging, rate limit, cache, dashboard...

ไม่ใช่งานที่ผมอยากทำ

แค่อยากให้ทีมใช้ LLM ได้สะดวก โดยที่ยังคุมทุกอย่างได้