Bài 1. Các yếu tố ảnh hưởng đến tốc độ phản hồi

1. Đặt vấn đề

Khi người dùng hỏi chatbot AI local và thấy hệ thống trả lời chậm, nguyên nhân không nhất thiết nằm ở model. Tốc độ phản hồi phụ thuộc vào nhiều yếu tố: kích thước model, lượng VRAM, RAM, CPU, tốc độ ổ cứng, context window, độ dài prompt, độ dài câu trả lời, số người dùng đồng thời, RAG, embedding, network nội bộ, API trung gian và cách cấu hình Ollama.

Nếu không hiểu các yếu tố này, bệnh viện dễ tối ưu sai hướng. Ví dụ, thay GPU mạnh hơn nhưng prompt quá dài vẫn chậm. Hoặc giảm model nhưng RAG truy xuất sai khiến câu trả lời nhanh mà không hữu ích. Hoặc chạy model lớn vượt VRAM khiến hệ thống phải offload sang RAM/CPU, tốc độ giảm mạnh.

2. Kích thước model

Model càng lớn thường càng chậm và cần nhiều bộ nhớ hơn. Một model 3B hoặc 4B thường trả lời nhanh hơn model 7B, 8B, 14B, 32B. Tuy nhiên, model nhỏ có thể yếu hơn trong lập luận, viết văn bản dài hoặc xử lý chỉ dẫn phức tạp.

Trong bệnh viện, không nên mặc định dùng model lớn cho mọi tác vụ. Có thể chia:

• Model nhỏ cho FAQ, tra cứu đơn giản, phân loại văn bản.
• Model trung bình cho viết báo cáo, bảng kiểm, phân tích quy trình.
• Model mạnh hơn cho lập luận sâu, đề án dài, tổng hợp nhiều nguồn.

3. Quantization

Ollama thường chạy model dạng quantized, ví dụ Q4, Q5, Q8. Quantization càng thấp thì model càng nhẹ, chạy nhanh hơn, ít tốn VRAM hơn, nhưng có thể giảm chất lượng. Q4 thường là lựa chọn thực tế cho nhiều máy GPU 16GB. Q5 hoặc Q6 có thể chất lượng tốt hơn nhưng tốn tài nguyên hơn.

Không nên chỉ nhìn số tham số model. Cùng một model 7B nhưng bản quantization khác nhau sẽ có tốc độ và nhu cầu VRAM khác nhau.

4. VRAM GPU

VRAM quyết định model có nằm được trên GPU hay không. Nếu model và context không đủ VRAM, một phần sẽ phải chạy trên CPU/RAM, tốc độ giảm. Với GPU 16GB, bệnh viện nên ưu tiên model vừa đủ, tránh chọn model quá lớn cho chatbot tương tác nhiều người dùng.

VRAM còn bị ảnh hưởng bởi:

• Kích thước model.
• Context window.
• Số request đồng thời.
• Số layer chạy trên GPU.
• Model embedding nếu chạy song song.
• Các tiến trình GPU khác.

5. RAM hệ thống

RAM lớn rất hữu ích trong AI local bệnh viện, đặc biệt cho:

• FAISS index.
• Metadata.
• Xử lý tài liệu.
• Chunking.
• Embedding batch.
• Chạy model bằng CPU.
• Cache.
• Nhiều service Docker.
• Nhiều người dùng đồng thời.

Nếu thiếu RAM, hệ thống dùng swap, tốc độ giảm mạnh. Với máy chủ RAM lớn, có thể xử lý tốt RAG và indexing, nhưng sinh câu trả lời vẫn nên ưu tiên GPU nếu cần tốc độ.

6. CPU

CPU ảnh hưởng đến:

• Tiền xử lý prompt.
• Tokenization.
• Chạy model nếu không dùng GPU hoặc offload một phần.
• FAISS nếu chạy CPU.
• API trung gian.
• Xử lý file.
• Nhiều request đồng thời.
• Nén/giải nén, đọc PDF, OCR nếu có.

