สรุปทอล์ก Serving the Agentic Workload ของ Simon Mo: งาน AI agent เปลี่ยนการ serve โมเดลอย่างไร

ช่วงหลังมานี้งานที่วิ่งเข้า inference server หน้าตาเปลี่ยนไปมาก จากแชตถามตอบไม่กี่รอบ กลายเป็น coding agent ที่วน tool call หลายสิบ turn ต่อ session ทอล์ก Serving the Agentic Workload ของ Simon Mo ผู้ร่วมก่อตั้งและ CEO ของ Inferact บริษัทที่ก่อตั้งโดยทีมผู้สร้างและ maintainer ของ vLLM เล่าว่าการเปลี่ยนแปลงนี้กระทบการ serve โมเดลตรงไหน ทีม vLLM แก้อะไรไปแล้ว และจะไปทางไหนต่อ

Simon พูดที่ Runtime 2026 งานคอนเฟอเรนซ์ของ Modal สำหรับวิศวกรที่รัน AI ใน production จัดเมื่อ 1 ตุลาคม 2026 ที่ The Midway ซานฟรานซิสโก วิดีโอทอล์ก ยาวราว 18 นาทีครึ่ง เผยแพร่บนช่อง YouTube ของ Modal เมื่อ 2 พฤศจิกายน 2026

บทความนี้คือสรุปภาษาไทยโดย vLLM Bangkok เรียบเรียงจากวิดีโอและสไลด์ในทอล์ก แล้วตรวจตัวเลขกับบทความต้นทางที่ทีม vLLM และ Inferact เผยแพร่ ส่วนไหนเป็นคำอธิบายหรือความเห็นที่เราเพิ่มเอง จะเขียนกำกับไว้ชัดเจน

เด็คสรุปภาษาไทย 20 สไลด์ของเราเปิดเป็น PDF ได้จากปุ่มด้านล่าง และมีฉบับภาษาอังกฤษอยู่ในบทความภาษาอังกฤษ

เปิด PDF20 หน้า · 0.3 MB

สรุปสั้น (TL;DR)

1. Workload เปลี่ยนไปแล้ว งานของ AI agent อ่าน context ยาวมาก (P50 ราว 142k token) แต่ตอบสั้น (P50 444 token) และวนหลายสิบ turn ต่อ session
2. KV cache คือหัวใจ vLLM รับมือด้วย Hybrid KV Cache ในเครื่องเดียว การแยก prefill กับ decode และ KV cache pool แบบกระจาย เฉพาะ pool แบบกระจายด้วย Mooncake ให้ throughput สูงขึ้น 3.8 เท่าบน Codex agentic traces (1P1D บน GB200 12 ตัว)
3. ปีของ hardware หลากหลาย NVIDIA Blackwell กับ AMD MI355X ให้ performance ระดับ production ได้ทัดเทียมกันแล้ว TPU อยู่เบื้องหลัง Gemini และโมเดลของ Anthropic อยู่แล้ว ส่วนฝั่ง open source ทีม Inferact ทดลองทำ TPU megakernel ได้ 709 tok/s ต่อผู้ใช้กับ Kimi K3 (บน TPU v7 16 ชิป วัดแบบผู้ใช้คนเดียว ใช้ speculative decoding)

ถ้าจะจำประโยคเดียว (ประโยคสรุปของเรา ไม่ใช่คำพูดในทอล์ก): ในยุค agent ความเร็วไม่ได้มาจาก GPU แรงอย่างเดียว แต่มาจากการไม่ต้องคำนวณซ้ำ

Workload เปลี่ยนไปแล้ว

vLLM คือ engine แบบ open source สำหรับ inference และ serving โมเดลภาษา เริ่มจากงานวิจัยระบบ serving ขนาดใหญ่ที่ Sky Computing Lab ของ UC Berkeley (เอกสาร vLLM) Simon เล่าเกร็ดว่า prototype แรกของ vLLM เขียนขึ้นก่อน ChatGPT เปิดตัวเสียอีก ส่วนสไลด์ในทอล์กนับ contributor ของ repository ได้ 3,488 คน (GitHub, กันยายน 2026) และงานที่ engine ต้องรับมือก็เปลี่ยนไปเป็นสามยุค ตามสไลด์ “Workloads are becoming more specialized”

• 2020-2022: single-turn completion ส่ง prompt เข้าไปครั้งเดียว ได้ผลลัพธ์กลับมาครั้งเดียว เช่น autocomplete จาก prompt เดียว API แรกของ vLLM จึงเป็น Completions API ไม่ใช่ Chat API อย่างที่ Simon ว่า “The first vLLM API is not even chat API.”
• 2022-2024: multi-turn chat ต้องแบกประวัติแชตไปทุกรอบ ช่วงกลางปี 2023 ถึง 2024 vLLM จึงสร้าง automatic prefix caching, chunked prefill และ prefill/decode disaggregation ขึ้นมารองรับ
• 2024-2026: agentic + real-time มี tool call, sub-agent และงาน real-time ความซับซ้อนพุ่งขึ้นมาก และนี่คือโฟกัสหลักของ vLLM ในปีนี้

