1. DeepSeek V4.1 Flash là gì? Có nên tự triển khai không?

Trong tuần qua, tôi đã nhận được hơn 30 câu hỏi tương tự nhau: DeepSeek V4.1 Flash có thể chạy cục bộ được không? Card 4090 đủ sức chưa? vLLM hay SGLang cái nào ổn định hơn? Thực tế, tôi từng băn khoăn rất lâu về vấn đề này. Chỉ sau khi thử nghiệm thành công bốn phương án triển khai khác nhau, tôi mới hiểu rõ hai yếu tố then chốt: tính toán bộ nhớ GPU và lệnh khởi động. Bài viết này cung cấp hướng dẫn toàn diện từ đầu đến cuối, bao gồm phân tích chi tiết nhu cầu bộ nhớ, cú pháp khởi động cho vLLM/SGLang, lựa chọn phương án phù hợp dựa trên cấu hình, cùng những lỗi thường gặp và cách xử lý. Phù hợp với ba nhóm người dùng: kỹ sư muốn triển khai riêng tư trong mạng nội bộ, sinh viên có card đồ họa tiêu chuẩn muốn chạy mô hình cục bộ, và các quản trị hệ thống bị ám ảnh bởi lỗi khởi động.

1.1 Ý nghĩa của hậu tố "Flash" trong sản phẩm

Trước tiên cần làm rõ: "Flash" không phải phiên bản thu nhỏ hay giảm chất lượng. Đây là một phân khúc chiến lược do nhà phát triển tạo ra theo từng ngữ cảnh sử dụng. Phiên bản chính thường tối ưu hiệu năng cao nhất, nhưng đòi hỏi tài nguyên khổng lồ và độ khó triển khai cực cao. Trong khi đó, phiên bản Flash cân bằng giữa hiệu suất, tốc độ và tiêu thụ bộ nhớ, thường áp dụng các kỹ thuật nén hoặc tinh chỉnh (distillation) mạnh mẽ hơn, giúp các thiết bị tiêu chuẩn và nhóm nhỏ có thể vận hành.

Phân tích kiến trúc từ cộng đồng cho thấy V4.1 Flash vẫn sử dụng mô hình MoE (Mixed Experts), kết hợp GQA (Grouped Query Attention) để giảm tải bộ nhớ KV Cache. Điều này khiến số tham số được kích hoạt trong quá trình suy luận thấp hơn nhiều so với tổng số tham số. Do đó, tốc độ sinh token mỗi lần không chậm, mà rào cản thực sự nằm ở dung lượng bộ nhớ chứ không phải sức mạnh tính toán. Chính vì vậy, câu hỏi "tính toán bộ nhớ thế nào?" trở thành vấn đề phổ biến nhất — mô hình trông nhỏ nhưng sai một mức độ chính xác thì card đồ họa sẽ không thể chứa nổi.

1.2 Trước khi bắt tay: Ba câu hỏi cần trả lời

Không nên sao chép ngay lệnh khởi động. Hãy dành 5 phút để tự hỏi ba điều sau:

1. Dữ liệu có thể rời khỏi mạng nội bộ không? Nếu chỉ dùng để thử nghiệm, gõ prompt, thì API chính thức là lựa chọn tốt nhất. Triển khai cục bộ chỉ đáng giá nếu dữ liệu nhạy cảm, yêu cầu hoàn toàn khép kín.
2. Kỳ vọng mức độ song song là bao nhiêu? Dùng cá nhân và phục vụ backend là hai quy mô hoàn toàn khác biệt. Khi số lượng truy vấn tăng, bộ nhớ tăng tuyến tính. Phần sau sẽ cung cấp công thức cụ thể.
3. Thiết bị bạn đang dùng là gì? Một card 24GB, hai card 48GB, hay một card 80GB? Cấu hình này trực tiếp quyết định bạn chỉ có thể đi theo con đường nào. Đừng chọn giải pháp trước rồi mới xem card, hãy nhìn vào card trước rồi mới chọn giải pháp.

