จดๆจาก Cloud Native Bangkok: Cloud Native AI (AUG-2026)

Building Inference Workloads with vLLM on Kubernetes (EKS)

Speaker: Patis Piriyahaphan, Dasapich Thongnopnua, Mongkol Thongkraikaew, Fukiat Julnual

📌AI Project หลายๆอันที่เปิดตัวกันมาเยอะ และ ไปเงียบหายไป สาเหตุหลักๆมาจาก 2 ส่วน

• แก้ Pain ของลูกค้าได้ไม่ตรงจุด เลยสร้าง Business Value > Impact ไม่ได้
• Technical Issue - ของดี แค่ตอบสนองช้าไป user ไม่ happy หรือ ลงทุนมากไปจนเริ่มขาดทุน

📌รูปแบบของ AI Project มันเปลี่ยนไปด้วย

• จากเดิม ML แบบเดิม Training > Inference
• ยุค Gen AI - ถ้าระดับทั่วไป ทำได้แค่ Inference ส่วน Training นั้นใช้ทรัพยากรที่เยอะมาก

📌ทำไมต้อง K8S + Self Host

• รูปแบบการคิดราคาของ AI ตอนนี้นับเป็น Token ยิ่งมี Request เยอะ ค่าใช้จ่ายเพิ่มไปตามด้วย ไม่สามารถ Fixed Cost ได้
• ต้องการความเป็นส่วนตัวของข้อมูล
• จุดเด่นของเอา K8S มา Host Inference EndPoint / GenAI App
  - Tooling Ecosystem
  - Extensiblity
  - Cost Optimization
  - Configurability
  - High Scalable
  - Run Anywhere

📌ถ้าเราจะ Self Host และติดต้องถึงอะไรบ้าง

• เข้าใจก่อน Anotomy ของ Model ก่อน ได้แก่
  - Model Weight (.bin / .safetensors / .Pt) - มองเซลล์สมอง มันหลาย GB
  - Config.json บอกว่า รูปแบบการเชื่อมของ Model Weight เป็นยังไง
  - Tokenizer - เราคุยกับด้วยภาษาไหน แปลง Text ของเราในรูปแบบที่ AI เข้าใจ
• เอา Model มาทำงานด้านไหน - Text / Image / Voice หรือ Multi Modal
• เอา Model ขนาดเท่าไหร่ มันจะพวก B เช่น 1ฺB / 70B ซึ่งมีผลกับขนาด Disk / VRAM

• พอเลือก Model ต้องมาคำนวณ เผื่ออีก VRAM เท่าไหร่ Model Weight + KV Cache + Other (temp / OS)
  - KV Cache ลองดูคำนวณเล่นๆได้ https://kvcache.ai/tools/kv-cache-size-calculator/
  - ลด Disk / Ram ลดได้จาก Qunantizatrion
• ใช้มุมไหน Inference / Traning ใช้ HW ต่างกันด้วย

• นอกจากนี้ต้องมาผสมของให้เหมาะสมด้วย พวก Version Runtime
  - K8S Cluster พวก Device Plugin - AWS EFA (Network) / NVIDIA Neuron (GPU for k8s scheduler) / DCGM Exporter (GPU Metric) / CSI Driver (Storage)
  - Image AMI ต้องมาลง CURA + Neuron Drive / CURA runtime ที่ Match กัย Inference แต่ละค่ายพวก vLLM Pytorch
  - ถ้าไม่อยากกวุ่นวายใช้ของที่เค้าลองมาแล้วจบ
• เลือกแบบดูตารางสรุปได้

📌Reference Arch

• Deploy EKS+ vLLM โดย AI Model เราเก็บไว้ใน S3/EFS/EFx'
• ที่นี่ถ้าใช้เคยเล่นพวก Local LLM มันดึง Model มาช้า บน EKS มี GPU / vLLM Image / Model มีการกับการ Scale อันนี้มี 2 เทคนิคมาช่วย
  - Spot Instance เพื่อช่วยลดต้นทุน + Karpenter เข้ามาจัดการระบบ Auto-scaling ใน cluster
  - ฝั่ง Image ใช้ตัว Seekable OCI มาช่วยดึง soci-snapshotter
• มุม Observability มีตัว Grafrana / Promethous โดยมี Metric สำคัฐที่

