LLM Inference Optimization 2026 - Kiến trúc KV Cache, PagedAttention, Continuous Batching và Speculative Decoding cho Multi-Agent Production

Posted on: 4/14/2026 4:11:13 PM

Trong suốt năm 2025, phần lớn các đội kỹ sư xây dựng hệ thống AI tập trung vào tầng ứng dụng: prompt, tool, orchestration, observability. Nhưng khi lưu lượng vượt ngưỡng vài triệu request mỗi ngày, một thực tế nghiệt ngã xuất hiện — chi phí GPU và độ trễ inference trở thành nút thắt lớn nhất của toàn bộ hệ thống. Một multi-agent workflow gọi mười lần LLM cho một yêu cầu người dùng sẽ biến mỗi mili-giây TTFT thành một giây trải nghiệm. Bài viết này đi sâu vào kiến trúc LLM Inference Optimization 2026 — cách các kỹ thuật như KV Cache, PagedAttention, Continuous Batching, Speculative Decoding và phân phối KV cache qua Redis/LMCache đã biến inference từ một bài toán phần cứng đắt đỏ thành một bài toán phần mềm có thể tối ưu hàng chục lần.

1. Tại sao Inference Optimization là mặt trận chi phí lớn nhất của AI 2026

Một năm trước, câu hỏi phổ biến của kỹ sư AI là "nên dùng GPT-4 hay Claude?". Năm 2026, câu hỏi đã dịch chuyển sang "tại sao p99 TTFT của chúng ta vượt 3 giây trong giờ cao điểm?". Sự dịch chuyển này đến từ ba lực đồng thời:

• Multi-agent khuếch đại số lượng request: Một yêu cầu người dùng đơn giản có thể tạo ra 10-50 lượt gọi LLM qua các sub-agent, reasoning step, tool planner. Mỗi lượt gọi đều chịu chi phí prefill và decode riêng.
• Context window mở rộng: Các model hiện đại hỗ trợ 200K-1M token. Điều này đồng nghĩa một request có thể chiếm hàng GB bộ nhớ GPU cho KV cache. Nếu không quản lý khéo, một request dài sẽ chặn hàng chục request ngắn khác.
• GPU là tài nguyên cứng: Khác với CPU, GPU không thể "scale co giãn" trong vài giây. Một H100 giá 3-5 USD/giờ và throughput tối đa thường chỉ đạt được khi batch đủ lớn. Lãng phí một slot batch là lãng phí trực tiếp tiền mặt.

Hệ quả: tầng inference trở thành nơi mà tối ưu phần mềm có thể đem lại hiệu quả gấp 10-100 lần so với tối ưu prompt. Một kỹ sư hiểu KV cache và batching có thể giảm chi phí GPU của cả một cụm cluster xuống còn 30% — thứ không một kỹ thuật prompt engineering nào làm được.

2. Hai thế giới khác biệt: Prefill và Decode

Điều đầu tiên mà bất kỳ ai muốn tối ưu inference phải hiểu là: một lượt gọi LLM thực chất gồm hai pha hoàn toàn khác nhau về đặc tính tính toán, không thể dùng chung một chiến lược tối ưu.

