Phần 1: Kiến Trúc Hybrid AI & Tự Host vLLM

← Chương trước: Executive Summary — Sổ Tay Tối Ưu Hóa SLM | Mục lục Series | Chương tiếp theo: Phần 2: Kỹ Nghệ Dữ Liệu Cho SFT: NEFTune & SemDeDup →

Answer-first: Kiến trúc Hybrid AI định tuyến 80% truy vấn có cấu trúc về SLM nội bộ trên vLLM trong 35ms TTFT, chỉ chuyển tiếp 20% bài toán phức tạp lên Frontier LLM qua circuit breaker. Thiết kế này cắt giảm 85% chi phí API hàng tháng và bảo toàn tuyệt đối dữ liệu PII nội bộ.

📖 Bản tiếng Anh (English Edition): Part 1: Hybrid AI Architecture & Self-Hosting vLLM

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

BLUF (Bottom Line Up Front): Các mô hình ngôn ngữ nhỏ (2B–14B) không còn là phiên bản rút gọn ngớ ngẩn mà đã đạt trạng thái chuyên môn hóa cao; mô hình 7B được fine-tune đúng bài toán hẹp đạt tỷ lệ hoàn thành 89%–99% trên SQL và JSON, đánh bại mô hình thương mại đa dụng.

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 nhanh chóng bộc lộ điểm nghẽn nghiêm trọng khi vận hành thực tế: chi phí bùng nổ và không thể kiểm soát dữ liệu PII.

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 đã mang lại sự chuyển dịch lớn. Những đại diện như Microsoft Phi-4 (14B), Qwen 2.5 Coder (7B/14B) hay Llama 3.2/3.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:

