AI tác tử sẽ vấp phải giới hạn hạ tầng trước khi chạm tới giới hạn trí tuệ

Các mô hình đang tiến bộ nhanh hơn khả năng đáp ứng những yêu cầu đặt ra cho chúng.

Phần lớn tranh luận về hướng phát triển của các tác tử AI xoay quanh năng lực. Liệu mô hình có thể lập kế hoạch một cách đáng tin cậy? Nó có thể tự khắc phục sai lầm của mình không? Có thể tin tưởng giao cho nó một hành động gây ra hệ quả hay không?

Đó đều là những câu hỏi xác đáng. Nhưng trong vài năm tới, chúng sẽ không quyết định liệu các tác tử có được triển khai trên quy mô lớn hay không, bởi có một giới hạn cận kề hơn và nó đang xuất hiện nhanh hơn. Việc vận hành tác tử tốn kém một cách khó tránh, và vấn đề này càng nghiêm trọng khi bổ sung chính những năng lực mà ai cũng muốn có.

Chatbot và tác tử là hai loại khối lượng công việc khác nhau

Một yêu cầu hội thoại là một lượt gửi đi rồi nhận về. Gửi lời nhắc vào, nhận token đầu ra, đóng kết nối. Bạn có thể xử lý theo lô, lưu bộ nhớ đệm tiền tố và tính toán thông lượng bằng một con số duy nhất.

Một yêu cầu dành cho tác tử là cả một phiên làm việc. Tác tử gọi một công cụ, chờ, đọc kết quả, quyết định bước tiếp theo, gọi công cụ khác rồi cuối cùng mới trả lời. Một tác vụ tương đối đơn giản có thể cần sáu hoặc tám lượt gọi mô hình, xen kẽ với thời gian chờ.

Sự khác biệt này quan trọng vì một lý do không liên quan gì đến trí tuệ. Giữa các bước, tác tử vẫn giữ trạng thái — nội dung hội thoại, đầu ra từ công cụ và phần lập luận đã tích lũy. Ở phía máy chủ, trạng thái đó nằm trong bộ nhớ GPU dưới dạng bộ nhớ đệm KV, chiếm dụng bộ nhớ suốt phiên làm việc, kể cả những giây tác tử chờ một API không phải do bạn cung cấp phản hồi.

Vì vậy, đơn vị đo năng lực không còn là “số yêu cầu mỗi giây” mà trở thành “số phiên đồng thời thường trú trong bộ nhớ”. Một hệ thống có thể xử lý thoải mái một nghìn yêu cầu hội thoại mỗi giây có thể chỉ phục vụ được vài chục phiên tác tử đồng thời trên cùng phần cứng.

Thời gian chờ mới là phần tốn kém

Đây là điểm đáng ngại: trong lúc gọi công cụ, tác tử không làm gì cả. Không có token nào được tạo ra. Không có năng lực tính toán nào được sử dụng. Tuy nhiên, bộ nhớ GPU vẫn bị chiếm dụng, vì loại bỏ ngữ cảnh rồi tính toán lại sẽ tốn kém hơn giữ nguyên nó.

Phần cứng đắt tiền nhất của bạn đang được dành riêng cho một yêu cầu mà vào thời điểm đó chỉ đang chờ truy vấn cơ sở dữ liệu.

Trong các hệ thống phân tán truyền thống, từ lâu chúng ta đã giải quyết vấn đề này bằng cách giải phóng tài nguyên rồi tiếp tục xử lý công việc khi nhận được phản hồi. Làm tương tự với việc phục vụ mô hình đồng nghĩa với việc chuyển bộ nhớ đệm KV sang bộ nhớ máy chủ hoặc ổ đĩa rồi khôi phục lại; chi phí truyền dữ liệu cao đến mức hầu hết các hệ thống không thực hiện việc đó. Nghiên cứu về chính vấn đề này đang được triển khai tích cực, bởi đây là một vấn đề tốn kém.

Thực thi tuần tự khiến vấn đề trầm trọng hơn mức cần thiết

Gần như mọi khung tác tử đều thực thi các lệnh gọi công cụ lần lượt. Mô hình yêu cầu tra cứu thời tiết, nhận kết quả, yêu cầu kiểm tra lịch, nhận kết quả, rồi yêu cầu tìm chuyến bay và nhận kết quả.

Thông thường, ba lệnh gọi đó không phụ thuộc vào nhau. Chúng có thể được thực hiện cùng lúc. Nếu thực hiện tuần tự, độ trễ bằng tổng thời gian của cả ba; nếu thực hiện đồng thời, độ trễ chỉ bằng thời gian của lệnh gọi lâu nhất.

Đây không phải là một nhận xét mới về tác tử — mà là nguyên tắc cấu trúc tương tự áp dụng cho mọi hệ thống chạy nhiều mô hình hoặc dịch vụ trong cùng một ngân sách độ trễ. Tổng độ trễ nên bằng thời gian của đường đi dài nhất trong đồ thị phụ thuộc, chứ không phải tổng thời gian của mọi công đoạn. Điều này quan trọng hơn đối với tác tử vì phiên làm việc chiếm bộ nhớ GPU trong suốt thời gian hoạt động; do đó, rút ngắn thời gian thực tế không chỉ cải thiện trải nghiệm người dùng mà còn trực tiếp tăng số phiên có thể chạy trên phần cứng.

