Baseten Grid đặt câu hỏi: hoàn thành một tác vụ lập trình tốn bao nhiêu?

Một tác nhân lập trình đưa ra bản sửa gọn gàng cho một bài kiểm thử lỗi. Bản sửa không qua được CI, nên lập trình viên yêu cầu tác nhân thử lại. Lần thứ hai đụng đến nhiều phần hơn của kho mã, và người rà soát mất nửa giờ kiểm tra một bản vá tưởng chỉ cần năm phút. Mô hình nào rẻ hơn?

Ngày 4 tháng 11, Baseten giới thiệu Grid dưới dạng bản thử nghiệm công khai. Sản phẩm kết hợp cổng truy cập các mô hình đã được duyệt, bộ định tuyến và các thiết lập tập trung để theo dõi sử dụng và áp dụng giới hạn. Dịch vụ có thể đứng giữa công cụ lập trình được hỗ trợ và các mô hình của chúng để nhóm áp dụng cùng một chính sách cho mọi yêu cầu. Trang đăng ký sớm đưa các nhóm vào danh sách chờ.

Hãy chọn đúng mẫu số

Chi phí trên mỗi tác vụ được chấp nhận. Minh họa do Telli.sh thực hiện.

Giá token đo một đơn vị sử dụng mô hình. Nhóm cần giao một kết quả đáp ứng tiêu chí nghiệm thu. Yêu cầu có thể nhận được câu trả lời, một lượt chạy có thể tạo ra bản thay đổi, mà tác vụ vẫn chưa hoàn tất. Tách riêng các sự kiện đó giúp phép thử định tuyến có ý nghĩa.

Giả sử hai tuyến nhận mỗi bên 100 tác vụ tương tự. Tuyến rẻ chi 50 USD cho tất cả các lần thử và hoàn thành 50 tác vụ đạt yêu cầu. Tuyến kia chi 90 USD và hoàn thành 90 tác vụ. Trong ví dụ này, cả hai đều tốn 1 USD tiền sử dụng mô hình cho một kết quả đạt yêu cầu. Khi cộng thời gian rà soát, phí công cụ và thời gian đợi chạy lại, hai tuyến có thể khác nhau. Những khoản đó có thể khiến bất kỳ tuyến nào tốn hơn.

Hãy giữ các lần thất bại trong tử số. Một tuyến bỏ cuộc trước yêu cầu khó có thể trông hiệu quả nếu chi phí các lần bỏ dở biến mất khỏi phép tính. Giữ nguyên cả định nghĩa thành công. Với thay đổi tài liệu, một bản chỉnh sửa được duyệt có thể là đủ. Việc di chuyển hệ thống cần thử trên dữ liệu hiện có và có cách quay lui.

Loại công việc rất quan trọng. Việc chuyển API trên toàn bộ kho mã có thể khó vì cần ngữ cảnh, phối hợp và nhiều thay đổi nhỏ. Một bản vá một dòng có thể còn khó hơn nếu liên quan đến lỗi đồng thời tinh vi. Số tệp và độ dài câu lệnh chỉ là tín hiệu hữu ích khi dự báo được kết quả trong môi trường của bạn.

Thử nghiệm bộ định tuyến cho thấy sự đánh đổi

Thử nghiệm định tuyến. Minh họa do Telli.sh thực hiện.

Báo cáo kỹ thuật của Baseten so sánh việc luôn dùng Opus 5.5 với việc định tuyến giữa mô hình đó và GLM 5.3 Flash. Trên tập tác vụ phối hợp từ DeepSWE, SWE Atlas QnA và Terminal-Bench, hãng công bố một điểm vận hành có chi phí thấp hơn 72% và tỷ lệ đạt chênh không quá 0,8 điểm phần trăm so với chỉ dùng Opus. Báo cáo so bộ định tuyến với cách chọn ngẫu nhiên ở mức chi phí tương đương. Đây là phép so sánh quan trọng, vì đưa nhiều công việc hơn sang mô hình rẻ sẽ hạ chi phí trung bình ngay cả khi quyết định bằng cách tung đồng xu.

