การ Deploy vLLM สำหรับ Production: การสร้าง Architecture สำหรับ High-Throughput Inference Serving

อัพเดทเมื่อ 11 ธันวาคม 2025

อัพเดทธันวาคม 2025: Stripe ประสบความสำเร็จในการลด inference cost 73% ผ่านการ migrate ไป vLLM (50 ล้าน API calls ต่อวันบน GPU fleet เพียง 1/3) PagedAttention ขจัดการสูญเสีย memory 60-80% จาก KV cache fragmentation vLLM ให้ throughput 2-24 เท่าเมื่อเทียบกับ conventional serving ใช้งานใน production ที่ Meta, Mistral AI, Cohere, IBM OpenAI-compatible APIs ทำให้การ adoption ง่ายขึ้น

ทีม ML platform ของ Stripe เห็น inference costs ลดลง 73% หลังจาก migrate จาก Hugging Face Transformers ไป vLLM โดยยังคง process 50 ล้าน API calls ต่อวันด้วย GPU fleet เพียงหนึ่งในสาม¹ ความลับของ efficiency ของ vLLM อยู่ที่ PagedAttention อัลกอริทึมที่จัดการ GPU memory เหมือนกับ virtual memory ในระบบปฏิบัติการ ขจัด fragmentation ที่สูญเสีย memory 60-80% ใน traditional inference systems² องค์กรที่รัน production LLM workloads พบว่า vLLM ให้ throughput improvements 2-24 เท่าเมื่อเทียบกับ conventional serving frameworks เปลี่ยนแปลง economics ของการ deploy large language models ที่ scale³

landscape ของ inference serving แบ่งออกเป็นหลายสิบตัวเลือก: TensorRT-LLM สัญญาการ optimization สูงสุดของ NVIDIA, Hugging Face TGI เสนอ integration ที่คุ้นเคย และ Ollama ทำให้ local deployment ง่ายขึ้น แต่ vLLM กลายเป็นตัวเลือกหลักสำหรับ production workloads ใช้งานใน inference ที่ Meta, Mistral AI, Cohere และ IBM⁴ การรวมกันของ PagedAttention, continuous batching และ OpenAI-compatible APIs ของ framework สร้างประสบการณ์ deployment ที่ balance raw performance กับ operational simplicity การเข้าใจ architecture และ deployment patterns ของ vLLM แยกองค์กรที่บรรลุ cost-effective inference ออกจากองค์กรที่จมอยู่ใน GPU bills

PagedAttention เปลี่ยนแปลง memory management

LLM inference แบบดั้งเดิมจัดสรร contiguous memory block สำหรับ key-value (KV) cache ของแต่ละ sequence โดยจองพื้นที่สำหรับ maximum possible sequence length โดยไม่คำนึงถึงการใช้งานจริง ระบบที่กำหนดค่าสำหรับ 4,096 tokens จะจัดสรร full memory แม้สำหรับ response 100 tokens สูญเสีย 97% ของ reserved capacity คูณด้วยหลายร้อย concurrent requests และ GPU memory เต็มไปด้วย empty reservations ในขณะที่ actual sequences รอคิวเพื่อรอ resources

PagedAttention คิด architecture นี้ใหม่โดยแบ่ง GPU memory เป็น fixed-size pages โดยทั่วไป 16 tokens แต่ละ page⁵ แต่ละ sequence รักษารายการ page references แทนที่จะเป็น contiguous allocation ช่วยให้สามารถ breakthrough capabilities หลายอย่าง:

Non-contiguous storage ช่วยให้ KV cache blocks กระจายไปตาม GPU memory ที่มีอยู่ ระบบไม่จำเป็นต้องใช้ large contiguous regions อีกต่อไป ขจัด fragmentation ที่รบกวน traditional allocators sequence 2,000-token เก็บ cache ใน 125 pages กระจายไปตามที่มีพื้นที่

Dynamic allocation จัดสรร memory เมื่อ sequences เติบโตเท่านั้น token แรกจัดสรร one page token ที่สิบเจ็ดจะ trigger การจัดสรร page ที่สอง การใช้ memory ตาม actual usage แทนที่จะเป็น theoretical maximums ปรับปรุง effective capacity อย่างมาก

Memory sharing ช่วยให้ identical prompt prefixes สามารถ share KV cache pages ระหว่าง requests ผู้ใช้สิบคนที่ถามคำถาม variations ของ system prompt เดียวกันจะ share cached copy เดียวของ prefix นั้น ลดการใช้ memory 90% สำหรับ common patterns production systems ที่มี standardized prompts เห็น utilization improvements เกิน 400%⁶

Near-zero waste ขจัด internal fragmentation ที่พบใน static allocation ระบบดั้งเดิมสูญเสีย average 4.1 tokens ต่อ sequence ใน partially filled blocks page-level granularity ของ PagedAttention ลด waste ไปเป็นเศษส่วนของ page โดยทั่วไปต่ำกว่า 8 tokens ต่อ sequence โดยไม่คำนึงถึงความยาว

