1. Đặt vấn đề
Một hệ thống AI local có thể chạy tốt khi một người dùng hỏi, nhưng chậm hoặc lỗi khi nhiều người dùng cùng lúc. Trong bệnh viện, số người dùng đồng thời có thể tăng đột ngột khi triển khai chatbot cho toàn viện, khi phòng chức năng cùng sử dụng để làm báo cáo, khi đào tạo tập trung, hoặc khi nhiều khoa cùng tra cứu trong đợt tự đánh giá chất lượng.
Tối ưu số lượng người dùng đồng thời là bài toán quản lý tài nguyên, hàng đợi, model, tác vụ và kỳ vọng người dùng.
2. Người dùng đồng thời ảnh hưởng thế nào?
Khi nhiều request cùng lúc:
- GPU VRAM bị chia tải.
- Model xử lý chậm hơn.
- CPU tăng.
- RAM tăng.
- FAISS/database có nhiều truy vấn.
- API có thể timeout.
- Response đến chậm.
- Người dùng bấm gửi lại, tạo thêm tải.
- Hệ thống dễ nghẽn.
Nếu không có quản lý đồng thời, trải nghiệm người dùng giảm nhanh.
3. Không phải mọi người dùng đều giống nhau
Có nhiều loại tác vụ:
- Hỏi nhanh FAQ.
- Tra cứu quy trình.
- Viết văn bản ngắn.
- Viết báo cáo dài.
- Tóm tắt file lớn.
- Phân tích dữ liệu.
- Batch tạo embedding.
- Tạo bài học dài.
Một request viết đề án dài có thể chiếm tài nguyên bằng nhiều request hỏi nhanh. Vì vậy, không nên xếp mọi request như nhau.
4. Phân loại tác vụ theo tải
Có thể chia:
Tải nhẹ
FAQ, phân loại, câu trả lời ngắn.
Tải trung bình
RAG, tóm tắt ngắn, tạo bảng kiểm.
Tải nặng
Viết báo cáo dài, phân tích nhiều tài liệu, tóm tắt file lớn.
Tải nền
Embedding, indexing, batch xử lý file.
Mỗi loại cần chính sách xử lý khác nhau.
5. Dùng model khác nhau cho mức tải khác nhau
Có thể dùng:
- Model nhỏ cho tác vụ nhanh.
- Model trung bình cho tác vụ thường ngày.
- Model lớn cho tác vụ chuyên sâu, ít người.
- Model embedding riêng.
- Model batch chạy ngoài giờ.
Điều này giúp tránh một model lớn chiếm toàn bộ tài nguyên.
6. Giới hạn request đồng thời
API trung gian nên giới hạn:
- Mỗi user được bao nhiêu request cùng lúc.
- Mỗi khoa/phòng có quota không.
- Model lớn chỉ cho bao nhiêu request đồng thời.
- Tác vụ dài đưa vào hàng đợi.
- Tác vụ ngắn ưu tiên xử lý ngay.
Ví dụ: mỗi user chỉ có 1 tác vụ sinh văn bản dài đang chạy; các câu hỏi tra cứu ngắn có thể xử lý nhiều hơn.
7. Ưu tiên tác vụ
Có thể ưu tiên:
- Tra cứu quy trình ngắn > viết bài dài.
- Tác vụ lãnh đạo > batch nền.
- Tác vụ giờ hành chính > embedding batch.
- Chatbot người dùng > indexing ngoài giờ.
- Tác vụ cấp thiết > tác vụ nền.
Cần cẩn thận để chính sách ưu tiên minh bạch, tránh bất công.
8. Streaming để cải thiện cảm nhận tốc độ
Streaming giúp người dùng thấy câu trả lời bắt đầu xuất hiện sớm, dù tổng thời gian không giảm nhiều. Với tác vụ rủi ro thấp, nên dùng streaming để cải thiện trải nghiệm.
Tuy nhiên, với dữ liệu nhạy cảm hoặc tác vụ cần kiểm soát đầu ra trước khi hiển thị, streaming cần cân nhắc.
9. Cache câu trả lời và nguồn
Một số câu hỏi lặp lại:
- Quy trình khám bệnh.
- Giấy tờ BHYT.
- Biểu mẫu báo cáo sự cố.
- Hướng dẫn sử dụng phần mềm.
Có thể cache kết quả hoặc cache retrieval để giảm tải. Nhưng cần chú ý:
- Cache theo quyền người dùng.
- Cache hết hạn khi tài liệu thay đổi.
- Không cache dữ liệu nhạy cảm tùy tiện.
10. Theo dõi số người dùng thực tế
Không nên đoán. Cần theo dõi:
- Số request/phút.
- Số user hoạt động.
- Thời gian phản hồi trung bình.
- Request đang chờ.
- Request lỗi/timeout.
- Model nào được gọi nhiều.
- Tác vụ nào nặng nhất.
- GPU/RAM/CPU lúc cao điểm.
Dữ liệu này giúp điều chỉnh cấu hình.
11. Kết luận
Tối ưu người dùng đồng thời không chỉ là nâng phần cứng. Cần phân loại tác vụ, chọn model phù hợp, giới hạn request, dùng hàng đợi, ưu tiên tác vụ, cache hợp lý và theo dõi tải thực tế. Trong bệnh viện, hệ thống AI tốt phải ổn định khi nhiều người dùng, không chỉ chạy nhanh trong thử nghiệm một người.
- Đăng nhập để gửi ý kiến
