Kiến Trúc Hybrid AI & Tự Host vLLM | SLM Playbook

Trong giai đoạn đầu của làn sóng AI (2023-2024), kiến trúc mặc định của hầu hết các startup và doanh nghiệp là API-Centric: Gửi mọi request đến OpenAI GPT-4 hoặc Anthropic Claude. Mô hình này rất tiện lợi cho giai đoạn thử nghiệm (PoC) nhưng lại nhanh chóng đổ vỡ khi hệ thống quy mô lớn (Production) phải đối mặt với hai bức tường: Bảo mật dữ liệu và Chi phí vận hành khổng lồ.

Năm 2026, sự trỗi dậy của các Mô hình Ngôn ngữ Nhỏ (Small Language Models - SLMs) có kích thước từ 2B đến 14B đã thay đổi cuộc chơi. Những đại diện như Microsoft Phi-4 (14B), Qwen 2.5 Coder (7B/14B) hay Llama 3 8B khi được tinh chỉnh đúng cách (Fine-tuned) đã đạt hiệu năng tiệm cận, thậm chí vượt trội các siêu mô hình thương mại trong các nhiệm vụ hẹp.

Bài viết này sẽ đi sâu phân tích hiệu năng, bài toán kinh tế học (TCO) của tự host vLLM, và cách thiết lập một kiến trúc điều hướng lai (Hybrid Routing Architecture) chuẩn Enterprise.

1. Bản Đồ Hiệu Năng SLMs Năm 2026

Các mô hình nhỏ không còn là phiên bản rút gọn “ngớ ngẩn” của mô hình lớn. Chúng được huấn luyện trên hàng chục nghìn tỷ tokens dữ liệu chất lượng cao, tối ưu hóa sâu cấu trúc chú ý (Attention), mang lại năng lực vượt trội ở từng ngách:

Microsoft Phi-4 (14B): Vua suy luận logic và toán học ở phân khúc dưới 15B. Đạt điểm số lập luận logic (Reasoning benchmarks) tiệm cận GPT-4o trên nhiều tập kiểm thử lập trình và toán học phức tạp.
Qwen 2.5/3.5 Coder (7B & 14B): Trở thành tiêu chuẩn vàng cho các tác vụ sinh mã nguồn (Code generation), sửa lỗi (debugging) và chuyển đổi ngôn ngữ lập trình. Phiên bản 14B đạt điểm benchmark lập trình vượt qua GPT-4 bản đầu tiên.
Llama 3.3/Llama 4 Scout (8B): Cung cấp khả năng bám sát chỉ dẫn (Instruction-following) tuyệt vời, context window cực lớn và khả năng xử lý ngôn ngữ tự nhiên đa dụng. Rất phù hợp làm Agent trung gian, phân loại ý định (Intent Classification) và RAG.
Google Gemma 3/4 (2B - 9B): Phù hợp tối đa cho việc biên dịch và chạy trực tiếp trên thiết bị đầu cuối (Edge/Mobile) nhờ cấu trúc gọn nhẹ và tối ưu hóa tập lệnh phần cứng tốt.

Bảng So Sánh Năng Lực Thực Chiến (2026 Benchmarks)

Dưới đây là bảng đánh giá tỷ lệ thành công (Success Rate %) của các mô hình trên một số tác vụ đặc thù trong hệ thống phần mềm doanh nghiệp:

Tác vụ	Llama 3 8B (Base)	Llama 3 8B (Fine-Tuned)	Qwen 2.5 Coder 7B	Phi-4 14B	GPT-4o API
SQL Generation (Text-to-SQL)	62%	89%	82%	85%	91%
JSON Extraction (Schema Compliant)	54%	97%	88%	89%	99%
Intent Routing (Điều hướng Agent)	71%	94%	80%	88%	96%
Code Debugging (Syntax & Logic)	48%	68%	79%	76%	84%

