Test-Time Compute Scaling 2026 - Chain-of-Thought, Self-Consistency, Tree-of-Thoughts và Process Reward Models cho Multi-Agent AI với Redis và ClickHouse

Posted on: 4/14/2026 5:10:34 PM

Trong gần một thập kỷ, công thức thành công của các mô hình ngôn ngữ lớn là scale up — tăng số tham số, tăng dữ liệu huấn luyện, tăng số GPU. Nhưng từ cuối năm 2024, cùng với sự xuất hiện của OpenAI o1, DeepSeek R1 và Claude extended thinking, ngành công nghiệp AI chứng kiến một bước chuyển âm thầm nhưng triệt để: thay vì chỉ tăng kích thước model, chúng ta bắt đầu đầu tư nhiều compute hơn vào chính lúc suy luận. Cách làm này được gọi là test-time compute scaling — và nó đang định nghĩa lại cách kỹ sư thiết kế hệ thống multi-agent AI production năm 2026. Bài viết này đi sâu vào các kỹ thuật cốt lõi (Chain-of-Thought, Self-Consistency, Tree-of-Thoughts, Best-of-N, Process Reward Models), cách phân bổ compute tối ưu cho từng prompt, và kiến trúc đầy đủ để triển khai reasoning ở quy mô lớn với Redis và ClickHouse.

1. Vì sao test-time compute trở thành trục scaling mới của AI 2026

Suốt giai đoạn 2020-2023, mọi cuộc tranh luận về năng lực LLM đều xoay quanh scaling laws của Kaplan và Chinchilla: muốn model thông minh hơn, hãy tăng tham số, tăng token huấn luyện. Nhưng khi ngành bước vào 2024, ba hiện tượng cùng lúc xuất hiện:

• Chi phí pretraining leo thang theo cấp số mũ: Huấn luyện một model 1T tham số cần hàng chục nghìn GPU H100 trong nhiều tháng, chi phí vượt ngưỡng hàng trăm triệu USD. Doanh nghiệp trung bình không thể tiếp tục đuổi theo cuộc đua này.
• Lợi nhuận giảm dần khi tăng tham số: Chênh lệch benchmark giữa một model 70B được huấn luyện tốt và một model 400B ngày càng mỏng trên nhiều tác vụ thực tế.
• GPU inference dư thừa công suất tính toán: Khi một LLM sinh câu trả lời tiêu chuẩn, GPU thực tế chỉ dùng 20-40% khả năng. Có cả một "kho" compute chưa khai thác ở tầng inference.

Từ đó, một câu hỏi đơn giản nhưng mang tính cách mạng đã được đặt ra: thay vì nhồi thêm tham số vào model, điều gì sẽ xảy ra nếu ta cho model suy nghĩ lâu hơn ngay tại thời điểm trả lời?

Kết quả là ngoạn mục. Một model 7B được phép sinh ra chuỗi suy luận dài và tự kiểm tra có thể vượt một model 70B trả lời "một phát ăn ngay" trên các bài toán toán học và lập trình. Với cùng budget FLOPs, việc chi compute cho inference đôi khi hiệu quả gấp nhiều lần so với chi compute cho pretraining thêm. Đây chính là phát hiện then chốt của các nghiên cứu test-time scaling từ DeepMind, OpenAI và DeepSeek giai đoạn 2024-2025.

2. Phân loại các kỹ thuật test-time scaling

Các kỹ thuật tăng compute tại thời điểm inference được chia thành hai nhóm lớn dựa trên cấu trúc tính toán: sequential scaling (kéo dài chuỗi suy luận của một lần sinh) và parallel scaling (sinh nhiều câu trả lời rồi chọn). Năm 2026, phần lớn hệ thống production kết hợp cả hai.

