Làm cho Fable rẻ hơn Opus

Chúng tôi đã thay thế Opus 4.8 bằng Fable 5, và hóa đơn của Devin đã giảm xuống.

Fable 5 có chi phí trên mỗi token gấp đôi Opus 4.8. Nhưng khi chạy cả hai mô hình trên FrontierCode 1.1 với kiến trúc Fusion mới của chúng tôi, Fable lại tốn ít chi phí hơn. Không có gì ngạc nhiên, nó cũng đạt điểm cao hơn. Bài viết này giải thích lý do tại sao, và điều đó có ý nghĩa gì đối với việc định giá các tác vụ tác nhân.

Giới thiệu

Bất kỳ ai chạy các tác nhân lập trình đều biết rằng mô hình mạnh hơn mang lại kết quả tốt hơn, nhưng bạn phải trả chi phí.

Khi chúng tôi giới thiệu Devin Fusion, chúng tôi đã chỉ ra một lối thoát: giữ một mô hình tiên tiến phụ trách, cho phép nó ủy quyền cho một trợ thủ rẻ hơn và nhanh hơn, và bạn sẽ có hiệu suất ngang tầm tiên tiến với chi phí thấp hơn 35%.

Nhưng một khi mô hình chính ủy quyền hầu hết công việc, liệu giá trên mỗi token của nó có còn chiếm ưu thế trong hóa đơn không? Fable 5 có chi phí trên mỗi token gấp 2 lần Opus 4.8, vì vậy một tác nhân do Fable dẫn đầu sẽ có chi phí cao hơn. Để tìm hiểu, chúng tôi đã chạy 3.000 phiên đánh giá trên FrontierCode 1.1 với bốn cấu hình: Fable và Opus ở vị trí dẫn đầu, mỗi cấu hình có và không có cùng một trợ thủ rẻ.

Các lần chạy thuần túy hoạt động chính xác như trực giác mách bảo: Fable đạt điểm cao hơn Opus (60.8 so với 55.4) và tốn nhiều chi phí hơn. Mô hình tốt hơn, hóa đơn lớn hơn.

Các lần chạy có hỗ trợ trợ thủ mới là nơi mọi thứ trở nên thú vị.

Với cùng một trợ thủ, thứ tự chi phí đảo ngược: Fable + Trợ thủ có chi phí thấp hơn Opus + Trợ thủ (1,86 đô la so với 2,04 đô la), trong khi đạt điểm cao hơn (60.7 so với 54.6). So với Fable thuần túy, Fable + Trợ thủ cắt giảm chi phí 54% trong khi điểm số gần như không thay đổi.

Cấu hình

Điểm số

Chi phí/lần chạy (trung bình)

Fable 5 (low) + Trợ thủ

60.7

$1.86

Opus 4.8 (medium) + Trợ thủ

54.6

$2.04

Fable 5 (low)

60.8

$4.03

Opus 4.8 (medium)

55.4

$3.06

Hóa ra, mức phí bảo hiểm trên mỗi token gấp 2 lần là con số sai để xem xét. Chi phí của một tác nhân bị chi phối bởi số lượt mà mô hình chính thực hiện, lượng ngữ cảnh nó kéo theo, và trên hết, là những gì nó quyết định không tự làm. Sự khác biệt nằm ở phong cách quản lý: Opus hành xử như một người quản lý vi mô với thực tập sinh; Fable là một người quản lý với một kỹ sư có năng lực.

Thiết lập

Một ôn nhanh về cách hoạt động của kiến trúc trợ thủ Fusion. Tác nhân chính sở hữu phiên: nó nói chuyện với người dùng, lập kế hoạch, xem xét công việc và commit. Nó cũng có một tác nhân phụ trợ thủ cố định để ủy quyền các nhiệm vụ. Tác nhân chính viết một bản tóm tắt chuyển giao bằng ngôn ngữ tự nhiên, và tác nhân phụ, được hỗ trợ bởi một mô hình rẻ hơn nhiều, thực hiện nó trong ngữ cảnh riêng của nó và báo cáo lại. Tác nhân chính xem xét kết quả và quyết định bước tiếp theo.