• Microsoft Phi-4 (14B): Đạt 84.8% trên benchmark lập luận logic và toán học MATH-500, vượt qua nhiều mô hình mã nguồn mở 70B và tiệm cận GPT-4o.
• Qwen 2.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 và chuyển đổi SQL. Phiên bản 7B đạt 84.1% HumanEval với tốc độ xử lý nhanh hơn 4 lần các API thương mại.
• Llama 3.3 8B: Cung cấp khả năng bám sát chỉ dẫn (instruction-following) hoàn hảo, context window 128k và khả năng xử lý ngôn ngữ tự nhiên đa dụng làm Agent trung gian.
• Google Gemma 2 / 3 (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ẹ.

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

2. Ước Tính Bộ Nhớ VRAM: Công Thức Toán Học Cho 7B–14B

BLUF (Bottom Line Up Front): VRAM phục vụ suy luận trên vLLM bao gồm trọng số mô hình cố định cộng với pool KV cache; lượng tử hóa AWQ 4-bit giảm kích thước trọng số 8B từ 16GB xuống 4.8GB, giải phóng 18GB VRAM cho KV cache để phục vụ hơn 70 luồng đồng thời trên 1 card RTX 4090/L4.

flowchart LR
    subgraph VRAMAllocation ["Phân Bổ VRAM Trên GPU 24GB (NVIDIA L4 / RTX 4090)"]
        direction TB
        Weights["Trọng Số Mô Hình (AWQ 4-bit): 4.8 GB"]
        CUDA["CUDA Context & Driver Buffer: 1.4 GB"]
        KVCache["KV Cache Pool (PagedAttention v2): 17.8 GB<br/>Hỗ trợ 75 phiên đồng thời @ 4k Context"]
    end

Công thức tính toán dung lượng KV Cache

Bộ nhớ KV Cache tiêu thụ trên mỗi token sinh ra được tính theo công thức chuẩn:

$$ ext{Memory}{ ext{KV}} = 2 imes n{ ext{layers}} imes n_{ ext{heads}} imes d_{ ext{head}} imes n_{ ext{tokens}} imes ext{precision_bytes} imes ext{batch_size}$$

Đối với mô hình Llama 3 8B ($n_{ ext{layers}} = 32$, $n_{ ext{heads}} = 32$, $d_{ ext{head}} = 128$, chạy ở độ chính xác FP16 $ ext{precision_bytes} = 2$):

• Mỗi token tiêu thụ: $2 imes 32 imes 8 imes 128 imes 2 = 131,072 ext{ bytes} pprox 128 ext{ KB/token}$ (nhờ Grouped-Query Attention với 8 KV heads).
• Với một phiên hội thoại 4,096 tokens, KV cache chiếm: $4,096 imes 128 ext{ KB} pprox 512 ext{ MB/user}$.
• Trên card đồ họa 24GB VRAM, sau khi nén mô hình xuống 4-bit AWQ (4.8GB) và trừ 1.4GB overhead hệ thống, chúng ta còn tới 17.8GB VRAM thuần cho KV Cache, cho phép phục vụ đồng thời 35–40 luồng đầy tải 4,096 tokens mà không xảy ra hiện tượng OOM.

3. Bản Thiết Kế Tầng Gateway Định Tuyến Hai Lớp (Two-Tier Routing)

BLUF (Bottom Line Up Front): Gateway định tuyến hoạt động như một reverse-proxy thông minh, đánh giá độ phức tạp và độ bất định token của truy vấn trong 3.5ms bằng mô hình phân loại nhẹ (ModernBERT/BGE-small), đảm bảo độ trễ P99 toàn hệ thống luôn dưới 45ms.

sequenceDiagram
    autonumber
    actor User as Client / User App
    participant GW as Hybrid AI Gateway (Go/FastAPI)
    participant Classifier as Fast Intent Classifier (ModernBERT)
    participant vLLM as Local SLM Engine (vLLM v0.7+)
    participant Presidio as PII Sanitizer (Presidio)
    participant Cloud as Frontier Cloud API (Claude 3.5)

    User->>GW: POST /v1/chat/completions (Prompt)
    GW->>Classifier: Trích xuất vector & phân loại ý định (< 3.5ms)
    
    alt Tác vụ nghiệp vụ xác định (80%)
        Classifier-->>GW: Intent: Structured Task (Confidence: 0.96)
        GW->>vLLM: Thực thi suy luận cục bộ (Local GPU)
        vLLM-->>GW: Output + Token Logprobs
        GW->>GW: Kiểm tra Entropy Logprob (H <= 0.82?)
        GW-->>User: Phản hồi kết quả (Latency: 28ms)
    else Tác vụ mở rộng hoặc SLM bất định (20%)
        Classifier-->>GW: Intent: Complex Open Reasoning
        GW->>Presidio: Quét và che giấu dữ liệu PII nội bộ (< 4ms)
        Presidio-->>GW: Prompt đã được làm sạch
        GW->>Cloud: Chuyển tiếp HTTPS lên Cloud API
        Cloud-->>GW: Phản hồi Frontier LLM
        GW-->>User: Phản hồi kết quả (Latency: 850ms)
    end

4. Tối Ưu Hóa vLLM Cho Môi Trường Doanh Nghiệp (vLLM v0.7+)

BLUF (Bottom Line Up Front): Kích hoạt PagedAttention v2, Chunked Prefill và Multi-Head Latent Attention (MLA) trên vLLM giúp loại bỏ 100% hiện tượng phân mảnh bộ nhớ, giữ độ trễ giữa các token (ITL) ổn định dưới 15ms ngay cả khi có các câu lệnh dài xen ngang.

Để phục vụ lưu lượng truy cập lớn trong doanh nghiệp, vLLM cần được cấu hình tối ưu với các tham số then chốt:

1. PagedAttention v2: Quản lý bộ nhớ KV Cache tương tự như bảng phân trang (page table) của hệ điều hành, chia nhỏ KV cache thành các block vật lý 16 hoặc 32 tokens. Cơ chế này giảm tỷ lệ lãng phí bộ nhớ do phân mảnh ngoài từ 70% xuống dưới 4%.
2. Chunked Prefill (--enable-chunked-prefill): Trong các hệ thống thông thường, khi một user gửi prompt dài 8k tokens, GPU sẽ dồn toàn bộ năng lực tính toán để xử lý prefill, khiến các user đang nhận stream token bị nghẽn (jitter). Chunked Prefill chia nhỏ prompt prefill thành các phần 512 tokens xen kẽ với quá trình decode, triệt tiêu hoàn toàn hiện tượng giật lag.
3. Multi-Head Latent Attention (MLA): Khi phục vụ các dòng mô hình kiến trúc DeepSeek-R1 Distill, MLA nén không gian KV cache xuống vector ẩn chiều thấp, giúp cắt giảm 85% dung lượng VRAM so với cơ chế chú ý MHA truyền thống.

File cấu hình triển khai Docker Compose sản xuất (vLLM Production)

# docker-compose.vllm.yml - Production vLLM v0.7+ Serving Stack
version: '3.8'

services:
  vllm-engine:
    image: vllm/vllm-openai:v0.7.2
    container_name: vllm-qwen-coder
    runtime: nvidia
    restart: always
    environment:
      - CUDA_VISIBLE_DEVICES=0
      - NCCL_DEBUG=INFO
    ports:
      - "8000:8000"
    volumes:
      - /opt/models/Qwen2.5-Coder-7B-Instruct-AWQ:/models/qwen-coder
      - /dev/shm:/dev/shm
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    command: >
      --model /models/qwen-coder
      --quantization awq
      --dtype half
      --gpu-memory-utilization 0.92
      --max-model-len 8192
      --max-num-batched-tokens 2048
      --enable-chunked-prefill
      --block-size 16
      --disable-log-stats
      --port 8000
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8000/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 3

5. Câu Chuyện Thất Bại Thực Chiến (Production Failure Case Study)

BLUF (Bottom Line Up Front): Một trang thương mại điện tử bị sập hoàn toàn hệ thống gợi ý giỏ hàng trong đợt Flash Sale 11/11 do cạn kiệt socket HTTP và rò rỉ bộ nhớ VRAM khi lưu lượng truy cập vọt lên 10,000 req/phút mà không bật Chunked Prefill.

Bối cảnh sự cố

Đêm 11 tháng 11 năm 2025, một sàn thương mại điện tử lớn triển khai tính năng trợ lý mua sắm AI sử dụng mô hình Llama 3 8B tự host trên cụm 4 GPU A10G. Khi chương trình Flash Sale bắt đầu lúc 00:00, lưu lượng truy cập vọt từ 200 req/phút lên 10,500 req/phút.

┌────────────────────────────────────────────────────────────────────────┐
│               SỰ CỐ NGHẼN VRAM VÀ SẬP HỆ THỐNG FLASH SALE               │
├────────────────────────────────────────────────────────────────────────┤
│ 00:01: Lưu lượng truy cập đạt đỉnh 10,500 req/phút                     │
│ 00:03: 50 người dùng gửi kèm giỏ hàng dài (>6,000 tokens)              │
│ 00:04: vLLM dồn compute vào Prefill; Decode phase bị nghẽn (ITL > 2s)  │
│ 00:05: Client timeout ở 5s; Web gateway gửi liên tiếp 15,000 retry     │
│ 00:07: Hàng đợi vLLM vượt 2,000 requests; GPU gặp sự cố CUDA OOM Crash │
│ 00:09: Toàn bộ cụm máy chủ sập; doanh thu gián đoạn 45 phút            │
└────────────────────────────────────────────────────────────────────────┘

Phân tích nguyên nhân gốc rễ (Root-Cause Autopsy)

1. Thiếu Chunked Prefill: Các truy vấn giỏ hàng dài chiếm dụng toàn bộ GPU Core trong 1.5 giây để tính toán ma trận Attention, khiến hàng nghìn truy vấn ngắn khác đang chờ sinh token bị đóng băng.
2. Cơn bão Retry từ Reverse Proxy: NGINX ingress được cấu hình timeout ngắn (5s) kết hợp tự động thử lại 3 lần. Khi vLLM phản hồi chậm, NGINX nhân bản số lượng request lên gấp 4 lần, làm sập hoàn toàn hàng đợi bộ nhớ.
3. Không giới hạn kích thước hàng đợi (max-num-seqs): vLLM tiếp tục nhận thêm request mới vào VRAM thay vì trả về mã lỗi HTTP 429 hoặc 503 ngay tại cửa ngõ, dẫn đến tràn bộ nhớ GPU driver.

Giải pháp khắc phục triệt để

• Bật cờ --enable-chunked-prefill với --max-num-batched-tokens 2048 để cân bằng giữa prefill và decode.
• Cấu hình NGINX Ingress áp dụng thuật toán Token Bucket Rate Limiting, từ chối ngay lập tức các request vượt ngưỡng quota và trả về HTTP 429 với header Retry-After.
• Tích hợp chốt chặn Circuit Breaker trên tầng Go Gateway: khi hàng đợi vLLM vượt quá 50 requests đang chờ (vllm:num_requests_waiting > 50), gateway tự động ngắt tải và chuyển tiếp lưu lượng sang Cloud API dự phòng.

6. Ma Trận Đánh Đổi Kỹ Thuật (Trade-Off Framing 2027)

Khi xây dựng bộ định tuyến cho mô hình ngôn ngữ, kiến trúc sư cần chọn lựa công nghệ phân loại phù hợp:

Kết luận kỹ thuật: Sử dụng ModernBERT hoặc BGE-small chạy trên CPU runtime (ONNX INT8) là giải pháp cân bằng hoàn hảo giữa độ trễ cực thấp (3ms) và độ chính xác phân loại ngữ nghĩa cao (96.8%).

7. Mã Nguồn Mẫu Sản Xuất: Bộ Phân Loại Ý Định Siêu Tốc (Fast Intent Router)

Dưới đây là module định tuyến hoàn chỉnh viết bằng Python sử dụng ONNX Runtime để phân loại ý định người dùng trong 3ms trước khi gửi vào vLLM:

# fast_router.py - Ultra-fast Intent Routing Engine (ONNX Runtime INT8)
import time
import numpy as np
import onnxruntime as ort
from transformers import AutoTokenizer
from typing import Tuple, Dict

class FastIntentRouter:
    def __init__(self, model_path: str = "modernbert-intent-int8.onnx", tokenizer_name: str = "answerdotai/ModernBERT-base"):
        self.tokenizer = AutoTokenizer.from_pretrained(tokenizer_name)
        # Khởi tạo ONNX Runtime session với tối ưu hóa đa luồng CPU
        opts = ort.SessionOptions()
        opts.intra_op_num_threads = 2
        opts.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL
        self.session = ort.InferenceSession(model_path, opts, providers=["CPUExecutionProvider"])
        
        self.labels = {
            0: "sql_generation",
            1: "json_extraction",
            2: "intent_triage",
            3: "complex_reasoning"  # Nhãn duy nhất cần chuyển tiếp lên Cloud
        }
        
    def route_query(self, prompt: str, threshold: float = 0.85) -> Tuple[str, float, float]:
        t0 = time.perf_counter()
        
        # 1. Tokenize văn bản với độ dài cố định ngắn để tối ưu tốc độ
        inputs = self.tokenizer(
            prompt,
            padding="max_length",
            truncation=True,
            max_length=128,
            return_tensors="np"
        )
        
        onnx_inputs = {
            "input_ids": inputs["input_ids"].astype(np.int64),
            "attention_mask": inputs["attention_mask"].astype(np.int64)
        }
        
        # 2. Chạy suy luận trên ONNX CPU
        logits = self.session.run(None, onnx_inputs)[0][0]
        
        # 3. Tính toán Softmax probabilities
        exp_logits = np.exp(logits - np.max(logits))
        probs = exp_logits / np.sum(exp_logits)
        
        pred_idx = int(np.argmax(probs))
        confidence = float(probs[pred_idx])
        latency_ms = (time.perf_counter() - t0) * 1000
        
        target_intent = self.labels.get(pred_idx, "complex_reasoning")
        
        # Nếu độ tin cậy thấp hơn ngưỡng, tự động nâng hạng lên bài toán phức tạp
        if confidence < threshold:
            target_intent = "complex_reasoning"
            
        return target_intent, confidence, latency_ms

if __name__ == "__main__":
    router = FastIntentRouter()
    intent, conf, lat = router.route_query("SELECT customer_id, SUM(amount) FROM orders GROUP BY customer_id;")
    print(f"Detected: {intent} | Confidence: {conf:.4f} | Latency: {lat:.2f}ms")

8. Hiện Thực Hóa Go 1.24 Edge Ingress Gateway với Fallback Dự Phòng

BLUF (Bottom Line Up Front): Đối với các cổng API doanh nghiệp cấp 1 xử lý >25.000 kết nối streaming đồng thời, một reverse proxy bất đồng bộ viết bằng Go 1.24 sử dụng worker connection pools mang lại overhead định tuyến dưới 1ms và streaming JSON không cấp phát bộ nhớ dư thừa.

Mặc dù Python/FastAPI phù hợp cho các bản thử nghiệm ban đầu (PoC), các tầng biên doanh nghiệp quy mô lớn đòi hỏi các runtime biên dịch được tối ưu hóa bộ thu gom rác (garbage collection). Dưới đây là hiện thực hóa proxy cấp sản xuất bằng Go 1.24, tận dụng HTTP/2 connection pooling bền vững, kiểm soát hàng đợi đồng thời qua atomic và cơ chế tự động fallback dự phòng lên Frontier LLM:

// gateway_proxy.go - High-Performance AI Ingress Gateway (Go 1.24 Standard)
package main

import (
	"bytes"
	"context"
	"encoding/json"
	"errors"
	"io"
	"log"
	"net/http"
	"os"
	"strconv"
	"sync/atomic"
	"time"
)

type RouteRequest struct {
	Prompt    string  `json:"prompt"`
	MaxTokens int     `json:"max_tokens"`
	Temp      float64 `json:"temperature"`
}

type RouteResponse struct {
	Content     string  `json:"content"`
	ServedBy    string  `json:"served_by"`
	LatencyMs   float64 `json:"latency_ms"`
	IsEscalated bool    `json:"is_escalated"`
}

// GatewayConfig parameterizes all networking, concurrency, and routing thresholds.
type GatewayConfig struct {
	LocalVLLMEndpoint   string
	FrontierAPIKey      string
	FrontierEndpoint    string
	LocalModelName      string
	FrontierModelName   string
	LocalTimeout        time.Duration
	ClientTimeout       time.Duration
	ConfidenceFloor     float64
	MaxQueueDepth       int64
	MaxIdleConns        int
	MaxIdleConnsPerHost int
	IdleConnTimeout     time.Duration
	ListenAddr          string
}

// DefaultGatewayConfig provides production-tuned baseline defaults.
func DefaultGatewayConfig() GatewayConfig {
	return GatewayConfig{
		LocalVLLMEndpoint:   "http://localhost:8000/v1",
		FrontierEndpoint:    "https://api.anthropic.com/v1/messages",
		LocalModelName:      "qwen-2.5-coder-7b-instruct-awq",
		FrontierModelName:   "claude-3-5-sonnet-20241022",
		LocalTimeout:        600 * time.Millisecond,
		ClientTimeout:       15 * time.Second,
		ConfidenceFloor:     0.84,
		MaxQueueDepth:       64,
		MaxIdleConns:        1000,
		MaxIdleConnsPerHost: 250,
		IdleConnTimeout:     90 * time.Second,
		ListenAddr:          ":8080",
	}
}

type ResilientAIGateway struct {
	cfg        GatewayConfig
	httpClient *http.Client
	queueDepth int64
}

func NewGateway(cfg GatewayConfig) *ResilientAIGateway {
	if cfg.MaxIdleConns <= 0 {
		cfg.MaxIdleConns = 1000
	}
	if cfg.MaxIdleConnsPerHost <= 0 {
		cfg.MaxIdleConnsPerHost = 250
	}
	if cfg.IdleConnTimeout <= 0 {
		cfg.IdleConnTimeout = 90 * time.Second
	}
	if cfg.ClientTimeout <= 0 {
		cfg.ClientTimeout = 15 * time.Second
	}
	if cfg.MaxQueueDepth <= 0 {
		cfg.MaxQueueDepth = 64
	}
	if cfg.ListenAddr == "" {
		cfg.ListenAddr = ":8080"
	}

	t := &http.Transport{
		MaxIdleConns:        cfg.MaxIdleConns,
		MaxIdleConnsPerHost: cfg.MaxIdleConnsPerHost,
		IdleConnTimeout:     cfg.IdleConnTimeout,
		DisableCompression:  false,
		ForceAttemptHTTP2:   true,
	}
	return &ResilientAIGateway{
		cfg: cfg,
		httpClient: &http.Client{
			Transport: t,
			Timeout:   cfg.ClientTimeout,
		},
	}
}

func (g *ResilientAIGateway) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	start := time.Now()
	if r.Method != http.MethodPost {
		http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
		return
	}

	var req RouteRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, "Malformed JSON", http.StatusBadRequest)
		return
	}

	atomic.AddInt64(&g.queueDepth, 1)
	defer atomic.AddInt64(&g.queueDepth, -1)

	var resp RouteResponse
	var err error
	if atomic.LoadInt64(&g.queueDepth) < g.cfg.MaxQueueDepth {
		resp, err = g.executeLocalSLM(r.Context(), req)
	} else {
		err = errors.New("local queue saturated, triggering fast spillover")
	}

	if err != nil {
		resp, err = g.executeCloudFrontier(r.Context(), req)
		if err != nil {
			http.Error(w, "Upstream AI Inference Exhaustion", http.StatusBadGateway)
			return
		}
	}

	resp.LatencyMs = float64(time.Since(start).Microseconds()) / 1000.0
	w.Header().Set("Content-Type", "application/json")
	w.Header().Set("X-AI-Served-By", resp.ServedBy)
	_ = json.NewEncoder(w).Encode(resp)
}

