RadixAttention ของ SGLang ช่วยลดเวลา warm-up time-to-first-token ลงเหลือเพียง 68 ms บนเครื่องที่ใช้ dual-RTX 3090 ในขณะที่ PagedAttention ของ vLLM ยังคงอยู่ที่ 184 ms ซึ่งเป็นช่องว่างของ latency ถึง 82.9% ที่ช่วยให้การโต้ตอบของ agent แบบ multi-turn รู้สึกลื่นไหลขึ้นอย่างเห็นได้ชัด
ทั้งสองโปรเจกต์พยายามเร่งความเร็วในการทำ inference ของ large language model (LLM) แต่การทดสอบ benchmark นี้มุ่งเป้าไปที่เวิร์กโหลดที่ขับเคลื่อนผู้ช่วยอัจฉริยะ (autonomous assistants) เช่น system prompt ที่ยาว, schema สำหรับการเรียกใช้เครื่องมือ (tool-calling) และประวัติการสนทนาระหว่างผู้ใช้และผู้ช่วยที่ต่อเนื่องกัน (rolling history) โทเคน (tokens) ที่ซ้ำกันเหล่านี้จะถูกเก็บไว้ในหน่วยความจำ GPU หากการจัดการ cache ไม่มีประสิทธิภาพเพียงพอ สิ่งเหล่านี้จะกลายเป็นคอขวดในการประมวลผล (compute bottleneck) ที่ทำให้การสนทนาหยุดชะงัก
เวิร์กโหลดที่เป็นตัวตัดสินความแตกต่าง
เซิร์ฟเวอร์ LLM แบบดั้งเดิมจะปรับแต่งมาเพื่อการแลกเปลี่ยนข้อมูลเพียงครั้งเดียว คือ user prompt, การตอบกลับของโมเดล แล้วก็จบไป อย่างไรก็ตาม agent สมัยใหม่จะรักษา "สถานะการสนทนา" (conversation state) ที่อาจครอบคลุมการโต้ตอบหลายสิบครั้ง ซึ่งแต่ละครั้งจะเพิ่มโทเคนหลายร้อยตัวเข้าไปใน cache ชุดทดสอบนี้ได้จำลองลูปแบบ multi-turn ดังกล่าวบนการ์ด RTX 3090 สองใบ โดยวัดค่าดังนี้:
- Warm time-to-first-token (TTFT) – ความล่าช้าก่อนที่โทเคนแรกจะปรากฏขึ้นหลังจากเริ่มการโต้ตอบครั้งใหม่
- Overall latency – เวลาเฉลี่ยต่อโทเคนตลอดทั้งลูป
- Sustained throughput – จำนวนโทเคนที่มีการประมวลผลต่อวินาทีเมื่อรันลูปอย่างต่อเนื่อง
- Cache-hit ratio – สัดส่วนของโทเคนที่ถูกนำกลับมาใช้ใหม่จาก key-value (KV) cache แทนที่จะต้องประมวลผลใหม่
SGLang เอาชนะ vLLM ได้ในทุกตัวชี้วัด: TTFT ที่ 68 ms เทียบกับ 184 ms, ลด latency ลงได้ 82.9%, มี throughput สูงกว่า 39.8% และมี cache-hit ratio อยู่ที่ 96.8% เมื่อเทียบกับ 84.2% ของ vLLM
PagedAttention vs RadixAttention
ทั้งสอง engine จะเก็บคู่ KV (KV pairs) ระหว่างการประมวลผลไว้ในหน่วยความจำ GPU แต่มีการจัดระเบียบหน่วยความจำที่แตกต่างกัน
- PagedAttention (vLLM) จะแบ่ง cache ออกเป็นบล็อกขนาดคงที่ หาก prompt สิ้นสุดลงกลางบล็อก โทเคนที่เหลือจะต้องถูกประมวลผลใหม่ในทุกๆ ครั้งที่มีการโต้ตอบ เนื่องจากไม่สามารถนำบล็อกมาใช้ใหม่เพียงบางส่วนได้ วิธีนี้มีความเรียบง่ายและใช้งานได้ดีเมื่อ prompt สอดคล้องกับขอบเขตของบล็อก แต่จะทำให้เสียรอบการประมวลผล (cycles) ไปกับโทเคน "ส่วนปลาย" (edge tokens) ที่มีการเปลี่ยนแปลงบ่อยที่สุดในลูปของ agent
- RadixAttention (SGLang) ปฏิบัติต่อ cache ในรูปแบบของ tree โดยจะค้นหา prefix ที่ยาวที่สุดที่มีร่วมกันระหว่าง prompt ปัจจุบันกับสิ่งที่ถูกเก็บไว้ใน cache แล้ว โดยไม่คำนึงถึงข้อจำกัดของบล็อก และทำการตัดกิ่ง (prunes) ที่ไม่ได้ใช้งานออก วิธีนี้ช่วยให้ system prompt ขนาดใหญ่ยังคงถูกตรึงไว้ในหน่วยความจำ GPU ในขณะที่ประมวลผลเฉพาะการโต้ตอบล่าสุดเท่านั้น ซึ่งช่วยเพิ่ม cache-hit ratio และลดการทำงานที่ซ้ำซ้อน
เมื่อไหร่ที่แต่ละ engine จะโดดเด่น
| สถานการณ์ | engine ที่แนะนำ |
|---|---|
| Autonomous agent แบบ multi-turn, การเรียกใช้เครื่องมืออย่างหนัก, การใช้เหตุผลแบบ tree-of-thought | SGLang (RadixAttention) |
| รองรับฮาร์ดแวร์ที่หลากหลาย (รวมถึงตัวเร่งความเร็ว AMD และ Gaudi), speculative decoding, vision-language models | vLLM (PagedAttention) |
ความแตกต่างนี้ไม่ใช่แค่เรื่องประสิทธิภาพเท่านั้น แต่ยังเป็นเรื่องของระบบนิเวศ (ecosystem) ด้วย ความสามารถในการรองรับฮาร์ดแวร์ที่กว้างขวางกว่าของ vLLM ทำให้มันเป็นตัวเลือกเริ่มต้นที่ปลอดภัยกว่าสำหรับองค์กรที่มีคลัสเตอร์การประมวลผลแบบผสมผสาน (heterogeneous compute clusters) นอกจากนี้ ฟีเจอร์ speculative decoding ซึ่งเป็นการสร้างโทเคนที่เป็นไปได้หลายตัวพร้อมกัน ยังสามารถเร่งความเร็วในการสร้างโทเคนแบบ single-turn ซึ่งเป็นจุดที่การทำ caching แบบ tree ของ RadixAttention ให้ข้อได้เปรียบไม่มากนัก
บทสรุป
สำหรับนักพัฒนาที่สร้าง multi-turn agent ซึ่งต้องจัดการกับ prompt ที่ยาวและการอัปเดตข้อมูลแบบเพิ่มทีละน้อย (incremental updates) RadixAttention ของ SGLang มอบประสบการณ์ที่รวดเร็วกว่าอย่างเห็นได้ชัดและใช้ cache ได้อย่างมีประสิทธิภาพมากกว่าบน GPU ระดับผู้บริโภค ส่วนทีมที่ต้องการการรองรับฮาร์ดแวร์ที่ครอบคลุมหรือเชี่ยวชาญด้านการสร้างแบบ single-turn อาจยังคงเลือกใช้ vLLM การตัดสินใจในตอนนี้จึงขึ้นอยู่กับว่าเวิร์กโหลดของคุณเป็นแบบ "เน้น agent" (agent-heavy) หรือ "เน้นความหลากหลายของฮาร์ดแวร์" (hardware-diverse)