ไป AI Party มา: บทเรียน local LLM infrastructure ที่เห็นรันจริง — แยกเครื่องเทรนกับเครื่องเสิร์ฟ

เกริ่น: ไปงาน AI มา แล้วได้เห็นของจริงไม่ใช่แค่สไลด์

ผมไปงาน Chiang Mai AI Party (ธีมปีนี้คือ "AI for Money") — เป็นงาน show & tell ของคนสาย AI. ปกติงานแบบนี้ผมคาดหวังแค่สไลด์สวยๆ แต่รอบนี้มี session เจาะ local LLM infrastructure ที่ไม่ได้พูดลอยๆ — เขาเอา cluster จริงมาเปิด Grafana ให้ดูสดๆ ว่ากำลังเสิร์ฟโมเดลอะไรอยู่. บทความนี้คือสิ่งที่ผมกลั่นออกมาเป็นหลักการที่เอาไปใช้ออกแบบระบบเสิร์ฟโมเดลของตัวเองได้.

บทเรียนที่ 1: แยก "เครื่องเทรน" ออกจาก "เครื่องเสิร์ฟ" (capacity ≠ speed)

ประเด็นที่ผมชอบที่สุดคือเขาไม่ได้ใช้เครื่องเดียวทำทุกอย่าง. เขาใช้ฮาร์ดแวร์สองแบบที่จุดแข็งคนละด้าน แล้วให้ทำหน้าที่ต่างกัน:

• เครื่องหน่วยความจำใหญ่ (unified memory ~128GB) — role: "โรงงานเทรน / คลังโมเดล". เอาไว้ fine-tune และโหลดโมเดลใหญ่มากๆ มาทดลอง. จุดแข็งคือ ความจุ ไม่ใช่ความเร็ว (bandwidth ต่ำกว่า)
• การ์ด VRAM เร็ว (bandwidth ระดับ ~1 TB/s) — role: "เครื่องเสิร์ฟ production". เอาไว้ inference ให้ผู้ใช้จำนวนมากพร้อมกัน. จุดแข็งคือ ความเร็ว/throughput (เสิร์ฟโมเดลขนาดกลางได้ ~150+ tok/s, รับ concurrent request ได้เยอะ)

บทเรียน transferable: capacity กับ speed เป็นคนละแกน. เครื่องที่จุโมเดลใหญ่ได้ ไม่จำเป็นต้องเสิร์ฟเร็ว และเครื่องที่เสิร์ฟเร็วก็อาจจุไม่พอสำหรับเทรน. ออกแบบระบบโดยแยกสองบทบาทนี้ แล้วจับคู่ฮาร์ดแวร์ให้ตรงหน้าที่ — อย่าซื้อเครื่องเดียวหวังให้เก่งทั้งสองอย่าง.

บทเรียนที่ 2: gateway มาตรฐาน OpenAI = สลับโมเดลเบื้องหลังโดย client ไม่ต้องแก้

ชั้นที่ผมว่าฉลาดที่สุดในสถาปัตยกรรมเขาคือ API gateway ตัวกลางที่พูดภาษามาตรฐาน OpenAI (เช่น LiteLLM). ผู้ใช้/แอปทุกตัวยิงเข้า endpoint เดียวด้วยรูปแบบ OpenAI API — แล้ว gateway ค่อย route ไปยังโมเดลจริงเบื้องหลัง (ตัวไหนก็ได้ ค่ายไหนก็ได้).

# client มองเห็นแค่ endpoint เดียว มาตรฐาน OpenAI
POST https://gateway.example.com/v1/chat/completions
{ "model": "our-local-model", "messages": [...] }
# เบื้องหลัง gateway จะสลับไปโมเดล/เครื่องไหนก็ได้ — client ไม่รู้ ไม่ต้องแก้

