Định tuyến mô hình AI: Tưởng đơn giản mà không hề dễ

Quay lại các bài viết

Tích hợp một bộ định tuyến (router) vào agent của bạn nghe có vẻ là một chiến thắng dễ dàng. Gửi các yêu cầu đơn giản đến các mô hình rẻ hơn, dành các mô hình đắt tiền cho những tác vụ khó hơn, hoặc định tuyến theo chuyên môn — Claude cho mã nguồn, Gemini cho đa phương thức, v.v. Một bộ phân loại hoặc thuật toán heuristic sẽ đưa ra quyết định, chi phí giảm xuống, hiệu suất vẫn được duy trì. Xong.

Nhưng thực tế không phải vậy. Hầu hết các hệ thống định tuyến đều giả định rằng việc chọn mô hình là một bài toán phân loại. Theo kinh nghiệm của chúng tôi khi xây dựng tính năng định tuyến vào các hệ thống agent, những gì trông có vẻ là bài toán chọn mô hình lại nhanh chóng trở thành bài toán tối ưu hóa hệ thống. Ba khía cạnh sau đây đã khiến việc này trở nên khó khăn một cách đáng ngạc nhiên đối với chúng tôi.

1. Chi phí không chỉ nằm ở giá của mô hình

Chúng tôi đã kỳ vọng GPT-4.1 sẽ rẻ hơn Claude Sonnet 4.6. Nhưng thực tế thì không.

Trên 417 tác vụ tại AppWorld Test Challenge sử dụng cùng một agent CodeAct, Sonnet tiêu tốn tổng cộng 79 đô la (0,19 đô la/tác vụ) trong khi GPT-4.1 tiêu tốn 155 đô la (0,37 đô la/tác vụ) — gần gấp đôi. Trên lý thuyết, điều này hoàn toàn vô lý. Giá token của GPT-4.1 thấp hơn ở cả đầu vào và đầu ra, và Sonnet cần số bước suy luận nhiều gấp khoảng ba lần để hoàn thành cùng một tác vụ. Chỉ xét theo giá niêm yết, GPT-4.1 lẽ ra phải thắng dễ dàng.

Lời giải thích? Bộ nhớ đệm (caching) — điều mà hầu hết các cuộc thảo luận về định tuyến đều bỏ qua hoàn toàn. Khối lượng công việc của agent có xu hướng tái sử dụng các phần lớn ngữ cảnh qua nhiều bước. Khi tỷ lệ truy cập bộ nhớ đệm (cache hit rates) cao, chi phí đầu vào thực tế sẽ giảm đáng kể. Giá đọc bộ nhớ đệm thấp hơn của Sonnet đồng nghĩa với việc nó được hưởng lợi không cân xứng từ mô hình này, đủ để vượt qua cả mức giá cơ bản cao hơn và các quỹ đạo suy luận dài hơn của nó.

Bài học rút ra: chi phí thực tế phụ thuộc vào sự tương tác giữa mô hình, khối lượng công việc và cơ sở hạ tầng phục vụ. Một bộ định tuyến chỉ nhìn vào bảng giá đang tối ưu hóa dựa trên những con số sai lệch.

2. Độ phức tạp không chỉ nằm ở độ khó của tác vụ

Một chiến lược định tuyến phổ biến là ước tính độ khó của tác vụ và gửi các tác vụ khó hơn đến các mô hình mạnh hơn. Nghe có vẻ trực quan, nhưng nó thất bại theo hai cách.

Thứ nhất, độ khó thường không thể nhìn thấy tại thời điểm định tuyến. Một yêu cầu như "tóm tắt hợp đồng này" trông có vẻ đơn giản, nhưng có thể kích hoạt việc truy xuất dữ liệu, kiểm tra tuân thủ, sử dụng công cụ và nhiều vòng tinh chỉnh trước khi hoàn thành. Trong khi đó, một prompt mang tính kỹ thuật cao có thể được xử lý hiệu quả bởi một mô hình chuyên biệt nhỏ hơn. Bạn thường không biết tác vụ đó thực sự khó đến mức nào cho đến khi quá trình thực thi bắt đầu.

Thứ hai, ngay cả khi bạn có thể ước tính độ khó một cách hoàn hảo, đó cũng chỉ là một tín hiệu trong số rất nhiều tín hiệu khác. Trong môi trường sản xuất, các bộ định tuyến cần cân bằng đồng thời chi phí, độ trễ, chuyên môn của mô hình và độ tin cậy. Các triển khai doanh nghiệp còn chồng chất thêm nhiều yêu cầu: quy định tuân thủ, quy tắc lưu trữ dữ liệu, ràng buộc quyền riêng tư, danh sách mô hình được phê duyệt. Một tác vụ lý tưởng nên được gửi đến mô hình này có thể cần phải chuyển sang mô hình khác vì lý do quản trị — và bộ định tuyến phải xử lý điều đó một cách linh hoạt.

Các bộ định tuyến không chỉ giải quyết một vấn đề duy nhất. Chúng liên tục phải xoay xở giữa chi phí, chất lượng, độ trễ, tính tuân thủ và độ tin cậy cùng một lúc.