ถ้าไม่รู้จะเริ่มยังไงดู Reference Arch ได้ https://awslabs.github.io/ai-on-eks/

📌แล้ว ถ้าต้อง Scale Cluster ? มันช่วยได้จริงไหม

ต้องเข้าใจก่อนการ Scale ช่วยได้ แต่ผู้ใช้เดิมต้องอยู่ที่ Node เดิม ส่วนคนใหม่ให้ไปที่ Node อื่น เพราะเคสของ AI มันที่เป็น Multi Turn มันต้องกับไปคุยต่อที่ Node เดิม ไม่งั้นมันจะหา KV Cache เดิมไม่เจอ แล้วเอ่อ ต้องมีของมาช่วยจัดการ

นอกจากนี้ต้องเข้าใจกระบวนการทำการของ Model ด้วย

• Prefill Stage: เป็นขั้นตอน Proces Input หรือ Prompt เพื่อสร้าง Key-Value (KV) ตรงนี้ขึ้น Compute TFLOPS) ของ GPU
• Decode Stage: เป็นขั้นตอน Generate Token ขึ้นอยู่ Memory Bandwidth

จากปัญหาข้างต้นเอา KServe มาช่วยได้ รองรับ Inference ได้หลายตัวอย่าง vLLM / llm-d.ai เป็นต้น ซึ่งมาช่วย Auto Scale / Prefix Cache / Distribute Prefill Decode / Multi Node Scale (Tensor / Pipeline Parallelism) / KV Cache Offloading มันจะอยู่คนละ Node ก็ได้เดว KServe จัดการให้

และเอา LLM-D มาช่วยเลือกให้ถูกตัว เพือไปเรียก KServe + vLLM ให้ถูกตัว

📌Demo Kserve + LLM-D + KServe + vLLM RTX6000 96GB (g7e.2xlarge)

• Envoy จัดการ Network
• LLM-D - Load Balance LLM Request เพือไปเรียก KServe + vLLM ให้ถูกตัว และต่อเนื่อง

📌Demo vLLM RTX 4500 32 GB (g7.Axlarge)

• อันนี้ลองทำ OCR ใช้ Model Typhoon แม้เป็น Model 7B / 14B แต่ความละเอียด BF16

Cloud Native AI Agents with ADK, A2A & kagent

Speaker Kamolphan Liwprasert

📌ยุค Cloud Native AI ซึ่งระบบแบบเดิมต้องปรับตัวให้ตอบโจทย์เพิ่ม

• Sandbox & Isolation สำหรับการทำงานเสี่ยงอย่าง Code Execution
• Life Cycle & Multi-tenancy
• Cost Optimization & Scale-to-Zero
• RBAC
• Zero Trust & Observability
• Tools Connectivity - MCP / A2A

📌kagent เข้ามาช่วยแก้ปัญหาข้างต้น

kagent เป็น project เพิ่งเข้ามาใน CNCF Sandbox Create โดย founder ของ Istio base on ADK (Golang) ซึ่งเข้ามาช่วยแก้ปัญหาข้างต้น รวมถึง

• Declarative Agent & GitOps: เราสามารถสร้าง Agent ได้ในรูปแบบของ CRD (Custom Resource Definition) ของ Kubernetes ทำให้สามารถกำหนดค่าต่างๆ เช่น System Instruction, Tools และ MCP Server ลงในไฟล์ Config แล้วส่งขึ้นระบบ Git เพื่อทำ GitOps และ AgentOps ได้ทันที

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: k8s-expert-agent
  namespace: kagent
spec:
  modelConfigRef:
    name: llama3-model-config
  systemPrompt: "You are a helpful Kubernetes operations assistant. You can check cluster status and Prometheus alerts."
  tools:
    - mcpServerRef:
        name: kubernetes-mcp-server

• รองรับหลาย Runtime/ Framework เช่น LangChain, ADK นอกจากนี้ ถ้ามันไม่ Support ตรงเอา Container มา Deploy ได้
• เชื่อมต่อกับ LLM ได้หลายค่าย ทำเป็น CRD เหมือนกัน

apiVersion: kagent.dev/v1alpha2
kind: ModelConfig
metadata:
  name: llama3-model-config
  namespace: kagent
