Làm sao để Fable rẻ hơn Opus: dùng ủy quyền để thay đổi cấu trúc chi phí của agent

Fable 像 một người quản lý cấp cao của một kỹ sư già dặn: giao việc sớm, viết rõ đặc tả, ít tự tay làm; Opus thì giống một người quản lý vi mô có tính giám sát sát sao đối với thực tập sinh. Bài viết này xuất phát từ bài của Joon Lee X, dùng 3.000 phiên đánh giá để mổ xẻ cấu trúc chi phí đằng sau.
（Tóm tắt trước đó: Anthropic ra mắt “Claude for Small Business”: nhắm tới tự động hóa các công việc bằng AI cho doanh nghiệp nhỏ và vừa, giúp bạn thúc đẩy hóa đơn, tính lương..）
（Bổ sung bối cảnh: Anthropic yêu cầu xác minh KYC định danh! Một số tính năng của Claude sẽ cần tải lên giấy tờ tùy thân, khiến áp lực tuân thủ tăng lên）

Mục lục

Toggle

• Giới thiệu
• Thiết lập thí nghiệm
• Chi phí của một agent
• Người quản lý vi mô với thực tập sinh vs người quản lý với kỹ sư già dặn
• Sau khi bàn giao
• Khi việc ủy nhiệm không giúp được gì
• Kết luận

Chúng tôi thay Opus 4.8 bằng Fable 5, còn hóa đơn của Devin lại giảm.

Chi phí của Fable 5 cho mỗi token bằng gấp đôi Opus 4.8. Nhưng khi chúng tôi chạy đồng thời hai mô hình này trên Fusion hoàn toàn mới tại FrontierCode 1.1, Fable lại rẻ hơn. Không bất ngờ, điểm số của nó cũng cao hơn. Bài viết này sẽ giải thích vì sao, và điều đó có ý nghĩa gì đối với việc định giá các công việc mang tính agentic.

Giới thiệu

Ai từng chạy một agent lập trình đều biết: mô hình mạnh hơn sẽ cho kết quả tốt hơn, nhưng bạn phải nuốt chi phí.

Khi chúng tôi ra mắt Devin Fusion, chúng tôi đã chỉ ra một lối đi: để một mô hình tiên phong đứng vai “đầu tàu”, để nó ủy nhiệm công việc cho một “cánh tay phải” rẻ hơn và nhanh hơn, nhờ đó bạn có thể đạt hiệu năng tầm tiên phong với chi phí thấp hơn 35%.

Nhưng một khi mô hình dẫn đầu ủy nhiệm phần lớn công việc đi hết, thì đơn giá mỗi token của nó vẫn sẽ thống trị toàn bộ hóa đơn chứ? Chi phí mỗi token của Fable 5 cao gấp đôi Opus 4.8, nên về lý thuyết, agent do Fable dẫn đầu phải đắt hơn. Để tìm ra câu trả lời, chúng tôi chạy 3.000 phiên đánh giá công việc trên FrontierCode 1.1, trải rộng qua bốn cấu hình: Fable và Opus lần lượt ngồi ở vị trí dẫn đầu, và mỗi bên lại chạy trong hai tình huống—khi có và khi không có cùng một mô hình phó rẻ.

Hiệu năng thuần túy (pure runs) đúng như trực giác: điểm của Fable thắng Opus (60,8 so với 55,4), còn chi phí cũng cao hơn. Mô hình tốt hơn, hóa đơn lớn hơn.

Phần thú vị bắt đầu khi có thêm cánh tay phải.

Trong điều kiện cùng một cánh tay phải, thứ tự chi phí đảo ngược: Fable + cánh tay phải rẻ hơn Opus + cánh tay phải ($1,86 so với $2,04), nhưng điểm vẫn cao hơn (60,7 so với 54,6). So với Fable thuần túy, Fable + cánh tay phải cắt giảm chi phí 54% trong khi điểm gần như không đổi.