Ngưỡng định tuyến thể hiện mức bạn chấp nhận trả để đổi lấy khả năng thành công dự kiến. Ưu tiên chi phí hơn có thể chuyển nhiều tác vụ sang tuyến rẻ. Một thiết lập khác có thể chọn mô hình mạnh hơn ở nơi kết quả quan trọng hơn. Kết quả của Baseten phản ánh các mô hình, tác vụ và giả định giá mà hãng đã chọn. Nhóm của bạn có cơ cấu công việc và chi phí thất bại khác.

Thông báo sản phẩm nêu một tuyên bố riêng, được làm tròn, rằng chi phí có thể thấp hơn tới 70% trong các bài thử ban đầu. Hãy đọc con số đó tách khỏi kết quả 72% và so sánh tỷ lệ đạt đi kèm trong thí nghiệm. Giá trị chính của báo cáo kỹ thuật là cho thấy sự đánh đổi thay đổi ra sao. Nhóm có thể chọn điểm phù hợp với ưu tiên của mình rồi kiểm tra xem nó có đứng vững khi làm việc thật không.

Cổng truy cập có thể giúp nhìn rõ chính sách

Thông báo Grid mô tả danh sách mô hình được duyệt, thiết lập cấp nhóm và khả năng theo dõi sử dụng. Nhóm phụ trách nền tảng có thể cấp cho lập trình viên quyền truy cập các mô hình tổ chức đã đánh giá và xem mức sử dụng được phân bổ ra sao. Điều này giúp hiểu tiền đang được chi vào đâu ngay cả trước khi giao việc chọn tuyến cho hệ thống.

Thực tế có vài quyết định phải đưa ra. Nhà cung cấp nào được thấy mã độc quyền? Mô hình nào được duyệt cho kho mã cụ thể? Nhóm nào chịu ngân sách thử lại? Ai được đổi tuyến sau sự cố? Cổng truy cập có thể gom những quyết định đó về một điểm chung nếu quản trị viên hiểu mỗi thiết lập chi phối điều gì.

Cổng mô hình và môi trường chạy tác nhân là hai điểm kiểm soát riêng. Cổng có thể quyết định mô hình nào nhận yêu cầu. Công cụ hoặc môi trường chạy quyết định tác nhân được đọc thông tin xác thực, ghi tệp hay gọi qua mạng không. Hạn chế định tuyến có giá trị khi đi cùng các quyền lúc thực thi. Tuyến rẻ vẫn cần những giới hạn tương tự với công cụ có đặc quyền.

Còn có câu hỏi về bằng chứng. Nhật ký định tuyến giúp giải thích vì sao chi phí thay đổi, nhưng dữ liệu theo dõi có thể chứa mã, đường dẫn và chi tiết sự cố của khách hàng. Hãy quyết định nền tảng được ghi gì, ai được xem và giữ bao lâu. Chính sách mà lập trình viên không thể xem thì khó chẩn đoán khi yêu cầu bị từ chối hoặc bất ngờ đi sang tuyến khác.

Thử định tuyến trước khi đổi mặc định

1. Chọn hai hoặc ba nhóm tác vụ phổ biến. Đưa vào một nhóm đơn giản như cập nhật bài kiểm thử thường kỳ và một nhóm khó hơn như di chuyển cần giữ tương thích ngược.
2. Xác định bằng chứng nghiệm thu trước khi bắt đầu. Tác vụ lập trình có thể cần bài kiểm thử hồi quy chạy đạt, bản thay đổi gọn, người rà soát phê duyệt và xác nhận không có tệp nào bị đổi ngoài dự kiến.
3. Ghi mốc tham chiếu với mô hình mặc định hiện tại. Tính cả các lần thất bại, thử lại và phần lập trình viên làm nốt bằng tay. Giữ các giới hạn bảo mật và dữ liệu đang dùng trên hệ thống thật.
4. So sánh định tuyến trên các tác vụ tương đương. Nếu đã được cấp quyền, hãy đọc tài liệu chính thức về công cụ được hỗ trợ và quyền của cổng trước khi kết nối tài khoản.
5. Quyết định khi nào chuyển lên mô hình mạnh hơn. Thất bại lần đầu có thể kích hoạt mô hình thứ hai, nhưng chạy lại không giới hạn có thể tốn hơn dùng mô hình mạnh ngay từ đầu. Đặt giới hạn và ghi lý do chuyển tuyến.
6. Giữ lựa chọn ghi đè cho các tác vụ mà kết quả sai sẽ gây hậu quả lớn. Sau đợt thử, xem các ngoại lệ cùng tổng chi phí và số liệu nghiệm thu.

