Semantic Caching cho LLM Agents: Tối ưu Chi phí và Độ trễ với Redis, ClickHouse và Prompt Caching 2026

Posted on: 4/14/2026 9:12:44 AM

Khi hệ thống AI Multi-Agent bước vào giai đoạn sản xuất năm 2026, ba bài toán nhức nhối nhất không còn là "model có đủ thông minh không" — mà là chi phí token, độ trễ end-to-end và khả năng quan sát (observability). Một phiên làm việc của Claude Code hay LangGraph agent có thể dễ dàng đốt vài trăm nghìn token cho một task trung bình, trong khi người dùng chỉ chịu đợi tối đa vài giây. Bài viết này đi sâu vào kiến trúc Semantic Caching kết hợp Prompt Caching của Anthropic, sử dụng Redis 8 làm tầng vector cache và ClickHouse làm backbone cho AI Observability — một công thức đang được nhiều hệ thống LLM production áp dụng.

1. Bài toán chi phí và độ trễ trong LLM Multi-Agent

Một hệ thống Multi-Agent thực tế — ví dụ một pipeline tóm tắt tài liệu kết hợp RAG — có thể phát sinh 4 đến 12 lời gọi LLM cho mỗi yêu cầu từ người dùng: phân loại intent, mở rộng truy vấn, đánh giá kết quả retrieval, tổng hợp câu trả lời, đánh giá chất lượng, tạo metadata... Mỗi lần gọi là một lần gửi toàn bộ system prompt, few-shot examples, lịch sử hội thoại và context retrieved qua network tới inference cluster. Điều này dẫn đến ba vấn đề lớn:

• Chi phí tăng theo cấp số nhân: Với Claude Opus 4.6, giá input ~15 USD/1M token. Một hệ thống 1 triệu request/ngày với trung bình 8K token context dễ dàng chạm mốc 3.600 USD/ngày chỉ riêng phần input.
• Độ trễ cao do Time-To-First-Token (TTFT): Prefill giai đoạn (model xử lý toàn bộ prompt) mất 200ms-2s tuỳ độ dài. Với 4-12 hops qua các agent, tổng TTFT có thể vượt ngưỡng chịu đựng của người dùng (3s).
• Tải lặp lại (repetitive load): Trong thực tế, 60-80% truy vấn là tương tự nhau về ngữ nghĩa — "cho tôi biết chính sách nghỉ phép" và "quy định nghỉ phép của công ty là gì?" về bản chất cần cùng một câu trả lời.

2. Ba tầng caching cho LLM: Exact, Prompt, Semantic

Không phải mọi cache đều giống nhau. Trong kiến trúc LLM, chúng ta cần phân biệt rõ ba cấp độ — mỗi cấp giải quyết một loại lặp khác nhau và có cơ chế lưu trữ riêng.

Chiến lược tối ưu là kết hợp cả ba: exact-match làm tầng L1 (micro-giây), semantic làm tầng L2 (mili-giây), và prompt caching làm tầng L3 ở phía nhà cung cấp model. Chỉ khi cả ba tầng đều miss, request mới thực sự đi qua inference pipeline đầy đủ.