Để tìm ra chi phí đi đâu, chúng tôi đã làm hai việc. Đầu tiên, chúng tôi phân tích mọi cuộc gọi LLM trên tất cả 3.000 phiên: mô hình nào đang nói, nó gọi công cụ nào, nó đọc và viết bao nhiêu token, và mỗi cuộc gọi tốn bao nhiêu. Thứ hai, chúng tôi chọn 40 tác vụ để xem xét kỹ hơn: những tác vụ mà Fable rẻ hơn đáng kể, những tác vụ mà Opus rẻ hơn, và một mẫu ngẫu nhiên khác từ giữa. Đối với mỗi tác vụ, chúng tôi phân tích lần chạy do Fable dẫn đầu so với lần chạy do Opus dẫn đầu, xem xét các quỹ đạo và quan sát nơi tiền đi.

Chi phí của một tác nhân

Đây là cách chi phí được phân chia giữa tác nhân chính và trợ thủ trong thí nghiệm của chúng tôi:

Tác nhân chính $

Trợ thủ $

Tổng $/lần chạy

Số lượt chính/lần chạy

Token đầu vào chính (tích lũy)

Fable + Trợ thủ

$1.28

$0.58

$1.86

11.5

545k tok

Opus + Trợ thủ

$1.73

$0.31

$2.04

26.5

1,679k tok

Fable chi nhiều hơn cho trợ thủ của nó so với Opus — nhiều hơn 0,27 đô la mỗi lần chạy. Nhưng nó chi ít hơn 0,45 đô la cho chính nó. Tác nhân chính của Fable thực hiện 11.5 lượt mỗi lần chạy so với 26.5 của Opus, viết một phần ba số token đầu ra (6.1k so với 19.0k), và tiêu thụ một phần ba số token đầu vào. Fable đắt hơn đáng kể trên mỗi token, nhưng thắng về quản lý ngữ cảnh và số lượt.

Việc tiết kiệm token của Fable đến từ việc tránh làm việc trực tiếp. Điều thú vị là, trong 81% các lần chạy do Fable dẫn đầu, tác nhân chính không bao giờ thực hiện một chỉnh sửa mã nào. Đối với Opus, điều đó chỉ đúng với 24% các lần chạy. Trong 13% các lần chạy do Fable dẫn đầu, tác nhân chính thậm chí không bao giờ đọc một tệp kho lưu trữ nào.

Một người quản lý vi mô với thực tập sinh so với một người quản lý với kỹ sư

Đây là điều làm cho khoảng cách trở nên thú vị: cả hai tác nhân chính ủy quyền cùng một số lần, khoảng 3 lần chuyển giao mỗi lần chạy. Nhật ký mỗi cuộc gọi bác bỏ lời giải thích dễ dàng rằng Fable đơn giản là ủy quyền nhiều hơn. Điều khác biệt là khi nào và cái gì chúng ủy quyền. Lần chuyển giao đầu tiên của Fable đến sớm. Opus thường ủy quyền muộn, sau một chuỗi dài khám phá và triển khai đơn độc; lúc đó, các quyết định thiết kế đã được đưa ra, các tệp quan trọng đã nằm trong ngữ cảnh của nó, và công việc đắt đỏ đã được hoàn thành.

GIF

Một lần chạy điển hình do Fable dẫn đầu thực hiện một vài hành động trinh sát trên kho lưu trữ, sau đó viết một bản tóm tắt chất lượng đặc tả ủy quyền toàn bộ vòng lặp implement + test + lint. Sau đó, một git show để xem xét sự khác biệt, và một commit.

Một lần chạy điển hình do Opus dẫn đầu trải qua 20–45 lượt khám phá, thiết kế và triển khai đơn độc, và một lần chuyển giao muộn cho phần đuôi máy móc.

Đôi khi, hành động đầu tiên của Fable trong một phiên là một lần chuyển giao. Trên cùng một tác vụ, hai tác nhân chính đã mở đầu như sau:

Giải pháp rõ ràng là làm cho Opus ủy quyền nhiều khám phá hơn, nhưng ép buộc hành vi đó có xu hướng giảm hiệu suất. Biết khi nào một cuộc điều tra an toàn để chuyển giao và khi nào nó là thứ bạn cần tự làm là một phán đoán. Một mô hình bị ép buộc ủy quyền không có được phán đoán đó; nó chỉ ủy quyền những thứ sai.

Phong cách quản lý của mỗi mô hình cũng thể hiện trong chính các bản tóm tắt chuyển giao. Khi Opus ủy quyền triển khai, nó ra lệnh, trong khi Fable viết một tài liệu thiết kế:

Ủy quyền không chỉ di chuyển chi phí; nó cũng thay đổi chất lượng công việc. Tác vụ băm ở trên là một ví dụ rõ ràng. Đặc tả tác vụ yêu cầu một hàm băm phải có độ phức tạp O(1) theo độ dài của con trỏ. Opus đã tự triển khai nó và không bao giờ ghi lại yêu cầu đó ở đâu. Dọc đường, nó quên mất ràng buộc và đưa ra một triển khai thời gian tuyến tính, đạt điểm 25. Ngược lại, Fable ủy quyền bằng cách sử dụng các ràng buộc cấp cao. Bản tóm tắt của nó nói: "operator() phải là O(1) theo độ dài con trỏ: KHÔNG quét token toàn bộ." Trợ thủ đã triển khai thành công điều này với điểm 94.

Chúng tôi thấy rằng mô hình này tổng quát hóa qua các tác vụ. Các lần chuyển giao của Fable liệt kê các ràng buộc, trường hợp biên, và định nghĩa "hoàn thành", tiết kiệm công sức cho chính nó trong khi cho phép trợ thủ triển khai chính xác và rẻ tiền.

Sau khi chuyển giao

Nửa còn lại là những gì tác nhân chính làm với công việc trở lại từ trợ thủ. Cả hai tác nhân chính thường chạy cùng một kiểm tra rẻ: hai hoặc ba cuộc gọi git diff/git show. Nhưng Opus không dừng lại ở đó. Nó kéo các tệp của trợ thủ trở lại ngữ cảnh riêng của nó thường xuyên hơn gấp 2 lần và thực hiện các chỉnh sửa sửa chữa nhiều hơn gấp 4 lần với giá của tác nhân chính. Trong trường hợp cực đoan, nó đã hoàn tác công việc của trợ thủ và viết lại bằng tay:

Sự thiếu tin tưởng của Opus cũng không làm tăng tính chính xác. Trong một số tác vụ đánh giá, việc xem xét diff đơn lẻ của Fable đã bắt được lỗi thực sự của trợ thủ, và chọn một lần chuyển giao rẻ khác, thay vì viết lại ở cấp độ tác nhân chính mà Opus thường sử dụng.

Khi ủy quyền không giúp ích

Chiến lược ủy quyền của Fable không phải lúc nào cũng hữu ích; nó thất bại khi tác vụ không có các thành phần có thể ủy quyền. Các loại tác vụ sau đây dường như khó phân tách:

• Các tác vụ ngắn chỉ bao gồm một vài lượt của mô hình chính và không có gì để ủy quyền giữa quyết định và giao hàng.
• Các tác vụ gỡ lỗi tuần tự nơi việc truy tìm nguyên nhân gốc rễ là một chuỗi dài các phán đoán. Ở đây, ngữ cảnh tích lũy chính là công việc.

Đáng chú ý, trên các tác vụ này, Fable hầu như không ủy quyền chút nào. Cùng một phán đoán viết một bản tóm tắt tốt cũng biết khi nào không nên viết một bản. Nhưng khi một tác vụ không cung cấp gì đáng để chuyển giao, ủy quyền không có đòn bẩy đối với chi phí.

Trong sản xuất, Fusion xử lý điều này ở một lớp khác: ủy quyền kiểm soát công việc nào ở lại với mô hình đắt tiền, trong khi định tuyến quyết định liệu mô hình đắt tiền có tham gia hay không.

Kết luận

Chúng tôi bắt đầu thí nghiệm này với kỳ vọng đo lường mức phí bảo hiểm gấp 2 lần của Fable sẽ làm tăng chi phí bao nhiêu. Chúng tôi đã ngạc nhiên khi thấy rằng việc ủy quyền hiệu quả của Fable thực sự làm giảm chi phí tổng thể. Nó xác định các ràng buộc và kết quả thay vì mô tả chi tiết triển khai, đưa ra phản hồi thay vì tự sửa lỗi, và trong hầu hết các trường hợp, không bao giờ chạm vào mã. Đây là những thói quen của một người quản lý tốt.

Khi các mô hình trợ thủ trở nên rẻ hơn và tốt hơn, nhiều công việc hơn có thể được chuyển giao cho chúng. Điều sẽ vẫn giữ giá trị ở mức tiên tiến là phán đoán: xây dựng cái gì, ràng buộc cái gì, và ai nên viết nó.