Dual Xeon hoặc CPU nhiều nhân rất hữu ích cho các tác vụ xử lý dữ liệu, FAISS và batch, nhưng với LLM tương tác, GPU thường nhanh hơn.

7. Ổ cứng

Ổ cứng ảnh hưởng đến:

• Load model.
• Đọc tài liệu.
• Đọc FAISS index.
• Ghi log.
• Xử lý file upload.
• Backup.
• Indexing.

NVMe/SSD nên dùng cho model, index, database metadata, ứng dụng và cache. HDD dung lượng lớn phù hợp lưu tài liệu gốc, backup, archive. Nếu đặt toàn bộ index và dữ liệu nóng trên HDD, tốc độ truy xuất có thể giảm.

8. Context window

Context càng dài, model càng phải xử lý nhiều token đầu vào. Prompt dài làm tăng thời gian trước khi có token đầu tiên và tăng tải VRAM/RAM. Trong RAG, nếu đưa quá nhiều chunk vào prompt, câu trả lời sẽ chậm hơn và có thể nhiễu hơn.

Không nên dùng context lớn chỉ vì model hỗ trợ. Nên dùng vừa đủ theo tác vụ.

9. Độ dài prompt

Prompt gồm:

• System prompt.
• Lịch sử hội thoại.
• Câu hỏi người dùng.
• Tài liệu RAG.
• Hướng dẫn định dạng.
• Metadata nguồn.

Prompt càng dài, tốc độ càng chậm. Một system prompt dài hàng nghìn từ cho mọi tác vụ là không tối ưu. Nên có prompt riêng ngắn gọn cho từng nhóm tác vụ.

10. Độ dài câu trả lời

Câu trả lời càng dài, thời gian sinh càng lâu. Nếu người dùng chỉ cần tra cứu nhanh, nên trả lời ngắn và có tùy chọn “xem chi tiết”. Với bài viết dài, báo cáo dài, đề án dài, chấp nhận chậm hơn nhưng nên đưa vào tác vụ nền hoặc chia phần.

11. RAG và embedding

RAG thêm các bước:

1. Tạo embedding câu hỏi.
2. Tìm FAISS.
3. Lọc metadata.
4. Có thể rerank.
5. Tạo prompt.
6. Gọi model.

Nếu RAG thiết kế tốt, overhead chấp nhận được. Nếu RAG dùng embedding chậm, index lớn không tối ưu, metadata truy vấn chậm, prompt quá dài, tốc độ sẽ giảm.

12. Số người dùng đồng thời

Một người dùng hỏi thì hệ thống nhanh. Nhiều người cùng hỏi thì GPU phải chia tải. Nếu không có hàng đợi, request có thể chậm, lỗi hoặc làm nghẽn model. Chatbot bệnh viện cần tính đến số người dùng đồng thời theo từng thời điểm: giờ hành chính, giao ban, lúc đào tạo, lúc tự đánh giá chất lượng.

13. API trung gian và network

Nếu API trung gian viết chưa tối ưu, mỗi request có thể chậm do:

• Query database chậm.
• Xử lý file quá lâu.
• Không cache.
• Gọi nhiều service tuần tự.
• Timeout chưa hợp lý.
• Ghi log đồng bộ quá nặng.
• Network giữa các server chậm.

Hiệu năng AI là hiệu năng toàn hệ thống, không chỉ Ollama.

14. Kết luận

Tốc độ phản hồi của Ollama trong bệnh viện phụ thuộc vào model, quantization, VRAM, RAM, CPU, ổ cứng, context, prompt, độ dài câu trả lời, RAG, số người dùng đồng thời và kiến trúc API. Tối ưu đúng cần đo từng phần, không đoán. Một hệ thống tốt là hệ thống biết chọn model phù hợp, prompt vừa đủ, RAG gọn, dữ liệu nóng trên SSD/NVMe, có hàng đợi và có giám sát tài nguyên.