spec:
  model: llama3
  provider: Ollama
  ollama:
    host: agentgateway-proxy.agentgateway-system.svc.cluster.local

• สร้าง Agent หรือ Harness Agent ก็ได้ + ใช้พวก Skill ก็ได้

ลองไปดูเพิ่ม https://kagent.dev/docs/kagent/concepts/architecture/

นอกจากนี้ Sandbox / Zero Trust / Observability / OpenAI Compatible API

มันปรับแนวคิดการ Deploy จากเดิม Microservice (Pattern แน่นอนตายตัว) > Agent Base (Topology Agent Create on runtime เรากะเส้นทางไม่ได้)

📌Demo มีแสดง kagent

• แสดงให้เห็นว่าเราสร้าง Agent จาก Declartive / Container มาเลยก็ได้ รวมถึงเลือกได้ทั้งเป็น Agent หรือ Harness Agent
• Config LLM Provider ได้ เชื่อม AWS BedRock หรือ Local ก็ได้
• เห็น Use Case ด้วย Observability agent / Incident response agent / debug agent / argo agent เป็นต้น

📌Agent Substrate

เดิมปกติ 1 pod ต่อ 1 agents ซึ่งตอนสนองช้าไป Idea ทำ Worker Pool เพื่อ

• Fast Start มีของรอพร้อมใช้ และสามารถเอาจาก Snapshot ขึ้นมาทำงานได้เลย
• Fast Scale-up & Scale-to-Zero
• Resource Sharing

AI Gateway in the Cloud Native AI Landscape

Speaker Jirayut Nimsaeng

📌Theory

AI Gateway vs API Gateway

• API Gateway เน้นทำเรื่อง Routing, Authentication, Authorization และ Rate limiting ทั่วไป
• ตัว AI Gateway จะเข้ามาเน้นการบริหารจัดการใน 4 แกนหลักคือ การจัดการ Token, การจัดการ API Key/Credential, การจัดการ Backend (โมเดล LLM หลายตัวขนานกัน) และการจัดการข้อมูล Input/Output

คุณสมบัติหลักของ AI Gateway 5 ข้อทาง Gartner ได้กำหนด

1. Access Control: ระบบการควบคุมและยืนยันสิทธิ์เข้าใช้งาน
2. Cost Management / Token Rate Limit: การควบคุมค่าใช้จ่ายและการจำกัดปริมาณการใช้ Token
3. Model Routing: การสลับและเลือกส่ง Requet ไปยังโมเดลที่เหมาะสม
4. Monitoring
5. Security

อย่าง vLLM จะเป็น Inference Engine หรือ Serving Layer ซึ่งมีฟีเจอร์ด้าน Routing หรือ Monitoring บ้าง แต่ยังไม่ถือว่าเป็น AI Gateway เต็มตัวตามนิยามนี้เนื่องจากขาดฟังก์ชันควบคุม Cost หรือ Token ในตัวเอง

Feature ที่ต้องมีสำหรับ AI Gateway เรียกว่าอีกตลาดที่บริษัท Software หลายเจ้าเข้ามาเล่น โดยมี

1. Model Selection (Routing): การสลับและเลือกส่ง Requet ไปยังโมเดลที่เหมาะสม ถ้าสำคัญใช้ที่ Host เอง หรือ ไป Cloud + Prompt Evaluation
2. Billing: Token & Cost Management การ Config Endpoint ของ LLM แต่ละที
3. Caching: เก็บประวัติ Inference ซึ่งจะส่งผลให้เรียกได้รวดเร็วขึ้น และลด Cost
4. Data Enrichment (Input, Output & Transformation): การ Transform ทั้ง Input และOutput เพื่อปรับแต่งคำสั่งให้เข้ากับ Model ปลายทางแต่ละตัว ซึ่งทำได้รวดเร็วด้วย
5. Guardrail (Sensitive Data Blocking): หน้าที่สแกน ตรวจจับ และบล็อก Sensitive Data เพื่อป้องกันข้อมูลสำคัญรั่วไหล
6. Retry & Fallback: ทำซ้ำกี่รอบ หรือให้ไปใช้เจ้่าอื่นเลย
7. Agent Protocol: สำหรับ AI Agent เช่น A2A และการทำหน้าที่ควบคุมสิทธิ์ MCP Gateway
8. Non-LLM Support: เช่น การใช้ Vision Models