func (g *ResilientAIGateway) executeLocalSLM(ctx context.Context, req RouteRequest) (RouteResponse, error) {
	ctxTimeout, cancel := context.WithTimeout(ctx, g.cfg.LocalTimeout)
	defer cancel()

	payload, _ := json.Marshal(map[string]interface{}{
		"model":       g.cfg.LocalModelName,
		"prompt":      req.Prompt,
		"max_tokens":  req.MaxTokens,
		"temperature": req.Temp,
	})

	httpReq, err := http.NewRequestWithContext(ctxTimeout, "POST", g.cfg.LocalVLLMEndpoint+"/completions", bytes.NewReader(payload))
	if err != nil {
		return RouteResponse{}, err
	}
	httpReq.Header.Set("Content-Type", "application/json")

	res, err := g.httpClient.Do(httpReq)
	if err != nil {
		return RouteResponse{}, err
	}
	defer res.Body.Close()

	if res.StatusCode != http.StatusOK {
		return RouteResponse{}, errors.New("non-200 local vllm response")
	}

	var vllmOut struct {
		Choices []struct {
			Text string `json:"text"`
		} `json:"choices"`
	}
	if err := json.NewDecoder(res.Body).Decode(&vllmOut); err != nil || len(vllmOut.Choices) == 0 {
		return RouteResponse{}, errors.New("failed to parse local output")
	}

	return RouteResponse{
		Content:     vllmOut.Choices[0].Text,
		ServedBy:    g.cfg.LocalModelName,
		IsEscalated: false,
	}, nil
}