Sau khi trả lời ba câu hỏi này, bạn sẽ biết mình nên đọc phần nào trong bài viết.

2. Tính toán chính xác nhu cầu bộ nhớ GPU: Tính tiền trước, đừng đợi OOM mới hối hận

2.1 Chi phí trọng số: Mô hình chiếm bao nhiêu bộ nhớ?

Nhu cầu bộ nhớ do trọng số rất dễ tính toán theo công thức đơn giản:

Memory_weight = Số tham số × Byte mỗi tham số

Các mức độ chính xác tương ứng:

• BF16/FP16: 2 byte
• FP8: 1 byte
• INT4/AWQ/GPTQ: ~0.5 byte

Theo thống kê từ cộng đồng, trọng số BF16 khoảng 60GB, FP8 ~30GB, INT4 khoảng 15GB. Bạn không cần nhớ, chỉ cần kiểm tra kích thước tập tin safetensors sau khi tải xong:

du -sh ~/models/DeepSeek-V4.1-Flash

Số GB bạn thấy là giới hạn tối thiểu để lưu trọng số vào GPU — đây là ràng buộc cứng, không thể tránh. Những lời đồn "4090 chạy mô hình 70B thoải mái" thường là do chưa hiểu rõ vấn đề này — trọng số vừa vào, nhưng KV Cache và chi phí tính toán còn chưa tính!

2.2 Chi phí KV Cache: Song song và chiều dài ngữ cảnh là kẻ giết người âm thầm

Trọng số chỉ là chiếm dụng tĩnh. Nguyên nhân khiến bộ nhớ vượt quá kiểm soát là KV Cache. Trong quá trình suy luận Transformer, mỗi token sinh ra đều cần lưu lại Key và Value của tất cả các token trước đó. Bộ nhớ này tăng tuyến tính theo chiều dài ngữ cảnh và số lượng truy vấn song song. Công thức:

KV Cache mỗi phiên = 2 × số tầng × số head KV × kích thước head × chiều dài ngữ cảnh × byte

Với cấu trúc GQA như V4.1 Flash (khoảng 48 tầng, 8 head KV, kích thước 128), dùng FP16, một phiên với 8K ngữ cảnh tiêu tốn khoảng 1.6GB. Điều đó có nghĩa:

Số song song	Chiều dài ngữ cảnh	Tổng KV Cache
1	8K	~1.6 GB
4	8K	~6.4 GB
16	8K	~25.6 GB
32	8K	~51.2 GB

Bạn thấy chưa? Một mô hình INT4 nặng 15GB, nhưng nếu mở 32 phiên song song, chỉ riêng KV Cache đã ăn hết 51GB — gấp nhiều lần ngân sách bộ nhớ. Đó là lý do tại sao nhiều hệ thống dịch vụ cuối cùng chọn BF16 + card lớn, thay vì cố gắng tối ưu hóa bằng lượng hóa.

2.3 Tổng hợp: Bảng ngân sách bộ nhớ & đề xuất chọn card

Công thức tổng thể:

Tổng bộ nhớ = Trọng số + (KV Cache mỗi phiên × số song song tối đa) + dư phòng (10%-30%)

Dư phòng dùng để lưu trữ giá trị kích hoạt, context CUDA, cache toán tử — không thể bỏ qua.

Dưới đây là bảng ngân sách cho các cấu hình phổ biến:

Độ chính xác	Trọng số	Card 24GB	2 card 48GB	Card 80GB
BF16	~60GB	Không chạy được	TP=2, giới hạn song song	Rộng rãi
FP8	~30GB	Không chạy được	Chạy được, song song trung bình	Rộng rãi
INT4/AWQ	~15GB	Chạy được, song song 2–4	Rộng rãi	Rộng rãi

