ผมใช้ Qwen3.6-35B-A3B-NVFP4 เป็น backend model ตัวเดียว แล้วสร้าง Virtual Models ผ่าน LiteLLM Proxy เป็น 10 profiles ตามลักษณะงาน
ทุก profile ชี้ไปที่โมเดลเดียวกัน แต่ override sampling parameters ต่างกัน — ทำให้โมเดลเดียวกันตอบออกมา "คนละคน" ตาม use case
เรื่องมันเริ่มจากปัญหาที่น่ารำคาญมากตอนเที่ยงคืนครับ API ที่ผมใช้รัน backtest trading bot มัน timeout แบบสุ่ม — บาง call ผ่าน บาง call ไม่ผ่าน แถมพอลองยิง prompt เดิมซ้ำ ก็ได้ output กลับมาทันที ฟังดูขัดแย้งใช่ไหมครับ?
ผมใช้เวลาทั้งคืนไล่หาสาเหตุ จนในที่สุดก็พบว่า ปัญหาไม่ได้อยู่ที่ vLLM ไม่ได้อยู่ที่ DGX Spark และไม่ได้อยู่ที่ model เลย — มันอยู่ที่ LiteLLM proxy layer ที่ผมตั้งใจใช้เป็น "แค่ทางผ่าน" ตั้งแต่ต้น
ผมรัน 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 ได้สะดวก โดยที่ยังคุมทุกอย่างได้