func (g *ResilientAIGateway) executeCloudFrontier(ctx context.Context, req RouteRequest) (RouteResponse, error) {
	payload, _ := json.Marshal(map[string]interface{}{
		"model":      g.cfg.FrontierModelName,
		"max_tokens": req.MaxTokens,
		"messages":   []map[string]string{{"role": "user", "content": req.Prompt}},
	})

	httpReq, err := http.NewRequestWithContext(ctx, "POST", g.cfg.FrontierEndpoint, bytes.NewReader(payload))
	if err != nil {
		return RouteResponse{}, err
	}
	httpReq.Header.Set("x-api-key", g.cfg.FrontierAPIKey)
	httpReq.Header.Set("anthropic-version", "2023-06-01")
	httpReq.Header.Set("Content-Type", "application/json")

	res, err := g.httpClient.Do(httpReq)
	if err != nil {
		return RouteResponse{}, err
	}
	defer res.Body.Close()

	bodyBytes, _ := io.ReadAll(res.Body)
	var cloudOut struct {
		Content []struct {
			Text string `json:"text"`
		} `json:"content"`
	}
	if err := json.Unmarshal(bodyBytes, &cloudOut); err != nil || len(cloudOut.Content) == 0 {
		return RouteResponse{}, errors.New("failed to decode cloud frontier response")
	}

	return RouteResponse{
		Content:     cloudOut.Content[0].Text,
		ServedBy:    g.cfg.FrontierModelName,
		IsEscalated: true,
	}, nil
}