flowchart LR
    A["User Request"] --> B{"L1: Exact
Match?"}
    B -->|"Hit"| Z1["Trả kết quả
~1ms"]
    B -->|"Miss"| C["Embed Query"]
    C --> D{"L2: Semantic
Cache?"}
    D -->|"Hit sim > 0.87"| Z2["Trả kết quả
~15ms"]
    D -->|"Miss"| E["Gọi LLM
với Prompt Cache"]
    E --> F{"L3: Prefix
Cached?"}
    F -->|"Hit"| Z3["TTFT thấp
~300ms"]
    F -->|"Miss"| Z4["Full inference
~1.5s"]
    Z2 --> G["Ghi lại log"]
    Z3 --> G
    Z4 --> H["Ghi cache L1+L2"]
    H --> G
    G --> I["ClickHouse"]
    style A fill:#e94560,stroke:#fff,color:#fff
    style B fill:#0f3460,stroke:#fff,color:#fff
    style D fill:#0f3460,stroke:#fff,color:#fff
    style F fill:#0f3460,stroke:#fff,color:#fff
    style Z1 fill:#4CAF50,stroke:#fff,color:#fff
    style Z2 fill:#4CAF50,stroke:#fff,color:#fff
    style Z3 fill:#ff9800,stroke:#fff,color:#fff
    style Z4 fill:#e94560,stroke:#fff,color:#fff
    style I fill:#0f3460,stroke:#fff,color:#fff

Kiến trúc 3 tầng caching cho LLM Multi-Agent

3. Prompt Caching của Anthropic — hoạt động ra sao?

Prompt Caching là tính năng được Anthropic (và gần như toàn bộ nhà cung cấp LLM lớn) hỗ trợ. Ý tưởng đơn giản nhưng mạnh: khi prefix của prompt (system message, tool definitions, few-shot examples, tài liệu cố định) không đổi giữa các request, nhà cung cấp có thể tái sử dụng KV cache đã tính sẵn trên GPU thay vì phải tính lại từ đầu.

3.1. Cách đánh dấu cache breakpoints

Trong Anthropic Messages API, bạn đánh dấu phần muốn cache bằng cache_control: {type: "ephemeral"}. Anthropic cho phép tối đa 4 cache breakpoints, và TTL mặc định là 5 phút (có thể cấu hình 1 giờ với phí cao hơn).

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Bạn là trợ lý pháp lý chuyên về luật lao động Việt Nam..."
        },
        {
            "type": "text",
            "text": LARGE_LEGAL_CORPUS,  # ~100k tokens tài liệu
            "cache_control": {"type": "ephemeral"}  # Breakpoint tại đây
        }
    ],
    messages=[
        {"role": "user", "content": "Quy định nghỉ phép năm là bao nhiêu ngày?"}
    ]
)

print(response.usage)
# cache_creation_input_tokens: 100000 (lần đầu)
# cache_read_input_tokens: 0
# Lần sau:
# cache_creation_input_tokens: 0
# cache_read_input_tokens: 100000  (trả phí ~10% giá gốc)

3.2. Kinh tế học của Prompt Caching

Với Claude Opus 4.6 (giả lập giá minh họa):

Công thức đánh giá nhanh: nếu cùng một prefix được dùng cho N ≥ 2 request trong cửa sổ TTL, caching đã có lãi. Với hệ thống Multi-Agent lặp lại cùng một system prompt hàng nghìn lần mỗi giờ, tiết kiệm thực tế dao động 70-90%.

4. Semantic Cache với Redis 8 + Vector Search

Prompt Caching chỉ hoạt động khi prefix trùng khớp chính xác. Nhưng nếu hai người dùng hỏi hai câu khác nhau nhưng cùng ý nghĩa, chúng ta cần một cơ chế khác — đó chính là Semantic Cache. Ý tưởng: nhúng (embed) câu hỏi thành vector, tìm câu hỏi gần nhất đã cache bằng cosine similarity, nếu vượt ngưỡng thì trả kết quả cũ.

4.1. Kiến trúc Redis Vector Search

Từ phiên bản Redis Stack (và Redis 8 native), Redis cung cấp RediSearch module hỗ trợ index vector với hai thuật toán: FLAT (brute-force, chính xác tuyệt đối, tốt cho <100k vector) và HNSW (approximate nearest neighbor, log-scale, xử lý hàng triệu vector).

import redis
from redis.commands.search.field import VectorField, TextField, NumericField
from redis.commands.search.indexDefinition import IndexDefinition, IndexType
from redis.commands.search.query import Query
import numpy as np

r = redis.Redis(host="redis-prod", port=6379, decode_responses=False)

# Tạo schema index HNSW cho embeddings 1536 chiều (OpenAI/Voyage)
schema = (
    TextField("$.query", as_name="query"),
    TextField("$.answer", as_name="answer"),
    NumericField("$.ts", as_name="ts"),
    VectorField(
        "$.embedding",
        "HNSW",
        {
            "TYPE": "FLOAT32",
            "DIM": 1536,
            "DISTANCE_METRIC": "COSINE",
            "M": 16,              # connections per node
            "EF_CONSTRUCTION": 200,
            "EF_RUNTIME": 100,
        },
        as_name="vec"
    ),
)

definition = IndexDefinition(prefix=["semcache:"], index_type=IndexType.JSON)
r.ft("idx:semcache").create_index(fields=schema, definition=definition)

4.2. Luồng đọc — ghi semantic cache

Mỗi request đi qua hai bước: (1) embed câu hỏi, (2) KNN search trên index. Nếu khoảng cách cosine nhỏ hơn ngưỡng (ví dụ 0.13 tương đương similarity 0.87), ta coi là cache hit.

def semantic_lookup(user_query: str, threshold: float = 0.13):
    q_vec = embed(user_query).astype(np.float32).tobytes()

    knn_query = (
        Query("(*)=>[KNN 1 @vec $vec AS dist]")
        .sort_by("dist")
        .return_fields("query", "answer", "dist", "ts")
        .dialect(2)
    )

    res = r.ft("idx:semcache").search(knn_query, query_params={"vec": q_vec})
    if not res.docs:
        return None

    top = res.docs[0]
    if float(top.dist) < threshold:
        return {"answer": top.answer, "matched_query": top.query, "dist": top.dist}
    return None

def semantic_store(user_query: str, answer: str, ttl: int = 86400):
    key = f"semcache:{hash_id(user_query)}"
    payload = {
        "query": user_query,
        "answer": answer,
        "embedding": embed(user_query).tolist(),
        "ts": int(time.time()),
    }
    r.json().set(key, "$", payload)
    r.expire(key, ttl)

4.3. Tuning similarity threshold

Đây là phần nhạy cảm nhất của semantic cache. Threshold quá cao (0.95+) sẽ bỏ lỡ nhiều cache hit. Threshold quá thấp (< 0.80) sẽ trả câu trả lời sai lệch cho câu hỏi khác chủ đề — một loại hallucination gián tiếp.

Quy trình tuning khuyến nghị:

1. Thu thập 1.000-5.000 cặp (query, expected_answer) từ log production.
2. Sinh embedding, tính ma trận similarity, gán nhãn cặp "cùng nghĩa / khác nghĩa".
3. Dựng ROC curve, chọn threshold tại điểm False Positive Rate ≤ 2%.
4. Triển khai shadow mode: cache trả kết quả nhưng không hiển thị, log để đánh giá chênh lệch với full LLM.
5. Sau 7 ngày shadow, bật live nếu accuracy giữ trên 98%.

5. Redis 8: tại sao lại là lựa chọn tối ưu cho cache layer

Redis đã tồn tại hơn 15 năm nhưng vẫn là vua của in-memory database nhờ kiến trúc single-threaded event loop + I/O multiplexing với độ trễ nhất quán dưới 1ms. Ở phiên bản mới, Redis bổ sung nhiều tính năng quan trọng cho AI workload:

• Vector Sets và RediSearch gộp vào core, không còn cần module riêng.
• Client-side caching với RESP3 tracking — giảm round-trip khi key không đổi.
• Multi-threaded I/O cho phép tận dụng nhiều core cho network processing.
• Streams làm hàng đợi sự kiện nhẹ, phù hợp log agent activity trước khi ghi vào ClickHouse.
• JSON native type thay cho việc serialize/deserialize thủ công.

flowchart TB
    subgraph Redis["Redis 8 Cluster"]
        direction TB
        A1["Shard 1
Exact Cache
String / Hash"]
        A2["Shard 2
Semantic Index
Vector HNSW"]
        A3["Shard 3
Rate Limit
Token Bucket"]
        A4["Shard 4
Session State
Agent Memory"]
    end
    App["LLM Agent"] -->|"GET / SET"| A1
    App -->|"FT.SEARCH KNN"| A2
    App -->|"INCR / EXPIRE"| A3
    App -->|"JSON.GET"| A4
    A1 -.->|"Stream Events"| CH["ClickHouse
ai_events"]
    A2 -.->|"Stream Events"| CH
    style App fill:#e94560,stroke:#fff,color:#fff
    style A1 fill:#0f3460,stroke:#fff,color:#fff
    style A2 fill:#0f3460,stroke:#fff,color:#fff
    style A3 fill:#0f3460,stroke:#fff,color:#fff
    style A4 fill:#0f3460,stroke:#fff,color:#fff
    style CH fill:#4CAF50,stroke:#fff,color:#fff

Redis 8 đa chức năng trong kiến trúc LLM

5.1. Eviction policy cho semantic cache

Với semantic cache, LRU/LFU thuần tuý không còn phù hợp — hai entry gần giống nhau về embedding nên được gộp chứ không phải loại bỏ ngẫu nhiên. Các chiến lược thực chiến:

• TTL theo độ ổn định của câu trả lời: câu trả lời về chính sách (ít đổi) — TTL 24h; câu trả lời chứa giá sản phẩm — TTL 5 phút.
• Score-based eviction: tính điểm hit_count × recency_decay và dùng sorted set ZSET để xoá entry thấp nhất.
• Dedup bằng khoảng cách: khi ghi entry mới, nếu tìm được entry cũ với similarity > 0.95 thì gộp (tăng hit_count), không thêm bản sao.
• Version tagging: mỗi entry mang source_doc_hash, khi tài liệu nguồn thay đổi, invalidate toàn bộ entry cùng hash.

6. ClickHouse — backbone cho AI Observability

Khi hệ thống Multi-Agent chạy production, bạn cần trả lời các câu hỏi như: "Cache hit rate hôm qua?", "Agent nào đốt nhiều token nhất?", "Tool call nào có error rate cao bất thường?", "P95 latency theo giờ ra sao?". Đây là OLAP workload — quét hàng trăm triệu event, group theo nhiều chiều. Postgres không chịu nổi tốc độ này; Elasticsearch đắt và phức tạp. ClickHouse là đáp án: cột-hướng, nén tốt, query phút-tỷ-dòng trong vài giây.

6.1. Schema ai_events cho LLM pipeline

CREATE TABLE ai_events
(
    event_time       DateTime64(3),
    request_id       String,
    agent_name       LowCardinality(String),
    model            LowCardinality(String),
    layer            LowCardinality(String),  -- 'L1_exact' | 'L2_semantic' | 'L3_prompt' | 'llm'
    cache_result     LowCardinality(String),  -- 'hit' | 'miss' | 'bypass'
    input_tokens     UInt32,
    cached_tokens    UInt32,
    output_tokens    UInt32,
    latency_ms       UInt32,
    similarity       Float32,
    cost_usd         Float64,
    tool_name        LowCardinality(String),
    user_id          String,
    tenant_id        LowCardinality(String),
    error_code       LowCardinality(String),
    trace_id         String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (tenant_id, event_time, agent_name)
TTL event_time + INTERVAL 90 DAY;

Ba điểm thiết kế quan trọng: (1) dùng LowCardinality cho các cột enum để giảm dung lượng và tăng tốc group-by hàng chục lần, (2) PARTITION BY theo tháng để prune phân vùng hiệu quả, (3) ORDER BY đặt tenant_id trước vì đa số query đều filter theo tenant trong multi-tenant SaaS.

6.2. Materialized Views để phục vụ dashboard real-time

Dashboard không thể quét lại cả bảng gốc mỗi lần refresh. Dùng Materialized View để roll-up dữ liệu theo phút/giờ và ghi sang bảng *_mv:

CREATE TABLE ai_events_1m
(
    minute           DateTime,
    tenant_id        LowCardinality(String),
    agent_name       LowCardinality(String),
    layer            LowCardinality(String),
    cache_result     LowCardinality(String),
    requests         AggregateFunction(count, UInt64),
    total_tokens     AggregateFunction(sum, UInt64),
    total_cost       AggregateFunction(sum, Float64),
    p95_latency      AggregateFunction(quantile(0.95), UInt32)
)
ENGINE = AggregatingMergeTree
ORDER BY (tenant_id, minute, agent_name, layer, cache_result);

CREATE MATERIALIZED VIEW ai_events_1m_mv TO ai_events_1m AS
SELECT
    toStartOfMinute(event_time) AS minute,
    tenant_id,
    agent_name,
    layer,
    cache_result,
    countState() AS requests,
    sumState(toUInt64(input_tokens + output_tokens)) AS total_tokens,
    sumState(cost_usd) AS total_cost,
    quantileState(0.95)(latency_ms) AS p95_latency
FROM ai_events
GROUP BY minute, tenant_id, agent_name, layer, cache_result;

Với cấu trúc này, dashboard "cache hit rate theo phút của agent X trong 24h qua" chạy dưới 100ms trên bảng tổng hợp vài chục nghìn dòng, thay vì quét hàng chục triệu dòng sự kiện gốc.

6.3. Các query "vàng" cho SRE vận hành LLM

Cache hit rate theo tầng trong 1 giờ gần nhất:

SELECT
    layer,
    countIf(cache_result = 'hit') / count() AS hit_rate,
    avg(latency_ms) AS avg_latency,
    sum(cost_usd) AS cost
FROM ai_events
WHERE event_time > now() - INTERVAL 1 HOUR
GROUP BY layer
ORDER BY layer;

Top 10 truy vấn đốt nhiều token nhất (dùng để tối ưu prompt hoặc thêm semantic cache thủ công):

SELECT
    request_id,
    agent_name,
    sum(input_tokens + output_tokens) AS total_tokens,
    sum(cost_usd) AS cost
FROM ai_events
WHERE event_time > today()
GROUP BY request_id, agent_name
ORDER BY total_tokens DESC
LIMIT 10;

7. Tích hợp vào Multi-Agent: Claude Code và LangGraph

Caching chỉ có giá trị khi được đặt đúng chỗ trong pipeline agent. Với Claude Code hoặc các framework như LangGraph, CrewAI, AutoGen, điểm chèn hợp lý là ở tool layer hoặc LLM proxy layer.

sequenceDiagram
    participant U as User
    participant A as Orchestrator Agent
    participant P as LLM Proxy
    participant R as Redis Cache
    participant L as Claude API
    participant C as ClickHouse
    U->>A: "Tóm tắt tài liệu X"
    A->>P: messages.create(prompt)
    P->>R: L1 exact lookup
    R-->>P: miss
    P->>R: L2 semantic KNN
    R-->>P: miss (dist 0.21)
    P->>L: forward with prompt_cache
    L-->>P: response
    P->>R: store L1 + L2
    P->>C: log event
    P-->>A: response
    A->>P: messages.create(verify)
    P->>R: L1 lookup
    R-->>P: hit (đã cache từ bước trước)
    P-->>A: cached response ~1ms
    A-->>U: Kết quả cuối
    note over P,C: Mọi event đều log vào ClickHouse

Luồng request có cache trong Multi-Agent pipeline

7.1. LLM Proxy là điểm chèn tốt nhất

Thay vì nhúng logic cache vào từng agent, đặt một LLM Proxy (ví dụ LiteLLM, Portkey hoặc tự viết) đứng giữa agent và Anthropic API. Proxy chịu trách nhiệm:

• Hash request để tra cứu L1 exact cache.
• Embed query (phần user message hoặc toàn bộ tuỳ chiến lược) để tra L2 semantic.
• Tự động chèn cache_control vào phần system/tools trước khi forward.
• Ghi event vào Redis Streams → batch consumer → ClickHouse.
• Theo dõi rate limit, retry có backoff, và failover giữa các provider.

8. Những pitfall thường gặp và cách tránh

9. Case study: áp dụng cho trợ lý nội bộ 500 nhân viên

Một setup điển hình đã được nhiều team áp dụng — minh hoạ qua timeline dưới đây:

10. Kết luận

Semantic caching kết hợp prompt caching và AI observability không còn là "optimization tuỳ chọn" — đó là một yêu cầu bắt buộc để vận hành hệ thống LLM Multi-Agent ở quy mô thực. Ba thành phần then chốt:

• Prompt Caching của Anthropic xử lý phần lặp lại của prefix prompt — miễn phí về mặt kiến trúc, chỉ cần đánh dấu đúng.
• Redis 8 với Vector Search đóng hai vai: L1 exact cache để loại request trùng lặp tuyệt đối, và L2 semantic cache để bắt các câu hỏi gần nghĩa — rẻ, nhanh, quen thuộc với SRE.
• ClickHouse làm backbone observability: schema MergeTree, Materialized Views phục vụ dashboard real-time, cho phép SRE theo dõi từng đồng token và từng mili-giây latency.

Kết hợp ba lớp này, một hệ thống Multi-Agent có thể cắt giảm 70-90% chi phí token và giảm quá nửa latency mà không hy sinh chất lượng câu trả lời. Quan trọng hơn, nó biến LLM từ một "khoản chi bất định" thành một hệ thống có thể dự báo, đo lường, và tối ưu liên tục — đúng tinh thần kỹ thuật mà các team AI Engineering năm 2026 đang theo đuổi.