Kinh nghiệm cá nhân: Nên mua card có bộ nhớ lớn hơn dù tốn kém, đừng vì tiết kiệm mà ép dùng lượng hóa. Lượng hóa gây mất mát chất lượng thực tế, đặc biệt trong nhiệm vụ dài và phức tạp. Thậm chí, INT4 đôi khi còn chậm hơn FP8 trên một số toán tử. Lựa chọn đầu tiên nên là FP8 + bộ nhớ đủ lớn, chỉ khi không thể mới chuyển sang INT4.

3. Phương án vLLM: Khởi động dịch vụ tương thích OpenAI chỉ bằng một lệnh

3.1 Chuẩn bị môi trường: Chọn đúng phiên bản là nửa thành công

vLLM là framework suy luận phổ biến nhất hiện nay, nổi bật với hiệu suất cao và quản lý bộ nhớ PagedAttention. Kiểm tra môi trường trước khi cài đặt:

nvidia-smi          # Xác minh hỗ trợ CUDA 12.x
python --version    # Đề nghị Python 3.10–3.12
pip install vllm    # Cài gói chính thức

Lỗi phổ biến nhất là phiên bản Python quá cũ hoặc quá mới — wheel chính thức chỉ hỗ trợ một số phiên bản hạn chế. Nếu không đúng, sẽ xảy ra lỗi biên dịch hoặc API tự động xuống cấp. Sau khi cài, kiểm tra bằng lệnh:

python -c "import vllm; print(vllm.__version__)"

Xác nhận thành công mới tiến hành bước tiếp theo.

3.2 Lệnh khởi động đơn card: Mỗi tham số đều quan trọng

Ví dụ điển hình: 1 card 24GB, trọng số lượng hóa INT4:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash-AWQ \
  --served-model-name v4-1-flash \
  --quantization awq \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --max-num-seqs 4 \
  --host 0.0.0.0 \
  --port 8000

Giải thích từng tham số:

• --served-model-name: Tên hiển thị cho mô hình. Yêu cầu trùng khớp với trường model trong API gọi sau này.
• --quantization awq: Thông báo cho vLLM biết trọng số ở dạng AWQ. Không thêm, framework sẽ cố tải dưới BF16 → OOM.
• --max-model-len 8192: Giới hạn chiều dài ngữ cảnh tối đa. Giá trị càng lớn, KV Cache càng nhiều. Khi thiếu bộ nhớ, ưu tiên giảm tham số này thay vì gpu-memory-utilization.
• --gpu-memory-utilization 0.92: Cho phép sử dụng 92% bộ nhớ GPU. Không nên đặt 0.99 vì CUDA context và driver cũng chiếm một phần — đặt đầy dễ sập ngay lúc khởi động.
• --max-num-seqs 4: Giới hạn số lượng truy vấn song song. Đây là tham số bảo vệ khi bộ nhớ thiếu — giảm số song song = giảm KV Cache.

3.3 Nhiều card trong máy: Cách bật Tensor Parallelism

Khi bộ nhớ không đủ, cách đơn giản nhất là dùng nhiều card. vLLM hỗ trợ Tensor Parallelism (TP): chia các tầng và head chú ý ra nhiều card để xử lý song song. Chỉ cần thêm một tham số:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 2 \
  --dtype bfloat16 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.9 \
  --host 0.0.0.0 \
  --port 8000

--tensor-parallel-size 2 nghĩa là dùng 2 card. Lưu ý: giao tiếp giữa các card qua NVLink hoặc PCIe — có chi phí truyền thông thực tế. Giao tiếp xuyên máy rất chậm, vì vậy "đơn máy nhiều card" là điểm ngọt. Không nên thử đa máy trừ khi thật sự cần.

Thêm nữa, nếu bộ nhớ đủ, chạy single-card luôn nhanh hơn double-card TP — TP chỉ là giải pháp mở rộng dung lượng, không phải tăng hiệu năng.

3.4 Kiểm tra API: Nhật ký khởi động không nói dối