func main() {
	cfg := DefaultGatewayConfig()
	if v := os.Getenv("VLLM_URL"); v != "" {
		cfg.LocalVLLMEndpoint = v
	}
	if v := os.Getenv("ANTHROPIC_API_KEY"); v != "" {
		cfg.FrontierAPIKey = v
	}
	if v := os.Getenv("MAX_QUEUE_DEPTH"); v != "" {
		if val, err := strconv.ParseInt(v, 10, 64); err == nil {
			cfg.MaxQueueDepth = val
		}
	}
	if v := os.Getenv("GATEWAY_PORT"); v != "" {
		cfg.ListenAddr = ":" + v
	}

	gw := NewGateway(cfg)
	log.Printf("Hybrid AI Gateway operational on %s", cfg.ListenAddr)
	if err := http.ListenAndServe(cfg.ListenAddr, gw); err != nil {
		log.Fatalf("Fatal gateway failure: %v", err)
	}
}

9. Cấu Trúc liên Mạng Edge-to-Cloud và Rủi Ro Phân Mảnh

BLUF (Bottom Line Up Front): Phân phối định tuyến gateway hybrid ra vùng biên thông qua Cloudflare Workers hoặc Fastly Compute hoàn tất bắt tay TLS người dùng trong vòng 12ms trên toàn cầu, tiền lọc yêu cầu trước khi chuyển tiếp về các cụm suy luận GPU khu vực.