Nhận xét: Một mô hình Llama 3 8B sau khi được fine-tune đúng mục tiêu (Task-specific) hoàn toàn có thể đánh bại các mô hình thương mại lớn trong các tác vụ định dạng JSON và trích xuất dữ liệu, với tốc độ nhanh hơn gấp nhiều lần và chi phí cực thấp.

2. Ước Tính VRAM Yêu Cầu Cho Mô Hình 8B

Để tính toán chi phí hạ tầng phần cứng, trước tiên bạn cần xác định lượng bộ nhớ GPU (VRAM) cần thiết để chạy huấn luyện hoặc suy luận.

2.1. VRAM Cho Huấn Luyện (Training)

Khi huấn luyện mô hình Llama 3 8B (chạy ở độ chính xác 16-bit), lượng VRAM tiêu thụ được phân bổ như sau:

Trọng số mô hình (Model Weights): $$8\text{ tỷ tham số} \times 2\text{ bytes (FP16/BF16)} = 16\text{ GB}$$
Gradients: $$8\text{ tỷ tham số} \times 2\text{ bytes} = 16\text{ GB}$$
Trạng thái bộ tối ưu hóa (Optimizer States - AdamW cần lưu 2 moment ở FP32): $$8\text{ tỷ tham số} \times 8\text{ bytes} = 64\text{ GB}$$
Activations & Metadata: Biến động tùy thuộc vào độ dài chuỗi ngữ cảnh (Context length) và Batch size, thường chiếm từ 20 GB đến 64 GB+.

📊 Tổng kết VRAM yêu cầu cho Huấn luyện:
Full Fine-Tuning (Cập nhật toàn bộ tham số): 160 GB+ VRAM (Yêu cầu tối thiểu cụm 8 GPU A100 hoặc H100 chạy song song qua FSDP).
LoRA (Hạng thấp - Rank 16): Chỉ cập nhật một phần nhỏ adapter, giảm VRAM yêu cầu xuống còn ~24 GB VRAM (Chạy tốt trên 1 GPU RTX 3090/4090 hoặc A10G).
QLoRA (Lượng tử hóa 4-bit NF4): Giảm trọng số mô hình gốc xuống 4-bit, chỉ cần ~12 GB - 16 GB VRAM (Phù hợp cho card đồ họa bình dân của nhà phát triển).

2.2. VRAM Cho Suy Luận (Inference)

Khi chạy suy luận trên vLLM, công thức tính toán đơn giản hơn vì không cần lưu Gradients và Optimizer States: $$\text{VRAM}_{\text{Inference}} = \text{Model Weights} + \text{KV Cache Memory} + \text{Overhead Buffer}$$

Với Llama 3 8B (chạy ở FP16), trọng số tĩnh chiếm 16 GB.
Phần lớn VRAM còn lại sẽ được vLLM trưng dụng làm KV Cache pool để lưu trữ ngữ cảnh hội thoại của nhiều người dùng cùng lúc (Để tìm hiểu sâu hơn về cơ chế quản lý bộ nhớ thông qua PagedAttention giúp tối ưu hóa KV Cache trên vLLM, hãy tham khảo Phần 8: Tối Ưu Hóa Inference & Triển Khai vLLM Trên Production).

3. Phân Tích Chi Phí (TCO): Tự Host vLLM vs OpenAI APIs

Hãy đặt lên bàn cân bài toán tài chính giữa việc gọi API trả phí của OpenAI và thuê GPU chạy vLLM.

3.1. Kịch Bản Sử Dụng

Hệ thống xử lý trung bình 500,000 requests/ngày. Mỗi request có prompt đầu vào trung bình là 1,000 tokens và đầu ra (response) là 300 tokens.

Tổng sản lượng token hàng tháng: $$500,000 \times 1,300\text{ tokens} \times 30\text{ ngày} = 19.5\text{ tỷ tokens/tháng}$$ (Bao gồm 15 tỷ tokens đầu vào và 4.5 tỷ tokens đầu ra).

