Reasoning Models & Extended Thinking 2026 - Kiến trúc Adaptive Thinking, Budget Router, Reasoning Trace Caching với Redis và ClickHouse cho Claude, OpenAI o3/o4, DeepSeek R1 trong Multi-Agent Production

Posted on: 4/15/2026 9:40:54 AM

1. Cuộc cách mạng Reasoning Models: Từ "trả lời nhanh" đến "suy nghĩ sâu"

Suốt thời kỳ GPT-3 đến GPT-4, kiến trúc LLM mặc định chạy theo cơ chế single forward pass — model đọc prompt, nội bộ tính attention qua vài chục layer rồi phát token tuần tự. Chất lượng câu trả lời bị chặn bởi lượng tri thức trong trọng số và khả năng "thầm thì" qua chain-of-thought mà người dùng phải prompt thủ công. Năm 2026, cán cân đó đã dịch chuyển hẳn: Reasoning Models — hay còn gọi là "thinking models" — trở thành hạng mục riêng, nơi model được phép tiêu thụ nội bộ hàng chục ngàn token để tự lập luận, tự kiểm tra, tự backtracking trước khi phát ra một từ nào cho người dùng.

Làn sóng bắt đầu từ OpenAI o1 cuối 2024, lan sang DeepSeek R1 tháng 1/2025, Claude 3.7 Sonnet với Extended Thinking tháng 2/2025, và đến tháng 4/2026 đã chín muồi trong bộ tứ Claude Opus 4.6 / Sonnet 4.6 Adaptive Thinking, OpenAI o3/o4, DeepSeek R1-0528 và Gemini 2.5 Pro Thinking. Bản chất của bài toán không còn là "tối ưu một forward pass" mà là điều phối ngân sách suy nghĩ (thinking budget) giữa tốc độ, chi phí và chất lượng — một bài toán kinh điển của System Design đặt trên nền tảng AI.

2. Giải phẫu một thinking turn: Thinking block, signature và interleaved thinking

Trên API Claude, một response bật Extended Thinking có cấu trúc content nhiều khối xen kẽ nhau. Ở dạng đầy đủ (chưa summarize), Claude trả về:

sequenceDiagram
    participant U as User
    participant R as Router
    participant C as Claude 4.6
    participant T as Tools
    U->>R: Prompt câu hỏi phức tạp
    R->>C: messages + thinking adaptive + effort high
    C->>C: Thinking block 1 phan tich va lap ke hoach
    C->>T: tool_use goi database
    T->>C: tool_result 5200 rows
    C->>C: Thinking block 2 danh gia ket qua
    C->>T: tool_use goi calculator
    T->>C: tool_result 7500
    C->>C: Thinking block 3 tong hop
    C->>U: text block cau tra loi cuoi

Hình 1: Interleaved thinking — Claude 4.6 xen kẽ thinking block giữa mỗi tool call, giữ ngữ cảnh lập luận xuyên suốt turn

2.1. Thinking block và chữ ký mã hóa

Mỗi thinking block có ba trường quan trọng: type: "thinking", trường thinking chứa văn bản lập luận (hoặc rỗng khi display: "omitted"), và signature — một chuỗi HMAC được server ký để chứng minh khối này thuộc một cặp prompt-model cụ thể. Khi bạn đa vòng (multi-turn) có tool-use, bắt buộc phải truyền lại nguyên vẹn các thinking block cùng signature; nếu thiếu, Claude trả lỗi hoặc tự động tắt thinking trong lượt kế tiếp.

Signature còn phục vụ mục tiêu chống tampering: một agent không thể giả mạo "tôi đã suy nghĩ rồi, hãy tin tôi". Server sẽ từ chối payload có thinking block mà signature không khớp với context hash.

2.2. Interleaved thinking — Khi suy nghĩ chen vào giữa tool call