หน้าตาของ 1 session ของ coding agent

ภาพที่เราว่าสำคัญที่สุดในทอล์กคือแผนภาพ session ของ coding agent แต่ละแถวคือหนึ่ง turn แท่งยาวคือ input ที่ส่งเข้าโมเดล (system prompt กับ skills, user input, thinking กับ tool call และ tool result) ชิ้นเล็กท้ายแถวคือคำตอบ Turn 1 ต้อง prefill ใหม่ทั้งหมด Turn 2 ดึงส่วนเดิมจาก cache แล้ว prefill แค่ส่วนที่เพิ่ม พอถึง Turn 43 แทบทั้งแถวเป็น prompt เดิมที่ cache ไว้แล้ว ไม่ต้องคำนวณใหม่ และ tool call เดียวอาจแตกเป็น sub-agent หลาย session ที่รันขนานกันทันที

ตัวเลขข้างแผนภาพ:

• 43 turn ต่อ session (ค่ากลาง)
• 142k token คือ P50 ของความยาว input
• 444 token คือ P50 ของความยาว output
• มากกว่า 95% คือ prefix reuse ตามทฤษฎี หาก cache ไว้ได้ทั้งหมด
• 44% ของ session มี sub-agent อย่างน้อย 1 ตัว ซึ่งมักพุ่งขึ้นมาพร้อมกันเป็นช่วง (bursty)

ตัวเลขชุดนี้มาจากไหน ในทอล์ก Simon เล่าว่าจากประสบการณ์ที่ทีม serve production workload ให้ลูกค้าและสิ่งที่เรียนรู้จากพาร์ทเนอร์ใน ecosystem งาน agentic coding นั้น serve ยากมาก และตัวเลขบนสไลด์ช่วยอธิบายความยากนี้ แต่เขาไม่ได้บอกว่าเป็นตัวเลขจาก traffic ของ Inferact เอง ตัวเลขชุดเดียวกันนี้ปรากฏในบทความ vLLM x AgentX (8 ก.ย. 2026) ของทีม vLLM และ Inferact ซึ่งระบุว่าเป็นสถิติของ SemiAnalysis AgentX อันเป็น benchmark สาธารณะที่สร้างจาก agentic coding traces จริง บทความนั้นเรียกตัวเลข cache hit ว่าเป็นค่าทางทฤษฎี (“a theoretical cache hit rate of more than 96%”) คือสัดส่วน prefix ที่ reuse ได้ถ้า cache ไว้ครบ ไม่ใช่ hit rate ที่วัดได้จาก deployment จริง

อ่าน 142,000 token เพื่อเขียนแค่ 444 token

เอาค่ากลางสองตัวมาหารกัน 142,000 หาร 444 ได้ราว 320 ต่อ 1 ตัวเลขนี้เราคำนวณเอง และเป็นสัดส่วนของค่า P50 สองค่า ไม่ใช่สัดส่วนที่วัดได้จริงในแต่ละ turn ชุด trace อื่นก็ได้ตัวเลขต่างออกไป เช่นชุด Codex/SWE-bench Pro ในบทความ vLLM x Mooncake มีสัดส่วน input ต่อ output เฉลี่ยราว 131 ต่อ 1

ไม่ว่าจะตัวเลขไหน ข้อสรุปเหมือนกัน คือทุก turn ระบบต้อง “อ่าน” context ยาวๆ ซ้ำ แต่ “เขียน” ออกมานิดเดียว เปรียบเหมือนนักบัญชีที่ต้องเปิดแฟ้มหนาหลายร้อยหน้าอ่านใหม่ทุกครั้ง ก่อนจะเขียนโน้ตหนึ่งบรรทัด ถ้าจำสิ่งที่อ่านไปแล้วได้ งานก็เร็วขึ้นมหาศาล สไลด์ของ Simon สรุปไว้ว่า “Every call replays the full context, so KV cache reuse carries the load.” นี่คือเหตุผลที่ทั้งทอล์กวนอยู่กับเรื่อง KV cache

ปูพื้นก่อนไปต่อ: prefill, decode และ KV cache

ส่วนนี้เป็นคำอธิบายพื้นฐานที่เราเพิ่มเอง ไม่ได้อยู่ในทอล์ก

• Prefill หรือ “อ่านโจทย์ทั้งหมด” โมเดลประมวลผล input ทั้งก้อน ทั้ง prompt ประวัติ และผลลัพธ์จาก tool ขั้นนี้หนักที่ compute และเป็นตัวกำหนด TTFT (time to first token) คือผู้ใช้ต้องรอนานแค่ไหนกว่าจะเห็นคำแรก
• Decode หรือ “เขียนคำตอบทีละ token” โมเดลสร้าง thinking และ action ถัดไปทีละ token ขั้นนี้มักติดที่ memory bandwidth (โดยเฉพาะตอน batch เล็ก) และเป็นตัวกำหนดความลื่น หรือ tok/s ต่อผู้ใช้
• KV cache หรือ “สมุดโน้ตที่จดไว้ตอนอ่าน” คือผลคำนวณ (key และ value ของ attention) ของ token ที่ผ่านมาแล้ว ทั้งจาก prefill และ decode ถ้า turn ถัดไปขึ้นต้นด้วย prefix เดิม ก็ดึงของเดิมมาใช้ได้โดยไม่ต้องคำนวณใหม่ เรียกว่า prefix cache hit

