Thực hành: dựng vLLM trong VPC của khách mà không để lộ cổng nội bộ

Tài liệu bảo mật của vLLM có một câu mà FDE nào cũng nên dán lên màn hình: đừng chỉ dựa vào --api-key để bảo vệ quyền truy cập vào vLLM. Nhiều người dựng server, thêm một key rồi coi như xong. Ở VPC của một ngân hàng hay một nhà máy, đó mới là điểm bắt đầu.

Với khách hàng không cho dữ liệu ra khỏi mạng nội bộ, production là máy của họ, subnet của họ và quy trình duyệt bảo mật của họ. Một deployment chạy được trên laptop của bạn mà không qua được buổi duyệt bảo mật thì vẫn chưa phải deployment.

Hướng dẫn này đi qua đúng con đường đó: dựng vLLM bằng Docker, gọi thử bằng API thật, khóa lớp mạng, xử lý chuyện bộ nhớ GPU, rồi biến tất cả thành thứ chạy lại được.

Cuối bài, bạn sẽ có một server vLLM nằm trong private subnet, phục vụ API kiểu OpenAI cho ứng dụng nội bộ, kèm một sơ đồ cổng đủ rõ để đưa cho đội bảo mật của khách.

Bạn cần chuẩn bị gì trước khi gõ lệnh?

Bạn cần một máy có GPU nằm trong một subnet không có địa chỉ public, có Docker và đã cấu hình để container dùng được GPU. Bạn cũng cần một máy khác trong cùng mạng để gọi thử. Hãy chọn một model open-weight mà khách được phép dùng; trong các lệnh dưới đây, tên model nằm trong biến $MODEL.

Các lệnh trong bài đã được rút gọn cho dễ theo dõi. Cờ GPU, cách mount thư mục cache model và cổng mặc định thay đổi theo phiên bản, nên trước khi chạy ở chỗ khách, hãy đối chiếu với trang “Using Docker” và “Online Serving” trong tài liệu vLLM.

Bước 1: Image chính thức, và cờ shared memory không được quên

vLLM có Docker image chính thức là vllm/vllm-openai. Dùng image này thay vì tự build giúp bạn trả lời nhanh câu hỏi đầu tiên của đội bảo mật: phần mềm đến từ đâu.

docker pull vllm/vllm-openai

Khi chạy trong container, vLLM cần truy cập shared memory của host. Tài liệu đưa ra hai lựa chọn: cờ --ipc=host hoặc cờ --shm-size. Bộ khung của lệnh chạy trông như sau:

# KHUNG LỆNH, CHƯA CHẠY ĐƯỢC NHƯ ĐANG VIẾT:
# còn thiếu cờ cấp GPU cho container, cờ map cổng API ra host
# và mount cache model. Lấy đủ các cờ này từ trang "Using Docker".
export MODEL=ten-model-open-weight
docker run --ipc=host vllm/vllm-openai --model "$MODEL"

Nói thẳng: nếu bạn copy nguyên lệnh trên, container sẽ không thấy GPU, và kể cả khi chạy được thì máy khác cũng không gọi vào được vì cổng API chưa được map ra host. Phần cờ shared memory là thứ bài này muốn bạn nhớ; phần GPU và cổng hãy lấy đúng theo phiên bản vLLM bạn đang dùng.

Nếu chính sách cô lập container của khách không cho dùng --ipc=host, hãy chuyển sang --shm-size và ghi lý do vào tài liệu bàn giao. Kiểm tra: log container chạy hết phần nạp model mà không báo lỗi về shared memory.

Bước 2: Gọi thử bằng một request thật

Ngoài Docker, bạn có thể khởi động server trực tiếp bằng vllm serve kèm tên model. Chạy cách nào thì vLLM cũng mở một HTTP server tương thích với các interface kiểu OpenAI. Vì thế đội ứng dụng của khách thường không phải sửa nhiều code: họ chủ yếu đổi địa chỉ server.

# Minh họa: đặt VLLM_BASE_URL, VLLM_API_KEY, MODEL theo cấu hình thực tế
# Ví dụ VLLM_BASE_URL=http://10.0.1.15:8000/v1 (IP nội bộ của máy GPU)
import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ["VLLM_BASE_URL"],
    api_key=os.environ["VLLM_API_KEY"],
)

resp = client.chat.completions.create(
    model=os.environ["MODEL"],
    messages=[{"role": "user", "content": "Trả lời trong một câu: 2 + 2 bằng mấy?"}],
)
print(resp.choices[0].message.content)

Kiểm tra: chạy đoạn này từ máy thứ hai trong cùng subnet chứ không phải từ chính máy GPU, và terminal phải in ra một câu trả lời. Nếu chỉ thử qua localhost, bạn chưa kiểm tra được gì về mạng.

Bước 3: Vì sao một API key là chưa đủ?

