Bài 6. Kiểm tra tốc độ phản hồi của model

1. Đặt vấn đề

Một model có chất lượng tốt nhưng phản hồi quá chậm sẽ khó được sử dụng trong bệnh viện. Nhân viên y tế và phòng chức năng thường bận, không thể chờ quá lâu cho mỗi câu hỏi. Vì vậy, khi chọn và vận hành model trong Ollama, cần kiểm tra tốc độ phản hồi một cách có hệ thống.

Tốc độ phản hồi không chỉ phụ thuộc vào model. Nó còn phụ thuộc vào GPU, VRAM, RAM, CPU, context length, độ dài prompt, độ dài câu trả lời, số người dùng đồng thời, quantization, nhiệt độ GPU và việc model có chạy hoàn toàn trên GPU hay không.

2. Các thành phần của thời gian phản hồi

Thời gian phản hồi gồm nhiều phần:

• Thời gian nhận request.
• Thời gian nạp model nếu model chưa được nạp.
• Thời gian xử lý prompt.
• Thời gian sinh token.
• Thời gian trả dữ liệu về giao diện.
• Thời gian truy xuất RAG nếu có.
• Thời gian rerank nếu có.

Khi dùng ollama run, người dùng cảm nhận tổng thời gian. Khi tích hợp API, có thể đo chi tiết hơn.

3. Tốc độ sinh token

Tốc độ sinh token thường tính bằng token/giây. Model sinh token càng nhanh thì câu trả lời dài càng nhanh hoàn thành. Tuy nhiên, người dùng thường quan tâm thời gian thực tế: từ lúc gửi câu hỏi đến lúc thấy câu trả lời.

Một model sinh nhanh nhưng prompt xử lý lâu vẫn có thể chậm nếu context quá dài. Trong RAG, đưa quá nhiều tài liệu vào prompt sẽ làm chậm.

4. Kiểm tra tốc độ bằng lệnh đơn giản

Có thể dùng lệnh time để đo thời gian chạy một prompt qua API hoặc command. Ví dụ, khi dùng API có thể đo bằng script hoặc curl. Với ollama run, việc đo thủ công kém chính xác hơn nhưng vẫn có thể ghi nhận thời gian cảm nhận.

Một cách thực tế là tạo bộ prompt cố định và ghi thời gian:

• Câu hỏi ngắn.
• Câu hỏi viết đoạn văn.
• Tóm tắt văn bản ngắn.
• Viết kế hoạch dài.
• Prompt RAG có nhiều ngữ cảnh.

5. Kiểm tra tốc độ lần đầu và lần sau

Lần đầu chạy model có thể chậm hơn vì model phải được nạp vào bộ nhớ. Lần sau có thể nhanh hơn nếu model còn được giữ trong RAM/VRAM. Vì vậy, cần phân biệt:

• Cold start: model chưa nạp.
• Warm run: model đã nạp.

Trong ứng dụng thực tế, nếu model thường xuyên được dùng, warm run quan trọng hơn. Nhưng nếu có nhiều model và model bị unload, cold start cũng cần quan tâm.

6. Kiểm tra độ dài prompt

Cần test với các độ dài prompt khác nhau:

• Prompt ngắn: chỉ câu hỏi.
• Prompt trung bình: câu hỏi + vài đoạn tài liệu.
• Prompt dài: câu hỏi + nhiều chunk RAG.
• Prompt rất dài: tài liệu lớn.

Trong bệnh viện, chatbot RAG thường có prompt dài hơn hội thoại thường. Vì vậy, tốc độ model trong RAG có thể khác tốc độ chat đơn giản.

7. Kiểm tra độ dài câu trả lời

Nếu yêu cầu AI viết bài dài, thời gian sẽ lâu hơn. Cần phân loại tác vụ:

• Trả lời ngắn: dưới 200 từ.
• Trả lời trung bình: 500–800 từ.
• Văn bản dài: 1500–3000 từ.
• Bài chuyên sâu: rất dài, có thể cần chia phần.

Không nên đánh giá model chậm khi yêu cầu nó viết một văn bản dài hàng nghìn từ. Cần đo theo từng nhóm tác vụ.

8. Theo dõi tài nguyên khi đo tốc độ

Khi đo tốc độ, đồng thời theo dõi:

nvidia-smi

htop

free -h

Nếu có:

nvtop

Cần xem:

• GPU utilization.
• VRAM.
• CPU.
• RAM.
• Nhiệt độ.
• Có swap không.
• Model có offload sang CPU không.

Nếu GPU không hoạt động, tốc độ chậm có thể do model chạy CPU.

9. Kiểm tra nhiều người dùng đồng thời

Một model có thể nhanh khi một người dùng, nhưng chậm khi nhiều người dùng. Cần test:

• 1 request.
• 2–3 request đồng thời.
• 5 request đồng thời.
• Nhiều prompt dài cùng lúc.

Trong bệnh viện, nếu triển khai cho phòng ban, cần biết giới hạn thực tế. Có thể cần hàng đợi request hoặc giới hạn người dùng.

10. Lập bảng benchmark

Nên lập bảng:

Bảng benchmark giúp lựa chọn model khách quan.

11. Ngưỡng chấp nhận trong bệnh viện

Không có ngưỡng tuyệt đối, nhưng có thể tham khảo:

• Hỏi đáp ngắn: nên phản hồi trong vài giây đến dưới 20 giây.
• RAG nội bộ: có thể chấp nhận lâu hơn nếu có nguồn tốt.
• Viết văn bản dài: có thể chấp nhận vài chục giây đến vài phút tùy độ dài.
• Tác vụ hàng loạt: nên chạy nền, không bắt người dùng chờ trực tiếp.

Cần thiết kế trải nghiệm phù hợp. Với văn bản dài, có thể dùng streaming để người dùng thấy phản hồi dần.

12. Kết luận

Kiểm tra tốc độ phản hồi là bước bắt buộc khi làm việc với model trong Ollama. Cần đo theo nhiều loại prompt, phân biệt cold start và warm run, theo dõi tài nguyên, kiểm tra RAG và thử nhiều người dùng đồng thời. Model phù hợp với bệnh viện không chỉ trả lời hay, mà phải trả lời đủ nhanh và ổn định trong điều kiện vận hành thực tế.