| Cấu hình | | --- | Điểm | Chi phí mỗi lần chạy (trung bình) | | --- | --- | | Fable 5(low)+ cánh tay phải | 60,7 | $1,86 | | Opus 4.8(medium)+ cánh tay phải | 54,6 | $2,04 | | Fable 5(low) | 60,8 | $4,03 | | Opus 4.8(medium) | 55,4 | $3,06 |

Kết quả cho thấy: “mỗi token đắt gấp đôi” là một con số nhìn sai. Chi phí của một agent chủ yếu phụ thuộc vào việc mô hình dẫn đầu đã đi qua bao nhiêu vòng, kéo theo bao nhiêu ngữ cảnh cùng di chuyển, và quan trọng nhất—nó quyết định “không” tự làm những việc nào. Sự khác biệt quy về phong cách quản lý: Opus thể hiện như một người quản lý vi mô dẫn dắt thực tập sinh; Fable thì giống một người quản lý dẫn dắt với một kỹ sư giỏi.

Thiết lập thí nghiệm

Ôn nhanh về cách kiến trúc cánh tay phải của Fusion vận hành. Agent dẫn đầu sở hữu toàn bộ phiên làm việc: nó trò chuyện với người dùng, lập kế hoạch, rà soát công việc và gửi commit. Nó cũng có một agent cánh tay phải thường trực để ủy nhiệm nhiệm vụ. Mô hình dẫn đầu viết một bản “tóm tắt bàn giao” bằng ngôn ngữ đời thường; còn một agent con do một mô hình rẻ hơn nhiều điều khiển sẽ thực thi trong ngữ cảnh của chính nó và báo kết quả về. Mô hình dẫn đầu sẽ rà soát kết quả và quyết định bước tiếp theo.

Để xác định chi phí chảy đi đâu, chúng tôi làm hai việc. Thứ nhất, chúng tôi phân tích mọi cuộc gọi LLM trong toàn bộ 3.000 phiên làm việc: mô hình nào đang nói, nó gọi những công cụ nào, đọc/ghi bao nhiêu token và mỗi lần gọi tốn bao nhiêu tiền. Thứ hai, chúng tôi chọn 40 nhiệm vụ để quan sát sát hơn: nhóm mà Fable rõ ràng rẻ hơn, nhóm mà Opus rõ ràng rẻ hơn, và một lô mẫu ngẫu nhiên ở vùng “trung gian”. Với mỗi nhiệm vụ, chúng tôi phân tích song song việc chạy do Fable dẫn đầu và chạy do Opus dẫn đầu, xem xét đường đi nước bước của chúng, và quan sát tiền đã được chi ở đâu.

Chi phí của một agent

Dưới đây là cách chi phí được phân bổ giữa mô hình dẫn đầu và cánh tay phải trong thí nghiệm của chúng tôi:

| | | --- | Dẫn đầu $ | Cánh tay phải $ | Tổng chi phí mỗi lần chạy $ | Số vòng dẫn đầu mỗi lần chạy | Token input của dẫn đầu (tích lũy) | | --- | --- | --- | --- | --- | | Fable + cánh tay phải | $1,28 | $0,58 | $1,86 | 11,5 | 545k tok | | Opus + cánh tay phải | $1,73 | $0,31 | $2,04 | 26,5 | 1.679k tok |

Fable chi nhiều hơn cho cánh tay phải so với Opus—mỗi lần chạy tốn thêm $0,27. Nhưng Fable lại chi ít hơn $0,45 cho chính nó. Mỗi lần chạy, số vòng mà phần dẫn đầu của Fable đi là 11,5, so với 26,5 của Opus; số output token chỉ bằng khoảng một phần ba (6,1k so với 19,0k), và input token cũng chỉ bằng khoảng một phần ba. Token của Fable rõ ràng đắt hơn, nhưng nó lại thắng ở quản lý ngữ cảnh và số vòng.