Trước đây, thinking chỉ xuất hiện một lần ở đầu turn rồi sau đó model chuyển sang hành động. Từ Claude Opus 4.6 và Sonnet 4.6, interleaved thinking trở thành mặc định trong chế độ adaptive: mỗi khi nhận tool_result, Claude có thể ngay lập tức mở một thinking block mới để đánh giá kết quả, chọn bước kế, hoặc quyết định kết luận. Điều này tương đương một vòng lặp Observe → Think → Act (OTA) chạy bên trong một lời gọi API duy nhất, thay vì phải tách thành nhiều turn và mất phí cache breakpoint giữa các turn.

Hệ quả quan trọng với kỹ sư: tổng budget_tokens trong một turn có thể lớn hơn max_tokens, vì nó đại diện cho tổng ngân sách của tất cả thinking block cộng lại trong một lượt assistant.

3. Adaptive Thinking và effort parameter: Khi model tự điều tiết

Chế độ manual {type: "enabled", budget_tokens: N} đã bị đánh dấu deprecated trên Claude Opus 4.6 và Sonnet 4.6. Thay vào đó, Anthropic khuyến cáo Adaptive Thinking:

{
  "model": "claude-sonnet-4-6",
  "thinking": { "type": "adaptive" },
  "effort": "medium",
  "max_tokens": 16000,
  "messages": [...]
}

Tham số effort có bốn mức — minimal, low, medium, high — tương ứng với ngân sách thinking khoảng 512, 2K, 8K và 32K tokens. Model tự quyết định có cần tiêu toàn bộ ngân sách hay dừng sớm: với câu hỏi factoid đơn giản, Claude có thể chỉ dùng 200 thinking tokens dù effort đặt là "high".

3.1. So sánh effort API trên các nhà cung cấp

3.2. display: summarized vs omitted — Đánh đổi latency vs debuggability

Claude 4+ không trả về thinking dạng raw mặc định. Người dùng có hai lựa chọn:

• display: "summarized" (mặc định Claude 4.6): một model nhỏ hơn tóm tắt thinking thành vài đoạn ngắn, hữu ích cho debug và prompt engineering nhưng thêm ~200-500ms độ trễ streaming đầu tiên.
• display: "omitted": chỉ trả về signature, không stream thinking_delta. Time-to-first-text-token giảm đáng kể — thích hợp cho ứng dụng voice/real-time. Vẫn bị tính phí đầy đủ cho thinking tokens.

Điều dễ gây ngộ nhận: chi phí billing không phụ thuộc vào mode hiển thị. Bạn vẫn trả tiền cho toàn bộ thinking tokens gốc, kể cả khi chỉ thấy tóm tắt. Đây là lý do ClickHouse observability cần tách thinking_tokens_raw và thinking_tokens_displayed thành hai metric độc lập.

4. Kiến trúc Production cho Reasoning Models: Router, Cache, Observability

Không phải request nào cũng xứng đáng để đốt 32K thinking tokens. Một hệ Multi-Agent trưởng thành phải có lớp điều phối ngân sách tư duy đặt trước LLM, quyết định ba thứ: (1) có bật thinking không, (2) mức effort nào, (3) có cache reasoning trace cũ không.

graph TB
    U["User hoac Agent caller"] --> CLS["Complexity Classifier"]
    CLS -->|"simple factoid"| FAST["Fast path Claude Haiku 4.5 no thinking"]
    CLS -->|"math code analysis"| BR["Budget Router"]
    BR --> RC["Reasoning Cache Redis"]
    RC -->|"HIT trace goi nho"| RET["Tra loi cache"]
    RC -->|"MISS"| LLM["Claude Sonnet 4.6 effort medium"]
    LLM --> OTEL["OpenTelemetry GenAI span"]
    LLM --> RC
    OTEL --> CH["ClickHouse traces metrics"]
    CH --> DASH["Grafana Langfuse HyperDX"]
    FAST --> OTEL
    RET --> OTEL
    style CLS fill:#e94560,stroke:#fff,color:#fff
    style BR fill:#ff9800,stroke:#fff,color:#fff
    style RC fill:#9b59b6,stroke:#fff,color:#fff
    style LLM fill:#4CAF50,stroke:#fff,color:#fff
    style CH fill:#f39c12,stroke:#fff,color:#fff

