Google chia sẻ cách tối ưu cân bằng tải cho AI Agent thời gian thực

3 tháng 8, 2026

Việc xây dựng các AI agent thời gian thực không giống như làm việc với các web API tiêu chuẩn mà chúng ta vẫn thường dùng. Với một API điển hình, vòng đời của nó rất dễ dự đoán: client gửi yêu cầu, server xử lý, trả về phản hồi rồi kết thúc. Mô hình nhất thời này rất tuyệt vời vì dễ theo dõi - bạn có thể đo lường hiệu năng thông qua các chỉ số quen thuộc như độ trễ (latency), QPS (số yêu cầu mỗi giây) và mức sử dụng CPU.

Các hệ thống AI thời gian thực làm thay đổi mô hình đó. Thay vì xử lý các yêu cầu riêng lẻ, backend phải quản lý một luồng dữ liệu hai chiều liên tục và trực tiếp. Bạn đang phải đối mặt với một dòng chảy không ngừng của các đoạn âm thanh, bản ghi, kết quả đầu ra từ mô hình và giọng nói tổng hợp được truyền qua lại đồng thời.

Mọi thứ trở nên phức tạp hơn nữa khi người dùng ngắt lời. Server phải ngay lập tức dừng việc tạo giọng nói hiện tại, chuyển hướng để cập nhật ngữ cảnh, có thể kích hoạt một công cụ mới và bắt đầu soạn thảo một phản hồi khác; tất cả việc này phải được thực hiện mà không làm mất kết nối.

Điều này buộc chúng ta phải suy nghĩ lại về cơ sở hạ tầng của mình. Trong thế giới AI thời gian thực, chúng ta không còn chỉ tối ưu hóa cho một yêu cầu đơn lẻ nữa; chúng ta đang quản lý sự phức tạp của một cuộc hội thoại đang diễn ra.

Tại sao QPS là không đủ

Các chiến lược cân bằng tải truyền thống thường ưu tiên lưu lượng yêu cầu (throughput) và mức sử dụng CPU hiện tại. Những phương pháp này giả định rằng mỗi yêu cầu gửi đến tiêu tốn một lượng tài nguyên có thể dự đoán được và việc hoàn thành một tác vụ sẽ giải phóng năng lực xử lý. Tuy nhiên, đối với các luồng AI có trạng thái (stateful) và tồn tại lâu dài, những giả định này không còn chính xác.

Hãy xem xét hai tác vụ backend: Tác vụ A xử lý 100 yêu cầu ngắn, mỗi yêu cầu hoàn thành trong 50 mili giây. Tác vụ B chỉ nhận 5 yêu cầu, nhưng mỗi yêu cầu lại trở thành một phiên làm việc kéo dài 20 phút. Nếu bạn chỉ đánh giá dựa trên tốc độ gửi yêu cầu, Tác vụ B có vẻ ít bận rộn hơn, nhưng thực tế nó có thể đang phải gánh một khối lượng công việc nặng nề và cam kết cao hơn đáng kể.

QPS theo dõi khối lượng yêu cầu gửi đến, nhưng không nắm bắt được số lượng cuộc hội thoại trực tiếp mà server đang quản lý.

Tương tự, mức sử dụng CPU có thể gây hiểu lầm. Ví dụ, một runtime giọng nói có thể chứa 20 phiên im lặng; vì không có quá trình xử lý giọng nói hay suy luận mô hình nào đang diễn ra, server trông có vẻ như chưa được sử dụng hết công suất. Nhưng ngay khi 20 người dùng đó bắt đầu nói đồng thời, mức sử dụng CPU có thể tăng vọt đột ngột.

Trong khi các chỉ số CPU phản ánh tải xử lý tức thời, số lượng phiên hoạt động (active session) lại tiết lộ khối lượng công việc mà backend đã cam kết xử lý. Đối với AI thời gian thực, bạn cần cân bằng cả hai tín hiệu này.

Các luồng dữ liệu tạo ra tải ở cấp độ ứng dụng

Các AI agent thời gian thực thường dựa vào các giao thức truyền phát hai chiều như gRPC hoặc WebSockets. Mặc dù các triển khai cụ thể có thể khác nhau, tất cả đều đối mặt với cùng một rào cản cơ sở hạ tầng: duy trì một kết nối mở, kéo dài, nơi dữ liệu liên tục luân chuyển theo cả hai hướng.

Trong khi một trình quan sát mạng chỉ thấy một kết nối đơn giản, ứng dụng lại coi đó là một phiên làm việc phức tạp và có trạng thái. Bên trong một phiên AI agent thời gian thực, bạn có thể có các bộ đệm âm thanh, bản ghi một phần, các lệnh gọi công cụ đang hoạt động, ngữ cảnh mô hình và các chỉ số dành riêng cho người dùng, tất cả đều nằm trong bộ nhớ runtime.

Các bộ cân bằng tải tiêu chuẩn gặp khó khăn với điều này. Chúng nhìn thấy luồng dữ liệu nhưng không thể phân biệt giữa một cuộc hội thoại thực sự của người dùng, một người nghe đang rảnh rỗi, hay tiếng ồn nền như các lần thử lại (retries) và kiểm tra trạng thái (health checks). Vì cơ sở hạ tầng thiếu khả năng hiển thị các trạng thái nội bộ này, bạn không thể chỉ dựa vào các chỉ số kết nối chung chung. Thay vào đó, bạn cần báo cáo ở cấp độ ứng dụng. Bản thân dịch vụ backend là thành phần duy nhất có đủ ngữ cảnh để theo dõi chính xác khi nào một phiên thực sự hoạt động so với khi nó đã thất bại, kết thúc hoặc bị hủy bỏ.

