Tôi cài đặt Ollama trên Mac Mini M4 Pro để chạy các mô hình Qwen38 và GLM cục bộ, đo lường VRAM và tốc độ thực tế. Kết quả cho thấy ngữ cảnh 32k tiêu tốn thêm 3GB RAM cho mỗi lần kiểm tra, kèm theo các bước khắc phục lỗi công cụ tìm kiếm web thường gặp.

Chuẩn bị máy và cài đặt Ollama

Tôi bắt đầu bằng việc tải bộ cài đặt Ollama cho macOS từ trang web chính thức, hỗ trợ rất tốt chip Apple Silicon M4 Pro. Sau khi cài đặt xong, tôi kiểm tra phiên bản qua lệnh ollama --version để đảm bảo đang dùng phiên bản mới nhất với hiệu suất quản lý bộ nhớ tối ưu.

Bước quan trọng là cấu hình đường dẫn mô hình trỏ đến phân vùng có đủ dung lượng trống, vì các mô hình lớn như Qwen38 có kích thước file lên tới hàng chục GB. Tôi sử dụng lệnh OLLAMA_MODELS=/Volumes/AI_Disk để tách riêng khu vực lưu trữ mô hình khỏi ổ hệ thống, giúp ngăn SSD chính đầy quá nhanh và giảm hoạt động đọc-ghi ảnh hưởng đến tuổi thọ ổ.

Ngoài ra, tôi còn kiểm tra quyền truy cập thư mục này bằng lệnh chmod -R 755 /Volumes/AI_Disk để Ollama có thể tải dữ liệu mà không gặp lỗi Permission Denied - một điểm nhiều người thường bỏ qua khiến việc load mô hình thất bại giữa chừng. Việc chuẩn bị không gian lưu trữ sẵn sàng là nền tảng quan trọng trước khi bước vào giai đoạn tải xuống và kiểm thử hiệu năng thực tế.

Tải xuống và quản lý mô hình Qwen38

Tôi chọn mô hình Qwen38 làm đối tượng chính để kiểm thử do có ngữ cảnh dài tới 32k tokens, phù hợp cho công việc phân tích tài liệu tiếng Việt. Tôi dùng lệnh ollama pull qwen38 để tải file weights (trọng số), mất khoảng 15 phút trên mạng internet tốc độ cao.

Sau khi tải xong, tôi kiểm tra kích thước thực tế bằng lệnh du -sh ~/.ollama/models/blobs/sha256-*, phát hiện mô hình này chiếm khoảng 18GB dung lượng lưu trữ. Khi kết hợp với ngữ cảnh 32k được phân bổ (KV Cache), tổng bộ nhớ sẽ tăng lên 21GB theo dữ liệu trong báo cáo kiểm thử của tôi.

Tôi sử dụng lệnh ollama run qwen38 --num-ctx 32768 để chạy mô hình với kích thước ngữ cảnh tối đa. Cấu hình này yêu cầu hệ thống dành thêm 3GB RAM riêng cho KV Cache, cần thiết để duy trì tính liên tục của cuộc trò chuyện hoặc xử lý tài liệu dài mà không bị quên thông tin trước đó.

Kiểm thử thực tế trên máy

Vào ngày 2 tháng 9 năm 2026, tôi chạy bộ kiểm thử resume-verify trên Mac Mini M4 Pro để kiểm tra trạng thái hệ thống qua API tại webui.siam2r.com/api/version. Kết quả hiển thị mã trạng thái 200, xác nhận dịch vụ hoạt động bình thường.

Tôi kiểm thử tuyến Vision với file PNG kích thước 1x1 pixel, phát hiện cả Qwen3-VL-8B và GLM-4.6v-flash đều vượt qua 3/3 lần kiểm tra với mã 200, cho thấy các mô hình này hỗ trợ xử lý hình ảnh cơ bản ngay trên máy Mac.

Tuy nhiên, tôi gặp vấn đề thực tế khi chạy hàm search_web trong LiteLLM, xuất hiện lỗi "failed-to-parse tool-call args" tại thời điểm 15:52:43. Dù đây là bug của Client Model, tôi cần ghi nhận rằng vấn đề này không liên quan đến cấu hình chính của tôi và không cần sửa code nào, chỉ cần chờ đội phát triển khắc phục ở nguồn.

Bài học từ lỗi và cách khắc phục

Bài học quan trọng tôi rút ra là kiểm thử dạng "dry-run" trước khi đưa vào hệ thống sản xuất (production) giúp ngăn ngừa thiệt hại. Tôi dùng alias qwen38-deep32k-test để mô phỏng tình huống trước khi chạy thật, giúp phát hiện vấn đề sử dụng bộ nhớ vượt dự kiến.

Tôi phát hiện khi chạy Qwen38 cùng lúc với Qwen2.5VL (7.3GB), máy bị swap cao dẫn đến chậm. Do đó, tôi phải thiết kế script predictive.sh để unmount các mô hình không sử dụng ngay sau khi kiểm thử hoàn tất.

Một điểm nữa là về Embedding Dimensions, tôi kiểm tra thấy Nomic-embed-text dùng 768 chiều và BGE dùng 1024 chiều. Hiểu rõ các con số này giúp lựa chọn Vector Database phù hợp, vì nếu chiều không khớp nhau, hệ thống sẽ hoạt động sai mà không hiển thị lỗi rõ ràng, khiến việc debug khó khăn hơn rất nhiều.

Tổng kết hiệu năng và khuyến nghị

Theo dữ liệu thực tế của tôi, Qwen38 Deep 32k tiêu thụ tổng cộng 21GB bộ nhớ (weights 18GB + KV Cache 3GB), trong khi phiên bản Fast chỉ dùng 18GB, phù hợp cho máy có RAM thấp hơn.

Tôi khuyến nghị người dùng Mac Mini M4 Pro có từ 64GB RAM trở lên có thể chạy các mô hình này mượt mà, không cần quá lo ngại về thermal throttling. Tuy nhiên nên đóng các ứng dụng khác tiêu tốn RAM như Chrome hay Xcode khi chạy mô hình lớn.

Cuối cùng, tôi khẳng định Local AI trên Mac cho kết quả đáng tin cậy và an toàn hơn Cloud về mặt riêng tư, nhưng phải đổi lại bằng việc quản lý tài nguyên máy nghiêm ngặt. Theo dõi log và mức sử dụng VRAM thường xuyên là điều không thể thiếu đối với nhà phát triển muốn đạt được sự ổn định.

Muốn theo dõi thêm các bài lab tương tự, hãy follow LINE @icafefx hoặc tải công cụ miễn phí tại redhatai.net.