ปัญหาคือสมุดโน้ตเล่มนี้ใหญ่และกินหน่วยความจำ GPU มาก ยิ่ง context ยาวและผู้ใช้เยอะ ยิ่งต้องบริหารเก่ง ใครอยากปูพื้นเรื่อง KV cache กับ PagedAttention ให้แน่นกว่านี้ อ่านต่อได้ที่บทความ vLLM คืออะไร ของเรา

ยากตรงไหน: 3 โจทย์ของการ serve agent

ลองเอาภาพ session ข้างบนมาคูณด้วยผู้ใช้หลักร้อยหลักพันคน นั่นคือสิ่งที่ serving engine ต้องรับ บาง session ร้อน บาง session เย็น บางอัน 10 turn บางอัน 100 turn บาง tool result ยาว 100k token แล้วทั้งหมดต้อง multiplex เข้าด้วยกันให้ได้ Simon สรุปโจทย์ไว้สามข้อ

1. Prefix cache pressure ทุกครั้งที่ agent เรียกโมเดล มันส่ง context ทั้งหมดซ้ำ ภาระจึงตกอยู่ที่การ reuse KV cache ให้ได้มากที่สุด ถ้า reuse ไม่ได้ก็ต้องคำนวณใหม่หมด
2. Execution efficiency แต่ละ step มี token ให้ประมวลผลมากขึ้นเรื่อยๆ แต่ยังต้องอยู่ใน latency budget และ SLA ที่ตึงเท่าเดิม
3. Global routing เมื่อมีหลายเครื่อง จะส่ง session ไปเครื่องที่มี cache อยู่แล้ว (cache affinity) หรือกระจายโหลดให้เท่ากัน (load balance) สองอย่างนี้ต้องแลกกัน โดยเฉพาะตอนที่ sub-agent พุ่งขึ้นมาพร้อมกัน

vLLM แก้โจทย์นี้อย่างไร

Simon เล่าทางแก้เป็นชั้นๆ เริ่มจากจัดการ KV cache ในเครื่องเดียว แล้วขยายไปทั้ง cluster ก่อนจะจบที่วิธีวัดผล

Hybrid KV Cache: page ขนาดเดียวสำหรับทุก attention

PagedAttention ซึ่งเป็นแกนของ vLLM มาตั้งแต่แรก ออกแบบมาสำหรับโมเดล dense แต่ช่วงหลังมีโมเดล hybrid attention และ sparse attention ออกมาเยอะมาก และแต่ละ layer ของโมเดลต้องการ KV cache คนละแบบ

• Full attention cache โตตามจำนวน token
• Sliding window จำแค่ช่วงล่าสุด ขนาดคงที่ต่อ request
• Linear attention เป็น state ขนาดคงที่ แต่เป็นก้อนใหญ่

ทางออกของ vLLM คือ Hybrid KV Cache Allocator ที่เลือกขนาด page เป็นตัวคูณร่วมน้อย (LCM) ของขนาดที่แต่ละแบบต้องการ บนสไลด์เขียนว่า page size = LCM(X, Y, Z) ทุกชนิดจึงอยู่ใน page pool เดียวกัน และ page ที่ว่างหยิบไปใช้สลับกันได้ เหมือนตู้คอนเทนเนอร์มาตรฐานที่ของต่างขนาดจัดลงตู้เดียวกันได้ แนวคิดนี้ตรงกับงานวิจัย Jenga (Simon พูดถึงแค่ “a paper” ที่ทีมเริ่มเขียนช่วงปี 2024-2025 โดยไม่ได้เอ่ยชื่อ การโยงไปที่ Jenga เป็นของเราเอง) ซึ่งใช้ LCM ของขนาด embedding มาจัดสรรหน่วยความจำ ส่วนรายละเอียดใน vLLM ปัจจุบันดูได้ที่เอกสาร Hybrid KV Cache Manager ซึ่งอธิบายว่าทุกชนิด layer ใช้ memory pool เดียวกัน โดยทุก block มี page size เท่ากัน

ผลใน production ตามที่ Simon เล่าคือ “we’re seeing typically 2x or 2.5x more KV cache space that’s getting freed up” ได้พื้นที่ KV cache คืนมาราว 2 ถึง 2.5 เท่า ชิปเดียวจึงรับผู้ใช้พร้อมกันได้มากขึ้น ทั้ง throughput และต้นทุนดีขึ้นตาม ตัวเลขนี้เป็นคำพูดบนเวที ไม่ได้อยู่บนสไลด์หรือใน benchmark ที่เผยแพร่

แยก prefill กับ decode

