Đưa AI Agent từ bản thử nghiệm lên môi trường production: Kinh nghiệm với Ray và Kubernetes

Hầu hết các đội ngũ phát triển AI agent đều bắt đầu bằng một ứng dụng FastAPI nhỏ chạy trên máy cá nhân. Nhưng khi đưa lên môi trường thực tế với lưu lượng lớn, bài toán trở nên phức tạp hơn nhiều. Tại một hội nghị công nghệ gần đây, hai kỹ sư Deepak Mohanakumar Chandramouli và Bhumik Vinodkumar Thakkar đã chia sẻ kinh nghiệm thực chiến khi chuyển các AI agent sang hệ thống production trên Kubernetes sử dụng Ray.

Từ prototype FastAPI đến hệ thống chịu tải thực tế

Điểm khởi đầu quen thuộc của phần lớn dự án AI agent là một dịch vụ FastAPI đơn giản, gọi tuần tự các mô hình ngôn ngữ lớn (LLM) và công cụ bên ngoài. Cách làm này đủ để demo, nhưng nhanh chóng bộc lộ điểm yếu khi gặp lưu lượng thực:

• Không có cơ chế chịu lỗi khi một bước trong chuỗi agent thất bại
• Khó duy trì trạng thái hội thoại giữa các lần gọi
• Không thể mở rộng linh hoạt khi tải tăng đột biến
• Thiếu công cụ giám sát và đánh giá chất lượng đầu ra

Ray được chọn làm nền tảng vì khả năng phân tán tác vụ, quản lý tài nguyên linh hoạt và hỗ trợ tính toán có trạng thái — những yếu tố cốt lõi cho một hệ thống agent phức tạp.

Cấu trúc RayCluster trên Kubernetes

Nhóm trình bày nhấn mạnh tầm quan trọng của việc thiết kế topology RayCluster phù hợp ngay từ đầu. Một cụm Ray điển hình gồm node head chịu trách nhiệm điều phối và các worker node thực thi tác vụ.

Việc tách biệt rõ vai trò giữa control plane và data plane giúp hệ thống vừa ổn định vừa dễ mở rộng theo chiều ngang.

Các bài học thực tiễn được chia sẻ bao gồm việc cấu hình tài nguyên CPU/GPU riêng cho từng loại tác vụ, tránh để các tiến trình nặng chiếm dụng tài nguyên của control plane, và đảm bảo head node không bị quá tải khi số lượng worker tăng lên.

Quản lý bộ nhớ trạng thái

AI agent khác với các dịch vụ stateless truyền thống ở chỗ chúng cần ghi nhớ ngữ cảnh qua nhiều bước. Nhóm đã áp dụng các actor có trạng thái của Ray để lưu giữ bộ nhớ hội thoại, kết hợp với các cơ chế lưu trữ bền vững bên ngoài.

Một số nguyên tắc được đúc kết:

• Giới hạn kích thước bộ nhớ trạng thái để tránh rò rỉ tài nguyên
• Thiết lập chính sách hết hạn cho phiên hội thoại
• Đồng bộ trạng thái giữa các node để đảm bảo tính nhất quán khi mở rộng

Tự động mở rộng theo lưu lượng động

Khi lưu lượng thay đổi liên tục, việc cố định số lượng worker sẽ dẫn đến lãng phí hoặc quá tải. Giải pháp là kết hợp autoscaler của Ray với các chỉ số từ Kubernetes để mở rộng theo nhu cầu thực tế.

Điểm quan trọng là cần theo dõi các chỉ số phù hợp với đặc thù của AI agent như độ trễ từng bước, số tác vụ đang chờ và tỷ lệ gọi LLM thất bại — thay vì chỉ dựa vào mức sử dụng CPU truyền thống.

Thiết kế control plane vững chắc

Một control plane ổn định là yếu tố sống còn. Nhóm đề xuất tách riêng logic điều phối khỏi logic thực thi, áp dụng cơ chế hàng đợi cho các tác vụ dài, và xây dựng các điểm kiểm tra để có thể khôi phục trạng thái khi xảy ra sự cố.

Guardrail và triển khai đa vùng

Với AI agent, việc kiểm soát đầu ra là bắt buộc. Các guardrail được triển khai ở nhiều lớp: kiểm tra tính hợp lệ của đầu vào, giới hạn công cụ mà agent được phép gọi, và kiểm duyệt đầu ra trước khi trả về người dùng.

Nhóm cũng chia sẻ kinh nghiệm triển khai đa vùng (multi-region) để giảm độ trễ và tăng khả năng chịu lỗi, với lưu ý rằng việc đồng bộ trạng thái giữa các vùng cần được thiết kế cẩn thận để tránh xung đột dữ liệu.

Đánh giá chất lượng với LLM-as-a-judge

Một trong những phần giá trị nhất của bài trình bày là pipeline LLM-as-a-judge — dùng chính một mô hình ngôn ngữ lớn để đánh giá chất lượng đầu ra của agent trong quá trình vận hành.

Cách tiếp cận này giúp phát hiện sớm các trường hợp agent trả lời sai lệch, đồng thời cung cấp dữ liệu để liên tục cải thiện prompt và logic xử lý. Tuy nhiên, nhóm lưu ý cần hiệu chỉnh định kỳ để tránh sai lệch của chính mô hình giám khảo.

Góc nhìn cho đội ngũ tại Việt Nam

Với các startup và công ty công nghệ Việt Nam đang bắt đầu triển khai AI agent vào sản phẩm thực tế, bài học từ phần trình bày này rất đáng tham khảo. Việc đầu tư sớm vào hạ tầng có khả năng mở rộng, cơ chế giám sát và đánh giá chất lượng sẽ giúp tránh những khoản nợ kỹ thuật lớn về sau. Ray cùng Kubernetes hiện đều là công nghệ mã nguồn mở, phù hợp với nguồn lực của nhiều đội ngũ trong nước.

Chuyển từ prototype sang production không chỉ là vấn đề hạ tầng, mà còn là việc xây dựng quy trình đánh giá và kiểm soát chất lượng ngay từ những ngày đầu.