Sau khi khởi động thành công, bạn sẽ thấy dòng log như:

Uvicorn running on http://0.0.0.0:8000

Kiểm tra dịch vụ bằng curl:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "v4-1-flash",
    "messages": [{"role": "user", "content": "Giới thiệu bản thân bằng một câu"}],
    "max_tokens": 256
  }'

Nếu nhận được phản hồi JSON có trường choices, tức là dịch vụ đang hoạt động. vLLM cung cấp giao diện tương thích OpenAI — mọi code SDK OpenAI trước đây chỉ cần đổi base_url thành http://localhost:8000/v1 là dùng được ngay, không cần sửa lại code nghiệp vụ.

Nếu muốn kiểm tra chất lượng mô hình, dùng lm-evaluation-harness:

lm_eval --model local-completions \
  --model_args "model=v4-1-flash,base_url=http://localhost:8000/v1" \
  --tasks mmlu --num_fewshot 5

Không bắt buộc, nhưng nếu báo cáo với lãnh đạo rằng "mô hình đạt yêu cầu", một bảng điểm định lượng sẽ thuyết phục hơn lời nói.

4. Phương án SGLang: Điểm mạnh là song song cao và tái sử dụng tiền tố

4.1 Vì sao có SGLang? Nó giải quyết vấn đề gì?

Nếu vLLM là lựa chọn phổ biến, thì SGLang là lựa chọn dành cho người chơi hiệu năng. Tôi lần đầu dùng SGLang vì tính năng RadixAttention: trong các tình huống như hội thoại nhiều vòng, RAG, hoặc gọi công cụ Agent, các truy vấn thường chia sẻ nhiều tiền tố token. SGLang có thể lưu giữ KV Cache của tiền tố và tái sử dụng — khi hit, thời gian prefill (chuẩn bị trước) giảm mạnh.

Đặc tính này cực kỳ phù hợp với mô hình V4.1 Flash – vốn hướng đến độ trễ thấp. Thử nghiệm thực tế cho thấy: khi hỏi liên tục cùng một văn bản dài, độ trễ lần đầu của SGLang thấp hơn vLLM từ 30% đến 50%. Nhưng nếu kịch bản là các câu hỏi ngắn, độc lập, không có tiền tố trùng, lợi ích này gần như không tồn tại — lúc đó vLLM lại ổn định hơn.

4.2 Cài đặt và khởi động SGLang

Cài đặt SGLang hơi phức tạp hơn vLLM, khuyến nghị cài gói đầy đủ:

pip install "sglang[all]"

Lệnh khởi động:

python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V4.1-Flash-AWQ \
  --host 0.0.0.0 \
  --port 30000 \
  --tp-size 1 \
  --quantization awq \
  --mem-fraction-static 0.85 \
  --max-len 8192

Mặc định port là 30000, khác với vLLM (8000). --mem-fraction-static tương đương --gpu-memory-utilization trong vLLM, điều chỉnh mức chiếm bộ nhớ tĩnh. Mặc định 0.9, nếu thiếu bộ nhớ giảm xuống 0.8. --max-len giới hạn chiều dài ngữ cảnh.

Sau khi khởi động, SGLang cũng expose giao diện OpenAI, endpoint là http://localhost:30000/v1. Kiểm tra tương tự vLLM, chỉ thay đổi port.

4.3 vLLM hay SGLang? So sánh qua bảng đánh giá

Yếu tố	vLLM	SGLang
Độ dễ cài đặt	Thấp, pip là xong	Trung bình, phụ thuộc nhiều
Tương thích OpenAI	Ổn định, trưởng thành	Cơ bản tương thích
Tái sử dụng tiền tố	Có Prefix Caching	RadixAttention, tỷ lệ hit cao hơn
Hiệu suất song song	Tốt	Tốt, một số trường hợp vượt trội
Phù hợp với kiến trúc mới	Nhanh, cộng đồng sôi động	Chậm hơn, hỗ trợ mới chậm
Tài liệu khi lỗi	Rất nhiều	Ít hơn
Khuyến nghị dùng	Service production, hợp tác nhóm	RAG/Agent, yêu cầu song song cao