เมื่อจัดการ cache ในเครื่องได้ดีแล้ว โจทย์ถัดไปคือทั้ง cluster Simon พูดไว้ตรงๆ ว่า

“Nobody is serving production agentic workload on an aggregated inference setup.”

แบบ aggregated คือ server เครื่องเดียวทำทั้ง prefill และ decode ซึ่ง Simon บอกว่า “it delivers inconsistent performance” ถ้ามี prefill ก้อนใหญ่เข้ามาเยอะ thinking ที่กำลัง stream อยู่จะสะดุดหรือช้าลงกลางทาง ถ้ามี decode request มากเกินไป ก็แทรก prefill เข้าไปไม่ได้ TTFT แย่ลงทันที

ทางออกคือ disaggregated serving แยก prefill instance กับ decode instance ออกจากกัน แล้วมี KV cache pool แบบกระจายเชื่อมตรงกลาง Simon บอกว่าในปี 2026 นี่คือ “the only way to go for large scale inference and production inference” เมื่อสองขั้นไม่ต้องแย่งเครื่องกัน latency ก็สม่ำเสมอขึ้น ตรงกับงานวิจัย DistServe ที่แยกสองขั้นออกจากกันเพื่อตัดการรบกวนระหว่าง prefill กับ decode

ข้อสังเกตเพิ่มของเรา (ไม่ได้อยู่ในทอล์ก): อีกข้อดีของการแยกคือขยายแต่ละฝั่งได้อิสระตาม workload DistServe จัดสรรทรัพยากรและ parallelism แยกให้แต่ละขั้น และบทความ vLLM x AgentX ก็หาสัดส่วน prefill ต่อ decode จากจุดอิ่มตัวของแต่ละ configuration เพราะสัดส่วนที่ดีที่สุดเปลี่ยนไปตาม concurrency

KV cache pool แบบกระจายด้วย Mooncake

vLLM มี native integration กับ framework และผู้ให้บริการภายนอกหลายตัว ตัวอย่างที่ Simon ยกคือ Mooncake connector (Mooncake คือแพลตฟอร์ม serving ของ Kimi จาก Moonshot AI) แผนภาพบนสไลด์แบ่งเป็นสามชั้น

• Control plane scheduler ของแต่ละ vLLM instance ถาม (lookup) Mooncake Master ซึ่งทำหน้าที่เหมือนสารบัญกลาง เก็บ metadata ว่า KV block ของ prefix ไหนอยู่ที่ใด
• Execution plane แต่ละ vLLM instance มี vLLM Worker กับ Mooncake Client อยู่ข้าง GPU HBM และส่งข้อมูลผ่าน GPUDirect
• Data plane คลัง KV cache กลางที่กระจายอยู่บน host DRAM และ NVMe SSD เชื่อมกันด้วย RDMA fabric

คิดแบบง่ายๆ คือ KV cache ไม่ต้องติดอยู่ใน GPU เครื่องเดียวอีกต่อไป เครื่องไหนเคยคำนวณ prefix ไว้ อีกเครื่องก็ดึงไปใช้ได้

บนสไลด์ผลคือ throughput สูงขึ้น 3.8 เท่า และ TTFT ต่ำลง 46 เท่า บริบทของตัวเลขนี้อยู่ในบทความ vLLM x Mooncake: รัน Kimi-2.5 แบบ NVFP4 (ตามชื่อที่บทความใช้) ตั้งค่า 1P1D คือ prefill instance หนึ่งตัวกับ decode instance หนึ่งตัว บน GB200 12 ตัว ใช้ agentic traces จริงจาก Codex/SWE-bench Pro 610 รายการ เทียบกับ baseline ที่ cache แค่ system prompt ผลคือ cache hit rate ขึ้นจาก 1.7% เป็น 92.2% throughput สูงขึ้น 3.8 เท่า P50 TTFT ต่ำลง 46 เท่า และ E2E latency ต่ำลง 8.6 เท่า

สองข้อที่ควรรู้ ข้อแรก 3.8 เท่าเป็นผลของ KV cache pool แบบกระจายในชุดทดสอบนี้ ไม่ใช่ผลรวมของทุกเทคนิคในบทความนี้ ข้อสอง ชุดทดสอบนั้นใช้ CPU DRAM เป็นที่เก็บ cache ส่วนชั้น NVMe SSD ที่เห็นในแผนภาพ ตอนบทความออก (พฤษภาคม 2026) ยังอยู่ในหัวข้อ “What’s next” และเพิ่มเข้ามาภายหลัง

อ่านกราฟ throughput ต่อชิป กับ interactivity

Simon เล่าว่าผลของทุกอย่างข้างบนสะสมออกมาให้เห็นใน benchmark ของ SemiAnalysis ซึ่งเป็นสนามวัดผลกลางที่ทีม vLLM ทำงานร่วมกับพาร์ทเนอร์ hardware อย่าง NVIDIA, AMD และ Google เขาออกตัวเองว่า “This is actually a very messy chart” เลยขอสรุปวิธีอ่านไว้ตรงนี้