นอกจากนี้มีพวก Security - Authentication / Authorization กับ Monitoring

ภาพรวมมี 3 มุม Model LLM Gateway / MCP Gateway / Agent Gateway หลักการคุมให้เกิด Audit Trail มี Governance มีสิทธิที่ชัดเจน ทำอะไรได้ไม่ได้บ้าง ซึึ่งเราต้องมาดู Maturity ตอนนี้ยังใหม่แบบพวก DevOps / DevSecOps และเจ้าเดิมอย่าง API Gateway อาจจะทำส่วนเสริมเข้ามาด้วย เป็นต้น

📌Landscape

CNCF AI Native เป็นตลาดที่ใหม่ ปัจจุบันมีเทคโนโลยี Open Source 77 ตัว และมี AI Gateway อยู่ 6 ตัว อยู่ใน CNCF Sandbox Kgateway / Higress แยกเป็น 3 กลุ่มและกัน

1. Open Source AI Gateway

• Envoy AI Gateway - เป็น Gateway หรือ Service Mesh อื่น ๆ เกือบทั้งหมดนำไปพัฒนาต่อยอด
  จุดเด่น ปรับแต่งโครงสร้างการทำงานได้ลึกและยืดหยุ่นสูง (Config ได้หมดทุกอย่าง) และสามารถเขียน CRD เพื่อควบคุมให้ตัวมันทำงานเป็น AI Gateway ได้
  จุดด้อย ไม่มี UI สำเร็จรูป / ไม่มีฟีเจอร์อย่าง Guardrails
• Agent Gateway - Linux Foundation / Dev Solo Contribute หลาย Project KGateway
  จุดเด่น เขียนขึ้นด้วย ภาษา Rust มี Feature ครบตาม Gartner ได้กำหนด
  จุดด้อย มาใหม่ยังไม่มีใครเอาขึ้น Prod
• KGateway
  จุดเด่น ความพร้อมใช้งาน (Maturity) สูง และปรับตามจาก API GW > AI GW
  จุดด้อย ต่อยอดจาก Envoy CRD Complexity / อยู่ในช่วงลองปรับตัว API GW > AI GW
• Higress - Alibaba Cloud ใข้จริง
  จุดเด่น เนื่องจากเป็นทำระบบครอบ Envoy / Istio / WebAssembly (Wasm) มองเป็นระบบ Plugin ทำให้ต่อยอด เสริมเข้าไปได้ง่าย
  จุดด้อย Doc ภาษาจีน และทำตวามเข้าใจระบบ Plugin สร้าง + Debug
• Volcano Kthene - Huawei
  จุดเด่น Rounting เข้าใน Context KV-Cache / PD Disaggregation ลงบางส่วนได้
  จุดด้อย เพิ่งมา
• MCP Gateway Registry - Community Project ไม่มีบริษัทใหญ่เป็น Back
  จุดเด่น เน้นงาน MCP / Access Control มาครบ
  จุดด้อย Nginx / Fast API / MongoDB อาจจะช้าไ้ และยังไม่มี Rounting / Cost Control

2. Extension ทำที่ให้เป็บ API Gateway ได้ - เน้น Rounting

• Gateway API Inference Extension - อาจจะเป็น Standard Kube ในอนาคต
• llm-d
• vLLM Semantice Rounter

3. AI Gateway - Open Source บางส่วน

• LiteLLM - อันนี้ผมใช้อยู่ ฟังจาก Live 9arm ง่ายดั
• Portkey Gateway - Core Open Source แต่ส่วนอื่นๆ อย่าง Observability / Goverancce เสียเงิน
• 9Rounter - License OK อยู่ เน้นไปมุม Coding

4. อื่นๆ

• API Management + AI Extension - Kong / API6 หรือ ของ Cloud
• AI Platform Build GW - Cloudfare / Vercel

Compare Feature บอกว่ามี ไม่บอก Maturity

📌Choice

เมื่อไหร่ที่ไม่จำเป็นต้องใช้

