1. Nút Cổ Chai Của LLM: Tại Sao GPU Vẫn Thất Nghiệp?

Sau khi thiết kế xong toàn bộ kiến trúc Agent ở 7 phần trước, đến lúc bạn đưa hệ thống lên Production (chạy thực tế). Mọi start-up đều sớm nhận ra một sự thật cay đắng: Kẻ thù của LLM không phải là Sức mạnh tính toán (Compute), mà là Băng thông bộ nhớ (Memory Bandwidth).

Để chạy mô hình Llama-3 70B (chuẩn FP16), bạn cần khoảng 140GB VRAM chỉ để chứa mô hình. Nhưng khi có 100 User cùng gửi prompt, hệ thống phải sinh ra một vùng nhớ tạm gọi là KV Cache để giữ lại bối cảnh của 100 cuộc hội thoại đó. Ngay lập tức, KV Cache phình to ra và ăn cạn bộ nhớ VRAM còn lại. Hệ thống báo lỗi Out-Of-Memory (OOM) và sụp đổ, mặc dù sức mạnh xử lý của GPU lúc đó chỉ mới xài hết 30%. Làm sao để “nhồi” nhiều User hơn vào GPU mà không bị tràn RAM?

2. Phép Màu Mang Tên PagedAttention & vLLM

Năm 2026, vLLM đã trở thành tiêu chuẩn vàng không thể thay thế cho Inference (TGI của HuggingFace đã bước vào chế độ bảo trì). Trái tim của vLLM là công nghệ PagedAttention.

Trước đây, hệ thống cấp phát bộ nhớ KV Cache thành những khối dài liên tục. Vì không biết User sẽ chat câu dài hay ngắn, hệ thống phải “đặt cọc” trước một vùng nhớ rất lớn, gây lãng phí và phân mảnh lên tới 60%. PagedAttention mượn ý tưởng từ Hệ điều hành (Virtual Memory): Nó chia KV Cache thành các “Trang” (Pages) nhỏ bằng nhau. Chỉ khi nào User sinh ra Token mới thì nó mới cấp phát thêm trang.

  • Kết quả: Sự phân mảnh bộ nhớ giảm xuống gần 0%. Cùng một dàn GPU, vLLM có thể chịu tải lượng User (Concurrency) gấp 4 lần so với kiến trúc cũ.

3. Nghệ Thuật Nhồi Băng Chuyền: Continuous Batching

Nếu bạn dùng kiến trúc cũ (Static Batching), Server sẽ gom 10 người dùng lại, chờ cả 10 người hỏi xong mới cho GPU trả lời. Ai hỏi câu ngắn sẽ phải chờ người hỏi câu dài. GPU phải chịu cảnh “chờ đợi”, cực kỳ lãng phí.

vLLM sử dụng Continuous Batching (In-flight Batching). Mọi thứ được xử lý ở cấp độ Từng Token:

  1. GPU đang bận rộn xử lý cho 10 User.
  2. User A vừa nhận xong chữ cuối cùng của câu trả lời. Vị trí của User A (Slot) lập tức bị trống.
  3. Trong chưa tới 1 mili-giây, Hệ thống bế User B từ hàng đợi (Queue) nhét ngay vào Slot trống đó. GPU không có 1 giây nào được nghỉ ngơi. Hiệu suất sử dụng (Utilization) luôn ở mức >90%, tối đa hóa từng đồng tiền điện bạn bỏ ra.

4. Ép Cân Mô Hình (Quantization): FP8 và AWQ

Không một Doanh nghiệp nào đủ giàu để chạy LLM 70B ở định dạng FP16 nguyên bản. Bạn phải ép cân (Quantize) mô hình xuống để nhét vừa vào GPU rẻ hơn.

  • Chuẩn mực Doanh nghiệp (NVIDIA H100 / Blackwell): Sử dụng FP8. Với các dòng GPU đời mới, FP8 được hỗ trợ ở cấp độ phần cứng (Hardware Tensor Cores). Ép xuống 8-bit giúp cắt giảm một nửa dung lượng RAM, tăng tốc độ xử lý lên x1.5 lần, mà chất lượng suy luận (Reasoning) gần như lossless (không giảm sút).
  • Tiết kiệm ngân sách (RTX 4090 / A100): Sử dụng AWQ (INT4). Bóp mô hình xuống 4-bit sẽ giảm 75% dung lượng VRAM. Bạn phải chấp nhận hy sinh một chút sự logic của mô hình, nhưng bù lại, bạn có thể chạy model 70B trên cấu hình GPU siêu rẻ. Đừng dùng GGUF trên Server, nó chỉ dành cho chạy local.

5. Phanh Thây Mô Hình: Tensor vs Pipeline Parallelism

Nếu model bị ép cân xong vẫn quá to để nhét vào 1 GPU, bạn buộc phải dùng nhiều GPU.

  • Tensor Parallelism (TP): Cắt dọc mô hình. Cả 4 GPU cùng tính toán một Layer (Lớp) cùng lúc. Giúp phản hồi cực nhanh (Low Latency). Tuy nhiên, nó đòi hỏi 4 GPU này phải nối với nhau bằng dây cáp siêu tốc (NVLink), nếu không độ trễ truyền tải sẽ giết chết hệ thống.
  • Pipeline Parallelism (PP): Cắt ngang mô hình. GPU 1 tính 20 Layer đầu, rồi ném kết quả qua GPU 2 tính 20 Layer cuối. Thích hợp khi bạn ghép các Server rẻ tiền lại với nhau qua mạng LAN, giúp tăng khả năng chịu tải (Throughput).

6. Hack Tốc Độ Bằng Speculative Decoding

Cơ chế sinh từ của LLM (Auto-regressive) rất chậm vì nó phải gõ từng chữ một. Năm 2026, Speculative Decoding (Giải mã suy đoán) là một kỹ thuật bắt buộc để tăng tốc. Thay vì bắt model khổng lồ 70B gõ từng chữ, bạn thuê một model “Nhí” siêu nhẹ (ví dụ Llama-3 1B) đoán nhanh 5 chữ tiếp theo. Sau đó, model 70B chỉ việc lướt qua 5 chữ đó, nếu thấy đúng thì “gật đầu” duyệt cả 5 chữ cùng lúc.

  • Lợi ích: Tốc độ sinh từ tăng gấp 2 đến 3 lần, trong khi độ chính xác vẫn giữ nguyên 100% của model 70B.

7. Khởi Chạy Nhanh vLLM Trên Production

Dưới đây là một lệnh (Code Snippet) tiêu chuẩn để khởi chạy Server vLLM tương thích với OpenAI API cho model 70B trên cụm 4 GPU, có ép cân FP8:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --tensor-parallel-size 4 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192 \
    --quantization fp8

8. Tổng Kết

Đưa AI lên Production không phải là ném một file Python lên Server. Nó là một cuộc chiến về kiến trúc hệ thống, nơi bạn phải dùng vLLM để quản lý bộ nhớ (PagedAttention), ép cân mô hình (FP8/AWQ), và hack tốc độ sinh từ (Speculative Decoding).

Khi hệ thống đã chạy mượt mà, câu hỏi tiếp theo là: “Làm sao để tôi biết Agent của tôi đang suy nghĩ gì? Lỡ nó làm sai thì lỗi ở bước nào?” Hãy cùng bước sang Phần 9: Agentic Observability & Monitoring để thiết lập hệ thống camera giám sát luồng suy nghĩ của AI bằng LangSmith và Langfuse.