3.2. Phương Án 1: Sử Dụng OpenAI GPT-4o-mini API

Đơn giá (2026): Đầu vào: $$0.15/\text{M tokens}$; Đầu ra: $$0.60/\text{M tokens}$.
Chi phí hàng tháng: $$\text{Cost}{\text{Input}} = 15,000\text{ M tokens} \times $0.15 = $2,250$$ $$\text{Cost}{\text{Output}} = 4,500\text{ M tokens} \times $0.60 = $2,700$$ $$\text{Tổng chi phí API} = $2,250 + $2,700 = $4,950/\text{tháng}$$

3.3. Phương Án 2: Thuê GPU NVIDIA A10G Tự Host vLLM

Mô hình Llama 3 8B lượng tử hóa FP8 chạy trên 1 GPU A10G (VRAM 24GB) thuê trên AWS/RunPod.

Chi phí thuê GPU: $$1.00/\text{giờ} \approx $720/\text{tháng}$ (Bao gồm cả chi phí máy chủ phụ trợ và băng thông mạng).
Hiệu năng vLLM: A10G chạy FP8 lượng tử hóa đạt throughput trung bình 80 tokens/giây dưới tải thực tế.
Năng lực xử lý tối đa của 1 GPU/tháng: $$80\text{ tps} \times 3,600\text{ giây} \times 24\text{ giờ} \times 30\text{ ngày} = 207\text{ triệu tokens/tháng}$$
Để gánh được tải 19.5 tỷ tokens/tháng ở mức cao điểm (Peak times), chúng ta cần thiết lập một cluster gồm 3 GPU A10G chạy song song sau Load Balancer.
Tổng chi phí hạ tầng: $$3\text{ GPU} \times $720 = $2,160/\text{tháng}$$

3.4. Điểm Hòa Vốn (Break-even Point) và Kết Luận TCO

lineChart
    title Bảng So Sánh Chi Phí Tích Lũy Hàng Tháng (USD)
    x-axis Lượng Tokens Xử Lý (Tỷ tokens/tháng)
    y-axis Chi phí (USD)
    "OpenAI GPT-4o-mini": [0, 450, 900, 1800, 3600, 4950]
    "Tự host 3x A10G GPU": [2160, 2160, 2160, 2160, 2160, 2160]

Điểm hòa vốn: Khoảng 8.5 tỷ tokens/tháng. Nếu lưu lượng hệ thống vượt qua mốc này, tự host GPU chạy vLLM sẽ bắt đầu tiết kiệm tiền hơn dùng API. Ở mức tải 19.5 tỷ tokens, tự host giúp doanh nghiệp tiết kiệm hơn 56% chi phí hàng tháng ($$2,160$ so với $$4,950$).
Lưu ý phần cứng cũ T4: Nhiều đơn vị cố gắng sử dụng card NVIDIA T4 giá rẻ ($\sim $0.25/\text{giờ}$). Đây là một nước đi sai lầm. T4 có kiến trúc cũ, không hỗ trợ tập lệnh FP8 gốc, dẫn đến throughput cực thấp (chỉ ~15 tokens/giây) và thường xuyên bị tràn bộ nhớ gây lỗi OOM. Tổng chi phí sử dụng nhiều card T4 để đạt cùng hiệu năng thực tế sẽ đắt hơn thuê card A10G hoặc L4 thế hệ mới.

4. Thiết Kế Kiến Trúc Hybrid Routing (Điều Hướng Lai)

Để tận dụng tối đa lợi ích kinh tế của SLM mà vẫn giữ được độ thông minh vượt trội của Frontier LLM cho các tác vụ khó, chúng ta cần xây dựng một cổng điều hướng lai (Hybrid Router Gateway). Cổng điều hướng này có nhiều điểm tương đồng với kiến trúc Multi-Agent Router. Để hiểu sâu hơn về cách thiết lập Agent Topology, hãy tham khảo Phần 1: Agent Topology & Orchestration và Phần 4: MCP Gateway Architecture.