Hình 2: Kiến trúc 5 lớp cho reasoning model production — classifier, router, cache, LLM, observability

4.1. Complexity Classifier — Lớp gác trước LLM

Classifier là một model nhỏ (Claude Haiku 4.5, gpt-4o-mini, hoặc fine-tuned BERT) chạy một forward pass duy nhất để trả về score độ phức tạp ∈ [0, 1]. Feature thường dùng:

• Token count của prompt (prompt > 4K gợi ý cần thinking).
• Detected domain: math, code, logic → effort cao; chitchat, FAQ → effort minimal.
• Intent keywords: "prove", "derive", "debug this race condition", "plan the deployment" → tín hiệu mạnh.
• Historical complexity từ cùng user/session (pulled từ ClickHouse).

Quyết định cuối cùng là lookup trong bảng policy: score ∈ [0, 0.3) → Haiku no thinking, [0.3, 0.6) → Sonnet effort low, [0.6, 0.85) → Sonnet effort medium, [0.85, 1.0] → Opus effort high. Chính sách này có thể học online bằng contextual bandit (Thompson sampling) — đây là điểm giao thoa với bài viết Agent Router & Model Cascading 2026 trên anhtu.dev.

4.2. Budget Router — Ngân sách thinking cho cả ngày

Ngay cả khi classifier nói "phức tạp", hệ thống vẫn cần kiểm soát ngân sách tổng theo tenant/org. Budget Router dùng Redis để track rolling-window consumption:

# Redis token bucket cho reasoning budget
KEY: reasoning:budget:org_{id}:{yyyymmdd}
TYPE: Hash
FIELDS:
  max_thinking_tokens: 50000000   # 50M tokens/ngay
  used_thinking_tokens: 17423500
  soft_limit_alert: 0.8           # canh bao khi dat 80%
  hard_limit_alert: 0.95          # ha effort xuong low khi dat 95%

Khi used/max > 0.95, router tự động downgrade effort từ high về medium (hoặc từ Opus về Sonnet) cho phần còn lại của ngày. Cơ chế này bảo vệ org khỏi "tai nạn chi phí" khi một agent rơi vào vòng lặp reasoning vô tận.

5. Reasoning Trace Caching: Khi model không cần suy nghĩ lại

Một trong những insight quan trọng nhất của 2026 là reasoning trace có thể cache được y như output text. Với hai request có prompt gần giống nhau semantic, ta không cần bắt Claude suy nghĩ lại — chỉ cần trả về kết luận kèm trace cũ.

5.1. Ba tầng cache cho reasoning

graph LR
    Q["Query"] --> L1["L1 Exact hash Redis 50us"]
    L1 -->|miss| L2["L2 Semantic embedding Redis 8 VSETS 8ms"]
    L2 -->|miss| L3["L3 Provider prompt cache Claude 30ms"]
    L3 -->|miss| LLM["LLM thinking 5-30s"]
    L1 -->|hit| R["Response"]
    L2 -->|hit| R
    L3 -->|hit| R
    style L1 fill:#4CAF50,stroke:#fff,color:#fff
    style L2 fill:#2196F3,stroke:#fff,color:#fff
    style L3 fill:#9b59b6,stroke:#fff,color:#fff
    style LLM fill:#e94560,stroke:#fff,color:#fff

Hình 3: Ba tầng cache — exact match, semantic match và provider-level prompt cache

5.1. L1 — Exact hash cache

Dành cho request bit-perfect giống nhau. Key là SHA-256 của (model, effort, system_prompt, messages_normalized). Value gồm cả text, thinking_summary và signature. TTL thường 1-24 giờ tùy domain. Redis 8 với module JSON lưu toàn bộ payload an toàn.

