Dùng model hiệu quả: khi nào cần Fable, Opus, Sonnet hay Haiku

Có một phản xạ đáng để kìm lại: cứ chọn model to nhất trong mọi lần. Nghe thì an toàn — nếu model mạnh nhất là model thông minh nhất, thì dùng cái khác làm gì? Nhưng "mạnh nhất" và "hợp với việc này" không phải là một. Phần lớn việc tôi làm trong một ngày không cần tới đỉnh của dải model, và cứ dùng đỉnh thì tôi mất tốc độ, đốt giới hạn sử dụng nhanh hơn, và đôi khi còn khiến câu trả lời tệ hơn. Bài này nói về việc chọn model hợp với công việc.

Vấn đề: model mạnh nhất không miễn phí

Giả sử dải model hiện tại chạy từ một model nhẹ cho tới model mạnh nhất. Bản năng là ghim mọi thứ lên đỉnh. Đây là những gì bản năng đó bỏ qua:

• Nó chậm hơn. Các model to hơn — và mức "effort" cao hơn — suy nghĩ lâu hơn trước khi trả lời. Với model nặng nhất ở mức effort cao, một tác vụ khó có thể chạy vài phút. Đó là đánh đổi hợp lý cho một cuộc refactor hóc búa; nhưng là đánh đổi tệ cho việc "đổi tên biến này."
• Nó đốt giới hạn của bạn nhanh hơn. Trên gói đăng ký, bạn có một hạn mức sử dụng cuốn chiếu (xem bài trước về status line). Model càng nặng, bạn càng ăn hết hạn mức đó nhanh. Tiêu nó vào những chỉnh sửa vặt và bạn sẽ đâm vào tường đúng lúc cần model to cho việc khó.
• Nó tốn kém hơn. Trên API, khoảng cách giá giữa các tầng là gấp mấy lần trên mỗi token. Kể cả trên một gói mà bạn không thấy hóa đơn theo token, "chi phí" hiện ra ở chỗ hạn mức của bạn cạn nhanh đến đâu.
• Nó có thể nghĩ quá. Đây là điều bất ngờ. Với các tác vụ đơn giản, gọn phạm vi, các model mạnh nhất — nhất là ở effort cao — đôi khi khám phá nhiều hơn mức việc cần: thêm abstraction, dọn dẹp không ai yêu cầu, cân nhắc dài dòng cho một thay đổi một dòng. Một model nhỏ hơn, hoặc một mức effort thấp hơn, chỉ việc làm xong.

Nên mục tiêu không phải là "luôn mạnh nhất". Mà là khớp model với công việc — đủ lớn để làm được, không lớn hơn.

Dải model, nói cho dễ hiểu

Tên và tầng model thay đổi theo thời gian, nhưng chúng chia thành bốn vai trò đại khái. Hôm nay đó là Haiku, Sonnet, Opus, và Fable — từ nhẹ tới nặng.

Một cách đọc bảng này cho hữu ích: Sonnet là lựa chọn mặc định thành thật cho coding. Nó tiến sát tầng đỉnh ở hầu hết việc thật trong khi chỉ tốn một phần chi phí. Vươn lên Opus hay Fable khi một việc thật sự khó hoặc chạy dài, và vươn xuống Haiku khi việc thật sự đơn giản. Các cực dành cho các trường hợp cực đoan.

Nếu bạn muốn biết độ chênh thực tế, đây là giá niêm yết trên API cho mỗi triệu token (đầu vào / đầu ra). Kể cả khi bạn dùng gói và không bao giờ thấy hóa đơn này, các tỉ lệ cho thấy mỗi bậc nặng thêm bao nhiêu:

Token đầu ra từ model nặng nhất tốn gấp mười lần model nhẹ nhất. Đó là cái giá của việc dùng nó cho thứ mà một model nhẹ hơn đã làm được.

Núm vặn thứ hai: effort

Chọn model không phải là đòn bẩy duy nhất. Hầu hết model hiện tại cũng nhận một thiết lập effort — model làm việc chăm đến đâu trước khi trả lời. Nó chạy từ low qua medium, high, xhigh, tới max. Effort cao hơn nghĩa là nghĩ nhiều hơn, kỹ hơn, nhiều token hơn, và lâu hơn; effort thấp hơn nghĩa là câu trả lời nhanh hơn, ngắn gọn hơn, thẳng vào việc hơn.

Điều này quan trọng vì effort và model là hai núm độc lập. Bạn không phải nhảy lên model to hơn để có thêm chiều sâu — đôi khi cùng một model ở effort cao hơn là nước đi tốt hơn. Và thường thì cái lợi lại nằm ở hướng ngược lại:

• low — việc đơn giản và subagent. Ít lời gọi tool hơn, gộp hơn, ít mở đầu.
• high — điểm ngọt cho hầu hết việc thật. Chiều sâu tốt mà không tốn phi mã.
• xhigh — mức nên chọn cho các tác vụ coding và agentic khó nhất.
• max — khi tính đúng đắn quan trọng hơn chi phí hay tốc độ, và không gì kém hơn.

Một cách kết hợp thực dụng: giữ một model có năng lực nhưng hạ effort cho một loạt chỉnh sửa dễ, rồi nâng nó lên cho một bài toán khó trong phiên. Hai núm, chỉnh theo việc, thắng một núm ghim cứng ở đỉnh.

Trong Claude Code trông thế nào

Bạn không phải cam kết một model cho cả phiên. Trong Claude Code:

• /model đổi model đang dùng giữa phiên — nhẹ cho một đoạn việc đơn giản, nặng cho phần khó.
• Mức effort là một thiết lập bạn có thể nâng hoặc hạ; status line có thể hiển thị mức nào đang hoạt động (lại một lần nữa, xem bài về status line), để bạn luôn biết model đang làm việc chăm đến đâu.
• Một số tầng có fast mode đánh đổi một khoản phụ trội để lấy tốc độ đầu ra cao hơn khi độ trễ quan trọng hơn chi phí.

Điểm mấu chốt là những thứ này rẻ để thay đổi. Đổi model hay effort giữa phiên tốn của bạn một phím gõ, không phải một lần khởi động lại.

Một quy tắc để lấy dùng

• Mặc định dùng model cân bằng (Sonnet ở thời điểm này) cho coding. Nó sát đỉnh ở hầu hết tác vụ với một phần độ nặng.
• Vươn lên (Opus, rồi Fable) chỉ khi việc thật sự khó hoặc chạy dài — một cuộc di trú lớn, debug sâu, một lần chạy tự động qua đêm.
• Vươn xuống (Haiku) cho việc đơn giản, số lượng lớn, nhạy về độ trễ.
• Dùng effort như núm vặn thứ hai — high cho hầu hết việc, xhigh/max cho các bài toán khó, low cho việc dễ và cho subagent.
• Để mắt tới giới hạn sử dụng. Nếu bạn đang đốt hạn mức vào những chỉnh sửa vặt bằng model nặng nhất, đó là tín hiệu để bước xuống.

Model mạnh nhất là một công cụ, không phải một mặc định. Hãy để dành nó cho những bài toán thật sự cần, và mọi thứ còn lại sẽ nhanh hơn, rẻ hơn, và — đủ thường xuyên — tốt hơn.

Link tham khảo

Bài viết gốc (tiếng Anh): Model Efficiency: When to Use Fable, Opus, Sonnet, and Haiku