• ใช้เองคนเดียว
• Flat-rate Subscription หรือใช้งานโดยมนุษย์โดยตรง (Human-only) ไม่ได้ผ่านระบบก็ไม่มีความจำเป็นต้องใช้ AI Gateway ให้สิ้นเปลืองทรัพยากร
• ใช้ API GW อยู่แล้ว รอเค้าพัฒนามา
• ไม่อยากเพิ่ม Hop ให้ช้าลง หรือ ทำ MVP Prototype
• องค์กรยังไม่มีทีม AI Governance ที่ชัดเจน ก็ไม่ควรเพิ่งติดตั้งใช้งานเนื่องจากจะเกิดปัญหางบประมาณและการดูแล

เมื่อไหร่ที่ควรใช้

• องค์กร AI หรือ Agent ที่ Pay-Per-Token / Pay-Per-Use
• ต้องการระบบตรวจสอบ / ความปลอดภัย / Sensitive Data
• หรือจำกัดโควตา Token แยกตามแผนก

📌Demo

Envoy + Backend 2 ตัวคือ LM Studio (Mac) และ DeepSeek ผ่าน API ภายนอก

• Model Routing & Fallback: ตั้งค่า Priority ให้ Router ไปหา LM Studio บนเครื่องก่อน หากระบบช้าหรือ Timeout ระบบจะทำ Fallback ไปที่ DeepSeek อัตโนมัติ
• Token Budget Control: จำกัดการใช้งาน เช่น 30,000 Token ต่อชั่วโมง) ซึ่งเมื่อเกินโควตา ตัว Gateway จะส่งคำสั่ง Block คำขอทันทีและแสดงข้อความแจ้งเตือน เพื่อป้องกัน Cost บวม
• Guardrails: เช่น เลขบัตรประชาชน บัญชีธนาคารไทย หรือเบอร์โทรศัพท์ เพื่อไม่ให้หลุดไปภายนอก ซึ่งฟีเจอร์นี้ต้องทำส่วนเสริมให้ Local ตาม PDPA ของไทยคู่กับ Gateway

Panel Discussion: AI ใน SDLC: ใช้แค่ไหนถึงพอดี 

Speaker Damrongsak Reetanon, Jirayut Nimsaeng, Saritrat Jirakulphondchai, Sharkrit Impat, Natechawin Suthison

📌การใช้ AI ช่วยพัฒนาซอฟต์แวร์ทำให้เร็วขึ้นจริงหรือไม่? (Efficiency & Speed)

• ในช่วง Panel การอ้างอิงงานวิจัยจาก metr.org (2025)ทดสอบเอา AI มาใช้กับ Open Source Dev 16 คนพบว่าทุกคนรู้สึกว่าเร็วขึ้น 24% ผ่านไป 5 เดือน เหลือ 20% แต่การ Tracking Activity (Capture screen/commits) กลับพบว่าช้าลงถึง 19%
• สาเหตุที่ช้า
  - จากงานวิจัย กลุ่มตัวอย่างน้อยเกินไป (เพียง 16 คน) และ model 2025 vs 2026 ละเรื่องเลย
  - นำ AI ไปใช้งานผิดจุด เช่น มีกรณีที่นักพัฒนาใช้ AI ในการเก็บ Requirements แทนที่จะไปคุย User สุดท้ายก็ใช้งานไม่ได้และต้องรื้อทำใหม่
  - ความเร็วขึ้นอยู่กับประสบการณ์ เช่น เรารู้ว่า ถ้าแก้ตรงนี้ในหัวมันมีเส้นทางวิ่งไปหาจุดเแก้ทันที เราเลือกแก้เอง ซึ่งไว้กว่าให้ AI มันหา และเผา Token จนเจอ

📌ใช้ AI แล้วของมันออกมาถูกต้องไหม ?

• AI มันเหมือนคนทำผิดได้ แต่เราจะสอน และ Update ความรู้ยังไง ? / คนต้องมาเพิ่ม Rule Harness
• Context Lost ต้องเข้าใจก่อน มันไม่ได้ฟังเราทั้งหมด จากงานวิจัยบอก ส่วนใหญ่จะแบบ ยาวไปไม่อ่านจำแค่หัว กับส่วนท้าย
• อีกประเด็นที่น่ากลัว Duplicate Code จากปี 2023 ถึง 2026 เพิ่มขึ้นถึง 81% เนื่องจาก AI มันเน้นสร้างใหม่ ไม่ได้มองถึงการ Refactoring
• หาวิธี Verify มันให้ได้