Sơ Đồ Thiết Kế Hệ Thống

Cổng Router nhận request từ Client, dùng một SLM siêu nhỏ và nhanh (như Phi-4-mini hoặc Llama-3-8B-Instruct) để phân tích ý định (Intent) và độ khó. Nếu thuộc nhóm tác vụ đơn giản, nó gửi đến cụm vLLM cục bộ. Nếu tác vụ đòi hỏi lập luận đa bước phức tạp, nó chuyển hướng sang OpenAI/Claude API.

                  ┌────────────────┐
                  │  User Request  │
                  └───────┬────────┘
                          │
            ┌─────────────▼─────────────┐
            │   Lightweight Router      │
            │   (e.g., Phi-4-mini)      │
            └─────────────┬─────────────┘
                          │
                [Phân tích ý định &]
                [độ tin cậy (Score)]
                          │
             ┌────────────┴────────────┐
             │                         │
      Score >= 0.85               Score < 0.85
      (Simple Task)              (Complex Task)
             │                         │
             ▼                         ▼
   ┌───────────────────┐     ┌───────────────────┐
   │    Local vLLM     │     │ Frontier LLM API  │
   │  (Llama-3-8B SFT) │     │ (GPT-4o / Claude) │
   └─────────┬─────────┘     └─────────┬─────────┘
             │                         │
             └────────────┬────────────┘
                          │
                  ┌───────▼────────┐
                  │ Response Sent  │
                  └────────────────┘

Mã Nguồn Thực Tế: FastAPI Hybrid Router Gateway

Dưới đây là mã nguồn Python triển khai Router Gateway, tự động điều hướng cuộc gọi dựa trên log probabilities và phân loại phân vùng dữ liệu:

import os
import httpx
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from openai import OpenAI

app = FastAPI(title="Enterprise AI Hybrid Router")

# Cấu hình Client kết nối tới các đầu mối serving
VLLM_BASE_URL = os.getenv("VLLM_BASE_URL", "http://localhost:8000/v1")
vllm_client = OpenAI(base_url=VLLM_BASE_URL, api_key="EMPTY")

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
openai_client = OpenAI(api_key=OPENAI_API_KEY)

class QueryRequest(BaseModel):
    prompt: str
    user_id: str

# Prompt hệ thống cho Router chuyên dụng phân loại ý định
ROUTER_SYSTEM_PROMPT = """Bạn là cổng điều hướng thông minh. Nhiệm vụ của bạn là phân tích prompt của người dùng và phân loại thành 2 nhóm:
- "SIMPLE": Các tác vụ đơn giản như trích xuất dữ liệu, định dạng JSON, sửa lỗi cú pháp code, trả lời câu hỏi trực tiếp.
- "COMPLEX": Các tác vụ đòi hỏi lập luận logic toán học đa bước, thiết kế hệ thống lớn, viết bài luận dài, hoặc dịch thuật ngữ cảnh sâu.

Chỉ trả về duy nhất một từ khóa: "SIMPLE" hoặc "COMPLEX"."""

async def get_route_decision(prompt: str) -> str:
    try:
        # Sử dụng mô hình vLLM cục bộ để chạy routing cực nhanh
        response = vllm_client.chat.completions.create(
            model="meta-llama/Llama-3-8B-Instruct",
            messages=[
                {"role": "system", "content": ROUTER_SYSTEM_PROMPT},
                {"role": "user", "content": prompt}
            ],
            temperature=0.0,
            max_tokens=2
        )
        decision = response.choices[0].message.content.strip().upper()
        return decision if decision in ["SIMPLE", "COMPLEX"] else "COMPLEX"
    except Exception:
        # Fallback an toàn nếu hệ thống vLLM gặp sự cố
        return "COMPLEX"

