Đo RAM và SSD khi dev chạy Docker kèm Ollama trên laptop

Nhiều lập trình viên thường tập trung vào xung nhịp vi xử lý mà bỏ quên bài toán tắc nghẽn bộ nhớ khi xếp chồng các tác vụ nặng: môi trường VS Code, hàng chục tab trình duyệt, cụm container Docker và một tiến trình LLM cục bộ như Ollama.

Đo mức tải RAM thực tế và bẫy tràn swap khi chạy đa nhiệm

Về mặt kỹ thuật, một mô hình 7B–8B lượng tử hóa Q4 cần từ 4.5 GB đến 6 GB bộ nhớ để nạp trọng số. Trên laptop có 16 GB RAM, sau khi trừ 4–5 GB cho hệ điều hành và IDE, dung lượng còn lại chỉ vừa đủ cho 2 đến 3 container nhẹ (như Node.js và PostgreSQL). Khi mở thêm ngữ cảnh tài liệu dài hoặc chạy thêm Redis/Kafka, máy chạm ngưỡng giới hạn và kích hoạt cơ chế bộ nhớ ảo (swap).

Vấn đề này bên ReviewLaptop cũng có một bài mổ xẻ riêng, ai cần chi tiết hơn thì đọc thêm ở đó.

Để giám sát chính xác mức tiêu thụ bộ nhớ, lập trình viên nên dùng các công cụ dòng lệnh thay vì chỉ nhìn biểu đồ đồ họa:

• Kiểm tra mức nạp layer mô hình vào GPU hay RAM hệ thống: ollama ps
• Đo tài nguyên tiến trình trên Linux/macOS: htop hoặc lệnh Windows: tasklist /FO TABLE
• Theo dõi tần suất swap: chạy vmstat 1 trên Linux và quan sát hai cột si (swap in), so (swap out). Nếu chỉ số so tăng liên tục, CPU đang phải chờ đợi I/O đĩa, làm phản hồi của IDE bị khựng rõ rệt.

Ngưỡng 32 GB RAM trở thành yêu cầu thực tế nếu bạn cần vận hành song song cụm microservices cùng mô hình 8B mà không bị chia sẻ dữ liệu xuống swap.

Áp lực lưu trữ lên SSD và cách đo I/O thực tế

Ổ cứng dung lượng gốc 256 GB sẽ cạn kiệt rất nhanh trong luồng làm việc này. Bản thân Docker images, volume dữ liệu và build cache thường xuyên chiếm 40–80 GB, trong khi mỗi tệp model AI tải về tiêu tốn thêm từ 4 GB đến 15 GB.

Thay vì dựa vào thông số đọc tuần tự quảng cáo, hãy đo thông lượng đọc/ghi ngẫu nhiên (Random 4K) — yếu tố quyết định tốc độ build container và nạp layer — bằng CrystalDiskMark trên Windows hoặc công cụ fio trên Linux:

fio --name=dev-test --ioengine=posixaio --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting

Theo phân tích kiến trúc phần cứng từ TechnologySpot, khi thiếu hụt bộ nhớ chuyên dụng, việc truy xuất tệp qua lại giữa RAM và SSD sẽ kéo tụt tốc độ phản hồi tổng thể. Để kiểm soát tài nguyên lưu trữ, bạn nên dọn dẹp cache định kỳ bằng docker system df và gán biến môi trường OLLAMA_MODELS sang phân vùng ổ đĩa thứ hai nếu máy hỗ trợ nâng cấp.