Việc tiết kiệm token của Fable đến từ việc nó tránh làm công việc. Điều thú vị là, trong 81% các phiên do Fable dẫn đầu, mô hình dẫn đầu từ đầu đến cuối không hề thực hiện bất kỳ lần chỉnh sửa mã nào. Với Opus, chỉ có 24% các phiên là như vậy. Trong 13% các phiên do Fable dẫn đầu, mô hình dẫn đầu thậm chí chưa bao giờ tự đọc bất kỳ file repo nào.

Người quản lý vi mô với thực tập sinh vs người quản lý với kỹ sư già dặn

Điểm khiến khoảng cách này trở nên thú vị là: số lần ủy nhiệm do hai mô hình dẫn đầu thực hiện là như nhau, mỗi phiên khoảng 3 lần bàn giao. Log cho thấy từng bước gọi đã bác bỏ giải thích đơn giản “Fable chỉ đơn giản là ủy nhiệm nhiều hơn”. Thực sự khác nhau nằm ở việc “khi nào” nó ủy nhiệm và “ủy nhiệm cái gì”. Lần bàn giao đầu tiên của Fable đến rất sớm.

Opus thì thường ủy nhiệm rất muộn, sau khi tự mày mò và hiện thực trong một khoảng thời gian dài; lúc đó, các quyết định thiết kế đã xong, các file quan trọng đã vào ngữ cảnh của nó, và phần công việc đắt đỏ cũng đã được làm xong.

Một phiên tiêu biểu do Fable dẫn đầu sẽ làm vài bước trinh sát trên repo trước, sau đó viết một bản tóm tắt ở mức đặc tả—ủy nhiệm toàn bộ vòng lặp “hiện thực + kiểm thử + lint” ra một lượt. Tiếp theo, một git show để rà soát diff và rồi commit.

Một phiên tiêu biểu do Opus dẫn đầu sẽ trải qua 20 đến 45 vòng tự khám phá, thiết kế và hiện thực; cộng thêm một lần bàn giao xảy ra rất muộn, chỉ để ủy nhiệm phần kết thúc mang tính cơ học.

Đôi khi, hành động đầu tiên trong một phiên của Fable chính là bàn giao. Ngay trên cùng một nhiệm vụ, phần mở đầu của hai mô hình dẫn đầu trông như sau:

Cách sửa hiển nhiên là buộc Opus phải ủy nhiệm thêm phần khám phá, nhưng ép kiểu hành vi như vậy thường làm giảm hiệu năng. Việc biết điều tra khi nào có thể ủy nhiệm an toàn, và khi nào bạn buộc phải tự làm, bản thân đã là một dạng năng lực phán đoán. Một mô hình bị ép đi ủy nhiệm sẽ không vì thế mà có được năng lực phán đoán ấy; nó chỉ ủy nhiệm đi những thứ đáng lẽ không nên ủy nhiệm.

Phong cách quản lý của mỗi mô hình cũng lộ rõ ngay trong chính bản tóm tắt bàn giao. Khi Opus ủy nhiệm hiện thực, nó đang “ra lệnh”; còn Fable lại đang viết một tài liệu thiết kế:

Việc ủy nhiệm không chỉ là chuyển chỗ chi phí; nó còn thay đổi chất lượng công việc. Nhiệm vụ “băm (hashing)” phía trên là một ví dụ rõ ràng. Đặc tả yêu cầu một hàm băm có độ phức tạp O(1) theo độ dài của con trỏ (pointer). Opus tự tay hiện thực nó, nhưng chưa từng ghi yêu cầu này ở bất kỳ đâu. Ở một bước nào đó trong quá trình, nó quên mất ràng buộc này và giao ra một hiện thực tuyến tính, khiến điểm chỉ đạt 25. Ngược lại, Fable ủy nhiệm bằng các ràng buộc cấp cao. Bản tóm tắt của nó ghi: “operator() phải là O(1) theo độ dài con trỏ: không được quét toàn bộ token.” Cánh tay phải thực thi thành công, đạt 94 điểm.