Kinh nghiệm của tôi: Nếu bạn đã quen vLLM, và không có scenario tái sử dụng tiền tố, không cần đổi sang SGLang vì đổi mới. Nhưng nếu làm việc với knowledge base, nơi tiền tố trùng lặp cao, trải nghiệm SGLang cải thiện rõ rệt — đáng để thử.

5. Bốn phương án triển khai: Không có lựa chọn nào tốt nhất, chỉ có phù hợp nhất

5.1 Phương án 1: Một card tiêu chuẩn + lượng hóa INT4

Là lựa chọn phổ biến nhất cho người dùng cá nhân và sinh viên. Thiết bị: 4090/4080 (24GB). Ý tưởng: trọng số INT4 (~15GB) + giới hạn song song và chiều dài ngữ cảnh để chạy được.

Lệnh giống mục 3.2, trọng tâm vào --max-num-seqs 4 và --max-model-len 8192. Thực tế, cấu hình này hỗ trợ 2–4 phiên song song, tốc độ sinh token ~30–50 tokens/s — đủ cho viết code, thử nghiệm, hỏi đáp tri thức.

Khuyết điểm: khi tăng song song, bộ nhớ nhanh chóng cạn kiệt, chất lượng trả lời giảm nhẹ so với BF16, đặc biệt trong nhiệm vụ phức tạp.

Lưu ý: Nếu bạn dùng N card 8GB/12GB, thậm chí INT4 cũng không fit — hãy chuyển sang phương án 3 hoặc 4, đừng cố thử.

5.2 Phương án 2: Nhiều card trong máy + độ chính xác cao (BF16/FP8)

Đây là ngưỡng cơ bản để "làm dịch vụ nghiêm túc". Thiết bị: 2× 48GB A6000, 2× 80GB A100/H100, hoặc 2× 4090 ghép (PCIe chậm hơn một chút).

Lệnh như mục 3.3. Với BF16 (trọng số 60GB, 30GB/card), mỗi card còn 18GB cho KV Cache — hỗ trợ ~10 phiên ở 8K. Nếu dùng FP8 (trọng số 30GB, 15GB/card), còn lại 33GB → song song lên tới 20.

Đối với hầu hết nhóm nhỏ, mức này là đủ dùng.

5.3 Phương án 3: Chạy CPU thuần – cứu cánh khi không có GPU

Trường hợp cần chạy mà không có GPU: máy nội bộ không có card, CI, hoặc kiểm tra tạm thời.

VLLM_CPU_KVCACHE_SPACE=8 \
vllm serve deepseek-ai/DeepSeek-V4.1-Flash-AWQ \
  --device cpu \
  --max-model-len 2048 \
  --quantization awq

VLLM_CPU_KVCACHE_SPACE chỉ định bộ nhớ cho KV Cache. Nếu không set, mặc định quá nhỏ, chỉ dài một chút là lỗi. Thực tế, tốc độ ~2–5 tokens/s — chỉ dùng để kiểm tra API, test khói, không thể dùng cho dịch vụ chính.

Coi đây là giải pháp cứu hộ khi không có GPU, đừng kỳ vọng.

5.4 Phương án 4: Ollama – lựa chọn cho người không chuyên

Nếu các lệnh khiến bạn đau đầu, Ollama là lựa chọn cuối cùng. Nó đóng gói download, lượng hóa, suy luận thành một lệnh duy nhất, hỗ trợ macOS, Windows, Linux, thậm chí chạy tốt trên Mac với unified memory:

ollama run deepseek-v4.1-flash

Nếu model chưa có trong thư viện, có thể kéo file GGUF từ HuggingFace, tạo Modelfile:

ollama create v4flash -f Modelfile

Ưu điểm: cực kỳ dễ dùng, sẵn sàng giao diện OpenAI (default port 11434), rất tiện cho laptop cá nhân. Nhược điểm: kiểm soát song song, điều chỉnh bộ nhớ, hàng đợi request yếu. Khi chuyển từ "dùng cá nhân" sang "dùng cho nhóm", vẫn nên quay về vLLM/SGLang.

5.5 So sánh 4 phương án

Phương án	Yêu cầu thiết bị	Độ chính xác	Năng lực song song	Độ dễ dùng	Phù hợp với ai
Card tiêu chuẩn + lượng hóa	24GB card tiêu chuẩn	INT4	Thấp (2–4)	Trung bình	Phát triển cá nhân, thí nghiệm
Nhiều card + độ chính xác cao	2× 48GB trở lên	BF16/FP8	Trung cao	Trung bình	Dịch vụ nhóm chính thức
Chạy CPU thuần	RAM lớn	INT4	Cực thấp	Thấp	Test, cứu hộ
Ollama	Bất kỳ máy có RAM	GGUF	Thấp	Cực thấp	Người dùng cá nhân

Thú vị: một số người hỏi có chạy được trên Ascend hay RK3588 không. Ascend được, vLLM có hỗ trợ backend, nhưng cần cài CANN, dùng image dựng riêng — phức tạp hơn. RK3588: khuyên nên bỏ cuộc. Trọng số Flash quá lớn, mật độ tính toán quá cao so với SoC viễn thông, hỗ trợ toán tử phải cross-compile thủ công — dự án không kiểm soát được, người mới đừng thử.

6. Kinh nghiệm thực tế: Từ lỗi khởi động đến OOM – chuỗi xử lý lỗi

6.1 Lỗi "Model class not found": Nguyên nhân gốc rễ

Đây là lỗi phổ biến nhất khi triển khai mô hình mới. Ví dụ: ValueError: Model class MiniMaxH3ModularPipeline not found. Bản chất: phiên bản framework quá cũ, không nhận diện được kiến trúc mô hình.

Khi gặp lỗi này, đừng vội nghi ngờ lệnh sai. Theo trình tự sau:

1. Chú ý tên lớp mô hình trong thông báo lỗi, ví dụ: MiniMaxH3ForCausalLM, Qwen2MoeForCausalLM.
2. Truy cập trang HuggingFace, mở file config.json, tìm trường architectures để xác nhận kiến trúc thực tế.
3. So sánh với phiên bản pip show vllm (hoặc sglang). Tìm trong changelog: kiến trúc này được hỗ trợ từ phiên bản nào?
4. Cập nhật framework: dùng pip install -U vllm hoặc pip install -U "sglang[all]".
5. Nếu mô hình cần code tùy chỉnh, thêm --trust-remote-code vào lệnh.

Chuỗi này nên ghi nhớ — mỗi lần triển khai model mới, bạn sẽ cần đến nó.

6.2 Xử lý lỗi "CUDA out of memory"

OOM là sự cố phổ biến nhất. Gợi ý: tuân thủ thứ tự sau, đừng nhảy vào thay đổi tham số ngẫu nhiên:

1. nvidia-smi: Kiểm tra trạng thái bộ nhớ. Nhiều người quên kill process cũ, bộ nhớ đã bị chiếm một nửa, mới khởi động là OOM — đừng đổ lỗi cho mô hình.
2. Xác nhận không còn process nào, kiểm tra xem trọng số có fit không. Nếu trọng số 60GB mà chỉ có 24GB, dù có chỉnh tham số cũng vô ích — chuyển sang phương án khác.
3. Trọng số fit nhưng khởi động liền OOM → giảm --gpu-memory-utilization (vLLM) hoặc --mem-fraction-static (SGLang), từ 0.9 xuống 0.8 hoặc 0.7.
4. Dịch vụ khởi động được nhưng chạy giữa chừng OOM → do KV Cache quá tải. Giảm --max-model-len và --max-num-seqs — hai tham số này trực tiếp ảnh hưởng đến bộ nhớ.
5. Đã thử hết mà vẫn sập → kiểm tra xem có phải lỗi ngẫu nhiên không. Có thể do một request siêu dài. Thêm --max-num-seqs và timeout request để chặn các request bất thường.