5.2. L2 — Semantic cache với Redis 8 Vector Sets

Dành cho request "gần giống nhau": khác cách diễn đạt nhưng cùng ý. Dùng embedding model (voyage-3, cohere-embed-v4) sinh vector 1024-d, lưu vào Redis 8 VSETS (xem thêm bài Redis 8 Vector Sets 2026). Tra cứu với cosine similarity threshold 0.93. Để tránh cache poisoning, luôn kèm guard tests: nếu câu hỏi chứa số liệu cụ thể (ngày, giá), bypass semantic cache.

# Redis 8 VSETS cho reasoning semantic cache
VSET.CREATE reasoning_cache DIM 1024 METRIC COSINE QUANTIZE Q8
VSET.ADD reasoning_cache "q:a1b2c3" \
  VALUES 0.012 -0.34 0.88 ... \
  ATTRS '{"thinking_summary":"...","text":"...","cost_cents":240}'

VSET.SEARCH reasoning_cache \
  VALUES 0.011 -0.33 0.87 ... \
  K 3 \
  FILTER "@domain=='math' AND @effort_ge=='medium'"

5.3. L3 — Provider-level prompt cache

Ngay cả khi L1 và L2 miss, các nhà cung cấp lớn đều có prompt cache nội bộ: Claude có 5 phút TTL cho system prompt và tool definitions; OpenAI tự cache implicit theo prefix token. Điểm cần chú ý: thinking block từ turn trước bị loại khỏi context nhưng vẫn tính vào token cache đọc. Nếu bạn thiết kế agent loop có nhiều bước, kích thước cache sẽ phình nhanh vì thinking block tích lũy.

6. Observability Reasoning Model với ClickHouse

Quan sát reasoning model khác quan sát LLM thường ở ba điểm: (1) phải tách biệt thinking_tokens và output_tokens, (2) phải theo dõi reasoning quality qua LLM-as-judge score, và (3) phải lưu trữ trace dài hạn để phân tích mode failure. ClickHouse là lựa chọn kinh điển cho workload này nhờ khả năng nén cột (LZ4 + Delta) giúp chi phí lưu trữ trace chỉ bằng 5-10% so với dạng JSONB thông thường.

6.1. Schema ClickHouse cho reasoning traces