graph TD
    TTS["Test-Time Compute Scaling"] --> Seq["Sequential Scaling
Làm sâu 1 chuỗi"]
    TTS --> Par["Parallel Scaling
Làm nhiều chuỗi"]
    Seq --> CoT["Chain-of-Thought
Long reasoning trace"]
    Seq --> Rev["Self-Revision
Sửa lỗi từng bước"]
    Seq --> Bud["Budget Forcing
Ép model suy nghĩ đủ lâu"]
    Par --> BoN["Best-of-N
Sinh N lời giải, chọn 1"]
    Par --> SC["Self-Consistency
Majority voting"]
    Par --> ToT["Tree-of-Thoughts
Beam search trên nhánh"]
    Par --> MCTS["MCTS Reasoning
Monte Carlo Tree Search"]
    BoN --> Ver["Verifier / PRM
Chấm điểm từng câu"]
    ToT --> Ver
    MCTS --> Ver
    style TTS fill:#e94560,stroke:#fff,color:#fff
    style Seq fill:#0f3460,stroke:#fff,color:#fff
    style Par fill:#0f3460,stroke:#fff,color:#fff
    style Ver fill:#4CAF50,stroke:#fff,color:#fff

Sequential scaling tăng compute theo chiều dọc: model sinh ra một chuỗi suy luận dài, thậm chí tự dừng lại giữa chừng để sửa lỗi, kiểm tra giả thiết, thử phương án khác. Chi phí chủ yếu nằm ở pha decode kéo dài, mỗi token tiêu tốn băng thông HBM của GPU. Claude extended thinking và OpenAI o1/o3 thuộc nhóm này: chúng được huấn luyện RL để biết khi nào cần "suy nghĩ thêm" và khi nào nên dừng.

Parallel scaling tăng compute theo chiều ngang: cùng một prompt được chạy N lần với temperature cao, tạo ra nhiều đáp án ứng viên. Sau đó, một cơ chế chọn lọc — majority voting, reward model, hay search heuristic — sẽ quyết định đáp án cuối. Ưu điểm lớn nhất là dễ dàng scale ngang: mỗi ứng viên có thể chạy trên một worker riêng, thích hợp với kiến trúc multi-agent phân tán.

3. Chain-of-Thought và kỹ thuật sinh chuỗi suy luận dài

Chain-of-Thought (CoT) là nền tảng của mọi kỹ thuật test-time scaling hiện đại. Ý tưởng gốc từ năm 2022 của Google Brain rất đơn giản: thay vì yêu cầu model đưa thẳng đáp án, ta khuyến khích nó viết ra các bước trung gian. Nhưng năm 2026, CoT đã tiến hóa qua ba thế hệ rõ rệt.

Điểm khác biệt quan trọng nhất của thế hệ 3 là sự xuất hiện tự nhiên của các "meta-hành vi": model tự dừng lại nói "chờ đã, có vẻ tôi đang sai", rồi quay lại sửa. Những hành vi này không được dạy trực tiếp — chúng là hệ quả của quá trình RL với reward dựa trên kết quả cuối. Đây là cơ chế chính giải thích vì sao test-time compute có thể thay thế được một phần đáng kể scale pretraining.

4. Best-of-N, Self-Consistency và bài toán chọn đáp án tốt

Khi đã có khả năng sinh nhiều đáp án ứng viên, câu hỏi trung tâm trở thành: chọn đáp án nào?. Đây là nơi kỹ thuật parallel scaling chia thành nhiều nhánh khác biệt tinh tế nhưng quan trọng về mặt kiến trúc.

Self-Consistency từ Google (2022) vẫn là baseline mạnh đáng ngạc nhiên: chỉ cần sinh 10-40 chuỗi suy luận rồi lấy majority vote trên đáp số cuối, độ chính xác trên các benchmark toán tăng 10-20 điểm phần trăm so với greedy decoding. Điểm mấu chốt: nó không cần verifier riêng, dễ triển khai, parallelize hoàn hảo. Điểm yếu: chỉ áp dụng được khi có "đáp số" rút gọn được, không dùng được cho open-ended tasks.

Best-of-N với reward model mạnh hơn nhưng đắt hơn. Ta sinh N ứng viên, đưa từng đáp án qua một reward model, chọn cái điểm cao nhất. Nếu reward model chỉ chấm kết quả cuối, đó là Outcome Reward Model (ORM) — đơn giản nhưng dễ bị đánh lừa bởi các chain có đáp án đúng nhờ may mắn. Nếu reward model chấm điểm từng bước trong chain, đó là Process Reward Model (PRM) — đắt hơn nhưng chất lượng chọn cao hơn hẳn.

5. Tree-of-Thoughts và search có cấu trúc

Best-of-N và Self-Consistency sinh các chain độc lập. Tree-of-Thoughts (ToT) đưa ý tưởng lên một bậc cao hơn: cấu trúc không gian suy luận thành một cây, tại mỗi node là một "thought" (một bước suy luận), sau đó chạy search có kiểm soát — BFS, DFS, hoặc beam search — với heuristic chấm điểm cho mỗi nhánh. Model không chỉ sinh tiếp từ token cuối mà có thể quay lại một nhánh đã dừng để thử hướng khác.

graph TD
    Q["Prompt gốc"] --> T1["Thought 1A"]
    Q --> T2["Thought 1B"]
    Q --> T3["Thought 1C"]
    T1 --> T1a["Thought 2A"]
    T1 --> T1b["Thought 2B"]
    T2 --> T2a["Thought 2C"]
    T3 --> Prune1["Loại bỏ
điểm thấp"]
    T1a --> Ans1["Câu trả lời 1
điểm 0.92"]
    T1b --> Ans2["Câu trả lời 2
điểm 0.74"]
    T2a --> Ans3["Câu trả lời 3
điểm 0.88"]
    Ans1 --> Best["Chọn đáp án
điểm cao nhất"]
    Ans3 --> Best
    style Q fill:#e94560,stroke:#fff,color:#fff
    style Best fill:#4CAF50,stroke:#fff,color:#fff
    style Prune1 fill:#888,stroke:#fff,color:#fff

Tree-of-Thoughts đặc biệt hiệu quả với các bài toán cần lập kế hoạch nhiều bước, nơi một quyết định sai ở bước đầu có thể khóa toàn bộ không gian lời giải. Một nhánh khác cùng dòng ý tưởng là Monte Carlo Tree Search (MCTS) cho LLM, lấy cảm hứng từ AlphaGo: ta mô phỏng nhiều rollout từ mỗi node, cập nhật ước lượng giá trị, rồi chọn nhánh có value cao nhất. MCTS được các hệ thống như Search-o1 và AlphaProof áp dụng để giải các bài toán Olympic.

Cái giá phải trả của ToT và MCTS là chi phí compute và độ phức tạp kỹ thuật. Với mỗi node mới, ta phải gọi LLM ít nhất một lần để sinh thought và một lần nữa để chấm điểm. Một cây có chiều sâu 5 và fanout 3 đã sinh ra 243 node, tức 486+ call LLM. Không có semantic cache và prefix cache, chi phí này sẽ khiến mọi hệ thống production phá sản.

6. Process Reward Model vs Outcome Reward Model

Trái tim của mọi chiến lược parallel scaling cao cấp là verifier. Verifier là model con chấm điểm độ đúng đắn của một câu trả lời hoặc của từng bước trong câu trả lời. Hai lớp verifier phổ biến:

• Outcome Reward Model (ORM): Nhận vào (câu hỏi, đáp án cuối) và xuất một điểm scalar duy nhất. Đơn giản, dễ huấn luyện từ dữ liệu cặp (đáp án đúng, đáp án sai). Nhược điểm: không phân biệt được "đúng nhờ may mắn" với "đúng nhờ suy luận chặt chẽ".
• Process Reward Model (PRM): Nhận vào (câu hỏi, chain suy luận), chấm điểm cho từng bước. Cho phép phát hiện bước sai dù đáp án cuối vẫn đúng, và ngược lại. Nhược điểm: huấn luyện khó vì cần nhãn cho từng bước — thường tạo ra bằng Monte Carlo rollout hoặc self-labeling.

Các nghiên cứu của DeepMind và OpenAI trong năm 2024 cho thấy PRM có thể cải thiện hiệu quả test-time compute từ 2x đến 4x so với ORM trên các bài toán toán học. Nhưng sự khác biệt này giảm dần khi model nền đã thực sự giỏi reasoning — ở đó, một ORM đủ tốt có thể đạt 90% hiệu năng của PRM với 1/3 chi phí huấn luyện.

7. Compute-Optimal Allocation — phân bổ compute thích ứng theo độ khó

Một trong những phát hiện quan trọng nhất của nghiên cứu test-time scaling năm 2024-2025 đến từ DeepMind: không có chiến lược test-time scaling duy nhất tối ưu cho mọi prompt. Prompt đơn giản hưởng lợi từ Self-Consistency nhỏ (N=4). Prompt trung bình hưởng lợi nhất từ PRM-guided search. Prompt cực khó cần tới budget forcing và sequential scaling dài hơi. Nếu áp dụng cùng một chiến lược cho mọi prompt, ta đang lãng phí compute cho các câu dễ và thiếu compute cho các câu khó.

Giải pháp gọi là compute-optimal allocation: một "router" đánh giá độ khó của prompt trước khi quyết định chiến lược và ngân sách compute. Router này thường là một model nhỏ (1-3B) được fine-tune để dự đoán xác suất giải đúng của model chính theo budget. Kết quả khảo sát trên các benchmark MATH, GPQA và HumanEval cho thấy compute-optimal allocation có thể cải thiện hiệu quả compute lên tới 4 lần so với một chiến lược Best-of-N tĩnh.

graph LR
    Req["Incoming request"] --> DR["Difficulty Router
1-3B classifier"]
    DR -->|"Easy"| S1["Greedy decode
1 sample"]
    DR -->|"Medium"| S2["Self-Consistency
N=8 parallel"]
    DR -->|"Hard"| S3["PRM + Tree-of-Thoughts
N=32, depth 6"]
    DR -->|"Extreme"| S4["Sequential CoT
Budget 16K tokens
+ Self-verify"]
    S1 --> Out["Final answer"]
    S2 --> Out
    S3 --> Out
    S4 --> Out
    style DR fill:#e94560,stroke:#fff,color:#fff
    style Out fill:#4CAF50,stroke:#fff,color:#fff

8. Kiến trúc production multi-agent với Redis và ClickHouse

Những kỹ thuật kể trên chỉ trở thành giá trị thực tế khi được nhúng vào một hạ tầng ổn định, có thể phục vụ hàng triệu request mỗi ngày mà không bùng nổ chi phí. Phần này mô tả kiến trúc mà nhiều đội engineering đang áp dụng năm 2026, đặc biệt khi hệ thống là multi-agent với nhiều sub-agent cần reasoning song song.

graph TB
    U["User request"] --> GW["LLM Gateway"]
    GW --> RT["Reasoning Router
chọn chiến lược TTS"]
    RT --> CK["Semantic Cache
Redis Stack + vector"]
    CK -->|"cache hit"| Fin["Response"]
    CK -->|"cache miss"| MA["Multi-Agent Orchestrator"]
    MA --> A1["Planner Agent
ToT"]
    MA --> A2["Solver Agent
Best-of-N + PRM"]
    MA --> A3["Critic Agent
Self-verify"]
    A1 --> Verify["PRM Verifier"]
    A2 --> Verify
    A3 --> Verify
    Verify --> Ag["Aggregator
majority / beam select"]
    Ag --> Fin
    Fin --> CK
    Ag -.->|"traces, steps, scores"| CH["ClickHouse
reasoning analytics"]
    A1 -.->|"KV prefix cache"| KVR["Redis KV Cache Layer
LMCache / Mooncake"]
    A2 -.-> KVR
    A3 -.-> KVR
    style U fill:#2c3e50,stroke:#fff,color:#fff
    style GW fill:#e94560,stroke:#fff,color:#fff
    style MA fill:#0f3460,stroke:#fff,color:#fff
    style Fin fill:#4CAF50,stroke:#fff,color:#fff
    style CH fill:#f39c12,stroke:#fff,color:#fff
    style KVR fill:#9b59b6,stroke:#fff,color:#fff

Bảy thành phần trong kiến trúc trên phối hợp để biến test-time compute từ lý thuyết thành công cụ production. Ba lớp quan trọng nhất liên quan trực tiếp đến Redis và ClickHouse: semantic cache, KV prefix cache layer, và reasoning analytics. Chúng ta sẽ đi chi tiết.

8.1. Redis — tầng cache đa mức cho reasoning trace

Một reasoning trace dài có thể chứa hàng nghìn token có giá trị tái sử dụng rất cao. Nếu cùng một bài toán con xuất hiện trong nhiều request khác nhau, ta có thể bỏ qua toàn bộ chuỗi suy luận đã tính xong. Có ba tầng cache Redis mà các hệ thống production 2026 thường dùng song song:

• Semantic reasoning cache: Lưu cặp (prompt embedding, chain + answer) trong Redis Stack với vector index. Khi có request mới, truy vấn ANN theo embedding, nếu độ tương đồng > 0.92 thì trả kết quả cached. Hiệu quả nhất với bài toán có câu hỏi lặp lại theo cấu trúc (FAQ, code review, quy trình).
• Step-level cache: Trong ToT và MCTS, nhiều node có cùng tiền tố suy luận. Lưu (prefix hash → thought tiếp theo) trong Redis hash cho phép các lần search sau tái sử dụng subtree đã expand. Tiết kiệm 40-60% compute trên các workload lặp.
• KV prefix cache: Khi nhiều request cùng dùng một system prompt hoặc cùng một đoạn context lớn, KV cache của prefix đó có thể đem ra khỏi GPU và đổ về Redis (hoặc một tầng RDMA như Mooncake/LMCache). Lần sau, GPU chỉ cần load KV đã tính sẵn thay vì prefill lại — có thể giảm tới 90% chi phí pha prefill.

Redis phù hợp cho vai trò này vì hai lý do: độ trễ sub-millisecond không làm gãy pipeline reasoning, và cấu trúc dữ liệu đa dạng (string, hash, sorted set, stream, vector index) đủ giàu để phục vụ cả ba tầng cache mà không cần thêm hệ thống khác.

8.2. ClickHouse — tầng observability cho reasoning

Không thể tối ưu cái không đo được. Một hệ thống reasoning production năm 2026 sinh ra một khối lượng telemetry khổng lồ: với mỗi request, ta có thể muốn ghi lại hàng chục trường dữ liệu về cả chain, các node trong cây, điểm số của reward model, latency của từng bước. ClickHouse trở thành lựa chọn mặc định cho tầng này nhờ khả năng nén mạnh, ingestion nhanh, và hỗ trợ truy vấn analytical trên tỉ dòng dữ liệu.

Một schema điển hình cho reasoning analytics có thể trông như sau:

CREATE TABLE reasoning_events (
    ts              DateTime64(3),
    request_id      String,
    tenant_id       LowCardinality(String),
    agent_id        LowCardinality(String),
    strategy        LowCardinality(String),  -- 'cot', 'boN', 'tot', 'mcts'
    difficulty      Float32,
    n_candidates    UInt16,
    n_steps         UInt16,
    tokens_in       UInt32,
    tokens_out      UInt32,
    tokens_reasoning UInt32,
    prm_best_score  Float32,
    prm_avg_score   Float32,
    final_correct   Nullable(UInt8),
    latency_ms      UInt32,
    gpu_cost_usd    Float32,
    model           LowCardinality(String),
    cache_level     LowCardinality(String)   -- 'miss', 'semantic', 'step', 'prefix'
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (tenant_id, agent_id, ts)
TTL ts + INTERVAL 90 DAY;

Với bảng này, ta có thể trả lời những câu hỏi quan trọng trong vài giây trên hàng tỉ dòng: chiến lược TTS nào đang đốt nhiều GPU nhất mà không cải thiện accuracy? Tỉ lệ cache hit theo tenant là bao nhiêu? Có bất thường nào ở phân phối n_steps trong 15 phút vừa qua? Những truy vấn này là nền tảng cho FinOps và cho chính các router compute-optimal — chúng thường dùng chính dữ liệu ClickHouse để tái huấn luyện định kỳ.

Một pipeline phổ biến: agent ghi sự kiện vào Kafka (hoặc Redis Stream) với tốc độ hàng trăm nghìn event/giây, rồi ClickHouse dùng Kafka Engine hoặc vector-based consumer kéo về. Materialized View tổng hợp theo phút/giờ để dashboard Grafana có thể quét dữ liệu 30 ngày trong vài trăm mili-giây.

9. Cách multi-agent tận dụng test-time compute

Khi hệ thống đã là multi-agent, test-time compute không còn đơn thuần là tăng sample hay tăng chiều dài chain — nó trở thành phân công compute giữa các agent. Một ví dụ điển hình về orchestrator bậc cao:

1. Planner agent nhận yêu cầu người dùng, chạy Tree-of-Thoughts với budget trung bình để phân rã thành 3-5 sub-task. Giai đoạn này ưu tiên độ đa dạng hơn tốc độ — ta muốn nhiều hướng tiếp cận khác nhau.
2. Solver agent xử lý từng sub-task song song. Với mỗi sub-task, Difficulty Router quyết định: sub-task dễ đi Greedy, sub-task khó đi Best-of-N với PRM. Các solver không chia sẻ KV cache GPU, nhưng chia sẻ prefix cache (system prompt, context chung) qua Redis.
3. Critic agent nhận câu trả lời của solver, chạy self-verification ngược lại (Chain-of-Verification). Nếu phát hiện mâu thuẫn, tạo feedback và yêu cầu solver retry với budget cao hơn. Critic thường là model nhỏ hơn được fine-tune chuyên biệt cho phát hiện lỗi.
4. Aggregator tổng hợp đáp án cuối, lưu trace vào ClickHouse, lưu kết quả vào Redis semantic cache, và trả về Gateway.

Điểm đáng chú ý: kiến trúc này tự nhiên hội tụ giữa hai trường phái "sequential scaling" và "parallel scaling". Planner và Critic thiên về sequential (chuỗi dài, có backtracking). Solver thiên về parallel (nhiều ứng viên). Tất cả cùng dùng chung một lớp Redis/ClickHouse phía dưới.

10. Những giới hạn cần biết trước khi triển khai

Test-time compute scaling rất mạnh, nhưng không phải cây đũa thần. Các nghiên cứu mới nhất năm 2025-2026 đã chỉ ra nhiều giới hạn quan trọng mà kỹ sư kiến trúc cần tính tới:

• Không hiệu quả với tác vụ cần kiến thức mới: Test-time compute không tạo ra tri thức chưa có trong model. Với các bài toán knowledge-intensive (cập nhật sự kiện mới, dữ liệu riêng của doanh nghiệp), tăng compute chỉ làm tăng xác suất hallucinate, không cải thiện độ chính xác. Lời giải là kết hợp với RAG hoặc tool use, không phải tăng N.
• Hiệu suất giảm dần khi N lớn: Ngoài một ngưỡng (thường quanh N=32 đến N=64), việc tăng thêm ứng viên cho lợi ích rất nhỏ nhưng chi phí thì tuyến tính. Quá điểm này, hãy đầu tư vào verifier tốt hơn thay vì N cao hơn.
• Chi phí verifier có thể vượt chi phí sinh: Với một PRM mạnh, việc chấm từng bước trên N=32 chain dài 4K token có thể tốn nhiều FLOPs hơn cả phần decode ban đầu. Quy hoạch verifier cần tính đến điều này — nhiều team dùng một verifier model nhỏ hơn model chính.
• Latency tăng tuyến tính với chuỗi sequential: Một chain 20K token có thể tốn 30-60 giây trên H100. Nếu UX yêu cầu stream dưới 2 giây, bạn không dùng được sequential scaling dài — phải chuyển sang parallel với stream hybrid.
• Khó cho tác vụ open-ended: Viết sáng tạo, tư vấn, brainstorming không có "đáp án đúng" để majority vote hay verifier chấm. Test-time compute ở đây chuyển sang vai trò chọn phong cách, không phải chọn sự thật.

11. Hướng đi 2026-2027

Cuối năm 2025 và đầu 2026 chứng kiến một làn sóng nghiên cứu mới, mở ra những hướng đi đầy tiềm năng:

• Latent reasoning: Thay vì sinh chuỗi suy luận ở tầng token, model suy luận trực tiếp trong không gian ẩn (hidden state) qua các bước recurrent depth. Giảm mạnh chi phí decode trong khi giữ được khả năng suy luận sâu. Các kiến trúc như "recurrent depth" và "parallel latent reasoning" đã đạt hiệu năng ấn tượng trên các benchmark reasoning hard.
• Training-time mô phỏng test-time: Huấn luyện model sao cho hành vi của nó ở test-time compute cao được "nội hóa" một phần vào weights, giảm được chi phí search tại inference. Đây là một dạng distillation từ chính test-time behavior.
• Compute-aware routing liên model: Một router không chỉ chọn chiến lược TTS mà còn chọn model. Request siêu dễ đi Haiku/Mini, request khó đi Sonnet, request cực khó đi Opus với budget forcing. Ranh giới giữa "chọn TTS" và "chọn model" sẽ mờ dần trong hai năm tới.
• Verifier phổ quát: Các PRM/ORM đang tiến hóa từ domain-specific (chỉ toán, chỉ code) sang general-purpose. Một verifier tốt có thể trở thành "critic universal" cho nhiều loại task — đây sẽ là bước ngoặt lớn cho multi-agent.

12. Tổng kết

Test-time compute scaling không đơn thuần là "cho model suy nghĩ lâu hơn". Nó là một dịch chuyển kiến trúc cơ bản: chi phí trí tuệ của AI đang chuyển từ tầng pretraining sang tầng inference, và kéo theo đó là sự thay đổi trong mọi thiết kế hệ thống — từ GPU scheduler, tầng cache, đến observability và FinOps. Kỹ sư 2026 không thể chỉ hỏi "model nào mạnh nhất?", mà phải hỏi "với ngân sách compute X, chiến lược TTS nào là tối ưu cho phân phối prompt của tôi?".

Các kỹ thuật cốt lõi — Chain-of-Thought, Self-Consistency, Tree-of-Thoughts, Best-of-N, PRM, compute-optimal allocation — đều đã được chứng minh trong nghiên cứu và đang được triển khai ở quy mô lớn. Điểm khác biệt giữa một hệ thống production tốt và một hệ thống trung bình không nằm ở việc nó biết bao nhiêu kỹ thuật, mà ở chỗ nó chọn đúng kỹ thuật cho đúng prompt, ở đúng thời điểm. Và để làm được điều đó, Redis + ClickHouse không phải là lựa chọn hạ tầng — chúng là bộ não đo lường và ghi nhớ của chính hệ thống reasoning.

Nguồn tham khảo

• Snell et al., Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Model Parameters, DeepMind, 2024 — arxiv.org/abs/2408.03314
• OpenAI, Learning to Reason with LLMs (o1 technical report), 2024 — openai.com/index/learning-to-reason-with-llms
• DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025 — arxiv.org/abs/2501.12948
• Muennighoff et al., s1: Simple test-time scaling, Stanford, 2025 — arxiv.org/abs/2501.19393
• Anthropic, Claude 3.7 Sonnet and Claude Code (extended thinking), 2025 — anthropic.com/news/claude-3-7-sonnet
• Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, Google, 2022 — arxiv.org/abs/2203.11171
• Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, 2023 — arxiv.org/abs/2305.10601
• Lightman et al., Let's Verify Step by Step (Process Reward Models), OpenAI, 2023 — arxiv.org/abs/2305.20050
• A Survey on Test-Time Scaling in Large Language Models, 2025 — testtimescaling.github.io
• Awesome Inference-Time Scaling (paper list) — github.com/ThreeSR/Awesome-Inference-Time-Scaling