Giảm một nửa thời lượng phiên thì gần như tăng gấp đôi năng lực xử lý đồng thời trên cùng số GPU mà không cần thay đổi mô hình.

Các lần thử lại cộng dồn theo cách không ai thiết kế

Các khung tác tử kế thừa cấu hình mặc định về số lần thử lại từ những thư viện HTTP bên dưới. Thông thường là ba lần thử.

Mô hình cũng thử lại theo cách riêng. Khi công cụ trả về kết quả không hữu ích, mô hình suy luận thường sẽ thử một cách tiếp cận khác — đó cũng là một lần thử lại, chỉ có điều không ai cấu hình nó.

Kết hợp hai cơ chế này, chính sách cho phép thử ba lần, áp dụng cho một mô hình tự suy luận và thử thêm ba cách tiếp cận, thực chất trở thành chính sách chín lần thử mà không ai ghi lại. Mỗi lần thử đều là một lượt gọi mô hình hoàn chỉnh, tiêu tốn token và thời gian GPU riêng.

Khi một dịch vụ phụ thuộc bị chậm, chính hiệu ứng khuếch đại này biến tình trạng suy giảm thành sự cố mất dịch vụ; chi phí cho mỗi lần thử cao hơn nhiều bậc độ lớn so với một lệnh gọi REST được thử lại.

Giới hạn đó thực sự biểu hiện ra sao

Không phải giới hạn về năng lực. Mà là một vấn đề kinh tế đơn vị bình thường hơn, khiến các dự án bị chặn giữa giai đoạn thí điểm và triển khai chính thức.

Dự án thí điểm hoạt động tốt. Chỉ có mười người dùng, độ trễ chấp nhận được và hóa đơn gần như không đáng kể. Nhưng rồi có người lập mô hình cho mười nghìn người dùng và nhận ra nhu cầu GPU cao đến mức khó khả thi — không phải vì mô hình chạy chậm, mà vì mỗi phiên đồng thời chiếm bộ nhớ trong suốt vòng đời của nó, bao gồm cả thời gian chờ.

Đây là giai đoạn mà nhiều bản trình diễn nội bộ đầy hứa hẹn âm thầm dừng lại.

Điều gì giúp vượt qua giới hạn

Không có gì quá phức tạp, và tất cả đều thuộc về hạ tầng chứ không phải mô hình hóa:

Thực thi đồng thời các lệnh gọi công cụ độc lập. Đây là cải tiến đơn lẻ lớn nhất hiện có, không cần phần cứng mới.

Lấy thời lượng phiên làm thước đo năng lực. Không phải số token mỗi giây. Cũng không phải mức sử dụng GPU. Mà là trạng thái được duy trì trong bộ nhớ bao lâu và có thể chứa được bao nhiêu phiên.

Phân bổ ngân sách cho số lần thử lại trên toàn hệ thống, thay vì cho từng lệnh gọi. Đặt giới hạn chung — số lần thử lại chỉ chiếm một tỷ lệ nhỏ trong tổng lưu lượng — sẽ ngăn hiệu ứng cộng dồn đã mô tả ở trên. Cả hướng dẫn của Google về SRE trong việc xử lý tình trạng quá tải lẫn ngân sách thử lại của Envoy đều áp dụng ý tưởng này bên ngoài ngăn xếp AI.

Tách biệt suy luận khỏi thực thi. Dùng một mô hình lớn để lập kế hoạch và một mô hình nhỏ hơn nhiều cho các bước mang tính máy móc. Phần lớn công việc của một tác nhân không cần đến mô hình tiên tiến nhất.

Giảm chi phí loại bỏ ngữ cảnh khỏi bộ nhớ. Bộ nhớ đệm KV lượng tử hóa, cơ chế chú ý phân trang và các phương thức chuyển dữ liệu ra ngoài cho những phiên không hoạt động. Đây là lĩnh vực đang diễn ra những nghiên cứu thú vị nhất về phục vụ mô hình.

Các mô hình sẽ tiếp tục được cải thiện. Điều đó có vẻ chắc chắn. Việc các tác nhân trở thành hạ tầng hay chỉ dừng ở mức trình diễn phụ thuộc vào một yếu tố kém hào nhoáng hơn — liệu chúng ta có thể phục vụ khối lượng công việc giữ bộ nhớ đắt đỏ trong khi chờ đợi hay không, và liệu chúng ta có ngừng trả chi phí bằng tổng thời lượng của cả chuỗi khi chỉ cần trả theo đường đi dài nhất hay không.

Tôi đã công bố mô hình thực thi làm nền tảng cho luận điểm cuối cùng đó — thực thi đồng thời các lệnh gọi mô hình phụ thuộc lẫn nhau trong cùng một ngân sách độ trễ — trong bài “Thực thi đồ thị suy luận bất đồng bộ để định tuyến mô hình trong các hệ thống học máy”, International Journal of Computer Trends and Technology 72(10), tháng 10 năm 2024. Cụ thể về việc tích hợp các mô hình tạo sinh vào các hệ thống ra quyết định bị giới hạn bởi độ trễ, xem bài “Các nền tảng giao dịch và ra quyết định được tăng cường bằng mô hình ngôn ngữ lớn: Kết nối trí tuệ tạo sinh với các hệ thống ra quyết định tài chính”, Journal of Information Systems Engineering and Management 11(1s), năm 2026.