CREATE TABLE reasoning_traces
(
    trace_id        String,
    span_id         String,
    parent_span_id  String,
    org_id          UInt64,
    user_id         UInt64,
    ts              DateTime64(3) CODEC(DoubleDelta, ZSTD(1)),
    model           LowCardinality(String),
    effort          LowCardinality(String),
    display_mode    LowCardinality(String),
    domain          LowCardinality(String),
    prompt_tokens       UInt32 CODEC(T64, LZ4),
    cache_read_tokens   UInt32 CODEC(T64, LZ4),
    thinking_tokens     UInt32 CODEC(T64, LZ4),
    output_tokens       UInt32 CODEC(T64, LZ4),
    latency_ttft_ms     UInt32 CODEC(Delta, LZ4),
    latency_e2e_ms      UInt32 CODEC(Delta, LZ4),
    cost_usd            Float32,
    cache_layer_hit     Enum8('none'=0, 'L1'=1, 'L2'=2, 'L3'=3),
    judge_score         Nullable(Float32),
    thinking_summary    String CODEC(ZSTD(3)),
    final_text_hash     FixedString(32)
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(ts)
ORDER BY (org_id, model, ts)
TTL ts + INTERVAL 90 DAY
SETTINGS index_granularity = 8192;

6.2. Truy vấn phát hiện "loạn budget"

Một anti-pattern phổ biến: agent đặt effort high cho câu hỏi có thể giải bằng effort low. Query phát hiện:

SELECT
    org_id,
    model,
    domain,
    quantile(0.95)(thinking_tokens) AS p95_thinking,
    avg(judge_score)                AS avg_quality,
    countIf(effort='high') / count() AS high_effort_ratio,
    sum(cost_usd)                   AS cost_day
FROM reasoning_traces
WHERE ts >= now() - INTERVAL 1 DAY
  AND effort = 'high'
  AND thinking_tokens < 2000      -- suy nghi it ma van dat high
GROUP BY org_id, model, domain
HAVING high_effort_ratio > 0.4    -- hon 40% request dat high
ORDER BY cost_day DESC
LIMIT 20;

Kết quả cho biết tenant nào đang "phung phí" ngân sách — tín hiệu để điều chỉnh classifier hoặc huấn luyện lại bandit router.

7. So sánh bốn mô hình reasoning chủ lực 2026

7.1. Ma trận chọn model theo workload

graph TB
    S["Workload"] --> Q1{"Co tool use da buoc?"}
    Q1 -->|Co| Q2{"Context lon hon 200K?"}
    Q1 -->|Khong| Q3{"Reasoning ve hinh anh?"}
    Q2 -->|Co| CSO["Claude Sonnet 4.6"]
    Q2 -->|Khong| CSO2["Claude Sonnet 4.6 hoac o4 mini"]
    Q3 -->|Co| O4["o4 mini"]
    Q3 -->|Khong| Q4{"Ngan sach cuc han?"}
    Q4 -->|Co| DSR["DeepSeek R1 0528 self host"]
    Q4 -->|Khong| Q5{"Context 1M tokens?"}
    Q5 -->|Co| GEM["Gemini 2.5 Pro Thinking"]
    Q5 -->|Khong| CSO3["Claude Sonnet 4.6"]
    style CSO fill:#e94560,stroke:#fff,color:#fff
    style CSO2 fill:#e94560,stroke:#fff,color:#fff
    style CSO3 fill:#e94560,stroke:#fff,color:#fff
    style O4 fill:#2196F3,stroke:#fff,color:#fff
    style DSR fill:#9b59b6,stroke:#fff,color:#fff
    style GEM fill:#4CAF50,stroke:#fff,color:#fff

Hình 4: Cây quyết định chọn reasoning model theo đặc tính workload

8. Multi-Agent với Reasoning: Ai cần suy nghĩ, ai không?

Sai lầm phổ biến nhất khi xây Multi-Agent là bật extended thinking cho mọi subagent. Kết quả: chi phí nổ 4-7x so với pipeline không thinking, trong khi chất lượng chỉ cải thiện ở 1-2 khâu critical. Công thức đúng là phân vai rõ ràng: thinking model làm "đầu não", fast model làm "tay chân".

8.1. Pattern Planner-Executor

graph TB
    U["User request"] --> P["Planner Claude Opus 4.6 effort high"]
    P -->|plan.json| O["Orchestrator"]
    O --> E1["Executor 1 Haiku 4.5"]
    O --> E2["Executor 2 Haiku 4.5"]
    O --> E3["Executor 3 Haiku 4.5"]
    E1 --> A["Aggregator Sonnet 4.6 effort low"]
    E2 --> A
    E3 --> A
    A --> U
    style P fill:#e94560,stroke:#fff,color:#fff
    style A fill:#ff9800,stroke:#fff,color:#fff
    style E1 fill:#4CAF50,stroke:#fff,color:#fff
    style E2 fill:#4CAF50,stroke:#fff,color:#fff
    style E3 fill:#4CAF50,stroke:#fff,color:#fff

Hình 5: Planner-Executor — chỉ Planner và Aggregator được phép thinking, Executor chạy Haiku không thinking

Planner là điểm duy nhất bắt buộc thinking high: đây là nơi quyết định kiến trúc đáp án, chia task, xác định ràng buộc. Một kế hoạch sai sẽ làm toàn bộ executor đi lạc hướng — chi phí sửa sai lớn hơn nhiều so với chi phí thinking ở bước plan. Ngược lại, executor nhận task rất cụ thể ("gọi API X, trích trường Y, trả JSON schema Z") — hoàn toàn không cần reasoning sâu, chạy Haiku 4.5 no-thinking là đủ.

8.2. Pattern Debate / Self-Consistency

Với bài toán có tính subjective hoặc rủi ro cao (legal review, medical triage, code security audit), chạy N agent song song, mỗi agent effort medium, rồi dùng một judge agent effort high để chọn câu trả lời tốt nhất hoặc merge. Đây là phiên bản multi-process của "test-time compute scaling" đã phân tích trong bài Test-Time Compute Scaling 2026.

Lưu ý: để giảm chi phí, hãy chạy song song qua cùng một prompt cache breakpoint. Provider như Claude chia sẻ cache cho các request cùng prefix trong 5 phút, nên 5 agent chạy cùng context 20K token chỉ tính tiền prompt 1 lần + 5 lần thinking — tiết kiệm đáng kể so với 5 request độc lập.

9. Chống reasoning loop và stall: Cơ chế bảo vệ production

Reasoning model có một mode failure không tồn tại ở model thường: reasoning loop — model rơi vào vòng lặp "Let me reconsider... actually, wait..." và đốt hết budget mà không đưa ra đáp án. Với DeepSeek R1, hiện tượng này hay gặp ở math olympiad prompt; với Claude, hay gặp khi effort = high + prompt có điều kiện mâu thuẫn.

9.1. Cơ chế chống loop ở tầng client

• Token budget hard cap: set max_tokens (bao gồm output + thinking) ở mức hợp lý, ví dụ 8K cho Q&A, 32K cho code generation.
• Soft timer: nếu TTFT vượt 30s, abort SSE stream và retry với effort thấp hơn.
• Repetition detector: cắt stream nếu 3 đoạn thinking liên tiếp có Jaccard similarity > 0.85.
• Circuit breaker per-user: nếu cùng user gặp 3 loop trong 1 phút, đóng mạch và chuyển sang Haiku trong 10 phút.

9.2. Retry và fallback ladder

graph LR
    REQ["Request"] --> O["Opus 4.6 effort high"]
    O -->|loop timeout| S["Sonnet 4.6 effort medium"]
    S -->|loop timeout| SL["Sonnet 4.6 effort low"]
    SL -->|loop timeout| H["Haiku 4.5 no thinking"]
    H -->|fail| FB["Fallback canned response"]
    style O fill:#e94560,stroke:#fff,color:#fff
    style S fill:#ff9800,stroke:#fff,color:#fff
    style SL fill:#ffc107,stroke:#000
    style H fill:#4CAF50,stroke:#fff,color:#fff
    style FB fill:#888,stroke:#fff,color:#fff

Hình 6: Fallback ladder — lần lượt tụt effort rồi tụt model để đảm bảo SLO

10. Bảo mật: Thinking trace có thể rò rỉ dữ liệu nhạy cảm

Một phát hiện đáng lo của 2026 là thinking trace thường chứa thông tin nhạy cảm hơn cả câu trả lời cuối. Khi model "suy nghĩ thành tiếng", nó có thể liệt kê nội dung email, code key API, hoặc phân tích chi tiết hồ sơ y tế — những thông tin sau đó bị lược bỏ khỏi text cuối. Nếu bạn stream trace qua WebSocket về client hoặc log toàn bộ trace vào ClickHouse không mã hóa, bạn đang mở một kênh rò rỉ lớn hơn cả output chính.

10.1. Checklist bảo mật reasoning trace

• Mặc định không stream thinking_delta về client. Dùng display: "omitted" ở production, chỉ bật "summarized" ở admin panel có quyền.
• Redact PII trước khi lưu vào ClickHouse: email, số điện thoại, SSN, credit card, IP address.
• Mã hóa column level: lưu thinking_summary trong column có CODEC AES256GCM, chỉ service có KMS key mới đọc được.
• Tách retention: text output giữ 90 ngày, thinking trace giữ 7 ngày.
• Audit log truy cập mỗi lần có query SELECT thinking_summary, ghi user và lý do.

11. Đồng bộ thinking blocks qua Agent Memory: Pattern nâng cao

Trong hệ Agent Memory đa tầng (xem bài Agent Memory Architecture 2026), một câu hỏi nan giải là: thinking block có nên lưu vào long-term memory không? Trả lời: không lưu raw, nhưng lưu summary distilled.

Cách làm: sau mỗi turn có thinking, chạy một agent nhỏ (Haiku 4.5) để chắt lọc thinking trace thành 2-3 câu "bài học" và lưu vào memory table dưới dạng lesson_learned. Turn sau, Planner sẽ retrieve lesson này qua semantic search và inject vào context — cho phép model "tiếp nối" lập luận cũ mà không cần truyền toàn bộ thinking block (sẽ tốn token và phá cache).

# Pseudocode distill thinking
def distill_thinking(trace_block, judge_model="claude-haiku-4-5"):
    prompt = f"""
    Below is the internal reasoning of a previous agent turn.
    Extract 2-3 concrete lessons or decisions that future agents
    should remember. Be terse, no narration.

    REASONING:
    {trace_block.thinking_summary}
    """
    return llm.complete(judge_model, prompt, max_tokens=200)

lesson = distill_thinking(response.thinking_block)
redis.xadd(f"agent_memory:{session_id}",
           {"type": "lesson", "content": lesson,
            "trace_id": response.trace_id})

12. Lộ trình phát triển reasoning models: Timeline 2024–2026

13. Kết luận: Reasoning không phải phép màu, mà là bài toán System Design

Trong hai năm, reasoning models đã đi từ demo học thuật sang hạ tầng production phục vụ hàng triệu request/ngày. Bài học quan trọng nhất không phải kỹ thuật huấn luyện mà là: giá trị thực của reasoning chỉ được giải phóng khi có một lớp hệ thống phía trước quyết định bật, cache, giám sát và fallback đúng cách. Một team dùng Claude Sonnet 4.6 high-effort cho mọi request sẽ trả chi phí 5-7 lần cao hơn, trong khi một team có complexity classifier + reasoning cache + budget router + ClickHouse observability có thể đạt chất lượng tương đương với chi phí rẻ hơn 60-70%.

Đây chính là lý do kỹ năng "System Design cho AI" trở thành giá trị cốt lõi của kỹ sư 2026: không chỉ là viết prompt và gọi API, mà là thiết kế hệ thống biết khi nào nên để LLM suy nghĩ, bao nhiêu là đủ, lưu trữ và tái sử dụng kết quả ra sao. Reasoning models là công cụ mạnh, nhưng nếu không có hạ tầng System Design đi kèm, chúng sẽ trở thành một lỗ đen chi phí lớn nhất trong ngân sách cloud của bạn.

14. Nguồn tham khảo

• Anthropic — Building with Extended Thinking (Claude API Docs)
• Anthropic — Adaptive Thinking Guide
• Anthropic — What's new in Claude 4.6
• OpenAI — Introducing o3 and o4-mini
• OpenAI — Reasoning models API Guide
• DeepSeek — Reasoning Model (deepseek-reasoner) Docs
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning (arXiv)
• MLCommons — DeepSeek Reasoning for MLPerf Inference v5.1
• ClickHouse — The three villains to agentic observability
• ClickHouse — Understanding LLM Observability
• ClickHouse — Tracing OpenAI agents with ClickStack
• Redis — RAG at Scale: Production AI Systems 2026
• Portkey — Complete guide to LLM observability 2026
• DeepSeek R1 vs OpenAI o3 — Ultimate 2026 Reasoning Model Comparison