Bài 3. Model chạy quá chậm

1. Đặt vấn đề

Model chạy chậm là một trong những lý do chính khiến người dùng bỏ hệ thống AI local. Nếu chatbot mất quá lâu để trả lời, nhân viên sẽ quay lại cách tìm tài liệu thủ công hoặc dùng công cụ khác. Tuy nhiên, model chậm có nhiều nguyên nhân: model quá lớn, không dùng GPU, context quá dài, prompt quá nặng, hết VRAM, nhiều người dùng đồng thời, RAG đưa quá nhiều chunk, CPU/RAM/ổ cứng bị nghẽn.

Vì vậy, cần phân tích có hệ thống thay vì chỉ kết luận “GPU yếu” hoặc “model kém”.

2. Dấu hiệu nhận biết

• Thời gian phản hồi dài.
• Token đầu tiên xuất hiện chậm.
• Token sinh ra từng chữ rất chậm.
• CPU cao nhưng GPU thấp.
• GPU đầy VRAM.
• Khi một người dùng thì nhanh, nhiều người thì chậm.
• Câu trả lời dài mất quá nhiều thời gian.
• RAG bật thì chậm hơn nhiều so với không RAG.

3. Kiểm tra model có dùng GPU không

Dùng:

ollama ps

và:

watch -n 1 nvidia-smi

Nếu GPU không tăng tải khi model sinh câu trả lời, có thể model đang chạy CPU hoặc offload quá nhiều sang CPU.

4. Kiểm tra CPU, RAM, swap

Dùng:

htop
free -h

Nếu CPU cao, RAM gần đầy hoặc swap tăng, hệ thống sẽ chậm. Swap là dấu hiệu xấu đối với inference và xử lý tài liệu.

5. Kiểm tra model và quantization

Model càng lớn càng chậm. Nếu GPU 16GB nhưng chạy model quá lớn hoặc quantization cao, tốc độ sẽ giảm. Cần thử model nhỏ hơn hoặc bản quantization nhẹ hơn.

Trong bệnh viện, model mặc định nên là model đủ tốt và đủ nhanh, không nhất thiết là model lớn nhất.

6. Kiểm tra context window

Context quá lớn làm chậm đáng kể. Cần xem:

• num_ctx có đặt quá cao không.
• System prompt có quá dài không.
• Lịch sử hội thoại có gửi quá nhiều không.
• RAG có đưa quá nhiều tài liệu vào prompt không.
• Câu trả lời yêu cầu quá dài không.

Giảm context thường cải thiện tốc độ rõ.

7. Kiểm tra RAG

RAG có thể làm chậm ở nhiều bước:

• Embedding câu hỏi chậm.
• FAISS search chậm.
• Metadata database chậm.
• Rerank chậm.
• Đưa quá nhiều chunk vào prompt.
• Prompt có nguồn quá dài.

Cần đo riêng thời gian retrieval và thời gian generation.

8. Kiểm tra số người dùng đồng thời

Nếu một request nhanh nhưng nhiều request chậm, cần:

• Hàng đợi request.
• Giới hạn request đồng thời.
• Dùng model nhỏ cho tác vụ thường.
• Tách tác vụ dài.
• Không chạy embedding batch giờ cao điểm.
• Dùng streaming cho tác vụ phù hợp.

9. Giải pháp tối ưu

Có thể áp dụng:

• Dùng model nhỏ hơn cho chatbot thường.
• Dùng model lớn chỉ cho tác vụ chuyên sâu.
• Giảm context.
• Rút gọn system prompt.
• Giảm số chunk RAG.
• Tối ưu chunking và retrieval.
• Bật streaming.
• Dùng queue.
• Đặt model/index trên SSD.
• Tách batch embedding ngoài giờ.
• Tối ưu API trung gian.

10. Đánh giá tốc độ theo tác vụ

Không nên yêu cầu mọi tác vụ nhanh như nhau. Có thể đặt chuẩn:

• FAQ: vài giây.
• Tra cứu quy trình: nhanh, có nguồn.
• Viết báo cáo dài: có thể chậm hơn.
• Tóm tắt file lớn: nên chạy tác vụ nền.
• Benchmark/model lớn: chỉ cho quản trị hoặc nhóm chuyên sâu.

11. Kết luận

Model chạy chậm có thể do model, GPU, CPU, RAM, context, prompt, RAG, số người dùng hoặc API. Cần đo từng thành phần trước khi tối ưu. Trong bệnh viện, giải pháp thực tế là dùng nhiều model theo tác vụ, giảm prompt/context, tối ưu RAG, quản lý hàng đợi và theo dõi tài nguyên thường xuyên. Tốc độ đủ dùng là điều kiện quan trọng để AI local được nhân viên chấp nhận.