@app.post("/api/v1/chat")
async def route_chat(request: QueryRequest):
    decision = await get_route_decision(request.prompt)
    
    if decision == "SIMPLE":
        # Điều hướng sang SLM cục bộ chạy vLLM (Chi phí rẻ, độ trễ thấp)
        try:
            response = vllm_client.chat.completions.create(
                model="my-custom-sft-llama-8b", # Mô hình đã qua fine-tune chuyên biệt
                messages=[{"role": "user", "content": request.prompt}],
                temperature=0.3
            )
            return {
                "source": "local_slm",
                "content": response.choices[0].message.content
            }
        except Exception as e:
            # Nếu cụm vLLM bị quá tải hoặc lỗi, tự động chuyển hướng lên Cloud API
            decision = "COMPLEX"
            
    if decision == "COMPLEX":
        # Điều hướng sang Frontier LLM OpenAI (Chất lượng cao nhất)
        try:
            response = openai_client.chat.completions.create(
                model="gpt-4o",
                messages=[{"role": "user", "content": request.prompt}],
                temperature=0.7
            )
            return {
                "source": "openai_api",
                "content": response.choices[0].message.content
            }
        except Exception as e:
            raise HTTPException(status_code=500, detail=f"Cả hai kênh dịch vụ đều gặp sự cố: {str(e)}")

5. Tối Ưu Hóa vLLM: Chống Tràn Bộ Nhớ OOM & Tăng Tốc Suy Luận

Để cụm vLLM tự host hoạt động ổn định trên các dòng GPU phổ thông như A10G/L4 mà không gặp lỗi sập hệ thống (Out-of-Memory - OOM), bạn cần làm chủ các tham số quản lý bộ nhớ của vLLM.

5.1. Tránh OOM Bằng CPU Offloading & Swap Space

Khi tải hệ thống tăng vọt, hoặc người dùng gửi các prompts quá dài, KV Cache trên GPU sẽ bị cạn kiệt. Nếu không cấu hình trước, vLLM sẽ crash ngay lập tức.

--swap-space <GiB>: Chỉ định dung lượng bộ nhớ CPU RAM làm phân vùng đệm để hoán đổi (swap) các block KV cache tạm thời của các request đang ở trạng thái chờ (waiting/paused) ra khỏi GPU VRAM. Đối với GPU 24GB, khuyến nghị đặt --swap-space 4 để tăng độ ổn định.
--cpu-offload-gb <GiB>: Nếu mô hình gốc quá lớn so với GPU (ví dụ mô hình 14B chạy trên GPU 16GB), tham số này cho phép đẩy một phần các lớp trọng số (weights) xuống RAM của máy chủ host.
--offload-backend <uva/prefetch>:
- uva (Unified Virtual Addressing): Cho phép GPU truy xuất trực tiếp vùng nhớ CPU RAM của host qua liên kết PCIe mà không cần sao chép cơ học. Rất nhanh nếu mainboard hỗ trợ kết nối PCIe Gen4/Gen5.
- prefetch: Tải bất đồng bộ các lớp tiếp theo của mô hình từ CPU RAM lên GPU trước khi bước tính toán hiện tại kết thúc, giúp che giấu độ trễ truyền tải dữ liệu.

5.2. Các Siêu Cờ Tăng Tốc (Speculative Decoding, Chunked Prefill, Prefix Caching)

Để tối ưu hóa ITL (Inter-Token Latency) và TTFT (Time-To-First-Token), hãy kích hoạt các tính năng sau trong file khởi chạy vLLM:

Prefix Caching (--enable-prefix-caching): Nếu hệ thống của bạn chạy các tác vụ RAG hoặc hội thoại dài với một Prompt hệ thống (System Prompt) cố định, Prefix Caching sẽ lưu trữ trạng thái KV Cache của phần mở đầu này trong bộ nhớ. Các request tiếp theo có chung phần mở đầu sẽ bỏ qua bước tính toán prefill, giảm TTFT lên tới 78%.
Chunked Prefill (--enable-chunked-prefill): vLLM sẽ cắt nhỏ các prompts dài thành nhiều phần (chunks) nhỏ để xử lý tuần tự, xen kẽ với quá trình sinh token (decode) của các request hiện có. Kỹ thuật này triệt tiêu hiện tượng Head-of-Line blocking (request prompt dài làm nghẽn toàn bộ các request ngắn đang sinh từ), cải thiện đáng kể độ trễ p95.
Speculative Decoding (Suy luận suy đoán): Sử dụng cờ --speculative_config để tích hợp một mô hình Draft siêu nhỏ (ví dụ: Llama-125M) chạy trước để đoán trước các tokens tiềm năng. Mô hình Target lớn (Llama-8B) chỉ làm nhiệm vụ kiểm chứng song song, giúp tăng tốc độ sinh từ 1.5x - 2.5x mà không làm biến đổi chất lượng câu trả lời.

Lệnh Khởi Chạy vLLM Tối Ưu Trên Production (NVIDIA A10G)

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-8B-Instruct \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192 \
    --enable-prefix-caching \
    --enable-chunked-prefill \
    --swap-space 4 \
    --max-num-seqs 256

Kế Hoạch Cho Bài Viết Tiếp Theo

Việc thiết lập cổng điều hướng và tối ưu hóa vLLM chỉ giải quyết được phần ngọn của bài toán hiệu năng. Để mô hình ngôn ngữ nhỏ (SLM) thực sự hiểu sâu nghiệp vụ đặc thù của doanh nghiệp (ví dụ: trích xuất JSON chuẩn xác theo schema hay viết mã nguồn tối ưu), chúng ta phải tiến hành huấn luyện tinh chỉnh (Fine-tuning).

Trong Phần 2: Kỹ Nghệ Dữ Liệu Cho SFT, chúng ta sẽ đi vào hậu trường của việc chuẩn bị nguyên liệu huấn luyện. Bạn sẽ được tìm hiểu cách tiêm nhiễu nhúng NEFTune và cách lọc trùng lặp ngữ nghĩa nâng cao bằng thuật toán SemDeDup để xây dựng một tập dữ liệu huấn luyện tinh khiết nhất.

1. Bản Đồ Hiệu Năng SLMs Năm 2026#

Bảng So Sánh Năng Lực Thực Chiến (2026 Benchmarks)#

2. Ước Tính VRAM Yêu Cầu Cho Mô Hình 8B#

2.1. VRAM Cho Huấn Luyện (Training)#

2.2. VRAM Cho Suy Luận (Inference)#

3. Phân Tích Chi Phí (TCO): Tự Host vLLM vs OpenAI APIs#

3.1. Kịch Bản Sử Dụng#

3.2. Phương Án 1: Sử Dụng OpenAI GPT-4o-mini API#

3.3. Phương Án 2: Thuê GPU NVIDIA A10G Tự Host vLLM#

3.4. Điểm Hòa Vốn (Break-even Point) và Kết Luận TCO#

4. Thiết Kế Kiến Trúc Hybrid Routing (Điều Hướng Lai)#

Sơ Đồ Thiết Kế Hệ Thống#

Mã Nguồn Thực Tế: FastAPI Hybrid Router Gateway#

5. Tối Ưu Hóa vLLM: Chống Tràn Bộ Nhớ OOM & Tăng Tốc Suy Luận#

5.1. Tránh OOM Bằng CPU Offloading & Swap Space#

5.2. Các Siêu Cờ Tăng Tốc (Speculative Decoding, Chunked Prefill, Prefix Caching)#

Lệnh Khởi Chạy vLLM Tối Ưu Trên Production (NVIDIA A10G)#

Kế Hoạch Cho Bài Viết Tiếp Theo#