Trong các kiến trúc doanh nghiệp phân tán toàn cầu, độ trễ bị chi phối chủ yếu bởi tốc độ truyền dẫn ánh sáng trong cáp quang. Định tuyến toàn bộ lưu lượng người dùng từ mọi châu lục về một trung tâm dữ liệu GPU tập trung duy nhất sẽ tạo thêm hàng trăm mili-giây độ trễ WAN không đáng có.

Cấu Trúc Phân Tầng Đa Vùng (Distributed Multi-Tier Topology)

1. Tầng Biên Anycast (Cloudflare Workers / Edge CDN): Kết thúc bắt tay TLS, áp dụng rate limiting theo token bucket, kiểm tra bộ nhớ đệm ngữ nghĩa Redis và loại bỏ các payload tấn công Prompt Injection ngay tại các Điểm Hiện Diện (PoP) biên cách 95% người dùng dưới 15ms.
2. Cụm GPU Riêng Biệt Khu Vực (VPC / On-Prem): Các cụm pod phục vụ suy luận vLLM mật độ cao đặt tại Frankfurt (EU), Singapore (APAC) và Virginia (US-East) trực tiếp thực thi các mô hình SLM 7B chuyên biệt hóa trên lưu lượng người dùng nội vùng.
3. Trung Tâm Chuyển Tiếp Frontier (Escalation Hub): Các mô hình Frontier trên đám mây chỉ được gọi khi các SLM khu vực báo cáo độ bất định token (entropy) cao, với toàn bộ dữ liệu định danh PII đã được khử nhiễm cục bộ trước khi rời khỏi mạng nội bộ.

❓ Câu Hỏi Thường Gặp (FAQ)

🔗 Các Bước Tiếp Theo Trong Sổ Tay

Sau khi hoàn thiện tầng phục vụ và định tuyến mô hình, bước quan trọng nhất quyết định 90% thành bại của SLM là chuẩn bị dữ liệu huấn luyện tinh khiết:
👉 Phần 2: Kỹ Nghệ Dữ Liệu Cho SFT: Tiêm Nhiễu NEFTune & SemDeDup.