• แกนตั้ง throughput ต่อชิป คือ token ต่อวินาทีที่ GPU ทั้งตัวผลิตได้ ใช้วัดความคุ้มค่า
• แกนนอน interactivity คือ token ต่อวินาทีที่ผู้ใช้แต่ละคนได้รับ (P90)
• เส้นในกราฟคือ Pareto frontier “A Pareto frontier means you cannot get to the top right.” จะเอาทั้งคุ้มสุดและเร็วสุดพร้อมกันไม่ได้ มุมซ้ายบนคือการตั้งค่าที่ประหยัดสุด ได้ throughput สูง มุมขวาล่างคือเร็วสุด หรือในคำของ Simon “you can just throw the GPU just for that single user”
• ทุกจุดบนเส้น คือการตั้งค่าหนึ่งแบบ (parallelism, batch, kernel) ที่รวมเทคนิคข้างบนเข้ากับการ optimize ระดับ kernel

งานของ vLLM คือดันทั้งเส้นออกไปทางขวาบนให้มากที่สุด แล้วให้ผู้ใช้เลือกจุดไหนบนเส้นก็ได้ตามงาน

กราฟจริงในทอล์กมาจาก SemiAnalysis InferenceX ชื่อ “Kimi K3 2.8T Agentic Token Throughput per Chip vs. P90 Interactivity” อัปเดตเมื่อ 21 กันยายน 2026 เปรียบเทียบ NVIDIA GB300 NVL72, GB200 NVL72, B200, B300 และ AMD MI355X โดยในกราฟมีทั้งชุดข้อมูลที่ติดป้าย vLLM และ Dynamo ปนกันอยู่

ก้าวต่อไป: agentic-first, agentic-efficient, agent-friendly

Simon แบ่งงานต่อจากนี้ของ vLLM เป็นสามทาง

Agentic-first เพิ่ม agent/session hints และทำ programmable KV cache ที่ตั้ง TTL ตั้ง priority และกำหนดได้ว่า cache ควรอยู่ที่ไหน ตัวอย่างที่ Simon ยกคือ “a session that you know you’re not going to touch for an hour” เช่นงานที่รู้อยู่แล้วว่าจะรันไปอีกชั่วโมง ควร pin session นั้นไว้ ปล่อยให้นโยบาย LRU ตัดสิน หรือ evict ทิ้งไปเลย ใน roadmap ไตรมาสสี่ของ vLLM ก็มีงานในทิศนี้ เช่นขยาย agent hints ไปถึง router และ KV connector, TTL ของแต่ละชั้น cache และการคุม prefetch กับ eviction ระดับ request

Agentic-efficient ลด latency ให้ต่ำมาก (ultra-low latency) ด้วย speculative decoding และประสิทธิภาพของ engine พร้อมทำให้ scale และกู้คืนได้ทันที (instant scaling and recovery) รวมถึง fault tolerance เป้าหมายคือ “you can pick any points on the Pareto curve and it’ll automatically run in production for you” Simon บอกว่าส่วนนี้มาจากประสบการณ์รัน vLLM ขนาดใหญ่ที่ Inferact

Agent-friendly ทำ interface และ infra ให้ agent ช่วยพัฒนา vLLM เอง ช่วงปีที่ผ่านมาทีมใช้โมเดลที่ serve ด้วย vLLM มา optimize ระบบ vLLM เป็น loop ปิด พร้อม agentic evaluation

ปีของ hardware heterogeneity

Simon ประกาศว่าปีนี้คือปีของ hardware heterogeneity เหตุผลแรกคือ parity of chips: NVIDIA Blackwell กับ AMD MI355X มี spec และหาซื้อได้ใกล้เคียงกันแล้ว ได้ hardware ระดับ data center มาก็ได้ performance ระดับ production จริง และปีนี้เขาได้ยินว่าผู้ใช้ vLLM รายใหญ่ deploy บน AMD มากขึ้นเรื่อยๆ บทความ Kimi K3 บน MI355X ของ AMD และ Embedded LLM บนบล็อก vLLM ยืนยันภาพนี้ว่า MI355X กับ B300 มี HBM3E 288 GB และ bandwidth 8 TB/s เท่ากัน

Inferact และ vLLM เป็นพาร์ทเนอร์กับทั้ง NVIDIA, AMD และ Google และแต่ละค่ายมีบุคลิกต่างกัน

• NVIDIA Blackwell (B200, GB200, GB300) ในคำของ Simon: “NVIDIA, general purpose, well designed, battle tested.”
• AMD Instinct MI355X ชูขนาด HBM ที่ใหญ่ (288 GB)
• Google TPU v7 Ironwood มี systolic array ขนาดใหญ่ที่โปรแกรมได้ และ VMEM ที่ใหญ่และโปรแกรมได้มากกว่า TPU อยู่เบื้องหลังโมเดลของ Anthropic และ Gemini ของ Google ใน production อยู่แล้ว

คำถามของ Simon คือ แล้วฝั่ง open source ใช้ TPU ได้แค่ไหน ทีม Inferact จึงทดลองสร้าง TPU megakernel เพื่อดูว่า TPU พิเศษตรงไหน

