Công cụ lý luận (reasoning engine) Claude Fable 5 mới của Anthropic luôn bật tính năng tư duy sâu cho mọi yêu cầu và thay vào đó cho phép các nhà phát triển tăng hoặc giảm độ sâu lý luận. Trước đây, các Mô hình Ngôn ngữ Lớn (LLM) hoạt động dựa trên các tham số tính toán cố định, tạo ra các token với tốc độ đồng đều bất kể độ phức tạp của truy vấn. Một lời chào đơn giản cũng tiêu tốn năng lượng xử lý tương đương như một chứng minh toán học nâng cao. Với Fable 5, Anthropic giới thiệu một framework lý luận hỗn hợp (hybrid reasoning), trong đó tư duy luôn hoạt động và bạn kiểm soát mức độ làm việc của mô hình thông qua một thiết lập effort duy nhất. Hướng dẫn này phác thảo cách thức hoạt động của API, cách chọn mức effort và cách triển khai kiến trúc này trong các luồng xử lý production.
[!WARNING] Cảnh báo giới hạn API: Tư duy luôn được bật đối với Fable 5, vì vậy bạn không thể tắt nó. Việc truyền
thinking: {type: "enabled"}hoặcthinking: {type: "disabled"}, hay cung cấp một giá trịbudget_tokens, sẽ trả về lỗi HTTP 400 — các tham số đó đã bị loại bỏ. Thay vào đó, hãy kiểm soát độ sâu lý luận bằngoutput_config: {effort: "..."}, và hãy để lại đủmax_tokenscho câu trả lời cuối cùng ở các mức effort cao hơn.Các điểm chính cần lưu ý:
- Điều chỉnh Effort, không phải công tắc bật/tắt: Đặt
output_config.effortthànhlow,medium,high,xhighhoặcmax— không có công tắc bật/tắt nào cả.- Tư duy diễn ra tự động: Bỏ qua
thinkinghoặc truyền{type: "adaptive"}; tư duy thích ứng (adaptive) chạy trên mọi yêu cầu.- Phân tích luồng (stream): Xử lý các khối nội dung
thinkingvới các deltathinking_deltatrong các stream máy chủ thời gian thực.- Quản lý chi phí: Lưu bộ nhớ đệm (caching) các prompt hệ thống giúp giảm các chu kỳ xử lý tư duy dư thừa.
Giải thích công cụ lý luận hỗn hợp của Claude
Cải tiến cốt lõi của Fable 5 là khả năng tư duy thấu đáo một vấn đề trước khi đưa ra câu trả lời cuối cùng. Điều này có nghĩa là mô hình sẽ xử lý một bản nháp logic của giải pháp ở bên trong trước khi phản hồi các yêu cầu từ client. Quan trọng hơn, giai đoạn tư duy này luôn được bật — bạn không thể tắt nó, và không có “chế độ tốc độ” riêng biệt nào để bạn chuyển sang.
Khi bạn gửi một câu hỏi phức tạp, mô hình không cố gắng đoán từ tiếp theo ngay lập tức. Thay vào đó, nó tạo ra các token tư duy nội bộ, mô phỏng quá trình lý luận từng bước. Kiến trúc này cải thiện đáng kể độ chính xác cho toán học, lập trình và đánh giá logic.
Để hỗ trợ các yêu cầu doanh nghiệp khác nhau, Anthropic cho phép các nhà phát triển điều chỉnh độ sâu của quá trình tư duy đó theo nhu cầu thông qua một tùy chọn effort duy nhất. Ở mức effort thấp (low), mô hình tư duy ngắn gọn và trả lời nhanh, giữ cho độ trễ và mức tiêu thụ token ở mức thấp. Ở mức effort cao (high) hoặc tối đa (max), mô hình lý luận sâu hơn nhiều, sử dụng thêm tài nguyên tính toán cần thiết cho toán học khó, logic nhiều bước và mã nguồn phức tạp. Sự đánh đổi giữa tốc độ và độ sâu được thể hiện hoàn toàn qua mức effort này thay vì một công tắc bật/tắt.
Cấu hình các tham số API Fable 5
Để triển khai các khả năng này trong phần mềm của bạn, bạn phải sử dụng schema API Anthropic đã cập nhật. Schema này đảm bảo các ứng dụng client của bạn chỉ định đúng tên mô hình và các tham số thực thi.
Độ sâu lý luận được thiết lập thông qua một khối output_config. Bên trong khối này, trường effort nhận một trong các giá trị "low", "medium", "high", "xhigh" hoặc "max", và giá trị duy nhất đó thay thế cho nút điều chỉnh ngân sách token cũ. Trong trường hợp đơn giản, bạn hoàn toàn không truyền khối thinking — tư duy thích ứng chạy tự động. Đoạn mã tích hợp JavaScript bên dưới trình bày cách cấu trúc yêu cầu này:
1import Anthropic from "@anthropic-ai/sdk";
2
3export default {
4 async fetch(request, env) {
5 const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
6
7 try {
8 const response = await anthropic.messages.create({
9 model: "claude-fable-5",
10 max_tokens: 8192,
11 // Thinking is always on for Fable 5; dial reasoning depth with effort:
12 output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13 messages: [
14 {
15 role: "user",
16 content: "Generate an optimised database migration script for 10 million records."
17 }
18 ]
19 });
20
21 return Response.json(response);
22 } catch (err) {
23 return Response.json({ error: err.message }, { status: 500 });
24 }
25 }
26};
Đừng cố gắng tắt tư duy hoặc truyền một giá trị budget_tokens: thinking: {type: "disabled"}, thinking: {type: "enabled"} và bất kỳ trường budget_tokens nào đều trả về lỗi HTTP 400 trên Fable 5, bởi vì các tham số đó đã bị loại bỏ trên mô hình này (cũng như trên Opus 4.7 và 4.8). Hãy chọn mức effort thấp hơn để tăng tốc độ và mức cao hơn để tăng độ sâu, và hãy chừa đủ dung lượng trong max_tokens cho câu trả lời cuối cùng khi bạn tăng effort lên. Để biết thêm chi tiết về kiến trúc serverless, hãy đọc hướng dẫn của chúng tôi về xây dựng API serverless với Cloudflare Workers
.
Xử lý các Token lý luận trong luồng Stream
Đối với các ứng dụng thời gian thực như giao diện chat, việc truyền phát (streaming) phản hồi là rất cần thiết. Fable 5 xuất ra cả các bước tư duy và nội dung cuối cùng thông qua các kênh SSE (Server-Sent Events).
Trong một stream, tư duy đến dưới dạng các khối nội dung thinking, được gửi qua các sự kiện content_block_delta có delta.type là "thinking_delta". Hãy đọc văn bản từ delta.thinking, và đọc câu trả lời cuối cùng từ các delta text_delta thông thường. Chuỗi suy luận thô (chain-of-thought) không bao giờ được trả về — để nhận được một bản tóm tắt dễ đọc, bạn phải chủ động chọn tham gia bằng thinking: {type: "adaptive", display: "summarized"}; giá trị mặc định "omitted" sẽ truyền phát văn bản tư duy trống. Một handler tối giản trông như thế này:
1const stream = await anthropic.messages.stream({
2 model: "claude-fable-5",
3 max_tokens: 8192,
4 output_config: { effort: "high" },
5 thinking: { type: "adaptive", display: "summarized" },
6 messages: [{ role: "user", content: prompt }]
7});
8
9for await (const event of stream) {
10 if (event.type === "content_block_delta") {
11 if (event.delta.type === "thinking_delta") {
12 process.stdout.write(event.delta.thinking); // summarised reasoning
13 } else if (event.delta.type === "text_delta") {
14 process.stdout.write(event.delta.text); // final answer
15 }
16 }
17}
Bạn có thể chuyển các đoạn thinking_delta đó vào một bảng “Thinking…” có thể thu gọn, hoặc bỏ chúng đi và chỉ hiển thị câu trả lời. Để xem tài liệu tham khảo chi tiết về tích hợp Anthropic, hãy truy cập trực tiếp vào Anthropic Developer Documentation
.
Hãy quản lý việc tính toán token của bạn một cách cẩn thận. Các token tư duy được tính vào hóa đơn API đầu ra của bạn. Do đó, hãy triển khai prompt caching mạnh mẽ để tránh chạy lại các chu kỳ lý luận trên các đầu vào giống hệt nhau. Khi lập kế hoạch triển khai production, việc theo dõi các chỉ số này thông qua một lớp đo lường từ xa ở biên (edge telemetry) giúp bạn xác định nơi việc sử dụng token tư duy vượt quá các tham số thông thường.
Quy trình tích hợp API từng bước
Để triển khai công cụ lý luận bên trong ứng dụng của bạn, hãy bắt đầu bằng cách cập nhật các gói thư viện cục bộ để phù hợp với các thông số kỹ thuật của Fable 5. Các phiên bản SDK cũ vẫn gửi budget_tokens, điều này giờ đây gây ra lỗi schema HTTP 400 trong quá trình tuần tự hóa API.
Tiếp theo, hãy xác định các ngưỡng độ trễ rõ ràng. Đối với các luồng đàm thoại đơn giản hoặc lời chào, hãy đặt mức effort thấp (low) để giảm độ trễ. Dành riêng mức effort cao (high) hoặc tối đa (max) cho các tác vụ như tạo mã nguồn hoặc toán học.
Ngoài ra, hãy lưu trữ an toàn các thông tin xác thực API của bạn bên trong các tham số môi trường serverless bằng cách sử dụng các công cụ như Wrangler. Khi xử lý các sự kiện đầu ra của luồng stream, hãy viết các handler frontend mạnh mẽ để lọc bỏ các gói tin thinking_delta, trừ khi bạn muốn hiển thị trực tiếp các bước lý luận của mô hình. Cuối cùng, hãy kiểm tra tỷ lệ hit của prompt cache để xác nhận việc lưu vào bộ nhớ đệm giúp giảm thiểu chi phí tiêu thụ token dư thừa. Để tìm hiểu về thiết kế biên API, hãy khám phá hướng dẫn Cloudflare Workers AI
của chúng tôi.
So sánh nhanh: Effort thấp vs. Effort cao
Việc lựa chọn mức effort là sự đánh đổi giữa độ trễ, chi phí và chất lượng câu trả lời. Bảng dưới đây so sánh các khía cạnh quan trọng nhất khi bạn ước tính quy mô của một yêu cầu. Các số liệu về độ trễ và thông lượng mang tính chất minh họa và sẽ thay đổi tùy theo độ dài prompt, tải và khu vực địa lý, nhưng mối quan hệ giữa chúng vẫn được duy trì.
| Khía cạnh | Effort thấp (low) | Effort cao (high) |
|---|---|---|
| Thời gian đến token đầu tiên | Dưới một giây (minh họa) | Tăng dần khi mô hình tư duy nhiều hơn |
| Chi phí cho mỗi yêu cầu | Ít token tư duy hơn, nên chi phí thấp hơn | Nhiều token tư duy hơn, được tính theo giá đầu ra |
| Độ chính xác cho tác vụ khó | Cơ bản | Cao hơn rõ rệt đối với toán học, logic nhiều bước và lập trình |
| Khả năng dự đoán token | Chặt chẽ và dễ dự báo hơn | Thay đổi, và lớn hơn với các prompt khó |
| Khối lượng công việc phù hợp nhất | Chat, phân loại, định dạng truy xuất | Debug, chứng minh, lập kế hoạch, tạo nội dung phức tạp |
| Cấu hình | output_config.effort = "low" | output_config.effort = "high" hoặc "max" |
Điểm mấu chốt là các token tư duy là các token đầu ra thực tế. Một yêu cầu ở mức effort thấp tư duy ngắn gọn và chủ yếu tính phí cho câu trả lời mà nó viết ra; một yêu cầu ở mức effort cao hoặc tối đa có thể tạo ra một lượng lớn token tư duy trước khi từ đầu tiên của câu trả lời xuất hiện. Tư duy không bao giờ bị tắt — bạn chỉ đang chọn mức độ tư duy để chi tiêu.
Khi nào nên sử dụng mỗi mức Effort
Một cách tiếp cận thực tế là ánh xạ từng loại tác vụ vào một mức effort mặc định, sau đó chỉ ghi đè khi một yêu cầu cụ thể rõ ràng cần nhiều không gian xử lý hơn. Hãy dành riêng mức effort cao và tối đa cho các vấn đề mà một câu trả lời sai sẽ tốn nhiều chi phí để phát hiện ở các bước sau.
| Loại tác vụ | Mức effort khuyến nghị |
|---|---|
| Lời chào, FAQ và trò chuyện ngắn | low |
| Phân loại mục đích và điều hướng | low |
| Tóm tắt tài liệu ngắn | low |
| Trích xuất dữ liệu có cấu trúc | low hoặc medium |
| Tạo mã nguồn nhiều tệp | high |
| Lý luận tài chính hoặc toán học | high hoặc xhigh |
| Debug phân tích nguyên nhân gốc rễ | xhigh hoặc max |
Chọn mức effort thấp khi phản hồi ngắn và phần lớn mang tính xác định, khi thời gian đến token đầu tiên quyết định trải nghiệm người dùng (live chat, tự động hoàn thành, trợ lý biểu mẫu), hoặc khi bạn đang chạy một khối lượng công việc lớn, biên lợi nhuận thấp, nơi mỗi token đầu ra bổ sung sẽ nhân lên trên hàng triệu lượt gọi.
Chọn mức effort cao hoặc tối đa khi một câu trả lời sai duy nhất sẽ mang lại chi phí thực tế — một đoạn mã di chuyển dữ liệu bị lỗi, một báo giá tính toán sai, một đường dẫn mã không an toàn — hoặc khi tác vụ liên quan đến nhiều bước phụ thuộc lẫn nhau mà mô hình phải liên kết lại với nhau. Đây là những công việc mà một vài giây độ trễ bổ sung sẽ mang lại sự gia tăng đáng kể về độ tin cậy.
Ví dụ thực tế: Đánh đổi giữa độ trễ và chi phí
Hãy xem xét một trợ lý hỗ trợ xử lý 50.000 yêu cầu mỗi ngày. Giả định rằng mỗi câu trả lời cuối cùng khoảng 250 token, rằng mức effort thấp (low) chỉ thêm một số ít token tư duy, và mức effort cao (high) tiêu tốn khoảng 1.500 token tư duy cho một truy vấn khó điển hình. Mỗi mức giá token dưới đây mang tính chất minh họa — hãy coi nó như một bài tập mô hình hóa hơn là một báo giá thực tế — và giả định mức giá đầu ra là 15 USD trên mỗi triệu token.
Việc chạy mọi yêu cầu ở mức effort thấp sẽ tạo ra khoảng 50.000 × 250 = 12,5 triệu token đầu ra mỗi ngày, tương đương khoảng 188 USD mỗi ngày theo mức giá minh họa. Ngược lại, việc chạy mọi yêu cầu ở mức effort cao sẽ tính phí 50.000 × (1.500 + 250) = 87,5 triệu token mỗi ngày, khoảng 1.313 USD mỗi ngày — gấp bảy lần, hầu hết chi phí dành cho việc lý luận qua các truy vấn vốn không bao giờ cần đến độ sâu bổ sung.
Bây giờ hãy điều hướng có chọn lọc. Giả sử một bộ phân loại effort thấp giá rẻ quyết định rằng chỉ có 15% lưu lượng truy cập thực sự phức tạp. Gửi 7.500 yêu cầu đến mức effort cao và 42.500 yêu cầu đến mức effort thấp sẽ tạo ra 13,1 triệu + 10,6 triệu ≈ 23,7 triệu token mỗi ngày, tương đương khoảng 356 USD mỗi ngày — tiết kiệm ~73% so với việc chạy mọi thứ ở mức effort cao, trong khi vẫn áp dụng lý luận sâu ở những nơi mang lại giá trị.
Bức tranh về độ trễ cũng tương tự. Ở mức effort thấp, token đầu tiên thường xuất hiện trong vòng chưa đầy một giây. Ở mức effort cao, mô hình tạo ra một bản nháp lý luận lớn hơn nhiều trước khi câu trả lời bắt đầu, vì vậy một bản nháp nội bộ 1.500 token với tốc độ minh họa 60 token mỗi giây sẽ làm chậm phản hồi hiển thị khoảng 25 giây. Việc stream các khối thinking_delta vào một bảng “Thinking…” có thể thu gọn là yếu tố giúp người dùng cuối chấp nhận được sự chờ đợi đó.
Di chuyển và Tổng chi phí sở hữu (TCO)
Nếu bạn đang chuyển đổi từ một mô hình tính toán cố định, thay đổi lớn nhất là độ sâu lý luận giờ đây là một nút điều chỉnh bạn thiết lập cho mỗi yêu cầu thay vì một mức giá cố định bạn trả cho mỗi cuộc gọi. Đòn bẩy lớn nhất trên hóa đơn của bạn không phải là mức effort của bất kỳ cuộc gọi đơn lẻ nào mà là lớp điều hướng (routing layer) quyết định yêu cầu nào thực sự xứng đáng với mức effort cao. Một lượt gọi phân loại effort thấp nhẹ nhàng — vài trăm token — làm cổng chặn cho lượt gọi effort cao đắt tiền hầu như luôn mang lại hiệu quả kinh tế.
Hai thói quen giúp tổng chi phí sở hữu luôn có thể dự đoán được. Đầu tiên, hãy đặt mức effort thấp nhất có thể giải quyết đáng tin cậy từng loại tác vụ thay vì một giá trị mặc định toàn cục quá hào phóng; một mức effort max áp dụng ở mọi nơi là nguồn gốc phổ biến nhất của các hóa đơn bất ngờ. Thứ hai, hãy cache các prompt hệ thống ổn định để ngữ cảnh lặp lại không bị tính phí lại trên mỗi chu kỳ lý luận. Cùng với nhau, điều hướng theo yêu cầu và prompt caching sẽ đẩy phần lớn chi phí vào số ít các yêu cầu thực sự hưởng lợi từ nó.
Các điểm mấu chốt cần nhớ
- Fable 5 (
claude-fable-5, ngữ cảnh 1 triệu token, đầu ra tối đa 128K) luôn bật tư duy; bạn điều chỉnh độ sâu của nó thay vì bật/tắt. - Cấu hình độ sâu lý luận bằng
output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"};budget_tokensvàthinking.type“enabled”/“disabled” giờ đây trả về lỗi HTTP 400. - Stream tư duy qua các khối nội dung
thinking(các deltathinking_delta) để hiển thị các bước của mô hình cho người dùng cuối, chủ động chọn tham gia bằngthinking: {type: "adaptive", display: "summarized"}để nhận một bản tóm tắt dễ đọc. - Kiểm soát chi phí hóa đơn API bằng cách chọn mức effort thấp nhất có thể dùng được và lưu cache các prompt thường xuyên sử dụng.
- Triển khai middleware API của bạn trên các mạng biên serverless để giảm độ trễ truyền tải dữ liệu.
Câu hỏi thường gặp (FAQ)
Lý luận Claude Fable 5 là gì?
Lý luận Claude Fable 5 là một khả năng luôn được bật, trong đó mô hình tạo ra các token tư duy nội bộ để giải quyết các vấn đề logic phức tạp trước khi đưa ra phản hồi cuối cùng. Thay vì cố gắng đoán từ tiếp theo ngay lập tức, mạng lưới mô phỏng một quá trình tư duy từng bước để giải quyết các lỗi cấu trúc, toán học và lập trình, và bạn điều chỉnh độ sâu tư duy của nó bằng thiết lập effort.
Làm cách nào để cấu hình mức effort lý luận trong API?
Bạn cấu hình độ sâu lý luận bằng cách truyền output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" } bên trong payload yêu cầu API. Mức effort thấp hơn tư duy ngắn gọn và trả lời nhanh hơn với ít token hơn, trong khi mức cao hơn lý luận sâu hơn. Tham số budget_tokens cũ đã bị loại bỏ và giờ đây trả về lỗi HTTP 400 trên Fable 5.
Các token lý luận có được tính phí khác đi không? Không, các token lý luận được tính phí theo mức giá token đầu ra tiêu chuẩn của mô hình. Bởi vì các token này đại diện cho tính toán đầu ra, chúng được tính trực tiếp vào hóa đơn API của bạn, khiến việc lưu prompt vào bộ nhớ đệm và chọn một mức effort hợp lý trở nên cần thiết để kiểm soát chi phí phần mềm.
Làm cách nào để khiến Fable 5 phản hồi nhanh hơn?
Bạn không thể tắt lý luận — tư duy luôn được bật đối với Fable 5, và việc truyền thinking: {type: "disabled"} sẽ trả về lỗi HTTP 400. Để giảm độ trễ, hãy hạ mức effort xuống bằng output_config: { effort: "low" }, điều này rút ngắn giai đoạn tư duy và giảm thiểu thời gian đến token đầu tiên cho các tác vụ đàm thoại cơ bản.
Làm cách nào để phân tích cú pháp các token lý luận từ một luồng SSE trong thời gian thực?
Trong quá trình truyền phát SSE serverless, tư duy đến dưới dạng các khối nội dung thinking thông qua các sự kiện content_block_delta có delta.type là thinking_delta; hãy đọc văn bản từ delta.thinking, tách biệt với đầu ra text_delta tiêu chuẩn. Hãy chủ động chọn tham gia bằng thinking: {type: "adaptive", display: "summarized"} để nhận một bản tóm tắt dễ đọc, sau đó hiển thị hoặc loại bỏ các token đó dựa trên tùy chọn giao diện người dùng frontend.
Bình luận