Bài 7. Kiểm tra mức sử dụng RAM, VRAM và CPU

1. Đặt vấn đề

Khi chạy model AI local, chất lượng câu trả lời chỉ là một phần của vấn đề. Người quản trị còn phải biết model sử dụng bao nhiêu tài nguyên. Một model có thể trả lời tốt nhưng chiếm gần hết VRAM, làm hệ thống không còn dư địa cho request khác. Một model có thể làm RAM tăng cao, dẫn đến swap và chậm. Một pipeline RAG có thể làm CPU quá tải khi xử lý nhiều tài liệu. Nếu không theo dõi RAM, VRAM và CPU, bệnh viện sẽ khó vận hành hệ thống AI local ổn định.

Trong môi trường bệnh viện, kiểm tra tài nguyên phải được thực hiện ngay từ giai đoạn thử model, không chờ đến khi triển khai chính thức.

2. Vì sao phải theo dõi RAM, VRAM và CPU?

Theo dõi tài nguyên giúp trả lời các câu hỏi:

• Model có vừa GPU không?
• Model có chạy trên GPU không?
• VRAM còn dư bao nhiêu?
• RAM có bị đầy không?
• Hệ thống có swap không?
• CPU có quá tải không?
• Có thể chạy thêm API, FAISS, web server không?
• Có thể phục vụ nhiều người dùng không?
• Model nào phù hợp với máy chủ hiện tại?
• Có cần giảm model hoặc nâng cấp phần cứng không?

Không có dữ liệu tài nguyên, lựa chọn model sẽ thiếu cơ sở.

3. Kiểm tra VRAM bằng nvidia-smi

Lệnh quan trọng:

nvidia-smi

Thông tin cần xem:

• Tổng VRAM.
• VRAM đang dùng.
• GPU utilization.
• Nhiệt độ.
• Công suất.
• Tiến trình đang dùng GPU.
• Tên tiến trình Ollama nếu có.

Ví dụ, nếu GPU 16GB và model đang dùng 12GB VRAM, hệ thống còn khoảng 4GB cho context, request khác hoặc tiến trình khác. Nếu VRAM gần đầy, model có thể chậm hoặc lỗi khi prompt dài.

4. Theo dõi GPU realtime

Có thể dùng:

watch -n 1 nvidia-smi

Lệnh này cập nhật mỗi giây, giúp theo dõi khi model đang trả lời.

Nếu có nvtop, có thể dùng:

nvtop

nvtop hiển thị trực quan hơn, nhưng cần cài thêm.

5. Kiểm tra RAM

Dùng:

free -h

Cần xem:

• Total.
• Used.
• Free.
• Buff/cache.
• Available.
• Swap.

Trường quan trọng là available, vì Linux dùng cache nên free thấp không nhất thiết là vấn đề. Nếu available thấp và swap tăng, hệ thống có nguy cơ chậm.

Theo dõi realtime:

watch -n 1 free -h

6. Kiểm tra CPU

Dùng:

htop

Nếu chưa có:

sudo apt install -y htop

Hoặc dùng:

top

Cần xem:

• CPU usage từng core.
• Load average.
• Tiến trình Ollama.
• Tiến trình Python/API/RAG.
• Tiến trình xử lý tài liệu.
• Swap.
• RAM.

Nếu model chạy CPU thay vì GPU, CPU sẽ tăng cao và tốc độ chậm. Nếu API hoặc RAG xử lý nhiều, CPU cũng có thể cao dù model chạy GPU.

7. Kiểm tra tiến trình Ollama

Có thể dùng:

ps aux | grep ollama

Hoặc xem service:

systemctl status ollama

Nếu cần xem model đang nạp:

ollama ps

Lệnh này giúp biết model nào đang chạy và chiếm tài nguyên.

8. Theo dõi ổ cứng khi chạy model và xử lý tài liệu

Mặc dù bài này tập trung RAM, VRAM, CPU, nhưng ổ cứng cũng cần theo dõi:

df -h

du -sh /mnt/data/ai/models

Nếu xử lý tài liệu lớn, file tạm và log có thể tăng nhanh. Nếu ổ đầy, service có thể lỗi.

9. Kiểm tra tài nguyên theo từng loại tác vụ

Cần đo tài nguyên theo các tác vụ:

9.1. Hỏi đáp ngắn

Thường dùng ít tài nguyên hơn, nhưng vẫn cần xem VRAM model.

9.2. Viết văn bản dài

Thời gian GPU hoạt động lâu hơn, sinh nhiều token hơn.

9.3. RAG

Ngoài LLM, còn dùng CPU/RAM cho truy xuất, FAISS, reranker nếu có.

9.4. Tạo embedding

Có thể dùng CPU/GPU tùy model và pipeline. Khi xử lý nhiều tài liệu, tài nguyên tăng rõ.

9.5. Nhiều người dùng đồng thời

Tài nguyên có thể tăng theo request. Cần test thực tế.

10. Dấu hiệu thiếu VRAM

Một số dấu hiệu:

• Model chạy chậm bất thường.
• GPU utilization thấp nhưng CPU cao.
• Log báo offload nhiều sang CPU.
• Request dài bị lỗi.
• Không chạy được model lớn.
• VRAM gần đầy trong nvidia-smi.

Giải pháp:

• Dùng model nhỏ hơn.
• Dùng quantization nhẹ hơn.
• Giảm context.
• Giảm số request đồng thời.
• Không chạy nhiều model cùng lúc.
• Nâng cấp GPU nếu cần.

11. Dấu hiệu thiếu RAM

Dấu hiệu:

• Swap tăng.
• Hệ thống chậm toàn bộ.
• Tiến trình bị kill.
• Xử lý tài liệu lỗi.
• FAISS hoặc API bị dừng.
• Load cao kéo dài.

Giải pháp:

• Tăng RAM.
• Giảm model.
• Tách dịch vụ.
• Giảm số tác vụ đồng thời.
• Tối ưu xử lý tài liệu.
• Giám sát file tạm.

12. Ghi nhận tài nguyên vào bảng benchmark

Khi test model, nên ghi:

Bảng này giúp chọn model khách quan hơn.

13. Kết luận

Kiểm tra RAM, VRAM và CPU là bước không thể thiếu khi làm việc với model trong Ollama. Model phù hợp không chỉ là model trả lời tốt, mà còn phải chạy ổn định trên tài nguyên hiện có. Trong bệnh viện, theo dõi tài nguyên giúp tránh đầy VRAM, đầy RAM, quá tải CPU, chậm hệ thống và lỗi khi triển khai cho nhiều người dùng.