graph LR
    Q["Request đến
10K token prompt"] --> P["PREFILL
Compute-bound
Tính KV cache cho toàn bộ
prompt trong 1 bước"]
    P --> D["DECODE
Memory-bound
Sinh từng token một
Cập nhật KV cache"]
    D --> T1["Token 1"]
    T1 --> D
    D --> TN["Token N"]
    TN --> End["EOS"]
    style P fill:#e94560,stroke:#fff,color:#fff
    style D fill:#0f3460,stroke:#fff,color:#fff
    style Q fill:#2c3e50,stroke:#fff,color:#fff
    style End fill:#4CAF50,stroke:#fff,color:#fff

Pha Prefill diễn ra đúng một lần cho mỗi request: model đọc toàn bộ prompt, tính self-attention cho từng token, và lưu các key/value vector vào một bộ đệm — đó chính là KV cache. Pha này compute-bound: GPU sử dụng tối đa tensor core, throughput phụ thuộc FLOPs. Một prompt 10K token có thể tạo ra 10K × 2 × num_layers × hidden_dim giá trị cần tính.

Pha Decode thì hoàn toàn ngược lại: model sinh từng token một, mỗi bước chỉ cần tính attention cho một token mới so với toàn bộ KV cache đã có. Pha này memory-bound: bottleneck là băng thông bộ nhớ HBM vì mỗi bước phải đọc lại toàn bộ KV cache. GPU thực tế chỉ sử dụng 10-30% công suất tính toán nếu batch quá nhỏ.

3. KV Cache — Trái tim của mọi tối ưu inference

Nếu không có KV cache, mỗi bước decode phải tính lại self-attention cho toàn bộ prompt từ đầu — chi phí tính toán tăng theo bình phương độ dài câu trả lời. KV cache biến chi phí đó thành tuyến tính bằng cách lưu trữ các vector K và V của mỗi token sau khi đã tính xong, rồi tái sử dụng ở bước kế tiếp.

Kích thước của KV cache được tính theo công thức:

kv_cache_bytes = 2 × num_layers × num_heads × head_dim × seq_len × dtype_size

Với một model 70B tham số (80 layer, 64 head, 128 head_dim, bf16), một request 32K token chiếm khoảng 20-40 GB bộ nhớ GPU chỉ riêng cho KV cache. Con số này lớn hơn cả chính model weights trong nhiều trường hợp. Đây là lý do vì sao quản lý KV cache trở thành bài toán trung tâm của LLM serving.

Ba vấn đề kinh điển của KV cache truyền thống:

• Internal fragmentation: Serving engine thường cấp phát tối đa một khối liên tục cho độ dài dự kiến. Nếu request dừng sớm (EOS token), phần không dùng bị lãng phí.
• External fragmentation: Khi các request có độ dài khác nhau kết thúc và giải phóng bộ nhớ, các khối tự do nằm rải rác, không thể hợp lại để phục vụ một request dài mới.
• Không chia sẻ được: Hai request có cùng prefix (ví dụ cùng system prompt) vẫn phải giữ hai bản KV riêng biệt, gấp đôi bộ nhớ vô ích.

4. PagedAttention — Đem paging của hệ điều hành vào GPU

Năm 2023, nhóm nghiên cứu Sky Computing Lab tại UC Berkeley công bố vLLM cùng kỹ thuật PagedAttention. Ý tưởng mượn trực tiếp từ quản lý bộ nhớ ảo của hệ điều hành Unix: thay vì cấp phát một khối liên tục cho toàn bộ sequence, KV cache được chia thành các block cố định, mỗi block chứa K/V cho một số token (thường là 16).

graph TB
    subgraph "Logical Sequence A - 33 tokens"
        LA1["Tokens 0-15"]
        LA2["Tokens 16-31"]
        LA3["Token 32"]
    end
    subgraph "Logical Sequence B - 20 tokens"
        LB1["Tokens 0-15"]
        LB2["Tokens 16-19"]
    end
    subgraph "Physical GPU Memory - KV Blocks"
        P0["Block 0"]
        P1["Block 1"]
        P2["Block 2"]
        P3["Block 3"]
        P4["Block 4"]
        P5["Block 5 Free"]
    end
    LA1 --> P2
    LA2 --> P0
    LA3 --> P4
    LB1 --> P1
    LB2 --> P3
    style LA1 fill:#e94560,stroke:#fff,color:#fff
    style LA2 fill:#e94560,stroke:#fff,color:#fff
    style LA3 fill:#e94560,stroke:#fff,color:#fff
    style LB1 fill:#0f3460,stroke:#fff,color:#fff
    style LB2 fill:#0f3460,stroke:#fff,color:#fff
    style P5 fill:#4CAF50,stroke:#fff,color:#fff

Mỗi sequence có một block table — bảng ánh xạ từ số thứ tự block logic (tokens 0-15, 16-31...) sang số block vật lý trong GPU HBM. Ý nghĩa của cơ chế này rất sâu:

• Không fragmentation: Block có kích thước đồng nhất, mọi block tự do đều có thể phục vụ mọi request. Mức lãng phí giảm từ 60-80% xuống dưới 4%.
• Copy-on-write chia sẻ prefix: Nếu hai request có cùng prompt đầu, chúng có thể trỏ vào cùng một block vật lý. Khi một bên bắt đầu sinh token khác nhau thì mới sao chép — giống hệt fork() của Linux.
• Swap ra ngoài: Khi GPU đầy, các block có thể được chuyển tạm xuống CPU RAM, đĩa hoặc Redis rồi nạp lại khi cần, không cần hủy request.

Kết quả đo đạc của nhóm vLLM cho thấy tỷ lệ batch size tăng 2-4 lần trong cùng một GPU, kéo theo throughput tăng đến 24 lần so với HuggingFace Transformers trên cùng phần cứng.

5. Continuous Batching — Bỏ hoàn toàn khái niệm batch tĩnh

Trong web serving cổ điển, batching thường tĩnh: gom N request, chạy xong N request rồi mới nhận batch mới. Với LLM, cách này thảm khốc. Vì mỗi request sinh số token khác nhau, một request trong batch có thể sinh 5 token rồi xong, trong khi các request khác sinh tới 2000 token. Slot của request đã xong bị bỏ trống suốt phần thời gian còn lại — đó là lãng phí thuần.

Continuous batching (còn gọi là iteration-level scheduling hoặc in-flight batching) loại bỏ khái niệm batch cố định hoàn toàn. Scheduler làm việc ở cấp từng bước decode:

1. Ở mỗi iteration, scheduler chọn một tập request đang hoạt động để chạy một bước forward duy nhất qua model.
2. Ngay khi một request sinh EOS, nó bị loại khỏi tập active, slot của nó được cấp phát ngay cho request đang chờ ở hàng đợi.
3. Request mới bước vào batch giữa chừng mà không cần đợi batch cũ chạy xong.

Để ghép nhiều request với độ dài khác nhau vào một forward pass, các engine hiện đại không dùng padding. Thay vào đó, tất cả sequence được flatten và nối lại thành một super-sequence. Position indices và attention mask đảm bảo mỗi token chỉ attend tới chính sequence của nó. Kỹ thuật này gọi là packed attention hoặc varlen attention, được hỗ trợ hiệu quả bởi FlashAttention 2/3.

6. Speculative Decoding — 2-3x tốc độ mà không đánh đổi chất lượng

Speculative decoding là kỹ thuật lý thuyết đơn giản nhưng tác động sâu: dùng một model nhỏ "đoán trước" vài token tiếp theo, rồi để model lớn kiểm tra các token đó trong một forward pass duy nhất.

sequenceDiagram
    participant Draft as Draft Model 1B
    participant Target as Target Model 70B
    participant Out as Output
    Draft->>Draft: Sinh token 1 nhanh
    Draft->>Draft: Sinh token 2 nhanh
    Draft->>Draft: Sinh token 3 nhanh
    Draft->>Draft: Sinh token 4 nhanh
    Draft->>Target: Gửi 4 draft token
    Target->>Target: Verify parallel 1 forward pass
    Target->>Out: Chấp nhận token 1, 2, 3
    Target->>Out: Từ chối token 4, thay bằng token đúng
    Note over Target,Out: 3 token được sinh với
chi phí 1 bước Target

Vì sao speculative decoding cho tốc độ 2-3x mà không mất chất lượng? Chìa khóa nằm ở memory-bound: một bước forward của model 70B đang bị giới hạn bởi băng thông bộ nhớ HBM, không phải bởi số phép toán. Nếu ta đã phải đọc toàn bộ trọng số model từ HBM cho một token, thì đọc thêm ba token nữa trong cùng bước gần như miễn phí. Model lớn xác minh 4 token song song chỉ tốn chi phí tương đương một token truyền thống.

Các dạng speculative decoding phổ biến năm 2026:

7. Prefix Caching và chia sẻ KV Cache phân tán với Redis

Trong các hệ thống multi-agent, một quan sát quan trọng: phần lớn các lượt gọi LLM đều có chung một prefix rất dài. System prompt của agent có thể là 2000 token, toolset description là 3000 token, few-shot example là 5000 token. Nếu mỗi request đều phải tính lại prefill cho cùng một prefix, chúng ta đang trả tiền cho cùng một phép toán hàng triệu lần.

Prefix Caching giải quyết điều này ở hai cấp độ:

1. Intra-node caching: vLLM/SGLang giữ lại các KV block của prefix đã thấy trong bộ nhớ GPU và tự động match khi request mới có cùng prefix. Hash của block làm key, nội dung token làm chữ ký.
2. Distributed caching: Các block KV có thể được offload xuống CPU RAM, NVMe, hoặc một lớp cache chia sẻ như LMCache với backend Redis. Khi một request đến node khác, block cũ được pull về qua mạng tốc độ cao (RDMA, NVLink) thay vì tính lại.

graph TB
    R1["Request A
Agent Planner"] --> GW["LLM Gateway
+ Prefix-aware Router"]
    R2["Request B
Agent Critic"] --> GW
    R3["Request C
Agent Executor"] --> GW
    GW --> N1["Node 1 vLLM
KV Cache tầng 1 HBM"]
    GW --> N2["Node 2 vLLM
KV Cache tầng 1 HBM"]
    N1 <--> LM["LMCache
Tầng 2 CPU RAM + NVMe"]
    N2 <--> LM
    LM <--> RD[("Redis Cluster
Tầng 3 chia sẻ mạng")]
    RD --> S["Durable Storage
S3 / NFS"]
    style GW fill:#e94560,stroke:#fff,color:#fff
    style N1 fill:#0f3460,stroke:#fff,color:#fff
    style N2 fill:#0f3460,stroke:#fff,color:#fff
    style LM fill:#4CAF50,stroke:#fff,color:#fff
    style RD fill:#ff9800,stroke:#fff,color:#fff

Kiến trúc phân tầng này có ba thuộc tính quan trọng. Thứ nhất, KV-aware routing: LLM Gateway biết node nào đang giữ prefix nào, điều hướng request mới đến node có sẵn cache để tối đa hóa hit rate. Thứ hai, hierarchical eviction: các block ít dùng bị đẩy xuống tầng thấp hơn thay vì xóa hẳn. Thứ ba, read-through với Redis: Redis đóng vai trò backing store phân tán, cho phép node mới vừa boot lên đã có ngay KV cache của các prefix nóng.

Theo LMCache và llm-d, trong các workload multi-agent điển hình, prefix caching giảm tới 85-95% chi phí prefill và TTFT trung bình giảm 3-6 lần. Đây là tối ưu mang tính kiến trúc — không thể đạt được bằng nâng cấp GPU.

8. Disaggregated Inference — Tách prefill khỏi decode

Bước tiến sâu hơn: nếu prefill và decode có yêu cầu tài nguyên khác nhau, hãy chạy chúng trên những cụm khác nhau. Đây là ý tưởng disaggregated serving được đưa vào sản xuất từ 2025 bởi DeepSpeed-FastGen, Splitwise (Microsoft), NVIDIA Dynamo, llm-d và SGLang.

graph LR
    Cli["Client"] --> SCH["Global Scheduler
+ KV Router"]
    SCH --> PRE["Prefill Cluster
8x H100
Tối ưu compute"]
    SCH --> DEC["Decode Cluster
32x A100
Tối ưu bandwidth"]
    PRE -->|KV cache transfer
qua RDMA| DEC
    DEC --> Cli
    PRE --> MET["ClickHouse Metrics"]
    DEC --> MET
    style PRE fill:#e94560,stroke:#fff,color:#fff
    style DEC fill:#0f3460,stroke:#fff,color:#fff
    style SCH fill:#4CAF50,stroke:#fff,color:#fff
    style MET fill:#2c3e50,stroke:#fff,color:#fff

Ba lợi ích cốt lõi của kiến trúc phân rã:

• Scale độc lập: Khi workload nhiều prompt dài nhưng câu trả lời ngắn (VD tool use, function calling), ta tăng prefill node mà không tốn decode node. Ngược lại khi workload là chat dài.
• Interference-free: Prefill mang tính burst và compute-heavy, không còn làm chậm decode của các request khác như ở kiến trúc gộp chung.
• Hardware heterogeneity: Có thể dùng H100 đắt tiền cho prefill, A100 hoặc L40S rẻ hơn cho decode, vì decode chủ yếu cần bandwidth HBM.

Thách thức duy nhất là chi phí truyền KV cache từ prefill sang decode. Với model 70B và prompt 8K token, một lần chuyển có thể đạt 10-20 GB. Giải pháp: dùng mạng RDMA với băng thông 200-400 Gbps và streaming KV theo layer — bắt đầu chuyển layer 0 trong khi vẫn đang prefill layer 79.

9. Đo lường inference — ClickHouse làm backbone metrics

Không có tối ưu nào có nghĩa nếu không đo được. Các chỉ số tối thiểu cần theo dõi cho một cụm LLM serving:

ClickHouse là lựa chọn mặc định năm 2026 cho việc lưu các metric này vì ba lý do. Một, các metric LLM có cardinality rất cao (mỗi request một row, thêm label user, agent, model, prefix hash) — ClickHouse xử lý hàng tỉ row một ngày mà truy vấn vẫn dưới giây. Hai, các pattern truy vấn đa số là time-series aggregation — công việc mà columnar store làm tốt hơn Postgres 20-50 lần. Ba, ClickStack của ClickHouse tích hợp sẵn OpenTelemetry GenAI semantic conventions, export thẳng từ vLLM/SGLang mà không cần viết adapter.

Cấu trúc bảng điển hình cho một sự kiện inference:

CREATE TABLE llm_events (
    ts            DateTime64(3),
    request_id    String,
    tenant_id     String,
    agent_name    String,
    model         LowCardinality(String),
    prefix_hash   UInt64,
    input_tokens  UInt32,
    output_tokens UInt32,
    ttft_ms       UInt32,
    tpot_ms       UInt32,
    queue_ms      UInt32,
    cache_hit     UInt8,
    spec_accept   Float32,
    cost_usd      Float64
) ENGINE = MergeTree
ORDER BY (tenant_id, ts);

Với schema này, bạn có thể viết một truy vấn để trả lời các câu hỏi tức thời:

SELECT
    agent_name,
    avg(ttft_ms) AS avg_ttft,
    quantile(0.95)(ttft_ms) AS p95_ttft,
    avg(cache_hit) AS hit_rate,
    sum(cost_usd) AS total_cost
FROM llm_events
WHERE ts >= now() - INTERVAL 1 HOUR
GROUP BY agent_name
ORDER BY total_cost DESC;

10. Kiến trúc Inference Production hoàn chỉnh cho Multi-Agent 2026

Tổng hợp các kỹ thuật trên, dưới đây là sơ đồ một stack serving đầy đủ đang chạy production ở nhiều doanh nghiệp AI đầu năm 2026:

graph TB
    subgraph Client["Tầng ứng dụng"]
        APP["Agent Orchestrator
Claude Code / LangGraph"]
    end
    subgraph Edge["Tầng điều phối"]
        GW["LLM Gateway
Rate limit, Routing, Guardrails"]
        SCH["KV-aware Scheduler"]
    end
    subgraph Serving["Tầng serving"]
        PRE1["Prefill Node 1
H100 + FlashAttn 3"]
        PRE2["Prefill Node 2
H100 + FlashAttn 3"]
        DEC1["Decode Node 1
A100 + Speculative"]
        DEC2["Decode Node 2
A100 + Speculative"]
    end
    subgraph Cache["Tầng KV Cache phân tán"]
        LM["LMCache Hierarchical
HBM / CPU / NVMe"]
        RD[("Redis Cluster
KV remote store")]
    end
    subgraph Obs["Tầng quan sát"]
        OTEL["OTel Collector
GenAI conventions"]
        CH[("ClickHouse / ClickStack")]
        GRAF["Grafana / HyperDX"]
    end
    APP --> GW --> SCH
    SCH --> PRE1
    SCH --> PRE2
    PRE1 --> DEC1
    PRE2 --> DEC2
    PRE1 <--> LM
    PRE2 <--> LM
    DEC1 <--> LM
    DEC2 <--> LM
    LM <--> RD
    PRE1 --> OTEL
    PRE2 --> OTEL
    DEC1 --> OTEL
    DEC2 --> OTEL
    OTEL --> CH --> GRAF
    style GW fill:#e94560,stroke:#fff,color:#fff
    style SCH fill:#e94560,stroke:#fff,color:#fff
    style PRE1 fill:#0f3460,stroke:#fff,color:#fff
    style PRE2 fill:#0f3460,stroke:#fff,color:#fff
    style DEC1 fill:#4CAF50,stroke:#fff,color:#fff
    style DEC2 fill:#4CAF50,stroke:#fff,color:#fff
    style LM fill:#ff9800,stroke:#fff,color:#fff
    style RD fill:#ff9800,stroke:#fff,color:#fff
    style CH fill:#2c3e50,stroke:#fff,color:#fff

Các quyết định thiết kế quan trọng khi triển khai kiến trúc này:

1. Hard isolation giữa tenant: Dùng scheduler có khả năng quota theo tenant để ngăn một agent rogue chiếm toàn bộ GPU bằng prompt dài.
2. Warm-up cache cho prefix quan trọng: System prompt của các agent chính nên được pre-load vào Redis khi node khởi động, đừng đợi traffic thực tế.
3. Graceful degradation: Khi queue length tăng quá ngưỡng, gateway tự động chuyển traffic sang model nhỏ hơn (Haiku thay Opus) thay vì để request timeout.
4. Separate SLO cho TTFT và TPOT: Alert riêng cho từng metric, vì hai vấn đề có nguyên nhân khác nhau: TTFT cao = thiếu prefill node, TPOT cao = thiếu bandwidth HBM.
5. Hash-based prefix key: Dùng xxhash64 của token ID, không phải hash chuỗi text, để tránh va chạm giữa các cách tokenize khác nhau.

11. So sánh các engine serving phổ biến năm 2026

12. Dòng chảy lịch sử của Inference Optimization

13. Checklist triển khai cho đội kỹ sư

14. Kết luận

Kỷ nguyên mà đội kỹ sư AI chỉ cần quan tâm đến prompt và orchestration đã kết thúc. Khi lưu lượng tăng và GPU trở thành chi phí chi phối, tầng inference quyết định cả tính kinh tế lẫn trải nghiệm người dùng. PagedAttention biến bộ nhớ GPU thành một tài nguyên có thể quản lý như RAM hệ điều hành, continuous batching xóa bỏ khái niệm slot cố định, speculative decoding bẻ gãy giới hạn memory-bound của decode, và prefix caching phân tán qua Redis giúp cụm serving chia sẻ công sức tính toán như một bộ nhớ đệm khổng lồ.

Với multi-agent hệ thống — nơi một yêu cầu người dùng có thể kích hoạt hàng chục lượt gọi LLM — các kỹ thuật này không còn là "tối ưu nâng cao", chúng là điều kiện sống còn. Một team hiểu rõ prefill/decode, biết warm prefix vào Redis, đo KV cache hit rate, và thiết lập ClickStack đúng cách có thể vận hành cùng một workload với 20-30% chi phí GPU so với team chỉ biết gọi API của model vendor.

Năm 2026 là năm mà inference optimization trở thành một core competency của mọi đội xây dựng sản phẩm AI serious. Và nếu có một điều bạn mang về sau bài viết này, hãy nhớ rằng: mỗi token không được reuse từ cache là một đồng đô la đốt vào HBM.

Nguồn tham khảo

• Inside vLLM: Anatomy of a High-Throughput LLM Inference System — vLLM Blog
• vLLM GitHub Repository — vllm-project
• Achieve 23x LLM Inference Throughput & Reduce p50 Latency — Anyscale
• LMCache: Supercharge Your LLM with the Fastest KV Cache Layer
• LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference — arXiv
• KV-Cache Wins You Can See: Prefix Caching in vLLM to Distributed Scheduling with llm-d
• Speculative Decoding — LLM Inference Handbook by BentoML
• Speculative Decoding: 2-3x Faster LLM Inference (2026) — Prem AI
• Looking Back at Speculative Decoding — Google Research
• LLM Observability with ClickStack, OpenTelemetry, and MCP — ClickHouse Blog
• Understanding LLM Observability — ClickHouse Engineering Resource Hub
• Key Metrics for LLM Inference — BentoML
• LLM Inference Benchmarking: Fundamental Concepts — NVIDIA Technical Blog
• vLLM Documentation — Official