Triển khai vLLM Production: Xây dựng Kiến trúc Inference Serving Thông lượng Cao
Cập nhật ngày 11 tháng 12 năm 2025
Cập nhật tháng 12/2025: Stripe đạt được mức giảm 73% chi phí inference thông qua việc chuyển đổi sang vLLM (50 triệu lượt gọi API hàng ngày trên 1/3 đội GPU). PagedAttention loại bỏ 60-80% lãng phí bộ nhớ do phân mảnh KV cache. vLLM mang lại thông lượng cao hơn 2-24 lần so với serving truyền thống. Đang vận hành production tại Meta, Mistral AI, Cohere, IBM. API tương thích OpenAI đơn giản hóa việc áp dụng.
Đội ngũ ML platform của Stripe đã chứng kiến chi phí inference giảm 73% sau khi chuyển từ Hugging Face Transformers sang vLLM, xử lý cùng 50 triệu lượt gọi API hàng ngày trên một phần ba đội GPU.¹ Bí mật đằng sau hiệu quả của vLLM nằm ở PagedAttention, một thuật toán xử lý bộ nhớ GPU như bộ nhớ ảo trong hệ điều hành, loại bỏ sự phân mảnh gây lãng phí 60-80% bộ nhớ trong các hệ thống inference truyền thống.² Các tổ chức chạy workload LLM production phát hiện rằng vLLM mang lại cải thiện thông lượng 2-24 lần so với các framework serving thông thường, biến đổi kinh tế của việc triển khai large language model ở quy mô lớn.³
Bối cảnh inference serving phân mảnh thành hàng chục lựa chọn: TensorRT-LLM hứa hẹn tối ưu hóa NVIDIA tối đa, Hugging Face TGI cung cấp tích hợp quen thuộc, và Ollama đơn giản hóa triển khai local. Tuy nhiên vLLM đã nổi lên như lựa chọn thống trị cho các workload production, vận hành inference tại Meta, Mistral AI, Cohere, và IBM.⁴ Sự kết hợp của framework giữa PagedAttention, continuous batching, và API tương thích OpenAI tạo ra trải nghiệm triển khai cân bằng giữa hiệu suất thô và sự đơn giản vận hành. Hiểu kiến trúc và pattern triển khai của vLLM phân biệt các tổ chức đạt được inference hiệu quả về chi phí với những tổ chức chìm đuối trong hóa đơn GPU.
PagedAttention biến đổi quản lý bộ nhớ
Inference LLM truyền thống cấp phát một khối bộ nhớ liền kề cho key-value (KV) cache của mỗi sequence, dự trữ không gian cho độ dài sequence tối đa có thể bất kể mức sử dụng thực tế. Một hệ thống được cấu hình cho 4.096 token cấp phát toàn bộ bộ nhớ đó ngay cả cho các response 100-token, lãng phí 97% dung lượng dự trữ. Nhân với hàng trăm request đồng thời và bộ nhớ GPU đầy các dự trữ trống trong khi các sequence thực tế xếp hàng chờ tài nguyên.
PagedAttention tái định hình kiến trúc này bằng cách chia bộ nhớ GPU thành các page có kích thước cố định, thường là 16 token mỗi page.⁵ Mỗi sequence duy trì một danh sách tham chiếu page thay vì một cấp phát liền kề, cho phép một số khả năng đột phá:
Lưu trữ không liền kề cho phép các khối KV cache phân tán khắp bộ nhớ GPU có sẵn. Hệ thống không còn cần các vùng liền kề lớn, loại bỏ sự phân mảnh gây khó khăn cho các allocator truyền thống. Một sequence 2.000-token lưu trữ cache của nó trên 125 page được phân phối ở bất cứ đâu có không gian.
Cấp phát động cung cấp bộ nhớ chỉ khi sequence phát triển. Token đầu tiên cấp phát một page. Token thứ mười bảy kích hoạt cấp phát page thứ hai. Mức tiêu thụ bộ nhớ theo dõi mức sử dụng thực tế thay vì tối đa lý thuyết, cải thiện đáng kể dung lượng hiệu dụng.
Chia sẻ bộ nhớ cho phép các prefix prompt giống hệt nhau chia sẻ các page KV cache giữa các request. Mười người dùng hỏi các biến thể của cùng một system prompt chia sẻ một bản sao cached duy nhất của prefix đó, giảm mức tiêu thụ bộ nhớ 90% cho các pattern phổ biến. Các hệ thống production với prompt được chuẩn hóa thấy cải thiện sử dụng vượt quá 400%.⁶
Gần như không lãng phí loại bỏ phân mảnh nội bộ phổ biến trong cấp phát tĩnh. Các hệ thống truyền thống lãng phí trung bình 4,1 token mỗi sequence trong các khối được lấp đầy một phần. Độ chi tiết cấp page của PagedAttention giảm lãng phí xuống còn phần nhỏ của một page, thường dưới 8 token mỗi sequence bất kể độ dài.
Thuật toán lấy cảm hứng trực tiếp từ bộ nhớ ảo hệ điều hành, áp dụng nhiều thập kỷ nghiên cứu quản lý bộ nhớ vào inference GPU. Giống như các hệ điều hành hiện đại ánh xạ địa chỉ ảo đến các page bộ nhớ vật lý, PagedAttention ánh xạ các vị trí KV cache logic đến các khối bộ nhớ GPU vật lý. Overhead dịch thuật thêm microsecond vào mỗi tính toán attention nhưng tiết kiệm gigabyte dung lượng bộ nhớ.
Continuous batching tối đa hóa sử dụng GPU
Static batching chờ một số lượng request cố định trước khi xử lý chúng cùng nhau, tạo ra các đỉnh latency khi batch được lấp đầy một phần và thông lượng giảm khi request đến không đều. Batch size 32 có nghĩa là request thứ 31 chờ thêm một lần đến nữa trước khi xử lý bắt đầu, có thể thêm vài giây latency trong các giai đoạn traffic thấp.
Continuous batching trong vLLM loại bỏ hoàn toàn ranh giới batch.⁷ Scheduler hoạt động ở cấp iteration thay vì cấp request, đưa ra quyết định mỗi forward pass thay vì mỗi batch. Khi một sequence hoàn thành generation, slot của nó ngay lập tức chấp nhận một request mới mà không chờ các sequence anh em hoàn thành. GPU xử lý bất kỳ công việc nào tồn tại tại mỗi thời điểm, lấp đầy các khoảng trống mà static batching để trống.
Việc triển khai đòi hỏi sự phối hợp cẩn thận giữa quản lý bộ nhớ và scheduling:
Scheduling cấp iteration đánh giá hàng đợi request tại mỗi bước decoder. Các sequence đã hoàn thành giải phóng slot của chúng, các request đang chờ chiếm dung lượng có sẵn, và iteration tiếp theo tiến hành với batch được lấp đầy tối ưu. Độ biến thiên latency giữa các request được hấp thụ thay vì khuếch đại.
Xử lý preemption quản lý các tình huống khi áp lực bộ nhớ buộc phải trục xuất sequence. Các request ưu tiên thấp hơn checkpoint trạng thái KV cache của chúng và nhường bộ nhớ GPU cho các sequence ưu tiên cao hơn. Khi dung lượng trở lại, các sequence bị preempt tiếp tục từ checkpoint của chúng thay vì khởi động lại từ đầu.
Prefix caching xác định các request chia sẻ prefix chung và định tuyến chúng đến các instance đã giữ các page KV cache liên quan. Một hệ thống hỗ trợ khách hàng nơi mỗi request bắt đầu với cùng context 500-token phục vụ các token tiếp theo từ trạng thái cached, loại bỏ tính toán prefix dư thừa.
Benchmark chứng minh tác động: vLLM đạt thông lượng 793 token mỗi giây so với 41 token mỗi giây của Ollama ở các cấu hình tương đương, với P99 latency là 80ms so với 673ms.⁸ Kiến trúc continuous batching duy trì những lợi thế này trên các mức độ đồng thời từ 1 đến 256 người dùng đồng thời.
Kiến trúc production mở rộng quy mô trên các cluster
Triển khai vLLM single-node xử lý traffic đáng kể, nhưng các hệ thống production đòi hỏi orchestration toàn cluster cho độ tin cậy, quy mô, và hiệu quả. vLLM production-stack biến đổi inference engine thành một hệ thống serving hoàn chỉnh với bốn bổ sung quan trọng.⁹
Request routing hướng các query đến các instance backend phù hợp dựa trên routing key, session ID, hoặc prefix matching. Routing thông minh tối đa hóa việc tái sử dụng KV cache bằng cách gửi các request liên quan đến các instance đã giữ context liên quan. Một cuộc hội thoại với nhiều lượt định tuyến nhất quán đến cùng backend, tránh tính toán prefix dư thừa giữa các instance.
KV cache sharing mở rộng hiệu quả bộ nhớ của PagedAttention trên nhiều instance vLLM thông qua dự án LMCache. Các backend chia sẻ các khối KV cache đã tính toán qua các interconnect tốc độ cao, cho phép cache hit ngay cả khi request định tuyến đến các instance khác nhau. Các hệ thống với workload lặp lại thấy giảm latency 3-10 lần và cải thiện thông lượng 2-5 lần từ chia sẻ cache cross-instance.¹⁰
Tích hợp observability expose metric thông qua Prometheus và visualization thông qua Grafana dashboard. Metric per-request capture time-to-first-token (TTFT), time-between-tokens (TBT), và end-to-end latency. Metric per-instance theo dõi GPU utilization, áp lực bộ nhớ, độ sâu hàng đợi, và tỷ lệ cache hit. Các đội operations có được visibility vào các bottleneck hiệu suất và dữ liệu capacity planning.
Horizontal scaling thêm và xóa các instance vLLM dựa trên tín hiệu demand. Các triển khai Kubernetes sử dụng Horizontal Pod Autoscaler với custom metric nhắm mục tiêu độ sâu hàng đợi hoặc các percentile latency. Lớp router tự động phát hiện các instance mới và cân bằng lại traffic, cho phép dung lượng đàn hồi theo dõi demand thực tế.
Triển khai tuân theo các pattern Kubernetes tiêu chuẩn thông qua Helm chart:
# values.yaml cho vLLM production-stack
replicaCount: 4
model:
name: "meta-llama/Llama-3.1-70B-Instruct"
tensorParallelism: 4
resources:
limits:
nvidia.com/gpu: 4
router:
enabled: true
prefixAwareRouting: true
observability:
prometheus: true
grafana: true
Stack được triển khai expose một API tương thích OpenAI thông qua một Kubernetes service, cho phép thay thế drop-in cho các ứng dụng hiện đang gọi endpoint OpenAI hoặc Azure OpenAI. Các codebase hiện có chỉ yêu cầu thay đổi URL endpoint để migrate từ cloud API sang inference tự host.
Yêu cầu hạ tầng định hình quyết định triển khai
Hiệu quả bộ nhớ của vLLM cho phép các model lớn hơn trên cấu hình GPU nhỏ hơn, nhưng lựa chọn phần cứng vẫn xác định các đặc tính hiệu suất. Hiểu mối quan hệ giữa kích thước model, bộ nhớ GPU, và thông lượng cung cấp thông tin cho các quyết định mua sắm.
Bộ nhớ GPU giới hạn kích thước model tối đa và dung lượng batch đồng thời. Một model 70B parameter trong FP16 yêu cầu 140GB chỉ cho weight, đòi hỏi tensor parallelism multi-GPU trên bất kỳ phần cứng hiện tại nào. Cùng model đó trong quantization INT4 vừa trong 35GB, có thể triển khai trên một A100 80GB hoặc H100 với headroom đáng kể cho KV cache. Memory bandwidth thường giới hạn thông lượng nhiều hơn raw compute, làm cho các GPU trang bị HBM3 hiệu quả không cân xứng.
Tensor parallelism chia các layer model trên nhiều GPU trong một node, thiết yếu cho các model vượt quá bộ nhớ single-GPU. vLLM hỗ trợ tensor parallel degree khớp với số GPU, tự động sharding các layer attention và feed-forward. Một node 8-GPU chạy tensor parallelism 8 phục vụ một model 405B parameter mà nếu không sẽ yêu cầu nhiều node với pipeline parallelism chậm hơn.
Network fabric trở nên quan trọng cho các triển khai multi-node. Pipeline parallelism trên các node yêu cầu interconnect low-latency, high-bandwidth giữa các stage. Mạng InfiniBand hoặc RoCE với băng thông 200-400Gbps hỗ trợ serving multi-node hiệu quả, trong khi Ethernet tiêu chuẩn giới thiệu latency làm giảm time-to-first-token đáng kể.
Storage throughput ảnh hưởng đến hiệu suất cold start khi tải model weight. Một model 70B trong FP16 yêu cầu truyền 140GB từ storage đến bộ nhớ GPU trước khi phục vụ các request đầu tiên. NVMe storage cung cấp 7GB/s tải model trong 20 giây; network-attached storage ở 500MB/s mất 5 phút. Các hệ thống production hoặc duy trì các instance warm standby hoặc triển khai các chiến lược model caching để giảm thiểu tác động cold start.
Introl giúp các tổ chức thiết kế hạ tầng vLLM trên vùng phủ sóng toàn cầu của chúng tôi, khớp cấu hình phần cứng với yêu cầu workload trong khi tối ưu hóa hiệu quả chi phí.¹¹ Các kỹ sư của chúng tôi đã triển khai hạ tầng inference phục vụ hàng tỷ request hàng tháng, hiểu các sắc thái phân biệt các triển khai hoạt động với các hệ thống được tối ưu hóa cao.
So sánh vLLM với các lựa chọn thay thế
Hệ sinh thái inference serving cung cấp nhiều framework, mỗi cái có điểm mạnh riêng biệt. Lựa chọn công cụ phù hợp đòi hỏi khớp khả năng framework với đặc tính workload.
TensorRT-LLM mang lại hiệu suất tối đa trên phần cứng NVIDIA thông qua kernel optimization và graph compilation tích cực. Benchmark cho thấy TensorRT-LLM đạt 10.000+ output token mỗi giây trên H100 với FP8 quantization, với time-to-first-token khoảng 100ms.¹² Đánh đổi: setup phức tạp yêu cầu checkpoint conversion, engine building, và cấu hình mở rộng trên TensorRT-LLM, tensorrtllm_backend, và Triton Inference Server. Các tổ chức với đội ngũ ML infrastructure chuyên dụng và triển khai model ổn định được hưởng lợi nhiều nhất.
**Hugging Fa
[Nội dung bị cắt ngắn cho bản dịch]