Chúng tôi nhận thấy mô hình này có thể áp dụng cho nhiều nhiệm vụ. Bàn giao của Fable liệt kê đủ loại ràng buộc, tình huống biên, và một định nghĩa “thế nào là hoàn thành”—vừa giúp tiết kiệm công sức cho chính mình, vừa giúp cánh tay phải thực hiện đúng và rẻ.

Sau khi bàn giao

Phần còn lại là: mô hình dẫn đầu làm gì với các kết quả mà cánh tay phải trả về. Hai mô hình dẫn đầu thường cũng chạy cùng một bộ kiểm tra rẻ: gọi hai ba lần git diff / git show. Nhưng Opus không dừng lại ở đó. Nó kéo file do cánh tay phải tạo về ngữ cảnh của chính nó với tần suất cao gấp 2 lần, và thực hiện nhiều chỉnh sửa mang tính sửa chữa tới mức có thể tới 4 lần, theo giá của mô hình dẫn đầu. Trong tình huống cực đoan nhất, nó hoàn nguyên toàn bộ kết quả của cánh tay phải, rồi tự viết lại:

Sự thiếu tin tưởng của Opus cũng không hề làm tăng tính đúng đắn. Ở một số nhiệm vụ đánh giá, chỉ cần một lần rà soát diff của Fable đã bắt được đúng bug thật sự của cánh tay phải, và nó chọn thực hiện thêm một lần bàn giao rẻ nữa, thay vì kiểu thường xuyên mà Opus hay làm—đó là viết lại ở cấp mô hình dẫn đầu.

Khi ủy nhiệm không giúp được gì

Chiến lược ủy nhiệm của Fable không phải lúc nào cũng dùng được; khi nhiệm vụ không có thành phần nào để ủy nhiệm, nó sẽ không còn hiệu quả. Những kiểu nhiệm vụ sau đây dường như rất khó bị chia tách:

• Các nhiệm vụ ngắn chỉ bao gồm một vài lượt hồi do mô hình dẫn đầu thực hiện, trong đó giữa “quyết định” và “bàn giao” không có gì để ủy nhiệm.
• Các tác vụ debug theo chuỗi, mà căn nguyên nằm ở một loạt các phán đoán liên tục. Ở đây, bản thân ngữ cảnh tích lũy đã là công việc.

Điểm cần lưu ý là: ở những nhiệm vụ như vậy, Fable gần như không ủy nhiệm. Năng lực phán đoán đủ tốt để viết một bản tóm tắt cũng đồng thời biết khi nào không nên viết. Nhưng nếu một nhiệm vụ không có gì đáng để ủy nhiệm, thì việc ủy nhiệm sẽ không có chỗ để phát huy tác dụng về chi phí.

Trong môi trường sản xuất thực tế, Fusion xử lý vấn đề này ở một tầng khác: quyết định ủy nhiệm sẽ xác định công việc nào được giữ lại cho mô hình đắt tiền, còn định tuyến (routing) quyết định liệu mô hình đắt tiền đó có cần phải bị kéo vào hay không.

Kết luận

Khi bắt đầu thí nghiệm này, chúng tôi dự định đo lường xem khoản phụ trội 2 lần của Fable sẽ làm chi phí tăng thêm bao nhiêu. Kết quả khiến chúng tôi bất ngờ: ủy nhiệm hiệu quả của Fable thực ra làm giảm tổng chi phí. Nó chỉ rõ ràng buộc và kết quả chứ không “viết cứng” từng bước hiện thực; nó đưa ra phản hồi chứ không tự tay sửa; và trong phần lớn trường hợp, nó gần như chưa từng chạm vào mã. Những điều này đều là thói quen của một người quản lý tốt.

Khi mô hình cánh tay phải ngày càng rẻ hơn và tốt hơn, có thể giao nhiều việc hơn cho chúng. Và thứ vẫn đáng trả giá tiên phong trong tương lai sẽ chính là năng lực phán đoán: nên làm gì, cần ràng buộc gì, và ai là người viết.