Chọn model Claude nào? Cách cân bằng năng lực, tốc độ và chi phí

TL;DR

• Không có một model Claude tốt nhất cho mọi workload. Hãy chọn theo độ khó của tác vụ, latency, chi phí mỗi tác vụ và quyền truy cập.
• Khuyến nghị mặc định của Anthropic là bắt đầu với model thông minh nhất đang được cung cấp rộng rãi, sau đó điều chỉnh effort level để tìm điểm cân bằng.
• Mythos/Fable và Opus phù hợp với suy luận sâu, coding khó và agent chạy dài. Sonnet là lựa chọn cân bằng cho phần lớn tác vụ tổng quát. Haiku ưu tiên tốc độ và chi phí.
• Đừng quyết định chỉ bằng benchmark. Custom evaluation từ các ca production khó mới cho biết model nào thực sự vượt quality bar của bạn.

Bài viết này được biên soạn từ hướng dẫn chọn model của Anthropic, kiểm tra lại các thông tin về Sonnet 5, Sonnet 4.6 và Haiku 4.5 vào ngày 27/07/2026. via Claude by Anthropic

Bắt đầu từ quality bar, không phải từ bảng giá

Câu hỏi về model mạnh nhất thường là điểm bắt đầu sai. Câu hỏi hữu ích hơn là: model nào hoàn thành được tác vụ này một cách ổn định, trong giới hạn latency và ngân sách của tôi?

Anthropic đưa ra một khuyến nghị có vẻ ngược trực giác: hãy bắt đầu với model thông minh nhất đang có sẵn, sau đó giảm effort hoặc thử lớp model thấp hơn khi đã hiểu quality bar. Model mạnh hơn có thể có giá mỗi token cao hơn, nhưng đôi khi lại rẻ hơn trên mỗi tác vụ hoàn thành vì cần ít lượt gọi, ít vòng sửa và ít thời gian suy luận hơn. Nếu bắt đầu bằng model nhỏ, bạn cũng khó biết lỗi đến từ model hay từ prompt, tool và workflow chưa đủ tốt.

Điều này không có nghĩa là lúc nào cũng dùng model lớn nhất. Với sản phẩm cần phản hồi trong thời gian thực hoặc chạy hàng triệu lượt mỗi ngày, latency và unit economics có thể quan trọng hơn vài điểm chất lượng. Khi đó, hãy dùng kết quả đo để đi xuống từng lớp cho tới khi chất lượng vừa đủ.

Bốn lớp model Claude và vai trò của từng lớp

Các lớp model của Claude không được chia theo kiểu model cho tài chính hay model cho khoa học. Mọi lớp đều hướng tới coding, agentic task và knowledge work. Khác biệt nằm ở độ khó mà model có thể xử lý ổn định, cùng cái giá phải trả về tốc độ và chi phí.

Trong thực tế, ranh giới giữa các lớp đang dịch chuyển nhanh. Sonnet 4.6 có context window 1M token ở chế độ beta và được Anthropic định vị là bước tiến lớn cho coding, computer use, long-context reasoning và agent planning. Sonnet 5 tiếp tục thu hẹp khoảng cách với Opus, trong khi Haiku 4.5 nhắm tới những workload cần tốc độ cao mà vẫn giữ năng lực gần frontier.

Vì vậy, bảng trên nên được xem là điểm xuất phát, không phải luật cứng. Model cụ thể, giá và khả năng truy cập có thể thay đổi theo thời điểm và nền tảng.

Chọn theo độ khó, latency và unit economics

Trước khi chọn model, hãy trả lời bốn câu hỏi:

1. Tác vụ khó đến đâu? Nếu cần nhiều bước, kéo dài, chứa nhiều điều kiện hoặc trước đây hệ thống thường thất bại, hãy bắt đầu ở lớp cao hơn.
2. Latency có phải ràng buộc chính không? Chat trực tiếp, chăm sóc khách hàng và vòng lặp tương tác thường có lợi từ Sonnet hoặc Haiku.
3. Chi phí cần tối ưu ở cấp token hay cấp tác vụ? Đừng chỉ nhìn giá input/output. Hãy tính cả số lượt gọi, số vòng retry, thời gian chạy và tỷ lệ hoàn thành.
4. Bạn được phép dùng lớp nào? Quyền truy cập, data retention và yêu cầu an toàn có thể loại một số lựa chọn trước cả khi benchmark bắt đầu.