ผลลัพธ์คือคำเดียว: ZERO CHANGE ฝั่ง client. อยากเปลี่ยนจากโมเดล A เป็น B, ย้ายจาก cloud มา local, หรือ A/B test สองโมเดล — แก้ที่ gateway ที่เดียว โค้ดที่เรียกใช้ไม่ต้องแตะเลย. นี่คือหลัก "เขียนโปรแกรมกับ interface ไม่ใช่ implementation" ที่เอามาใช้กับ LLM — ทำให้ทั้งระบบไม่ผูกติดกับโมเดลตัวใดตัวหนึ่ง (ไม่ vendor lock-in).

บทเรียนที่ 3: โมเดลเฉพาะทางรัน production จริง ไม่ใช่แค่ทฤษฎี

ตรงที่ทำให้ผมเชื่อว่านี่ของจริงคือจอ Grafana ที่เปิดมอนิเตอร์ cluster สดๆ ในงาน. มันไม่ใช่ตัวเลขในสไลด์ แต่เป็นกราฟ tok/s ที่ขยับจริง. สิ่งที่สังเกตได้:

• เครื่องความจุใหญ่รันโมเดล MoE ตัวใหญ่ (generation ~28 tok/s)
• การ์ดเร็วรันโมเดลขนาดกลางเสิร์ฟ production (~150 tok/s ตรงกับที่สไลด์เคลม)
• มีอีกเครื่องรันโมเดล fine-tune เฉพาะทางด้านคณิตศาสตร์/พีชคณิตเชิงเส้น — request เข้าเป็น burst เป็นช่วงๆ

จุดที่ผมเก็บกลับมา: โมเดลเฉพาะทางขนาดเล็กที่ fine-tune มาตรงงาน กำลังรัน production จริง ควบคู่กับโมเดลใหญ่. คุณไม่จำเป็นต้องมีโมเดล 100B ตัวเดียวทำทุกอย่าง — โมเดล 7B ที่เทรนเฉพาะทางอาจเสิร์ฟงานเฉพาะได้ดีกว่าและถูกกว่ามาก. และการมี dashboard วัด tok/s ต่อเครื่องต่อโมเดล คือสิ่งที่ทำให้รู้ว่าจริงๆ แล้วอะไรกำลังทำงานอยู่ ไม่ใช่เดา.

ภาพรวม: local LLM ไม่ใช่ของเล่นแล้ว

ทั้งวันของงานเต็มไปด้วยหัวข้อ "เอา AI ไปทำเงิน" — automation, agent, market intelligence, การเทรนโมเดลเอง. สิ่งที่ย้ำชัดคือ การรันโมเดลเองในองค์กร (local/on-prem) เข้าสู่จุดที่ทำได้จริงในเชิงต้นทุนและประสิทธิภาพแล้ว — ด้วยแพตเทิร์นง่ายๆ: แยกเครื่องเทรนกับเครื่องเสิร์ฟ, ครอบด้วย gateway มาตรฐาน, แล้วมอนิเตอร์ด้วย dashboard. ไม่ต้องรอ cloud ให้บริการ ไม่ต้องส่งข้อมูลออกนอกองค์กร.

สรุป

• แยก capacity ออกจาก speed — เครื่องหน่วยความจำใหญ่ไว้เทรน/จุโมเดลใหญ่, การ์ด bandwidth สูงไว้เสิร์ฟ production เร็วๆ
• ครอบด้วย gateway มาตรฐาน OpenAI (เช่น LiteLLM) — สลับโมเดลเบื้องหลังโดย client ZERO CHANGE, ไม่ vendor lock-in
• โมเดลเฉพาะทางเล็กๆ รัน production ได้จริง — ไม่ต้องมีโมเดลยักษ์ตัวเดียวทำทุกอย่าง
• มอนิเตอร์ด้วย dashboard (tok/s ต่อเครื่อง/โมเดล) — รู้ว่าอะไรทำงานจริง ไม่ใช่เดา
• local LLM เข้าจุดใช้งานจริงแล้ว — แพตเทิร์นเรียบง่ายพอที่องค์กรกลางๆ ทำเองได้