TPU megakernel: 709 tok/s ต่อผู้ใช้

ผลบนสไลด์ “First TPU Megakernel: 709 tok/s/user”

• Kimi K3 709 tok/s ต่อผู้ใช้บน TPU v7 16 ชิป (TPU megakernel) เทียบกับ 452 บน GB200 16 ตัว (vLLM baseline)
• Qwen 3.8 27B 1,515 tok/s ต่อผู้ใช้บน TPU v7 4 ชิป เทียบกับ 695 บน GB200 4 ตัว

คิดเป็นเร็วกว่า baseline ราว 1.6 และ 2.2 เท่า (เราคำนวณเองจากตัวเลขบนสไลด์) แต่ก่อนเอาตัวเลขนี้ไปใช้ ควรรู้บริบทให้ครบ

• ตัวเลข Kimi K3 เป็นการวัดของ Inferact เอง แบบผู้ใช้คนเดียว ใช้ speculative decoding (DSpark ที่ acceptance length 6) บทความ 700 TPS on Kimi K3 ของ Inferact เขียนว่า “over 700 tokens/s with speculative decoding, compared with 452 tokens/s on GB200” โดย baseline คือ recipe Kimi K3 ที่ vLLM เผยแพร่ บน GB200 16 ตัว และกราฟ acceptance length ในบทความแสดงว่า baseline บน GB200 ก็ใช้ DSpark speculative decoding เช่นกัน (452 tok/s ที่ acceptance length 6 และ 229 ที่ acceptance length 3)
• ตัวเลขของ Qwen (1,515 กับ 695 บน 4 ชิปต่อฝั่ง) ไม่ได้อยู่ในเนื้อความของบทความ แต่อยู่ในกราฟแรกของบทความ Inferact (ใช้ speculative decoding ที่ acceptance length 6 เช่นกัน) ซึ่งระบุว่าเร็วกว่า 2.18 เท่า
• ถ้าไม่ใช้ speculative decoding บทความของ Inferact รายงานว่า megakernel ของทั้ง Kimi K3 และ Qwen 3.8 27B ให้ decode throughput ราว 1.4 ถึง 2 เท่าของ GB200 baseline ที่ batch size 1 ถึง 8 ตัวเลข 1.6 กับ 2.2 เท่าจึงเป็นกรณีดีที่สุดต่อผู้ใช้หนึ่งคน ไม่ใช่ speedup ทั่วไป
• Inferact เรียกงานนี้ว่า “a first step” และบอกว่าเท่าที่รู้ นี่คือ open-source inference megakernel ตัวแรกที่เขียนด้วย Pallas ส่วน Google Developers Blog ก็รายงานตัวเลขระดับเดียวกัน คือมากกว่า 700 token ต่อวินาทีต่อผู้ใช้หนึ่งคนบน Ironwood

Simon ย้ำว่านี่ไม่ใช่การ bench-max เพื่อโชว์ตัวเลข (“this is not just like benchmarking”) แต่ “What we’re trying to do here is really to understand the core differences between each hardware.”

VMEM prefetching ได้อะไร

Megakernel คือการเขียน kernel ตัวเดียวให้ดูแลการ decode ทั้ง step ทั้ง 92 MoE layer ของ Kimi K3 รันอยู่ใน Pallas call เดียว แบบเดิมที่แยก kernel ทีละขั้น ต้องโหลด weight จาก HBM ให้เสร็จก่อนจึงคำนวณ แล้วค่อย store ต่อกันเป็นทอดๆ ระหว่างรอ bus ก็ว่าง และเป็นแบบนี้หลายร้อยรอบต่อ step

TPU มี VMEM ซึ่ง Simon เทียบว่าคล้าย shared memory บน GPU แต่ใหญ่กว่าและโปรแกรมได้มากกว่า megakernel จึง prefetch weight ของ attention และ MoE ของ layer ถัดไปขึ้นชิปไว้ล่วงหน้า ระหว่างที่ยังคำนวณ layer ปัจจุบันอยู่ งานจึงซ้อนกันเป็น pipeline เหมือนเชฟที่หั่นวัตถุดิบจานต่อไประหว่างผัดจานนี้ Simon บอกว่า pipeline แบบนี้ยังทำไม่ได้ในวันนี้ด้วย PDL ของ NVIDIA

บทเรียน: premature abstraction is bad

บทเรียนทางเทคนิคที่ Simon บอกว่าทีมเรียนรู้เองคือ “this idea of premature abstraction, right, is bad.”

ช่วงปี 2024-2025 ทีม abstract interface ของ kernel และ model ให้เป็นชั้นกลางร่วมกัน เพื่อรวมทุกอย่างให้ง่าย เพราะ vLLM ต้องรองรับ model architecture หลายพันแบบและ hardware หลายร้อยแบบ แต่ปีนี้ทีมพบว่าถ้าอยากได้ performance สุดขีด ต้องแยกออก: “every single model is getting their own file, their own kernel, and their own essentially inference engine.” โดยยังมี vLLM เป็น core runtime ร่วมกัน พูดอีกแบบคือสร้าง inference engine เฉพาะสำหรับแต่ละโมเดล บนแต่ละ hardware สำหรับแต่ละ workload