3. Độ trễ không chỉ nằm ở tốc độ của mô hình

Thật dễ dàng khi nghĩ về độ trễ thuần túy dựa trên kích thước mô hình — mô hình lớn hơn thì chậm hơn, mô hình nhỏ hơn thì nhanh hơn. Nhưng những gì người dùng thực sự trải nghiệm phụ thuộc vào nhiều yếu tố hơn thế.

Bản thân việc định tuyến cũng tạo thêm chi phí vận hành (overhead). Các yếu tố cơ sở hạ tầng — phần cứng mà mô hình đang chạy, bộ nhớ đệm có đang "nóng" hay không, điểm cuối (endpoint) đang bận rộn như thế nào — thường quyết định thời gian phản hồi từ đầu đến cuối. Một mô hình nhanh về lý thuyết vẫn có thể tạo ra trải nghiệm chậm nếu các điều kiện phục vụ không phù hợp.

Sau đó là tính chi tiết (granularity) của việc định tuyến. Định tuyến mỗi tác vụ một lần sẽ tạo ra chi phí tối thiểu. Nhưng định tuyến ở mỗi bước — điều mang lại cho bạn sự linh hoạt hơn để thích ứng giữa quá trình thực thi — đồng nghĩa với việc mỗi điểm quyết định bổ sung đều làm tăng độ trễ và độ phức tạp vận hành.

Một bộ định tuyến bỏ qua hệ thống phục vụ đang tối ưu hóa dựa trên một thực tế sai lệch.

Vậy chúng tôi đã xử lý điều này như thế nào?

Những bài học này đã định hình cách chúng tôi xây dựng bộ định tuyến của mình. Sự thay đổi then chốt: chúng tôi ngừng coi định tuyến là một bài toán phân loại và bắt đầu coi nó là một bài toán tối ưu hóa. Thay vì đặt câu hỏi "mô hình nào tốt nhất cho tác vụ này?", thuật toán của chúng tôi tối ưu hóa đồng thời chi phí, chất lượng và độ trễ — trong khi vẫn đủ nhẹ để không trở thành điểm nghẽn.

Hình dưới đây cho thấy kết quả trên AppWorld Test Challenge với agent CodeAct. Mỗi hình vuông màu xanh lam là một cấu hình khác nhau của bộ định tuyến, vạch ra một đường biên chi phí-độ chính xác (cost-accuracy frontier). Điều quan trọng không nằm ở bất kỳ điểm đơn lẻ nào — mà là bộ định tuyến cung cấp cho bạn một loạt các điểm vận hành để lựa chọn tùy thuộc vào việc bạn muốn ưu tiên chi phí, độ trễ hay độ chính xác. Cấu hình 1 (tối ưu hóa độ trễ) đạt độ chính xác 84% với chi phí 93 đô la và 83 giây — giảm 21% chi phí và 9% độ trễ so với việc chỉ chạy Opus, với độ chính xác chỉ giảm 4%. Cấu hình 2 đẩy chi phí xuống thấp hơn nữa.

Lưu ý rằng một bộ định tuyến dựa trên độ khó tiêu chuẩn (hình thoi màu xanh mòng két) nằm trong phạm vi độ chính xác tương tự nhưng với chi phí cao hơn — nó không khám phá toàn bộ không gian đánh đổi (tradeoff space) theo cách mà phương pháp dựa trên tối ưu hóa có thể làm được. Và vì bản thân quá trình tối ưu hóa rất nhẹ (khoảng 6 ms và 2 kB bộ nhớ mỗi tác vụ), bộ định tuyến không trở thành điểm nghẽn mà chúng tôi đã cảnh báo trước đó.

Bức tranh toàn cảnh

Bài học chúng tôi rút ra từ công việc này là định tuyến không thực sự chỉ là việc chọn mô hình. Đó là việc tối ưu hóa hệ thống. Các mô hình là một biến số — một biến số quan trọng, nhưng chỉ là một trong số các yếu tố bao gồm hành vi bộ nhớ đệm, trạng thái cơ sở hạ tầng, các ràng buộc tuân thủ và mô hình khối lượng công việc.

Khi việc định tuyến hoạt động tốt, hiếm khi là do nó tìm thấy mô hình "tốt nhất" cho một tác vụ nhất định. Đó là vì nó tìm thấy điểm vận hành tốt nhất cho toàn bộ hệ thống. Đó là một bài toán khó hơn so với phân loại, nhưng là bài toán đáng để giải quyết.

Chúng tôi sẽ chia sẻ thêm về các chi tiết kỹ thuật đằng sau phương pháp của mình trong một bài viết tiếp theo. Trong thời gian chờ đợi, nếu bạn đang xây dựng tính năng định tuyến vào các hệ thống agent của riêng mình, chúng tôi rất muốn biết những sự đánh đổi mà bạn đang gặp phải.

Lời cảm ơn

Bài viết này chịu ảnh hưởng từ nhiều cuộc trò chuyện với các đồng nghiệp, những người có câu hỏi, phản hồi và hiểu biết sâu sắc đã giúp tinh chỉnh tư duy của chúng tôi.