Một bài toán đơn giản có thể không hưởng lợi từ model lớn hơn. Khi cả model nhỏ và model lớn đều vượt quality bar ngay từ vài lượt suy luận đầu tiên, token bổ sung chủ yếu mua thêm double-check chứ không tạo ra chất lượng mới. Ngược lại, với bài toán khó, model mạnh hơn có thể đạt cùng chất lượng với ít token hơn ở effort phù hợp.

Kết hợp model bằng advisor strategy

Thay vì chọn một model duy nhất cho toàn bộ pipeline, bạn có thể để model worker nhanh và rẻ thực thi phần lớn công việc, rồi gọi model thông minh hơn khi cần lập kế hoạch, kiểm tra hoặc đánh giá đầu ra. Đây là advisor strategy.

Cách phối hợp này phù hợp với agent workflow nhiều bước. Worker giữ throughput và chi phí thấp; advisor xử lý những điểm có rủi ro cao như phân rã yêu cầu, kiểm tra điều kiện biên, review code hoặc xác nhận kết quả trước khi gửi cho người dùng.

Bài nguồn đưa ra một ví dụ đáng chú ý: Sonnet 5 dùng Fable 5 làm advisor đạt kết quả trong vòng 10% so với việc dùng Fable 5 cho toàn bộ tác vụ, nhưng chỉ bằng 63% chi phí. Đây là con số định hướng từ evaluation cụ thể, không phải cam kết cho mọi workload. Giá trị thật của chiến lược nằm ở việc bạn biết chính xác bước nào cần năng lực frontier và bước nào chỉ cần một worker ổn định.

Xây custom evaluation trước khi đổi model

Benchmark công khai hữu ích để định hướng, nhưng không đủ để quyết định một hệ thống production. Khi các model mạnh đều giải được gần hết bộ câu hỏi, benchmark bị bão hòa và không còn phân biệt được lựa chọn nào tốt hơn cho tình huống của bạn.

Custom evaluation nên bắt đầu từ những ca thật: ticket khó, pull request từng thất bại, tài liệu dài, truy vấn nhiều bước hoặc tình huống người dùng thường phải sửa lại đầu ra. Mỗi ca cần có tiêu chí thành công rõ ràng, chẳng hạn độ chính xác trích xuất, tỷ lệ hoàn thành, số lượt tool call, latency, chi phí và mức độ cần người can thiệp.

Quy trình tối thiểu có thể là:

• Thu thập một tập ca đại diện cho workload thật, bao gồm cả ca thành công và thất bại.
• Viết task rõ ràng, tách tiêu chí pass/fail khỏi cảm nhận chủ quan.
• Chạy cùng một tập qua vài model và effort level khác nhau.
• Đo chất lượng cùng cost-per-task, latency và tỷ lệ retry.
• Duy trì bộ evaluation theo thời gian để phát hiện model hoặc workload đã thay đổi.

Giá và khả năng tiếp cận: chỉ là một lát cắt

Tại thời điểm kiểm tra, Claude Sonnet 5 có giá giới thiệu $2 cho mỗi triệu token input và $10 cho mỗi triệu token output đến hết ngày 31/08/2026, sau đó chuyển sang $3/$15. Sonnet 4.6 bắt đầu từ $3/$15, còn Haiku 4.5 được công bố ở mức $1/$5. Đây là các mức giá tham khảo theo công bố chính thức, không phải dữ liệu cố định; hãy kiểm tra trang pricing của Claude trước khi lập ngân sách.

Ngoài giá token, hãy tính chi phí vận hành thật: số vòng lặp agent, thời gian chờ, tool call, retry, kiểm duyệt và phần việc con người phải làm sau khi model trả lời. Một model rẻ nhưng khiến đội ngũ phải sửa nhiều có thể đắt hơn một model mạnh hoàn thành ngay từ đầu.

Kết

Chọn model Claude không phải là cuộc thi tìm một cái tên duy nhất đứng đầu bảng. Quyết định tốt là quyết định gắn với quality bar, workload và dữ liệu đo được. Hãy bắt đầu với model đủ mạnh để phân biệt lỗi của model với lỗi của hệ thống, điều chỉnh effort level, rồi dùng evaluation thật để tối ưu dần về tốc độ và chi phí.

Nếu workload có nhiều loại tác vụ, hãy nghĩ theo portfolio: Opus hoặc Fable cho phần khó, Sonnet cho worker tổng quát, Haiku cho throughput, và advisor strategy để nối các lớp lại với nhau. Khi model và giá tiếp tục thay đổi, lợi thế bền vững không nằm ở việc nhớ tên model mới nhất, mà ở việc sở hữu một quy trình evaluation đủ tốt để biết lúc nào nên đổi.

via Claude by Anthropic và via Anthropic.