Trong thử nghiệm nội bộ, hãy so một giai đoạn lập trình viên tự chọn mô hình với một giai đoạn dùng định tuyến trên công việc tương tự. Nhóm đầu có lợi thế hiểu kho mã. Nhóm sau có thể hưởng lợi từ chính sách nhất quán và dễ theo dõi hơn. Ghi lại điểm khác biệt giữa các tác vụ để phép so sánh cho thấy khi nào tự động hóa hữu ích và khi nào phán đoán của con người vẫn có giá trị.

Đọc kết quả của các tác vụ được ghép tương đương

Một điểm bắt đầu tốt là các pull request đã hoàn tất trong một tháng. Gắn nhãn theo yêu cầu ban đầu, chẳng hạn cập nhật phụ thuộc, lỗi có bài kiểm thử tái hiện được, thay đổi qua nhiều kho mã hoặc yêu cầu mở để điều tra một lần triển khai lỗi. Lưu phiên bản kho mã và cách nghiệm thu của từng tác vụ. Chạy lại một mẫu với mốc ổn định và với bộ định tuyến. Dùng cùng công cụ, giới hạn thời gian và môi trường kiểm thử cho cả hai.

Cập nhật phụ thuộc là một trường hợp ít mơ hồ. Tác vụ thành công khi phụ thuộc được chỉ định thay đổi, kiểm tra tương thích chạy đạt và pull request không chứa thay đổi ngoài phạm vi. Tác vụ chạm đến điều khoản tính phí cần rà soát kỹ hơn. Nó cũng có thể cần người đọc hiểu những yêu cầu chưa đầy đủ. Tách các nhóm công việc giúp thấy chi phí trung bình thấp hơn đến từ đâu. Nếu tuyến rẻ xử lý tốt cập nhật phụ thuộc nhưng phải chạy lại nhiều với thay đổi tính phí, nhóm có thể định tuyến khác nhau cho hai trường hợp.

Ghi thời gian một người cần để quyết định có chấp nhận kết quả hay không. Giả sử mốc tham chiếu tạo 19 kết quả được chấp nhận trên 20 tác vụ với chi phí 19 USD, còn bộ định tuyến tạo 18 kết quả với 9 USD. Trong phép tính minh họa, chi phí mô hình trên mỗi kết quả được chấp nhận lần lượt là 1,00 USD và 0,50 USD. Nếu người rà soát mất thêm 20 phút sửa một kết quả định tuyến thất bại, phép so sánh chi phí sẽ đổi. Tổ chức có thể tính phần làm lại mà vẫn phân biệt tiền với thời gian.

Tìm hiểu bộ định tuyến học từ những tác vụ nào

Bài kỹ thuật của Baseten nêu DeepSWE 1.1, SWE Atlas QnA và Terminal-Bench 2.1. Nghiên cứu so sánh Claude Opus 5.5 với GLM 5.3 Flash trên nhiều tác vụ rồi đánh giá bộ định tuyến trên dữ liệu dành riêng cho kiểm thử. Chi tiết đó quan trọng khi quyết định nên áp dụng kết quả rộng đến đâu. Câu hỏi tìm vị trí trong kho mã có cơ cấu chi phí khác với việc chạy lệnh shell, dùng công cụ bên ngoài hoặc sửa nhiều tệp. Phép đánh giá của khách hàng cần đại diện cho các tác vụ họ thực sự định gửi.

