บ่ายวันอาทิตย์นี้แอดได้มีโอกาสไปเข้าร่วมงาน vLLM Bangkok Day ที่ดำเนินงานหลักโดย AGICAFET งานนี้เต็มจนที่นั่งไม่พอแต่ทีมใจดีมีไลฟ์ให้ด้วย https://web.facebook.com/100063640873544/videos/751409158067885
ก่อนเข้าเรื่อง แอดปูให้ไว ๆ ว่า vLLM คืออะไร แล้วทำไมต้องมีงานทั้งงานเพื่อมัน
ถ้าเราเคยลองรัน LLM บนเครื่องตัวเอง น่าจะรู้จักพวก Ollama หรือ LM Studio กันอยู่แล้ว แต่ vLLM มันคล้าย ๆ กัน แต่คนละแบบ vLLM มันคือ “inference engine” หรือเครื่องยนต์สำหรับ “เสิร์ฟ” LLM ให้คนจำนวนมากใช้พร้อมกัน
แต่พวก Ollama หรือ LM Studio อ่ะเราเอาไว้ใช้เอง หลายคนอาจจะงงแล้ว inference นี่มันยังไงนะ? ให้เราเข้าใจอย่างนี้ เทรนโมเดล (training) มันคือการสร้างสมอง ส่วน inference จะเป็นการเอาสมองนั้นแหละมาตอบคำถามจริง ๆ เหมือนอย่างที่เราถาม ChatGPT, Gemini, Claude ที่เราถาม โมเดลประมวลผล แล้วมันตอบเรามา ซึ่งเป็นขั้นตอนที่เกิดขึ้นซ้ำ ๆ ทุกวินาที ทุกครั้งที่ผู้ใช้พิมพ์อะไรเข้ามา ค่าใช้จ่ายส่วนใหญ่ในชีวิตจริงของระบบ AI จึงไม่ได้อยู่ที่การเทรน แต่อยู่ที่ inference นี่แหละ คำถามคือ เราจะทำให้ขั้นตอนนี้ถูกลง เร็วขึ้น และเสถียรพอจะเอาไปใช้งานจริงได้ยังไง?
Session 1 — vLLM Roadmap in the Thailand Ecosystem
คุณจ๊อบ (Natdhanai) — Founder & CEO, AGI Cafe
เปิดงานโดยคุณจ๊อบ ผู้ก่อตั้ง AGI Cafe เจ้าของเพจ ตื่นมาโค้ด Python by AGICAFET เปิดมาด้วยตัวเลขลงทะเบียน ตึง ๆ เปิดมามีคนสมัครเข้ามา 256 คนภายใน 24 ชั่วโมงแรก รวมทุกแพลตฟอร์มก็ทะลุ 500 คน คุณจ๊อบบอกว่าตัวเลขนี้บอกผมอย่างเดียว ประเทศไทยพร้อมจะคุยเรื่อง inference กันอย่างจริงจังแล้ว
ภาพย้อนหลังคอมมูนิตี้ vLLM ในไทยตลอดปีที่ผ่านมา จากมีตอัพเล็ก ๆ สู่งานที่คนล้นห้อง
Roadmap ที่ประกาศบนเวที
- จัด vLLM Virtual Sharing ทุกเดือน สำหรับคนที่มาที่งานจริงไม่ได้
- จัด vLLM Thailand Conference ทุก ๆ 6 เดือน
- เปิดวิชาใหม่ร่วมกับมหาวิทยาลัยธรรมศาสตร์และ Embedded LLM ในชื่อ Platform Engineering ให้นักศึกษาไทยเรียนเรื่อง inference optimization และ post-training จริงจัง
- เปิดรับความร่วมมือจากองค์กรที่อยากลงมาช่วยสร้าง ecosystem ผ่าน vllmbangkok.com
Session 2 — Introduction to vLLM: ทำอย่างไรให้ GPU ที่มีอยู่ทำงานได้เต็มที่ที่สุด
Tun Jian Tan — vLLM Maintainer, Principal AI Engineer, Embedded LLM
คุณ Tun Jian Tan เป็นหนึ่งใน maintainer ของ vLLM ที่ทำโปรเจกต์นี้มาเกือบสามปี เขาบอกว่าปีที่แล้วเขาเคยมาพูดที่กรุงเทพฯ แล้วครั้งหนึ่ง และดีใจที่เห็นคอมมูนิตี้โตขนาดนี้
ประเด็นหลักคือ ตอนนี้ GPU แพงและหายากมาก การจะไปหา H100 หรือ B300 มาใช้ก็ไม่ใช่เรื่องง่าย แล้วถ้าเรามีแค่ RTX 5090 หรือการ์ดระดับ consumer เราจะรีดประสิทธิภาพออกมาได้แค่ไหน เห้ย น่าสนใจ!!!
Ollama กับ vLLM ต่างกันตรงไหน
สไลด์นี้แอดชอบ เพราะมันเคลียร์มาก
ตารางเปรียบเทียบ Ollama กับ vLLM — คนละเป้าหมาย คนละสนาม
- Target — Ollama ออกแบบมาเพื่อผู้ใช้คนเดียวบนแล็ปท็อป ส่วน vLLM ออกแบบมาเพื่อรับคนพร้อมกันหลายคนบน production (เห็นมั้ยว่าเคลียร์เลย55)
- Batching — Ollama ตั้งต้นที่ batch size = 1 ส่วน vLLM ใช้ continuous batching คือยัดคำขอใหม่เข้าคิวได้เรื่อย ๆ โดยไม่ต้องรอรอบเดิมจบ
- Scale-out — vLLM รองรับการกระจายงานหลายแบบ ทั้ง TP/PP/DP/EP และ PD Disaggregated Inferencing (เดี๋ยวแอดอธิบายเพิ่มด้านล่าง)
- Day-0 support — พอมีโมเดลใหม่ออก vLLM รันได้วันเดียวกัน เพราะเจ้าของโมเดลกับเจ้าของฮาร์ดแวร์เข้ามาทำงานร่วมกับคอมมูนิตี้ตั้งแต่ก่อนประกาศ
- Quantization — Ollama ใช้ GGUF ส่วน vLLM รองรับ FP8, INT4, INT8, MXFP4, NVFP4
ศัพท์แปลไทยฉบับน่าจะเข้าใจขึ้น
😂 TP (Tensor Parallelism) คือหั่นโมเดลตามแนวขวางแล้วให้ GPU หลายใบช่วยกันคำนวณเลเยอร์เดียวกัน
PP (Pipeline Parallelism) คือแบ่งโมเดลเป็นช่วง ๆ ให้ GPU แต่ละใบรับผิดชอบคนละช่วง
DP (Data Parallelism) คือก๊อปโมเดลไว้หลายชุดแล้วแบ่งคำขอกันไป
EP (Expert Parallelism) ใช้กับโมเดลแบบ MoE ที่มี “ผู้เชี่ยวชาญย่อย” หลายตัว
ทำไมต้อง self-host
คุณ Tun Jian Tan บอกว่าเหตุผลหลักสามข้อ คือ security, privacy และ control ถ้าข้อมูลของเราเป็นข้อมูลสุขภาพหรือข้อมูลการเงิน เราอาจไม่อยากส่งออกไปข้างนอกเลย และเขาก็เอากราฟจาก Artificial Analysis มาโชว์ว่าโมเดล open source วิ่งไล่โมเดลปิดมาใกล้มากแล้ว
โดยเฉพาะโมเดลขนาดเล็กอย่าง Qwen3 ระดับ 27B ที่รันบนการ์ด consumer ได้สบาย ๆ ก็มีคะแนนใกล้เส้น frontier ของรุ่นเดียวกันแล้ว
อะไรกินหน่วยความจำ GPU ของเราบ้าง
จุดที่หลายคนพลาดคือคิดแค่ว่า “โมเดลกี่ GB” แล้วซื้อการ์ดตามนั้น จริง ๆ แล้วมีสามก้อนที่ต้องคิด
- Model weights — น้ำหนักโมเดล เช่น Llama-3.1-70B ที่ BF16 กินราว 141 GB
- KV cache — แคชของ key/value ที่เกิดจากทุก token ที่เข้ามา เช่น Llama-3.1-70B ที่ 8k sequence กินอีกราว 2.56 GB
- Static memory — พวก CUDA graph, PyTorch memory pool และ kernel workspace buffer ที่ต้องกันไว้
KV cache คือพระเอกของงานนี้ เพราะเวลาโมเดลอ่าน prompt มันต้องคำนวณค่า K และ V ของทุก token แล้วเก็บไว้ พอจะสร้าง token ตัวถัดไป มันต้องหันกลับไปมองค่าเหล่านั้นทั้งหมด ถ้าไม่เก็บไว้ก็ต้องคำนวณใหม่ทุกครั้ง ซึ่งสมัยก่อนที่ prompt ยาวแค่ 500 token ก็ไม่เท่าไร แต่ทุกวันนี้เราคุยกันที่ agentic workload ที่ prompt ยาว 200K–500K token การคำนวณใหม่ทุกรอบคือหายนะ
สี่ท่าที่คุณ Tun Jian Tan บอกว่าให้ลองก่อน
1. Quantization — ลดความละเอียดของตัวเลข
ปกติน้ำหนักโมเดลเก็บที่ BF16 (16 บิต) ถ้าลดลงมาเหลือ FP8 ก็ประหยัดพื้นที่ไปครึ่งหนึ่งทันที และการ์ดใหม่ ๆ อย่าง RTX 5090 ก็รองรับ FP8 บน tensor core อยู่แล้ว จุดที่หลายคนไม่รู้คือ vLLM มี online quantization ให้ด้วย คือโหลดโมเดล BF16 เข้ามาแล้วให้มันแปลงเป็น FP8 ตอนเสิร์ฟเลย ไม่ต้องไปหาไฟล์โมเดลที่ quantize มาแล้ว
และไม่ใช่แค่น้ำหนักโมเดล activations และ KV cache เองก็ quantize ได้ ถ้ากังวลเรื่องความแม่นยำ มีแฟล็ก calculate-KV-scales ให้ใช้ ส่วนในระดับ production เจ้าของโมเดลเขาจะ calibrate ด้วย dataset ภายนอกที่ครอบคลุมโดเมนที่ต้องการ
2. Automatic Prefix Caching — ใช้แคชร่วมกันข้าม request
ถ้าระบบเรามี system prompt ยาว ๆ ที่ใช้เหมือนกันทุกคำขอ (ซึ่งเกือบทุกระบบเป็นแบบนั้น) เราไม่จำเป็นต้องคำนวณ KV ของส่วนนั้นใหม่ทุกครั้ง เปิดฟีเจอร์นี้แล้วคำขอที่มี prefix เหมือนกันจะใช้แคชร่วมกันได้เลย คุณ Tun Jian Tan ใช้คำว่า “อันนี้ควรเปิดไว้เป็นค่าเริ่มต้น”
3. KV Cache Offloading — ย้ายแคชออกจาก GPU
อันนี้คือแนวคิดที่คุณ Tun Jian Tan ย้ำว่า “ให้จำไว้เลย” สำหรับงาน long context โดยเฉพาะ agentic workload หลักการคือแทนที่จะทิ้ง KV cache ไป เราย้ายมันลงไปเก็บที่ CPU RAM หรือ SSD หรือ remote storage แทน
เหตุผลง่ายมาก: การโหลดข้อมูลกลับมาจาก DRAM หรือ SSD เร็วกว่าการคำนวณ 500K token ใหม่เยอะ แม้ว่าที่เก็บบน GPU จะเร็วที่สุดแต่ก็เล็กที่สุด ไล่ลงมาเป็น CPU RAM ที่ใหญ่ขึ้น SSD ที่ใหญ่ขึ้นอีก จนถึง remote storage ที่แทบไม่จำกัด เป็นการแลกความเร็วกับความจุแบบตรงไปตรงมาจริง ๆ
4. Speculative Decoding และ Sleep Mode
Speculative decoding คือการเอาโมเดลเล็กมาเดาว่าโมเดลใหญ่จะพูดอะไรต่อ แล้วให้โมเดลใหญ่ตรวจทีเดียวหลายตัว เพราะการรันโมเดลเล็กถูกกว่ามาก โมเดลใหม่ ๆ อย่าง Kimi K3 หรือ MiniMax M3 ก็มาพร้อมกลไกแบบ Eagle หรือ MTP ในตัวแล้ว
ส่วน Sleep mode เอาไว้ใช้ตอนที่เราอยากรันหลายโมเดลบนการ์ดใบเดียวกัน มันจะถอดน้ำหนักโมเดลและ KV cache ออกจาก VRAM แต่ยังเก็บ metadata อย่าง CUDA graph ไว้ ทำให้สลับโมเดลได้เร็วกว่าการปิดเซิร์ฟเวอร์แล้วเปิดใหม่ประมาณ 20 เท่า
เช็กลิสต์ก่อน setup vLLM
คุณ Tun Jian Tan ปิดท้ายด้วยคำถามที่ควรตอบตัวเองให้ได้ก่อนจะไปกดปุ่มอะไร จะรันโมเดลไหน, context ยาวเท่าไร, ต้องรองรับกี่คนพร้อมกัน, input/output ยาวประมาณไหน แล้วค่อยเลือกเทคนิคที่เหมาะกับ workload นั้น
และคุณ Tun Jian Tan ก็ย้ำว่าทุกอย่างมีราคาที่ต้องจ่าย อย่าง quantization อาจทำให้ความแม่นยำลดลงนิดหน่อย ส่วน speculative decoding ก็ต้องกิน VRAM เพิ่มเพื่อเก็บ draft model
“ถ้าเรากำลังเสิร์ฟ LLM ในปลายปี 2026 เราก็คงใช้ vLLM อยู่แล้ว หรือไม่งั้นก็ควรอธิบายตัวเองให้ได้ว่าทำไมถึงไม่ใช้”
Panel 1 — AI Adoption in Thailand
Dr. Komes Chandavimol (KBTG) · Tuan Luong (TensorMesh) · Peng Chiang Tan (Embedded LLM) · ดำเนินรายการโดยคุณยิ้ม (FlowAccount)
วง Panel แรกของงาน มองการ adopt AI จากฝั่งองค์กร ฝั่งต้นทุน และฝั่งคนที่ต้องทำให้มันรันจริง
คุณยิ้มเปิดวงได้ดีมาก คุณยิ้มเล่าว่าดูแลโปรดักต์ที่ FlowAccount ซึ่งลูกค้าส่วนใหญ่เป็นเจ้าของธุรกิจขนาดเล็กที่อาจไม่เคยได้ยินคำว่า inference มาก่อน
ปีที่ผ่านมาอะไรขยับบ้าง
Dr. Komes จาก KBTG เล่าว่าขั้นแรกขององค์กรไม่ใช่การเลือกเครื่องมือ แต่คือการวัด “ความพร้อม” ของคนก่อน เมื่อสามปีก่อนพวกเขาสำรวจแล้วพบว่าพนักงาน 80–90% ใช้ ChatGPT อยู่แล้ว กลุ่มนั้นคือ early adopter จากนั้นค่อยออกแบบวิธี adopt ให้เหมาะกับแต่ละกลุ่ม
ส่วนคุณ Tuan Luong จาก TensorMesh พูดถึงสิ่งที่เรียกว่า productivity paradox คือ AI ทำให้ “คน” ทำงานเร็วขึ้นชัดเจน แต่พอถามว่า “องค์กร” ได้ผลตอบแทนเพิ่มขึ้นเท่าไร กลับไม่มีใครตอบได้ และผู้บริหารเห็นแต่บิลค่า GPU ที่พุ่งขึ้น
และอีกเคสที่เกิดในไทย บริษัทหนึ่งจ่ายเดือนละ 500,000 ดอลลาร์เพื่อให้ dev 1,000 คนใช้ AI แต่ใช้หมดตั้งแต่กลางเดือน แล้วหลังจากนั้นทีมก็ทำงานกันแบบอดอยาก
Self-host หรือเรียก API ดี
คำตอบของทั้งวงตรงกันอย่างน่าสนใจ ปัจจัยที่ตัดสินจริง ๆ ในทางปฏิบัติคือ “บิลค่า GPU” ไม่ใช่เรื่องเทคนิคสวยหรู ส่วนปัจจัยรองคือ latency, sovereignty และนโยบาย data residency ที่บางอุตสาหกรรมห้ามส่งข้อมูลออกนอกประเทศเด็ดขาด
คุณ Peng Chiang Tan จาก Embedded LLM สรุปสั้นและตรงว่า “ถ้ามี GPU อยู่แล้ว ให้ self-host เลย มันคือเครื่องพิมพ์เงินของเรา แต่ถ้ายังไม่มี ให้เริ่มจาก API ก่อน”
ตัวอย่างเคสมีการเล่าถึงคือลูกค้าที่มีการ์ด Radeon ระดับ consumer อยู่แปดใบแต่รันได้ช้ามาก พอทีมเข้าไปช่วย optimize ตาม use case ที่เป็นแบบ concurrency ต่ำแต่ยอมรับ latency ได้ ผลคือเร็วขึ้น 50–100 เท่า
Governance ที่ทำให้ทีมเร็วขึ้น ไม่ใช่ช้าลง
ส่วนนี้เราคิดว่าเป็นของดีที่คนสายเทคนิคมักข้าม Dr. Komes อธิบายกระบวนการของ KBTG ไว้เป็นขั้น ๆ
- ให้ AI literacy กับทุกคนก่อน เพราะทุกวันนี้คนที่สร้าง prototype ไม่ใช่ developer อย่างเดียวแล้ว
- ใครก็สร้าง prototype ได้ แต่มี “ประตู” คอยประเมินว่าอันไหนมีผลกระทบจริง ถ้าผ่านถึงจะได้เครดิต ได้เครื่องมือ ได้สิทธิ์เข้าแพลตฟอร์มเพิ่ม
- จาก MVP ไปเป็น pilot ต้องทดสอบกับพนักงานในบริษัทก่อน ยังไม่ให้แตะลูกค้า
- มี exit criteria ชัดเจนว่าอะไรคือ “สำเร็จ” ก่อนจะขึ้น production
- ที่สำคัญที่สุด governance ไม่จบตอน go live ต้องมอนิเตอร์ต่อว่ามี hallucination ไหม มี infinite loop ไหม และต้องมีแผนสำรองเสมอถ้าต้องถอดของออก
“จากไอเดียเป็นพัน เหลือ MVP เป็นร้อย เหลือ pilot สิบตัว และตอนจะสเกลไปหาลูกค้า 20 ล้านคน นั่นคืออีกประตูหนึ่งที่ต้องผ่าน”
แล้วรายเล็ก ๆ ล่ะ
คำถามปิดวงเป็นคำถามที่ดีมาก ธุรกิจ SME ที่ไม่มีทีม IT เลย จะเข้าถึง AI ได้อย่างไร ต้องพึ่ง engineer ไหม ต้องพึ่งรัฐไหม
อาจารย์โกเมธให้คำตอบว่า “ต้องพึ่งตัวเองครับ” อย่างน้อยที่สุดคือต้องรู้ว่าคำตอบที่ AI ให้มานั้นถูกหรือผิด ต้อง validate ผลลัพธ์เป็น ซึ่งก็คือ AI literacy พื้นฐานเหมือนที่เราต้องรู้ว่าผลการค้นหาใน Google อันไหนเชื่อได้
ส่วนคุณ Tuan มองในมุมนโยบาย เขาบอกตรง ๆ ว่าอาเซียนยังอยู่ในสถานะ “ผู้ใช้” มากกว่า “ผู้สร้าง” ถ้าลองไปนับดูว่ามี developer จากอาเซียนกี่คนที่มีชื่ออยู่ในโปรเจกต์โอเพนซอร์สใหญ่ ๆ ตัวเลขยังน้อยมาก
Session 3 — Thai and Global Perspective: Connected Point
CK Cheong — CEO, Fastwork.co
CK Cheong จาก Fastwork ขึ้นเวทีในหัวข้อ Thai and Global Perspective
เซสชันนี้ไม่มีสไลด์เทคนิคเลยสักแผ่น แต่เป็นเซสชันที่คนในห้องให้ความสนใจแบบสุด ๆ รวมถึงแอดด้วย เพราะคุณ CK พูดเรื่องที่คนในห้องไม่ค่อยได้ยินจากเวที AI
คำถามแรกคือไทยควรวางตัวอย่างไรในระบบนิเวศ AI โลก คำตอบของเขาคือ “อย่าเริ่มจากเทคโนโลยี ให้เริ่มจากปัญหา”
“ถ้าเราจะสร้าง foundational model มาแข่งกับ OpenAI หรือ Anthropic มันคงไม่ฉลาดนัก เราต้องเลือกให้ถูกจุด และผมอยากเริ่มจากปัญหาที่เราอยากแก้มากกว่า”
ปัญหาที่เขาคิดว่าเร่งด่วนที่สุดของไทยคือเกษตรกรรม เขาให้ตัวเลขว่าแรงงานไทยราว 30% เป็นเกษตรกร ที่ดินราว 70% เป็นพื้นที่เกษตร แต่ GDP ที่มาจากภาคเกษตรกลับไม่ถึง 10% คุณ CK ใช้คำว่า “น่าเสียดาย” และตั้งคำถามกลับว่า ถ้าเกษตรไม่ใช่อนาคตจริง แล้วทำไม Bill Gates ถึงไล่ซื้อที่ดินเกษตรในอเมริกา ทั้งที่อเมริกาปลูกได้ปีละครั้ง ส่วนบ้านเรามีแดดทั้งปีและมีน้ำ (มากเสียจนน้ำท่วม)
CK ระหว่างพูดถึงการ rethink ว่า “ซอฟต์แวร์” ในยุค agent ควรหน้าตาเป็นอย่างไร
AI ยังไม่ได้เปลี่ยนฝั่ง consumer จริง ๆ
คุณ CK บอกว่า AI startup ทุกวันนี้ราว 95% เป็น SaaS สำหรับองค์กร ในขณะที่แอปที่คนทั่วไปใช้อย่าง Netflix, Shopee หรือ Grab หน้าตายังเหมือนเดิมแทบทุกอย่าง แปลว่า AI ยัง disrupt ฝั่ง consumer ไม่ได้จริง และนั่นแหละคือรางวัลก้อนใหญ่ที่ยังไม่มีใครคว้า
เคสที่ CK ยกมาน่าคิดมาก คือการที่ Salesforce ยอมให้ Claude เป็นหน้าตาที่ผู้ใช้คุยด้วย แล้วตัวเองถอยไปเป็น backend ให้ agent เข้ามาทำงานใน CRM แทนที่จะให้มนุษย์กดเมนูเอง
“อนาคตอาจจะเหลือ agent interface อันเดียว และทุกอย่างที่เราสร้าง แม้แต่ Fastwork เอง ก็กลายเป็น backend ของมัน เหมือนเรามีร้าน 7-Eleven ที่บางครั้งมนุษย์เดินเข้ามา แต่ส่วนใหญ่จะเป็น agent”
นิยามใหม่ของ full stack
ท่อนที่แอดคิดว่าโดนสุด คือเขาบอกว่าทุกวันนี้ coding ถูก commoditize ไปแล้ว สิบห้าปีก่อนถ้าอยากได้ engineer เก่งที่สุดต้องไป Silicon Valley แต่วันนี้แม้แต่ coder ที่เก่งที่สุดก็เขียนโค้ดไม่ชนะ coding agent และบริษัทอเมริกันเข้าถึงเครื่องมือเดียวกับที่เราเข้าถึง
“นิยามใหม่ของ full stack ไม่ใช่ front-end กับ back-end แล้ว แต่คือคุณมี product taste ไหม คุณรู้ไหมว่าควรสร้างอะไร คุณคิดแบบ product manager ได้ไหม”
และเขาก็ฝากไว้อีกข้อว่า เวลาสร้างซอฟต์แวร์ ให้สร้างเพื่อคนทั้งโลกไปเลย ไม่ต้องคิดว่าเป็นของไทยแล้วต้องขายแค่ในไทย
Session 4 — Inside vLLM: Production Best Practices, Model Integration and Roadmap
Tiezhen Wang — Head of Ecosystem, Inferact
The state of vLLM today — 91K GitHub stars และ 3,336 contributors
Tiezhen มาจาก Inferact ซึ่งเป็นบริษัทที่อยู่เบื้องหลัง vLLM เขาเปิดด้วยการให้คนในห้องยกมือว่าใครเคยได้ยินชื่อ vLLM บ้าง แล้วถามต่อว่าใครเคยส่ง PR เข้าไปบ้าง มือที่ยกลดลงเยอะมาก ซึ่งก็ตรงกับที่ Tuan พูดในวงก่อนหน้าพอดี
เริ่มจาก recipes ไม่ใช่จาก docs
ทริกแรกที่เขาแนะนำคือให้เข้าไปที่ recipes.vllm.ai เลือกโมเดล แล้วจะได้ชุดค่าที่ผ่านการทดสอบมาแล้วสำหรับฮาร์ดแวร์แต่ละแบบ ทั้งแบบ quantize และแบบ parallelize
จากนั้นคุณ Tiezhen ก็ตั้งคำถามกับห้องว่า recipe เหล่านี้ยังขาดของสำคัญไปหนึ่งอย่าง คำตอบคือ speculative decoding
Speculative decoding คือการให้โมเดลเล็กเดาล่วงหน้า แล้วให้โมเดลใหญ่ตรวจทีเดียวหลายตัว
เขาอธิบายเพิ่มว่าเทคนิครุ่นเก่าอย่าง MTP เดาได้ทีละไม่กี่ตัว แต่รุ่นใหม่อย่าง DiffFlash 2 เดาได้ทีเดียว 16 token แล้วส่งไปให้ verifier ตรวจพร้อมกัน ผลคือได้ token เร็วขึ้น 2–3 เท่าบนฮาร์ดแวร์ชุดเดิม โดยยังการันตีว่า distribution ของผลลัพธ์เหมือนเดิม
สองพารามิเตอร์ที่สำคัญที่สุด
ถ้าให้เลือกแค่สองตัวจากรายการยาวเหยียด เขาเลือก max-model-len กับ max-num-seqs
- max-model-len คือความยาว context ที่เรายอมให้ผู้ใช้ใช้ได้ ต่อให้โมเดลรองรับ 1 ล้าน token ก็ไม่ได้แปลว่าเราต้องเปิดให้ครบ ถ้าทำแชตบอต 2,000–3,000 ก็พอแล้ว เพราะ context ที่เปิดไว้กินหน่วยความจำ GPU ที่มีค่ามาก
- max-num-seqs คือจำนวนคำขอที่ GPU ประมวลผลพร้อมกันได้ในหนึ่งรอบ หรือขนาด batch นั่นเอง
กราฟ trade-off ระหว่าง interactivity (token ต่อวินาทีต่อผู้ใช้) กับ throughput รวม
กราฟนี้อธิบายเรื่องที่หลายคนเข้าใจผิด แกน X คือ interactivity หรือจำนวน token ต่อวินาทีที่ผู้ใช้แต่ละคนได้รับ ส่วนแกน Y คือ throughput รวมทั้งระบบ เราจะทำให้ผู้ใช้คนเดียวมีความสุขมาก ๆ ก็ได้ แต่จะแพงมาก หรือจะปั๊ม throughput รวมให้สูงก็ได้ แต่แต่ละคนจะรู้สึกช้า งานของเราคือหาจุดที่ยอมรับได้บนเส้นนั้นตามฮาร์ดแวร์ที่มี
และเขาย้ำว่ากราฟนี้ไม่ใช่ค่าคงที่ ทุกครั้งที่คอมมูนิตี้ optimize เพิ่ม เส้นทั้งเส้นก็ขยับ
Day-0 integration ทำงานอย่างไร
ส่วนนี้เป็นเบื้องหลังที่เราไม่เคยรู้มาก่อน เวลามีโมเดลใหม่จะออก vLLM ได้โมเดลมาก่อนคนอื่นเป็นเดือน (เขายกตัวอย่าง DeepSeek V4 Flash ที่ได้มาล่วงหน้าหนึ่งเดือน) แล้วทำสี่ขั้น
- ประสานงานกับเจ้าของโมเดล
- implement แล้ว verify ว่าคะแนน eval ตรงกับที่เจ้าของโมเดลได้ ไม่ใช่แค่ “รันได้”
- แพ็กทุกอย่างรวม PR ที่ยังไม่ merge ลง Docker image สำหรับ day-0
- ปล่อย recipe พร้อมวันที่โมเดลประกาศ แล้วค่อยทยอย merge PR เข้า main ภายในหนึ่งถึงสองสัปดาห์
เขาโชว์แดชบอร์ดของ Kimi K3 ให้ดูว่าตอนเปิดตัวได้ราว 500 token ต่อวินาทีต่อ GPU แต่ตอนนี้ทะลุ 1,000 แล้ว เพิ่มขึ้นเท่าตัวจากการ optimize ของคอมมูนิตี้ล้วน ๆ โดยที่ฮาร์ดแวร์ไม่ได้เปลี่ยน
ช่องว่างระหว่างโมเดล open source กับ closed source ที่แคบลงเรื่อย ๆ
สไลด์นี้เขาแบ่งเป็นสามโซน โซนซ้ายคือโมเดลเล็กที่ open source ชนะขาดเรื่องต้นทุน เพราะเราไม่ต้องจ่าย “ค่าพรีเมียมโมเดล” โซนกลางคือสูสี ส่วนโซนขวาสุดที่เป็น frontier ก็เริ่มมีโมเดลเปิดอย่าง K3 ที่ไล่ตามมาใกล้มากแล้ว
สำหรับโรดแมป Q3 ของ vLLM เขาสรุปไว้สั้น ๆ ว่า เน้น model performance และ speculative decoding, ขยายการรองรับฮาร์ดแวร์ (Google TPU และ AMD GPU), และลดช่องว่างระหว่าง training กับ inference เพื่อรองรับงาน RL
Session 5 — Scaling Distributed Inference with llm-d
Jing Wen Ng — Specialist Solution Architect, AI, Asia Pacific, Red Hat
Scaling Distributed Inference with llm-d โดยทีม Red Hat ถ้าเซสชันก่อนหน้าคือการรีด GPU หนึ่งใบหรือหนึ่งเครื่องให้เต็มที่ เซสชันนี้คือคำถามว่าแล้วถ้าต้องขยายเป็นสิบเป็นร้อยเครื่องล่ะ
รอบนี้เปิดด้วยการเปรียบเทียบที่ชัดมาก request แบบเดิมก่อนยุค AI นั้นเร็ว สม่ำเสมอ และถูก เช่นการ query ฐานข้อมูลง่าย ๆ ที่กิน CPU กับ RAM พอ ๆ กันทุกครั้ง การกระจายโหลดแบบ round robin จึงพอ
แต่ request แบบ LLM ช้า ไม่สม่ำเสมอ แพง และที่สำคัญคือ stateful เพราะบทสนทนามีหลายเทิร์นและมี KV cache ค้างอยู่ตามเครื่อง การส่งคำขอแบบสุ่มไปเรื่อย ๆ จึงพังทันที
llm-d คืออะไร
llm-d เป็นโปรเจกต์โอเพนซอร์สที่ Red Hat, Google, NVIDIA และอีกหลายเจ้าร่วมกันทำ และถูกบริจาคให้ CNCF เป็น sandbox project เมื่อมีนาคม 2026 หน้าที่ของมันคือเป็น framework สำหรับ distributed inference ที่รันบน Kubernetes โดยตรง และต่อยอดบน vLLM อีกที
หัวใจของมันคือส่วนที่เรียกว่า EPP หรือ Endpoint Picker ซึ่งทำหน้าที่เป็น “สมอง” ในการตัดสินใจว่าคำขอนี้ควรไปลงที่ pod ไหน โดยดูจากข้อมูลที่ Kubernetes service ธรรมดาไม่มี เช่น pod ไหนเหลือ KV cache headroom เท่าไร, pod ไหนมีคิวยาว, หรือ pod ไหนมี prefix ของ prompt นี้แคชไว้อยู่แล้ว
หกเส้นทางที่ผ่านการพิสูจน์แล้ว (Well-Lit Paths)
Key Features — หกเส้นทางหลักของ llm-d
- Intelligent Inference Scheduling จัดเส้นทางโดยดูทั้ง prefix ที่แคชไว้และภาระงานของแต่ละ pod พร้อมกัน
- KV Cache Management ช่วย offload แคชลง CPU หรือ storage เพื่อให้แคชอยู่ในระบบได้นานที่สุด Prefill-Decode Disaggregation แยกการประมวลผลส่วน prefill และ decode ออกจากกัน
- Multi-Node Serving รองรับโมเดล MoE ขนาดใหญ่ด้วย Wide Expert Parallelism
- Flow Control จัดการคิวโดยคำนึงถึงทั้ง fairness และ priority สำหรับงานแบบ multi-tenant
- Workload Variant Autoscaling ปรับสเกลโดยอาศัยตัวชี้วัดที่มองไปข้างหน้า แทนการใช้ตัวชี้วัดที่ตามหลัง
ของที่เราชอบที่สุดในเซสชันนี้คือ predicted latency scheduling ซึ่งเป็นการปรับปรุงต่อจาก scheduling ปกติ โดยเอาโมเดล machine learning ตัวเล็ก ๆ (XGBoost) มาช่วยทำนายว่าถ้าส่งคำขอนี้ไปที่ pod นี้ TTFT จะเป็นเท่าไร มี trainer pod คอยเก็บ request ที่เพิ่งเสร็จมาเทรนใหม่ตลอดเวลา แล้วมี predictor pod คอยทำนายแบบเรียลไทม์
PD Disaggregation แยกคนละงาน คนละเครื่อง
แอดขออธิบายศัพท์ก่อนนะครับ P คือ prefill หรือขั้นตอนอ่าน prompt ทั้งก้อน ซึ่งขนานกันได้เต็มที่และติดที่กำลังคำนวณ (compute bound) ส่วน D คือ decode หรือขั้นตอนพ่น token ทีละตัว ซึ่งต้องทำเรียงลำดับและติดที่แบนด์วิดท์หน่วยความจำ (memory bound)
สองงานนี้ต้องการการตั้งค่าคนละแบบ การจับมันยัดไว้ในเครื่องเดียวกันจึงเป็นการประนีประนอมเสมอ llm-d แยกมันออกเป็นคนละ pod ให้แต่ละฝั่งทำสิ่งที่ตัวเองถนัดที่สุด
ผลลัพธ์ของ PD Disaggregation — ITL ที่ P99 ลดจากราว 800–900 มิลลิวินาที เหลือระดับ 100 กว่ามิลลิวินาที
ตัวเลขบนสไลด์คือ inter-token latency ที่ P99 ลดจากราว 800–900 มิลลิวินาที เหลือประมาณ 100 กว่ามิลลิวินาทีอย่างสม่ำเสมอ — ดีขึ้นราวแปดเท่า และที่สำคัญกว่าค่าเฉลี่ยคือมัน “นิ่ง” ขึ้นมาก
องค์ประกอบห้าชั้นของ inference stack ระดับองค์กร
ห้าองค์ประกอบของ enterprise GenAI inference platform
- ชั้นล่างสุด — รองรับ hardware accelerator ได้หลากหลาย ไม่ผูกกับยี่ห้อเดียว
- ชั้นสอง — inference engine ที่มีประสิทธิภาพ ซึ่งวันนี้คือ vLLM
- ชั้นสาม — เลือกโมเดลโอเพนซอร์สได้หลายตัวตาม use case ทั้งงานเขียนโค้ดและงาน RAG
- ชั้นสี่ — framework สำหรับ distributed inference ซึ่งเธอเสนอ llm-d
- ชั้นบนสุด — AI Gateway ที่ทำ API management, token tracking, rate limiting และ authentication และกำลังขยับไปเป็น agentic gateway หรือ MCP gateway
“Keep sharing, keep learning and keep contributing เพราะนั่นคือวิธีที่วัฒนธรรมโอเพนซอร์สทำงานได้ดีที่สุด”
Session 6 — Supercharging vLLM with LMCache
Shaw Nguyen — TensorMesh
Supercharging vLLM with LMCache โดยทีม TensorMesh
เซสชันสุดท้ายฝั่งเทคนิคเจาะลึกเรื่องเดียว KV cache และเป็นเซสชันที่ทำให้เราเข้าใจว่าทำไมทุกคนตลอดทั้งงานถึงพูดถึงมันซ้ำ ๆ
เปิดด้วยการยกคำพูดของ Eric Schmidt ว่าเรากำลังจะเห็น context window ที่ใหญ่มากในไม่กี่ปีข้างหน้า และมันจะส่งผลกระทบในระดับที่ยังไม่มีใครเข้าใจ แล้วก็บอกว่าตอนนี้มันเกิดขึ้นแล้ว ทั้งหนังสือ ข่าว ไฟล์เสียง และ code repo ทั้งก้อน กำลังถูกยัดเข้าไปเป็น input
ไบต์ที่แพงที่สุดบนการ์ดของคุณ
Your GPU’s most expensive bytes — 320 KB ต่อ token, ~40 GB ที่ context 128K, ใช้ครั้งเดียวแล้วถูกลบ
เขาคำนวณให้ดูสด ๆ โดยใช้ Llama 3.1 70B เป็นตัวอย่าง: KV cache หนึ่ง token กินราว 320 KB เมื่อคูณกับ context 128K token ก็ได้ราว 40 GB ซึ่งเกือบครึ่งหนึ่งของ VRAM บน H100 หนึ่งใบ
และสิ่งที่เกิดขึ้นตามปกติคือ เราคำนวณมันขึ้นมาครั้งเดียว ใช้กับคำขอนั้นคำขอเดียว แล้วก็ลบทิ้ง
ทำไมแคชถึง “ตายเร็ว”
The cache dies young สี่สาเหตุที่ทำให้ KV cache หายไปก่อนเวลาอันควร
- Evicted — ถูกไล่ออกเพราะ HBM เต็ม
- Restart — พอ engine ล่มหรืออัปเกรด แคชที่ผูกอยู่กับ engine ก็ตายตามไปด้วยทั้งหมด
- Dispersed — คำขอถัดไปวิ่งไปโดน replica ที่ไม่เคยเห็นแคชนั้นมาก่อน
- Blind spot — เปลี่ยน prefix นิดเดียว เช่นแทรก timestamp หรือ request ID ลงไป ก็กลายเป็น miss ทั้งก้อน
ข้อสุดท้ายนี้เป็นกับดักที่เจอบ่อยมากในงานจริง เขาเล่าเคสที่ลูกค้าตั้งค่าทุกอย่างถูกหมดแล้วแต่ hit rate เป็นศูนย์ ปรากฏว่า chat template แทรก timestamp เข้าไปในทุก prompt
LMCache
LMCache เก็บ KV cache ไว้หลายชั้น ตั้งแต่ GPU HBM ลงไปจนถึง remote shared store
LMCache สร้างโดยทีมนักวิจัยจาก University of Chicago และตอนนี้มีดาวบน GitHub เกิน 10,000 ดวง มี contributor ราว 150 คน แนวคิดของมันคือเก็บ KV cache ไว้หลายชั้น ตั้งแต่ GPU HBM, CPU RAM, ดิสก์ในเครื่อง ไปจนถึง remote shared store ที่ engine หลายตัวใช้ร่วมกันได้
และเนื่องจากการขนข้อมูลก้อนใหญ่ข้ามชั้นเป็นคอขวดในตัวเอง เขาจึงมีเทคโนโลยีที่บีบอัดข้อมูลก่อนส่ง เพื่อใช้แบนด์วิดท์ระหว่างชั้นให้คุ้มที่สุด
CacheBlend ก้าวข้ามข้อจำกัดของ prefix caching
อันนี้คือของเด็ดของเซสชัน ปัญหาของ prefix caching แบบเดิมคือถ้าตรงกลางของ prompt เปลี่ยนไปนิดเดียว ทุกอย่างที่อยู่หลังจากนั้นใช้ไม่ได้เลย ซึ่งเป็นสถานการณ์ปกติของงาน RAG ที่เอกสารสลับลำดับกันไปมา
CacheBlend แก้ด้วยการหั่นประโยคเป็นบล็อกเท่า ๆ กัน แล้วอนุญาตให้สลับตำแหน่งบล็อกหรือแก้บล็อกทีละก้อนได้ จากนั้นค่อยคำนวณ cross-attention เฉพาะส่วนเล็ก ๆ ที่จำเป็นเพื่อรักษาความแม่นยำไว้ ผลคือ TTFT เร็วขึ้นราว 2.2–3.3 เท่าเทียบกับ prefix caching ล้วน ๆ และงานนี้ถูกตีพิมพ์ใน EuroSys 2025
ตัวเลขจากงานจริง
ผลทดสอบงาน long-document QA บนโมเดลขนาด 120B
เขาทดสอบกับงาน long-document QA บนโมเดลขนาด 120 พันล้านพารามิเตอร์ ในสถานการณ์ที่เอกสารยาวมากจนเก็บบน GPU ไม่ไหว ผลที่ได้คือ
- TTFT เร็วขึ้น 5.9 เท่า
- Throughput เพิ่มขึ้น 4.57 เท่า
- ค่า P99 ดีขึ้น 7.6 เท่า ซึ่งแปลว่าประสบการณ์ของผู้ใช้ที่โชคร้ายที่สุดก็ดีขึ้นด้วย
เขาแปลตัวเลข 4.57 เท่าให้เป็นภาษาธุรกิจว่า ถ้าเดิม GPU หนึ่งใบเสิร์ฟได้ 300 คำขอต่อชั่วโมง ตอนนี้เสิร์ฟได้ประมาณห้าเท่าบนฮาร์ดแวร์ชุดเดิม
แต่เขาก็เตือนตรง ๆ ว่านี่ไม่ใช่ค่าคงที่ offload จะคุ้มที่สุดก็ต่อเมื่อ working set ใหญ่เกินหน่วยความจำ GPU เท่านั้น
แล้ว workload แบบไหนไม่ควรทำ
สไลด์ที่เราชอบที่สุดคือสไลด์ที่บอกว่าอย่าใช้ ถ้างานเราเป็น prompt สั้น ๆ ที่ไม่ซ้ำกันเลย คำตอบคือไม่ต้องทำ เพราะ vLLM มี prefix caching ที่ดีอยู่แล้ว ส่วนงานที่ควรทำคือแชตหลายเทิร์น, QA กับเอกสารยาว, coding agent และ RAG
และสำหรับคนที่จะเอาไปใช้จริง เค้าแนะนำว่าให้ไต่ทีละขั้น เริ่มจาก LMCache บนเครื่องเดียว แล้วค่อยเพิ่มชั้น shared tier แล้วค่อยไปถึงระดับที่มี operator คอยดูแลแคชทั้งคลัสเตอร์ พร้อมของที่จำเป็นในระดับองค์กรอย่าง multi-tenancy (ไม่ให้ลูกค้า A แตะแคชของลูกค้า B) และ observability แยกราย tenant
Panel 2 — vLLM Developers in Thailand
คุณโจ้ Sattaya Singkul (True Digital Group) · คุณเต้ Natthanan Bhukan (Tsinghua University) · พี่มด Pongsasit Thongpramoon (NVIDIA) · ดำเนินรายการโดยคุณเจมส์ Kanin (PSF Fellow, PyCon Thailand)
Panel ปิดท้าย ด้วยมุมของ developer ไทยที่ทำงานสาย inference จริง ๆ วงนี้เป็นวงที่คนไทยพูดกับคนไทยโดยตรง
ปัญหาที่เจอจริงบนหน้างาน
คุณโจ้จาก True Digital Group ยกปัญหาที่ไม่มีใครนอกประเทศไทยจะมาแก้ให้เรา การ tokenize ภาษาไทย ข้อความไทยความยาวเท่ากับภาษาอังกฤษจะถูกหั่นออกมาเป็น token จำนวนมากกว่ามาก ผลกระทบตรง ๆ คือ TTFT แปรปรวน และต้องใช้ทรัพยากรมากกว่าเมื่อเทียบกับภาษาอังกฤษ ซึ่งกลายเป็นเรื่องใหญ่ตอนต้องประเมินสเปกและงบซื้อ GPU
พี่มดจาก NVIDIA มองในมุมที่กว้างกว่า โดยบอกว่า NVIDIA มอง AI เป็นเค้กห้าชั้น ตั้งแต่พลังงาน ชิป infrastructure โมเดล ไปจนถึงแอปพลิเคชัน โดย inference อยู่ระหว่างโมเดลกับแอป และเขาใช้คำว่า “token factory” โจทย์จึงไม่ใช่แค่ผลิต token ได้ แต่ต้องผลิตได้ในสเกลที่เอาไปใช้ใน production ได้จริง
“ปัญหาที่คุณจะเจอแน่ ๆ หลังจากเปิด endpoint คือคำว่า ช้า และหน้าที่ของ inference engineer คือตอบให้ได้ว่าช้าตรงไหน ด้วยข้อมูล ไม่ใช่ด้วยความรู้สึก”
เขาบอกว่าต้องแยกให้ออกระหว่างสองตัวชี้วัด คือ TTFT (time to first token) ที่ได้รับผลจากขั้น prefill กับ ITL (inter-token latency) ที่ได้รับผลจากขั้น decode พอแยกออกแล้วถึงจะรู้ว่าควรไปแก้ตรงไหน
ส่วนคุณเต้จาก Tsinghua เล่างานวิจัยในแล็บเรื่อง context parallelism ปัญหาคือเวลา prompt ยาวจนใส่ GPU ใบเดียวไม่ได้ เราต้องหั่นไปหลายใบ แต่ถ้าหั่นแบบง่าย ๆ เท่า ๆ กัน ประสิทธิภาพจะไม่ดี เพราะจะมี GPU บางใบนั่งรออยู่เฉย ๆ ระหว่างขนข้อมูล งานวิจัยของเขาจึงหั่นเป็น tile แล้วใช้ scheduler จับคู่ tile กับเครื่องให้เหมาะ เพื่อให้ทุกใบมีงานทำตลอดเวลา
สถานะของไทยตอนนี้ อยู่ตรงไหน
คำตอบของคุณโจ้ บอกว่าฝั่ง training เราทำได้โอเค เรามี Typhoon, Pathumma, OpenThaiGPT แต่ฝั่ง serving เรายังตามหลังอยู่พอสมควร และเขาก็ไม่คิดว่าเราควรไปไล่แข่งกับ frontier lab ที่เขียน custom kernel รันบน GPU หลายพันใบ
“แต่ประเด็นคือ ไม่มีใครที่ frontier จะมา optimize ให้เรา ไม่มีใครนอกประเทศไทยจะมาแก้ปัญหา tokenizer ภาษาไทยให้เรา หรือมาแก้เรื่อง data residency ให้เรา ช่องว่างที่แท้จริงคือคน”
พี่มดเสริมด้วยเรื่องที่เพิ่งกลับจากสำนักงานใหญ่ที่ซานตาคลารา เขาบอกว่าเห็นป้ายโฆษณาริมถนนเป็นธุรกิจ token-as-a-service เต็มไปหมด หลายชื่อที่เขาไม่เคยได้ยินมาก่อน แล้วเขาก็ถามกลับห้องเบา ๆ ว่า “มีใครรู้จักธุรกิจ token-as-a-service ในไทยบ้าง”
คุณเจมส์ก็เสริมอีกเคสว่ามีบริษัทหนึ่งอยากขยายทีม inference engineer ในไทย ให้เงินเดือนสูงมาก แต่หาคนไม่ได้เลยสักคน
แล้วเราควรเริ่มยังไง
คำแนะนำจากทั้งสามคนสำหรับ software engineer ที่อยากเข้าสายนี้
- คุณโจ้ ลง vLLM แล้วเสิร์ฟโมเดลเล็ก ๆ บน GPU ใบเดียว ใช้เวลา 10 นาที แล้วยิง traffic เข้าไป จากนั้นวัด TTFT กับ ITL ดูว่าตรงกับที่คาดไหม ถ้าไม่ตรงก็ไปปรับ max-num-batched-tokens ดู
- คุณเต้ เริ่มจากความสงสัยของตัวเอง ลองรันบนฮาร์ดแวร์ต่างกัน ทั้ง CPU, GPU, NPU แล้วถามว่าทำไมผลถึงต่างกัน ทุกอย่างที่ฟังมาวันนี้เริ่มจากใครสักคนที่สงสัยแล้วลงมือแก้
- พี่มด หา “คุณค่า” ให้เจอ ว่าธุรกิจที่เราทำงานให้อยู่ ต้องการอะไรจาก inference แล้วเชื่อมทักษะเราเข้ากับสิ่งนั้น เพราะพอเจ้านายเห็นว่ามันทำเงินได้ เราจะมีคนสนับสนุนอยู่ข้างหลัง
สำหรับคนที่เป็นผู้ประกอบการหรือฝั่งนโยบาย คุณโจ้ฝากไว้สองข้อ อย่าเริ่มจากการซื้อ GPU ให้เริ่มจากคนที่จะมารันมัน เพราะคลัสเตอร์ GPU ที่ไม่มีคนเข้าใจเรื่อง serving ก็คือฮีตเตอร์ราคาแพง และข้อสองคือทำกฎเรื่องข้อมูลให้ชัด เพราะข้อจำกัดที่ห้ามส่งข้อมูลออกนอกประเทศ จริง ๆ แล้วคือ “ข้อได้เปรียบ” ของเราในการสร้างขีดความสามารถในบ้านตัวเอง
และทั้งหมดนี้ก็เป็นแค่ส่วนหนึ่งของงานที่แอดเก็บมาฝากทุกคนสามารถย้อนดูแบบเต็ม ๆ ได้ที่เพจ ตื่นมาโค้ด Python by AGICAFET ได้เลยครับ https://web.facebook.com/100063640873544/videos/751409158067885
ขอบคุณทีมงานที่จัดงานความรู้แน่ ๆ นี้ด้วยคร้าบบบ 😊🙏