Theo dõi các phiên hoạt động bên trong runtime

Một mô hình đơn giản là theo dõi các phiên hoạt động tại thời điểm vòng đời của phiên truyền phát bắt đầu và kết thúc.

Kotlin

Đã sao chép

Khối finally không chỉ dừng lại ở việc dọn dẹp cơ bản. Nó chính là thứ giữ cho số lượng phiên hoạt động đủ chính xác để đưa ra các quyết định định tuyến.

Nếu bộ đếm không giảm xuống, backend của bạn có thể trông như đang quá tải rất lâu sau khi phiên đã kết thúc. Ngược lại, việc giảm bộ đếm hai lần có thể báo cáo sai năng lực, dẫn đến việc thu hút quá nhiều lưu lượng truy cập. Các triển khai thực tế cũng cần quản lý cẩn thận các trường hợp biên (edge cases) nơi mà sự kiện timeout, hủy bỏ hoặc ngắt kết nối xảy ra đồng thời để dọn dẹp cùng một phiên.

Về cơ bản, các "phiên ma" (ghost sessions) đóng vai trò là các tín hiệu định tuyến gây hiểu lầm thay vì chỉ đơn thuần là rò rỉ bộ nhớ.

Ngay cả với một bộ đếm chính xác, bạn vẫn phải tính đến sự đồng bộ hóa. Vì các bộ cân bằng tải thường lấy dữ liệu chỉ số theo định kỳ, trong khi các phiên bắt đầu và kết thúc liên tục, dịch vụ của bạn cần báo cáo một ảnh chụp nhanh nhất quán về các phiên hoạt động để ngăn bộ cân bằng tải đưa ra quyết định dựa trên dữ liệu lỗi thời.

Sử dụng số lượng phiên làm tín hiệu cân bằng tải

Khi backend có thể báo cáo các phiên hoạt động, mô hình cân bằng tải sẽ phản ánh khối lượng công việc chính xác hơn. Một mô hình năng lực đơn giản có thể chỉ sử dụng các khe cắm (slots) tĩnh:

Văn bản thuần

Đã sao chép

Nếu bạn có chỗ cho 100 phiên và đang giữ 80, bạn còn 20 khe trống. Nhưng điều này rất mong manh. Nó giả định rằng mỗi phiên tiêu tốn lượng CPU như nhau, điều hiếm khi đúng trong AI tạo sinh.

Đây là lý do tại sao số lượng phiên hoạt động không nên thay thế việc cân bằng dựa trên mức sử dụng; chúng phải được kết hợp thành một mô hình lai. Mức sử dụng (CPU/Bộ nhớ) nắm bắt áp lực tài nguyên hiện tại, trong khi số lượng phiên nắm bắt tải trọng cam kết trong tương lai.

Một cách để kết hợp các tín hiệu này là ước tính năng lực hiệu dụng của mỗi backend bằng cách sử dụng vòng lặp phản hồi. Nhưng trước tiên, chúng phải chuẩn hóa cả hai tín hiệu thành một đơn vị đo lường chung. Vì các bộ cân bằng tải vốn dĩ tư duy theo tốc độ (rates), chúng chuyển đổi số lượng phiên tĩnh thành một luồng liên tục. Ví dụ, nếu một backend giữ 90 phiên hoạt động trong khoảng thời gian báo cáo 10 giây, một cách triển khai có thể coi đây là "9 QPS giả định". Bằng cách chuyển đổi các phiên tĩnh thành một tốc độ tiêu chuẩn, lớp định tuyến có thể thêm áp lực phiên vào các tín hiệu truyền thống như QPS một cách liền mạch.

Một cách đơn giản để ước tính năng lực hiệu dụng là đặt câu hỏi: backend này có thể nhận thêm bao nhiêu công việc trước khi đạt đến mức sử dụng mục tiêu? Công thức ước tính năng lực đơn giản có thể trông như thế này:

Hãy cùng phân tích công thức đó:

Khi bộ cân bằng tải tính toán được Additional_Session_Rate (Tốc độ phiên bổ sung), nó sẽ nhân giá trị này với khoảng thời gian báo cáo và cộng vào các phiên đang hoạt động để tìm ra Năng lực hiệu dụng thực sự (Effective Capacity).

Cách tiếp cận lai này giúp giải quyết vấn đề định tuyến cốt lõi cho các khối lượng công việc AI thời gian thực. Ví dụ, một backend với 10 phiên hoạt động và 90% CPU sẽ có Cost_Per_Session (Chi phí mỗi phiên) rất cao, khiến Additional_Session_Rate của nó về 0, dẫn đến việc không nhận thêm lưu lượng mới. Trong khi đó, một backend với 80 phiên hoạt động nhưng chỉ 40% CPU có vẻ như vẫn còn chỗ trống, nhưng Safety_Scaler (Bộ điều chỉnh an toàn) đảm bảo rằng nó chỉ được nhận thêm các phiên mới một cách dần dần, ngăn chặn các đợt tăng đột biến.

Thuật toán chính xác phụ thuộc vào proxy và khối lượng công việc của bạn, nhưng nguyên tắc thì nhất quán: một bộ cân bằng tải AI thời gian thực phải hiểu được cả trọng số của trạng thái hiện tại và khối lượng của các phiên đã cam kết.

Đánh giá hiệu năng cân bằng tải nhận biết phiên (session-aware balancing)