Bài viết mô tả Cost, Balanced và Intelligence là các lựa chọn theo từng yêu cầu làm dịch chuyển ngưỡng định tuyến. Nhóm sản phẩm có thể dùng chúng để so sánh song song trên dữ liệu thử. So các thiết lập trên một tập yêu cầu được phép chạy lại và ghi mô hình đã chọn nếu tích hợp cho biết. Xem kỹ những trường hợp thiết lập chọn khác nhau. Nếu lựa chọn đắt tập trung ở các trường hợp nhóm xem là nhạy cảm hoặc khó, chính sách có thể đang hoạt động đúng ý. Nếu khác biệt tập trung vào một tác vụ phổ biến và đơn giản, có thể cần chỉnh cách phân loại hoặc chính sách.

Theo dõi những tác vụ chậm và tốn kém nhất

Độ trễ trung bình có thể che mất thời gian người dùng chờ một bản vá khó đi qua nhiều mô hình. Ghi thời gian thực tế từ lúc yêu cầu đến lúc chấp nhận kết quả và đánh dấu mọi lần thử lại, chuyển cấp, hết thời gian chờ hay bàn giao. Bảng điều khiển chỉ hiển thị thời gian phản hồi của mô hình đầu có thể báo tiến bộ cho một tác vụ người vận hành phải khởi động lại. Hãy tính cả chi phí và thời gian sau khi bàn giao.

Giới hạn đợt thử trước khi mở rộng. Đặt ngân sách cho toàn tác vụ và quy tắc dừng hoặc chuyển lên mô hình có năng lực hơn. Lần thử thất bại cần để lại đủ bằng chứng cho lần sau làm tiếp. Đừng chạy lại bài kiểm thử hoặc đọc lại các tệp chỉ vì bộ định tuyến chọn mô hình khác. Chỉ số hữu ích là công việc đã tiến thêm được bao xa.

Khi triển khai, hãy bắt đầu với nhóm tác vụ hẹp có thể nghiệm thu tự động và để con người kiểm tra ngoại lệ. Sau đó thêm một nhóm mà việc nghiệm thu đòi hỏi phán đoán. Tách riêng chi phí trên mỗi tác vụ được chấp nhận, tỷ lệ chuyển cấp và thời gian rà soát. Nếu lợi ích vẫn còn sau khi đổi nhóm, tổ chức có cơ sở tốt hơn để chọn mặc định.

Giữ mốc tham chiếu hữu ích sau khi thay mô hình

Kết quả thu thập trong một tuần có thể lỗi thời khi một mô hình, công cụ hoặc kho mã thay đổi. Lưu mã định danh mô hình, phiên bản kiểm thử và quy tắc nghiệm thu cùng quyết định định tuyến. Khi sửa chính sách, chạy lại một nhóm nhỏ tác vụ đại diện. Giữ trong nhóm vài trường hợp thất bại tốn kém, vì chi phí của chúng dễ bị che trong số trung bình.

Đề nghị người rà soát xem một trường hợp hai tuyến chọn khác nhau mà không biết mô hình đã chọn. Nếu họ không xác định được kết quả nào đạt yêu cầu, hãy làm rõ tiêu chí trước khi chạy thêm. Chính sách định tuyến dễ so sánh hơn khi nhóm thống nhất cách nhận ra thành công.

Chính sách cần thay đổi theo công việc

Định tuyến có giá trị khi nhóm không phải lặp lại cùng một quyết định nhỏ. Nó đặc biệt hữu ích khi hiệu quả và giá có thể đo trên cùng một đơn vị công việc. Mô hình, giá và kho mã sẽ thay đổi theo thời gian. Hãy giữ các tác vụ tham chiếu và cập nhật tập kiểm thử để chính sách bắt kịp.

Con số đáng mang đến cuộc họp kế hoạch là khoản nhóm đã trả để giao phần việc được chấp nhận, kèm mô tả rõ những gì phải đánh đổi. Trưởng nhóm kỹ thuật và người phụ trách ngân sách có thể cùng quyết định dựa trên đó.

Nguồn

• Thông báo bản thử nghiệm Grid ngày 4 tháng 11 của Baseten
• Báo cáo kỹ thuật Router ngày 4 tháng 11 của Baseten

---

Để lưu các cuộc trao đổi và quyết định trong công việc theo cách có thể tìm lại, hãy tạo tài khoản Telli.sh.