ควบคู่กันคือให้ agent เขียน kernel มากขึ้น ดึง kernel ล่าสุดจากทีม hardware ทุกค่ายเข้ามา และเก็บโครงสร้างโมเดลให้ flat ซึ่งใน roadmap ก็มีงานย้ายโค้ดโมเดลของ speculative decoding ไปเป็น Flat Model (SIG Spec Decode)

vLLM Q4 roadmap: agentic production serving

สไลด์ “vLLM Q4 Roadmap: Agentic Production Serving” ในทอล์กแบ่ง roadmap ไตรมาสสี่ปี 2026 เป็นสี่ด้าน (ส่วน GitHub issue #61024 ที่เปิดเมื่อ 10 ตุลาคม 2026 ลงรายละเอียดเป็นรายกลุ่ม SIG ไม่ได้แบ่งเป็นสี่ด้านนี้)

• Production agentic workloads และ large-scale serving
• Performance model performance ซึ่งรวมถึงให้ agent ช่วยเขียน kernel และ speculative decoding ที่ Simon บอกว่ายังเป็นวิธีหลักในการลด latency และใช้ hardware ให้คุ้มในงานที่ concurrency ต่ำ
• Refinement ปรับโครงสร้าง KV cache (KV cache refactoring) และดูแล CI/release ให้ vLLM เสถียรและปลอดภัย
• Ecosystem hardware support (รวมถึง hardware รุ่นใหม่อย่าง Rubin และ MI455X) งาน RL และ vLLM-Omni สำหรับโมเดล omni-modal

ทุกหัวข้อมี working group (SIG) ที่เปิดให้ทุกคนเข้าร่วมและ contribute และนัดประชุมอยู่บน public vLLM calendar Simon ยอมรับตรงๆ ว่า “We never found a harder problem to work on than keeping the project at this scale sustainable and useful for everybody.”

Simon ปิดทอล์กด้วยการชวนมาร่วม community ที่มี contributors มากกว่า 3,000 คน เริ่มสร้างได้จาก docs.vllm.ai ติดตามบทความเชิงลึกที่ vllm.ai/blog และร่วม contribute ที่ github.com/vllm-project/vllm

นำไปใช้กับทีมที่รันโมเดลเอง

ส่วนนี้เป็นข้อคิดของเรา ไม่ได้อยู่ในทอล์ก

1. วัด workload จริงก่อน ดูสัดส่วน input ต่อ output จำนวน turn และ prefix cache hit rate ของงาน agent ที่ใช้อยู่ ตัวเลขของคุณอาจต่างจากชุด trace ในทอล์กมาก
2. ทำ prefix ให้นิ่ง วาง system prompt, tool definition และเอกสารคงที่ไว้ต้น context เพราะ prefix caching ใช้ได้เฉพาะเมื่อลำดับ token ส่วนต้นเหมือนเดิมทุกตัว และอย่าใส่ timestamp หรือค่าที่เปลี่ยนทุก request ไว้ใน system prompt
3. เลือกจุดบน Pareto ให้ตรงงาน งาน batch เบื้องหลังเน้น throughput ต่อชิป งานที่มีคนนั่งรอเน้น tok/s ต่อผู้ใช้ สองแบบนี้ตั้งค่า serving ต่างกัน
4. วางแผนขยายข้ามเครื่อง เมื่อโตเกินหนึ่งโหนด พิจารณาแยก prefill/decode และใช้ KV cache connector เช่น Mooncake หรือ connector อื่น (NIXL ฯลฯ) ข้อนี้เห็นผลชัดเมื่อระบบใหญ่พอ

แหล่งที่มาและอ้างอิง

1. Serving the agentic workload | Simon Mo CEO at Inferact, Runtime 2026 — Modal (YouTube), 2 พ.ย. 2026. แหล่งหลักของเนื้อหาทอล์ก คำพูดที่ยกมา และตัวเลขบนสไลด์ทั้งหมด
2. Runtime Recap — Modal, 1 ต.ค. 2026 (วันจัดงาน). วันที่ สถานที่ และลักษณะของงาน Runtime 2026
3. [Roadmap] vLLM Roadmap Q4 2026 — vllm-project/vllm บน GitHub (issue #61024), 10 ต.ค. 2026. agent hints, TTL ของ cache แต่ละชั้น, Flat Model (SIG Spec Decode), Rubin และ MI455X, vLLM-Omni และแผนงานแยกตาม SIG ที่นัดประชุมบน public vLLM calendar (สี่ด้านของ roadmap มาจากสไลด์ในทอล์ก)
4. Hybrid KV Cache Manager — เอกสาร vLLM, เข้าถึงเมื่อ 4 พ.ย. 2026. memory pool เดียวและ page size เท่ากันสำหรับทุกชนิด layer
5. Jenga: Effective Memory Management for Serving LLM with Heterogeneity — arXiv 2503.18292, 24 มี.ค. 2025. การจัดสรรหน่วยความจำด้วย LCM ของขนาด embedding
6. Serving Agentic Workloads at Scale with vLLM x Mooncake — vLLM Blog, 6 พ.ค. 2026. throughput 3.8 เท่า, P50 TTFT 46 เท่า, E2E latency 8.6 เท่า, บริบทของ benchmark, สถาปัตยกรรม Mooncake และสัดส่วน input ต่อ output ราว 131 ต่อ 1
7. kvcache-ai/Mooncake — GitHub (kvcache-ai), เข้าถึงเมื่อ 4 พ.ย. 2026. Mooncake คือแพลตฟอร์ม serving ของ Kimi, distributed KV cache, RDMA และ cache หลายชั้นบน DRAM และ SSD/NVMe
8. vLLM x AgentX: Optimizing for Real-World Agentic Serving — vLLM Blog (vLLM Team และ Inferact), 8 ก.ย. 2026. ที่มาของตัวเลข 43 turn, 142k, 444, prefix reuse และ 44% (สถิติจาก SemiAnalysis AgentX) รวมถึงการหาสัดส่วน prefill ต่อ decode จากจุดอิ่มตัว และชั้น cache บน disk/NVMe ที่เพิ่มเข้ามาภายหลังบทความ vLLM x Mooncake
9. AI Accelerator System Benchmark | AcceleratorX by SemiAnalysis — SemiAnalysis (หัวเว็บใช้ชื่อ InferenceX), เข้าถึงเมื่อ 4 พ.ย. 2026. แดชบอร์ด benchmark ที่เป็นที่มาของกราฟ Pareto ส่วนกราฟฉบับ 21 ก.ย. 2026 อ้างจากสไลด์ในทอล์ก
10. Scaling Kimi K3 on AMD Instinct MI355X: Matching NVIDIA HGX B300 Throughput per GPU on AgentX — vLLM Blog (AMD และ Embedded LLM), 16 ต.ค. 2026. HBM3E 288 GB และ 8 TB/s ของ MI355X และ B300
11. 700 TPS on Kimi K3: A Case for TPU Megakernels — Inferact News, ก.ย. 2026. ตัวเลขกว่า 700 เทียบ 452 tok/s และเงื่อนไข speculative decoding ของทั้งสองฝั่ง, ตัวเลขของ Qwen ในกราฟแรก, ราว 1.4 ถึง 2 เท่าเมื่อไม่ใช้ speculative decoding, 92 MoE layer ใน Pallas call เดียว และการ prefetch ข้าม layer
12. Announcing New vLLM and SGLang Inference Engines on TPU — Google Developers Blog, 20 ต.ค. 2026. TPU Ironwood และ megakernel ของ Kimi K3 ที่ได้มากกว่า 700 token ต่อวินาทีต่อผู้ใช้หนึ่งคน
13. Efficient Memory Management for Large Language Model Serving with PagedAttention — arXiv 2309.06180 (SOSP 2023), 12 ก.ย. 2023. การออกแบบ PagedAttention ดั้งเดิมสำหรับโมเดล dense
14. Welcome to vLLM — เอกสาร vLLM, เข้าถึงเมื่อ 4 พ.ย. 2026. vLLM เริ่มพัฒนาที่ Sky Computing Lab ของ UC Berkeley และช่องทาง Build ที่ Simon ชวนไป
15. Blog | vLLM — vLLM, เข้าถึงเมื่อ 4 พ.ย. 2026. ช่องทาง Learn ที่ Simon ชวนไปติดตาม
16. vllm-project/vllm — GitHub, เข้าถึงเมื่อ 4 พ.ย. 2026. นิยามของ vLLM ในฐานะ inference และ serving engine และช่องทาง contribute
17. Inferact | Frontier Inference You Control — Inferact, เข้าถึงเมื่อ 4 พ.ย. 2026. Inferact คือบริษัทที่ก่อตั้งโดยผู้สร้างและ maintainer ของ vLLM
18. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving — arXiv 2401.09670, 18 ม.ค. 2024. การแยก prefill กับ decode เพื่อตัดการรบกวนกัน และการจัดสรรทรัพยากรแยกให้แต่ละขั้น

ดูต่อ

• Serving vLLM on Agentic Production Workloads | Inferact | Ray Summit 2026 — Anyscale (YouTube), 17 ก.ย. 2026
• vLLM and the State of AI Inference | Simon Mo (Inferact) | Ray Summit 2026 — Anyscale (YouTube), 17 ก.ย. 2026
• หน้าสรุป Ray Summit 2026 Recap ของเรา รวมสไลด์จากงาน recap ที่กรุงเทพฯ เมื่อ 24 ตุลาคม 2026

บทความนี้เป็นสรุปจาก community โดย vLLM Bangkok คำพูดที่ยกมาเป็นของทอล์กต้นฉบับ เว้นแต่ระบุแหล่งอื่นไว้ หากพบข้อผิดพลาด แจ้งเราได้ทางช่องทางติดต่อบนเว็บไซต์