Thực hiện 5 bước này, 90% lỗi OOM đều được xác định nguyên nhân, không phải mò mẫm.

6.3 "Khởi động một lần thì có chạy mãi không?"

Nhiều người thắc mắc: "Kafka producer chạy một lần có chạy mãi không?" Câu hỏi này cũng đúng với mô hình. Khi chạy vllm serve, terminal không thoát → tưởng bị treo, thực tế là bình thường.

Dịch vụ suy luận là một tiến trình nền, giống Kafka producer/consumer, chạy trong vòng lặp chờ yêu cầu. Nó sẽ chạy mãi cho đến khi bạn nhấn Ctrl+C. Cách làm đúng: chạy lệnh trong nohup, systemd, hoặc container — đừng để một terminal chờ suốt.

6.4 Triển khai nhiều mô hình cùng lúc: Hai cách tiếp cận

vLLM hiện tại chỉ hỗ trợ một engine cho một mô hình. Muốn chạy V4.1 Flash và một mô hình khác cùng lúc, chỉ có hai cách:

• Nhiều instance – nhiều port: Chạy hai tiến trình vLLM ở port 8000 và 8001, mỗi cái load một mô hình. Ưu: tách biệt hoàn toàn, một cái sập không ảnh hưởng đến cái kia. Nhược: phải phân bổ bộ nhớ trước.
• Gateway trung gian: Dùng proxy phía trước, dựa vào trường model trong request để chuyển hướng. Phù hợp khi muốn đưa ra một endpoint duy nhất, nhưng thêm một lớp proxy → thêm độ trễ.

Kinh nghiệm: trừ khi bộ nhớ cực kỳ hạn chế, đừng cố gom hai mô hình vào cùng một GPU — tranh chấp KV Cache gây jitter hiệu năng, khó debug.

6.5 Một vài mẹo nhỏ nhưng thiết thực

• SGLang khởi động sập mà không báo OOM? Đầu tiên kiểm tra xem port 30000 có bị chiếm không — nhiều công cụ giám sát dùng port này. Thử đổi sang 30001 hoặc 8080.
• SGLang phụ thuộc flashinfer, rất nhạy với phiên bản PyTorch. Sau khi nâng cấp PyTorch, nhớ cập nhật flashinfer — nếu không, có thể gặp lỗi toán tử không khớp.
• Khi bộ nhớ đủ, có thể bật --enable-prefix-caching trong vLLM — giúp giảm tính toán lặp lại trong hội thoại nhiều vòng, tác động nhỏ.
• Sau khi triển khai, nên chạy kiểm thử toàn chuỗi bằng hey hoặc wrk gửi request đến /v1/chat/completions — kiểm tra xem hiệu năng song song thực tế có khớp với ngân sách bộ nhớ không. Tôi đã thấy nhiều người triển khai xong liền nhận task, đến khi lên tải thì OOM — lúc đó xử lý rất khó.

Hệ thống hiện tại tôi dùng: dịch vụ chính dùng vLLM + FP8 trên hai card, prototype RAG dùng SGLang để tận dụng tốc độ tái sử dụng tiền tố. Hệ thống này đã chạy ổn định và linh hoạt suốt vài tháng. Nếu bạn đang chuẩn bị triển khai V4.1 Flash, hãy đọc kỹ hướng dẫn này, tính toán rõ ngân sách bộ nhớ trước, chọn phương án phù hợp — khả năng gặp lỗi sẽ giảm đáng kể.