อัลกอริทึมได้รับแรงบันดาลใจโดยตรงจาก operating system virtual memory นำการวิจัย memory management หลายสิบปีมาใช้กับ GPU inference เช่นเดียวกับที่ operating systems ทันสมัย map virtual addresses ไป physical memory pages PagedAttention map logical KV cache positions ไป physical GPU memory blocks overhead ของการแปลเพิ่ม microseconds ให้กับ attention computation แต่ละครั้ง แต่ประหยัด memory capacity เป็น gigabytes

Continuous batching เพิ่ม GPU utilization สูงสุด

Static batching รอ fixed number ของ requests ก่อนจะ process ด้วยกัน สร้าง latency spikes เมื่อ batches เต็มแค่บางส่วนและ throughput ลดลงเมื่อ requests มาไม่สม่ำเสมอ batch size 32 หมายความว่า request ที่ 31 รออีกหนึ่งตัวก่อนจะเริ่ม processing อาจเพิ่ม latency เป็นวินาทีในช่วง low-traffic periods

Continuous batching ใน vLLM ขจัด batch boundaries ทั้งหมด⁷ scheduler ทำงานใน iteration level แทนที่จะเป็น request level ตัดสินใจทุก forward pass แทนที่จะทุก batch เมื่อ sequence สิ้นสุดการ generation slot นั้นจะรับ new request ทันทีโดยไม่รอให้ sibling sequences เสร็จ GPU process งานที่มีอยู่ในแต่ละ moment เติมช่องว่างที่ static batching ทิ้งไว้

การ implementation ต้องการการประสานงานระหว่าง memory management และ scheduling อย่างระมัดระวัง:

Iteration-level scheduling ประเมิน request queue ทุก decoder step sequences ที่สมบูรณ์ปล่อย slots ของพวกเขา requests ที่รอ claim available capacity และ iteration ถัดไปดำเนินต่อด้วย batch ที่เต็มอย่างเหมาะสม latency variance ระหว่าง requests จะถูกดูดซึมแทนที่จะถูกขยาย

Preemption handling จัดการสถานการณ์ที่ memory pressure บังคับ sequence eviction requests ที่มี priority ต่ำ checkpoint KV cache state และยก GPU memory ให้ sequences ที่มี priority สูง เมื่อ capacity กลับมา preempted sequences ดำเนินต่อจาก checkpoints แทนที่จะเริ่มใหม่

Prefix caching ระบุ requests ที่ share common prefixes และ route พวกเขาไป instances ที่ถือ relevant KV cache pages อยู่แล้ว ระบบ customer support ที่ทุก request เริ่มด้วย context 500-token เดียวกันจะให้บริการ subsequent tokens จาก cached state ขจัดการคำนวณ prefix ซ้ำซ้อน

Benchmarks แสดงผลกระทบ: vLLM บรรลุ throughput 793 tokens ต่อวินาทีเมื่อเทียบกับ 41 tokens ต่อวินาทีของ Ollama ที่ configurations เทียบเท่า ด้วย P99 latency 80ms เทียบกับ 673ms⁸ continuous batching architecture รักษาข้อได้เปรียบเหล่านี้ใน concurrency levels ตั้งแต่ 1 ถึง 256 ผู้ใช้พร้อมกัน

Production architecture scale ข้าม clusters

การ deploy vLLM แบบ single-node จัดการ traffic ที่มากได้ แต่ production systems ต้องการ cluster-wide orchestration สำหรับ reliability, scale และ efficiency vLLM production-stack เปลี่ยน inference engine เป็น complete serving system ด้วยสี่ additions ที่สำคัญ⁹

Request routing นำ incoming queries ไป backend instances ที่เหมาะสมตาม routing keys, session IDs หรือ prefix matching intelligent routing เพิ่ม KV cache reuse สูงสุดโดยส่ง related requests ไป instances ที่ถือ relevant context อยู่แล้ว conversation ที่มีหลาย turns route อย่างสม่ำเสมอไปยัง backend เดียวกัน หลีกเลี่ยงการคำนวณ prefix ซ้ำซ้อนระหว่าง instances

KV cache sharing ขยาย memory efficiency ของ PagedAttention ข้าม vLLM instances หลายตัวผ่าน LMCache project backends share computed KV cache blocks ผ่าน high-speed interconnects ช่วยให้ cache hits แม้เมื่อ requests route ไป different instances ระบบที่มี repetitive workloads เห็นการลด latency 3-10 เท่าและการปรับปรุง throughput 2-5 เท่าจาก cross-instance cache sharing¹⁰

Observability integration เปิด metrics ผ่าน Prometheus และ visualization ผ่าน Grafana dashboards per-request metrics จับ time-to-first-token (TTFT), time-between-tokens (TBT) และ end-to-end latency per-instance metrics track GPU utilization, memory pressure, queue depth และ cache hit rates ทีม operations ได้รับ visibility ใน performance bottlenecks และข้อมูล capacity planning

Horizontal scaling เพิ่มและลบ vLLM instances ตาม demand signals การ deploy Kubernetes ใช้ Horizontal Pod