vLLM: động cơ phục vụ LLM và bài toán đa khách hàng cho SaaS B2B
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Tóm tắt: vLLM là động cơ phục vụ, chưa phải một sản phẩm AI hoàn chỉnh
vLLM là thư viện Python mã nguồn mở để suy luận (inference, tức chạy mô hình đã huấn luyện để sinh kết quả) và phục vụ (serving) mô hình ngôn ngữ lớn. README nhấn mạnh PagedAttention, cơ chế gộp lô liên tục, prefix caching và máy chủ API tương thích OpenAI, kèm Anthropic Messages API và gRPC [1]. Nó là tầng động cơ giữa trọng số mô hình và ứng dụng, không phải mô hình hay giao diện chat.
Nên cân nhắc vLLM khi tổ chức đã quyết định tự vận hành mô hình mở trên GPU cho nhiều người dùng đồng thời và muốn giữ giao diện kiểu OpenAI. Chưa nên dùng khi lưu lượng nhỏ, chưa có người vận hành GPU, hoặc cần cách ly tuyệt đối giữa khách hàng: tài liệu bảo mật nói rõ vLLM không cô lập các tenant (từng khách hàng của hệ thống dùng chung) trong cùng một tiến trình [5].
Khuyến nghị của bài: đặt vLLM sau một cổng API có xác thực, giới hạn tần suất và danh sách endpoint được phép, không mở thẳng ra Internet, vì cờ --api-key chỉ bảo vệ một số tiền tố đường dẫn [5]. Rủi ro chính nằm ở cách triển khai hơn là ở thuật toán.
Nút thắt khi phục vụ LLM: bộ nhớ KV cache, hàng đợi và tiền tố lặp lại
Khi nhiều người cùng gọi một mô hình, mỗi yêu cầu đang sinh văn bản giữ một vùng KV cache, tức bộ nhớ lưu khóa và giá trị attention của các token đã xử lý, lớn dần theo độ dài ngữ cảnh. Bài báo gốc của vLLM tại SOSP 2023 gọi đúng tên vấn đề: quản lý bộ nhớ hiệu quả cho phục vụ LLM bằng PagedAttention [1].
Nút thắt thứ hai là lịch xử lý khi yêu cầu đến không đều, ngắn dài lẫn lộn; README nêu continuous batching, chunked prefill và prefix caching là cơ chế cốt lõi [1]. Automatic Prefix Caching lưu KV cache của truy vấn trước để truy vấn mới cùng phần đầu khỏi tính lại, hữu ích khi hỏi nhiều lần trên một tài liệu dài hoặc hội thoại nhiều lượt [10].
Nút thắt thứ ba thuộc về sản phẩm: đổi mô hình mà không viết lại tích hợp. API tương thích OpenAI giải quyết phần giao diện, còn chọn mô hình viết tiếng Việt tốt hay quyết định dữ liệu khách hàng được đi đâu vẫn là việc của doanh nghiệp.
Kiến trúc V1: API server, engine core và một tiến trình cho mỗi GPU
Tài liệu kiến trúc mô tả hai lối vào: lớp LLM cho suy luận offline trong chương trình Python, và lệnh vllm serve cho máy chủ trực tuyến [7]. Kiến trúc V1 chia việc cho nhiều tiến trình: API server nhận HTTP, tách từ (tokenization), nạp dữ liệu đa phương thức và trả kết quả dạng luồng; engine core chạy bộ lập lịch, quản lý KV cache và điều phối; mỗi GPU có một worker nạp trọng số và chạy forward pass [7].
Khi dùng data parallel, số API server tăng theo và có thêm một tiến trình điều phối cân bằng tải [7]. Tài liệu đưa ví dụ bốn GPU với tensor parallel 4 cần sáu tiến trình, tám GPU với tp=2 và dp=4 cần mười bảy [7]; vì thế phải định cỡ cả CPU và RAM, không chỉ đếm GPU.
VllmConfig là đối tượng cấu hình trung tâm, và việc chia nhỏ hay lượng tử hóa trọng số diễn ra ngay khi khởi tạo mô hình; ví dụ mô hình 405B khoảng 810GB chạy trên 16 GPU 80GB, mỗi GPU chỉ nạp khoảng 50GB [7]. Trang kiến trúc còn ghi hỗ trợ hơn 50 loại mô hình, trong khi README cùng commit ghi hơn 200 kiến trúc [7][1], dấu hiệu một số đoạn tài liệu thiết kế đã cũ.
Một yêu cầu chat đi qua vLLM: từ Bearer token đến token cuối cùng
Giả sử ứng dụng gửi POST tới /v1/chat/completions. Nếu máy chủ chạy với --api-key, Bearer token được kiểm tra vì đường dẫn thuộc tiền tố /v1 [5]. API server tách từ, tải ảnh hoặc âm thanh đính kèm rồi chuyển yêu cầu sang engine core qua ZMQ [7]; media trỏ tới URL nên bị giới hạn tên miền bằng --allowed-media-domains để tránh SSRF, kiểu tấn công lợi dụng máy chủ gọi vào mạng nội bộ [5].
Bộ lập lịch chọn yêu cầu chạy trong mỗi bước, engine core quản lý KV cache [7]; nếu bật prefix caching và phần đầu lời nhắc trùng yêu cầu trước, khối cũ được dùng lại [10]. cache_salt được trộn vào hash của khối đầu tiên, nên chỉ yêu cầu cùng salt mới dùng chung tiền tố [5]. GPU worker chạy forward pass, token được giải mã và truyền về client theo luồng [7].
Dữ liệu còn rời luồng chính ở ba chỗ: thư mục cache trên đĩa giữ kết quả biên dịch và tài nguyên tải về [5]; thống kê sử dụng ẩn danh về phần cứng, kiến trúc mô hình và cờ cấu hình được gửi đi nếu không tắt [8]; và mạng giữa các nút khi chạy nhiều máy [5]. Pháp chế cần một sơ đồ ghi rõ các điểm này.
Bề mặt HTTP: các endpoint nằm ngoài vùng bảo vệ của --api-key
Chi tiết dễ bỏ sót nhất: --api-key hoặc biến VLLM_API_KEY chỉ áp dụng cho endpoint dưới /v1, /v2, /inference và /cohere [5]. Trên cùng máy chủ, /invocations (tương thích SageMaker, dẫn tới cùng hàm suy luận như /v1), /pooling, /classify, /score và /rerank không bị kiểm tra khóa [5].
Các endpoint điều khiển như /pause, /abort_requests, /scale_elastic_ep và /update_weights cũng mở; ai tiếp cận được máy chủ có thể gây từ chối dịch vụ hoặc thay trọng số mô hình mà không cần token [5]. Khi đặt VLLM_SERVER_DEV_MODE=1, /collective_rpc còn cho phép gọi RPC tùy ý tới engine, và tài liệu yêu cầu không bao giờ bật chế độ này trong production [5].
Biện pháp được khuyến nghị là reverse proxy, tức máy chủ trung gian như nginx, Envoy hay Kubernetes Gateway, chỉ cho phép đúng endpoint cần dùng và bổ sung xác thực, giới hạn tần suất, ghi log [5]. Ví dụ nginx của dự án chuyển tiếp toàn bộ đường dẫn gốc [6], nên khi dùng thật phải thay bằng danh sách location cụ thể. Cổng gRPC bật bằng --grpc-port cũng không xác thực, không mã hóa [5].
Những năng lực đối chiếu được trong tài liệu tại commit
Về hiệu năng, README liệt kê PagedAttention, continuous batching, chunked prefill, prefix caching, CUDA/HIP graph, lượng tử hóa FP8, INT8, INT4, GPTQ/AWQ và GGUF, speculative decoding (giải mã suy đoán) với n-gram, suffix và EAGLE, cùng khả năng tách rời các pha prefill, decode và encode [1].
Về sử dụng, README nêu tích hợp mô hình Hugging Face, parallel sampling, beam search, song song tensor, pipeline, data, expert và context, đầu ra có cấu trúc qua xgrammar hoặc guidance, tool calling, reasoning parser và multi-LoRA [1]. Phần cứng gồm GPU NVIDIA, AMD, Intel, nhiều loại CPU và plugin cho TPU, Ascend, Apple Silicon; mô hình trải từ Llama, Qwen tới MoE, đa phương thức và embedding [1].
Với LoRA (adapter tinh chỉnh nhẹ gắn lên mô hình gốc), adapter được khai báo khi khởi động bằng --lora-modules và chọn qua trường model của từng yêu cầu [9]; riêng LoRA cho phần tower và connector của mô hình đa phương thức còn ở mức thử nghiệm [9]. Tổ hợp mô hình, phần cứng và phiên bản cụ thể vẫn phải tự kiểm tra.
Ai nên tự vận hành vLLM, ai nên dừng ở API có sẵn
Phù hợp nhất là đội kỹ thuật cần API LLM nội bộ có lưu lượng đáng kể: công ty phần mềm tích hợp AI vào sản phẩm, đơn vị dữ liệu trong ngân hàng hay viễn thông muốn giữ dữ liệu trong nhà, phòng thí nghiệm chạy đánh giá hàng loạt bằng lớp LLM offline [7]. Các tích hợp Kubernetes như KServe, KubeRay hay llm-d cho thấy vLLM thường là một khối trong nền tảng lớn hơn [4].
Tải có lời nhắc lặp lại như hỏi đáp trên tài liệu dài hay hội thoại nhiều lượt được lợi từ prefix caching; tác vụ sinh văn bản rất dài từ lời nhắc ngắn thì ít, vì cơ chế này chỉ rút ngắn pha prefill, không rút ngắn pha sinh token [10].
Không phù hợp: cá nhân chạy mô hình trên laptop, doanh nghiệp vài người dùng, tổ chức không có người trực hệ thống; những trường hợp này nên dùng API thương mại hoặc công cụ chạy cục bộ đơn giản.
Đề xuất cho startup SaaS B2B: trợ lý soạn phản hồi trong phần mềm chăm sóc khách hàng
Tình huống giả định: một startup SaaS ở TP.HCM bán phần mềm helpdesk cho vài trăm doanh nghiệp vừa và nhỏ, mỗi doanh nghiệp là một tenant. Đội sản phẩm muốn thêm tóm tắt ticket, gợi ý trả lời tiếng Việt và tìm kiếm ngữ nghĩa trong kho hướng dẫn của từng khách hàng, trong khi vài hợp đồng lớn cấm gửi dữ liệu cho nhà cung cấp AI bên ngoài.
Kiến trúc đề xuất: ứng dụng gọi một AI gateway nội bộ; gateway xác thực tenant, áp hạn mức, chỉ ghi siêu dữ liệu và tự sinh cache_salt ngẫu nhiên cho từng tenant, đủ dài như mức 256 bit tài liệu gợi ý [5]. Sau gateway là reverse proxy chỉ mở /v1/chat/completions và /v1/embeddings, rồi tới các instance vLLM trong subnet riêng. Nếu phân loại ticket qua /classify, nhớ rằng endpoint này nằm ngoài vùng bảo vệ của --api-key [5].
Khách hàng lớn muốn giọng văn riêng có thể có adapter LoRA khai báo tĩnh kèm base_model_name, để /v1/models hiển thị quan hệ giữa adapter và mô hình gốc [9]; không bật nạp LoRA động vì tài liệu cảnh báo rủi ro bảo mật của tính năng này [9]. Tenant cần cách ly theo hợp đồng nên có instance riêng, đúng phương án tài liệu nêu cho triển khai đa tenant [5].
Đây là đề xuất, chưa phải hệ thống đã chạy. Câu hỏi đầu tiên nằm ở mô hình chứ không ở vLLM: tóm tắt tiếng Việt có chính xác không, thuật ngữ ngành có được giữ không, và nhân viên phải sửa bao nhiêu trước khi gửi.
Triển khai và vận hành: container, probe, cache mô hình và nhịp nâng cấp
README khuyên cài bằng uv pip install vllm, kèm lệnh vllm download-kernels để tải kernel biên dịch sẵn [1]. Trên Kubernetes, hướng dẫn dùng image vllm/vllm-openai, một PersistentVolumeClaim giữ cache mô hình, Secret chứa token Hugging Face cho mô hình cần cấp quyền, và /dev/shm dạng bộ nhớ vì tensor parallel cần shared memory của máy chủ [4].
Probe liveness và readiness trỏ tới /health; nếu ngưỡng khởi động thấp hơn thời gian tải mô hình, container bị dừng với dòng log KeyboardInterrupt: terminated và cần tăng failureThreshold [4]. Khi chạy nhiều bản sao bằng Docker, nên khởi động bản đầu tiên để tải mô hình vào cache dùng chung trước [6]. Các ví dụ dùng thẻ latest; production nên ghim phiên bản cụ thể.
Theo chính sách bảo mật, lỗi CRITICAL và HIGH được sửa trong fork riêng, CVE được xin khi bản vá được merge và advisory chỉ công bố khi bản sửa có trong một release [3]. Vì vậy cần theo dõi Security Advisories, nâng cấp định kỳ qua môi trường thử và giám sát tối thiểu thời gian tới token đầu tiên, độ dài hàng đợi, mức dùng KV cache, tỷ lệ lỗi.
Bảo mật và quyền riêng tư khi nhiều khách hàng dùng chung một máy chủ
Theo tài liệu, giao tiếp giữa các nút, gồm PyTorch Distributed, truyền KV cache và các kênh song song, mặc định không an toàn, không mã hóa và phải nằm trong mạng cô lập; riêng PyTorch Distributed không có phân quyền [5]. Ngay trên một máy, TCPStore của torch.distributed có thể lắng nghe trên mọi giao diện mạng, nên tường lửa chỉ nên mở cổng API server [5].
Với SaaS, điều quan trọng nhất là vLLM không cô lập các tenant dùng chung một tiến trình; yêu cầu được lập lịch và dùng cache chung [5]. Prefix caching còn tạo kênh rò rỉ theo thời gian (CVE-2025-46570): kẻ tấn công đo thời gian tới token đầu tiên để đoán tiền tố lời nhắc của người khác, và nghiên cứu được dẫn cho ROC AUC 0,99 ở tiền tố chỉ 8 token [5]. cache_salt giảm rủi ro nhưng không phải ranh giới cô lập và làm giảm hiệu quả cache [5].
Checklist nên có thêm: hạ VLLM_MAX_N_SEQUENCES từ mặc định 16384 xuống mức như 64 hoặc 128 cho hệ thống công khai [5]; khóa quyền ghi thư mục cache vì nội dung được nạp không kiểm tra toàn vẹn, kể cả định dạng có thể thực thi mã [5]; và quyết định về thống kê sử dụng vốn bật mặc định, tắt được bằng VLLM_NO_USAGE_STATS=1 hoặc DO_NOT_TRACK=1 [8].
SECURITY.md yêu cầu báo lỗ hổng qua biểu mẫu riêng, phân mức theo CVSS, và chỉ thông báo trước cho đơn vị có triển khai đáng kể, đội bảo mật riêng hoặc đóng góp đều đặn [3]; startup nhỏ nên theo dõi advisory công khai.
Giấy phép Apache-2.0: phủ mã vLLM, không phủ trọng số và dịch vụ
LICENSE tại commit là văn bản Apache License 2.0 đầy đủ; phụ lục giữ nguyên dòng mẫu Copyright [yyyy] [name of copyright owner], không ghi tên chủ sở hữu cụ thể [2]. Giấy phép cho phép dùng, sửa, phân phối, kèm cấp phép bằng sáng chế từ người đóng góp; người phân phối lại phải giữ thông báo bản quyền, văn bản giấy phép, tệp NOTICE nếu có và đánh dấu tệp đã sửa [2].
Phạm vi là mã vLLM tại commit này, không phải trọng số mô hình tải từ Hugging Face với điều khoản riêng, cũng không phải dữ liệu, plugin phần cứng bên ngoài hay dịch vụ đám mây đóng gói vLLM. Thư mục vllm/third_party có tệp LICENSE riêng mà bài chưa đọc, cần rà soát khi đóng gói sản phẩm.
Các nguồn đã đọc không mô tả bản doanh nghiệp hay phần trả phí; README chỉ nêu địa chỉ liên hệ cho hợp tác và đối tác [1]. Công cụ demo của tool server do gói gpt-oss cài riêng cung cấp, không phải mã vLLM [5], nên điều kiện sử dụng của gói đó cần xem riêng.
Chi phí: tính theo GPU-giờ được dùng hữu ích, không theo giá token lý thuyết
vLLM không thu phí giấy phép, nhưng chi phí gồm bốn nhóm: GPU mua hoặc thuê đủ VRAM cho trọng số và KV cache; ít nhất một kỹ sư nền tảng hiểu GPU, Kubernetes và mạng, cộng thời gian xây gateway; thời gian nâng cấp và xử lý sự cố; lưu trữ trọng số, băng thông tải mô hình và giám sát.
Giả định cần có: số yêu cầu mỗi ngày, độ dài vào ra, tỷ lệ tiền tố lặp, mức đồng thời giờ cao điểm và ngưỡng chất lượng. Mô hình và kiểu song song quyết định số GPU, còn kiến trúc đa tiến trình cần CPU cho API server và xử lý media [7]. vLLM hỗ trợ lượng tử hóa như FP8 hay INT4 [1], cách thường dùng để chạy mô hình lớn hơn trên cùng phần cứng, đổi lại phải đánh giá lại chất lượng tiếng Việt.
So với API thương mại, nên đo chi phí trên mỗi kết quả được chấp nhận, ví dụ một bản nháp nhân viên gửi đi, thay vì giá mỗi token. GPU tự vận hành tốn gần như cố định, nên tải thấp hoặc theo mùa đẩy chi phí mỗi kết quả lên. Bài không nêu giá vì giá thay đổi theo nhà cung cấp và thời điểm.
So sánh phương án: API thương mại, engine tự vận hành khác, công cụ cục bộ
API của nhà cung cấp mô hình thương mại không đòi vận hành GPU và có mô hình mạnh ngay, nhưng dữ liệu rời hạ tầng và sản phẩm phụ thuộc giá, điều khoản, hạn mức của bên thứ ba. Đây thường là điểm khởi đầu hợp lý; vLLM đáng xét khi yêu cầu dữ liệu hoặc quy mô làm phép tính thay đổi.
Engine tự vận hành cùng tầng gồm SGLang, TensorRT-LLM của NVIDIA hay Text Generation Inference của Hugging Face. Không có phép đo độc lập nên bài không xếp hạng hiệu năng; nên chọn theo mô hình mục tiêu, phần cứng sẵn có, mức tài liệu hóa bảo mật và năng lực đội ngũ. Điểm kiểm chứng được ở vLLM là hướng dẫn bảo mật chi tiết và danh sách tích hợp Kubernetes dài [5][4].
Công cụ chạy cục bộ hoặc nền tảng bao gói nhiều engine như llama.cpp, Ollama hay LocalAI hợp với máy đơn; dịch vụ suy luận được quản lý trên đám mây giảm vận hành nhưng cần hợp đồng xử lý dữ liệu. Thực tế thường kết hợp: API thương mại cho tác vụ khó, vLLM cho tác vụ khối lượng lớn như phân loại và embedding.
Khi nào vLLM là lựa chọn sai
Không dùng vLLM khi chưa có GPU và người vận hành: CPU chỉ để minh họa và thử nghiệm [4], còn GPU đòi hỏi hiểu shared memory, probe, cache mô hình và mạng nội bộ [4][5]. Không mở vLLM trực tiếp ra công chúng vì nhiều endpoint không xác thực, và không coi tiến trình dùng chung là ranh giới cô lập cho khách hàng có yêu cầu bảo mật cao [5].
Nên tắt các tính năng mang cảnh báo trừ khi thật cần: nạp LoRA động [9], plugin endpoint có thể che route lõi vì chưa có cơ chế chống xung đột route, và tool server demo với trình thông dịch Python không cô lập mạng theo mặc định [5]. Môi trường FIPS phải đổi thuật toán hash mặc định blake3, vốn không được FIPS phê duyệt, và tự lo mã hóa kênh giữa các nút [5].
Hạn chế cuối là độ lệch giữa tài liệu và mã đã nêu ở phần kiến trúc [7][1]; nên khóa một bản phát hành cụ thể và chỉ nâng cấp sau khi chạy lại bộ kiểm thử nội bộ.
Kế hoạch thử nghiệm sáu tuần với tiêu chí dừng rõ ràng
Tuần 1, chuẩn bị: chọn hai hoặc ba mô hình mở có năng lực tiếng Việt, lập bộ đánh giá khoảng 300 ticket đã ẩn danh từ khách hàng đồng ý bằng văn bản, thống nhất thang chấm đúng ý, đủ thông tin, giọng phù hợp, và đo đường cơ sở bằng cách làm hiện tại.
Tuần 2 và 3, kiểm thử kỹ thuật trên một nút GPU trong mạng riêng với proxy allowlist, cache_salt theo tenant và thống kê sử dụng đã tắt [5][8]. Đo p50, p95 thời gian tới token đầu tiên, thông lượng và tỷ lệ lỗi ở mức đồng thời mục tiêu. Kiểm thử bắt buộc: từ ngoài proxy không gọi được /invocations, /pause, /update_weights; hai tenant khác salt không dùng chung tiền tố.
Tuần 4 đến 6 chạy song song với ba đến năm tenant tự nguyện: gợi ý hiện cho nhân viên nhưng không tự gửi; đo tỷ lệ gợi ý được dùng, mức chỉnh sửa và thời gian xử lý ticket so với nhóm đối chứng.
Dừng nếu chất lượng thấp hơn đường cơ sở, chi phí mỗi bản nháp được chấp nhận vượt ngân sách, một kiểm thử bảo mật thất bại, hoặc thiếu người trực. Chỉ mở rộng khi đạt ngưỡng đặt trước, hệ thống ổn định hai tuần liền và đã có runbook cho nâng cấp lẫn sự cố.
Kết luận: động cơ mạnh cần một lớp cổng có kỷ luật
vLLM là engine phục vụ LLM giàu tính năng, có tài liệu kiến trúc và bảo mật chi tiết, phát hành theo Apache-2.0 [1][2][5]. Trong SaaS B2B, giá trị thật nằm ở lớp bao quanh: gateway xác thực tenant, proxy chỉ mở đúng endpoint, chính sách salt và quy trình nâng cấp.
Với startup Việt Nam, hãy chứng minh chất lượng mô hình trên dữ liệu tiếng Việt thật trước khi đầu tư hạ tầng; tối ưu thông lượng không cứu được một mô hình chưa đạt yêu cầu.
Câu hỏi kiểm tra trước khi chọn: lớp nào xác thực, lớp nào cô lập khách hàng, ai cập nhật bản vá. Khi cả ba đã rõ, vLLM là ứng viên đáng thử nghiệm nghiêm túc.
Nguồn, commit và giới hạn của nghiên cứu tài liệu
Bài thuộc nhóm Mô hình và suy luận AI trong loạt 100 nghiên cứu ứng dụng mã nguồn mở xuất hiện trên GitHub Trending năm 2026. Theo dữ liệu tuyển chọn từ một kho lưu độc lập các danh sách Trending theo ngôn ngữ, vLLM được ghi nhận 16 lần từ 22/01 đến 08/10/2026; quan sát làm bằng chứng là danh sách Python ngày 22/01/2026, vị trí 11 [11]. Kho lưu chỉ gồm Python, Go, JavaScript, Swift và thiếu ngày 03/09, 12/10; đây không phải Top 100 chính thức của GitHub.
Đối chiếu dùng commit 36f397281295f5b58852a7eaf429b90348161079 (tạo và kiểm tra ngày 12/10/2026) với README, LICENSE, SECURITY.md, hướng dẫn Kubernetes, nginx, bảo mật và bốn tài liệu bổ sung về kiến trúc, thống kê sử dụng, LoRA, prefix caching [1][2][3][4][5][6][7][8][9][10]. Siêu dữ liệu GitHub cùng ngày ghi bản phát hành mới nhất là v0.31.0 (05/10/2026).
Đây là nghiên cứu tài liệu có hỗ trợ AI: không cài đặt, không chạy, không đo hiệu năng vLLM, và không phải công trình khoa học đã phản biện. Kiến trúc SaaS, tình huống Việt Nam, nguồn lực và kế hoạch thử nghiệm là đề xuất; số liệu về vLLM lấy từ tài liệu dự án có ghi nguồn, còn số sao GitHub không được dùng làm bằng chứng chất lượng.