Bạn hoàn toàn có thể khởi động server với --api-key, và nên làm thế. Nhưng tài liệu vLLM nói rõ không nên dựa duy nhất vào nó. Ở chỗ khách, lớp bảo vệ còn lại thường là hạ tầng kiểm soát truy cập họ đã có, như gateway, reverse proxy hay security group chỉ cho đúng các máy ứng dụng gọi vào.

Quan trọng hơn là các cổng nội bộ. Khi chạy phân tán, vLLM dùng thêm cổng cho giao tiếp giữa các tiến trình và cho việc truyền KV cache. Tài liệu yêu cầu không bao giờ để các cổng này lộ ra internet hay mạng không tin cậy, nên chúng phải nằm trong một mạng cô lập.

Trước khi bàn giao, còn một kiểm tra nữa: biến môi trường VLLM_SERVER_DEV_MODE=1 không bao giờ được bật trên production. Hãy chạy env trong container và tìm biến này, vì nó dễ lọt vào từ một file cấu hình dùng lúc thử nghiệm.

Bước 4: KV cache cạn thì chuyện gì xảy ra?

Khi KV cache không đủ chỗ, vLLM preempt bớt request rồi tính lại khi có chỗ trống. Hệ thống không sập, nhưng người dùng thấy độ trễ tăng mà không rõ lý do. Vì thế, nếu đội ứng dụng than “lúc nhanh lúc chậm”, hãy tìm dấu hiệu preemption trong log trước khi nghi ngờ mạng.

Thử hình dung một trường hợp đơn giản hóa: GPU 80 GB, trọng số model chiếm 60 GB, chỉ còn khoảng 20 GB cho KV cache và các phần khác. Bật tensor parallelism trên 2 GPU thì trọng số được chia đôi, mỗi GPU giữ khoảng 30 GB và còn khoảng 50 GB trống.

Tài liệu vLLM mô tả đúng cơ chế đó: chia trọng số qua nhiều GPU để mỗi GPU có thêm bộ nhớ cho KV cache. Tên tham số cụ thể nằm trong trang “Optimization and Tuning”.

Nhưng cái giá cũng có con số rõ ràng.

IBM cũng cảnh báo rằng chi phí hạ tầng và bảo trì có thể ngốn phần lớn ngân sách deployment. Việc của FDE là đưa cho khách cả hai con số, độ trễ và số GPU, để họ tự chọn.

Bước 5: Gói lại thành script dựng được từ đầu

Sau khi đã gõ tay đủ các lệnh, hãy gói chúng lại thành một script hoặc cấu hình hạ tầng dựng được từ đầu, gồm image, cờ shared memory, cấu hình GPU, quy tắc mạng và bước kiểm tra biến dev mode. AWS cho rằng tự động hóa việc tạo và deploy model giúp ra thị trường nhanh hơn và giảm chi phí vận hành.

Ở chỗ khách, lợi ích còn cụ thể hơn: khi đội IT của họ cần dựng lại sau một đợt bảo trì, họ không phải gọi bạn.

Server chạy ổn định rồi thì đến lượt phần theo dõi. IBM coi việc theo dõi hiệu năng model, đặc biệt là model drift, là phần cốt lõi của monitoring. Hãy thống nhất với khách ngay từ đầu ai xem số liệu nào và bao lâu một lần.

Những lỗi hay gặp nhất

Triệu chứng	Nguyên nhân thường gặp	Cách xử lý
Container lỗi khi nạp model	Thiếu quyền truy cập shared memory	Thêm --ipc=host hoặc --shm-size
Đội bảo mật từ chối duyệt	Chỉ có --api-key, cổng nội bộ chưa cô lập	Đặt API sau lớp kiểm soát truy cập, tách mạng riêng cho cổng nội bộ
Độ trễ lúc tăng lúc giảm	KV cache cạn, request bị preempt	Xem log, cân nhắc tensor parallelism hoặc giảm tải
Rủi ro bảo mật trên production	VLLM_SERVER_DEV_MODE=1 còn bật, trái khuyến cáo của tài liệu vLLM	Xóa biến, thêm bước kiểm tra vào script

Ở chỗ khách và trong CV, kỹ năng này trông ra sao?

Ở dự án thật, phần lớn thời gian không nằm ở vllm serve. Nó nằm ở cuộc họp với đội mạng để mở đúng một cổng, ở buổi giải thích cho đội bảo mật vì sao cổng nội bộ không bao giờ ra ngoài, và ở cuộc nói chuyện về số GPU với người giữ ngân sách.

Khi đọc JD vị trí FDE, hãy để ý các cụm như “self-hosted LLM”, “on-prem”, “VPC deployment” hay “customer environment”. Trong CV, đừng chỉ viết “dùng vLLM”. Hãy viết việc đã làm: dựng vLLM trong private subnet, tách mạng cho cổng nội bộ, xử lý preemption bằng tensor parallelism trên 2 GPU, bàn giao bằng script dựng lại được.

Lần tới khi có người hỏi bạn đã từng deploy LLM chưa, câu trả lời giá trị nhất không phải tên model. Đó là sơ đồ cổng bạn tự vẽ được, và lý do đằng sau từng mũi tên trên đó.