vLLM ทำคะแนนได้ดีกว่า SGLang ในการประมวลผล prompt ขนาด 64K tokens แต่ SGLang กลับแซงหน้าเมื่อ context สูงถึง 200K บนเซิร์ฟเวอร์ 8-GPU B300 การเปลี่ยนแปลงนี้แสดงให้เห็นว่าเมื่อหน้าต่าง token ขยายใหญ่ขึ้น คอขวดในขั้นตอนการ decode (decode-stage) ไม่ใช่ขั้นตอน prefill ต่างหากที่เป็นตัวกำหนดประสิทธิภาพ
ทำไมการทดสอบนี้ถึงสำคัญ
การประมวลผลแบบ long-context เป็นตัวขับเคลื่อนต้นทุนสำหรับ chat assistants, code assistants และแอปพลิเคชันใดๆ ที่ต้องเก็บ token จำนวนหลายแสนไว้ในหน่วยความจำ Kimi-K3 ซึ่งเป็นโมเดลที่มีพารามิเตอร์ขนาดใหญ่ เป็นหนึ่งใน open-weight LLM รุ่นแรกๆ ที่สามารถจัดการกับ context window ขนาดใหญ่เช่นนี้ได้อย่างราบรื่น แต่ engine ที่ใช้รันโมเดลจะเป็นตัวตัดสินว่าคำขอจะเสร็จสิ้นภายในไม่กี่วินาทีหรือหลายนาที
ทั้ง vLLM และ SGLang ต่างก็สัญญาว่าจะให้การประมวลผลแบบ high-throughput inference แต่ทั้งคู่มีแนวทางที่ตรงกันข้ามในขั้นตอนการ decode โดย vLLM จะรักษาเส้นทางการ decode ให้เรียบง่าย เพื่อหลีกเลี่ยงการทำ synchronization ส่วนเกินที่เกิดจาก Decode Context Parallelism (DCP) ในขณะที่ SGLang จะกระจายการอ่าน key-value (KV) cache ไปยัง GPU หลายตัวโดยใช้ DCP ซึ่งเป็นเทคนิคที่ช่วยเฉลี่ยการใช้งาน memory bandwidth แต่ต้องแลกมาด้วยการสื่อสาร (communication) ที่เพิ่มขึ้น
สภาพแวดล้อมการทดสอบ
- Hardware: เซิร์ฟเวอร์เดี่ยวที่ใช้ NVIDIA B300 GPU จำนวนแปดตัว โดยแต่ละตัวมีหน่วยความจำที่เหมือนกัน
- Workloads: การตั้งค่าความยาว context สองระดับ คือ 64K tokens (ขอบเขตล่างของ "long context") และ 200K tokens (ขอบเขตบนที่งานวิจัยจำนวนมากมุ่งเป้าไปถึง)
- Metrics: เวลาทั้งหมดที่ใช้ในการประมวลผล batch ของ prompt ที่กำหนด โดย throughput คำนวณจากส่วนต่างของเวลา
เรากำหนดให้ batch size, น้ำหนักของโมเดล (model weights) และเป้าหมายการใช้หน่วยความจำ (memory-utilization targets) คงที่ สิ่งเดียวที่เราเปลี่ยนระหว่างการทดสอบคือ inference engine
ตัวเลขที่ได้จากการทดสอบ
| Context | Engine | Time (s) | Relative speed |
|---|---|---|---|
| 64 K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ 1.5× เร็วกว่า | |
| 200 K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ 1.31× เร็วกว่า |
Throughput (tokens ต่อวินาที) ของ vLLM ลดลงอย่างมากเมื่อ context เพิ่มขึ้น โดยลดลงถึง 3.29× จาก 64K เป็น 200K ในขณะที่ throughput ของ SGLang ลดลงเพียง 1.25× ในช่วงเดียวกัน
สาเหตุของความแตกต่าง
ทั้งสอง engine ใช้เวลาในขั้นตอน prefill (การโหลด prompt เข้าสู่ KV cache) ในปริมาณที่ใกล้เคียงกัน ความแตกต่างจะปรากฏชัดในขั้นตอน decode ซึ่งเป็นช่วงที่โมเดลสร้าง token ออกมาทีละตัว
- 64K tokens: การสื่อสารระหว่าง GPU (inter-GPU communication) เป็นปัจจัยหลัก เส้นทางการ decode แบบ single-GPU ของ vLLM ช่วยหลีกเลี่ยงการทำ synchronization ส่วนเกินที่จำเป็นสำหรับ DCP ทำให้ทำงานเสร็จเร็วกว่าประมาณ 1.5×
- 200K tokens: KV cache มีขนาดใหญ่มากจนการอ่านข้อมูลกลายเป็นคอขวด DCP ของ SGLang ที่ตั้งค่าขนาดไว้ที่ 8 จะกระจายการอ่านเหล่านั้นไปยัง GPU ทั้งแปดตัว ผลตอบแทนจาก bandwidth ที่ได้รับจึงคุ้มค่ากว่าภาระจากการสื่อสาร (communication penalty) ทำให้ SGLang นำหน้าอย่างชัดเจน
ข้อสังเกตเชิงปฏิบัติอีกประการหนึ่งคือเรื่องความกดดันของหน่วยความจำ (memory pressure) การรัน engine ใดก็ตามที่ตั้งเป้าหมายการใช้หน่วยความจำไว้ที่ 0.95 จะทำให้เกิดการลองใหม่เนื่องจากหน่วยความจำเต็ม (OOM retries) บน B300 การลดเป้าหมายลงเหลือ 0.92 ช่วยขจัดปัญหาการ retry และทำให้เวลาในการทำงานเสถียรขึ้น โดยแลกกับ latency ที่เพิ่มขึ้นเพียงเล็กน้อย
ใครคือผู้ชนะ และใครคือผู้แพ้
- นักพัฒนาที่ใช้งาน context ขนาดสั้นถึงปานกลาง (≤ 64K tokens) จะได้รับประโยชน์มากกว่าจากเส้นทางการ decode ที่คล่องตัวของ vLLM การประมวลผลที่เร็วกว่าหมายถึงค่าใช้จ่าย cloud-compute ที่ต่ำลงและประสบการณ์ผู้ใช้ที่ลื่นไหลขึ้น
- ทีมที่สร้างเครื่องมือวิเคราะห์เชิงลึกหรือเครื่องมือวิจัย ที่จำเป็นต้องรักษา token จำนวนหลายแสนไว้ใน context ควรเลือกใช้ SGLang พร้อมเปิดใช้งาน DCP เนื่องจาก throughput ที่สม่ำเสมอกว่าจะช่วยลดความเสี่ยงในการเกิด time-out และรักษาการใช้งาน GPU ให้สูงขึ้นเมื่อความต้องการหน่วยความจำเพิ่มขึ้น
- ผู้วางแผนด้านฮาร์ดแวร์ จะเห็นได้ว่าจำนวน GPU เพียงอย่างเดียวไม่สามารถรับประกันการขยายตัวแบบ linear ได้ เมื่อ bandwidth ของ KV กลายเป็นจุดอุดตัน สถาปัตยกรรมที่สามารถทำ parallelize การอ่าน cache ได้ ไม่ว่าจะผ่าน DCP หรือการอัปเกรดระบบหน่วยความจำในอนาคต จะสามารถดึงประสิทธิภาพจากชิปตัวเดิมออกมาได้มากขึ้น
ข้อโต้แย้ง: vLLM จะสามารถปิดช่องว่างนี้ได้หรือไม่?
จนกว่าจะมีข้อมูลใหม่ ตัวเลขปัจจุบันถือเป็นการเปรียบเทียบสาธารณะที่ดีที่สุด
สิ่งที่ต้องจับตามองต่อไป
- Context window ที่ใหญ่ขึ้น จะยิ่งสร้างความเครียดให้กับ KV bandwidth มากขึ้น ซึ่งอาจทำให้ช่องว่างของ SGLang กว้างขึ้นไปอีก
บทสรุป
เมื่อคุณต้องการให้บริการคำขอแบบ long-context บนคลัสเตอร์ที่ใช้ B300 ให้เลือก engine ที่เหมาะสมกับขนาด token window ของคุณ สำหรับงานขนาด 64K tokens vLLM ให้การประมวลผลที่เร็วกว่าประมาณ 1.5× แต่หากขยับเกิน 200K tokens การ decode ที่ขับเคลื่อนด้วย DCP ของ SGLang จะเป็นตัวเลือกที่มีประสิทธิภาพมากกว่า โดยมี throughput ลดลงเพียง 1.25× เมื่อเทียบกับการลดลงถึง 3.29× ของ vLLM ควรปรับการใช้หน่วยความจำ (memory utilization) ไปที่ 0.92 เพื่อหลีกเลี่ยง OOM retries และจำไว้ว่า engine ที่ "ดีที่สุด" นั้นขึ้นอยู่กับ context ไม่ใช่โซลูชันเดียวที่ใช้ได้กับทุกงาน