พวก use case น่าจะดูจากอันนเพิ่มได้ สรุป Arise Tech Meetup #10: AI Agents in Action

📌AI ทำ Code Review โดยไม่ต้องมีคนดูได้ไหม

• ต้องมีวิธี Verify มันให้ได้ เช่น เคส Bun จาก zig > rust ต้องมี Test ที่แข็งพอ แต่สุดท้ายยังไม่มี Release ส่วนตัวเคยได้ยินมาว่าลองใน Claue Code อยู่นะ
• Human in the Loop อย่าลืม เพราะงานมันเป็นความรับผิดชอบของเรานะ
• อย่าลืม Code Review นอกจากตรวจเป็นการ Share KM สร้าง Communication / แบ่งปันความรู้ภายในทีม

📌ใช้ AI ทำส่วนไหนใน SDLC มีประสิทธิภาพมากที่สุด

• การเขียน Technical Spec โดยใช้ AI มาช่วยแปลงจาก Business Spec จากฝั่ง PO/PM เพราะ AI สามารถช่วยคิด Edge cases ที่มนุษย์คิดไม่ถึงได้ อย่างใน LMWN เน้น SpecFirst เอา AI มาช่วยหา Edge Case หลังจากคุย Dev QA PO
• Shift Left Security เข้ามาในส่วนอื่นได้ง่าย เช่น Code suggestions ให้ Dev ได้เหมาะสม และเกิดการเรียรรู้
• Testing - เอามาช่วย Gen Test / Chaos Test ทดสอบในเคสที่แย่สุดๆ
• Maintenance & Recovery - เมื่อเกิดปัญหาเราสามารถให้ AI ช่วยหาส่วนที่คาดว่าจะผิด เอา log ส่วนนั้นเตรียมไว้ แล้วให้ human มาเตรียมซ่อมต่อ

📌SDLC Share Agent / Prompt / Skill ระหว่างทีมยังไง

• Share เพื่อ Sync กัน เช่น ทำ Repo กลางในการแชร์ แต่ต้องระวัง AI Slop หรือ เอาจากข้างนอกมาแปะเลย โดยที่ไม่เข้าใจ
• Context Engineer อาจจะเป็นตำแหน่งใหม่ ที่มาช่วยจัดการ ลดความซ้ำซ้อน หรือ หาสิ่งที่ Common เป็นองค์ความรู้กลาง เช่น ทำ Thai writing ให้ได้สำนวนชัดเจน
• ส่วนตัวคิดว่า Session นี้น่าจะตอบโจทย์นะ "Building an Internal Agent Skills Catalog: One MCP, Three IDEs, Zero Drift"

📌ทำให้ทุกคน Prompt ในแบบเดียวกันได้ไหม เพื่อให้ได้ Output เดียวกัน

• ยาก เพราะ LLM Non Detemisnistic

📌ทำอย่างไรให้เขียนโค้ดได้เร็วขึ้นด้วย AI แต่ตัวผู้ใช้ยังเก่งขึ้นด้วย?

• AI เก่งไม่เก่งขึ้นกับคนใช้งาน หากเราต้องการให้ AI ทำงานได้ดี เราต้องเรียนรู้กันและกัน ถามสิ่งที่มันถาม และให้ AI เอ๊ะสิ่งที่มัน หรือ ที่เราทำ
• ถามถึงที่มา และลองตรวจสอบ ทำความเข้าใจ และสุดท้าย ต้องมาดู Fundamental สำคัญที่สุด ถ้า AI มันใช้ไม่ได้ เราแก้เคสไม่ได้เลยนะ
• ถ้าใช้อะไร เข้าใจแนวคิดที่สร้างด้วย
• รู้วิธีการที่ทำให้ได้คำตอบที่ถูกต้อง ตรวจยังไง

ปิดท้ายและ

• ทีมงานหาคนช่วยแปล Doc Kube ภาษาไทย รายละเอียดตามนี้

• มีงานใหญ่ปีหน้า March 2027 - KCD Bangkok

Reference

• https://ocgroups.dev/cncf/group/n5zdgbe/event/zjyt8sr
• Live: https://www.youtube.com/@cloudnativebangkok/videos