Bài 7. Quản lý hàng đợi request

1. Đặt vấn đề

LLM inference là tác vụ tốn tài nguyên. Nếu mọi request được gửi thẳng đến Ollama ngay lập tức, hệ thống có thể bị nghẽn khi nhiều người dùng cùng hỏi hoặc khi có tác vụ dài. Hàng đợi request giúp điều phối tải, tránh quá tải GPU, ưu tiên tác vụ quan trọng và cung cấp trải nghiệm dự đoán được hơn.

Trong bệnh viện, quản lý hàng đợi rất quan trọng vì có nhiều loại tác vụ: hỏi nhanh, tra cứu RAG, viết văn bản dài, tóm tắt file, embedding tài liệu, batch xử lý hồ sơ, benchmark model.

2. Hàng đợi request là gì?

Hàng đợi là cơ chế tiếp nhận request, xếp thứ tự và xử lý theo năng lực hệ thống. Thay vì tất cả request cùng chạy, hệ thống quyết định request nào chạy ngay, request nào chờ, request nào từ chối vì quá tải, request nào chạy nền.

3. Vì sao cần hàng đợi?

Hàng đợi giúp:

• Tránh GPU bị quá tải.
• Giảm timeout.
• Giới hạn số request đồng thời.
• Ưu tiên tác vụ quan trọng.
• Theo dõi thời gian chờ.
• Cho phép hủy tác vụ.
• Tách tác vụ realtime và batch.
• Cải thiện ổn định hệ thống.

Không có hàng đợi, hệ thống dễ bị “lụt request”.

4. Phân loại queue

Có thể có nhiều hàng đợi:

Queue realtime

Cho câu hỏi ngắn, chatbot tra cứu, RAG nhanh.

Queue long task

Cho viết báo cáo dài, tóm tắt file lớn, tạo chương dài.

Queue batch

Cho embedding, indexing, xử lý nhiều tài liệu.

Queue admin

Cho benchmark, quản trị model, cập nhật index.

Mỗi queue có số worker và ưu tiên riêng.

5. Chính sách ưu tiên

Có thể ưu tiên theo:

• Loại tác vụ.
• Vai trò người dùng.
• Mức độ khẩn.
• Độ dài request.
• Model cần dùng.
• Thời gian chờ.
• Tác vụ nội bộ hệ thống.

Ví dụ, batch embedding không nên chiếm GPU khi nhiều người dùng đang chat trong giờ hành chính.

6. Giới hạn thời gian và kích thước

Hàng đợi cần giới hạn:

• Thời gian tối đa một request.
• Độ dài prompt.
• Độ dài output.
• Kích thước file.
• Số request đang chờ.
• Số request/user.
• Số request/model.

Nếu vượt giới hạn, hệ thống nên báo rõ thay vì treo.

7. Trạng thái request

Người dùng nên thấy trạng thái:

• Đã nhận.
• Đang chờ.
• Đang xử lý.
• Hoàn thành.
• Lỗi.
• Đã hủy.
• Quá tải, vui lòng thử lại sau.

Không nên để người dùng bấm nhiều lần vì tưởng hệ thống không hoạt động.

8. Hủy request

Cần cho phép hủy tác vụ dài. Ví dụ, người dùng yêu cầu viết báo cáo dài nhưng phát hiện prompt sai. Nếu không hủy được, GPU tiếp tục chạy lãng phí.

9. Retry

Một số lỗi có thể retry:

• Ollama tạm bận.
• Timeout nhẹ.
• Lỗi kết nối tạm thời.

Nhưng không nên retry vô hạn. Retry có thể làm tải nặng hơn.

10. Công nghệ triển khai

Có thể dùng:

• Hàng đợi trong ứng dụng đơn giản.
• Redis Queue.
• Celery.
• RabbitMQ.
• Database job queue.
• FastAPI background task cho mức nhỏ.
• Systemd service/worker riêng.

Giai đoạn đầu có thể đơn giản, nhưng cần thiết kế để mở rộng.

11. Log hàng đợi

Cần ghi:

• Thời gian vào queue.
• Thời gian bắt đầu xử lý.
• Thời gian hoàn thành.
• Model.
• User.
• Loại tác vụ.
• Trạng thái.
• Lỗi.
• Token input/output nếu có.

Dữ liệu này giúp phát hiện nút thắt.

12. Kết luận

Quản lý hàng đợi request là yếu tố quan trọng để Ollama vận hành ổn định trong bệnh viện. Hàng đợi giúp kiểm soát tải, ưu tiên tác vụ, tránh quá tải GPU và cải thiện trải nghiệm người dùng. Khi hệ thống mở rộng cho nhiều khoa/phòng, queue không còn là tùy chọn kỹ thuật phụ, mà là thành phần vận hành bắt buộc.